计划是如何做出来的？
一、要站在战略的高度。
有时候我会问项目经理这样的问题：
1、项目预算是多少？（注意前文提到的预算与估算的差别哦，预算是指公司打算花多少钱做这个项目。）
2、合同要求在什么时候验收？
3、验收一次进行还是分初验、终验？
有些项目经理答不出了，他们没有去关注合同中的要点，也没有向高层取得项目的战略指示。
一般情况下，在项目初期，你应该搞清楚这些战略层面的内容：
1、合同价钱是多少，公司打算赚多少钱？
2、公司为什么要做这个项目？想赚钱？想维持客户关系？想积累业务和技术？本项目是公司战略的其中一步？
3、项目的工期要求。
4、项目的验收办法、验收标准。
5、项目是如何收款的，客户每次的付款条件是什么？
你可以通过看合同，向公司高层请示，了解到这些关键信息。当然很多公司合同是保密的，你可能无法直接看到合同，但你可以直接问高层领导嘛，尽量获取上述关键信息。做项目就像打仗，秦国名将白起没有一次败仗，主要是因为他每次打仗之前，都会处在战略高度来审视国与国之间的大势。你要做好项目，先要把握项目的大势！
二、明确计划的“输入”。
要做好计划，你还需要了解清楚以下内容：
1、系统的需求。通常需求是不明确的，能明确多少算多少，同时你需要有计划地去搞清楚。
2、系统的设计。通常设计也是不明确的，你需要安排很多前期技术研究。
3、项目组当前的能力情况。
4、为成功完成项目，项目组还需提升哪些知识和技能。
以上这些内容，是项目计划的“输入”，良好的输入是优质计划的基本保证。
三、用估算来控制计划，由计划来调整估算。
估算如果做得好，其实计划就完成大部分了，你需要利用估算来指导计划。为了说明“估算指导计划”，下面我会虚拟一个例子。
某项目估计完工需要1000人日的工作量，其估算明细如下：
1、项目管理150人日。
2、需求150人日。
3、设计150人日。
4、编码250人日
5、测试100人日。
6、实施200人日。
根据估算，你安排了详细的进度计划，进度计划中的各任务可以分为六类：项目管理、需求、设计、编码、测试、实施。请注意每一类工作量的总和，不能超过对应的估算，你需要用各子估算来控制这六类子任务。
不少项目在安排具体进度计划时，忘记做这个检查，有时候进度计划的总工时没有超出预算，但可能编码方面的任务已经超出了编码的预算了。
在具体计划时，往往会发现估算时遗漏考虑的内容，这时很有可能实际计划的总工时会超出估算，或者是某类别的工时超出相应的子估算。这是很正常的事情，项目组对项目的认识是逐步深入的，不太可能在估算时就100%考虑周到。遇到这样的情况，我们通常这样处理：如果仅是某类别工时超出相应的子估算，如果能从别的子估算挪一点过来“补数”，而总估算不受影响，则不需要申请估算调整；但如果总估算受到影响，则需要申请变更估算。
前文讲述估算时提到，会因为需求不能全部明确、设计也不能全部明确，估算往往不能一次完成，这时只需要估算能估算的部分就可以了。但我们需要随着项目的开展，认识的加深，持续更新估算。估算与计划的关系是：估算指导计划，计划反过来促进估算更新。
四、制定可执行可检查的进度计划。
具体工作任务的制定是很讲技巧的，如何做到“可执行可检查”是关键，下面是制定进度计划的一些技巧：
1、每个任务的时长不要超过5天。
我们公司的项目，任务时长往往是在两三天内。
2、任务只有完成与未完成两种状态。
所谓任务完成90%之类的说法是不靠谱，任务应该足够细分，不要安排周期长的任务，这样能更好控制项目进展。
3、每个任务都有可供检查的工作产物。
不要笼统安排“研究什么什么技术点”之类的任务，必须明确工作产物，如：研究某某技术点，编写研究报告，提交演示程序。而任务完成标准就是：这些工作产物能达到期望的要求。
4、一个任务一个人负责。
一般不要安排类似“小甲与小乙共同完成某设计文档”之类的工作，多人同时负责一个事情，效率会很低，效果也不太好。
尽管实际工作中有可能需要多人同时做一个事情，你可以：
1）再次将任务分解，落实到具体的人头上，如上述任务可以分解为两个任务：小甲完成设计文档的章节1、2、3，小乙完成章节4、5、6。
2）如果任务实在不好再分解，就只安排一个人去做。
在我们公司，一般只有评审任务是多人参与的，别的任务都会落实到具体的人头上。
五、细化近期计划，定下远期计划大节点。
我曾经负责一个房地产公司的成本管理系统，当时需求还没有全部明确、技术也很不成熟，就被要求做出该项目的全部详细计划。我当时很郁闷，一个月后某一天谁干什么的事情也要计划出来吗？我只能明确近期一两周的具体工作，而远期的工作我只能定出大概，以后的事情可变因素太多，现在写出所谓具体工作，其实是毫无价值的，浪费时间。
近期两周内的工作能明确的工作，必须按照上述第四点的要求制定详细的明确的可执行的可检查的任务，而对于将来的工作，则需要定出关键节点，如什么时候发布什么版本，什么时候验收。
六、让项目组各成员详细计划自己的工作。
在项目经理主持下，项目组全体共同来制定进度计划框架，明确任务的先后关系。而对于每个人的具体任务，则可以在项目经理的指导下，由每个人自己来确定。
项目组由项目管理、需求、设计、编码、测试、实施等各专业人才组成，每个人承担起自己专业方面的管理工作，项目管理其实是项目组成员每个人的事情，不是只由项目经理一个人来负责。
七、持续更新计划。
计划不是死的，是活的！项目计划不是一次成型就固定不变的，项目组需要持续更新计划细化计划，要随时保证近期的任务都已经明确，而远期的任务如果能明确也应当尽量明确。任何项目组成员都可以发起计划更新，项目经理要推动大家管理好自己工作，让大家主动更新计划。
这里要谈谈计划变更问题，谈到计划变更很多人会“闻虎色变”，我们先要看看看什么叫“计划变更”？
“计划变更”要与“计划调整和细化”区别开来，调整和细化是指根据实际情况，不断的适时地去修改计划。任务微调是很经常和很正常的时间，某某任务稍微延长一天，某某任务比计划提早一天完成，某项目组成员请假等影响因素，都需要我们去调整计划。与此同时，我们应当不让去细化中远期的任务，至少要一直保证近期的任务都是明细化的。
而计划变更是指，项目关键节点受到影响的重大变化，关键节点一般有：需求规格说明书通过评审的时间点、版本发布时间点、验收时间点等。这些关键节点的变化，会影响合同条款的履行，会影响公司的战略规划。通常是因为内因或外因导致计划变更，内因一般有：遗漏重要需求、软件设计出现重大失误、代码质量不过关；而外因一般有：客户的需求变更，客户未能做好项目上线准备，第三方未能及时完成相关工作（如：硬件提供商未能及时发货）。
在我们公司，计划调整和细化只需要项目组内达成一致便可，而计划变更则需要报高层审批。
如何跟踪计划？
计划做出来不是用来看的，而是要执行计划！跟踪计划执行的难度和工作量比起做计划要高出好多倍。
计划跟踪并不是对照进度计划，按时间检查每个人的任务完成情况这么简单，下面介绍一些计划跟踪的关键要点。
1、建立便捷的项目组内沟通机制。
很多人强调加强沟通，虽然大家的意识算是加强了，但还是收不到理想效果。程序员不善沟通的特点（理科生往往是不善沟通），不是一下子能改变的。下面一些最佳实践供大家参考：
1）所有人的工作产品必须share！我们要求大家的文档要提交到项目网站，而代码满足提交条件的，每天都需要提交。工作产品不能几天都只存在自己电脑上，哪天你不上班了，大家就无法接手。
2）每天站立会议。
口头沟通是最有效的沟通办法，我在很多项目中实施了每天站立会议的做法，要求大家简要地说明工作情况及遇到的问题，需要大家提供什么支援等。每次会议，如果有决议和代办事项，我都会安排记录下来，并将会议记录公布在项目网站上。
3）有问题即反馈！
很多项目组成员喜欢遇到问题就闷头干活，不好意思问，也好像是怕被主管认为能力低。遇到问题有可能是任务本身有问题，也有可能是你的认识不到位，某些知识不具备等导致的。实际工作中遇到问题是很正常的事情，如果没有人提出问题，这反而是项目的最大问题。我强调任何人都可以提问题和大家讨论，任何人都可以发起项目会议讨论问题。问题如果不在产生时消除，将来必定会因此徒增很多项目工作量。
2、建立项目组成员的自信。
我带领过很多项目团队，很多项目组成员是新手，甚至是应届生，项目团队中新手太多是很大的挑战！在中国基本上不可能每个项目团队一开始就是最强阵容的，大部分项目团队是新老结合，中高低搭配的。我强调每个人的重要性，对于新手要给出更多的机会，更多的指导，更多的鼓励！犯错不要紧，犯错多也不要紧，只要错误不是重复的，这就是好事！只要去做事情，就有机会犯错，只要做未做过的事情，犯错机会也会更大一点，关键是总结和进步！
3、质量投资，减少返工。
项目时间紧，大家就会一头扎到编码中，想尽快弄出个东西来。“谋定而后动”“磨刀不负砍柴工”等大道理大家都懂，但事到临头还是明知故犯，结果往往是工作质量低、返工一大堆！
要培养大家零缺陷意义，零缺陷意识包括零缺陷文档、零缺陷代码、零缺陷发布。我经常和大家强调，做一个事情只有两种选择，一种就是不做，一种就是认真做好！不要搞什么60分万岁，不要应付完成，任何带有缺陷的工作，会在将来带来无穷无尽的“后患”。一步一个脚印，欲速则不达。
除了向大家灌输这种思想并要求大家这样去做，作为项目经理还需要尽早检查和指导大家的工作。比方说：我安排小甲完成某模块的设计文档，我不会等文档完成才去看，我会先要求小甲思考后找我口头说明他的思路，大致没有问题我就让他动手写文档，而且我要求项目组所有人写文档都必需在线完成，我会随时检查文档的质量。（说明：我们用SharePoint来管理项目文档，Word、Excel等文档都可以在项目网站上在线编辑。）
绝大部分项目是分秒必争的，保证大家用正确的方法做正确的事情，才能最大限度地减少返工。不过上面提到的检查办法确实有点夸张，我一般对于新手才会这样检查，当新手已经成长起来，你对他有信心，就不需要检查得这么密了。
4、不断思考减少工作量的办法。
失败的项目特点，往往是无用功太多，返工太多！
软件项目的特点是“两不明确两大限死”：需求不明确、设计不明确、工期限死、预算限死。要成功完成项目，不能光靠所谓的项目管理知识，你需要熟悉这个软件开发的方方面面，想出降低工作量的方法。
能极大降低工作量的两个方面：
1）需求方面：抓住本质需要，尽量简化需求，优先实现稳定的需求。
稳定的需求是指我们基本能明确，客户将来不太可能会变化的需求，这些需求应该优先实现。
2）设计方面：采用成熟设计，重用组件，采用能降低编码和实施工作量的设计。
通过以上两方面降低工作量，光靠项目管理知识是办不到的，你需要在这两方面有资深的经验，你需要发动项目组全体人员的智慧，一起想出简化工作的办法。
5、密切留意需要客户和第三方完成的工作。
我们公司的项目在开发阶段还算比较顺利，因为一切都是自己来掌控的，但一旦涉及到客户或者第三方，问题就非常多。下面是常见的一些问题及应对办法：
1）确认需求规格说明书，特别是一旦要求客户签字盖章，就会左推右推。我们会跟客户说明签字是表示对前面工作的确认，不代表将来不允许变更。
2）客户不能及时准备好实施所需的软硬件环境。我们会提前很多提醒客户，并尽可能帮助可以搭建实施环境。
3）系统上线后，客户无法及时组织人员参加培训，推动系统正式使用。我们一般会走高层路线，让客户高层推动系统上线。
4）系统需要用到的服务器或相关硬件不能及时采购。我们会事先做好供应商选择，挑选合适的供应商。
不要忽视客户和第三方的工作，一般需要打很大的提前量来进行预防性管理。
优秀项目经理是怎样炼成的？
软件项目经理往往是权力小而责任重大，软件项目的“两不明确两大限死”特点，让我们做项目犹如走钢丝，而且要高速地走钢丝！
你的综合实力决定你能否成为优秀的项目经理！项目经理是练出来的，下面谈谈我的体会。
1、你需要有扎实而丰富的软件工程实践经验。
想成为优秀项目经理，从编码切入可能是最好的打基础办法。我编写VB与C#的代码都有若干年时间，编码的工作其实不只是编码的，你还需要考虑测试，你还需要思考软件是否符合需求，考虑软件如何安装部署等。只要你能坚持3年以上的编码工作，相信你一定会有软件工程的多方面经历，如需求、测试、实施，这些经历都是你宝贵的财富！如果你是从测试、实施切入，你可能难以获取软件编码、软件设计、软件技术方面的经验。
2、学习软件开发牛人总结出来的项目管理知识。
关于项目管理的资料书籍很多，强烈建议大家重点阅读软件开发牛人总结出来的经验。如果你还没有实际工作经验，大学中学习的软件工程知识，可能还能“忽悠”一下你。但如果你已经有实际工作经验了，建议你一边工作一边学习资深软件开发人员的著作，会让你产生极大的共鸣，让你思考如何工作得更好。我最开始看的一批项目管理书是微软资深开发人员编写的，大家找实用项目管理知识书一定要注意作者有没有多年的实际软件项目管理经验。
3、主动承担项目管理工作。
我刚开始的三年编码生涯，基本上是出于“无人管理”状态下完成一个技术含量较高的桌面程序。当时没有人带领我做这个软件，我完全是靠自己一边探索，一边前进，这无疑是给了我自己管理自己的锻炼机会。不要等别人来管理你，你首先应该要会自己管理自己！如果你能管好自己，你就应该主动申请带领团队完成一些工作。项目经理可以说是训练综合素质的最好职位，无论你将来升任部门经理、高层领导，甚至做老板，还是回头钻研技术，项目经理一职绝对是你以后成功的超级助力器！
4、持续总结，不断进步。
总结使人进步！你应该利用一切机会思考和改进。很多人不喜欢写文章，这一个很大的问题，写文章其实不需要什么文采，关键是你脑袋中有没有东西？我主要通过以下几种途径来帮助自己总结：
1）在项目中我会编写计划、需求、设计等各种文档。
2）我平时会整理出很多文章。
3）我会整理出很多课程，在公司的每日培训中与大家分享。
本文介绍了我在项目估算与计划的实践体会，希望能为大家带来有益的启发。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/