如何打造高效的团队（二） - Android平台团队架构实例
文章目录
- 前言
- 虚构一个背景
- 传统的infrastructure团队架构
- Platform 团队架构
-
- Platform和Infrastructure的区别
- 平台团队架构
- 平台团队文化
- 总结
- 相关博客
如何打造高效的团队（一） - 团队架构
如何打造高效的团队（二） - Android平台团队架构实例
如何打造高效的团队（三） - 领导力
前言
这篇博客接着上一篇 如何打造高效的团队（一） - 团队架构，从架构一个手机平台团队的实战事例，来讨论Team Topologies理论在实际中的应用。文章中的实例是根据我自己工作中的实际经历提取出来，不涉及所在公司的具体业务，也不透露具体公司的细节，不过可以声明以下三点：
- 文中的例子是在知名互联网公司里的实践经验。
- 文中举例用到的公司只是随机举几个我知道的例子，并非文中实战例子的原型。
- 文中例子的原型实战中经过海量用户、复杂系统（100M 代码）和复杂产品矩阵的考验。
团队架构和业务需求、公司文化、发展阶段、人员水平等因素密不可分，个人觉得并没有一种one-size-fits-all的解决方案。本文也仅仅从个人的经验分享出发，希望可以提供一定的启发，读者可以酌情作为团队架构的参考，并且欢迎留言交流你们的想法和实战经验。
虚构一个背景
假设有这么一个产品，是个安卓的app，业务场景如下：
- DAU过亿——你推出去的功能可能过了两年都还有不少人在用，不能说砍就砍。
- 庞大的产品矩阵：什么产品加到你的app里不是你决定的了的，甚至不是你老大的老大决定得了的。
- 这些产品来自于不同的团队，工程师数量可以是几百上千，很大一部分不在你所处部门，地点上甚至是分布于世界各地。
- 这些产品都需要通过你这个app交付给用户。
- 你带一个团队负责这个app，比如它的构建(build)，release，整体性能等等，总之就是要能保证这些产品矩阵快速、安全、稳定的迭代给用户。
- 你的这个团队的人数远远低于上文提到的做产品的人数。
比如支付宝或者微信，可能就符合上述的例子。这篇文章探讨的就是你可以怎么去架构这样的一个团队。
传统的infrastructure团队架构
一个很自然的想法就是既然有人开发功能， 有人开发架构，那就将整体的参与者看成两类：功能团队(feature)和架构团队(infrastructure)。功能组就负责开发功能，开发出越多的功能，迭代得越快，就越好。架构组就负责整合这些功能，做好模块化，做好快速迭代，做好各种排查错误的工具。实例图如下：
这种团队架构方式分工明确，事实上也有很多团队在采纳，实际应用中经常也可以work。但是随着时间的增长和规模的增加，有一个问题会越来越麻烦：维护。功能团队的动力来自于推出更多的功能，一个系列的功能完成之后团队很可能会解散或者重组，以开发新的功能。而这个时候架构组就会发现有一堆自己完全不熟悉的功能被留下来需要自己去维护， 形成一个“鬼城”，如下图：
其实归根结底，这种模式更像是把架构组看成是一个专门的operation team。功能组开发完功能，通过架构组把自己的功能迭代出去（当然这时候功能组会参与并且主导，毕竟把功能迭代出去是他们的动机），然后放手交给架构组去维护自己的功能。当然功能组往往会先自己维护一段时间，然后换到其它项目上；虽然换之前一般都会承诺自己会接着对自己以前做的功能负责，但起码我观察到的实际情况是不用太久马上就连人都找不到了或者互相踢皮球——毕竟团队可能解散或者重组了，有新的任务了，人可能也离开公司了；以 Team Topologies 的“团队是执行任务的最小粒度”的观点来看，这里已经没有一个团队是对这个功能负责的了，后续维护全靠个人责任心，没有制度支撑往往就靠不住了。同时因为维护交给了架构组，功能组也没有足够的机会去发现自己开发的功能在维护上的问题，也缺少足够的动机去设计易维护的功能——很容易就会导致再新开发的功能也一样有这些问题。
而对于架构组，别人开发完功能，该庆功的庆功，该升职的升职，最后留了一堆你根本就不了解的东西让你去维护，上手难、维护起来花时间，然后除了大家口头的感谢外，其它啥也得不到，搁谁谁都不乐意。而为了减少自己未来潜在的工作量，架构组往往的会严格对加入的功能和其实现方式进行审查，而功能组的人数远大于架构组，这就造成single point of failure，拖垮研发效能，产生团队矛盾。
接下来我介绍另一种方案——Team Topologies里的Platform Team.
Platform 团队架构
Platform和Infrastructure的区别
平台团队类型(Platform Team)是Team Topologies四种基本团队类型之一。它强调的是向负责产品的团队提供自助式的产品，以促成他们可以独立的去在平台上运营他们的产品：开发、迭代、维护和关闭功能。所谓的自助式产品这里可以指代码库、API、工具、文档等等。而架构团队(Infrastructure)并不在四种基本团队类型之中，并且如上文所讨论那样会有各种各样的问题。
平台团队架构
正如Team Topologies所讨论的，所有其它团队类型都是服务于Stream-aligned team的，然后由Stream-aligned team去向目标用户带来价值。所以架构除了讨论平台这边，也需要考虑功能那边：
-
功能组重新定义为产品组（这里的Stream-aligned team）：从之前只负责功能的开发，改成负责一部分的产品，比如像微信里的朋友圈这个产品。包括整个产品的生命周期，比如立项、开发、维护、迭代甚至关闭这个产品里的各种各样的功能。
-
将架构组重新定义为平台组：目的是通过提供自助式的服务，促成产品组可以独立、快速和安全的迭代（包括开发和维护）他们的产品。平台组往往可以以运营内部产品的思维去运营平台。
示例如下：
在这种架构方式下，相比于之前功能组思考的如何更快更有效的交付更多更好的功能，产品组还需要思考如何让这个产品更好的维护。
从用户价值的角度，产品组因为从头到尾对一个产品领域负责，被迫需要去从整个产品生命周期的角度去思考产品的质量和用户价值，而不是像之前功能组那样，只看功能上线时的数据（或者挑一个数据最好看的时候，庆祝下成功然后这个功能的后续发展就和自己没关系了）。这种激励模式下可以鼓励开发并维护长期给用户带来价值的功能。
从研发效能的角度，产品组不需要依赖于架构组的审核，而是独立运营，去除了Single point of failure, 可以促成产品组更高效的迭代。平台组以提供内部产品的方式去运营团队，以赋能产品组为目的，能够促成他们以产品组的成功为自己的成功，思考如何提供更易用、更高效、更稳定和更有用的服务给产品组。从之前功能组和架构组激励模型的对立，变成产品组和平台组激励模型的和谐。
从个人发展的角度，平台组的工程师少了纯粹的维护性的工作（架构组对于没有owner的功能），产品组的工程师少了重复性的工作（平台组提供了自助式服务，封装了一部分逻辑）， 双方都能被解放出来去专注在更有价值的事上。
这里还有一个需要注意的地方是对于定位和问责(Accountability)的建设，因为所有的这些产品矩阵最终都是通过这个平台分发到用户。虽然从公司内部来看，你们是不同的产品；对于用户来说，你们是一个产品。用户那出现的问题，是整个产品的问题；如何将整个产品的问题快速过渡到负责具体产品的团队，就需要快速定位和问责的建设。这里不单单是技术上的模块化设计，还包括产品上需要有合理产品矩阵的划分、清晰的产品边界；数据上能清晰定位，比如线上的crash主要是来自于哪个子产品、用户抱怨产品速度慢具体是哪个部分慢等等；流程上谁来负责分发、多长时间需要响应等等。
平台团队文化
上面提到的都是一些包括团队的边界、相配套的软件模块化架构、流程和数据都是硬性的设置，这种“产品-平台”的划分如果要成功的话还需要有相应的文化建设。
对于产品组来说，最重要的就是类似DevOp的思路，需要对产品负责而不是对开发功能负责。
对于平台组来说，最重要的就是产品化运营思维——将你做的事情看成是一个公司内部产品，将你打交道的产品组看成是你的客户。具体可以有以下操作：
- 以产品思路去设计平台：弄清楚客户需要的是什么，不要闭门造车，也不要盲目追着需求跑；想清楚产品定位是什么，产品是什么。
- 以运营产品的方式去推广产品：当你运营一个产品的时候，大部分情况下你不是靠将你的产品强加给用户，而是靠你产品多好多准确的解决用户痛点；靠你产品的质量；靠你的营销手段等等。作为一个平台组推广你的自助式服务也是一样，采用Build-Measure-Learn的方式了解客户需求；小步迭代、快速试错；建立用户社区等等。其中很重要的一点就是一定要建立用户反馈渠道，比如用户review：
- 追求产品的卓越：关于Product Excellence有太多的书，感兴趣的可以自己搜一搜。我自己总结了一套SUPER的标准：
- Shareable: 不要捆绑式销售，用户不应该因为使用了你的产品而没有办法使用公司内部或者业界比较好的解决方案。比如你提供了十个服务，用户只需要其中一个服务，他们应该能只取他们所需的那个服务，而不用直接依赖于你的十个服务；并且不会因为使用了你的这个服务，而对其它常见而合理的解决方案不兼容。
- Useful：平台组提供的服务应该有效准确的解决用户痛点，提高产品组的效能。
- Performant：平台组提供的服务在性能上应该是高效的。
- Easy：服务应该简单易用。
- Reliable：不可靠的服务不如没有。
总结
- 功能和架构的分离类似于development和operation的分离，随着功能越来越多，这种方式代价会越来越大。功能和架构的激励模型有很大程度上是冲突的。
- 另一个方案是DevOp的思路：
- 将功能组重新定义为产品组，从开发到维护的负责一部分产品，而不是只负责开发功能。
- 将架构组重新定义为平台组，目的是促成产品组可以独立、快速和安全的迭代（包括开发和维护）他们的产品。
- 这种方式二者的激励模型是和谐的。
- 平台组应该以运营内部产品的思维去运营平台。
这里只是单纯的从团队架构的角度上去讨论，如何打造一个高效的移动端平台还有其它许多需要考虑的内容，比如怎么样高质量的联通各个功能之间的数据、怎么样能够保证功能的高速迭代、怎么样提升开发效能、怎么样去维护老版本、怎么样快速定位问题来源和配套处理问题的流程等等，这些每一项都有很多可聊的，以后有机会再分享。
相关博客
- 如何打造高效的团队（一） - 团队架构