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

此文为早期文档

建立于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.组织架构随需调整

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

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

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

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

-第一节完-

头图图片来源于必应搜索

欢迎订阅个人微信订阅号『老兵笔记』