一直以来,许多企业进行敏捷转型,不少转型推动者其本身都有丰富的项目管理经验,认为找到一个流行的敏捷框架(比如scrum),就能把敏捷转型做好——这太理想化了。
先抛出一个问题来,“如果你是老板,在你的项目状态会议上,你最想要向项目经理问到什么?”
艾利·高德拉特博士,作为一个企业管理大师,曾经说过这样一句话:“告诉我你怎样评价我,我就会告诉你我会怎样行事。”这恰恰说明了,人们的行为取决于受评价的方式。对于敏捷转型来说,最大的障碍在于项目管理和人员管理的考核。这是因为敏捷改变了我们评价项目成就的方式,也改变了我们评价人员行为的标准。
在软件行业,项目经理会定期受考核,考察项目是否处在正轨。每周项目经理都会报告项目的状态:是否如计划行事?是否符合预算?是否按时推进?是否超出范围?于是他们尽一切努力避免项目超支、超时、超出范围。你会问,这有什么问题吗?项目经理按照预期行事,并因此获得奖励,难道不应该吗。然而问题正是在于此,让项目“保持正轨”不应该是公司的目标!我们都知道,软件产品很难预测最终状态,所以所谓朝着最终状态前进是不可行的。我们需要改变项目目标!“无法基于未知的最终状态进行评价”的前提下,项目目标应该是满足用户需求。我们的目标应该是交付正确的产品(创造利润的)并保持客户满意度。几乎不曾有哪个初始的项目计划能符合这一目标(项目计划总是需要不停调整)。终归一句话:“关注于纠正错误的事情”并不会直接帮助我们实现目标。
讲完敏捷转型的最大障碍,我们来讲讲敏捷转型失败的三大模式(三大坑),其实坑也是障碍的一种表现。
这种失败模式会以不同的方式显现;最终,它会证明其头号失败模式的地位并推动所有其他失败模式。行政支持用当下的话说又叫做“投入”,缺少行政支持可能来自两个方向。
想像一小群渴望采用敏捷的技术人员。在没有任何行政支持的情况下,他们要躲避监管,不让可能会令他们停工的管理层发现。在团队内部,项目可能会取得短暂的动力,但不大可能有持续性。缺少行政支持将限制对团队成功情况的了解,无法为所有后续团队的是否采用敏捷提供足够的支持。
在第二种情景中,某位高管下令在整个 IT 组织实施敏捷转型,但却没有真正的贯彻落实,只是一张空头支票。不改变成功的指标(其实就是上文讲述的最大障碍),这些采用敏捷的宣言很可能永远不会带来真正的业务转型。缺少执行者的持续参与,组织最多只有零星的敏捷成功,而且通常仅在团队层面。
管理人员与其团队合作的方式对采用敏捷的成败也具有影响。管理人员依赖自上而下的方法,在几乎不考虑团队意见的情况下推进项目,这种情况太常见了。
这样的管理风格是经典的敏捷转型失败模式。如果管理人员不接受更加服务于团队的行为,而是试图控制他们,所有团队层面的敏捷实践终究没有任何意义。Robert Greenleaf 指出了他所谓“仆人式领袖”的特征:通过带领来服务,并通过服务来带领。仆人式领袖是成功的敏捷转型的关键。
您目前的组织结构是什么?每个敏捷团队周围存在多少层管理?如何感知监管?谁准备好消除隔阂以确保价值在组织中流动?
这些都是关键的问题,因为失败的敏捷转型源于无法改变现有组织基础架构。通过部门绩效与总体价值交付对比来衡量成功的组织限制了总体成效的可见性。他们还以组织成功的代价将注意力集中于特定团队的绩效。
在软件行业,很多项目形态的管理是把事情“做”对;相对而言,产品形态的管理更偏向是“做”对的事情。其实在我看来,不管是项目型还是产品型,最终都是为了交付价值,都应该是“做”对的事情。
在将传统的项目管理方法应用到复杂软件产品时,经常是把“错误”的事情做对(按时、不超支、在范围内)。
好的敏捷产品领导则会接受这些现实:计划可能是错误或不清晰的,范围是未知的。由此敏捷会适应变化并做正确的事情,以满足我们客户的需求。
当项目经理调整并改进项目计划,以使其一直符合目标、跟上变化的需求并应对突发事件时,他们就应该得到奖励,升为领导。但更常见的情况是,他们尽可能强制让突发事件和现实去符合他们的计划,于是“管理”项目的结果是让项目越走越偏。
换句话说,他们的行为取决于我们的考核方式。所以,在我们的下一次项目状态会议上,想想我们应该要问什么:我们是在要求项目经理展现对客户和现实情况的意识,并表明他们在应对变化,还是因为他们说项目一切正常、没有问题就奖励他们?看到这里,答案显而易见了。
没有问题才是最大的问题。——大野耐一(丰田生产方式的创始人)。往往很多项目经理都在努力的证明自己的项目没有问题,这非常可怕。
参考文献:
https://www.onlyscrum.com/
https://baijiahao.baidu.com/s?id=1594167901723988212&wfr=spider&for=pc