挨踢项目求生法则——计划篇，计划赶不上变化！
摘要：
计划赶不上变化，计划还要不要写呢？项目工期限死，估算有什么价值呢？只有项目经理紧张项目，其他人是打工心态，怎样办呢？PMP的知识能搭救项目吗？如何才能做出一个按期交付的完美计划呢？所有问题，将在这一篇中大爆发！
说明：
这是“挨踢项目求生法则”系列文章，之前已经为大家分享了战略篇、团队建设篇、需求篇、设计篇、编码篇、测试篇、实施篇，这篇是计划篇。
什么叫挨踢项目？
IT项目，特别是软件开发项目，都属于“挨踢”项目的范畴。挨踢项目的几大特点：
1.需求不确定。
2.技术不确定。
3.工期限死。
4.预算限死
两大不确定和两大限死，你想不“挨踢”都难！
什么是项目计划？
实际工作中计划应该在前面就写了，为什么本系列文章直到第8篇才写计划这个主题呢？
计划其实就是为了实现项目的目标，对项目各项工作的统筹安排。
那什么是项目的“各项工作”呢？
各项工作包括团队建设、项目分析、需求分析与管理、软件设计、编码、测试、实施等，本系列前面的文章逐一分享了”各项工作“（当然项目的”各项工作“不止这些，后文会补充说明）。各项工作的最佳实践，将会直接决定计划的质量。为什么在第8篇才分享“计划”这个主题，原因也是如此。
计划对加速工期有多大帮助？
有朋友问了一个计划应该如何写的问题。这位朋友已经有几年的软件研发一线工作经验，项目经理的工作也不是第一天干的，问出这样的问题我觉得有点怪。但我仍然说了一通项目计划的“大道理”供他参考。然后他说：项目成员技能不足，计划怎样写？
后来我才发现，他的真正问题是：如何写好计划以保证工期！
我给出的回答竟然是：计划本身对加速工期并没有帮助！
要加速项目工期，主要在于两方面：
1）提升需求分析与管理能力，能为客户带来价值的前提下，尽量将需求控制在一定范围内并尽量简单。
2）提升软件的设计能力，让项目的整体工作量下降。
如果项目小组能力不足，并且不重视上述两个方面，那么这个计划怎样写都是写不好的，写计划不是纸上谈兵啊。
而通常情况我们的工期是限死的，所以我们的计划是“倒推法”写出来的，计划中的关键节点基本上通过倒推法已经卡死，我们能做的事情就是想办法让事情变得更简单、工作量更少和提升我们的能力，以便在工期内完成项目！
所以计划及计划跟踪的问题，并不是仅仅本篇就能解决的，你还需要再认真看看前面的几篇文章，理解项目的”各项工作“是做好计划的根本。
法则1：项目管理首先是一门技术活
作为新上任的项目经理，如何写计划指导大家工作呢？
首先请做这两条自测题：
1）你熟悉这个项目需求吗？
2）你熟悉这个项目需要用到的开发语言、数据库和相关技术吗？
如果上述两条题目的回答都是NO，你是无法开展工作的。
软件项目管理首先是一门技术活，如果你不懂需求、不懂技术，你将会：
1）无法拆解工作；
2）无法和项目组成员沟通；
3）无法与客户沟通。
当然大部分项目经理是技术出身的，这方面的问题就不太严重；但有些项目经理是“外行”出身的，如果又不愿意去学习需求和技术，那么只能说祝你好运了……
法则2：项目经理需要周身刀并且每把刀都要锋利
中国的项目经理，通常要干以下事情：
1）项目管理（这个不用说了，废话）；
2）需求分析与管理；
3）软件设计，包括数据库设计；
4）写代码；
5）测试软件；
6）和客户沟通；
……
或者这样说会更合适一点，项目经理不干的事情有哪些？结果你发现：没有！
项目经理必须是全才，而且各方面能力都需要数一数二！
当然你会说：你当我是齐天大圣啊，可以三头六臂地干活！
以下一些实用建议供你参考：
1）有机会要尽量每方面都学习一下锻炼一下，项目经理确实是需要全才；
2）如果项目规模不大，那么你一个人兼任”管理+需求+设计”是可以的；
3）如果项目规模比较大，你可以兼任“管理+需求”或“管理+设计”；
4）哪怕项目规划超级大，不建议你干“纯管理”的事情，你至少要兼任“管理+需求”。“纯管理”其实是干不了事情的，还需要其他人“服侍”你，你才能“纯管理”。
法则3：积极提升项目成员水平
我做过这么多项目，没有试过项目小组从一开始具备了完成这个项目所需要的全部能力，这种情况估计以后也不会发生。提升项目成员的能力和水平，是按期交付的重要因素，甚至是决定性因素。
员工离职的两个重要因素，一个是薪金，另外一个就是学不到东西。项目经理可能还无法直接提升项目成员的薪金，但你可以创造学习机会和环境，甚至是亲自传授知识给项目成员，让他可以学到提升薪金的技能。如果你的下属离职了，原因是一直学不到东西，那么你们两个可以抱头痛哭了！
法则4：应对变化的最好办法就是计划
计划赶不上变化，所以计划写了也没有用！果然如此吗？
你可能觉得软件项目“两大限死两不确定”很恐怖，其实有更恐怖的项目呢，那就是战争指挥！
打仗要不要写作战计划？战争中信息千变万化，你会因为这样而不准备作战计划吗？情况越复杂，不确定因素越多，其实越需要计划！
法则5：估不准总比不估算要好！
估算很恐怖，很多人不愿意估算，主要原因有：
1）“两大限死“，估了等于没估；
2）“两不确定”直接导致无法估算；
3）估算就是一种承诺，我可不愿意自己限死自己啊。
其实在我们软件开发届，估算偏差达到100%是很常见的事情，甚至是200-300%都很正常，但如果不估算，你的误差就是无穷大！
勇敢的跨出第一步，估不准总比不估算要好，估算和实际工作量之间总会有个谱，只要跨出第一步，我们就有改进基础了！
法则6：计划需要近期细，中长期粗，并持续细化和优化
曾经负责某项目，项目工期3个月，领导要求我写出3个月的详细计划。我很郁闷，死活写不出来，我不想纸上谈兵、不想浪费时间写这些没有用的计划，所以我还去和领导理论这样的做法是不合理的。软件项目存在这么多不确定因素，一般来说几周后的具体工作是很难计划出来的，所以法则6很重要。计划并不是僵化的东西，需要持续细化和优化。
其实比较怕遇到外行的领导，外行领导监督工作的办法就是让你写计划，然后根据你的计划来检查你，而这个计划的工期是卡死的。如果有人用这个你无奈而写的计划来卡死你，你肯定不愿意写这样的计划。
开明的领导是这样做的：
1）计划写出来了，我会全力支持你完成计划，包括：提供各种资源、协调各部门、协调客户等等；
2）计划可以变，可以推迟，但你要尽早告诉我；
3）我不会用计划作为你工作成绩的检查标准，也不会以此来绩效考核。
法则7：人人都是项目管理者
很多项目经理都有这样的感触：好像整个项目小组当中，就只有自己最紧张项目的成败，其他人的心态就是完成工作的打工心态。其他人似乎从来不会主动汇报工作，主动思考项目的风险与问题等。
项目管理是每一个人的事情，而不仅仅是项目经理的事情，每一个人至少需要做到：
1）全力完成工作，要保证工作质量；
2）要主动报告进度，遇到风险和问题要主动提出来；
3）要主动管理好自己的工作产品；（做好自己工作产品的配置管理）
4）要主动协助同事完成工作；
5）要主动沟通。
每一个人至少要做到能管理好自己的工作，如果自己的工作还需要别人来管理，这样的工作水平是不及格的！
法则8：计划的执行在于每一天！
我们都知道以下大道理：
1）项目的问题都是通过一天天积累的；
2）问题越早发现，解决成本越低。
但我们往往在计划跟踪上节省时间，结果得不偿失，在临近项目死期（发布日），进入正式测试阶段时问题大爆发：
1）某些需求没有实现；
2）某些缺陷无法改，需要改动数据库底层或软件架构才能搞定；
3）软件整体的用户体验很差，但这些问题已经遍地都是了，没有时间去改；
4）一大堆不符合编码规范的代码；
……
每天的计划跟踪能解决上述问题，并且能加速项目成员的能力提升。
跟踪计划的最有效方法是眼见为实，就是直接编译程序看看运行效果，同时检查代码与数据库实现。
法则9：通用项目管理知识的对项目的帮助不大
我在大学时曾经学过“施工进度管理”的课程（我大学学的专业是城镇建设），当时学了很多项目管理的知识，例如：前置任务后置任务、关键路径、单代号网络图、双代号网络图、甘特图、流水施工等等概念，开阔了很大的眼界，发现项目管理确实是一门高深的学问。后来我的课程设计就是要写一个施工进度计划，我纸上谈兵地完成了这个课程设计，结果我感觉良好，以为自己就是项目管理大牛了！
幸好我舅父给我泼了冷水，让我浮躁的心安静下来。当时舅父带我到某建筑工地见识一下，我见到工地的办公室中有一张很大的甘提图（进度计划），我问这个图有用吗？我舅父说：这个图只是摆出来应付检查的！
从事软件研发工作后，尽管我学过一些项目管理知识，但确实发现这些知识对项目管理基本上没有实质性的帮助。刚学习时，你确实会有“哇呀”这样的感觉，项目管理居然可以这样！实际上如果你没有丰厚的一线研发工作经验，软件项目管理是做不好的。
关于通用项目管理知识的学习建议：
1）公司报销或者你是土豪，并且你有很多空余时间，建议去考一考PMP，这个过程还是学到一些知识的；
2）没有银两，但你有很多时间，可以去自学一下，考证就不是必须的了；
3）这些通用的项目管理知识不要硬套到软件项目上。
还有会有SQA篇、SCM篇和维护篇
之前刚写完“实施篇”的时候，有朋友问什么时候写“SQA篇”？
确实我原来没有计划写“SQA篇”，“计划篇”就是最后一篇。
但计划赶不上变化，计划是可以调整的！我打算将来再为大家分享SQA篇、SCM篇和维护篇。
你有任何想法和建议，欢迎提出来！
如果本文对你有帮助，麻烦点一下“推荐”啦，谢谢！
作者：张传波
创新工场创业课堂（敏捷课程）讲师
软件研发管理资深顾问
CMMI首席专家
《火球——UML大战需求分析》作者
软件知识原创基地创办人
