技术分担产品之忧（上）：挑选有业务专家潜力的人

你好，我是王植萌，去哪儿网的高级技术总监、TC主席。从2014年起，担任一个部门的技术负责人，有8年技术总监经验、5年TC主席的经验。这节课我会从去哪儿网产研融合的经验出发，和你聊一聊怎么让技术分担产品之忧。

技术分担产品之忧的背景

作为去哪儿网公司2022年“巩固技术之本，分担产品之忧”技术战略的一部分，如何带领技术团队快速融入业务团队，形成产研融合的效果，成为了一个十分重要的管理课题。

为什么在2022年去哪儿网会着重强调“分担产品之忧”呢？

在2020年和2021年，去哪儿网技术侧整体主要是从效率入手做事情，去哪儿网的研发效能得到了很大提升。

但与此同时也面临着一个问题，随着研发速度变快，交付周期变短，但业务增长的边际效益在降低，并且效能优化的空间也越来越小。虽然技术侧的研发效能在不断提升，需求的研发成本在不断降低，但是业务收益变得越来越不显著，所以在2022年，技术侧准备进一步在业务侧分担产品的压力。

我们的战略目标是实现技术组织“分担产品之忧”，具体怎么实现这个目标呢？

根据杨三角模型，我们可以把实现这个目标的组织能力拆解为三部分：

需要什么样能力的成员来做表率？
如何让团队成员愿意把更多的精力从技术中抽出来，投入到与业务人员的合作中？
另外，要实现产研融合，该使用什么样的组织形式来做？

要解决第一个问题，找出能够分担产品之忧的技术员工，并让他做出表率，需要从员工的能力入手，挑选有业务专家潜力的技术成员，借此来鼓励大家去专注业务。

挑选有业务专家潜力的技术成员

在去哪儿网挑选有业务专家潜力的成员，主要有以下几个渠道。

第一，通过培养员工承担技术负责人职责，使其逐步成长为业务专家，这也是去哪儿网应用得最广泛的一种方式。

去哪儿网早在2018年就设立了技术负责人制度，技术负责人的主要职责是负责业务全流程，从接到需求到完成交付的整个过程，是产品经理在一个完整项目中的业务搭档。

技术负责人要承担怎样的职责呢？

辅助产品经理梳理业务线，完成PRD文档。
担任整体技术方案负责人。
协同各技术团队确认工作量与排期，并实时把控进度状况。

技术负责人做到了这些，就可以有效降低产品经理在项目过程中的工作压力了。

在去哪儿网，技术负责人还有两个进化版本，第一个是可以承担产品的“一句话需求”，技术负责人根据一句话需求，结合自身的业务背景，完善“一句话需求”，并自己构建项目的度量指标，完成除 Idea 之外的全部产品需求流程。

还有一个进化版本，是实现 DRI（Direct Responsible Individual 总负责人）的能力，也就是一些业务需求直接由技术人员发起，技术同学既承担产品经理的职责，又承担研发项目负责人的职责，这类项目通常是一些非常适合技术同学来主导的项目，比如说酒店非标准接口代理商接入项目。在这类项目中，产品同学和运营同学都会辅助技术负责人来完成项目。

比如我负责的国际酒店业务线，有大量的 UI 优化类的产品诉求，而这部分诉求通常比较简单，只要与国内酒店部门的 UI 变化一致即可，也就是说这部分的需求相对而言是更偏标准化的，这部分产品经理的职责就由前端开发来承担了。

还有就是在国际酒店的供应侧，每年都有大量提供非标准接口的代理商计划接入去哪儿网平台，一般这种情况下代理商接口与去哪儿网接口的对接工作，是需要由去哪儿网来完成的，而这部分工作就非常适合技术人员主导，产品运营同学配合技术同学来完成。2022年上半年，技术同学主导的需求创造的业务价值接近700万人民币，这部分价值的确认也是很有仪式感的，由技术负责人发邮件，业务成果最终由业务线负责人确认，具有权威性。

第二，通过各项分享交流活动，逐步培养团队中业务架构方向的人才。在这方面，我在2022年与郑吉敏老师、龚珂老师一起制作了8期业务架构系列讲座，邀请到了去哪儿网各个业务线承担业务架构师职责的同学来分享，分享内容被严格把关，一定要按照业务架构的思路来讲，一定要围绕业务架构与企业架构、数据架构、应用架构和技术架构之间的关系来讲。通过这次分享，各个业务线都有不少同学对业务架构产生了浓厚的兴趣。

在讲解业务架构之前，去哪儿网的工程师们大多数都听到 TOGAF 5A 模型，但是如何在实践中将 EA/BA/AA/DA/TA 进行关联，还没有清晰的方法论。

[reference_begin]注：TOGAF是一个架构框架，即开放群组架构框架 The Open Group Architecture Framework。[reference_end]

去哪儿网搭建“业务架构系列分享”这个平台，通过各个业务线架构师一号位的分享，反复向基层技术同学传递业务架构的作用，EA/BA/AA/DA/TA 间如何联动。课程可数字度量的反馈是去哪儿网迄今为止所有分享中最好的。75%场次给予反馈的听众大于100人，25%场次给予反馈的听众大于200人。分享的平均得分全部大于4.6分[reference_begin]（满分5分）[reference_end]。

另外，TC[reference_begin]（技术委员会）[reference_end]的业务架构 SIG[reference_begin]（特殊兴趣小组）[reference_end]也是公司内运行最规范、组织最为活跃的 SIG 之一，每两周一次例会，每次例会都会有一名 SIG 成员分享近期自己在负责的业务架构改进工作。通过这些措施，整个工程师团队在短期内对于业务架构的认知有了非常大的提升，也有越来越多的同学投入到业务架构相关工作中。

在2022年上半年，业务架构SIG吸纳了门票、火车票、内容、公共、国际酒店部门的架构一把手加入到 SIG 组织中，这些小型业务线的一把手通常都是带着很多问题来到业务架构 SIG 的。他们面临着系统是否该在目前的时机进行重构、是否是与产品一起进行 DDD 事件风暴的好时机，是否该由传统3层架构改用 COLA 架构等问题，在业务架构 SIG，大家一起帮助这些中小型业务线的一把手分析问题、解决问题。

在业务架构 SIG，大家还会自发组织学习并讨论市面上业务架构方面的新书籍，例如2022年8月，业务架构 SIG 就自发组织了对《业务架构解构与实践》一书的学习讨论。这些活动给各业务领域的架构师提供了非常好的锻炼环境。

经过2022年半年的发展，业务架构 SIG 一共吸引了21名各个业务线架构方面的主导工程师，通过每位架构师同学对自身应用架构的分享，各个业务线整理出了从三级业务部门到五级业务部门的不同粒度的应用架构图，这些应用架构图全部落地到了 wiki 文档中，wiki 文档对产品同学、运营同学和技术同学都是开放的。

第三，对于团队中级别比较高的员工，比如Team Leader，可以采用业务总监技术合伙人的方式来实现高级别业务专家的进化。通常情况下，技术团队整体上会要求技术合伙人的绩效在一定程度上与业务负责人绑定，达到业务管理者与技术管理者同时为业务负责的效果。这个方法对于提升高级别特别是 Team Leader 级别的技术人升级为业务专家是非常有效的。

去哪儿网通过这三种方式挑选具有业务专家潜力的技术成员，对业务结果负责，从而为其他技术同学做表率，来实现技术分担产品之忧的目标。

小结

最后我们一起来回顾一下这节课的内容。

去哪儿网从2022年开始，着重强调“技术分担产品之忧”，进而提高业务收益，推动企业的发展。根据杨三角模型，想要实现这一战略目标，需要从员工能力，员工的意愿以及治理方式入手，一步步推进。这节课我从员工能力角度，分享了去哪儿网挑选有专家潜力的技术成员的方法。

首先，让员工承担技术负责人职责，逐步培养他们成为业务专家。为此，去哪儿网设立了技术负责人制度，之后还演化出了一句话需求和实现 DRI 两个版本，让技术负责人承担起业务责任。
然后通过公司内部的分享与交流，让技术人员熟悉团队内部的业务架构，培养他们成为团队中业务架构方向的人才。
通过业务总监技术合伙人的方式，让中高层的技术管理者进化成高级业务专家。除了培养并挖掘有能力做业务专家的技术人员外，员工自身的意愿以及企业内部的治理方式也是非常重要的两个方面，下节课我会分享这两点。