评注：比较接地气的一种团队建成方式
转自：
http://mp.weixin.qq.com/s?__biz=MzAxNzM4OTE4Mg==&mid=210320484&idx=1&sn=eab0401c2a20b7d2fd117733807e1eed#rd
我心目中的理想团队
2015-07-25 玉伯 探索时间
昨天 @左耳朵耗子 发了篇文章：「开发团队的效率」（http://coolshell.cn/articles/11656.html），对文中绝大部分观点都很认可，但关于团队小而精这点上，我觉得有失偏颇，于是回复了一条：
非常理想化的想法，但不接地气。小而精的全栈式团队，就像一个曲线的波峰，看似美好，但不稳定。更喜欢朴实的工程团队，能安然处于谷底，每个人可能都不太牛，但通过各种土办法，能汇聚起来，所向无敌。
由于微博的字数限制，读者容易断章取义。看大家的疯狂回复，只能淡淡一笑了。不过耗子既然约战，我就详细写下，侧重于描述我心目中的理想团队。
耗子描绘的小而精，我的感觉是这样的：
每个小红点都是一个不错的全栈式人才。全栈的含义，一是多语言的快速掌握能力，消除技术锁，二是跨模块的业务深入能力，消除模块锁。这非常赞，是很多技术团队梦寐以求的追求。
我关注的是，怎么组建出这样一支团队？耗子全文中并没有给出答案，耗子描述了美好的终局，但并没给出实际可行的路径。能猜到的一种做法是，疯狂招聘牛逼的人才，看不上的都不要。对于现有人员，则严要求、高淘汰。这种做法，对于极少部分团队，是可行的。但对绝大部分团队来说，缺乏实际的可操作性，不接地气。
我更倾向于下面这种团队构成：
小红点是大牛，团队里有，但并不多。小黄点是小牛，正在快速成长为大牛。团队里更多是小绿点，技术基础不错，发展潜力好，但当下只熟悉某一门语言，在具体项目里，也只能为某一两个模块负责。我相信这是绝大部分团队的现状。
在这种现状下，我们回到耗子的主题：开发团队的效率。很明显，耗子的倡导是好的，但直接开搞，团队非死即残，只有很侥幸的机会能存活下来。面对现实，说说我的「土」办法。
第一步是承认现状，认清自己所处的环境。耗子所在的阿里云我不清楚，不多说。我待过的淘宝和支付宝两家公司，这么多年，从来没看到小而精的团队能持久存活。同时还有一点非常重要，无论自己多牛，需认清的一个现状是，大家都不是傻瓜，能在阿里一路带兵打将到带领团队的负责人，十个里面有八个都是不错的，否则阿里不可能做这么大。这么一帮不错的技术负责人里，肯定有不少人想过耗子想做的事情，为什么没去做或没做成？希腊的神谕真的不是鸡汤，认识你自己，无论什么时候都非常非常重要。
认清现状，很多问题会清晰和简单化。在不断的碰壁失败后，会发现一些可行的「土」方法更接地气并且更能实现理想中的目标。比如
对于软件开发中的「锁」，耗子的解决方案是：
一个程序员应该能够掌握多个语言，也能够负责多个模块甚至不同的职责。如果一个程序员觉得多学习一门语言，多掌握一个模块是件很困难的事，那么这个程序员本质上是不合格的。
这个解决方案，淘宝曾经的技术负责人三丰，支付宝 CTO 鲁肃等等牛人，都自上而下以及自下而上推行过，但现阶段来看都尚未成功。我现在的主要工作职责之一，就是和鲁肃一起在支付宝推行全栈工程师文化，其实从 2009 年开始就有尝试。我们尝试过让前端学 Java，也尝试过让 Java 工程师学前端。但最后的解法，并不是发现培训不成功，就认定这些工程师本质上是不合格的。即便认定不合格，在当下技术人才稀缺的情况下，你能怎么样呢？耗子给的是要求，并不是解决方案。
分工并不可怕。分工源自社会经济学，分工解决的问题，就是效率提升。无论在传统工业车间，还是在互联网技术公司，分工依旧是提高团队效率最「土」但最有效的方式。分工的背后，是遵循人类社会发展的规律性，是术业有专攻。分工有两个非常关键的点：
1、分工的合理性。耗子说分工越细团队就越没效率，并没有说到点子上。影响团队效率的，是分工的合理性，而不是粗细。究竟怎样的分工是合理的？不同领域、不同团队，在不同阶段下，合理的分法可能都不同。在支付宝，对于高交互类业务，前后端分开，各司其职是很有必要的。对于可规范的平台类业务来说，让 Java 开发懂一点前端，基于前端提供的服务化方案去独立完成产品研发，则是非常不错的方式。分工的合理性离不开实际场景和团队的人员情况，会有一些规律性，需要在时间的长河中不断去探索、沉淀。
2、团队间彼此赋能。就是耗子说的团队间的服务化。这一点非常非常赞同，服务化不是我帮你做事，而是让你能做我的事。不过耗子依旧是只说了方向，而没有说打法，是目标，而不是解决方案。在支付宝，为了能让 Java 开发学会更多前端技能，我们的做法是，成立了前端技术学院，与各技术团队负责人一起，筛选出培养目标，通过一系列培训，以及在实际项目中的以战练兵去赋能。同时，也需要在前端类库与框架层面发力，尽可能让前端的技术门槛降低。一方面是通过培训提升人员的能力，一方面是通过技术架构优化降低技术门槛，当能力提升能匹配上技术门槛的降低时，很可能就可以真正实现团队间的彼此赋能。真实操作过程中，还有大量大量的细节工作需要去攻破，远比耗子喊喊口号复杂很多。
其实这些接地气的解决方案，回过头来想，都很「土」，都是自然而然就能想到的方案。但正因为「土」，反而不怎么被很多有远见的牛人待见。因为很多牛人，总想着通过某些取巧的方式去达成目标，我之前也疯狂想过通过各种更快速的方案，比如搞一套类似 Visual Studio 的可视化拖拽方案去给后端团队赋能，但实际操作下来，这样反而会惯坏后端团队，使得后端团队在前端技能的积累上停留于初级阶段。大道至简，返璞归真，越来越觉得，真正能解决问题的，往往都是最「土」的方案。
耗子说的第二点，接力棒式的软件开发，跟软件开发中的锁本质上是一样的。解法是，一是要找到合理的分工，二是要通过服务化让团队间彼此赋能。
耗子说的第三点是保姆式的软件开发，这一点的解法依旧是合理的分工与服务化赋能。耗子解决方案里提到的招聘、以及人多人少的问题，并不是关键。支付宝最近一年，在逐步把测试团队取消掉，让开发也懂测试。但无论怎么融合，专业化的质量工具团队与质量架构师依旧是有必要的。这需要大家的专业度都提升，开发需要懂得测试，掌握的技能与责任感需要更多，同时测试发展空间也被打开了，不再需要专职的测试去做重复性的人肉测试，而需进一步提供测试自动化工具，需要往深里钻，非常有挑战。
WatchDog 式软件开发，这一块要看领域。耗子所在的领域我不熟悉，不多评价。但解决方案里提到的设计想好了再做，以及残酷无情还债，实在是有点片面，并不具备普适性。大部分商业系统的设计，如果要等设计想好了再做，可能已经错失商业契机，做出来已经黄花菜都凉了。先土土的上去，在行进中开火，在飞机高空飞行时换零件，我更佩服这种能力。如何做到高空中换零件，一开始可能还真需要 WatchDog 系统。最常见的是监控系统，这一块太重要了。
不光是从技术上考虑需要 WatchDog 系统，还有一个非常实际的问题是考虑团队人员的实际情况。大部分团队里都有很多新人，有很多耗子可能看不上的普通工程师。这些新人们每天在产生大量代码，很多代码可能质量真的不高。长期的挑战是如何让大家的技能都提升到耗子期望的水平，但短期的挑战也非常棘手：如何让一帮新人写出来的代码，即便再烂，也有一定的可控性？
去年和 Facebook 的一个资深工程师交流，他说最有挑战的事情之一就是，如何能让一帮刚从大学毕业的 newbie 们，写出来的全栈代码不至于太烂。这背后需要大量工程化的思考与实践，涉及质量控制等很多方面。前端领域的同学，对最近如日中天的 React 技术应该不陌生。React 背后的故事真的非常有意思，React 能在 Facebook 的环境下诞生，一定程度上是被逼无奈。有太多各种背景的新人们需要在 Facebook 环境下去写前端代码，但如何保证这些所谓的 Facebook 牛逼闪闪的全栈工程师写出来的前端代码不会随着时间快速腐败？如何保证各个业务线的前端代码不会臭不可闻？Facebook 有一个专业的 Frontend Infrastructure Team（简称 FIT），这帮人可是想尽了各种办法，最后才发现基于 DOM 是无望的，必须超越 DOM，必须打破 W3C 规范的很多拘束，于是有了大道至简的 React 方案。React 的技术亮点就在于「土」，新人们操作 DOM 老出问题，我就搞一层 Virtual DOM，不让你直接操作真实 DOM。Flux 单向数据流的设计也是一种非常「土」的做法，土得出奇，但现阶段看起来，正因为土，反而把很多很多问题简化了。土到极致，牛气冲天。
最后，回到如何构建一支心目中的理想团队。我的想法依旧是一张图：
很多团队是处于 A1 状态，都期待着往耗子说的 B1 而去。我们真正要解决的问题，是如何带领团队从 A1 波谷，到达耗子描绘的 B1 波峰。除了合理分工、团队间的彼此赋能、以及土到极致的技术突破，还需要重视一个规律性：
波峰是不稳定的，不要尝试让团队永远处于美好的波峰状态。当一个团队的人都成长成为精兵悍将时，往往意味着这个团队前途有限了。站在波峰，很容易藐视群雄，很容易拔剑四顾心茫然。一个良性团队，在短暂攀登上波峰时，应该能有勇气去打破一些东西，有勇气去带着团队下山。下山会很痛，甚至会让效率降低，但不下山，不到达另一个波谷，就永远难以攀登上更高的波峰。前端团队的发展在这一点上有很多故事可讲，耗子若有兴趣，我们可以私聊。
很尊重耗子的理想，也是我的理想。面对现实，我选择我的路，也期待着耗子能把自己的路在美国走通。
玉伯
2015.7.25 杭州三墩