成长型公司大多存在方轮子和谷仓困局，这些制约公司发展、团队进步的经典困局，破局思路其实只有5点。但怎么落地实行，才是每个人应该去思考的。

　　编者按

这是作者的一篇2016年度架构思考总结，将其近期对技术型组织转型提升的一些思考心得总结出来分享给大家，既作为自己的总结沉淀，又输出给感兴趣的人学习，一举两得。

本文假设针对提供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：四象限工作法