IT领导力 ｜ 需求管理的博弈及解法

在给企业做IT管理的咨询中，我发现IT部门如何证明自己在组织内的价值，是很多公司的IT部门面临的挑战，而矛盾的焦点往往在于IT部门是否能够全面、及时、保质保量地满足业务部门雨后春一样提出来的“需求”。昨天在一个CIO论坛上，我发现某大企业的CIO用下图来展示他的IT战略——“需求管理”是衔接业务战略和企业架构的战略性环节，可见“需求管理”对CIO的重要性：

然而，真相简单又很残酷，在这个世界上，不可能有100%能被满足的需求。“需求管理”实质上是IT部门既要证明自己存在的价值，又要跟业务部门在必要性、交付能力、交付优先级等方面不断博弈的战场。

如果IT部门被动应付业务部门提出的需求，就会被整得很惨。我过去管理企业大型信息系统实施项目的经验是：绝对不能让用户信马由缰地提需求，而是要主动引导用户的应用需求。

业务部门的用户提出“系统需求”，自然而然地会站在IT系统使用者角度，既无全局观、也无系统观、更没有业务流程优化的高度和前瞻性；而信息系统实施（注意，不是定制化开发系统）受到套装软件本身功能和架构的限制，以及出于控制项目范围的考虑，一定会采取措施，控制用户提需求。

此外，实施信息系统的目的是提升企业管理，不是简单地满足用户使用需求；很多用户在上系统前提了一堆需求，一部分可能无法满足，然而，用上了先进的IT系统后，他们会发现很多超越自己过去认知的提升，会有柳暗花明、会临绝顶的感觉，这就是他们的格局被打开了，发觉自己过去“提需求”的格局小了、格局低了。

用户开上了奔驰，还会嫌原来自行车的那个刹车把手捏起来不舒服吗？

怎么做到这点呢？有经验的实施顾问会在项目开始前，花大量的精力来对企业高管和系统用户进行培训，熟悉软件本身的“最佳业务实践”，了解通过信息系统来提升管理的原理，全面认识解决方案架构，形成端到端的业务流程意识。

这就是IT实施顾问和软件开发工程师的技能差别。

上述方式是传统的瀑布式方法，今天，系统开发越来越多采用“敏捷”，敏捷方法强调用户深度参与开发过程，在开发迭代过程中不断确认原型和产出、确认优先级选择，从这个角度上说，无需用户把需求一次性地讲完整，更便于小步快跑地管理需求。

有些企业的IT部门领导善于跟业务部门谈判，甚至希望从制度去控制业务部门的需求，例如：制定企业内部的IT服务计价体系，采用内部计价以及业务部门IT预算控制的方式，去平抑业务部门的需求疯涨。

而另外有些IT部门领导则可能在面向对业务部门的谈判能力上有所欠缺，被动地应付业务部门的需求，搞得IT部门自己内卷至死。例如，有些企业IT部门拼命搞“研发效能管理”，对自己的技术人员搞各种能力素质评价、产出效率评估、OKR等等，折腾IT部门内部的人员绩效管理，搞得怨声载道。不是说IT部门的内部管理不重要，“攘外必先安内”、“打铁还要自身硬”也是对的，然而，这样折腾多少有点自己人欺负自己人的意思。

有些企业的IT部门求诸于实施IT工具，来解决需求管理的烦恼，例如国外的JIRA或者国内的禅道一类的工具（示例如下图）。这些工具对于提高软件系统研发的流程标准化程度很有必要，是IT部门的提升效率、降低成本和提高质量的利器。但是，这种工具思维无助于解决IT部门和业务部门的外部博弈。

来源：PingCode研发管理工具示例

解决“需求管理”问题，在根本上要求IT管理者能主动地管理需求，传导IT的业务价值。

IT毕竟是服务于业务的，这个企业基本伦理不能变。IT管理者应该换位思考，向其他领域的“需求管理”学习，例如，向IT公司的销售人员学习，客户的需求也是千变万化的，销售人员是怎么既搞定客户，又搞定公司自己的交付团队的。又例如，向带孩子的父母学习，不懂事的孩子提需求也是随心所欲，上要上天摘星，下要下海捉鳖，父母是怎样做到既不损伤大人的尊严和信用，又能不对孩子有求必应的？

解决“需求管理”痛点的咨询药方很可能是CIO领导力提升。CIO和产品经理要提升自身领导力，加强客户服务意识，深入洞察业务，对IT系统的业务架构、解决方案架构具有全面深入的理解，才能在企业内树立威信，搞定用户。

 我来总结一下：

二逼的需求管理靠吵架

普通的需求管理靠JIRA

文艺的需求管理靠茅台

各位CIO，你们觉得是不是这个理儿？

(欢迎大家加入数据工匠知识星球获取更多资讯。)

了解更多精彩内容

长按，识别二维码，关注我们吧！

数据工匠俱乐部

微信号：zgsjgjjlb

专注数据治理，推动大数据发展。