发帖
雷达卡
文章目录
- 为什么技术要理解业务？
- 产品需求不等于业务诉求
- 领域建模的前提是理解业务
- 提升技术团队的使命感
- 如何理解业务？
- 不要盲信产品
- 建立走进业务的机制
- 业务上多参会多画图
- 小结
前面 5 讲
围绕稳定性、技术债务和大项目管理分享了一些过往的经验与思考，从今天开始，我会用两讲的时间，围绕“
架构设计与系统演进其实对任何一个技术人士而言，“架构设计与系统演进”都不是陌生的话题，早些年“架构”还是一个有身份、充满力量的词汇，很多同学不敢随意谈论“架构”，但最近几年这个词变得越来越普通，与架构相关的各类书籍、文章层出不穷，而许多文章里都会提到这样一个观点：
架构要结合具体的业务场景来设计“结合业务场景”听起来似乎是一件简单的事情，但据我观察，在自己负责的领域里真正深入理解业务的技术人员非常少见，因此我想专门拿出一讲，与你详细探讨“理解业务这件事”。
为什么技术要理解业务？
产品需求不等同于业务诉求
日常工作中，通常产品提出要实现的系统功能未必等于业务想要解决的问题，但是有了一个清晰的功能需求再配上合理的截止日期，
大部分技术同学的关注点就会变成：怎么在规定的时间内搞定这个需求。至于为什么要实现这个需求、它能否真正解决业务问题可能就没人关心了，这种情况你肯定不陌生。
有时产品需求就像是说我们要建造一艘船，这艘船要满足：载客量1W、速度200km/h，能抵御10级海浪，2个月后完工。技术人员一看需求如此明确，立即着手实施，开始规划所需材料数量、工人人数、发动机数量、船舱结构设计等。但是业务的诉求真的是造船吗？如果你与业务同事深入交流，可能会发现他们的要求其实是：安全抵达彼岸。至于你是建桥、造船、开车绕行，他们其实并不十分在意。
尽管我的例子有些极端，但在实际开发过程中，如果你不关注需求的根源，不去理解业务，只是埋头实现，长期下来，实际情况会更加严重。
此外，在大多数商业公司中，技术处于价值创造流程的末端（技术团队常被视为支持实现的团队），用户的真实需求在到达技术部门前会经过业务、运营、产品等多个环节的加工、处理、拆解，技术看到的问题可能已经远离最初的问题，没有弄清问题的根源就去解决，后果将非常糟糕。
同样，技术 Leader 可能会花费时间参加各种会议，特别是产品需求的会议，在会议上如果仅仅听取“自己的团队应该做什么”，而不思考和探究业务的基本诉求，那么依我的经验，技术团队不可避免地会沦为工具人。领导者缺乏独立思考，随波逐流，最终整个团队都会受到影响，这也是大多数研发团队被产品和业务压制的原因！
领域建模的前提是理解业务
在大型互联网企业中，DDD（领域驱动设计）是当前的主要趋势，也是微服务实施的最佳实践之一。我们定义领域并通过 DDD 理念设计服务模型，旨在通过一套统一的标准来描述业务流程和组成部分，但业界并没有一个公认的定义标准，主要依赖经验和主观判断，其中最关键的是你对业务的理解。
以饿了么交易系统为例，熟悉订单系统的读者可能不会感到陌生，订单作为交易的载体需要承载大量数据，在初期，订单系统的演进完全跟随业务需求，我们发现总是有些数据需要存储在订单上，例如商户系统希望在订单上添加一个标志、营销系统希望在订单上放置一个计算中间值……之前我们很难决定是否应将这些数据存储在订单上，因为这些系统的开发者说得也很有道理，数据存储在订单上可以减少调用次数，方便根据订单号快速获取。但由于早期订单系统未能很好地设计冗余，这些信息都被存储在一个难以管理的 JSON 字段中，给我们带来了无尽的麻烦。
回顾分析后发现，这个问题表面上是系统设计和实现不够完善，
但是根本原因是没有在深度理解业务的基础上对交易系统进行建模，确定边界与能力范围
正是因为没有细致观察业务现状、预测业务发展、思考业务对交易的需求，我们认识的只是一个又一个的需求，而非从整体业务角度思考系统的设计，导致系统复杂度不断增加。
所以要想设计可靠、简单、真正可持续迭代的系统，深度理解业务就是前提，你对业务的理解程度影响了你对系统未来发展的预判程度。
提升技术团队的使命感
最后，我认为通过理解业务可以让团队成员更深入地了解自己工作的价值和意义。技术成员对业务的直观感受大多来自于线上产品和系统，这与直接接触用户有很大不同，就像有些设计你可能觉得不那么理想，但当有用户打电话投诉时，你才会真正意识到这种“不理想”的严重性。
我过去领导的技术团队会定时安排成员在客户服务部门监听，随后与一线客服直接交流问题所在，通常技术成员会遭遇来自用户和客服双方的挑战。例如，参与营销系统开发的成员，一方面用户会质疑为何某红包不可用、为何系统计算的优惠额与个人计算不符，另一方面客服人员也会诉苦优惠信息查询繁琐、不同红包的互斥规则未在系统中明确等。技术成员在收集问题的同时，也真切地与外界互动，而非仅完成代码编写和提交。
这种意识到自己的代码对现实世界产生影响而形成的共情能力极为重要，当你能够清楚且直接地体会到：你编写的每一行代码，每次线上发布，都会影响用户体验，解决实际问题时，你就能深刻感受到这份职业的意义。
如何理解业务？据我观察，许多领导者之所以能在技术团队中脱颖而出，除了具备坚实的技术基础外，对业务的深刻理解和熟悉也是一个重要因素，尤其在像阿里这样的“重视技术的企业”中，P7以上级别的技术人员是否能晋升，很大程度上取决于其对业务的深入理解。而且，职位越高，对业务理解的要求也越高。
可能你觉得理解业务并不难，某个领域的系统做久了，自然而然就了解了，但了解、熟悉和深刻理解不能混为一谈，这里面还有深度与广度之分。许多人最初认为饿了么只是一个外卖配送公司，觉得其系统架构和设计与电子商务类似，认为送外卖这么简单的事情能有多复杂？或许这些人在饿了么订过餐，加上这是一项面向消费者的业务，在流程和操作上看似不复杂，因此推测背后的系统也不难。
然而，实际参与其中的感受可能完全不同，我们常说表面看起来简单的事情，困难的部分往往隐藏在其后。数以千万计的订单、数百万商家和骑手，这一切的背后是一整套业务体系和复杂的系统支撑，包括餐厅和菜品的数字化、交易流程涉及商家和骑手且需在30分钟内完成、长期持续的营销补贴等，这些业务差异在系统上的表现尤为显著。单单一个骑手调度问题就涉及到业务、商业和技术等多个方面的考量，因此，远距离观察业务只能说了解，近距离参与、实践、思考和尝试才能说是真正理解。关于理解业务，我有三点建议：
不要盲目信任产品
引用雷军的话：“永远不要试图用战术上的勤奋掩饰你在战略上的懒惰。”这句话用来形容大多数产品经理再合适不过，优秀的产品经理有很多，而“自认为优秀”的产品经理则更多。他们从客户那里接收需求描述，稍加修改成产品需求文档，再根据客户的诉求强度决定优先级，最终直接交给技术团队。
我对技术同学尤其是技术 Leader 的建议是： 不要盲信产品与 PRD，在讨论 PRD 和执行开发任务之前学会独立思考，深入理解业务想要解决什么问题，需要什么效果或作用，严格把控那些伪需求和无价值需求，防止它们侵占团队的技术资源。
要知道，如果产品经理已经沦为PPT设计师和客户需求的传声筒，那么技术成员就不能被当作需求实现的工具人，否则技术将陷入无价值的需求中，难以发挥自身价值，这也是许多技术团队没有时间偿还技术债务、业务节奏无法停止的原因。你应该去了解业务的目标、所处的环境、为何要做某事，把自己当作半个业务成员来理解业务，这样才能找到技术和业务之间的平衡点。
建立深入业务的机制
技术领域90%的问题可以在理论上得到验证，10%的问题则遵循意外原则，大致上仍可通过数据分析来判断。但在业务领域，并非所有内容都能通过数据判断正误，技术成员理解业务，就是要增强对业务的认识和感知，毕竟大家平时的思维已经非常结构化和数据化，更需要在理性之上构建感性的部分。
最简便的方法是换位思考，亲自体验服务，看看具体的服务、感受和业务流程是怎样的。滴滴就建立了深入业务的机制，一位滴滴的朋友曾向我提及，他们内部有一个改善乘车体验的机制，每月挑选一些员工，并提供一定的乘车费用报销额度，这些员工将日常乘车的体验汇总，指出哪些方面做得好、哪些不好，然后统一反馈给专门的同事，之后按照问题类别在业务流程中形成具体需求，由运营、产品和业务团队共同解决。
饿了么也是如此，我们会定期前往某个城市与市场BD的同事一起走访商家，或作为骑手去餐馆取送餐，以此体验业务的细节。例如，在走访商家后，我发现如果营销系统过于复杂，大多数商家的使用成本会增加，使用意愿降低，通常商家只会使用满减和红包这类简单的促销方式；我在珠海体验过送餐，由于珠海禁止电动车，只能骑自行车送餐，每公里都感到疲惫不堪，那时才体会到派单系统的重要性。
在技术团队你也要建立走进业务的机制，因为实际去体验业务会让你建立很强的认识感与同理心，还能发现一些痛点问题从统计数据上看，一个骑手一天可以送20单，但如果你亲自作为骑手一天送20单，那种感受完全不同。只有站在他们的立场，你才能发现他们的痛点，并思考技术是否能解决这些问题，这就是业务共情。
当然，我也想提醒你，不要让业务机制变成“一次性的表演”，最好建立一种低成本且可持续的机制，而不是只是为了形式上的参与。应带着发现问题和解决问题的心态深入业务。我建议从客服开始，成本低、效果好，每次都能带着任务来，带着问题离开，容易形成可持续的循环。
多参加业务会议，多绘制业务图
可以适度参与业务会议，例如运营、客户服务、商务拓展的月度总结会，或是向领导汇报业绩的会议，定期与产品经理一同参加业务需求的评估会，从根源了解业务方希望解决的问题所处的背景。
此外，如果技术部门通过绘制多种架构图和系统链路图来理解和梳理系统架构，那么对于业务，同样可以通过自己整理绘制业务流程图来加深理解。技术角度的业务流程图无需过于繁琐，不必严格遵循某种标准规范，只要能够清晰表达“谁在何时做了什么，产生了何种变化”即可。例如，饿了么订餐的交易流程图，可以简化为：
技术人员梳理业务流程图时还有一个优势就是可以借助系统和数据来辅助你理解，因为系统是你做的所以你非常清楚数据流是怎样的，中间发生了什么变化，通过追踪数据来研究每一步的处理逻辑进而理解业务的处理步骤。同时，你可以将个人见解与团队其他成员分享，对团队而言，最理想的转变是从个人到全体的提升。仅你自己认识到、熟悉并理解业务是不够的，还需使整个团队都具备同样的认识、熟悉度和理解力，这样才能促使系统和产品发生实质性的改进。在这个过程中，也能帮助团队成员树立正确的观念，让他们意识到理解业务与编码交付同等重要。如此一来，团队中的每个人都会自觉关注业务动态，深入了解业务现状。设想若团队中每位成员对业务的某一环节都有深刻的理解，便可通过彼此交流，共同构建出全面的业务认知。这与熟悉系统、分析架构的原理相同，关键在于形成这样的认知和氛围。
小结
在这次讨论中，我与大家分享了理解业务的重要性和一些实用的小建议，希望你能认识到理解业务对实际工作的巨大助力。理解业务不仅仅是口头上的承诺或偶尔参加几次业务会议就能实现的，首先要在内心深处认识到理解业务的价值和益处，接着愿意像钻研代码那样深入研究业务的运行机制及其未来的发展方向，并不断向团队传达这些思考和对业务重要性的认识。
技术人深刻地理解业务所产生的结果是“1 + 1 > 2”的，很多时候业务乃至产品认为只能通过A方案来解决的问题，可能在你眼里还有B、C、D的方案，或者更清楚不同方案的利弊与取舍，因为懂技术可以带来无限的可能。
留个作业：你对目前负责的业务有何理解？如果你的团队中有新加入的成员，你会采取什么方法帮助他们迅速掌握业务知识？
精选评论
8904：BD具体指的是什么含义呢？
讲师回复：business development，通常指的是前线业务人员，直接对接商家的，比如以前饿了么的业务人员
涛：非常赞同，业务同理心非常重要，理解起来有点像广义上的用户体验
春：完全同意，业务可能表面上要的是匹马，但其背后的真正需求可能是一辆车
讲师回复：确实如此，业务的需求与技术实现之间总有一个匹配的过程，多一点或少一点都不行
注：本文来自拉勾教育《成为会带团队的技术人》课程资料，撰写此文主要是为了记录学习笔记，如有版权问题，请联系删除。
京公网安备 11010802022788号
