软件项目需求管理总结

思考的牛

　　在软件项目中，需求管理贯穿了项目的整个生命周期。销售阶段的需求管理核心目的是要激发企业业务部门对信息化的需求，而此时业务部门往往因为对软件的心理障碍和本身的限制，提不出需求来，一般是售前顾问站在企业管理特点和管理问题等角度提出，这个阶段的需求，越多越好，而且需求越痛越有卖点，因为这样更能体现信息化建设的必要性和带来的价值。

　　但从实施立项开始，需求就成了所有项目经理的心头之痛。客户花钱购买了我们软件，理所当然地认为软件可以解决一切问题、甚至代替管理;加上销售过度承诺、客户应用经验的增加和对软件的了解程度加深等，都有可能使客户对软件的需求不断变化。如果不能有效管理这些需求，就很容易导致项目失去控制，客户购买的一辆QQ，也许最后你不得不为他打造一辆劳斯莱斯。

　　如何管理？

　　一、需求无法控制，只能进行管理

　　需求无法控制，只能进行管理，正如吃饭一样，饿了就得吃，不吃难受。为了把需求管理在一定的范围内，首先，实施顾问必须充分了解销售阶段是否有过度承诺(包括文字或签约)。前期在实施JL项目时，签约合同中明确只实施1套帐，但客户咬定销售承诺实施2套帐，最后不仅项目拖期才验收、增加成本，更坏的是客户对金蝶印象大打折扣。其次，我们在制定实施方案时就要与客户项目负责人确认实施范围、目标、项目风险及本次实施工作的重点。

　　二、了解需求产生的原因

　　原因何在?总结大部分项目，提出的需求所产生的原因往往集中在以下几方面：

　　1、调研产生的需求;

　　2、对软件操作不熟悉，总觉得需要快捷方式或快捷键

　　3、操作模式同之前的软件有较大的区别，这种情况尤其是此前使用过软件或习惯了EXCEL灵活模式的人;

　　4、业务流程还未理顺，尤其是部门之间的衔接还不顺畅，这时候抱怨产生的需求;

　　5、相关的基础数据不完善，甚至有错误的地方;

　　6、出于部门利益的考虑，某个人或部门的想法，没有考虑全局;

　　7、客户方人员或项目负责人变更引起;

　　8、企业高层比较理想化的思维;

　　9、随着对软件深入了解，对软件提出的更高要求。

　　三、需求分析

　　1、需求调研和业务流程整理完成后，实施顾问手里就会有一大堆的新需求。这时，最忌讳的就是哪个最简单的，就先实现哪一个。而应该是那个最重要，最有影响力，就要先实现它，以达到很好的短期效果。

　　2、针对实施过程中产生的临时需求，需要灌输"先固化、再优化"的思想。

　　3、对于应用层面的，主要加强培训，并对提出者要给予鼓励和表扬，说明将在后续的工作或软件版本中给予响应或解决。

　　4、对于关心部门利益的，可提交客户方项目负责人或多部门同时开会讨论解决，很多时候这种效果很明显。

　　5、对于影响了企业全局工作或影响实施效果的需求，经过判断，应和客户管理层进行沟通。

　　6、随着客户应用层面的提升，客户提出的需求必须明确可以提供解决方案，但不在本次实施范围。

　　四、需求需要沟通并确认

　　客户提供出了众多的需求，均需充分了解客户需要的是一个解决方案还是真正的功能需求。提前和客户方项目负责人及提出人一起，对需求的认识达成一致;确认需求时要避免与一般业务人员交谈，因为一般业务人员可能仅仅考虑软件的实际操作或习惯问题，应该与企业的管理层沟通，了解他们需求背后实际的管理要求，从而分清客户需要的是一个解决方案还是软件的功能需求;确认后双方书面签字确认。我们实施顾问经常忽略的一点是需要解决未和客户确认，这非常重要，问题解决一定要确认，看处理情况可以高调宣布。

　　五、不要一次满足所有需求

　　对员工基础的需求，不要一下子就全部满足。有些人会想不通，认为马上全部满足，不是会更好吗，员工不是更满意吗?从短时间来说这没错，但是从长久来看，不见得非常准确。

　　其实，这个道理喜欢看连续剧的人非常了解。比如一部30集的电视剧，你今天看了第29集，明天就会感到非常牵挂、非常期盼，觉得还有事情要做，做事有动力。在项目实施中的目标就要达到这个效果，让员工对软件需求有个动力(当然在验收前必须处理好)。

　　六、承诺必须兑现

　　1、对客户提出的需求，实施顾问要仔细考虑，不能随口承诺，这里最要注意的是人的思想同计算机语言毕竟是有区别的。

　　2、如果承诺是通过二次开发实现，需和开发进行评估，避免由此引起的风险。

　　3、如果同客户确认了需求并明确了解决方案和实现时间，必须在规定时间内兑现，不能如期兑现的，也需提前和客户沟通，切忌到兑现时间没完成才去和客户谈，一次还好，多了直接影响客户对实施顾问的信任度。

　　总之，软件项目的需求管理是项目成败的关键，尤其是在强调个性化的时代，客户一贯认为软件是万能的，因此对实施顾问考验也很大，但只要能很好管理需求，赢得客户信任，就可以取得项目的成功和客户的认同。