IT设计师该怎样与业务方讨论需求

作者|苏文力

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

家里改造卫生间，装修公司设计师很快就拿出了设计方案。大多数设计内容都挺好，可竟然缺失防渗漏水的部分。原本以为咱要求改进的意见很合理，对方却各种绕圈子、找借口，让人十分恼火。

看着这位年轻人，貌似专业却很自我的样子，突然就想起了年轻时的自己。作为IT系统设计师，常要与业务部门一起讨论需求，确认所给出的设计实现方案，同样总能成功的惹恼对方。

所犯的错误都一样。没将关注的重点放在客户想要实现的目标上，而是以完成自己的设计方案为出发点，更多考虑的是确保需求实现更可行、更省事、更经济，且后续不会有太多的责任。

与客户站在一起

自己刚开始做设计师时，接到业务方的需求，若能找到比较现成的解决方案，就满口答应下来，而若实现起来有较大难度，则会想办法说服对方调整需求。为此难免相互间有些磕碰，但一般都能最终谈拢。

一次行里信用卡部门找来，商讨开发全国信用卡系统。其中有一项重要的诉求，就是要让储蓄网点都能受理信用卡业务。该要求极大的限制了系统实现的设计思路，造成了我们思维的僵化。

一开始谈的挺顺利，可很快就在信用卡采用多少位卡号，这一细节问题上卡住了。卡部提出要16位，而我们却坚持只能设定为15位。双方各说各的理，氛围一度搞得十分紧张。

我们认为唯一可行的实现方案，是在现有储蓄系统的基础上，增加开发信用卡服务功能。因此，新系统必须沿用现有的系统架构。卡号长度超过15位，会破坏原设计的数据结构，引发对系统架构的调整。

这不但会造成开发工程量和时间成倍增加，更令我们无法忍受的是，还可能影响已有储蓄系统生产运行的稳定。为此我们坚持不让步，反复向卡部解释说明，请其理解我们的难处。

根本就听不进去对方的意见，脑子里考虑的都是自己的风险和收益。想要确保实施方案的简单高效，以及上线后运行的安全稳定。一门心思就是要说服对方，还自认为也是为了业务好，对方应该让步。

以往遇到类似情况，软磨硬泡之下总能奏效。可这次卡部却毫不退让。双方争执不下，只能先搁置分歧，讨论其他部分。可卡号长度问题怎么也绕不开，谈着谈着就又回到了卡号上，当天的会议就在争执中早早结束。

会议所在地的IT部门领导，作为局外人看到了真相。会后跑过来提醒我，在这种相互都想说服对方的局面下，怎么吵都不可能解决问题，还是该多听听卡部究竟是怎么想的，或许能有新的发现。

一语点醒梦中人。我们已站在了卡部的对立面，一心想要说服对方，证明自己是正确的，赢得这场争论，却忽略了会议的目的，是为了更好的了解和达成业务所追求的目标。为此我们应该与卡部站在一起。

赶紧调整心态，摆正自身的位置，放下对所设想方案的执念。在第二天的讨论中，耐心倾听对方的想法，努力发现和理解其中的合理性。气氛一下就缓和了，也掌握到了许多未曾注意到的信息。

业务之所以坚持采用16位卡号，是其国际标准化发展战略的要求。通过发行符合国际卡组织标准的信用卡，逐渐与国际接轨，借助国际组织的力量，学习提高，把信用卡业务做大做强。

我们却错误的认为发行国内使用的信用卡，没那么多条条框框，卡号长度完全可以变通。当问题上升到业务发展战略的高度上时，也就失去了讨价还价的余地。既然国际组织对于卡号有明确的规范标准，那就只能遵守了。

不仅是卡号长度这一项，未来需求中肯定还会有更多的业务规则，是基于国际卡组织的标准规范而提出的，都必须不折不扣的执行。搞清楚了这一点，心里反而踏实了。唯一的选择项就是改变我们设想的方案。

奇怪的是，认识到这一点后，我们的思路反而开阔起来了。很快就找到了极为简单的解决方案。只需在输入输出模块中做卡号转换，完全不涉及对核心架构的调整。无论是开发工作量还是实现周期，都在承受范围内。

这件事给咱上了难忘的一课。往后与业务方讨论需求时，就知道先不去考虑设计实现的事情，而是与业务人员站在一起，探索想要达到的目标，共同迎接达成目标路径上所遇到的挑战。

从业务目标出发

在讨论需求的过程中，不能只盯着业务方想要解决的问题。还要通过与其共同探讨，深入问题的本质，搞清楚其解决问题后，想要最终达到的目标。确保后续措施能让其取得想要的进步。

从解决问题出发，容易局限于问题本身，缺乏整体思考。采取行动措施后，很可能解决了老问题，却发现随之出现了更多新问题。不但没有达到业务想要的目标。反而给其带来了更多的麻烦。

只有面向业务目标，把握住全局，才能保证采取措施能达到业务真正想要的进步。以终为始还能帮助我们打开思路，看清实现目标路途中的障碍，产生更多的创意思路，找到更有效的实现路径。

业务方对自己目标的描述一般都很模糊。有些需求文档貌似详实，可涉及最终目标的部分，往往只是一带而过。认为目标不言自明，却可能自己都没有认真思考过。经常会有盲区存在。

业务方基于自己的知识经验阐述需求，所提供的信息往往不是很充分。而设计人员缺乏完整的业务背景知识，理解上常出现歧义。这就需要耐心向业务方请教，通过提问一起深入探索，补充缺失的信息。

提问的内容应包括实现该需求想要达到的目的，价值和意义，最终成果的具体样子，为此愿意付出的代价，想要极力避免碰到的麻烦和风险等等。有了更多的信息，才能做出靠谱的设计。

以我装修卫生间为例。最想解决的是浴缸不实用的问题。家里人从不泡澡，在浴缸里淋浴，既不好站，还把水溅得到处都是。需求就是拆掉浴缸，换装成淋浴间，为此也提供了大致的尺寸规格和价格区间要求。

设计师因无法观察浴缸下面的防水情况，不能准确评估相应的施工量，因此就做了个大致设计。将具体的实施内容，留给施工者根据实际情况而定，合同中也就不涉及相应的防漏水条款了。

可其忽视了我所追求的目标，以及我的担心。换装淋浴间只是我解决问题的手段，所追求的目标是让家人使用洗手间时感到舒服。如果以后洗澡时，发生往楼下漏水的情况，想想都头疼。

给设计师倒了杯茶，坐下来慢慢聊。请其站在我的位置上，看看目标应该是什么，还有哪些更好的解决方案。设计师很快理解了我的诉求，赶紧请教有施工经验的工长，给出了令我满意的设计，协议顺利达成。

在所遇到的IT项目中，很多在原有系统基础上优化的需求。设计者常会图省事，不假思索的在原系统上修修补补。做出来的东西，有时业务方却不满意。问题就出在对业务目标的理解上。

随着时代的进步和技术环境的变化，如AI大模型的出现，客户会产生新的想法，其目标将随之调整，而达成目标的方式也会更为多样和有效。因此要保持对客户目标的持续关注，经常回顾思考，并寻求更好的实现方法。

有些需求可能仅仅是业务应对领导压力的缓兵之计，或有其他不愿讲的目的。不管怎样还是要尝试去沟通，借助与对方讨论目标实现的机会，摸清其底牌，以避免对IT资源的过度浪费。

公司高层领导常会提出创意设想，自信的要求业务部门尽快落实。可其中有很多想法并不靠谱。若业务部门面对领导所关注的业务困境问题，拿不出更好的解决方案，一般就会顺着领导的意思去做。

可高层领导时间紧张，常会缺席需求讨论。业务部门对领导的想法并不充分了解。大家只能猜想其中缺失的信息，以此得出的结论自然质量不高，很可能造成所做出来的系统，表现的不尽如人意。

解决的方法是将讨论的结果形成较为详细的文字报告，提交给领导确认。若其真对此项工作很重视，就一定会找时间看，给出反馈意见。若长时间得不到领导的反馈，那就别等了，尽人事听天命吧！

保持正确的交流姿态

多年来与业务方相处的挺融洽。其中的秘诀，应该就是能一心想着为业务创造价值，帮助其取得成功，努力争取做贡献的机会，让业务依赖。有了这个做基础，相互的关系就错不了。

不过咱跟许多IT设计师一样，常犯自以为是的毛病。自认为很懂业务了，只听得进去业务所讲内容中，跟自己想法相同的部分。在获取信息不充分的情况下，依照脑补信息做决定，导致犯简单愚蠢的错误。

一个人觉着自己什么都懂，那就很容易被事实的表象所欺骗。以至于封闭了自己的信息获取渠道，无法探究事情的本质。态度上不自觉的表现得很不耐烦，让业务方感到被轻视，相互间的关系就会疏远。

必须承认业务人员在业务领域更为专业，更有发言权。毕竟人家长期从事这一行，拥有的知识和经验储备不是咱IT人员能比的。业务部门是责任的最终承担者，自然会谨慎权衡各种利弊，从整体系统上做出选择。

业务人员也有其专业上的局限，或许在借助IT开展创新方面不是特别擅长。这虽是咱们系统设计师的长项，但应先认真听懂业务的想法，再有针对性的提供帮助，从而实现双方的优势互补。

与业务的交流过程中，要给予对方足够的尊重和顺从。尊重其专业上的权威，顺从其业务上的决策。千万不要去质疑，而是通过提问去请教，一起深入探索。这样才能建立起亲和信任的关系。

应以好奇、开放、求真的初学者心态跟业务交流。先努力清空自己，即便已经知道一些，也要当成不知道，重新去认识学习。这样的状态很容易丢失，需要不断提醒自己注意保持。

要积极倾听，注意力集中在对方身上，不仅听其说什么，还好观察其表情和身体语言，感受其情绪的变化。结合所接收到的信息，进一步询问究竟是怎么回事，到底是为了什么，探寻业务想要的和背后的原因。

根据业务方的需要，反馈补充一些IT的专业意见，给出解决方案的更多选项，请业务方面选择确认。对于IT实现有困难的地方，不要闷在自己心里，而要分享给对方。大家一起想办法，经常会有意想不到的收获。

记得在开发银行电子汇兑系统时，业务要求每隔半小时做一次资金清算，可当时IT所拥有的计算资源根本无力承受。经与业务共同讨论，居然彻底改变了业务资金清算方法和制度。不但资金清算更及时，技术实现还很简单。

深入到业务领域，进行专业的对话，就会得到业务方的欣赏和认同。大家在问题的探讨过程中，发现各自认知上的盲区，产生新的行动意愿。期间还会发现许多共同点，有了更多交集，友谊就此加深。