头脑敏捷的负责人会预见项目执行中的不确定性变化,并灵活应对,而不是固守原来的计划。实践中,他们深知预估性判断的局限性,因而更信赖自己的变通能力,即根据变化对项目的步骤和做法进行调整。
首先,看一下企业对“成功”是如何定义的。长期对软件项目进行“成功(或失败)”评级的斯坦希集团(Standish Group)认为,如果一个项目能够“在计划的时间、预算内完成,并达到所有计划之内的预期特征和功能”,便称之为成功。但是,这个定义不是以创造价值为基础的,而是以各种条条框框为基础的。按照这样的定义,项目经理们就只能紧遵计划执行,而不会去应对任何突发的变化。
相反,如果把客户价值和质量作为最终目标,那么计划就成了实现这些目标的手段,而非目标本身。计划设定的条条框框依然重要,依然指导着项目的执行,但是我们也应该清楚,计划并非圣旨那样尊不可违,而是具有一定的灵活性的;计划应该成为行动的指南,而不是紧箍咒。
传统的项目负责人也罢,敏捷的项目负责人也罢,都会制定计划,而且会为之投入相当的时间。但是他们对待计划的态度截然不同。虽然他们都把计划当作底线,但是传统的项目负责人会按照这个底线,时不时对实际的结果试图“纠正”。在敏捷项目管理中,我们采用“调整性行为”来说明应该采纳的一些正确做法(其中之一便有可能是纠正计划本身)。
在关于敏捷处理原则的文件中—包括敏捷宣言(Agile Manifesto, AM)和相互依赖宣言(Declaration of Interdependence, DOI)—有对怎样随机调整做出的五条主要说明:
>预见项目执行中可能发生的不确定性,并且通过试点、预估性判断和随机调整来管控这些不确定性。(DOI)
>通过采取符合具体情况的策略、步骤和做法,提高项目的效率和可靠性。(DOI)
>面对突发性变化,应该调整计划予以应对,而非继续执行原计划。(AM)
>哪怕项目已临近收尾,也要对客户在项目要求上提出的变化持欢迎态度。敏捷的项目过程能够控制并利用这些变化,来保证客户的竞争优势。(AM)
>对于如何更好地提高效率,团队要定期反思,然后根据总结出的经验,对团队行为进行调整或改善。(AM)
以上原则可以归纳为两点:
知晓变化(即不确定因素)可能随时发生,面对突发的变化,要进行相应的调整,而不能继续按原计划执行。
必要时,对项目的过程和实施办法做出随机调整。
这种应对变化调整的能力,能够激发团队的竞争优势。想像一下,如果能够每周发布一款新的产品,会为团队带来什么样的机遇(而不是问题);如果能够整合性能,为客户提供个性化软件服务(并保持很低的维护成本),又会给团队带来怎样的竞争优势!
因此团队必须灵活调整,但调整的同时,也应保证项目的既定目标始终不变。此外,无论是做出调整,还是进行预估性判断,都要问下面的四个问题,来对项目的进展做出时时评估:
(1)最终的产品是否能够体现(客户/团队的)价值.
(2)产品的质量目标—可靠性和兼容性—是否达成.
(3)在可接受的限制条件下,项目进展是否令人满意.
(4)当管理、客户以及技术等发生变化时,团队能否做出有效的调整和应对.
字典上把变化(change)定义为:“带来不同,给出一个完全不同的形式或外表”;把调整(adapt)定义为:“使适于或适应某一特定的用途或情形”。由此看来,变化和调整不仅不同,而且差异很大。变化是突发的,是没有目的性的,比如字典中给出的这个解释:“发生了某件事”。而调整则恰恰相反,它意味着直奔目标而去(强调适合性)。由此可见,变化是无心而至,调整是有意为之。
调节项目中的已知和未知
哈佛商学院教授罗布·奥斯丁(Rob Austin)和同事李德文(Lee Devin)共同执笔发表了《艺术性管理》(Artful Making)一书。书中提到一个价值1.25亿美元的IT项目最终失败的案例。失败的原因正是由于合作企业一味坚持原计划,亦步亦趋死板执行,拒绝用调整来应对突发的变化而造成的。书中写道:“"为工作制定计划,然后按照计划做事"成了让他们盲从的真言,直接导致团队采取了毁灭性的做法,带来惨重的代价。……在商界,人人都以为这种问题很少发生,可实际上却非常普遍。”
每一个项目都有其已知的条件和未知的因素,有其确定的一面以及不确定的一面,因此每一个项目都必须在计划和随机调整之间取得平衡。这种平衡是必须的,因为项目可以是生产性的,也可以是开发性的,还可以是介于两者之间的。生产性的项目不确定性很低,而开发性的项目却是高度不确定的。开发性项目强调预见性,项目执行的过程,就是朝着预见的方向探索前进的过程,而不是制定出严密周详的计划,然后严格实施的过程。也就是说,计划或调整,不能说孰对孰错,管理者应根据项目自身的具体情况、具体条件,作出最恰当的选择。