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

此文为早期文档

创建于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这三年间所做出的管控策略。 我们认为管理技术人才是一门学问,第一,外行不可能领导内行,第二,靠挖人,靠猎头,一朝一夕之间不可能组建一支能打硬仗的技术团队,那只能攒出乌合之众。

-第一节完-

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

稿源:旁观者-郑昀 (源链) | 关于 | 阅读提示

本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » 后端存储 » 我当初是怎么管理技术团队的

喜欢 (0)or分享给?

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录