《构建之法 》800 字观后感

Posted 2020-07-10

最近看到 《构建之法》的“8.6 计划和估计”这一节，颇多感触。这些年来，不同的阶段，对项目计划都有不同的认识和掌握。

提到了制定计划的几个概念：目标、估计和决心。

目标：表明一个希望达到的状态。例如，软件“五一”之前要投放市场！在建校一百周年之时把我校建成世界一流大学！不论这类目标如何重要，它们未必能够实现。
估计：以当前了解的情况和掌握的资源，要花费多少人力物力时间才能实现某事。
决心：保证在某个时间之前完成预先规定的功能和质量。例如：我们跑步前进，全民炼钢，两年超英赶美！
大二的暑假的时候，从学校BBS上接了个私活，帮人做个办公OA系统，第一次独立的去做项目，雇主给了我一个别人的办公系统，让我模仿着做一个，功能界面样式都一样，给了一个月的时间，结果就是我最后一周连续在机房熬了好多天通宵，在时间点之前赶出来了。现在回头来看，这其实只有目标和决心，而没有任何估计，如果目标再大一点，如果不是年轻的时候身体好能熬夜，是不太可能完成的。

但就算有估计，也不代表就能制定合理的计划。毕业后刚参加工作，在一个项目中，项目经理给我分配了一个比较复杂的功能，让我估计一下时间，我乐观的估计了一下，觉得三星期就能搞定，项目经理不放心，给我按一个月时间算上了，结果由于我急于在项目中应用一些不熟悉的新酷技术，沉迷于技术细节中，导致一个月时间到了还是没能按时完成，导致整体项目延误，最后项目经理挨了批评。

类似的错误我不止犯过一次，也看到很多程序员犯过类似的错误：过于沉迷技术，忽视进度，导致计划不能按期执行，所以后面我尝试作出了一些改变：

对于不熟悉不成熟的技术，尽可能不要应用到项目中，利用项目之外的时间去学习试验，验证后再应用。
将项目计划细化，不能说一个功能模块一周，争取把计划的力度细化到天，这样能及早的发现问题。
设置关键的时间点，在这个时间点的时候，需要交付一定的东西出来，这样就逼着自己不敢在某一个细节上浪费太多时间。
后来在自己开始去做项目管理的时候，在做项目计划的时候相对有了经验，其实自我管理是最难的，管理别人要相对容易得多。但即使如此，在做项目计划时也遇到很多问题。

遇到的第一个问题就是如何做团队的项目计划，以前自己给自己做计划，相对容易，但如果整个项目的计划要一起做就比较麻烦了，每个人的能力水平不一样，预估项目的乐观程度不一样，要协调起来可不容易。

最开始的时候，我尝试按照自己写代码的经验来给大家分配任务和定计划，比如说这个用户注册模块我觉得我需要三天，给张三做，张三经验不如我丰富，那么张三应该四天能搞定，给他四天时间。这样计划是很快做出来了，但是问题马上来了：

首先是准确度不高，误差比较大，每个人实际上在做的过程中都会遇到各种各样的问题，比如前面提到的让张三四天完成注册模块，可能他以前没做过，而且正好环境不熟悉，那么可能四天根本完不成。还有可能是他直接用一些现有第三方模块，一两天就完成了这个功能。
然后是当发生计划不准确的时候，项目成员会有情绪。比如注册模块让张三四天完成，结果功能比预计要复杂，导致张三加班加点才勉强完成，张三就会想，这个功能我当时就觉得四天不够，你只给四天，这不是故意为难我吗？
于是尝试做出调整，对功能模块进行划分和分工后，让团队成员自己去预估时间，在实行一段时间后，大家积极性是提高了，自己定的计划，含着泪也要按时完成，但又有新的问题：

以前计划都是项目经理一手包办，而现在需要自己去制定计划，很多人在定计划的时候才去了解项目需求，在需求不了解的情况下做出的计划不靠谱
有的人的计划过于乐观，完全没有预估到项目的复杂性，导致最后项目计划难以完成；有的人比较偷懒，定的计划总是很松散。
显然项目经理想当甩手掌柜是不现实的，所以后来在定项目计划的时候，我一般会分成以下几步：

第一步，在目标（项目需求）明确后，开始预估项目计划，这时候精确度不需要太高，精确到周为单位即可。
第二步，对项目需求和团队成员进行同步，确保项目成员充分理解项目需求，将任务分配下去后，让项目成员自行评估各自项目计划
第三步，对项目成员的计划进行一一核查，参照第一步预估的时间，对过于乐观的和过于宽松的，都要一起把计划细化，细节仔细推敲探讨，确保计划科学合理
第四步，完成最终计划，并确定几个关键里程碑，确保在里程碑的时候能交付一定的内容

这样下来，制定的计划相对要合理多了，保持进度的跟踪，尤其是里程碑时间点的把握，基本上不会有太大的问题。

但项目计划还是很容易受到外部影响的。在《构建之法》里面提到了软件项目的时间估计可以从两个方面来看：

自底向上。团队成员各自估计底层模块和单个功能（及单元测试）所需的时间，再加上集成及基本测试的时间，就是大概的开发时间。这还没有考虑各个模块之间的相互依赖性。
回溯。团队从整个项目最终交付之日往回倒推。
很不幸，我见过的绝大多数项目都是采用的回溯法来制定计划的，比如客户说，这个功能我下个月必须上线；比如就算你按照自底向上制定好的2个月项目计划汇报给老板说，老板说2个月太长了，希望1个月就能看到。

这个问题其实在软件工程中是个非常典型的问题，有的比较滑头的项目经理会在上报给老板的进度加个比较大的Buffer，例如本来两个月可以做完的，报上去是三个月，那么老板压一压，还有两个月时间，这不是皆大欢喜了！不过这毕竟只是“术”，玩多了被揭穿了以后就没得玩了。

那么什么是“道”呢？在构建之法中有一张“功能/资源/时间的平衡图”，非常形象的说明了这几个项目要素的关系。

项目管理也是一种平衡之道，现在在资源不变，时间缩短的情况下，要么去牺牲功能，要么去牺牲质量。一般在这种情况下，如果不是一次性产品，我通常会选择牺牲功能，质量上欠的债终究是要加倍还的，功能可以通过版本的迭代来完善。

除了被缩短时间导致计划更改，还有个计划更改的重要因素是来自需求的变更！据说因为需求老变，产品经理或老板被程序员砍的例子不少！其实需求的变更在软件项目开发里面是常态，没必要太过抵触，但是需要科学的去管理。一般来讲，如果项目的周期越长，需求变更带来的影响越大！所以现在一般互联网的项目，都比较追求功能精简，快速上线，上线后持续迭代。

在遇到一些影响项目计划的问题时，我一般处理原则如下：

对于需要缩短计划时间的，根据情况减少一些功能或牺牲质量，并承担相应的后果
对于需求变更的，评估是否对整体进度有较大影响：
如果影响不大，则不改变整体项目计划，只做局部调整
如果影响较大，则对重新制定整体项目计划，走相应的需求变更流程
同时，为了能及时相应需求的变更，需要对每一期项目功能进行合理筛选，合理搭配核心功能和外围功能，让项目周期在一个相对可控范围。

项目计划是项目管理中非常重要的一环，不计划无管理。不同的项目不同的团队，项目计划的方式也各有不同，不过万变不离其宗，根本还是在于对软件工程构建之法的掌握和运用。