软件开发实施过程中如何管理业务需求
企业的常规做法是比较典型的交钥匙工程，业务部门提需求，软件开发部门就去张罗方案论证并组织实施，业务部门最后验收评价和使用，IT部门负责系统维护和更 新。这样做的结果往往是系统不好用，不适用，或者跟不上业务的发展，业务部门不愿意用，最终成为摆设，浪费了投资，而带来的唯一好处可能是给企业相关人员 上了一堂生动现实的用户培训课，花钱买了经验教训。
一般地，在IT项目上线前后，都会做需求调研，并要求业务相关方签字进行需求确认。而在后续的项目推进过程中，一般都会冻结业务需求不做变更响应。这样会 造成系统上线后与业务需求匹配存在偏差，需求实现程度又直接关系到项目效果，业务用户要求更改，这又增加系统正式上线时间，影响项目如期验收，IT部门将 被诟病。如果项目比较复杂，IT部门害怕出错，前期需求调研时间都比较长，应用推出的周期相应增加，业务部门等待时间过长，满意度也会降低。
因此，为了推进企业IT建设，适应业务管理需要，必须让业务部门深度参与IT建设，充分激活业务人员的主观能动性。如果企业以前没有采用这种模式，可以选 择一两个业务部门，试点推行一些节省人力、改善效率的系统，业务部门很快感受到技术的好处，就会带动其他部门逐渐形成主动提出各种需求的习惯。
在软件开发系统建设和完善过程中，企业都需要积极地管理业务用户的需求，并根据情形对系统进行优化完善。为此，IT部门具有IT项目建设管理、系统维护职能，需要在系统全生命周期中对业务需求进行有效地管理，便显得尤为重要。
一是尝试逐步建立需求量化管理模式，可以从使用角度对需求管理、IT实现程度、业务期望值等方面进行量化，考量项目是否满足业务的期望。以需求管理为例， 在开始建立IT系统时，可同步建立用户的使用日志，让管理层、业务层的每一个使用者都可随时了解企业整体系统的使用情况，哪些系统使用的频率更高，哪些功 能用的多，哪些功能用的少等。通过这样不断的积累，在企业内部形成这样一种新观念：一个系统用得好不好，首先源于业务部门的需求提得好不好，业务部门应该 对这些需求负责。如果业务部门提出一项需求，但实际上并不使用这些功能，说明当初的需求提得并不好。
随着来自业务的需求越来越多，可以进一步引入看板管理，将需求进行分级分类。需求分为功能需求、界面需求、使用需求等，主要的、重要的需求会被写到看板 上，让所有人都可以看到哪些需求正在排队，哪些需求正在解决中，哪些需求已经解决完毕，尽量做到公开、透明，能够获得相关部门和人员的理解、支持与配合。
二是IT部门要帮助业务部门更好地提出需求。通过建立良好的沟通模式，IT部门和业务部门共同研究业务变化、需求变更，并深入探讨需求的合理性。IT部门 在接到一项需求后，并不马上就投入需求实现的工作中，而是先对需求进行初始化，探究需求背后的动机，了解业务部门的真正想法、管理者的想法、技术人员的想 法，各方达成一致。在确定需求的内容合理之后，才会开始进行规划和执行阶段。
对于IT部门和乙方而言，平时最头疼的并非项目型需求，而是来自用户平时的零散需求，或者根本说不清需求，只有一个大概的需求框架。先说前者，零散需求往 往来自对现有某一项功能的改进，或者临时需要对一部分数据进行处理等。面对这些零散需求，一般企业的IT部门会采取拖延战术，尽可能不做响应，其实更好的 做法则是拥抱需求，拥抱变更。一个好的系统是设计出来的，一个好的系统也是用出来的。一个系统在用户的使用中，必然因为用户的习惯和业务变化，产生各种需 求，而IT部门通过小修小补的多次改变，才能逐渐让系统变得友好易用。反之，如果一个系统不做任何变更，用户逐渐便不愿意使用，系统也就荒废了。
至于后者，在业务需求不清晰的情况下，可以暂缓执行需求，应和业务部门继续研究完善。当然，如果有能力，可以先搭建一些原型系统，引导业务部门思考，不断参与系统试用，进一步明确、完善需求。
三是要加强IT部门自身的团队建设。在项目建设过程中，IT团队最好能够相对固定，并且要随着业务发展进行转型。企业IT部门在进行项目管理时，在乙方人 员进场后，不能只当“包工头”监督乙方的工作进度，还要领会业务的IT需求和实施方案，进行需求的匹配分析。否则系统一旦上线，IT团队还是不知道内部的 设计细节。基于此，IT团队需要具备更高的技术技能，包括把控需求、设计主要的技术路径，从长远来看更有利于IT团队能力和价值的塑造。
根据个人经验，IT系统建设都是不断的折衷，IT部门、业务部门和承建方三方相互妥协。系统越复杂越是这样，企业要抓大放小，实现主要的功能需求、使用需 求和界面需求，一些未尽需求只要不影响大局也可以留待后续升级更新中去实现。从这点来看，IT系统项目建设和新房装修其实差不多，业主方的能力强、考虑问 题全面，留的遗憾就会少一些，或者无关痛痒，总体上来说就算是比较成功的了。
