项目管理艺术 2.5-2.6 第二章 大结局(转自moneyice)

2.5 计划起作用的必要条件
既然明白了计划难以维持的原因，那么我就给出对任何项目计划来说能够最小化风险，最大化收益的建议。这些方法和行为贯穿了那些反映计划真实本质的惯例角色和背景。因为计划表现的是项目的整体性，唯一有效的使用计划的方法就是认识到那些促使项目成功的一切必要条件。这是一件交叉领域任务，不仅局限于工程或管理活动。
l 里程碑长度要适应项目的可变性。预期的变化越多，里程碑就应该越短。小的里程碑使项目有了从容的中场调整时间。这样，管理上每次检视的间隔就更短，也就降低了做变化的风险。在里程碑交叉的时候，团队可以预习一下对变化的期望，这样他们就可以期望变化，而不是抵制变化。
l 对愿景保持乐观，对计划保持怀疑。对
于做计划来说，一个主要的心理上的挑战就是要使用正确的怀疑论，而不要压抑了团队的激情和冲劲。创建愿景文档的时候，热情和乐观是一定要有的，但是计划不
同，计划的制定要正好相反。那些写下来用来评估事情要做多长时间的数字需要严格遵守摩菲法则（“能出问题的地方一定会出问题”）。计划不能反映出那些在理
想条件下可能发生或能够发生的事情。相反，尽管许多重要的地方没有被预期到,一份好的计划还是会断言将要发生的事。在做计划的时候，有测试和QA团队的参
与也很重要，因为他们都好怀疑，而且总是以批评的眼光看待工程工作的。
l 在设计上押宝。设
计的过程是最好的避免无知和意外挑战的保证。更多的的设计练习是提升团队对实现过程和其他阶段认知的唯一手段。设计技能和实现技能是不同的，最强最快的编
码人员不一定是最好的设计和问题解决人员。出色的设计过程在计算机科学课程中是学不到的，不管这些课程涉及的内容多么的精辟，多么接近于工程项目。第5章
和第6章将详细讨论这一主题。
l 设立计划检查点来添加或削减讨论。计
划应该包含短暂的检视周期，这样负责人可以检视当前的进度，理解新的信息或者用户反馈。这一点应该被列入主要任务计划中，并清楚的在合同中注明。在这些检
视活动中，已经存在的工作项目和特性可以被削减，新的也可以被添加进来，这些都依据领导层对当前情况的分析而定。普通的检视点是两个阶段之间，或者基于某
些限定要素，在每一次设计和实现阶段结束后。但是如果在计划和实际之间有严重的利害关系或者显而易见的矛盾，检视随时可以进行。讨论的目的是应该是保证项
目健全，更新计划，排列工作项的优先次序，清楚计划的下一部分，对随后的工作充满信心（见14章，15章）。
l 告知团队计划的哲学观。不管使用什么方法或技巧，这都应该是整个团队的共同知识。如果每一个程序员或测试员都对怎样预定计划工作有一定的基本理解，当有特别策略的项目管理方式被应用在当前项目上时，他们就能够提出很多问题，而且差不多能理解所进行的规划。
l 使用问题间距度量团队经验。团
队对于要解决的问题的经验值是计划中的一个魔法变量。如果团队要构建一个数据库驱动的网站，一个六个程序员中，有五个以前做过了好几个类似的项目，所以就
很容易设想他们在设计和估计工作方面要比没有从事过此工作的团队强。这一点应该作为规划计划冒险或保守程度的一个重要因素。
l 度量团队的信心和团队合作经验。即
使评估来自于个别的程序员，但是程序员们是最为一个整体来完成工作内容的。一个全是高手程序员的团队如果以前没有在一起工作过（或者一起面临过挑战），就
不一定像预期的那样高效。如果一个新组成的团队要做一个大型的，有风险的项目，或者要负责一个很冒险的计划，这是很危险的行为。
l 提早发现风险。如果你知道萨利要负责最困难的模块，在计划前面就要处理了这些问题。风险越大，你就希望得到更多的时间来解决它。如果你直到计划晚期才从事风险方面的工作，你就不会有很大的自由度来响应它们。政治的，组织的，以及资源相关的风险都是这样。我们将在第14章讨论工作项管理。

2.6 总结
l 计划提供三个功能，斟酌要做出的承诺，让每个人都看到他的工作是在为整体作贡献，能够跟踪进程状况。即使计划出问题了，它还是有其价值的。
l 大的计划应该被划分为小计划，以降低风险，增加进行项目调整的频率。
l 所有的评估都是或然性。因为计划是一组评估，评估就有一定的可能性。这一点和计划的正确性有关，因为概率乘积的关系（80% x 80% = 64%）
l 评估做的越早，正确性就越低。但粗略的评估仍然是下一个更好的评估的唯一起点。
l 做计划的时候要充满怀疑，而不要太乐观。在设计过程中认知假设，从而得到可靠的自信心。