中小型技术团队的组织架构3

3.4 如何让异地团队更高效

3.4.1 消除“网状”沟通，提高异地沟通效率

在上面的章节中，我们分析了大型技术团队的组织架构，组建一个大型技术团队往往要考虑成本、人员层次配比等问题，建立异地研发中心能够使人员成本得到优化，并且容易获得更优秀的人才，建立起人才梯队。因此，许多超大型互联网技术团队，都选择建立异地研发中心。比如腾讯、华为、阿里、京东、百度、搜狐、网易等互联网巨头，将独立研发中心建立在成都、武汉、南京等二三线城市。

一般来说，二三线城市的技术人员成本是一线城市的60%~80%，高校林立的二三线城市里，人才济济，只是本地互联网公司数量较少，难以形成市场化的人才培养机制，以至于毕业生在毕业后的几年里，技术的深度和广度跟一线城市的从业者拉开了距离。因此，如果一个公司本身已经形成了一套人才培养的机制，通过在二三线城市建立研发中心，能够获得优秀的技术人才，也能够大幅节省成本。

当建立起异地团队后，首先出现的问题是异地沟通效率低下的问题。为了更好地了解这个问题的现象和本质，我们首先来看一张异地沟通协作示意图，如图3-13 所示。异地团队一般所采用的是网状沟通方式，这种沟通方式的效率非常低下，产品设计人员为了给异地的开发人员讲解需求，需要做一次统一的需求讲解，所有的开发人员参与，当开发人员在实际开发中发现问题后，又需要再次找产品设计人员，当10 个开发人员，每个人有2 个问题需要跟产品设计人员沟通时，就有至少20 次异地沟通，要知道异地需求讲解通过电话、语音等即时通讯工具，是比较低效的事情。
 

比较有效的办法是，建立“异地沟通接口人”的方式，涉及到这种需求讲解、方案说明的情况，都可以通过这种异地接口人先进行沟通，并且确保内容完全沟通彻底，通常这个接口人的沟通表达能力较强、对业务需求和技术方案都非常熟悉，才能胜任这个角色。如图3-14 所示就是异地接口人的沟通示意图，异地接口人负责进行异地工作的沟通，再有效传达给团队，把异地沟通数量减少90%以上，更多的是同地团队成员跟接口人的沟通。
 

3.4.2 每日晨会，暴露问题

异地团队协作进行项目开发时，最致命的问题是，在开发过程中项目经理很难发现异地团队出现的问题，只有等到项目联合调试的时候才暴露出问题，但是这个时候已经晚了，严重影响了项目的交付质量。

异地团队之间的每日晨会，能够很好地解决这个问题，每日晨会的形式跟敏捷开发里的“每日站会”是相同的，需要团队成员都参加，每个团队成员只需要讲3 个问题：昨天我完成了什么？今天准备完成什么？目前遇到的困难是什么？讲的过程中不允许打断，讲完就结束每日晨会，时间控制在15 分钟以内。

Team leader 和项目经理，记录下问题项，晨会结束后找到相关人员，帮助解决出现的问题。这样的晨会必须持之以恒，以便养成团队主动反馈问题的习惯，另外这对于异地团队之间培养默契是非常重要的。

有条件的情况下，可以通过视频会议的方式进行每日站会，如有必要，可以打开电子白板，两地团队看到同样的信息。

3.4.3 异地“白板”，进度透明化

对于异地开发团队来说，能够及时地反馈出每个团队成员的工作进度，是非常重要的。建立一个“电子白板”（如图3-15 所示）就能够让两地的团队成员，实时地看到每个人的进度，如果你的团队正在使用敏捷开发，那么你可以考虑建立在线的一个敏捷开发工作平台，让团队成员通过网络访问敏捷开发工作平台，把每天的进度录入到工作平台中，让整个开发过程透明化，便于管理人员及时发现问题，及时解决问题。也为管理工作积累数据，日后通过分析这些数据，来发现团队开发效率的短板。
 

3.3.4 最佳实践案例：异地团队的3 种高效组织架构

下面我们通过某互联网公司的上海、武汉两地团队的例子，来向大家介绍搭建高效异地团队的3 种架构方式。

案例3-5 搭建高效异地团队的3 种架构方式

第1 种，三七团队。

以10 个人的开发团队为例，有3 个人：PD（产品设计）、DL（domain leader）、AA（应用架构师）在业务中心所在地—上海，其他的诸如TL(Team leader)、开发、测试在武汉，所以叫三七团队。应用场景：需要频繁交流、强调沟通职能的domain，偏前端的应用、未成熟且快速增长业务。这种结构下，PD 和DL 最接近产品的业务方，可以随时面对面深入讨论功能需求和产品走向，允许在短暂降低DL 和开发团队之间的沟通效率的情况下，尽量保证功能开发和产品大方向不会受到较大的影响。

三七团队组织架构如图3-16 所示。
 

第2 种，一九团队。

PD 1 个人在上海，其他的诸如DL、TL、AA、开发、测试均在武汉。

应用场景：业务相对成熟或发展缓慢、偏后端的应用，例如后台管理系统、报表系统。这样的团队的特点是，所有人对当前产品已非常熟悉，或者对UI 界面的用户体验要求不是非常苛刻，PD 一人足以决定产品的下一阶段走势。如此一来，DL 就可以和开发团队一起工作，更加专注于迭代开发的效率、质量和流程。

一九团队组织架构如图3-17 所示。
 

第3 种，五五团队。

PD、DL、AA 及一部分开发或测试人员在上海，剩余人员在武汉。应用场景：很多情况下，也存在着上海必须有开发人员来更快速地支持业务方反馈的日常紧急问题。在DL 忙于其他事情的时候，上海的开发人员，就可以加快问题解决的速度，提高业务方的满意度。五五团队组织架构如图3-18 所示。
 

根据上述原则，依据不同的业务场景去搭建不同类型的异地团队可提升技术团队的服务水准，提高沟通效率。

当然，我们知道，事情不会是100%想象中那样完美，每个团队对这种结构调整的适应也是需要一段时间来磨合的。举例来说，由于成员分在上海、武汉两地，所有组员无法面对面交流，需要借助一些IM 通讯软件或者电话，一开始的敏捷晨会沟通效率变得不那么高，会议时间也延长到原先的两倍甚至三倍。有时候遇到复杂技术问题的讨论需要用到白板画图，更是让人有一种有力无处使的感觉。

解决的办法还是有的，团队无法面对面沟通的问题，可采购些大显示器加上视频软件，迅速可以让远在两地的组员仿佛近在咫尺，沟通变成了零距离。

为了长期提高队伍凝聚力，增进感情，有条件的情况下，可要求异地团队制定出差计划，上海前往武汉或者武汉前往上海，让平时身处两地的成员消除陌生感，培养团队默契。