业务动态

当稳定的过程,遇上敏捷……

时间:2019-7-31 17:15:02  作者:Fancier凡奉信息

S公司是一家成立15年的软件企业,遵循传统的项目管理模式,流程完备、成熟度高。为了落实客户导向,公司设置了独立的产品部,专门负责对接与转化客户需求,之后交由研发部来实现。


Daniel是研发部的PM,8年工作经验。尽管入职三年有余,他依旧非常不喜欢这套标准而复杂的项目管理流程。因为,Daniel是个坚定的敏捷者。为了推行敏捷,他总跟研发部的老大Sam唠叨:“敏捷的及时交付、拥抱变化,杜绝价值浪费,只做最具价值的工作......”Sam虽然心动,但毕竟受限于公司的“规矩”,对敏捷这事儿一直没松口。

终于在今年年初,公司明确提出要降低成本,缩短交付周期,提高人员效率,并要求每个部门积极发挥主观能动性与协作精神,在Q4完成转型调整,实现目标。于是,Sam让已经是Scrum Master的Daniel制定一个敏捷转型计划,并带领团队进行试点。

Daniel等这一天已经三年了!为了让敏捷转型计划完美无瑕,Daniel要做到的第一件事,便是获得产品部门的认可。于是,他第一时间找来了产品经理Leo,提出了三点敏捷改进建议:


1.   希望Leo放弃原来厚厚的用户需求说明书,改用简单的待办产品列表来说明需求

2.   产品部提出来的需求,研发部每次会进行一个为期4周的Sprint迭代开发,期间不接受任何需求调整

3.   研发部每四周,会交付一个可用的版本,供产品部与客户进行确认

然而,Daniel大刀阔斧的敏捷想法,在Leo眼中却极为不妥。

首先,复杂全面的用户说明书是产品部的考核指标,改成待办产品列表,无法满足人力资源部门的绩效考核要求。

第二,这个项目的客户是公司的大客户,极为强势且“变化多端”。产品部贯彻公司客户导向的指导方针,从来都是有求必应。4周0变化,不仅违背了公司的经营思想,也会引起客户的不满。

第三,每4周需要客户参与一次评审。以前没实施过,不知道有没有问题。

像S公司的例子其实屡见不鲜——规范而标准的管理流程,带来了稳定的绩效保障,也限制了工作的灵活性与人员的能动性。既然要改,那么敏捷便是首当其冲的选择。可是,船大难掉头。


Daniel一蹴而就的敏捷,显然会受到方方面面的制约。那么“混合敏捷”的概念,就是恰如其分的转型之选。

1.   识别参与改进的范围,比如S公司的产品部和研发部。挑选适合的改进试点项目,比如找个不那么难缠的“小客户”,尽可能减小改进失败的影响。

2.   充分考虑既有的各项工作流程,识别出可以直接替换、间接转化,以及无法适应的部分,并一一制定调整方案。案例中,敏捷除了影响了研发部与产品部既有的工作流程外,还冲击了人力资源部的绩效考核流程,以及客户公司的评审验收流程。这些既有的“规矩”,都是变革时的限制因素。

3.   不要盲目遵从敏捷特有的规则,比如一个Sprint必须是4周。而是应该全方位考虑项目的特点、人员的能力、客户的接受程度等各方面因素。


4.   敏捷流程建立后,会冲击既有的岗位与角色。为了让试点人员各就各位,除了必要的培训外,还要考虑到角色变化带来的职责与心理的变化。比如,别一上来就把项目经理给“咔嚓”了,这必然会遭到“反噬”。

5.   最后,也是最重要的部分,就是用数据度量改进的成果。没有什么方法是绝对好的,如果敏捷无法实现S公司的目标,那么大动干戈,就不如四平八稳了。

既然成熟的公司敏捷起来那么费劲。那么敏捷,是不是更适合于那些“规矩”不多的公司呢?下一篇,我们将深入聊聊敏捷的精神,不迷信、不盲从。


更多PM管理干货,请关注凡奉信息微信公众号 fancier-info

CMMI、PCMM服务提供商-Fancier凡奉信息微信公众账号二维码

专注于为软件、互联网企业提供CMMI发过程管理PCMM人力资源管理结合的咨询、培训与评估服务

公司网站:www.fancier-info.com

业务热线:4009-9393-06

服务邮箱:service@fancier-info.com

QQ咨询:3200634404

  • 返回顶部
  • 4009-9393-06
  • 在线咨询
  • 凡奉微信公众号
    关注凡奉信息