前言
之前看过一篇关于研发效能的文章，其中提到了效率竖井，结合实际的工作情况，有一点体会与想法。
效率竖井的概念
效率竖井：由局部优化导致，表现为：各个环节和部门繁忙而“高效”，但总体的效率和响应速度却很低。
局部优化，指的是工作部门内部的工作提升，比如设定工作优先级，形成工作规范，旨在提升效率。但这有可能导致一些耗时较短的任务由于优先级低而排队等候，导致产品或服务交付受阻。
工作实践
最常见的便是“老板需求”，这种需求一般优先级最高，所以由产品-设计-开发-测试组成的开发工具都把这个需求当成第一要务。但此时又一些合理的需求，比如技术优化，或者是紧迫性更高的，比如某地区的活动需求，就都没法进行，除了“老板需求”的其他产品或服务无法及时得到交付。
另一种情况是我最近遇到的，同个部门内部也会产生效率竖井。平台组的技术输出，有一部分是为了支撑业务组更好的实现，所以这两者会有合作关系。而平台组自身也有一些技术需求需要实现，当遇到业务组需要平台组支援时，技术需求和业务支援会冲突，所以存在无法及时响应业务组的问题。平台组的策略是需求排队，提交需求形成表格，这里还没形成优先级。这么一来，业务组紧急的需求无法推动，要么等，要么向上反馈，时间白白耗费。
第三种解决方法
以上这两个问题，可能每家公司都会存在，形式不同而已。解决方式可能也是两种，等待or向上反馈。但是我不想满足这两种解决方式。我想自己解决出现的问题，比如当业务组的问题能自己解决时，可以直接要平台组的代码来改，然后提给平台组review，通过了才入库。比如“老板需求”的阻挡下，技术优化无法获得测试资源，那么可以自己测试，自己保证质量。
感悟
第三种解决方式，我想表达的其实是遇到问题，等待不是最好的方法，我们对待问题，最好的方法就是想尽各种办法去解决他，外部无法依靠的情况下，那只能发挥自己的主观能动性。有些人可能觉得要是遇到开发在等设计稿的情况，该怎么处理。其实这种情况我也建议开发或者产品进行设计稿的设计，国外的开发经常兼任UI设计，人家的产品也有过亿日活。新时代下，给自己设限不是一种明智的选择，不该总想守着自己的一亩三分地。
站在老板的角度，我认为这种解决办法也是会得到认可的。上班，说白了就是解决工作中出现的问题。问题的解决自然是越快越好，你等我我等你，猴年马月才能把问题解决呢？
所以效率竖井，靠制度无法保证的情况下，其实靠人的主观能动性，靠公司内人才的主人翁意识，我认为可以得到一定程度的解决，当然我保留一些特殊情况下存在只能部门合作才能解决的问题。