相反，如果把客户价值和质量作为最终目标，那么计划就成了实现这些目标的手段，而非目标本身。计划设定的条条框框依然重要，依然指导着项目的执行，但是我们也应该清楚，计划并非圣旨那样尊不可违，而是具有一定的灵活性的；计划应该成为行动的指南，而不是紧箍咒。
传统的项目负责人也罢，敏捷的项目负责人也罢，都会制定计划，而且会为之投入相当的时间。但是他们对待计划的态度截然不同。虽然他们都把计划当作底线，但是传统的项目负责人会按照这个底线，时不时对实际的结果试图“纠正”。在敏捷项目管理中，我们采用“调整性行为”来说明应该采纳的一些正确做法(其中之一便有可能是纠正计划本身)。
在关于敏捷处理原则的文件中——包括敏捷宣言(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项目最终失败的案例。失败的原因正是由于合作企业一味坚持原计划，亦步亦趋死板执行，拒绝用调整来应对突发的变化而造成的。书中写道：“‘为工作制定计划，然后按照计划做事’成了让他们盲从的真言，直接导致团队采取了毁灭性的做法，带来惨重的代价。…… 在商界，人人都以为这种问题很少发生，可实际上却非常普遍。”
每一个项目都有其已知的条件和未知的因素，有其确定的一面以及不确定的一面，因此每一个项目都必须在计划和随机调整之间取得平衡。这种平衡是必须的，因为项目可以是生产性的，也可以是开发性的，还可以是介于两者之间的。生产性的项目不确定性很低，而开发性的项目却是高度不确定的。开发性项目强调预见性，项目执行的过程，就是朝着预见的方向探索前进的过程，而不是制定出严密周详的计划，然后严格实施的过程。也就是说，计划或调整，不能说孰对孰错，管理者应根据项目自身的具体情况、具体条件，作出最恰当的选择。
影响选择的另一个因素是试点成本，即做实验的成本问题。尽管对创新非常渴求，但如果试点成本过高，也会限制管理者，从而加大对项目进行预估性判断。而如果像之前提到的，试点工作成本较低的话，就有利于管理者作出随机调整的管理选择。这样一来，项目的计划、构架和设计等，就随着产品的开发进度，同步前进，同时变化。
随机调整的幅度取决于三点：产品、步骤和人。首先团队成员应该团结敏捷，面对变化应该持有正确的态度。其次，采取的项目步骤和实施办法，要有利于团队在遇到突发变化时进行随机调整。最后还要有能够进行自动测试的高品质产品编程。你当然可以用陈旧的产品编程，也可以选择不敏捷的团队，但这样一来想要调整就非常困难。因此，如果团队想做到敏捷和随机应变，以上三点缺一不可。
驾驭风险，抓住机遇
人们不想采取敏捷的做法时，往往会找各种借口、理由，甚至抱怨：“这样做太费时间了”，或者“这样做成本太高”等等。所以无论是短期试点，更新数据，随时整合，自动检测，还是其他的各种变通性做法，总是会遇到这样的托辞。更有甚者，很多公司简直像是患上了“新玩意”痴迷症——把所有的精力重心都放在开发新的东西上，而忽略了整合企业的传统编码程序。这样以来，传统编程变得散乱不堪，也成了管理者们拒绝做出调整的借口，甚至障碍。有的调整的确是成本高昂，而大多数调整，根本没有人们嘴上说的那么可怕，那么难。经验丰富的敏捷管理大师们，会把这些困难和障碍变为机会。他们会这样想：“如果真的这样做了，会带来什么好处？”
数年前，我们曾与一家大企业合作，在一个很大的、超过500人的超大型项目团队里工作 (多个项目，下辖在同一个整合式产品套装之内)。当时我们要求对方在做完每一组试点后，必须进行完整的跨项目的编程整合。但对方却说：“我们办不到，这需要很多人手，而且要占用好几周时间，太影响项目进展。”原来这个团队以前习惯于临近产品发布环节才进行编程整合，所以之前他们的产品，老是在临发布前出现严重的问题。于是我们这样问他们，“要是编程整合没有你说的那么浪费时间、浪费成本的话，会给我们带来什么好处？”并且我们告诉他们说，“你们别无选择。要想为自己赢得敏捷便捷的余地，就必须尽早而且要经常对全套产品的编程进行整合。”
他们虽然极不情愿，但仍然第一次认认真真的对产品进行了全面整合，结果发现用的时间远远少于预期。经过三、四轮的全面整合之后，他们也有了经验，可以在三两天内、用很少的人手，就完成全套产品的整合。这种时时整合的做法非常重要，帮他们的团队提前发现并解决了很多问题；而在以前，这些问题都往往是积压到产品发布之前，才集中暴露出来的。
多数情况下，虽不尽然，找种种借口拒绝调整，往往会直接导致效率低下，因为它让企业失去了精简流程、提高随机应对的机会。培养团队的敏捷性，必须进行小型的试点；而小型试点的目的就是找到方法，让重复的工作环节能够低成本地快速完成。而快速且低成本的工作习惯，又能促使团队面对变化，另辟蹊径。快速低成本的解决办法，还能够鼓励团队勇于创新，从而锻炼团队的创新精神。而这种创新又会影响到企业的其他部门，产生涟漪效应。这样一来，降低成本应对变化，就会促使企业重新思考它的商业模式。
采取可靠的——而不是可重复的——步骤
必须指出“可重复的”并不意味着敏捷。虽然实施可重复的步骤，已经成为许多企业的管理目标，但在产品开发的过程中，追求可重复的目标却不仅是错误的，而且会极大的遏制产品的开发。可重复意味着用同样的方式，做同样的事情，产出同样的结果。而可靠性却指的是无论遇到什么困难障碍都要实现既定的目标——也就意味着不断的作出调整，应对各种变化，实现定好的目标。
可重复的步骤，通过制定标准和对流程的不断改进，来减少产品的质量变化。这是一个源于制造业的词。因为在生产制造中，产出什么样的产品，是已经定义好的。那么可重复性就意味在生产过程中，只要连续输入，就可以产出预期的结果。可以重复意味着从输入到产出的转换过程是可以复制的，而无需任何变化。它还意味着生产的过程不会有任何新情况发生，因为所有信息都全部预先知道，来保证最终的精准产出。但是，可重复的步骤在产品开发中毫无用处，因为首先很难精准地判断出最终的结果；其次项目不同，项目的投入也大不相同；第三，开发不同产品，从输入到产出的转换过程本身更是大相径庭。
可靠的步骤过程关注的是产出，而不是投入。哪怕是投入完全不同，通过采取可靠的步骤，项目成员也能够想出各种办法，不断向既定的目标靠拢。也正因为投入的差异，他们决不会把一个项目所采用的步骤或做法，亦或是试点，复制到另一个项目中。可靠性是受结果驱动的；而可复制性是受输入驱动的。如果把项目的步骤固定下来，那么项目本身就会因为投入和转化的巨大差异，而变得极其危险。即便是那些声称采用了固定步骤且获得成功的企业，他们的成功并非来固定的、可重复的过程本身，而是来自企业员工在实施这些步骤时，进行的敏捷调整。
此外，这里面还有一个项目规模问题。在生产型项目中，尤其是那些适合采用重复性步骤的生产型项目，既定的生产要求就是项目的规模范围。但是在产品开发时，生产要求会随着项目的周期发生更改，因此根本无法在一开始时就准确界定一个项目规模。
因此，对于开发产品这种本身就比较敏捷的项目，要想准确估计项目的规模，不能只看生产要求，而要看项目的远景规划—即可以发布的产品。产品经理们也许会拿不准具体的要求，但行政主管们会对产品进行整体考虑—那就是最终产品能不能够满足客户的期许？所以再次听到这个耳能详熟的问题 “项目是不是达到了既定的规模、方案和成本目标？”我应该首先对项目的远景规划、价值和整体的表现能力进行衡量，然后再做出回答。也就是说，对成功的衡量，可以包含在这个问题中：“有没有做出可以发布的成熟产品？”而不是看项目的种种计划指标是否都已经达成。
敏捷项目管理（APM)既是可靠的，又是可预测的：这样的项目过程，由于考虑到了各种不确定性因素，因而在规定的时限内开发出的产品，最能满足客户不断变化的各种需求。这一点是其他任何一种管理方式都无法比拟的。而之所以能够这样，不是因为项目经理制定出了极其周详的任务计划，也不是对这个计划实施了精微细致的管理，而是因为敏捷的项目管理者，营造了一个这样的工作环境和氛围：人人追求卓越，并愿意为实现目标而努力。
敏捷管理虽然是可靠的，但也并非是无往而不胜的，因为它并不能消除所有的不确定性，也无法避免全部的意外。但是，这样的管理方式能够设法转化这些意外和不确定性，使项目最终走向成功。如果一个企业既想在框定的时间和成本限制内从事产品规划开发，还要保证从不失败，那么他只能去经营生产型的装配线，而不要去从事产品开发。
培养随机调整的技巧
随机调整需要有沉着的头脑和相应的技巧。要做到随机调整，我们必须认真、客观地评估自己的个人表现和集体表现。成功的项目团队，要在以下四个关键方面做好评估和反思：产品评估：从客户的角度和技术质量的角度同时对产品进行评估；步骤评估：看团队采用的步骤和做法是否高效；团队评估：看团队成员之间的整体合作是否协调、是否高效；项目评估：项目进展是否按照计划顺利进行。每一次试点结束，及每一个项目结束，只要对以上四个方面进行全面反思，就一定能总结出一套随机调整的策略办法，提高工作效率。
实际上，人们做什么，如何做，才是产出优秀产品的保障。原则和实践就是我们的指南，帮助我们甄别并强化各种能够提高效率的行为。
原则为敏捷的团队提供了做事指南，但要想顺利完成工作，具体的实施做法也必不可少。步骤流程和细致的做法，为团队的自律提供了最基本而又灵活的框架。而在敏捷的项目团队，一定是既有预估判断性的流程和做法，也有随机调整性的流程和做法。
开发伟大的产品需要进行探索，而不是按照计划按图索骥。不断探索和不断调整，恰恰是创新行为的两大特征——既有探索未知的勇气，又有知错必改、因地制宜的谦逊。
浙公网安备 33010802003509号
