我当初是怎么管理技术团队的

此文为早期文档

创建于2015/6/28

关键词：管理技术人才、管理技术团队、技术传承、对题集/错题集、研发哲学

本文档适用人员：研发干部

阅读大约需要二十分钟。

0x00，背景知识

窝窝技术团队大约两三百人左右，主要是五大块：研发、数据、无线、质量、运维。

2012年年初，一个大项目结束后，我召开了飞行研讨会，经过这次深刻反思，形成了几个影响深远的管理观点：

1. 管理者要向下提供工具，以形成干部的简单、易记忆、易执行的工作套路。

2. 干部要直面白刃战，必须随时能深入到业务细节。

3. 培训直到最基层，有案例点评，结合正反实例反复讲，有机会就讲，有机会就补充，有机会就强调，不断检查，不断重复。业务精英都是从五湖四海汇集而来，工作习惯、方式、话术、意识不尽相同，所以需要通过重复重复再重复、CheckCheck再Check，不仅仅要矫正错误行为，更重要的是指明什么是正确的行为。

随后的数年岁月里，首先我们在实践中形成了自己的研发哲学：

1. Don't make me think：凡是被很多人不断重复的好习惯，要将其自动化，绑定到工具之中，以"Don't make me think"的方式来推广最佳实践（best practice）。

2. If it hurts, do it more and often：如果一件事做起来很烦，那就把它拆成很多块儿，每天做一点，每次做一点。

3. 这个世界从来没有什么救世主：从来就没有什么救世主，要创造人类的幸福全靠我们自己，不要指望有什么人能救我们，只能绞尽脑汁闯阵。

4. 没有苦劳，只有功劳：没有结果就没有意义。不要期望公司因为你和小伙伴们有苦劳而宽容你们没有产出，这是一个商业公司。

其次，经过长期的磨合，我们认同如下理论：

企业的研发管理应该注重建立一个良性的循环：

1. 研发能力的提升，有助于促进研发效率的改善；

2. 研发效率的提升，使得研发人员可以有更多的空余时间，进而激发更多的研发活力；

3. 研发活力的提升，研发人员积极交流与分享，有助于提升研发人员的总体能力。

过去的软件开发方法论，往往只是注重了研发管理中的一两个方面，缺乏整体视角，常常期望以一套方法论包打天下。事实上，真实情况下的研发管理，需要至少三套方法论：

1. 提升研发能力，主要依靠经验积累，建立企业内部的知识库与传承体系（促进交流与协作，借助研发活力促进研发能力提升，也很重要）；

2. 提升研发效率，主要依靠科学的数据分析，建立或引进一系列的研发工具，建立合理的流程与制度（通过提升研发人员能力，激发他们不断改进效率，也很重要）；

3. 提升研发活力，主要靠多种社会化的沟通机制，促进分享与交流（给研发人员松绑，让他们有足够的空余时间，也很重要）。

我们从2012年开始推行的很多策略制度都暗合以上理论，下面展开讲一讲。

0x01，管控基本思路

=2012年=

1.1.RCA制度

话说2011年下半年，多个技术团队融合，又处于“飞行过程中换发动机”的重构期间，陆续出现了项目一再 delay、Bug 数迟迟不能收敛、相似问题在不同团队反复发生、刚修复的 Bug 又复现等现象，团队之间也互相抱怨。为了遏制这种势头，我组织了一些项目管理者和大家分享他们之前的成功经验，看看能不能从中找到解决之道。

2011年9月的一次分享会上，鲍嘉宝分享了他在上一家公司做飞信项目时降低 Bug 率的几个措施：

方案一：逐步落实质量保障措施

1. 增加 RCA（Root Cause Analysis，根本原因分析）制度，对 Bug 的成因进行分析和标注，定时汇总并通告，让开发人员集体增长问题解决经验，减少同类问题多次出现的概率；

2. 开展协议与接口规范讲解，降低使用方因为理解偏差或者使用随意造成问题的概率；

3. 强制推行编码规范，降低代码随意造成问题的概率；

4. 规范化技术方案实施与评审机制，降低逻辑层面与架构层面造成问题的概率；

方案二：Bug 评审会

1. 定期或不定期开展 Bug 评审会，清理库存 Bug，或者针对难以解决的 Bug 协商处理方案；

2. 评审会上对“解决 Bug”和“做新需求”的优先级进行明确安排；

3. Bug 评审会还具备其他职责，包括回归测试出现问题的解决方案讨论，上线前遗留 Bug 的处理措施的确定等。

最终，从2012年9月开始，研发体系正式推广 RCA 制度，双周一次 RCA 总结会，发送质量保障周报，公布每个开发任务的有效软件 Bug 数和千行代码缺陷率等指标。

当时的具体做法如下所示：

1）双周一次RCA总结会

主持人：质量控制负责人

形式：会议

面向对象：研发全体+质量控制全体

时间：每双周五下午14点～16点

开始执行时间：2012 年 9 月 28 日

规则：

1. 点评案例提前准备好，要点名；

2. 重点针对漏测 Bug ；

2.1. 兼顾有典型意义的 Bug；

3. 回顾每一个 RCA 案例时，做到：

3.1. 造成的后果或影响，

3.2. BUG的原因(一定要问清楚，说得太含糊可起不到警示作用)，

3.3. 漏测的原因，

3.4. 得到的教训，

3.5. 事后补救措施或改进方案。

2）每周质量保障报告

报告人：质量控制负责人

形式：邮件

发送范围：质量控制部全体，研发部全体，产品经理全体，SA 全体

第一份报告：漏测BUG简报

字段：

项目名称 上线时间 BUG描述 严重程度 发现人 线上处理办法 责任人 缺陷类型

第二份报告：项目质量简报

字段：

项目名称 提测时间 测试用例数 (预计)上线时间 有效Bug数 严重Bug数 严重缺陷率 平均Bug解决时长 千行代码缺陷率

在之后的几年里，我们在技术团队内部贯彻了 RCA 处理流程：

• 收集足够多证据

• 重新描述问题

• 现象没有描述清楚之前，切勿下结论

• 构建证据链

• 给出结论

• 线下重现

• 确认影响范围

• 纠正线上数据

• 制定防范措施

• 撰写 RCA 报告

• 公开通报（包括同步给其他业务部门）

• 纳入 RCA 案例库

时至今日，RCA 已汇总了七季，RCA 报告数百个，成为了研发体系的宝贵财富。

RCA报告的标准格式为：

1. 背景知识（Optional）

2. 问题现象

3. 影响范围

4. 问题原因

5. 问题分析过程（Optional）

6. 解决办法

7. 后续处理措施：如线上脏数据如何修复，如对用户造成的影响如何弥补等（Optional）

8. 经验教训

9. RCA类型：如代码问题、实施问题、配置问题、设计问题、测试问题

=2013年 - 2014年=

在设定2013年工作计划时，我明确需要解决如下三个问题：

1. 对产品的质量及细节（如稳定性、速度、体验等）的把控不足，

2. 团队的开发效率不够理想（如产品的迭代速度慢），

3. 技术团队对于行业关键技术的掌握能力偏弱。

我认识到，必须预留足够多的研发资源，优先解决技术团队日常开发和维护过程中遇到的痛苦。

那时候我们有哪些痛苦？

1. 开发联调环境、测试环境搭建和部署麻烦，动辄服务中断、接口，开发者为此劳心劳力。

2. 系统之间的数据同步，一般通过接口同步调用达成，不够可靠，不能保证最终数据一致性，遗漏后难以排查。

3. 层出不穷的定时任务难以管理，日志难以查看，常常是用户投诉了，我们才发现定时任务没有执行或者执行失败了。

4. 不能保证平滑上线，常常通宵上线。

……

于是，2013年集中解决制造工具、持续集成和过程透明化数据化这三件事。

1.2.制造工具

制造（或发现）什么样的工具 ？答案是：

1. 提高开发效率的 ，

2. 提高系统可伸缩和可靠性的，

3. 不同业务线可复用的。

方法是：

• 找到技术团队的痛点；

• 找到技术团队的生产效率低的原因；

• 抽象业务场景；

• 有针对性地深入了解其他公司如何解决的，梳理各种方案，向功课好的学生学习；

• 发现现有开源工具，或组织人员开发工具，制定和验证高可用方案 。

实例：

• 自动化测试

• 早期的自动化测试都是基于 QTP 的，比较古老。2013年开始，质量控制部一支人马开始基于 Robot Framework（Python）做，另一支人马则基于 Lazyman（Ruby）展开做。

• 持续集成

• 2012年大家想做持续集成，之后大家各自发展，一，主站全部切换到 gitlab 管理代码，二，由 hudson 或 jenkins 驱动构建，三，使用统一的 maven 库，四，去除那些影响构建和部署的配置项，五，运维部开发自动化上线的管理平台。

• 定时任务调度和管理 JobCenter

• 最开始是因为多个定时任务停了或天天报错，但无人知晓，直到用户投诉。

• 所以痛下决心整顿。开发中间件 JobCenter 花了三个月，推广又花了三个月。

• 异步推送 NotifyServer

• CMS 与商品中心之间的消息推送屡屡失败，引发各种问题和投诉，排查费时费力。

• 最终决定自行研发一个健壮的中间件 PushServer。

时至今日（注：指2015年），积累的通用技术工具有：

1. 前期基于StatsD+Graphite，后期基于OpenTSDB的智能监控解决方案-天机

2. 定时任务调度与管理系统-JobCenter

3. 内部统一认证系统-IdCenter

4. 异步消息可靠推送-NotifyServer

5. 分布式跟踪系统-鹰眼

6. 分布式缓存管理平台-Discache

7. 基于ELK的异常日志分析方案

8. 基于Diamond的持久化配置中心和业务降级方案

9. 基于ElasticSearch的搜索筛选排序解决方案

10. 基于FastDFS的文件上传和分布式文件存储系统

11. 数据库自动化运维平台

12. 基于Apriori算法的Nginx+Lua+ELK异常流量拦截方案

13. 基于TCPCopy的仿真压测方案

1.3.持续集成

 我在《窝窝研发过去几年做对了哪些事》一文中讲过：

每逢业务大跃进，就会欠下一屁股技术债。

是债就要还。

酷壳陈浩说过，技术债是不能欠的，要残酷无情地还债。很多事情，一开始不会有，那么就永远不会有。一旦一个事情烂了，后面只能跟着一起烂，烂得越多，就越没有人敢去还债。

首当其冲的就是线下环境和线上环境的维护和发布，大把大把的时间浪费在这上面，一代又一代的工程师在离职时表达了愤懑情绪。

于是，从2012年6月开始到2013年10月底，窝窝研发体系开始了持续集成第一季整改，万事开头难，这一干就是一年多。

所谓的第二季 CI，截止到2014年6月，至此，团购业务线基本做到了线下自动化编译、部署、测试（日检），线上自动化上线和回退。

第三季 CI 主要是让 PHP 工程（CMS和SWP）和前端（CSS/JS/Images）也接入自动化上线体系，截止到2014年10月底，基本完成。

目前，基于 Docker 的私有云深刻地影响着持续集成的方方面面，所有的环节都被改变了。

1.4.过程透明化数据化

2013年我在内部做职场培训时，以《职场（潜）规则：心法和技法》为题讲过：

十三）解释成本很高
彪悍的人生也必须解释。
前面说过，多数人都不太清楚其他板块和部门在做什么，是怎么运转的，管理方式是什么，人都投在哪儿了，为什么做这件事为什么不做那件事，那个外部投诉是怎么解决的，为什么一个我认为简单的问题你们却迟迟未解决。
如果我们没有做到冰箱陈列式的项目管理方式，如果没有养成信息第一时间同步、通报的习惯，我们就可能被迫事后解释。
当你需要解释的时候，其实已经有点儿晚了。
别人心中可能已经形成了观点，可能还传播出去了，你又保证不了你的解释能让该听到的人都听到，听到也不见得再帮你传播。

还会耗费你我大量时间解释，与其如此，不如提前主动通报、制定流程和信息同步。

所以我们应该有意识地遵循如下模式：

模式75 冰箱门

——团队成员定期地把各自的工作成果展现给团队所有的人。

项目产物的公开展示反映出团队成员之间的信任，它传达了一种信号——没有什么会仅仅因为主观原因而隐藏起来。没有人会因为让其他人看到了未完成的事务或进度延迟而担心。冰箱门型项目上的团队成员基本上不会去“偏袒”或者粉饰自己的进度报告。

 

所以，从2013年3月开始，我们试图一步步做到过程数据化 ，然后做到过程透明化：

• 按项目：

• 收集项目实施中的各种数据

• 资源投入、占用和释放

• 工时

• 加班工时

• 代码统计信息

• 测试用例数

• BUG数/严重BUG率/缺陷类型/解决时长

• 线上漏测数

• 千行代码缺陷率

• 按部门

• 细分到日的人员工作饱和度

• 技术分享和培训的类型和工时

• 过程透明化

• 每一个流转环节都向外部干系人通告，过程透明，数据可检索

• 提前发出延期预警通告

• 提前发出风险警示

1.5.预研药不能停

工程师文化中有一条：愿意投资比较长期的项目。是的，如果一个技术团队总被”紧急且重要“和”紧急且不重要“的事情牵着鼻子走，没有余力去做”重要但不紧急“的事情，最后一定是被动挨打，积劳成疾，最后病入膏肓。

我在《窝窝研发过去几年做对了哪些事》一文中讲过：

职场潜规则里我讲过，一定要低头拉车抬头看路。

最开始我们怎么抬头看路呢，那就是看淘宝这么多年都怎么过来的，他们在不同阶段都在解决什么问题。

冯仑说过，我们要把别人的历史当作自己的未来，这样，才能知道过去人家在做什么，我们现在应该怎么做。

于是，从2013年开始，我们抽调宝贵的研发人力，花费三四个月去做 JobCenter、NotifyServer、鹰眼、数据仓库，花费大量精力去测试 Dubbo、Cobar，做完这些还需要见缝插针地分批分期内部推广。

但这些提前量都是值得做的，否则我们很可能做着做着就“死做做死”了。

 

所以，药不能停，技术领袖需要眼光放长远，技术积累和传承不可能一蹴而就，中间的坑一个也少不了，不趟怎么知道有多少雷，曾鸣的话怎么说的：

什么叫战略？

——做对了一定会有好结果。

什么叫执行？

——中间的苦，一步也少不了。

时至今日（注：指2015年），我们提前预研了这些解决方案：

1. 基于mesos+marathon+consul+registrator+haproxy+docker的容器虚拟化方案

2. 基于Shib+Presto的大数据即席查询方案

3. 基于HUE+Oozie的Hadoop集群调度与管理

4. 基于Piwik+Flume+Kafka+Storm的推荐评测系统

5. 基于Cobar的水平分库方案

6. Disruptor在订单交易中的应用方案

7. 基于Ionic+Cordova+Saas+Bower+Angularjs+CoffeeScript+Gulp的HTML5移动开发方案

8. 基于ArtTemplate+FrozenUI+Backbone+Zepto的H5轻应用方案

9. 灰度发布平台

10. 运维自动化平台

11. 自助式报表解决方案

1.6.分享与学习的氛围

 工程师文化中还有两条：分享与学习的氛围强，让工程师有一定的冗余时间自我学习新知识。这也暗合最前面我提到的研发能力、研发效率和研发活力三者之间的循环促进关系。

为了激发研发活力，需要多管齐下，从2012年开始我们有意识去做：

• 定期举办技术分享讲座，当研发人员足够多，方向足够广时，Topic 还是有很多的；

• 为了开讲座，需要给主讲人预留出一定的学习和准备时间；

• 为了让大家有研究有思考有实践，不能把人全陷在具体业务逻辑开发上，不要过分追求低费率和性价比，明明10个人的活儿非让5个人干，最后项目也屡屡延期，一年到头技术团队也没进步。

其次，研发工程师要能够清晰表达。别人听不懂，多半是因为你讲不清楚，你讲不清楚，往往是因为你本来就没想明白没听懂，自然也就没逻辑。

所以，我们从新员工入职之后就有意识要求他们，在试用期内，新人必须做一次技术分享和一次技术评审，面对各方的 challenge，逼着大家学会公开陈述和清晰表达。

以后，我打算实行讲师制度，效仿微博的新兵训练营，申请预算，为训练营讲师的课件制作和授课支付费用。

1.7.组织架构随需调整

当组织结构影响效率时，就要动动组织结构了 ，干部都得抬抬屁股动动窝了。

首要目的是要避免以部门为沟壑。何谓沟壑？阻碍了问题排查或解决，阻碍了技术方案的推行，某类型工程师过少形成管理死角或不利于技术进步，这都叫沟壑。

有时也可能为新业务线提供骨干和人员。这都需要调整部门结构。

以上这七点就是窝窝技术团队在2012、2013、2014这三年间所做出的管控策略。我们认为管理技术人才是一门学问，第一，外行不可能领导内行，第二，靠挖人，靠猎头，一朝一夕之间不可能组建一支能打硬仗的技术团队，那只能攒出乌合之众。

-第一节完-

头图图片来源于必应搜索

欢迎订阅我的微信订阅号『老兵笔记』