四．项目工作量预估和问题分析（这是难的工作）

　　这个问题直接决定项目周期的长短和人员的投入及调配，也是项目经理难定的一个量，需要在实践中不断积累经验。一般是按调研后的需求分析说明书来确定工作量，根据各个模块的难度和开发量决定投入的人手和时间，预估项目中的问题难点，包括技术瓶颈、负载压力等。很多问题的发现和预估则靠多年的工作经验。
    
　　这方面内容是项目经理争取优势资源配置的重要依据，所以有些技术难点不防有限度地夸大一些，但牛皮不能吹破了，不然以后领导对你的印象是夸大其辞。

　　笔者有一次向领导申请公司牛人来负责软件中的权限设计，将话说过头了，结果领导听后反驳了一把。日后笔者再向这位领导申请资源时，领导遇到自己不懂的技术，总会去问问其他同事后再答复笔者，而不是之前那样，笔者提什么要求都当场一口答应。让笔者花了半年以上的时间才重新建回了信任关系。
   
　　项目工作量的预估要在熟知需求的基础上，没有太多经验的项目经理一定要多读几次需求说明书，明了客户的需求重点和关心的结果，有经验的项目经理都会关注需求说明书，更何况是经验不多的项目经理了。对需求说明书中有疑问的、有岐义的一定要标注出来，和相关人员讨论清楚，甚至和客户谈清楚需求点，以防出现方向性错误。

　　五．项目工作计划（这是核心的工作）

　　本项目的工作计划，包括资源的申请、人员的搭配、团队的组建、开发进度的安排，计划分期的重点，如第一期大约到什么时间，主要完成的任务是什么，需要投入什么样的人，各自负责什么。

　　注意时间点的把握，如果项目实际进度和计划的时间出入较大，项目后期将非常被动。笔者提供一些参考数字：一个半月以内的一般多报一个星期，三个月内的一般多报两个星期，半年以内的一般多报一个月，一年以内的一般多报一个半月到两个月，为项目预留出足够的时间。

　　在国内，软件厂商签约时都处于劣势地位，明知道时间很紧，为能顺利签下合同，也不会向客户提出因对需求理解不准而导致的项目时间推延，怕客户认为我们不专业而丢单。项目经理如果不能在规定时间内完成任务，项目如果因为一个不可控的风险导致项目时间不足乃至失败，则项目经理的压力非常大。所以安排工作计划，要预留出时间以备处理意外事件。
   
　　六．项目推进计划

　　这部分是写客户现场的推进计划，包括什么时候提交什么东西给客户，现场工作的重点是什么，需要客户怎样配合等。还有项目的验收思想和验收时的问题及注意点，比如采取整体验收还是分期验收，还是分模块验收或分批验收，验收时要找谁，需要哪些人配合，验收时应注意什么问题、如何避免等。有了上面的分析后，制定执行计划水到渠成了。所以大公司往往将高薪发放有发现问题、分析解决问题的人才，对编程人员的薪水往往差一档次了。

　　这部分计划可以扩充和细化后提交客户，让客户也明白什么时候我们的软件会开发到什么程度，什么时候需要他们什么样的配合，不至于项目组进场打乱他们日常的工作安排。客户有了这样的计划书后，都会提前安排自己的工作，到时对项目的配合力度更强。

　　笔者的计划书一般写两页多一点，多不超过5页，把握重点难点，又对客户进行较详细的初步分析。不论是和公司的领导谈项目的进度安排，还是和同事及项目组成员布置具体任务，大家心里都有数，知道下一步要做什么。这样项目只要不发生大的意外和方向性的错误，一般都会处于笔者的预期和控制范围内，项目失败的风险尽可能地降到了低。