制定日常计划时的三个建议（如何制定靠谱可执行的计划）

软件开发人员常常不喜欢制定开发计划，因为担心计划不准确，一旦承诺了不能按时完成任务会被领导死磕。有人认为计划只对领导有用。有人认为计划赶不上变化，那要计划还有何意义？

的确，制定有效项目计划是项目经理的一项重要职责。但是，计划对项目和团队的重要性不言而喻，即算一个烂计划也比没有计划好。一个项目一定有项目目标，有起始和结束时间，有一个要完成项目目标的团队。计划就为团队以怎样的进度达成目标提供了依据，是项目管理的重要手段。

项目计划依目的不同而有不同的展现形式。比如项目路线图，只列出大的关键里程碑和交付物（转测时间点，版本发布时间等）。这个方便给领导或客户汇报使用。团队内部日常管理跟踪得有更详细的计划。计划主要反应：谁什么时间做什么事，什么时候完成，交付物是什么。而且，更重要的是通过制定计划本身，可以促使团队分析思考要达成目标所必须要完成的事情（任务），分析其中的风险或上下游、内外部依赖，以提前做好应对措施，管理风险。

如果计划不切实际不可行，那是没有用的。笔者之前碰到有人鱼和熊掌想兼得，导致计划不可落地，两个重要目的都没达成，鱼和熊掌一个也没抓到。

为了让项目计划能落地可执行，一般采用渐进明晰、远粗近细的方法。对远期的只有高层的粗略计划，对近期的制定详细计划（比如：一个月内的或两星期内的任务）。

如何制定有效计划？

1. 分解 制定计划中一个重要步骤是评估，评估完成某一件事需要花费的人力/时间。这个评估的准确度直接影响了你的计划是否靠谱，是否可执行。对任何复杂任务，如果没有相同或类似经验常常难以准确评估。对此，一个有效方法是分解。将目标分解成一个一个小的任务，再对小任务评估。分解成多小才算合适？一般估计工作量在半天到一天内能完成就可以，最长不要超过两天。最好用小时来度量，最长不超过16小时。
2. 记录实际时间 评估很难百分之百准确，为了度量预估时间与实际时间之间的偏差，自然需要记录完成每个任务的实际用时。然后按周或双周或月度分析总结差异所在，尤其是相差很大的根本原因是什么。是碰到预料外的技术难题或者被意外事情打断进展，又或是要解决新发现的重要bug。如此在团队内持续运行一段时间，比如一个月或三个月，建立起团队效能数据库，作为后续评估参考的重要历史数据。

关于制定计划的一些要点

1. 应该让完成具体任务的程序员给出评估时间 任何想当然的由领导拍脑袋给出的评估时间常常会失败。华为任总有句话是：让听到炮火声音的人做决定，就是要尊重一线人员的专业能力。在软件项目中也应该这样。有人肯定担心喜欢划水的程序员会给自己的评估很多水分。这个有很多方法可以解决。你可以用德尔菲法，找三个不同的程序员对同一任务分别给出评估，记录下来。首先要信任团队，如果成员划水你也应该很快发现。可以直接面谈沟通。如后续仍有此情况，你可以直接砍掉水分，或者降低其绩效记录，甚至最后直接移出你的团队。
2. 将解决Bug的时间也计入你的任务实际完成时间 因为你任务的完成意味着是已测试的代码，交付可工作的软件，而不是一堆bug的代码。有些人为了号称自己是敏捷交付快速响应，一周发布多次版本，结果两天写完的代码需要三天甚至一周时间来改bug，完全是本末倒置。
3. 经理们尽量不要压缩开发人员的评估时间 这个前提是你的团队已经磨合成熟，团队成员诚实地给出合理的评估。领导和项目经理常常喜欢压缩开发人员的时间。主要原因是在商务谈判时常常给客户过度乐观地承诺，承诺3个月可以完成的产品，实际可能需要12个月。这样项目实际开始时，客户肯定会不高兴，经理们为了让客户高兴就常常压缩开发人员的时间。
4. 计划表像木盒 如果你有一堆小木盒想装入一个大木盒却装不下，你只有两个选择：要么找一个更大的木盒，要么扔掉一些小木盒。比如就你要在六个月内发布版本，但要12月才能完成所有开发。你要么延期，重新规划交付计划；要么砍掉一些不重要的需求。当然你也可以考虑加人和加班。加班对短期冲刺更有效，对长期的效率和质量都没有保证。加人也有边际效益，因为新人的加入需要培训，也会影响已有成员的效率，亦会增加沟通成本和管理成本。

当然，计划未必是一成不变的，根据项目实际情况需要持续监控管理或调整，在与相关干系人（客户、领导）达成一致后可以修订并签字后成为新的基线。

总之，切实可行的时间计划表是创建优秀软件的关键。 它迫使您首先开发最重要功能，并允许您对构建内容做出正确的决定。 这样可以使您的产品更好，老板更快乐，使客户满意，最重要的是更大可能让你团队按时下班回家。（这个对习惯于996的“码农”来说几乎成了痴人说梦）