三、需求管理

       需求管理，广义上来是说我认为需求来源是比较宽泛的，从不同角度，层次，维度会有不同的需求，项目不可能满足所有的需求，也完全没有必要。能提出符合企业真实有效的需求，相当于是提出了一个正确的问题，已经成功一大半，我所经历的项目中，需求点大部分都来源于业务操作过程中需要的功能点，甚至很多是便利性操作的功能点。很少会从价值的角度和更宏观的角度去分析和怀疑业务流程本身，从而提出更有价值的需求。

       实际项目中，相对复杂的需求企业往往很难把需求描述清楚，或者是牵涉的部门和业务比较广，或者是企业自身也没有梳理清楚和确认，结果出方案或者实施落地时候就被牵扯进去，很难收尾。我遇到这种比较复杂的需求时会厘清需求，优先定方案，扯不清的需求跟客户说清楚不做。

       对于定制化开发的需求，其实我是比较矛盾的，站在用户的角度来看，很多确实是有需要的，也有一定的价值，但从开发和维护的角度看，又涉及到人力成本，特别涉及业务比较多的开发，经常会因为用户的骚操作和业务场景的多变性，使开发内容报错，让后面接管开发维护代码的程序员也是头疼事情。开发的越多，出错的可能性就越大。另外在定制化开发时，也要考虑开发的通用性，不能完全按照企业目前的场景去开发，可以适当让客户做出改变或妥协。

       需求有时就像购物一样，买之前兴致勃勃，买之后用一会就吃灰。我曾经二开处理过很多需求，但事后发现很多被客户验收的二开功能根本就没有用，或者用的少。对于很多伪需求，不产生价值，可以和客户沟通去掉，当然要有充分的理由。把时间精力用在处理真正有价值的事情上。

      在处理需求上，我们新顾问可能会唯唯诺诺，不够自信，往往被客户带着走，特别是遇到比较强势的客户，一下这些技巧是可以借鉴下的：

      一是懂得拒绝，除了上线前的需求，上线后可能会不停的有需求提出，对影响不大的可以直接拒绝，说明理由，否则需求会越来越多。有一定影响的，新需求或者需求变更，一定要让提需求人向上反馈，让领导们决定怎么处理。即使客户领导也同意新需求和需求变更，顾问如有充分的理由，也是可以拒绝的，或者放在后期再处理。

      二是要势利点，越是重要的人需求越是要重要对待，有机会与重要的人多沟通。这点很重要，越是上层的人，对公司产生价值越大，对项目影响力也越大。

暂时写到这，后面再继续补充

这位实施大佬还懂二开，牛逼！