来源：看懂经济

作者|苏文力

看懂经济专栏作家，曾供职于阳光保险、中国工商银行

一次聚会上，老同事引荐我认识一家咨询公司老板，对我过去在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方必须复刻老做法，动辄以“制度规定”为理由，不顾技术变革对业务流程的重塑作用，拒绝与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资源有限，注重抓主要矛盾，将需求重点放在最能创造业务价值的地方。一开始并不盲目追求完美，而是强调先上路，完成最关键部分的开发。根据应用效果再逐步优化。

他敢于突破传统思维和既有制度的束缚，大胆探索技术赋能下的创新机会。敢于承担业务变革带来的风险，并会在严控风险上做出周密的设计安排。同时会积极向上级和审批单位证明风险可控，获取批准和支持。

他会遵照IT的需求文档格式要求，组织写出详细的业务需求说明书。他带领业务团队加班加点，并在第一时间征求IT的意见，以给IT留出更多的开发时间。对于IT的疑问和意见，耐心的给予解释，虚心的做出调整。

他把支持开发排在其工作优先级中的前面，经常与我们在一起。当遇到技术难题无法突破时，他会主动在业务上做出调整，帮助IT越过障碍。当因市场竞争或发现业务漏洞，需要补充需求时，会跟我们协商，适当延长工期。

系统原型开发出来后，会第一时间赶来，安排体验IT系统实现后的效果，验证前期需求想法的正确性。系统开发出来后，会积极组织测试验收。支持我们开发的同时，精心准备好系统上线后所需的业务配套。

投产后业务上取得成功时，他总是强调IT发挥了关键作用。效果不及预期时，则会先从业务上思考改进的地方。即便IT发生掉链子的情况，也从不埋怨，而是与IT携手，一起共渡难关。

我们之间并非总是一团和气，也会激烈争吵。但大家都不固执己见，而是会替对方考虑，愿意做出妥协让步。每次都能找到大家都能接受的选项。我们的关系也因此更加密切，以至于有些惺惺相惜了。

业务需求方的水平决定了创新成效所能达到的上限。可以尝试对业务需求方做个检视：在创新中发挥了怎样的主导作用？与IT方在一起讨论的时间有多长？有哪些决策受到了IT方的启发？在业务配套体系方面做了哪些？希望您在思考中产生了新的觉察，为此有所行动。

苏文力在看懂经济上发表的文章

特别声明：以上内容仅代表作者本人的观点或立场，不代表Hehson财经头条的观点或立场。如因作品内容、版权或其他问题需要与Hehson财经头条联系的，请于上述内容发布后的30天内进行。