我当初是怎么管理技术团队的 - 旁观者 - 博客园

标签: 管理 技术 团队 | 发表时间:2017-06-19 20:15 | 作者:
出处:http://www.cnblogs.com

此文为早期文档

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

-第一节完-

头图图片来源于必应搜索

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

 

相关 [管理 技术 团队] 推荐:

关于技术团队管理的胡言乱语

- - 博客园_知识库
  临近年底,接到《程序员》杂志的邀请,希望我能写一篇与团队管理有关的年终盘点文章,盘点2013年业界与团队管理相关的大事. 试想,揪出各个公司在2013年的各种“大事”,指点江山,激扬文字,那种众人皆醉我独醒的感觉是相当的妙不可言. 可细细一想,2013年可以归纳为团队管理大事的事件倒是不少,例如Yahoo!美女CEO宣布取消在家办公制度,最近又按照绩效评估结果排名开始裁员;最近知乎上好事者提出的“你问什么离开xx公司”系列,各种回答纷至沓来,为2013的团队管理大事记提供了不少素材.

我当初是怎么管理技术团队的 - 旁观者 - 博客园

- -
关键词:管理技术人才、管理技术团队、技术传承、对题集/错题集、研发哲学. 窝窝技术团队大约两三百人左右,主要是五大块:研发、数据、无线、质量、运维. 2012年年初,一个大项目结束后,我召开了飞行研讨会,经过这次深刻反思,形成了几个影响深远的管理观点:. 管理者要向下提供工具,以形成干部的简单、易记忆、易执行的工作套路.

资深CTO:关于技术团队打造与管理的10问10答

- - 博客园_新闻
在打造和管理一支强大的工程技术团队方面,Adil Ajmal 有着绝对丰富的经验. 他曾在 7 家公司负责过技术团队的组建与管理工作. 他曾在 TenMarks 担任过 VP 和 CTO,这家公司后来被 Amazon 收购. 他也在 Posterous 担任过技术负责人,这家公司后来被 Twitter 收购.

技术出身的创业者管理销售团队的七条成功秘笈

- - 互联网的那点事
销售是公司的血液供应线,销售管不好公司可能会走向破产. 作为技术出身创业者如何管理公司销售团队尤为重要,小编在此摘录一些相关销售案列供大家学习参考. 挑个好销售太难了,你不懂销售怎么判断呢?我认为要想把复杂的看人角度简化的话,你主要判断他是否会勤奋以及他是否知道销售工作流程就够了. 多数半吊 子销售人员其实并不知道单子是怎么拿下来的,他们通常只能跟你说”我要满足客户需求,我要让客户知道我们的产品和服务能够和他需求对接”.

团队管理101招

- 狂之想 - C++博客-牵着老婆满街逛
转载自:http://www.iteer.net/modules/doc/article.php?storyid=1402. 无论你是新手还是资深管理人,对你而言,管理好团队都是重要且具激励性的挑战. 切记:每位成员都能为团队作出一些贡献. 谨慎地设定团队目标,且认真严肃地对待它们. 尽早决定何种形态的团队适合你的目标.

谈团队知识管理

- - 人月神话的BLOG
如果要谈学习型团队,那么团队知识管理就相当重要,团队知识管理介于企业知识管理和个人知识管理之间,核心是知识能够成为整个团队的资产,并为团队创造价值. 今年在团队知识管理上,重点就是按照cmmi的一些思路,形成指导书,规范流程,工具模板,培训教材,检查单的完整知识库积累. 明确各个岗位职责和分工边界,能够按着规范流程做事情,大量前期积累的知识库又能够帮助团队成员快速的学习和解决问题.

谈技术团队目标

- - Tim[后端技术]
技术主管新年想得最多的一件事必定是如何比上一年做得更好. 宏大的目标设定每个团队都会做,谈几个不引人注意的小问题. 见过一些技术团队将计划定义为“按时完成需求”,需求驱动并没有什么不对,但是研发工作仅考虑被动需求的话是很难做好. 之前完成的许多需求有什么共性. 经常出问题/bug/故障的项目/功能/模块是哪些.

小团队管理与大团队管理

- -
如有好文章投稿,请点击 → 这里了解详情. 我们公司和大部分传统软件公司一样,随着业务的发展和新领域的开拓,公司的管理风格越来越像华为,这是不是最佳的演进路线,我觉得值得探讨,以下是我的思考,希望跟大家讨论. 前段时间跟一个创业的朋友聊天,说起他们最近在做的一个项目,这是一个教育行业的管理系统,业务非常复杂,牵涉到的决策人,需要对接的系统也非常多,最后问到他们做了多久完成这个项目,朋友告诉我2个多月,6个人,其中还括一个美工,一个项目经理;剩下的都是开发人员,没有测试,没有前端开发;朋友问我,如果这个项目给你们做,你们需要做多久;我想了想说,这个项目如果交给我们做,顺利的话,至少要半年.

在Google管理一个软件团队

- - 博客 - 伯乐在线
伯乐在线注:2003年到2010年期间,原文作者 Matt Welsh 是哈佛大学工程和应用科学学院的计算机科学系教授. 在我离开学术圈之后,我常常被问及我在Google的工作是怎样的. 我猜想从终身教授到 软件工程师的转变听起来像是个巨大的落差. 抛开职位不说,我现在比起前面在哈佛的8年,工作更快乐也更高效,尽管做教授和管理软件团队有很多相似之处.

如何提高团队管理能力?

- - 人人都是产品经理
接手任何一个部门的最重要的事情,是明确或者重新调整组织架构. 架构的关键是:谁在什么位置,负责什么内容,一定要明确. 出了问题,大家都清楚谁应该出来承担责任. 领导不是决定怎么爬梯子的人: 他是决定把梯子搭在哪个墙上的人. 所以他必须明确的指出这个方向,向全员传达. 如果这个没有做好,再优秀的团队也不会拿出好的结果.