你的位置:首页 > ASP.net教程

[ASP.net教程]我们过去几年做对了哪些事


郑昀 创建于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-