我们过去几年做对了哪些事

郑昀 创建于2014/11/10

关键词：财富观、对题集、一票否决、业务收敛、持续集成、预研、培训、公开演讲、传承

---

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

提纲：

1. 研发财富观——问题和事故都是财富
2. 挤出人力做预研课题
3. 减少痛苦和抱怨——持续集成
4. QA一票否决
5. 风险收敛——关键业务逻辑收敛到业务中心
6. 技术分享和职场培训并行 

---

0x00，我们一定做对了什么，当然，也做错了很多

话说曾鸣教授曾曰过，

什么叫战略？

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

什么叫执行？

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

对于我们而言，经历了多年的血雨腥风，勉强算是屹立不倒，肯定是做对了某些事情，当然做错的可能更多。

 

0x01，研发财富观：问题和事故都是财富

对于事故处理，航天有二十字诀：定位准确、机理清楚、可以复现、措施有效、举一反三。

我们从 2011 年开始，一直坚持每错必查、错了又错就整改、每错必写，用身体力行告诉每一个新员工直面错误、公开技术细节、分享给所有人，长此以往，每一次事故和线上漏测都会变为我们的财富。这就是我们的 RCA（Root Cause Analysis）制度，截止到目前已经收集整理了近两百个详尽的 RCA 报告。

 

54chen 曾经说过：

如果在你的公司里，故障报告与工资是挂钩的，恭喜你，制度用错了。 故障报告的本意，是让发生的故障告诉所有的人，让所有的工程师都学到，这次故障的起因是什么、如何避免。 故障报告绝对不是用来惩罚和警告你犯错了。

 

是的，熟知一千零一种死法，还会让我们变得每逢大事有静气：靠，老子什么没见过。

 

0x02，挤出人力做预研课题

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

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

 

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

于是，从2013年开始，我们抽调宝贵的研发人力，去做 JobCenter、NotifyServer、Tracing 等研发解决方案或中间件，花精力去改造 Dubbo、Cobar 等开源系统，做完这些还需要见缝插针地分批分期内部推广。

 

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

 

0x03，减少痛苦和抱怨——持续集成

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

是债就要还。

 

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

 

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

于是，从2012年开始，我们开始了持续集成第一季整改，万事开头难，这一干就是一年。

第二季 CI 做完后，至此，主营业务线做到了线下自动化编译、自动化部署、自动化测试（日检），做到了线上自动化上线和回退。

第三季 CI 主要是让前端（CSS/JS/Images）也接入自动化上线体系，2014年年内完成。

 

当然，这些还不够，离我的研发哲学所言"Don't make me think"还有很长的路要走，还得跟随容器虚拟化闹革命。

 

0x04，QA一票否决

在这里，QA 的话语权很大，说你质量不达标，就是不能上线。线上运维部对接 QA 的配置管理组（CM）。

当然，最开始可不是这样，在业务部门的压力之下，在业务部门为我们锁定了 Deadline 的情况下，即使版本带着伤，也得上。

忘了从 2011 年哪天开始，终于拨乱反正：QA 的 CM 规划版本，QA 对线上质量保障负责，上线日期以 CM 输出为准，业务部门可以提出意见建议，但无权要求上线日期。

 

这样，CM、DBA、SA 作为上线发布的看门人，用非黑即白的规则倒逼上游的研发、产品、需求方改变。

 

0x05，风险收敛——关键业务逻辑收敛到业务中心

可能本来就该这么做，业务收敛，避免不同 IT 系统对数据增删改查，引入脏数据风险，埋下各种隐患。

当然，因此会导致中心化，会让一些业务中心变为整个系统的瓶颈，非常容易导致系统雪崩。历史上也确实多次发生过此类灾难性场景，某个业务中心阻塞，导致上游工程受影响，全站被迫业务降级。

 

在2011年年底，趁着一个大项目，我们把业务收敛的重构需求揉进去，导致了项目进度的严重不可控。但现在看来，这也是躲不开的苦。

54chen 曾就 Java 的积重难返曰过：

曾在一处见到，淘宝在长期使用 java 构建 web 项目后，得出一个结论：积重难返。

实际工作经验得到的结论，积重难返的原因，往往不是 java 本身的缘故，而是团队成员基础积累参差不齐，许多次的“一不小心”积累成了最终的结果。到了悔之晚矣的时候自然就积重难返了。如何避免 java 使用自伤，最关键在于，统一团队成员的 code 入口，框下可能发生的事情，避开不能发生的事情。

 

对于一个快速发展起来的技术团队，统一团队成员的 code 入口，框下可能发生的事情，最简单的就是业务收敛，商品、门店、商户、用户、订单、支付、库存、积分、评价、优惠……，甚至有时候连查询都框起来。

 

0x06，技术分享和职场培训并行

首先，一个所谓有技术传承的技术团队，注定需要大量的定期的技术分享讲座，为什么呢？

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

1. 研发能力的提升，有助于促进研发效率的改善；
2. 研发效率的提升，使得研发人员可以有更多的空余时间，进而激发更多的研发活力；
3. 研发活力的提升，研发人员积极交流与分享，有助于提升研发人员的总体能力。

 

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

1. 提升研发能力，主要依靠经验积累，建立企业内部的知识库与传承体系（促进交流与协作，借助研发活力促进研发能力提升，也很重要）；
2. 提升研发效率，主要依靠科学的数据分析，建立或引进一系列的研发工具，建立合理的流程与制度（通过提升研发人员能力，激发他们不断改进效率，也很重要）；
3. 提升研发活力，主要靠多种社会化的沟通机制，促进分享与交流（给研发人员松绑，让他们有足够的空余时间，也很重要）。

 （注：以上阐述来自于庄表伟）

综上，为了激发研发活力，需要多管齐下，至少我们应该做到：

• 定期举办技术分享讲座，当研发人员足够多，方向足够广时，Topic 还是很多的；
• 为了开讲座，需要给主讲人预留出一定的准备时间；
• 为了让大家有研究有思考有实践，不能把人全陷在具体业务逻辑开发上，不要过分追求低费率和性价比，明明10个人的活儿非让5个人干，最后活儿也屡屡延期，一年到头开发组织也没进步。

 

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

所以，我们需要从入职之后就有意识地训练大家，让大家能够公开陈述、清晰表达。所以，试用期内，新人必须做一次技术分享和一次技术评审，面对各方的 challenge。

 

第三，面向中层干部，我们不定期做职场培训，截止到目前已做了十期培训。

纯银曾曰过：一家公司战斗力的强弱，取决于中层里边，有多少业务精英，而且是本部门核心业务的精英出身，不是其他业务领域的精英升中层然后调动过来。这是一个相当粗暴的判断，中层本人的业务技能水平极大地影响整个部门的战斗力。

本部门业务精英也是从五湖四海汇集来的，工作习惯、方式、话术、意识不尽相同，所以需要通过重复重复再重复、CheckCheck再Check，来矫正错误行为，并指明什么是正确的行为。

 

最后，我们的中层干部终究有一天将成为领军者，组队单干，还有不少员工离开后成为创业公司的技术合伙人。这些人需要用技术分享来构建专业技术形象。再引申一层，我们的干部在大公司里也千万不要放弃对自己核心技能持续磨练。什么是核心技能？谈商务，公众演讲，出方案，画原型，写代码，部署，维护，培训员工……

 

小结：对题集

我们不能只是为了不白交学费而整理错题集，还需要梳理过去几年我们做对了哪些事情，让正确的行为一代一代传承下去。

 

-EOF-