让需求活动脚踏实地（零）——搞需求太难了

本文原创，如需转载，请注明来源及作者。

陶朱子

严格说来，需求活动涵盖了系统架构过程中需求获取、需求分析、需求变更、需求管理等重要的过程。但为叙述方便，本文特指需求获取、需求分析这两项活动。另外，本文所指系统开发人员泛指进行系统建设的需求分析、系统设计等人员。

很多系统开发人员觉得需求活动很难，为什么难？

首先，认识业务领域很难。系统所涉业务领域可能与开发人员的知识背景范围相差很大，开发人员需要花很多时间精力去学习认识这一业务领域，但这些业务领域并不是系统开发周期内就能钻深研透的。

其次，业务创新很难。许多系统的建设可能会涉及到相关单位体制机制等方面的改革问题，系统建设的发起者想通过系统建设来推动业务创新达到解决问题的目的；而现实情况却是人们已习惯了现有的体制机制，即便人们都知道它存在问题，也不愿去改变它，如果涉及到改革问题，阻力就很大，更不用说涉及权力和利益的重新划分这种深水区了，业务创新的动力很多时候就无从发起，这就难怪在去向客户、顾客、用户等风险承担者了解需求时，他们对我们并不真正热心了，导致系统建设虎头蛇尾，规划的时候很宏大，做出来后发现不过尔尔。

第三，突破客户对需求的认识很难。现在很多客户也有了主导各类建设项目的经历了，特别是建筑类项目，历史悠久，规章制度齐全，规划设计方式成熟，需要多少砖瓦能用数据估算出来，所需要的大小形状能用蓝图表现出来，建筑设计师们的需求活动给客户的实际感受很强。客户受建筑类的项目影响很大，以致于使他们认为信息系统的需求活动也是如此简单，但事实却不是这样：客户目标在开始的时候可能就很模糊，系统覆盖的业务范围也不是很清楚，具体用户可能都不知在哪，就算有了用户还可能就不知道想怎么使用系统，还有可能用户根本就对系统涉及到的业务领域一无所知，甚至还需要系统开发人员去创新业务。

总的来说，开发人员对需求的感觉就是朦朦胧胧，如镜中花，水中月，仿佛能接触到，一伸手却捞不到什么。尽管如此，难是不是就意味着，开发人员就可以把需求活动一带而过了呢？是不是就可以以客户的需求不现实为由而拒绝接纳需求呢？是不是可以让需求活动浅尝则止，浮于表面呢？都不行！开发人员必须把需求活动落到实处，帮助客户去发现需求，引导他们表达出他们真正需要的东西，勾画出一个让用户能真正去切身感受的需求定义，最终为系统设计奠定一个良好的基础。好！下面我们就开始吧。