怎样构建卓越研发团队？
目录
卓越研发的标尺
两年前开始做平台工程，一方面大量基建问题堆积如山，必须快速迭代；另一方面，平台工程是飞行中换引擎，质量、安全性都有很高要求。项目开始时，而团队经验并不丰富、资源有限，很多地方做的不到位，因此，只有不断提升整体水平，成长为一个卓越的研发团队，才能真正解决问题。
那么，哪些是卓越研发团队的关键特质？我一直在思考这个问题。
在去年读的书中，有三本书触动很深：
- 《决断：成功的领导者怎样做出伟大的决断》-- Warren G. Bennis, Noel M. Tichy
- 《信任的速度》-- Stephen M.R. Covey
- 《相变》-- Safi Bahcall
在这三本书中，我找到了卓越研发团队的三把标尺 —— 产品力、执行力、创造力。
为什么是这三个特质？在人和组织层面，如何培育这些特质呢？
下面，我们从每本书的核心内容出发，结合真实案例逐个分析解答。
《决断》-- 明确战略目标是提升产品力的前提
《决断》的作者沃伦•本尼斯、诺埃尔•蒂奇，是两位领导力理论的先驱。全书首先明确了决断的定义和框架，再讲述了世界顶级CEO的决断案例，包括通用电气、宝洁、百胜、波音这些家喻户晓的公司，最后点出“传统决策”和“决断”的差异，上升到理论高度进行总结。
这本书副标题原文是：“How winning leaders make great calls”，但并不是只有领导者才能看，任何人去读，都能在这些CEO生动的故事中得到启发，提升格局和领导力。
书中有成功的也有失败的案例，总体分成三类：人的决断、战略决断、危机决断，前后两种决断更多是领导力范畴，这里我们重点看中间的：战略决断。
韦尔奇与伊梅尔特的战略决断
韦尔奇在1981年成为通用电气CEO之后，解雇了200多名战略规划师，他说："领导者需要拥有自己的战略，而不是官僚作风的参谋"。通过清晰的战略决断、对组织的精简、发挥人才潜力，韦尔奇在任期内，将通用电气的9个事业部做到了世界500强、市场价值增长30多倍。
他的接班人杰夫·伊梅尔特，也继续战略决断的故事主线，通过对市场需求和企业能力的精确理解，不断寻找最佳方向，不断重组、转型，续写了通用电气的传奇，连续保持了10%的高增长。
时至今日，这家百年企业虽然不再有千禧年前的风光，但从近年来重组为航天、医疗、能源三个公司、卖掉家电这些资产的动向，仍然可以看到清晰的战略方向。
战略与产品力的关系
那么，回到软件研发领域，为什么战略决断对研发团队的每个人都很重要呢？
软件研发是知识密集型劳动，不确定性高，产出难以量化。越复杂的软件项目，模块级别的产品负责人、工程师掌握越多的业务信息。信息是一切决策的前提，因此，研发团队的权力结构通常是自下而上的，模块级别的负责人既影响战略方向制定，也是战略落地的关键执行单元。
一旦底层决策与整个产品的战略目标偏移，必然导致大量资源浪费、形成不了合力，这也是不同研发团队效能相差十倍甚至百倍的关键原因。方向错了，其他一切都毫无意义。
所以，研发团队的每个人，特别是产品负责人，都要学习杰克·韦尔奇、杰夫·伊梅尔特那样的战略意识，要有对外部趋势、市场的准确把握，还要有对自身优势、劣势的精确理解。战略的理解和决断能力具备了，再去躬身前往细节世界，理解一个个具体用户的痛点、提炼需求，用软件模型去表达真实场景的普遍问题，最后回到宏观战略目标做减法、找增量，汇集力量把一个个阶段性目标打穿。
产品力 = (对战略目标的理解 x 对用户的理解) x 建模表达能力
怎么在实践中提升产品力
在项目中，我们也一直在实践和改进，和组员做1:1沟通时，我最喜欢探讨的一个问题就是：“如果你是整个产品的负责人/公司的CEO，你会做哪几年事情，未来几年的你觉得方向应该是什么？”，每次讨论都有不同的收获，经过多轮自下而上、自上而下的沟通和决策，我们所负责的平台产品，其战略方向的故事主线越来越清晰，用《决断》中的定义就是一个包括了想法、价值观、锐气的“Teachable point of view” (TPOV)。
另外，在每季度确定下阶段排哪些任务之前，我会组织团队头脑风暴，对需求列表逐个问两个问题：
- 这件事与我们大目标的匹配度可以打几分？
- 换到用户角度思考，这件事对用户的重要性有几分？
当大家给出量化的评分时，自然会从各种角度想到“这件事重要或不重要”的关键原因，让每个需求有了是否要做减法的依据，也完善了每个需求对应的用户故事。这个过程会花很多时间讨论、思考，搞清楚每件事在战略地图中的位置、每个人在价值链中的意义，看起来慢，实则通过产品力的磨炼，来减少大量返工和无效工作，是非常划算的。
越大的项目，越要谋定而后动，“Think Slow, Act Fast”。
几个季度执行下来，能明显感到大家的产品力提高了。很多同事不再会只从自己的技术思维出发，简单的说“我想做一个XXX”，而是能自主做出“哪些需求不该做”、“哪些核心功能中用户仍然有痛点需要改进”的决断，真正把战略目标和用户痛点一起刻到了岩石上。
《信任的速度》-- 有信任才有执行力
对信任的解构
《信任的速度》是我司CEO Eric S. Yuan在全员大会上，推荐所有人看的三本书之一。作者史蒂芬·科维还写过另一本传播更广泛的《高效能人士的七个习惯》，读这类畅销书中的经典，要有一些阅历才能深刻体会，否则很容易认为只是心灵鸡汤。《信任的速度》把“信任”这个看似简单的概念解构的很彻底，首先定义了构建信任的积木：信用（Credit）。信用具体指什么呢？有四个核心要素：
- 诚实：基本的道德要求
- 动机：关心共同利益而非私利
- 能力：具备兑现承诺的天赋、态度、技能、知识
- 成果：已经实现过的承诺
与广义上的“信一个人的人品”不同，信用的要素包括能力与成果，就像一个人品再好的老师也没办法去给病人做手术、一个刚还没毕业的医生也没办法让病人信任其医术。
其次，作者从影响圈范围的角度，把信任分为五个层次，讲解了构建每一层信任的方法论和必要的行为：
- 自我的信任
- 关系的信任
- 组织的信任
- 市场的信任
- 社会的信任
每一层信任的递进，都会带来指数级的效率提升，形成改变世界的力量。反之，没有信任这块人类文明的基石，一切沟通协作都无从谈起。
一个跨四时区临时团队的故事
2021年底，在我的直属经理支持下，打算开始做公司级别的平台工程，那时我的本职是微服务开发框架的架构工作，自己团队内只有一位研发能抽出时间，无法完成这么大的工程。本着“人多力量大”的朴素想法，我去找了所有利益相关方，正好有几个团队也非常想解决缺乏基建平台、十几条业务线各自为战、职能部门孤岛这些阻碍业务发展的系统性问题，我们临时组建了一个跨中美印的四个时区和文化的虚拟团队。
很快，由于对目标的理解、工作方式不同，前两个月就在设计和技术选型就上产生了不少冲突，项目推进缓慢。
好在上层出面及时帮助做了目标纠偏，方向上达成了一致。具体到每个模块，我和另外一位项目发起人，靠着一次一次组织同时区的、跨时区的会议、不断讨论直到达成共识的“蛮力”，推进产品研发。
半年后平台产品发布，我把之前在做微服务框架时积累的内部客户，转换成了平台的首批用户，一个“反馈-改进”的增强回路搭建出来了。
磨合一年后，每个模块的关键贡献者不言自明，随着信任关系的不断强化，职责和分工越来越明确。一周一个迭代的快速改进，让用户对我们的信任也逐渐增强，同时，我们也尽可能让项目的决策过程和进度对所有人透明公开。
没有哪个团队刚组建就能互相高度信任，经过了太多曲折，现在回顾这个故事，很多地方本可以做的更好。
两年后，公司大部分业务线、超过400个服务组件，已经迁移到了我们构建的标准化运维平台、计算平台。这些结果传递到高层，形成对平台工程大方向的信任，又间接促成了多个部门的组织架构调整。
这就是信任飞轮带来的执行力。
塔克曼团队发展模型
前不久学到了塔克曼团队发展阶段模型，发现上面这段经历完美符合了理论模型。塔克曼论述了团队发展必然经过 Forming, Storming, Norming, Performing这4个阶段。塔克曼这篇1965年的16页论文，是组织发展理论的开山之作。模型论述了团队的整体效能是一条微笑曲线，在Storming结束前，效能逐渐下降，而只要渡过了Storming阶段，效能会稳步上升，最终达到高效能状态。
从信任的角度看，团队的效能和执行力，与内部信任程度正相关。
- 刚开始团队被共同目标组织起来的时候，团队成员互相不熟悉，有一个薄弱的信任基础和沟通距离，因此在Forming阶段通常呈现出“假和谐”；
- 随着各种分歧的出现和积累，信任逐渐降低到冰点，士气低落，就标志着Storming阶段来了，多数失败的、名存实亡的项目和创业公司，就是倒在了Storming阶段；
- 如果团队渡过了这个难关，随着信任曲线的上升、经验的积累，团队开始自主调整资源分配、制定流程和规范，进入了Norming阶段；
- 正向成果的不断积累、失败经验的沟通和学习，让信任曲线上升到最高点，团队执行力也达到顶峰，进入长期的Performing阶段。
那么，作为团队领导者，怎样才能让这条曲线更快进入后半段呢？
要做的事情太多，这里分享一些是最关键的，每一条背后都有血泪教训。
首先，是关于人的决策。在Forming阶段，慎重对待每一个招聘；在Norming和Performing阶段，慎重对待每一个绩效评估，在研发领域，尤其要注意绩效评估中的“Fireman Bias” -- 感谢消防英雄的人一定会比感谢用防火材料盖房子的人多，就像只有扁鹊知道他大哥的医术最高。关于人的决策就是关乎企业和团队生死存亡的决策，“生死存亡”这个词很重，这是管理学常识，却经常被忽略。Sam Altman在那次被OpenAI董事会武断裁掉后说：
OpenAI is nothing without its people.
其次，每个阶段的关键点要做好。在Forming阶段，需要组织一些破冰活动，形成更紧密的人际关系，也互相了解其他成员的人格特质和能力模型；同时，也要把团队目标传递给每个人，让所有人都能真正理解“Why”。这点我经验不足，以前做的很不好，有条件最好请一些专业的Facilitator，帮助团队打造一个更好的信任起点。还有一个在Forming阶段要并行开始做的是Stakeholder管理，找全利益相关方，让他们在前期就及时了解、随时参与，这对建立更大范围的信任至关重要。
在Storming阶段，必然产生冲突，而这时候的冲突大部分是“建设性冲突”，管理者要作为一个连接者让各方充分沟通、交换意见，直面冲突、管理冲突，而不是避免冲突。要是有冲突解决不了怎么办？找上级领导吗，错！这是一个非常好的机会，让团队成员抛开当前的问题，共同想想我们决策的准则是什么。在决策准则上达成了一致，所有的冲突拿这根尺子一量，自然有了答案，。那么，要是决策的准则也无法达成一致怎么办？那又是一个很好的机会，讨论团队的价值观是什么，大部分情况只要“以用户为中心”、“以公司整体利益为重”、“关心人的发展”这样几个普世价值观的尺子，就足以衡量出决策准则孰优孰劣了。
在Norming阶段，是资源调配和流程确立的关键时期，团队发展到这个阶段，有一些前期资源分配的问题就暴露出来了，树挪死、人挪活，这时调换岗位为时不晚。另外，前期经验不足埋下的风险也暴露出来了，要把每个风险视为一个改进机会，共创流程、制度，识别记录那些暂时处理不了的风险。我的经验是尽量不要管理者自己做，“微操”、“跨领域教人做事”是管理者的大忌，当好一个组织者和助推者，让团队成员充分表达意见，形成自发秩序，这就是Norming阶段的完美状态了。
在Performing阶段，那些曾经非常有挑战的事情，要么已经解决了、要么变成了可以轻松处理的日常事务，团队高效运转，不断输出有价值的产品和服务。在这个阶段，除了上面提到的关于人的最重要的事情“绩效和激励”以外，管理者要能看到团队文化，想办法培育独特的、符合团队发展方向的团队文化。
文化是一种像DNA一样，很难看到的强大力量，对提升工作满意度、保持高效状态至关重要。分享一些个人经验，我会通过一些小活动，或者表彰一些行为，来刻意打造独特的团队文化，我们的团队文化总结成了CCTL四个字母：
- Care -- 关心用户，代码通常只是20%的工作，帮助用户端到端解决掉问题才是100%
- Collaboration -- 只做协作双赢的事情，Win-win or no deal
- Transparent -- 信任是结果，公开透明是前提
- Life-long Learning -- 终身学习，无限进步
最后，作为团队领导者，在任何一个发展阶段，都要去感受团队内部的信任程度，一旦出现信任危机，不要急于下结论，就事论事、坦诚沟通，想办法恢复信任水平。团队的执行力是结果，一切效率来源于《信任的速度》。
《相变》-- 创造力不能被计划
从天文仪到蒸汽机
《相变》的英文标题“Loonshots”是一个生造词，对应”Moonshots“，形容像登月计划那样的疯狂项目。与登月不同的是，“Loonshots”项目不被重视、维护者被认为是“疯子”。雷达、心脏病药物、喷气式飞机、蒸汽机，这些改变世界的发明是怎么问世的呢？
作者借用了物理学的“相变”概念，解释这些发明怎么 在不经意中酝酿出来、突破了哪些阻碍、经历了哪些曲折，最终量变引起质变，跨过临界点一举扭转世界线。
这本书副标题“How to Nurture Ideas That Win Wars, Cure Diseases, and Transform Industries”已经总结全书内容，我们从中找几个有意思的案例，管中窥豹。
给我印象最深的是，作者用相变理论回答了“李约瑟难题”：为什么科技革命发生在欧洲？
一千年前的北宋已经是工业奇迹，天文、航海、金融领先欧洲将近600年，为什么没有进一步发展出科技革命和工业革命呢？
《相变》第9章对比了宋代沈括和500年后丹麦第谷的天文学研究，双方都得到了统治者的支持，都招募了出色的数学家助手（魏璞和开普勒），都因为统治者更替的政治因素被流放。但关键区别是：宋朝皇帝认为沈括的天文仪已经足够好了，停止了天文学的研究，而丹麦仍然继续支持第谷的研究。沈括晚年隐居山林，“只能与毛笔和砚台交流”。
多么可惜啊，一个伟大的项目，在萌芽、发展期被扼杀，再也没有机会达到相变的临界点。
另一个有趣的例子是蒸汽机的发明。1685年，在英国皇家学会，波意耳实验室的法国医生帕旁，改造了胡克制作的空气泵，两年后他出版了一本叫《Digester of Bones》的“烹饪书”，讲怎么用这个高压锅装置压碎骨头。英国皇家学会虽然没有重视这个装置，但学会提供了最早的专利机制和奇思妙想的摇篮。终于，到了1712年，纽可曼把这个装置改造成了实用的蒸汽机，跨过了相变的临界点，再后来就是大家熟知的瓦特改良蒸汽机的故事了。
那达成“相变”的条件是什么呢？作者也给出了答案。
创造力的摇篮：布什-韦尔平衡
200年后的美国，AT&T CEO韦尔建立的贝尔实验室里，产生了8个诺贝尔奖，点开了人类的信息革命科技树。这些创造奇迹的组织有什么共同点？作者出的答案是“布什-韦尔平衡”。在这个平衡点上，发明家自由发挥创造力、工程人员快速将技术落地。
具体来看，构建这样的平衡，需要把“艺术家”和“士兵”两个群体相态分离、再提供恰到好处的交流频率，让二者保持动态平衡。“艺术家”指的是有各种奇思妙想的科学家、发明家们，在宽松的环境下让“艺术家”自由发挥；“士兵”指的是带着专利解决现实问题的职业经理人、工程师、工人们；给二者提供恰到好处的交流，让双方平等的互相反馈。这种状态被称为“相态分离”。
为什么一定要相态分离呢？一个很明显的原因是“艺术家”是允许失败的，而“士兵”不能失败，各自的优势也完全不同。
为什么要有持续的交流呢？反过来想，没有足够的交流，“艺术家”的研究一定会变成空中楼阁，而失去创造增量的“士兵”一定会陷入存量竞争逐渐僵化。
布什-韦尔平衡，其实就是现在企业和高校都在说的“产学研融合”的最佳状态。
无心插柳柳成荫
在读到这本书之前，我并没有系统性理解“布什-韦尔平衡”这个培育创新的机制。回顾以前团队成员和我自己迸发创造力的瞬间，惊讶的发现整个过程确实如此。我一直在践行谷歌80-20的做法，留出20%的时间去折腾各种新技术，我也告诉团队成员都可以花20%的时间学习自己想学的东西，哪怕和项目没什么关系。
我自己的一个例子是关于WebAssembly的，多年前了解到WebAssembly技术，竟然可以在JavaScript Runtime跑任何主流的编程语言，真是太酷了。虽然80%的时间都是”士兵“，留出的20%的时间，在脑海中塑造了一个“艺术家”，允许失败，肆意探索。
前段时间这颗种子发芽了，云计算相关的开源项目大多是Golang，如果编译成WebAssembly不就可以把编译型语言做成函数插件，随意组合使用了吗？于是，我们把Helm、Nomad都编译到了运维引擎中，也编译了一些Rust库进去，开发过程中一位同事甚至还修复了一个Golang的Bug！
我们团队当初那些“无用”的技术储备和算不上发明的小创新，在项目中都起到了重要的作用。如今，WebAssembly在Web后端和云计算领域的应用越来越多，这个本来为了解决“在浏览器运行旧软件”的技术，也是无心插柳柳成荫了。
卓越的研发团队一定不是完全循规蹈矩的、按部就班的，而是能够时不时创造出前所未有的技术和方法，轻松解决掉一些棘手的问题。创造力是团队的源头活水，也是卓越研发团队必不可少的要素之一。
总结
我们从《决断》、《信任的速度》、《相变》三本书出发，找到了战略目标决策、构建信任、培育布什-韦尔平衡这三个关键思想，以及卓越研发团队要具备的产品力、执行力、创造力三个要素，回顾了我们团队做的好的地方、要改进的地方。
Tim Pan创建的影视飓风公司有句Slogan：“无限进步”。的确，追求卓越没有止境，让我们在产品力、执行力、创造力上一直前进吧！