当我们在说“效率”的时候,我们其实在说什么?

今天去听了一天的“工程效率”专场交流会。这次交流会邀请了Facebook, Amazon,Pintrest及上海几个知名大厂的工效团队负责人坐台。给大家分享了一下他们经历,方案及对于“工程效率”的见解。

整场交流会还是蛮成功的,尽管台下的听众只有几十人且一点儿都不活跃。参会嘉宾们讲的东西还是比较有诚意的。先从工程效率所解决的问题入手,从工具,理念,协同,流程,技术等方面的展开了分析与对话。该讲的基本都讲到了。有几个主要观点我是非常认同的(虽然并没有什么新观点,基本都是大家已经知道的东西)。

  1. 工程效率的本质,是解决复杂度问题,化繁为简,提高效率。
  2. 善用工具并且能把各个工具有机地串联起来,一提高工作效率的有效手段之一。任何需要被做两次以上的事儿,都值得自动化起来,避免低效的手工执行,但是又要避免过度自动。什么是过度自动呢?我的理解是判断都自动化就过度了。判断应该由人来做,判断好之后的处理,手工触发,自动执行,以免误伤。
  3. 工程效率要落地。可以以两个方面入手:
    1. 找到合作方,积极合作,共同推进。
    2. 找到真实的业务痛点(即使他们自己都不知道),并解决问题,提供价值。要以做产品,提供服务的心态来做工程效率。
  4. 工程效率不是一个技术问题。而是融合技术,人员与流程的综合性问题。我个人还想加上业务。因为业务不同,对效率的改进点的需要也是不一样的。
  5. 对于工程实践上的问题,没有银弹。不存在这样一个方案:每个公司拿去就能化腐朽为神奇创造奇迹。因为每个公司的成熟度是不同的,所适合的工程实践也会大相径庭。把一个公司跑得好好的方案照搬过来,跑不通还算好的,不好的是反而会产生严重的负面影响。每一个方案,必须是因地制宜地、因人而异的。
  6. 软件工程,与传统工程是非常不一样的。传统工程,做完就是完工了。而软件工程,做完只是开始,一个软件,从出生到消亡,始终都在发生变化。从外部的需求,到内部的技术方案,再到参与的人员,全部都是在持续变化的。
  7. 提高效率,要从最薄弱的环节入手,把瓶颈找到。有针对性地解决问题。
  8. 技术开放,以赋能扩展能力,而非以规范约束能力
  9. 每个公司间的文化不同,但是同一个公司,要上下一致,形成共识。这样才能劲儿往一处使。
  10. 工程效率的度量指标,不应该被纳入KPI或ORK,更不要以此为团队做排名,因为很容易产生误导。
  11. 不要写那么多文档,没人看。重要的处置方案,直接内化成系统功能。
  12. 系统不是设计出来的,是演化出来的。

另外想补充一个比较有意思的现象,因为本次与会的嘉宾比较多,会出现这样一种很奇妙的碰撞。阿里中间件的李云老师前脚说,团队是培养出来的,不是招聘出来的。后脚许式伟就在另一个话题上,表示严把招聘关是非常重要的,因为人是不可塑造的,“基本上大学毕业是什么样就是什么样了。”他们说得其实都对。但是话,都是有上下文的,脱离了上下文,单独去看,甚至会有些自相矛盾。

我下面想讲讲他们没有讲的。点也比较多,我争取讲得有条理点儿。

  1. 关于“工程效率的本质是降低复杂度”的论题,我有一点儿补充。假定工程效率本身的范畴包括:CICD,自动化测试,设计规约,代码审查,开发流程,发布流程,团队协作,工具打通并平台化,最佳工程实践的推广及开源。那么工程效率本身其实并没有降低复杂度。而只是把复杂度遮盖起来,让人们看不到。而上面这此东西的引入,其实反而增加了实际的复杂度(尽管不可见)。在平时的软件开发工作中,真正需要被降低复杂度的部分,是人为的额外的复杂度。比如一个用四则运算可以解决的问题,用了微积分来描述与求解。其实是人为地增加了复杂度。而在真实的项目中,这部分的复杂度,其实是远超工程效率所涉及的部分的。比如服务间的不必要的耦合,接口设计不必要地暴露了内部实现并强绑定,都会带来不必要的复杂度。而且,这种复杂度,影响范围更大,不仅仅会影响开发效率,还会影响服务的稳定性,可扩展性等。
  2. 老板们讲“工程效率”,本质上是指:“从公司整体,最终业务的层面,用更少的资源(一切成本,如:人,时间),办更多的事儿。”。个体的效能高,不代表整体产出高。但是个体效能低,整体一般也高不到哪儿去。所以工程效率,一方面是提高单兵作战能力,但是更更重要的,是团队协同作战的能力及规划调度的能力。
  3. 提高做事效率是一方面。但是在此之前,更重要的是明确,我们正在做的这个“事”本身。是不是必要的,有价值的。不然效率再高,也是无用功,白白浪费宝贵的时间。具体指什么呢?从最简单的,个人及团队层面上,要保证每个人不重复造轮子,起码做到一个公司内部,不要有两个人在做重复的事情。当然,B计划除外。从产品与技术的协同的角度,产品前期做好必要的充分调研,避免不必要的反复或返工。总结下来就是,专门的人或团队,用正确的方式,充分利用现有资源,做一次,做到位,推广开。

我在会上还问了一个比较尖锐的问题,经济学上有一个原理,就是劳动分工是生产力进步的原因,那么现在DevOps所倡导的,开发即运维,同一个组织或个人负责服务的方方面面,是不是与这个原理冲突呢?

有位嘉宾解释得比较形像,DevOps就像是工厂里的流水线。这个比较还是很贴切的。

我自己当然其实思考这个问题很久了,并不是在会上突发奇想想到的,所以自己其实是有自己的答案的。

在我看来,DevOps不是一个纯粹的方法论,而是一套体系,有方法论,有工具,有相应的人员素质模型要求。DevOps并不是真的要求开发人员去按传统的运维人员的样子去实施运维。DevOps是构建在现代的虚拟化的自动化的运维体系与工具链之上,在让运维本身接近透明的情况下,消解了开发、运维的协作壁垒,让开发能专注开发而且对于服务有更高的控制能力,从而提高了整体工作效率。这恰恰是分工的进化而非倒退。单就运维工作本身而言,运维已经比过去的搬机器、拉网线、登跳板,传文件,换硬盘的传统运维有了云泥之别。已经失去了成为一个独立的职业的必要。有些公司,打着DevOps的旗号,又没有执行现代化运维的能力,仅仅是为了强迫开发同时做运维,以求省掉运维的开支。这种DevOps,才是那种反分工的伪DevOps。

IMG_20190525_085747

发表评论

电子邮件地址不会被公开。 必填项已用*标注