SaaS服务的软件研发型组织技术发展困局

本文假设针对提供SaaS服务的软件研发型组织，其它类型涉及IT系统的组织也可从中获得借鉴。本文属于个人思考心得总结，如有理解不当偏颇之处，还请各位不吝指教。

一、困局

先上三个图，分别说明企业，特别是成长型企业，所面临的普遍困局，下面是第一个：

图1：方型轮子困局1

这个图对于从大公司（如BAT）跳到初创和成长型公司的童鞋来说感触特别深刻，你跑到随便一家刚刚熬到B或C轮融资的互联网公司，看到这里的童鞋还在用非常落后的技术（方型轮子）支持业务，童鞋们很忙很累，加班超严重，但是效率和产出很低，你忍不住搬出在大公司已经司空见惯的高端技术（圆形轮子，如云计算、容器、微服务和DevOps等一堆天花乱坠的新技术和理念），结果得到的反馈却是：“对不起，我们赶业务太忙没时间升级”，然后你就只能无语了！

图2：方形轮子困局2

第二个图是另一个版本的方轮子困局，在大部分企业里头也是非常常见的。一方面，受到市场竞争的压力，企业中拉车一方（业务方和管理层）和推车的一方（员工），都迫于赶业务而无法停下来做系统改进提升，尽管提升的技术手段存在企业内部（车里的圆形轮子）。第二种可能的情况是，企业一线的推车员工可能是意识到企业面临的效率问题的，但是企业的拉车方由于长期脱离生产一线，看不清业务支撑系统的效率问题，无法从上到下推进系统提升改进。

图3 谷仓困局

第三个图称为谷仓（Silo）困局，反映企业内部各自为政，缺乏领导力、信任和合作所造成的困局。

上图反映一个典型的场景：

• 业务方领导层：我们的增长太慢了，为啥我们不能比竞争对手更快推出产品？
• 产品管理层：我们现在不招新人了，技术团队不给力，一大堆项目堆着无法推进，研发团队是不是出了问题？
• 产品研发团队：没有按时交付项目不能怪我们，我们要求的机器运维一直拖着没有到位，我们的运维太挫，要换个头了。
• 运维团队：客户都气疯了，我们大部分时间在救火保证系统稳定性，不要再丢东西给我们了，我的团队天天熬夜都嚷嚷要离职…

谷仓困局还有一个典型的问题是，企业团队倾向自立门户，重复造轮子（基础设施）、造成大量重复劳动，企业效率低下，成本骤增和浪费严重。

对谷仓困局描述最生动的要数小说《凤凰项目：一个IT运维的传奇故事》，推荐有兴趣的童鞋进一步阅读（参考附录1）。

二、根因分析和破局思路

针对这些困局，背后的深刻原因是什么？我们该如何破局？下面是我近期的三点学习和思考。

1. 要事第一和压强原则

Stephen R.Covey博士的《高效能人士的七个习惯》（附录2）中的第一个习惯称为要事第一，Covey还为我们提供了一个时间管理的重要工具~四象限工作法则，把事情按照重要性和紧迫性分在四个象限里头，我们的注意力应该主要放在和重要性相关的两个象限里头。

A. 重要但不紧迫：通常是一些基础性长期重要的事情，比如抢占市场的新产品规划，人才引进和培养，基础设施建设，系统提升型项目等。

B. 既重要又紧迫：通常是一些火烧眉毛的事情，比如系统故障救火，网站紧急bug修复等。

这两个象限的时间分配是门平衡的艺术，理想70%的时间应该放在A象限，即未雨绸缪象限，20%的时间放在B象限，用于应急。A象限做好了，B象限事件的概率会变小。如果一个公司大部分时间在B象限救火，通常说明是A和B两个象限的时间分配失衡或者倒挂了，需要关注投资那些长期重要但不紧迫的事情。

图4：四象限工作法

实力上处于劣势的企业如何与优势企业竞争？华为公司的实践表明，要实行“压强原则”，也就是将有限的资源集中于一点，在配置强度上大大超过竞争对手，以求重点突破，然后迅速扩大战果，最终达到系统领先。华为公司总裁任正非先生曾用坦克和钉子的比喻说明“压强原则”。坦克重达几十吨，却可以在沙漠中行驶，原因是宽阔的履带分散了加在单位面积上的重量；钉子质量虽小，却可以穿透硬物，是因为它将冲击力集中在小小的尖上，二者的差别就在于后者的压强更大。

同样的道理应用到企业战略上，就有了“压强原则”。华为公司靠“压强原则”突破了万门数字程控交换机，突破了GSM全套移动通信设备，突破了光网络设备……几乎所有的重大产品，最初都是这么突破的。公司规模小时如此，如今公司规模大了，每年的研发费用超过了100亿元，但在项目资源配置上，还要继续贯彻“压强原则”。

在《华为基本法》中是这么描述的：“在成功关键因素和选定的战略生长点上，以超过主要竞争对手的强度配置资源，要么不做，要做，就极大地集中人力、物力和财力，实现重点突破”。

抓不住重点，克制不住做新产品的冲动、妄图全面开花，常常是制造方轮子和谷仓困局的一个主要诱因。 初创或成长型公司，本身资源匮乏，研发能力相对较弱，更需贯彻“压强原则”，应抓住重点，集中资源各个击破。

2. 系统思考、反馈环和试错文化

我们大部分人都有在高速或高架上堵车的经历，因为两辆车的事故，常常造成整个高速的流量急速下降（用我老婆的话说是龟速）甚至瘫痪。

图5：瓶颈理论

上面这个图很形象的展示了企业管理中知名的瓶颈理论（也称约束理论），整个系统的吞吐是由系统的瓶颈决定的，例如上图，瓶颈处的容量是4，那么整个系统的吞吐量是4。在瓶颈上游的优化，上图中上游的容量是6，只会造成上游的进一步拥堵和积压，而在瓶颈下游的优化，上图中下游的容量是6，则对整个系统的吞吐没有任何帮助，反而造成资源的闲置和浪费。

IT运维管理畅销书《凤凰项目》（附录1）的作者Gene Kim在调研了众多高性能IT组织后总结了支持DevOps运作的三个原理(The Three Ways: The Principles Underpinning DevOps)（附录3），可以认为是系统改进提升的一般性原理，见下图：

图6：支持DevOps运作的三个原理

原理一：系统思考(Systems Thinking)，开发驱动的组织，其能力不是制作软件，而是持续的交付客户价值。价值从业务需求开始，经过研发测试，到部署运维，依次流动，并最终以服务形式交付到客户手中。整个价值流速并不依赖单个部门（团队或个人）的杰出工作，而是受整个价值链最薄弱环节（瓶颈）的限制，所以局部优化通常是无效的，反而常常导致全局受损。

Gene Kim特别指出，在瓶颈之外的任何优化提升都只是幻象。Any improvements made anywhere besides the bottleneck are an illusion. — Gene Kim

在研发型组织中，常见的系统瓶颈如运维机器资源提供（Provisioning）缓慢，发布流程繁琐容易出错，遗留系统耦合历史负担重，研发基础平台和框架薄弱等等。这些瓶颈点是研发型组织特别需要关注和优化的。

原理二：强化反馈环(Amplify Feedback Loops)，过程改进常常通过缩短和加强反馈环来达成，原理二强调强化企业和客户之间，企业组织团队间，流程上和系统内的反馈环（如图7）。没有测量就没有提升（图8），反馈要以测量和数据作为基础，通过反馈数据来优化和改进系统。强化反馈环在技术上的一些主要手段包括大数据分析和监控告警等。

图7：强化反馈环

图8：没有测量就没有提升

原理三：持续试验和学习的文化(Culture of Continual Experimentation And Learning)，在企业管理文化层面强调勇于试错和持续试验的文化，真正的试错文化包括：

• 管理层要承认企业内部50%的创新或流程提升项目是可能失败的，即使失败，员工不会受到责罚，鼓励持续的实验和从中学习。
• 管理层要有技术偿债意识，勿追求100%的员工利用率，要留至少20%~30%的时间给员工做创新和系统改进提升项目。

技术研发型组织，尤其是领导层，视野不足仅仅关注自己的一亩三分地（局部优化），缺乏全局系统思考和合作意识薄弱，常常是造成组织各自为政的谷仓困局的另一个主要诱因。而企业和客户之间，企业组织团队间，流程上和系统内的反馈环不闭合，则会让谷仓和方轮子困局进一步恶化。

企业追求追责文化，则会造成员工束手不敢试错，出了问题则相互推诿和扯皮。企业追求100%的员工利用率，过分“压榨”员工，没有技术债偿还意识，不懂得留至少20%~30%的系统提升改进时间，光顾要母鸡生蛋但对母鸡本身照顾不到位，必然导致方轮子困局。

3. 提升人才密度

我个人认为，造成方轮子和谷仓困局的根本性问题还是企业的人才密度不够，无法支撑起日益复杂的业务和系统。不管是领导力、信任和协作、规划和抓工作重点能力，还是系统思考、闭环反馈和试错文化、都离不开人才密度这个根基的支撑。

初创型公司，一开始的目标是找准市场和谋活，一般花不起钱和很难找到好的开发人员，当然一开始的业务不复杂，一般的开发人员可以应付。随着业务复杂度的增加，一般开发人员难免堆砌业务代码和欠下大量的技术债务（坑），当企业的业务和系统复杂度到一个点，方形轮子和谷仓困局就出现了（如图9）。

图9：人才密度和业务复杂度的关系

互联网研发是一个智力密集型行业，一个好的研发人员和一个一般的研发人员到低有多少差异？我看到过至少三个版本：

第一个版本是Steve McConnell在《代码大全》（附录4）一书中提到的：“A good programmer can be as 10x times more productive than a mediocre one”，优秀程序员生产力可以是一般程序员生产力的10倍。

第二版本来自被誉为硅谷最重要的文档《Netflix企业文化》PPT（附录5）：对于程序性工作，顶级员工的输出量是一般员工的2倍，对于创新和创意型的工作，顶级员工的输出是一般员工的10倍。

第三个版本是乔布斯讲的：在软件行业里，最好的人才与一般的人才的差距是50倍，甚至是100倍！

不管这些数字是否准确，足以说明说明业界大牛和伟大公司对人才密度的重视。随着业务和系统复杂度的增加，如果企业人才密度跟不上，必然造成方型轮子和谷仓困局。所以应对上述企业困局的根本性方法，还是要想办法提升人才密度，说白了就是要换血，用海尔张瑞敏的话说就是要引入“负熵”。创业或成长型公司到一定阶段如果有钱了，老板千万记得花钱提升人才密度，特别要舍得花钱引进行业大牛。

另外还要注意那些表面看起来常常身处救火一线，常常加班熬夜的所谓“猛将明星”型员工，他们有可能恰恰是埋了很多坑的问题制造者，因为在软件行业，真正好的研发人员其实是非常“懒惰”的，他们大部分时间在思考和设计（好像不在做事），换句话说他们大部分时间花在未雨绸缪的A象限，做事的时候也常常尽可能采用自动化的手段，对于技术方案，他们会权衡长期的可维护性和可规模化，知道有些技术方案虽然可行，但是长期不可维护和规模化，所以不能这样干，找到这样的员工是企业之福。

三、总结

下面总结突破方轮子和谷仓困局的五点思路：

• 不惜代价引进优秀人才，特别是行业大牛，提升企业人才密度，人才密度要领先于业务复杂度。
• 要事优先，总结并抓住系统改进提升的重点环节并立项，贯彻“压强原则”，确保重点系统改进型项目的长期坚持推进和落地。
• 培养企业员工特别是领导层的流式(flow)思维、系统性思维和加强合作意识，协同找出系统瓶颈，针对瓶颈立项，集中投入资源做改进和提升。
• 培养企业员工的闭环反馈意识，建立和强化业务、团队沟通、流程和系统各个层次的反馈环。建设监控和数据分析基础设施，基于数据和可视化反馈改进和完善系统。
• 鼓励试错和免责文化，支持业务的同时留20%~30%时间给员工做系统提升和改进。

上面分析了方轮子和谷仓困局背后的深层次原因和一般性的解决思路，那么我们该如何落地提升呢？如下图，对一个处在方轮子困局阶段的企业，如何达到BAT水平呢？一蹴而就直线到达显然是不现实的。

图10：直线式转型

图11：曲线式转型的阶段

图11反映企业改进转型的现实情况，员工一般会经历从害怕，到恐慌，到放弃，到逐步接受并到达终点，中间还会经历反复，可能还会退回到老习惯做事的方法，但只要坚持推进，最终会达到终点。

图12：持续提升

一蹴而就(Big Bang)式的提升转型非常困难，一方面员工通常反弹会很大，另一方面太过折腾甚至可能影响到企业业务的健康发展。所以一般提升需要分解为各个阶段，每个阶段制定重点转型提升任务目标，借助如PDSA（Plan-Do-Study-Act）等闭环式管理工具，稳步长期锲而不舍推进，直至达成目标。

附录：

1. 凤凰项目：一个IT运维的传奇故事https://book.douban.com/subject/26644070/
2. 高效能人士的七个习惯https://book.douban.com/subject/1048007/
3. 支持DevOps运作的三个原理http://itrevolution.com/the-three-ways-principles-underpinning-devops/
4. 代码大全第2版https://book.douban.com/subject/1477390/
5. Netflix企业文化ppthttp://wenku.baidu.com/view/ef9319b4ad51f01dc381f166.html