未来酒店——建设高效研发团队的经验分享

摘要：

在5月29日召开的第二届研发效能嘉年华中，由浙江未来酒店网络技术有限公司的孙吉君带来了“未来酒店——建设高效研发团队的经验分享”。本次分享中他对未来酒店研发规模进行了介绍，对高效团队的三个特征、四个能力的培养和团队建设过程中的四个方法进行了讲解。

在5月29日召开的第二届研发效能嘉年华中，由浙江未来酒店网络技术有限公司的孙吉君带来了“未来酒店——建设高效研发团队的经验分享”。本次分享中他对未来酒店研发规模进行了介绍，对高效团队的三个特征、四个能力的培养和团队建设过程中的四个方法进行了讲解。
以下实践案例来自云效一站式研发协同平台，立即注册云效，体验阿里巴巴的研发速度和工作方式，一起Work Like Alibaba。
精彩视频请点击
PPT下载请点击
以下为精彩内容整理：

未来酒店研发规模

“未来酒店”是飞猪、石基和首旅的合资公司，我们的使命是让天下酒店没有难做的生意，旨在通过AI、大数据等技术赋能中小单体酒店，做到入住体验升级、酒店服务能力升级和经营能力升级。作为未来酒店技术团队，我们没有从小长到大的成长过程，一开始就面临大规模开发的挑战，我们用了3个月的时间组建了百人研发团队，完成了产品技术体系和项目管理体系的基础建设。我们能够如此快速的组建一支高效成熟的团队，很重要的一个原因是基于阿里云为我们提供的解决方案，让我们有更多的精力放在行业SAAS层面的产品技术建设上，那今天这个会就和大家分享一下，我们是如何组建高效研发团队的。

我们目前共支持18个产品线，最高的时候可以并行研发50多个项目，同时在线运维70多个应用，目前的研发团队规模是120多人，

三个特征

团队建设之初我们对团队做了一些定义，我们认为高效的团队应该具有3个特征，同时也在四个能力的培养上做了很多。首先说一下三个特征：

• 清晰：团队要有清晰定位与目标，清晰是团队的工作边界、系统边界、责和权的定义。同时清晰也是你的技术路线、技术战斗。同样也要有清晰的过程和结果的考核原则，虽然做不到很具体，但是我们可以定义一些原则与共识。没有目标、方向和共识的团队，走不远。这也是团队聚焦的过程，让团队的同学们达成共识的过程。
• 通畅：团队的内部沟通是不是很通畅，在合作过程中是不是纠结这个事该谁做，在做什么事情的时候是不是有各种不配合。就像很多车要到同一个地方，车少的时候按按喇叭就够了，车一多就需要更多的信号灯与指示牌，单车道不够还要多车道。同样各自目的地不同的情况下，如何避免老是撞车。一个leader有责任，在团队决策多了的时候，构建一个畅通的环境，无论对上、对下还是对平级，最重要的是有问题了能第一时间反馈到你。同时有一个达成共识的过程，当共识达成之后大家是不是能在一起有组织的畅通的执行下去。
• 信赖：一个团队构建信赖的环境是非常重要的，信赖和信任不一样，信赖是信任+依赖。一个团队光有信任是不够的，人与人、人与团队、团队与团队之间一定要有互补性，互相基于信赖在一起工作。在我们这行有一个叫“重复造轮子”的问题，必要的重复造轮子我们应该有，但是低效的重复造轮子应该绝对避免，出现这种情况一是你东西做的不好，二是我觉得我做的更牛，而背后出现问题的原因还是彼此的不信任。团队的氛围要简单直接，不能勾心斗角，任何猜忌负面的东西我们发现了一定要阻止。抱怨这个东西就跟传染病一样，一个人得了，这个小组就会得，一个小组得了，整个管队都会得。一方面我们要及时发现抱怨背后的问题，并解决它，一方面我们要提高整个团队的免疫力，有能力的人我们要及时的去处理。

四个能力

一个高效团队应具备4种能力，这个能力应该是团队的能力不单是个人的能力

• 量化的能力：工作量化能力是团队每一个成员必备的能力，工作量化一直是开发团队讨论的话题，是一种业务方和实施方共识，你的团队是不是存在当沟通需求的时候，会存在看看代码才能评估工作量的情况？同样，工作量化的能力，一定是顶层架构设计的能力扩展，每个同学业务知识不同，技术能力不同，对系统熟悉能力的不同，会造成不同的结果，那我们有没有可能提供一种方式，让工作量化的能力每个人都具备，让他评估的过程中八九不离十。
• 应变能力：随着业务的不断发展，我们会随时处于一个变化的环境，业务会变、组织架构会变，但技术体系不能总变。我们一方面要让团队知道变化是常态要去适应，另一方面我们也应该让团队在变化的过程中，知道自己技术的位置，以技术的不变应对业务的变化。
• 补位能力：不单是同岗位的补位能力，更需要的是跨岗位的补位能力，能够让一个开发同学快速的跟进另外一个同学的进度，背后是我们对架构梳理是否清晰，这里边需要跨越的就是代码的障碍。在一个开发框架下，遵循同一个规范，把补位工作变成对业务本身的熟悉，是我们要做到的。
• 优化能力：优化能力是指团队自我更新的能力，我们要倡导一个文化，任何技术的想法、项目管理的想法以及对工作有益处的想法都应该鼓励，当我们经过讨论后觉得是这样的，那就要坚定不移的去执行，可以先小范围的试测，成熟后再在大的范围内推广。如果一个团队没有自我优化的能力将会是一潭死水，当然也不是所有的想法都是对的，这背后看的还是我们在处理问题时的智慧，我们要建立一种机制鼓励大家参与进来，提出一些有建设性意义的想法，同时能达成共识能对整个团队不断的向前发展有更大的益处。

四个方法

我们在整个团队的建设过程中有四个方法：
1、三张大图：
每一个leader心里都应该有三张大图，即业务大图、技术大图和组织大图。业务大图是实现是什么样的业务价值，有什么目标、有什么策略、有什么抓手；组织大图是我们完成这些业务目标需要的组织保障、人才保障以及人才能力的保障；技术大图是我们实现业务大图的方式方法，包括系统结构、技术选型、路线、边界、平台和工具定义等，技术大图应该是超越业务大图有前瞻性，能看到未来3年、5年技术的情况。大有大作、小有小作，但我们从小做到大的时候是验证规划顺理成章的延伸，如果是颠覆性的说明我们技术大图的规划有问题。每个公司的技术leader要有这三张大图，同时要把这三张大图印在核心团队每个人的脑子里，尤其是技术大图，最好能在我们有决议冲突的时候，做为我们技术选择的指导。是业务系统的，还是业务平台的，是工具建设的还是技术中间件的。
2、定义开发框架：
针对不同的开发场景要有不同的开发框架定义，如果说三张大图是架构层面的定义，技术大团是定义系统与系统之间的关系，那么开发框架就是定义系统内代码与代码之间的关系，系统内部人与人之间在组织代码配合的关系。你可以定义一个复杂的关系，你也可以定义一个很技术的关系，但我觉得你应该定义一个更贴近业务的关系，能够让业务逻辑和代码逻辑尽可能的对应起来，这将给我们开发效率带来很大的提升。同时开发框架要足够的低耦合，业务和代码能够清晰的映射，代表着开发的同学能够快速的把业务逻辑转化为代码关系，方便我们评估工作量，以及问题沟通、跟踪。在实际工作中，我们设计了一个任务职责框架，这个框架很简单，就是模版模式和职责链模式，背后代码的逻辑直接对应着业务的系统、模块、功能和子功能，模块是目录结构，功能是任务，子功能是职责，一个功能顺序的执行子功能就完成了一个逻辑功能，由页面出发还是定时的任务出发都不影响背后的业务逻辑关系。
3、建立模型
结合前面的三张大图、开发框架，我们已经有了建立数据模型和流程模型的基础，我们基于此就可以建立沟通模型。这个模型可以是一张excel表、可以是一个系统，他梳理出来的功能分解，就是我们对应的系统和实现系统的代码。这个模型完全是由业务语言描述的，但背后存在着与技术代码实现的逻辑关系，让开发同学可以用业务的语言来沟通技术。如何构建畅通的沟通正是我们要去讨论的。我遇到过一个开发框架，业务的描述是业务处理的流程，而开发用了一个状态机，当双方沟通的时候如果拿一个状态机去沟通一个业务诉求，双方产生了偏差，效率很低，同时由于状态机实现的问题，产生了大量的类与类之间的网状依赖，这个系统发展到最来就是只敢增加代码，不敢修改代码，任何一个改动都有可能影响到其它依赖的代码。所以我们应该建立一个业务逻辑和代码逻辑的沟通模型关系，同时要尽可能的是以线性方式实现，避免代码之间的依赖，如果有公用的逻辑，可以抽象出工具类，甚至重写规避。
4、丰富工具
工具是非核心链路上的辅助系统，他的目的是提高我们的效率，无论开发、测试、产品、运维还是运营都有工具的诉求。我们应该鼓励丰富的工具，让工具体系化，并持续的投入，当开发团队不超过20人时，我们应该尽量做工具，当超过20人时我们可以有平台化的方式去落地。工具化的建设一定是通盘考虑的，一个开发团队应该尽量避免重复低效的制造工具，同时我们也鼓励有想法的有序的工具，通过建设规划成长的方式为整个开发团队带来效率的提升。当然也可以从我们的角色不同定义我们的工具，开发的、测试的、产品的、运营的、以及项目管理过程中需要的工具。
几点思考
最后抛出几点思考，
第一个是：如果一个团队经常重构系统，那我想一定是存在架构的问题，你的团队是不是也有同样的问题？
第二个是：平台化听上去很高大上，但实际操作一定要谨慎！
第三个是：业务复杂度是不是决定了系统复杂度和代码复杂度？作为一个技术团队的Leader我们觉得是有责任让我们的系统复杂度和代码复杂度不依赖于业务复杂度，也就是业务做的再深入，业务做的再复杂，背后的代码逻辑和系统之间的关系应该都是相对清晰的、线性的；第四个是：我们如何在团队管理过程中平衡技术和业务的目标？当业务需求很紧张的时候，我们如何还能朝着规划去实现技术的目标以及一些技术的规划？

原文链接