成为会带团队的技术人 - 前阿里本地生活研发总监 - 拉勾教育
前面 5 讲我围绕稳定性、技术债务和大项目管理分享了一些过往的经验与思考，从今天开始，我会用两讲的时间，围绕 “架构设计与系统演进” 与你分享我的经验。这几方面是我认为技术 Leader 在技术工作上一定要做好并且极为重要的，从八二法则上看，它们也是我认为值得花 80% 的精力去做好的，而你能否做好这几点会影响团队未来的发展。
其实对任何一个技术人来讲，“架构设计与系统演进”都不是陌生的话题，早些年 “架构” 还是一个有身份、充满力量的词，很多同学不敢张嘴闭嘴谈 “架构”，但最近几年这个词变得愈发平常，与架构有关的各类书籍、文章层出不穷，而很多文章里都会有这样一个观点：架构要结合具体的业务场景来设计。“结合业务场景” 听起来应该是一件容易的事儿，但据我观察，在自己负责的领域里真正深刻理解业务的技术人凤毛麟角，所以我想专门拿出一讲，和你好好聊一聊 “理解业务这件事”。
为什么技术要理解业务？
产品需求不等于业务诉求
日常工作中，往往产品提出要实现的系统功能未必等于业务想要解决的问题，但是有了一个明确的功能需求再搭配好 DeadLine，大部分技术同学的关注点就会变成：怎么在规定的时间内搞定这个需求。至于为什么要实现这个需求、它能否真正解决业务问题可能就没人关心了，这种情况你肯定不陌生。
有时产品需求就好像说我们要造一艘船，这艘船要满足：载客量 1W、速度 200km/h，能抵抗 10 级海浪，2 个月后完工。技术一看需求这么明确，马上着手实现，开始计划按照标准需要多少钢材、多少工人、几个发动机、船舱结构要如何设计。但是业务上的诉求是造船吗？如果你去找业务的同学仔细了解，可能会发现他的要求是：安全到达对岸。至于你是修桥、造船、开着老爷车绕路他其实并不是那么在意。
虽然我的例子略微极端，但是在实际的开发工作中，如果你不关心需求的源头，不去理解业务，只是低头实现，长此下去，真实的情况会更可怕。
另外，在大部分商业公司中，技术处于价值创造流程的末端（技术团队会被定义为支撑实现的团队），用户的真实需求在到达技术之前会经过业务、运营、产品等多个环节，每一层都会被加工、处理、拆分，技术看到的问题可能距想解决的问题已经很远了，没有搞清楚问题的源头而去解决问题，结果会很糟糕。
同样的，技术 Leader 可能会花时间参加各种会议，尤其是产品需求的会，在会上如果仅仅是听 “自己团队应该做什么”，而没有思考和探究业务的根本诉求，那么就我的经验来说，技术团队不可避免的会成为工具人。Leader 缺乏独立思考，人云亦云，最后整个团队都会被拖累，这也是为什么大多数研发团队被产品以及业务按在地上摩擦的原因！
领域建模的前提是理解业务
在大型互联网公司中，DDD（领域驱动架构设计）是目前的主流，也是微服务落地的最佳实践之一。我们定义领域并且通过 DDD 思想设计服务模型是为了通过一套统一的标准描述业务流程与组成，但业界并没有一个共识的标准去定义，主要是根据经验、主观地设计，其中发挥最大作用的就是你对业务的理解。
以饿了么交易系统为例，熟悉订单系统的同学可能不会陌生，订单作为交易的载体需要承载大量的数据，在一开始，订单系统的演进完全跟着业务需求走，我们发现总有一些数据要存储在订单上，比如商户系统要在订单上加一个标志、营销系统需要在订单上放一个计算中间值…… 之前我们很难判断是否应该让这些数据落到订单上，因为这些系统的研发同学说得也有道理，数据落在订单上可以少几次调用，可以根据订单号便捷地获取。但是早期订单系统并没有做好对应的冗余设计，所以这些信息都存储在一个无法管理的 JSON 字段中，给我们带来了数不尽的麻烦。
我们复盘后发现，出现这个问题表面上看是系统设计和实现不够好，但是根本原因是没有在深度理解业务的基础上对交易系统进行建模，确定边界与能力范围。如果可以更早地设计好交易模型，拆分正逆向交易，将订单场景、类型配置化实现，设计好标记数据的存储结构，那么很多问题都不会发生。
正因为没有仔细看业务的现状、推测业务的发展、去思考业务上对交易的诉求，我们认识的只是一个个需求，而非整体的从业务维度思考系统的设计，导致系统复杂度越来越高。所以要想设计可靠、简单、真正可持续迭代的系统，深度理解业务就是前提，你对业务的理解程度影响了你对系统未来发展的预判程度。
提升技术团队的使命感
最后，我认为通过理解业务可以让团队的同学进一步了解自己工作的价值和意义。技术同学对业务的直观感受大多来自线上的产品和系统，这和直接接触用户有很大差别，就好像有些设计你可能觉得不那么好，但如果有用户打电话过来投诉，你才能真的意识这个 “不那么好” 有多糟糕。
我之前负责的技术团队会定期安排同学在客服中心听线，然后与一线的客服人员直接沟通痛点，往往技术同学会受到来自用户和客服的双向暴击。比如营销系统研发的同学，可能一边用户会责问为什么某个红包无法使用、为什么系统优惠计算的金额和自己算的不一样，另外一边客服同学也在抱怨优惠信息查询复杂、不同红包的互斥规则在系统中没有体现等。技术同学一边收集问题，一边真实地与这个世界交互，而不是写完一段代码提交发布就结束了。
这种感知到自己的代码对真实世界产生影响进而生成的同理心是非常关键的，当你能清晰且直观地感受到：你写的每一行代码，线上的每一次发布，都会改变用户的体验，解决实际的问题，你就会发现这份工作的意义。
如何理解业务？
根据我的观察，很多 Leader 之所以能在技术组织中崭露头角，除了技术功底扎实之外，对业务的熟悉和理解也占了很大因素，尤其是阿里这样 “尊重技术的公司”，P7 以上的技术人员能否晋升，深度理解业务很重要。而且级别越高，对你理解业务的程度要求也越高，可能你觉得理解业务并不难，某个领域的系统做久了，自然而然就了解了，但了解、熟悉和深刻理解不能混为一谈，这里面还有深度与广度之分。
很多人一开始对饿了么的理解就是一个送外卖的公司，觉得系统的架构和设计与电商会很类似，送外卖这么件小事儿能有多复杂？可能这些同学在饿了么上点过餐，加之这是一个 To C 的业务，在流程和操作上看起来也并不复杂，所以推理出背后的系统应该不难。
但实际身处其中的感受可能会完全不一样，我们常说看得见的都是最简单的，难的东西都藏在背后。过千万的订单、数百万商户和骑手，这背后是一整套业务体系和复杂的系统支持，餐厅和餐品的数字化、交易流程包括商户和骑手并且时效性要在 30 分钟以内、营销补贴长年持续不断，种种业务上的差异在系统上的体现会更加明显。单是一个骑手调度就包含了业务、商业、技术等多个角度的博弈，所以远观一个个业务只能说是知道，近观乃至下场去看、去做、去思考和尝试才能说是真正理解。关于理解业务我有三个小的建议：
不要盲信产品
借用雷军的话：永远不要试图用战术上的勤奋，去掩盖你战略上的懒惰。这句话形容大部分的 PD 再贴切不过，厉害的 PD 很多，“说起来厉害的 PD” 就更多了，他们从业务方接收需求描述说明，然后简单加工成 PRD，再根据业务方的嗓门大小进行优先级的排序，最后直接输出给技术。
我对技术同学尤其是技术 Leader 的建议是： 不要盲信产品与 PRD，在讨论 PRD 和执行开发任务之前学会独立思考，深入理解业务想要解决什么问题，需要什么效果或作用，严格把控那些伪需求和无价值需求，防止它们侵占团队的技术资源。
要知道，如果 PD 已经退化成一个 PPT Designer 和业务需求的传话筒，那你就更不能让技术同学充当需求的实现机器，不然技术会陷入无价值的需求中，很难创造自己的价值，这也是为什么很多技术团队没时间偿还技术债务、业务节奏停不下来的原因。你要去看业务想要什么、处于一个怎样的环境、为什么想做这件事儿，把自己作为半个业务同学去理解业务，这样才能找到技术与业务平衡的空间。
建立走进业务的机制
技术领域 90% 的事情可以在理论层面证伪，10% 的事情在意料之外需要遵守墨菲定律，大体上还是可以通过数据来判断。但在业务领域，并不是所有的内容都可以通过数据判断对错，技术同学去理解业务，就是应该加强对业务的认知和体感，毕竟大家日常的思维方式已经很结构化和数字化了，更需要在理性之上去建立感性那部分。
最简单的方法就是代入用户视角，去实际地体验一下，看一看具体的服务、感受和业务流程是怎样的。滴滴就建立了走进业务的机制，滴滴的朋友曾经和我提起过这样一件事儿：他们内部有一个打车体验改进的机制，每个月选取一些同学，并给予他们一定的打车报销额度，这些同学将日常打车的体验总结下来，觉得哪些比较好、哪些比较糟糕，然后统一反馈给专门的同学，之后会按照问题的分类在业务流程上形成一个个实际的需求，由运营、产品、业务一起去解决。
饿了么也是这样，我们也会定期到某个城市去和市场 BD 的同学一起走访商户，或者作为骑手去餐厅取餐送餐，以此体验业务上的细节。比如走访商户后我发现如果营销系统比较复杂，大部分商户的使用成本就会增高，使用的意愿就会降低，往往商户只会用满减和红包几个简单的玩法；我之前在珠海体验送餐，因为珠海禁止电动车所以只能自行车送餐，每一公里都累得想吐，那时你才会发现派单系统有多么关键。
在技术团队你也要建立走进业务的机制，因为实际去体验业务会让你建立很强的认识感与同理心，还能发现一些痛点问题。你从统计数字上看一个骑手一天可以送 20 单，和你真的作为骑手一天去送 20 单，那个感觉是完全不一样的。只有站在他们的角度你才能看到他们的痛点，才会思考技术是不是能解决这些你原本未必知道或关注的问题，这就是业务同理心。
当然，我也想提醒你，不要让业务机制成为 “一次性作秀”，最好有一个低成本可持续的机制，而不是仅仅是为了走个形式到业务侧打个卡。要带着发现问题、解决问题的想法走进业务。我建议你从客服入手，成本低、效果好、每次都带着任务来也带着问题走，很容易就形成一个可持续的循环。
业务上多参会多画图
可以适当参加业务会议，比如运营、客服、BD 的月度复盘会，或者给老板做的业绩汇报会，定期与产品一起参加业务需求的评审会，从源头来看业务方想解决的问题是处于一个怎样的背景。
另外，如果说技术了解系统，梳理架构是通过画各种架构图和系统链路图，那么对于业务同样可以结合自己的整理去画业务流程图。技术视角的业务流程图并不需要特别复杂，也没必要一定遵守某个标准范式，只要能将 “谁在、在什么时候、做什么、产生什么变化” 这些画明白就可以了。比如饿了么点餐的交易流程图，可以简单画为：
技术人员梳理业务流程图时还有一个优势就是可以借助系统和数据来辅助你理解，因为系统是你做的所以你非常清楚数据流是怎样的，中间发生了什么变化，通过追踪数据来研究每一步的处理逻辑进而理解业务的处理步骤。
同时，你可以将自己的理解分享给团队的其他成员，对一个团队而言，最好的改变肯定是从个体到集体，你一个人认识、熟悉、理解业务还不够，还要让整个团队认识、熟悉和理解业务，这样才会让系统和产品产生质变。在这个过程中也会让团队成员建立正确的认知，让成员明白理解业务与编码交付同样重要，这样一来，其他人也会有意识地去关注业务的变化、去了解业务的现状。试想如果团队中每个人都对某一部分业务了解很深，大家就可以通过各自分享的方式组合成一个完整的业务认识。道理与熟悉系统、分析架构是一样的，重要的是形成这种认识和氛围。
小结
这一讲我和你分享了理解业务的重要性和一些小的建议方法，希望你意识到理解业务对实际工作会有巨大的帮助。并且理解业务并不是嘴上说说或者参加一两次业务会议就够了，你要先在心里意识到理解业务的重要性和收益，然后愿意像研究代码一样去琢磨业务是如何运作、接下来可能会怎样发展，并且将这些思考和对业务重要性的认识反复传达给团队。
技术人深刻地理解业务所产生的结果是 “1 + 1> 2” 的，很多时候业务乃至产品认为只能通过 A 方案来解决的问题，可能在你眼里还有 B、C、D 的方案，或者更清楚不同方案的利弊与取舍，因为懂技术可以带来无限的可能。
留个作业：你对当前负责的业务是如何理解的？如果你团队有新成员，你会通过何种方式帮助他快速理解你们的业务？
若有收获，就点个赞吧
0 人点赞
