“三新”团队如何克服成长的烦恼？ | 线上分享
小欧有话说：
为了加深EGO会员之间的相互了解，同时也为更多的技术人提供相互学习交流的机会，EGO开展了每周四21:00的线上分享活动。本文根据第25期嘉宾——刘天胜9月8日线上分享内容整理而成。
大家好，我叫刘天胜，是EGO上海分会第四小组成员，2014年加入上海讯联数据服务有限公司，目前担任CTO职务，公司是一家支付服务商，主要业务方向是为境内外机构和商户提供扫码、Apple Pay及银行卡交易处理和数据服务。我在加入讯联数据前在一家外企从事研发工作。平时主要关注的技术领域有高可用高并发、微服务架构、信息安全、性能优化、研发流程改进等。
在讯联数据，一些新兴的业务和创新产品是由新组建的团队采用不同于传统系统的方式从零开始不断迭代开发出来的，相信其他公司也是类似的。
我们把此类通过各部门抽调和招聘临时组建起来利用新技术研发新产品的新团队简称为“三新”团队。在此过程中所遇到的典型问题以及由此引发的“放大效应”称为“三新”团队成长的烦恼。
目前，在支付行业大趋势下，随着一些新兴业务的红火，经过我们系统处理的交易量也不断攀升新高，架构不断地演化，“三新”团队经受着一轮又一轮的考验，遭遇并克服着成长的烦恼。今天以一个团队为例跟大家聊聊在这个过程中，我们的一些思考、遇到的问题以及是如何克服的。
在每家公司和每个团队的成长中总会面临很多抉择时刻，但肯定都是在当时的条件下做出的最合适的选择。那么，在当时组建一个“三新”团队、启动一个项目时，我们是如何考虑的呢？
2014年以来，支付行业风云际会、暗潮涌动。随着移动互联网的普及，支付行业在业务模式和新产品上不断探索，涌现出很多创新产品，大大地拓展了支付场景。我们公司作为服务商也一马当先，尝试了一些新的业务方向。当时的一些考虑是：
1）业务上，与传统银行卡支付相比：
存在不确定性：新兴支付方式很多，都在发力中，局势尚不明朗，政策上存在很大不确定性，需要快速应变；
参与方不同：传统支付体系的核心是由卡组织、发卡行、收单行和商户组成的四方模式，而一些新兴支付体系中除了商户外，其他的角色感觉一家都干了；
做事方法不同：传统支付重视流程、规范和收益分成，而一些新兴支付是互联网做法，玩法灵活多变，喜欢烧钱，攻城圈地，赢者通吃；
支付场景不同：传统支付是在单纯地解决支付问题，而新兴支付模式除了支付功能外，还能将商家和顾客连接起来，演化出更多的场景，为商户创造更多的价值。例如微信公众号内的打赏功能，支付宝服务窗内的抢优惠券功能等。
2）技术上，新兴支付也跟传统刷卡支付在交易流程、接口接入和安全上存在不同。
所以，需要跟公司核心稳定业务区别开来。
当公司决定开展新业务时，我们又面临着一个选择题：是让公司最熟悉业务的同事进行开发，还是让新组建的团队来做？我们当时选择了后者，主要的考虑因素如下：
1）打破固化思维
2014年，我们核心的开发主力都是从事传统支付系统开发的，对传统卡组织规范烂熟于心、经验丰富。但如上面所说的新兴支付跟传统存在一些不同，我们期望有些不一样的实现。而且，当时我们有几位新同事组成的小组虽然刚入职不久、支付行业经验欠缺，但技术水平相当不错、迭代速度也快、承担的任务完成的都很漂亮，能够胜任此项工作。
2）消除排期魔咒
当时，我们的核心开发任务排期非常紧张，如果再复用人员排上此项新业务，迭代速度会比较慢。同时，也担心会给已经稳定的核心业务带来扰动，毕竟人的精力是有限的。而新组建的小组排期没有那么紧张，前端市场压力也不是太大，工作更容易掌握主动权，实现快速迭代和试错。
3）拓展想象空间
新鲜血液因为背景的不同可以带来新的设计思路和实现方式，充满想象空间，值得一试。
采用新技术来实现新兴业务引起的争议较大，也确实带来一些困难。我们当时的考虑如下：
1）客观现实的制约
我们的核心系统是用C和Java写的，已经非常稳定，在上面堆加功能相对容易，但支持一个灵活多变的新业务存在一定困难。整个系统架构经过了几轮的优化和拆分已经很庞大，不是三两个人能驾驭的。而且，承担创新业务的这几位新同事对这套技术体系和C语言也不太熟悉。于是，我们首先排除了 C 语言；
2）时髦技术的甜头
这几位新同事原本都是Java开发经验很丰富的同事，如果用Java自然轻车熟路，但是当时我们的一个秒杀系统是用 Golang 写的，也亲身体会到Golang的简单高效以及在实现高并发后端服务器程序方面的优势，所以开发语言方面，我们选择了 Golang。
3）技术储备的初心
就像Golang一样，我们期望能通过这个项目的实践探索一些新技术进行技术储备，于是，我们陆续选择了MongoDB、Polymer、亚马逊、阿里云等相对于传统支付系统而言较为时髦的技术和云平台。
随着新兴业务的普及、交易量增长较快，作为一个“三新”团队，遇到的困难也更多一些。在这个过程中挖坑填坑，有时感觉像漂流一样，高风险强刺激。
曾经有段时间，故障发生频率较高，团队承担的压力大，加班熬夜甚至通宵达旦都是常事儿，我也因此有好几夜失眠。在发生故障时，前后端同事承受着巨大压力，尤其前端市场和业务同事需要不断向客户道歉、解释，后端开发和运维同事也需要在极短的时间内定位和解决问题。而面对这一切，作为一个已经不再写代码的CTO有时恨不得亲自上阵。那种表面镇静、内心惶恐的感觉，唯有亲身经历才能体会个中滋味。记得有一篇InfoQ 对 EGO会员饿了么 CTO 张雪峰的专访标题是“未长夜痛哭者，不足以语人生”，当时读到这个标题，感觉真是太贴切了。
概括而言，遇到的典型问题可以归纳为以下三个方面：
1）对新业务的理解不够
新业务跑的快、上游合作方提供的一些功能和接口还在不断演化，也缺少必要的文档说明，以至于我们在实现一些功能时只能通过猜测先做了再说。在后续业务量大时，一些隐患就逐渐暴露出来了。同时，因为新同事对业务缺乏了解以至于公司的一些经验没有得到很好的传承。
2）对新技术的驾驭程度有限
因为对于新技术的认知有限，有时会根据经验设计一些场景甚至会误用一些特性。例如，有一次我们做秒杀优惠券活动需要导入数百万数据，导入前评估这点量对于数据库而言应是毫无压力的，并在测试环境测试通过。但在生产上导入这些数据后，却发现MongoDB副本集的主从库不同步，其中的从库处于recovering状态。研究了各种恢复方法，只能采用夜间停机、从库重建的方式才能解决。
同样因为尚不能完全驾驭新技术以至于在业务需求猛增时依然需要花费很大的精力去解决一些基础性的技术问题，造成排期不靠谱、迭代较慢、交付质量也难以提高。此外，用新技术，相关的开源组件和典型解决方案较少，招人也很困难。
3）对新团队的管理欠缺
由于是新组建的团队，大家技术水平都不错，在还未磨合好时，有时谁都不服谁，对一些研发流程、代码规范、设计方案存在分歧，也无形中增加了很多沟通成本。
1.短期而言，问题驱动、对症下猛药，期间得到的一些经验是：
a)跟业务同事一起共同解决问题
当面对问题时，业务和技术相互配合，大家齐心协力从不同的角度出谋划策，而不是彼此推卸责任，对于快速定位和解决问题至关重要。
b)完成比完美重要，业务比技术重要
在遇到故障时，时间就是金钱，快速的解决问题比一个完美无缺的方案更加重要。例如，一些生产场景下，查询请求对数据库的压力突然加大，我们面临一个选择：直接在实时交易库中用MongoDB的 auto sharding 做水平扩展，还是采用数据同步做冷热分离。官方和一些朋友建议用前者，但如果采用MongoDB auto sharding，我们需要生产停机，而且需要在很短的时间内现学现用，风险较大。而做冷热分离，我们以往的架构优化经验可以充分利用，当然也不需要生产停机，风险可控。此外，还有人员因素，我们DBA的人力资源比开发资源要紧张的多。于是，为了尽快上线并控制风险，我们最终选择了冷热分离，利用Golang开发了一套数据库同步工具和一致性校验工具，实时无误地将交易数据同步到另一个集群，供查询使用。同时，也准备了Plan B以防不测。
回头来看，这个方案较为保守，技术上也存在一些缺陷，没有充分利用MongoDB的特性，但是风险较低，保障了业务连续性，同时也为新技术探索争取了时间。如果再做一次选择，我想我们还是会这么做。
c)明确指挥权，让合适的人奋力一搏
对于一个“三新”团队来说，由于还未形成严格的故障等级体系，所以遇到故障时指挥权必须明确，避免群龙无首，无谓地消耗时间和战斗力。我们的经验可总结为一句话：首先点将，快速组队，明确指挥权，结合“矛”与“盾”，让合适的人奋力一搏。其中，快速组队是指快速组建一个问题应急解决小组，避免相关人员一窝蜂全上，无助于解决问题，也耽误了其他排期。结合“矛”与“盾”是指以这个问题应急解决小组作为“盾”，其他人作为“矛”，在很短的时间内去找这个小组给出的解决方案的漏洞，让这个方案更完善，但并不追求完美，如果有漏洞但不容易实现，想好应对方案即可。
类似的场景，以往我更多地掌握指挥权，但今年我在尝试转型，除了大的问题以外，更多地承担“矛”的角色，这可以让团队骨干得到更多的历练、主动思考、发挥潜能。这个转变谈何容易，“做”永远比“想”要难的多，记得在一本游记《再不远行，就老了》中有段话“你站在桥上看风景，看风景的人在楼上看你，……”，总之，把心放宽，故障解决了，团队成长了，问心无愧就好。
d)学会自我减压以及为团队减压
Leader的状态对一个团队的战斗力是至为关键的，而关于如何缓解压力，我很长一段时间处理不好，但逐渐找到一个药方，学着控制自己的情绪。比如当压力大甚至有负面情绪时，就想想我们的CEO，相比CEO承受的压力，我们这点算得了什么呢。于是，又鸡血满满，尽最大努力地想办法解决问题了。
2.长期而言，寻根摸底、规范机制、被动变主动
故障频发，总靠救火不是办法，业务也会受到制约，所以长期而言还是要寻求根本解决方案。我们通过下述方法，使这种情况得到极大改善：
a)确定跨部门沟通机制，站在对方的立场上考虑问题
与产品、运营等部门一起讨论新业务需求，逐步确定沟通机制，明确相互之间的接口人，让信息流动的更顺畅、让需求更明确。平时利用一些机会增进跨部门之间的相互了解，要学会换位思考，促进技术理解业务需求和相关背景，业务了解技术体系和系统架构。
同时，经常向同事传递一个理念：不同部门由于出发点的不同导致思路上会有差异，这是很正常的。只要大家整体方向一致，抱着解决问题的心，就事论事，适度的不同意见甚至争论是有益的。
b)调整研发人员结构，形成人才梯队
明确组织架构和汇报体系
就像杰克·韦尔奇在《赢》中所说，“一个新的组织架构，并重新明确工作职责，对于消除混乱状态有着积极影响”。对于一个“三新”团队更是如此，随着业务的发展，组织架构的调整也必须跟得上。有明确的接口人和汇报体系会减少很多沟通成本，执行力也会更强。
调业务经验丰富的骨干开发同事加入
开始时，从其他业务方向调人并不容易，毕竟各组人员和项目排期都很紧张，对这个组的技术体系也不熟悉，而且经过金三银四已经有核心人员流失，谁愿意跳出自己的舒适区呢？但在这样的关键时候，一些有担当的同事总会脱颖而出。Golang不会？学呗。新业务不懂，理理呗。遇到故障，两眼放光，不用叫他，也会向前冲锋，一起出谋划策。就这样，调动了几位这样的同事加入这个组使一些行业经验和流程规范得以传承。
鼓士气壮声势，发动学习Golang的热潮
为了建立梯队，增加人才储备，通过专门的技术分享会、one on one面谈、茶余饭后等多种场合，鼓励研发人员学习Golang和其他相关新技术，并支持开发同事利用这些新技术写一些小工具练手。通过努力，相关技术的基本盘得到极大巩固。例如，从最开始只有3位工程师了解Golang，到现在有近20位可以使用Golang进行开发，这已经大大地改善了人员结构。
知识共享，消灭信息孤岛
在一个“三新”团队，好多信息都是存在个别同事脑子里或者个别邮件内，人员更替就会带走一些信息。为消灭类似的信息孤岛，避免因信息不一致带来沟通障碍，我们建立了邮件组，要求相关业务和技术邮件抄送到这个邮件组。虽然只是一个小小动作，但却无形中培养了很多同事，因为有心的同事是不会放过学习机会的。
大力招聘，不拘一格降人才
直接招熟悉相关新技术的同事是非常困难的，所以我们就通过各种渠道招聘学习能力强的人才。不懂Golang没关系，只要愿意学就行。我们团队中的一员就是咱们EGO会员推荐的，非常靠谱，来到后不久就能独立承担一个产品的开发和维护任务。
总之，通过这半年的努力，这个团队虽然损失了几位核心同事，但更多的同事得到了历练，很多好苗子已经出类拔萃。虽然工作压力依然很大，但遇到问题时，现在每一位同事的脸上不再是胆怯而是兴奋，就跟发现了宝贝似的，这是一种自信的表现。有这样的团队，不担心会有过不去的坎，这是财富、团队之福。
就像《重新定义团队：谷歌如何工作》里描述的埃里·施密特所说，“管理者需要服务于团队，……，关注的重点不是惩罚或奖励，而是消除路障，激励团队”，我深以为然并以此为行动指南一直努力着。
c)重构代码和优化系统，努力形成常态
重新梳理业务流程和系统架构
为了根本性地解决一些问题，我们曾经抽调人手形成混编团队，进入War Room重新梳理业务流程、重构核心代码、完善异常处理、消除隐患，并根据业务进行了垂直和水平拆分，降低了业务模块之间的耦合；
专人专题进行系统性能和架构优化
为了长治久安，我们听从了EGO会员、喜马拉雅FM CTO 陆栋栋在一次EGO小组分享中的建议，在各小组安排了一位技术能力较强的同事，减轻他业务需求排期的压力，主要从事内部优化工作。经过类似的安排，日志统计与分析、数据库优化、容量规划和架构演进等业务同事不怎么关心的重要事项都在有序进行中，并已形成了常态化分析和优化机制。同时，系统灾备体系也在从单一机房向混合云演变。
d)传承、改进并严格执行研发流程
我们其他研发团队经过多年的积累已形成了较为完善地版本发布、变更管理和技术审核流程。最开始想直接把此类流程规范照搬到这个“三新”团队，但实际执行效果并不好。后来，利用一些故障和争论机会，结合这个团队的特点适时引入，以及利用各种场合向同事传达统一团队行为准则的重要性，大家逐步能接受，然后制定纪律要求严格执行，效果不错。这里，我们得到一个经验就是做任何事，掌握时机很重要，在没有到那个点的时候，怎么努力都白搭。用心适时引导，胜过强制命令。
e)稳妥引入适合的技术和工具，积极但不盲从
技术人都是喜欢尝鲜的，但在利用新技术解决问题的同时，需要减少对业务产生负面影响。对于此，我们得出以下经验：
不为时髦而学，而是鼓励同事根据业务场景需要研究新技术，选择出适合我们的技术；
决定采用新技术开发前，需经过技术评审。技术评审时，除了考虑是否能解决当前问题外，还要考虑是否符合我们的技术体系规划，判断相关同事是否具备足够的驾驭能力；
新技术投入生产前需经过严格的功能和压力测试，并需逐步推行。每推行到一个新系统前，均要再经过一次技术评审，并进行复盘，总结其优缺点。
f)完善监控体系，加强故障管理
大家都知道，为了满足SLA要求，一方面要想办法减少故障的频率，另一方面还要提高故障的响应速度。例如：
建立全方位的监控体系，及时发现故障
将新业务纳入我们7x24小时有人值守的实时交易监控范围和客户服务体系内，并利用Zabbix、ELK和阿里云监控分别对系统、网络、应用、日志建立了监控，然后通过短信和邮件报警，大大减少了故障响应时间。
加强故障管理和响应
此外，我们进行了故障分类，并制定了二线支持人员排班计划，相关人员需要保持24小时手机开机或者在监控室内值守，有效保障了故障发现后及时得到处理。
但就算做了这些，我觉得我们还差得远，离行业领袖的差距还非常巨大，所以依然在不断改进现有监控。
加入EGO的这段时间正是我们业务快速增长的时期，团队遭遇成长的烦恼，同时也是我自己的瓶颈和转型期。此前，通过多次EGO组织的线上线下交流和分享，受益颇多。很多建议应用到团队中都能起到立竿见影的效果，所以我是EGO的受益者。借此次分享的机会，一方面是跟大家分享一下自己的经验和教训，另一方面也是向EGO，尤其是EGO上海分会第四组的同学表示感谢！
感慨一下，经常听人说，几十倍的业务增长，放着好路不走却自己找虐、瞎折腾，但我想说这不正是所有创业者的本色吗？走的过程是痛苦煎熬的，但走过后回头一看，无限美好、硕果累累……
最后广告一下，Golang确实是门不错的语言，虽然被“坑”了很多次，但已在我司开枝散叶，成蓬勃发展之势了~~~，所以也想利用这次机会发出英雄贴，如果大家有认识的朋友对于支付感兴趣，对于用Golang实现当前最热门的支付系统感兴趣，欢迎推荐！
本文由EGO原创首发，请获取授权后转载