业务需求与业务管理

从理论上来讲，需求工程包含两部分主要工作：一是需求开发，二是需求管理。

需求开发又包含需求获取、需求理解、需求分析、需求定义和需求验证，
需求管理主要是需求跟踪、需求核实、需求变更的管理。

项目中经常遇到两类问题：一类是我们按照获取到的需求实现的功能，用户觉得不是想要的，或者没有达到他想要的效果，导致重新提出需求或者需求变更。另一类是用户反复的变更需求，有时候已经提出过的需求又重新被提出来，到时工作范围一直变化，工期一拖再拖。通过对以往项目管理工作的总结我觉的可以这样处理，可能会获得比较好的效果。

第一类问题通常是由于我们在需求沟通过程中忽略了客户需求背后的需求。客户的需求通常都是为了支撑实际业务提出来的，而且大多数情况下客户都是经过了自己的思考，意识中已经有了一定的解决思路或想法，他们觉得这样做或者那样做就可以满足我的业务需要，然后把经过自己思考后的需求按照他们想的思路提了出来。问题在于客户毕竟不是专家，他们的想法和解决方案未必是好的有效的，有的甚至是不可实现或实现代价很大的。我们拿到这样的需求做出来的东西相当于替客户在验证他们的想法是否可行，而我们自己却以为这就是客户真正想要的，结果可想而知。

如果要避免或者减少这样的情况发生，我们应该关注用户需求背后的需求，也就是业务需求。在和用户沟通的过程中，在了解用户所提出的需求时，要一并了解这个需求的业务场景、要解决的业务问题是什么，在业务逻辑中的位置和逻辑关系是什么，然后与用户一同针对业务问题进行分析，得到真正的用户需求，进而得到真正的软件需求。这样我们做出来的东西更有可能解决用户实际的业务问题。

第二类问题首先我们都要承认需求变更是不可避免，也是可以理解的。此外最重要的就是对需求的变更要进行管理。在项目之初最好就与客户约定一个变更的流程，让客户了解需求可以由变更，不过要有一个流程不是随意变更。可能有人会觉得说起来容易做起来难，确实这种事情一般客户不太愿意配合我们，不过我们也要理解客户不配合的原因，适当的采取写策略。例如流程不要定的太刻板太复杂，形式可以不是很正式。曾经我一个项目的需求并更流程是这样的。变更前要把变更的目的和必要性讨论清楚，然后客户发起一封邮件，说清楚我们讨论过的需求变更内容和相关要求，抄送他的主管领导发给我们，这样就可以了。然后我们会把每次的变更和变更结果做好记录，每个月拿这个记录与客户确认一次，使整个事情有一个延续性。这样做起码有两个好处：1、基本保证了客户每次提出需求变更前自己已经想清楚了，并且业务领导是知道的，然后通过我们之间的沟通找到一个比较好的实现方式，避免做一些没有必要的变更；2、为需求变更留下清晰的痕迹，使客户能够记得曾经有过哪些变更，清楚现在的需求是怎么得到的，我们中间做过哪些工作，不要给客户留下记忆模糊的机会。