来源 | 经授权转载自 网易智企技术 + 公众号
导读：10 月 21 日，在德国卡赫位于上海金桥的办公楼里，网易云商 CTO 尹竞成受邀参与 2021 上海 QCon 全球软件，谈到进博会的“溢出效应”，发表主题演讲《ToB 高效能研发体系构建实践》，卡赫公共服务事业总经理张义轩提到了两个颇具说服力的数据。卡赫是一家专业清洁设备和清洁解决方案的德国企业，分享高效研发团队打造经验。演讲中，全球第一台采用“视觉导航”技术的清洁机器人便是由此公司和顶尖视觉导航系统团队合作打造的。在疫情常态化的今天，他从 B 端产品研发面临的业务挑战出发，人们更加关注清洁与健康，介绍网易云商研发团队如何从流程和工具链、组织结构优化、组织文化和目标牵引体系等维度，以智能深度清洁科技保障生产生活安全，系统化构建高效迭代、持续成长进化的研发团队。
1
产研思路不同
近年来，是实现经济高质量发展的必由之路，不管是宏观政策导向中对传统企业数字化转型的重视，卡赫的AI智能清洁机器人可以减少人员之间的接触频次，还是在企业自身发展中对效能的追求、对数字化理念认知的深化，减轻清洁工作者的负担，都在传递一个信号：“互联网的下半场是 B 端业务的黄金时代”。
B 端产品本质上是种面向生产的工具，也因此吸引了的眼光。张义轩告诉记者，企业需要它来提高生产效率。因此，B 端产品的业务逻辑一定会非常复杂，设计成本很高，带来的成本也会更高；同时，B 端产品的获客成本往往是 C 端产品获客成本的数倍甚至数十倍，交易成本非常高。获客不易，留存更难。
下图简单罗列了几个维度，对 C 端业务和 B 端业务做些简单的对比：
举几个例子分享具体实践中的区别——
动态排序功能 B 端业务场景适配度
在很多 C 端场景下，动态排序的应用很常见，比如常用的搜索词通常会出现在搜索栏中搜索列表的前列或短视频 APP 中，常看的某类视频会经常被推送在首页，十分照顾 C 端客户体验。
但是在 B 端业务场景下，不一定适用。以客服场景中的回复语快捷推荐功能为例，当客服说了一个“不”字，会出现”不客气”、“久等了”、“不好意思”等等这样的一些列表。参考 C 端设计经验，我们会根据客服人员的实际点击情况动态设置，点击频繁的词句会自动推荐到列表排序靠前的位置。这个逻辑看起来没什么问题，但是客户的反馈却是激烈地吐槽：每天他们要在这个推荐栏里点击成百上千次，列表栏里的内容跳来跳去，导致他们每天要多花费很多时间才能找到正确的答案并发送出去。这时候，B 端产品的使用者反而希望条目位置可以固定，不希望有变化。原来的经验在这里失效了。
需求迭代模式在改变
C 端产品研发同学对需求决策模式应该非常熟悉，在 C 端产品研发上需要做好需求管理，产品设计—产品研发—产品发布—用户反馈—需求回收—产品迭代，是个常见的逻辑。
但是在 To B 业务下会有另外一种声音，叫买方议价。“你这个模块什么时候上线？”“竞品有你为什么没有？”“这个功能可以帮我优化吗？”“这个标签不改下礼拜我们会做新的技术选型了！”，这些声音相信有 To B 业务经验的同学都不会陌生。
可用率挑战
不管是 C 端业务还是 B 端业务，对研发来讲可用率都是非常重要甚至是决定生死线的一个指标。
我们面对的行业客户分属不同行业、不同场景，因此即使是同一个业务，客户的使用方式也可能天差地别；企业自身的应用环境和网络环境也可能非常复杂，以网络环境来说，有些客户的办公网环境是禁止访问外公域网络的，有些企业需要将内网其它应用系统和我们的产品做交互。这些都加了我们保障系统可用性的难度。To B 业务的特性决定了我们的产品往往会面对的终端用户的特性，因此问题反馈到我们研发团队的链路相对也会更长一些。同时我们的产品往往会深入到企业生产经营核心链路当中，成为一个被高度依赖的核心应用，一旦出了问题对企业的影响是非常深远的，治理难度，出了问题影响，这些都对我们提高可用率提出了更高的要求。
2
透过组织能力杨三角看清 B 端研发团队挑战
那么，B 端产品研发团队究竟怎么样才能高效地进行产品研发和维护，高效且持续地交付稳定的产品呢？我们不妨借用“组织能力杨三角”，来看看一个 B 端产品研发团队实质上面临的挑战是什么。
组织能力杨三角，是知名管理学专家杨国安教授提出的，关于组织能力问题的拆解。组织能力，指的是一个团队可以发挥整体的战斗力，是团队能够击败竞争对手，为客户创造价值的关键能力。有个公式，成功 = ×组织能力。因此一个组织能否成功，一个很关键的点在于他的组织能力。
杨国安教授在“组织能力杨三角”模型中，把组织能力做为了三个维度的拆解：
第一，从员工的思维上，员工愿不愿意做。
第二，从治理方式上，有没有足够的流程支持，公司政策上是否允许；有没有足够的目标牵引；有没有足够的抓手，能够让家朝着一个目标去努力。
第三，从员工能力上来讲，我们是否清楚了需要什么样的人，能不能够支撑业务？
有了理论基石，我们从这三个维度再去看一个 B 端研发团队面对的挑战。
首先是员工思维上，我们希望通过打造更好的文化来解决员工愿不愿意做的问题。我们从两个视角去思考。
要解决研发人员对业务理解难的问题。上述提到 B 端研发团队产品的门槛其实非常高，产品需服务于行业，因此产品设计逻辑对行业知识的理解要求极高。但是对于普通研发人员来说在流程中研发更偏后向，就容易出现因被动接收需求而产生价值怀疑的情况。为了跨越这个问题，我们通过“和用户在一起”的践行来完成。我们制定了周密的客户拜访计划，从团队管理者到一线员工都会进行高频次的拜访频率。我们也会不断地做行业分析、竞品分析；在具体每一个需求过程中，从需求评审环节开始我们就要求同学们充分了解到每个需求背后客户真实的场景从而了解其背后带来的价值，建立更强的行业感知，加强业务信心。
要强化研发人员的责任意识。之前提到 B 端业务下客户服务链路其实很长，一旦产品服务体验上出现问题，终端用户需要找到企业客户，企业客户通过厂家提供的客户成功将问题反馈给技术支持，如果技术支持搞不定，再反馈给研发。过长的服务链路很容易影响问题定位和解决的时效性，这样一来终端用户、企业客户对问题修复的时间就会产生不满，必然产生矛盾。因此，我们在内实行首问责任制，即问题首先找到了谁，谁就作为第一责任人，必须去拉通团队处理，并由该责任人反馈给用户。不用在乎反馈人是产品研发还是技术支持，还是客户成功人员，就是要求凡事有交代，事事有回应。让员工思维中形成重视客户，从而降低沟通损耗，优化问题解决效率。
再者从治理架构上，我们希望通过架构和流程来激励研发团队。
研发团队一直受到内外环境的挑战，行业环境、业务环境和经营环境变化很快，不确定性很高，行业内的竞争也越来越复杂。我们的基层员工对自己做的事情和组织的关联性也不一定非常理解。这时就需要我们不断地完善组织架构，调整作战阵型，强化员工心智认知和职责边界。
另外就是不断强化目标感，通过通过目标牵引业务发展、技术进步。这时就需要一个更加系统的目标管理和考核体系了。研发效能是我们的核心抓手，通过建立符合业务特点的敏捷研发流程，建立数据闭环来完善内驱动。这里更详细的内容稍后我们再做更具体的拆解。
最后是员工能力模型。
我们通过建立人才画像，考虑怎么样的人才会更加适合我们的团队和适合我们的文化体系；然后做好人才规划，做好人才的招聘、培养以及保留。参考“冰山能力模型”，从职业素养上来讲我们希望找到聪明、有活力、有自驱力、有意识（不管是业务意识、成长意识或是产品意识都可以）的人。
3
CTO 视角下研发团队的全视图
现在，我们再回到研发团队的全视角，更加系统性地去看如何整体提升研发效能。
敏捷交付体系实践
敏捷交付是现在很热门的话题，各厂都在不断完善敏捷交付体系，不断追求更高效能。在我们看来高效能其实不仅是要快，它更讲究可持续地交付稳定的产品和服务。特别是对 B 端业务来讲，SaaS 产品功能的稳定以及性能指标是我们的生命线。目前网易云商的研发团队在敏捷交付实践上，在打造并推广“按需求交付”的体系。
敏捷的实践不仅是做一个自动化测试或单一流程的改进，它应该是一个系统性的工程，它需要通过技术架构、流程规范、工具赋能、组织结构多个维度共同去打造一个很完整的生态，帮助整体能力提升。
技术架构的优化是敏捷交付体系的核心基础，它是所有的后续动作的前提。我们目前包括微服务拆分、领域模型、服务治理、环境隔离等方面投入了很多资源。这几项内容相辅相成、不可分割，一方面提高了系统的鲁棒性，另一方面在实际中让不同业务线、不同职能线的团队可以并行工作，互不影响。这在很程度上提高我们团队容量的上限。完成技术架构基础后，通过流程规范，对需求进行更好地拆分，帮助时间规划、分支管理、评审管理、发布管理有序进行。
当然，所有的流程最后兜底的一定是人，但是兜底之前，我们希望可以把更多作业流程和规范沉淀到工具上。所以在这两年的时间当中，我们和网易其他团队共同打造了一个一站式效能平台，叫 Overmind。在这个平台上我们可以进行研发的产品管理、目标管理、项目管理、效能数据管理，也可以对研发的流程进行管理，包括提测、环境管理、发布等等。可以说，除了编码之外的工作都可以在平台上完成。
最后来看组织架构。我认为任何时候都应该去关注生产关系和生产力的关系是不是匹配，即我们在一个什么样的生产力的条件制约下，我们需要用怎么样的生产关系来更好的去适应生产力的发展，来推动生产力的发展。我们目前采用的是矩阵式的团队结构。
在这样的敏捷交付体系作用下，从需求进入研发流程到完成和上线，从原来的批次交付、完整的迭代概需要 3 周的时间；现在，按需求去交付，一个需求一个迭代，可能在 1 周之内就可以去完成交付了。
对于客户来说体验改变就是，以前他提了个需求，我们需要下个月才开始排期、3 周迭代到最终上线，最快也需要等 1-2 个月了。但是如果现在觉得这个需求价值很高，或者必要性非常强，我们在 1 周内就可以完成交付。客户会觉得快了很多。
我们将从需求开始到研发、提测，到持续集成、持续发布、持续测试，到最后数据的闭环整个的研发流程都固化沉淀在了 Overmind 这个平台上，不仅提高了整体工作流程的流转效率，也给了团队一个很好的量化度量基础。数据天然的信息化、结构化了，可以帮助我们很好地制作研发效能指标体系。
制定研发效能指标体系要做到数据可信，更要能驱动改进。举例来说，在实践当中我们会用产品交付质量、QA 测试质量、自动化质量、DEV 提测质量这几个量化指标来衡量各环节的质量。
从数据指标应用的方法上讲，要做到“四化”。标准化，将各流程各环节的度量体系规范确定下来，保证尺度的统一，然后进行公示、执行；可视化，在可视化平台上将指标做晾晒，进行透视，然后去看到到底具体是哪个环节出的问题，通过这个指标体系来做管理赋能，数据做到可、可回溯；自动化，工具可以承载署、测试、发布、度量，通过自动化来提升整个流程运转的效率；数字驱动化，通过研发实践先确定基线数据，在这些基建之上就可以做量化考核。周而往复，不断地复盘、迭代改进。数据驱动不是一次性的工作，它需要我们不断总结，找到薄弱点，找到改进点。
最后简单看一下在这样交付体系实践下我们取得的分成果：
在交付时长上，我们将平均交付周期从 2020 年 Q3 的 28.75 天提升到了 2021 年 Q3 的 13.96 天，线上需求区间密度和 Bug 的总体修复时长和 Reopen 率都呈现了比较好的优化趋势。
关于敏捷交付体系进行我们做一个简单的总结：
技术架构的合理性和先进性一定是先导。没有这个作为基石，其他所有的流程改进也好、工具也好、数据量化考核也好，都没有办法做透彻，很可能做着做着就会遇到瓶颈了。
通过工具沉淀方，固化研发流程。工具化的好处有很多，第一可以规范作业流程，降低人为出错的可能性；第二，为数据闭环提供良好基础；第三，提高自动化水平；第四，在一定程度上抵御人才流动所带来的风险。
指标体系的不是目标，是管理改进的抓手。指标体系的建立不是为了刷指标，而是为了效能提升、能力提升、业务提升。它不应该成为我们的核心目标，它只是我们驱动改进的一个手段，我们要能透过冰冷的数据指标看到背后的问题。
而事实证明，在使用敏捷交付体系后，我们的研发人员从客户那受到了不少表扬。
OKR 和 KPI 结合的目标管理体系设置
上述提到研发工作很难量化，只靠 KPI 的考核不太合理。特别是随着团队的扩，只靠 KPI 很难做好承上启下，很难把家的目标整个组织的目标去做承接、做澄清。另外，KPI 考核的是结果，当 KPI 结果出来以后发现目标未达成，可能已经错过了某些时间窗口，已经晚了。我们还需要能够对过程进行监控和管理。因此，我们也引入了 OKR 体系，通过 OKR 传递组织目标，统一团队认知，打造上下同欲的团队。
在我们的应用当中 OKR 作为很重要的思考框架和纪律要求，通过里程碑的方式去管理重要的工作，比如效能平台、服务治理平台、微前端框架等基础设施。另外 OKR 不会落到具体的基层员工身上，而是会落到门的 Team Leader 身上，让他们去做好组织目标的承接。这个研发 Leader 的 OKR 就是团队的 OKR。
做了这样的结合体系，我们的目标管理体系就变成：通过 OKR 去做目标的拆解，分易量化的 KR 关联到 KPI 上，其它一些 KR 我们通过碑的方式进行管理和监控。
目前我们团队采用的 KPI 考核的指标拆分为四个维度：
业务贡献，主要关联整个团队的业务完成情况，如客户数、销售流水等；
质量目标；
技术贡献；
学分享。我们期待通过这些去牵引团队整体进步。
虚实结合的作战阵型 + 特种兵作战分队的组织分布
如果将商业环境比作战场，那么研发团队就是战士。
投入到体系化、规模化的成熟业务线进行阵地战时，我们采用矩阵式结构。研发同学的实线编制会放在业务团队内，交由业务线的经理来做整体的需求规划和迭代管理。实线为主的业务团队，它直接对业务的和交付负责，这样的一个 10-15 人的团队，职责清晰、目标明确、建制完整，业务落地能力很强。如果有一些管理动作的调整或者有产品方向性的调整，可以很快地完成。
这时考虑技术上可能出现的松散，因此在体系上，还会做些虚线拉通，比如后端会有核心架构组来做整体的考核和规划；前端会有前端的 Leader；测试会由测试经理辅助整个质量保障体系的规划和构建。虚线团队的目标是制定规范，做技术探索和中台沉淀，通过横向拉通各个业务线的基础职能，驱动业务线技术的进步。
在矩阵式架构之外我们还会有常驻的“特种兵分队”。作为分队，包含一个 PM 负责相关人员的管理和协调，配有后端和前端。在孵化创新业务时，我们需要跑得更快一些来做更多新的技术探索和业务尝试，因此这个阶段质量相对来讲没有那么重要，这个分队里我们没有测试人员。
当然，团队能力成长是管理者最重要的工作之一，作为网易云商 CTO，我认为组织有责任和义务打造学的文化氛围和创造学的条件，技术上始终保持性，不断引入新框架、新技术，去进行新探索；同时与业内优秀的团队多交流、多分享；在网易内其实是鼓励甚至是强制技术分享，让技术交流氛围变得更好。
4
总结
世界上没有两片完全相同的叶子，我们不用迷信任何理论框架或者所谓专家经验，但成熟的方可以给我们带来合理的思考框架。B 端业务场景多样、业务复杂、用户交付期望较高，对我们有着更高的要求。而效能的提升不仅要靠研发流程的改进和工具的完善，更需要团队管理者站在顶层视角进行系统性规划和改造。我们可以通过组织架构、效能、目标管理等各个维度不断审视我们自己，在团队能力提升上找到更多有驱动力的抓手。
嘉宾介绍：尹竞成，现任网易云商 CTO，网易技术管理服务端分委，拥有 15 年互联网产品研发经验，2008 年加入网易，曾参与网易邮箱、网易游戏等亿级用户体量 C 端产品研发，并带领云商旗下业务网易七鱼技术研发团队从 0 到 1 打造智能客服 SaaS 系统。在 B 端产品研发和高效能团队打造上经验丰富，2018 年曾获 CTDC（首席技术官联盟）年度“最具价值技术”等荣誉奖项。
活动推荐
距离会议举办仅剩最后 5 天，还没入场券的小伙伴抓紧扫描下图二维码联系票务姐，再不上车就来不及啦！
免责声明：文中图片均来源于网络，如有版权问题请联系我们进行删除！
