一、做好计划

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

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

2、项目计划的缓冲时间

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

3、接口沟通的重要性

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

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

5、项目计划的粒度

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

二、需求变更控制

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

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

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

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

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

2、预估需求

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

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

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

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

4、对待需求变更的技巧

对用户提出的需求来说，首先项目经理要考虑变更的合理性。不合理的需求要找到推掉的理由，避免直接拒绝。比如，如果一个用户提出的变更和系统的目标不一致的话，让用户自己推倒自己需求。好处是即给了用户面子，客户关系也能得到提高。同时避免产生了工作量。

绊字诀：先把他的招接过来，之后他脚下出一招，让他用自己的冲力把自己摔倒。

封字诀：在我们的系统是不能实现这种功能的”。之所以用这么肯定的语气是要断了他要实现这种功能的念头。封字诀就是直接回绝他，清楚的告知这招是行不通的。

拖字诀：对于比较合情合理的需求，但又不是现在要解决的问题.要想办法往后拖，不至于打乱当前的计划。

对于客户内部斗争，千万不要正面参与。有些人可能会直接拿系统做替罪羊，这个时候需要找到更上一级的领导来出面协调。借助客户的力量来摆平。目的推到二期来做。

5、编写需求变更申请表

编写要尽量详细，并经过客户、高层经理和项目组内部人员的认可。比如测试人员对测试的工作量要参与评估，开发人员对开发工作量要进行评估。数据来源基于基层，确保数据的准确性。同时补充一点变更带来的质控工作量也应该纳入到变更需求表中，比如可能设计项目总结和数据统计的工作量。

客户提交的问题要做好详细的记录，保证有据可查，对问题要进行面对面的确认，避免含糊其词的用户需求。对确认结果进行记录。

6、变更控制流程转

(1)、内部项目：用户提出需求-》项目组对问题进行分析(不明确的问题要进行确认，区分问题的优先级和解决方案)-》提交变更申请表(包含估计和计划)-》高层领导决策-》审批通过-》依照项目计划执行。

2)、外部项目：用户提出需求-》项目组对问题进行分析(过滤需求是否合理、是否在本版本来做、能否放到二期、需求的必要性等)-》与客户讨价还价(把不合理的需求、不必要在本期实现的功能推掉)-》必须要实现的需求-》提交需求变更申请(初步的计划和解决方案)-》高层领导决策-》详细分析需求和解决方案-》评估工作量-》设定计划-》客户签字确认-》依照项目计划执行

以上两者的区别在于：内部项目一般需求的控制权在高层领导中，有时候不一定关注成本，偏重于系统产生的价值，对用户而且主要关注实用和易用性上。项目经理或团队主要侧重分析用户需求的合理性。

外部项目首先应该考虑是公司投入的成本和获取的收益，比如变更会给公司增加合同额或后期市场拓展的机会和对产皮的提炼(有的项目是项目型的产品)。如果上述条件不满足，则首要考虑的是如何推掉需求。