一、做好计划

项目计划是指导项目执行的依 据，也是衡量项目组绩效的基准，做好计划至关重要。 项目计划是由项目总体计划和子计划组成的。通常，进度计划、质量计划、风险计划、测试计划、配置管理计划以及沟通计划是项目计划中比较重要、对实际工作也 比较有指导意义的几个子计划。其中，进度计划是所有计划的基础，它确定了项目的时间范围，它让你知道在哪个时间应该完成哪项工作;质量计划则告诉你这项工 作是否已经完成，是否满足要求;风险计划将会告诉你完成这项工作可能出现的障碍，应如何解决，比如对于维护型的项目要考虑到人员常被借调，突发任务对计划 的影响等;测试计划将会告诉你如何循序渐进的发现工作中存在的漏洞，是否可以交工;配置管理计划将会为你列举一下这项工作将由哪些部分组成，哪些是关键 的，哪些是可变的;沟通计划将告诉你在做这项工作的过程中你要跟哪些对象共事，应如何跟他们协调一致。 另外要注意项目计划是项目组全员参与的，目的是项目组团队对计划取得一致，另一个原因是获得双向的一个承诺。

1、针对确认的需求评估工作量，评估要基于功能细节来做，经过估计计划才有意义，与实际偏差才会少一些

2、项目计划的缓冲时间

按常规的项目计划，一般预留10-20%的缓冲时间，以应对中间可能出现的风险，比如人员变动带来的影响或接口部门的节奏不一致对项目计划造成的影响。

3、接口沟通的重要性

一 般项目中难掌控的是接口系统的开发进度，不同部门的工作习惯和人员能力不同，加强沟通和引导。通俗地讲，是项目组在沟通过程中，要预先把这部分的工作 分析好。对涉及双方沟通 的结果需要有文档记录，比如会议纪要。确定责任人、完成时间等。出了问题后可追述到人。追究毕竟不是项目组要的结果。为确保项目能顺利进行，接口的沟通是 很重要的，比如研发组在沟通过程中能否处于权威的地位?能不能领导其它接口系统的工作?可视情况适当借助上级或对方上级的力量，对相关接口人进行督促。保 障项目的进度。

4、项目计划是渐进明细的过程：计划也不是一蹴而的，任何人也没有料事如神的本事，它是一个由宏观到微观、由粗到细逐渐分解逐渐细化的过程。 如果不考虑外部因素的影响，计划变更的频率和幅度，可直接反映出制定计划时存在的问题，比如可操作性。总结经验，避免下次再犯同样的问题。

5、项目计划的粒度

按PMI的提倡工作任务的分配是规则是80小时的单位，软件行业属于高新产业，对进度的控制相对要比建筑行业更紧凑一些。所以软件研发类的项目更应该控制在2-3内比较合适，即16-24小时。

二、需求变更控制

首先需求分析应该有两层的含义：

1、理解用户的需求，2：辨别用户需求。做到这俩点的基础是需要理解用户的业务需求，即业务模式和操作习惯(通过信息系统或人工处理事务的方式)。

理解用户需求：指的是在做调研的时候，要理解用户表达的意思，不要漏掉用户提供的细节。比如文档或口头的描述。为辨别用户需求做基础

辨 别用户需求：一般系统常见的问题是，业务专家有很多，很多时候，专家意见不一致。甚至天马行空，不符合逻辑，不切实际的需求很多，需要在了解用户的业务模 式后，才能辨别出来。注意在调研的时候要做好文字记录，不要漏掉细节。回头仔细琢磨。这一点是很多项目经理或需求分析人员忽略的地方，为后期变更埋下隐 患。

避免这种问题的情况是，找理由到客户现场，想办法收集基层操作员的需求。

2、预估需求

对于用户未提到的需求，但可能以后会扩展的需求的应对方法。对于内部系统来说，可以早期引导用户。对于外部项目要在设计时考虑到，保留必要的接口。等客户提出后，执行需求变更。增加合同额。

3、焦油坑：需求变更之站得高未必看得远

“领导层定的需求”或叫“排脑袋型的需求”

很多业务系统的需求，没有用户方实际操作人员的参与，导致的现象是“站得高，看得远，但不一定看得清楚”。这种问题发生后一般是影响范围很大，但又不能不修改，通常是超出了项目经理控制能力范围之内。客户还不愿意加钱，需要尽快和公司领导汇报，由领导出面来解决。