从研发执行“做不完”中跳出来

在互联网的研发工作中，总有这样一类人：要支撑的需求太多，白天会议连轴转，消息软件里未读几百条，需求池里的工作只增不减。一天忙下来好像什么都做了，又好像什么都没做成。心里其实有几件早就知道值得做的长期高价值工作，如价值分析、技术攻关、系统重构，但偏偏一直没时间启动和推进。

这种情况，如果只是持续一周，那还可以看作一时忙碌。如果连着几个月都这样，就需要跳出来换个方式解决问题了。

为什么？

互联网行业节奏太快，所以事情做不完不会单独一周的问题：组织在不断调整和发现新的增长点，试错和调整节奏快，业务结构和依赖复杂。因此，需求产生的速度天然高于个人消化的速度，越追只会越慢。最终陷在事务中，无法发掘新的价值和增量。

既然做不完，关键就不是怎么做完，而是判断做哪些、不做哪些，让自己能抽身去并行考虑长期高价值工作。

那么具体怎么跳出？我的建议，是围绕一份工作准则文档解决问题。下面讲的，就是这篇文档应该写什么、为什么写、以及怎么用。

怎么做？

要写的文档并不复杂，可以叫做《工作准则》，或者柔和一些的《XXX使用手册》。链接可以放在团队Wiki里，也可以放在聊天软件签名中，让需求方人人能看到。

第一节：定义职责范围。讲清自己负责什么、不负责什么。确保需求方能快速判断，是否找到了正确的人。

第二节：顺序排列短期需求。这是需求方最关心的一部分。

首先要根据自己的情况，按类型说明优先级原则，比如，线上故障 > 已承诺的业务交付 > 阻塞他人的协作项 > 新业务需求 > 内部优化和探索性工作。这样就做好了总排序。

然后是同类需求内，按价值和紧急程度排序，并放入下表之中：

注意以下四点：

1. 排序的最关键因素是“价值估计”一列。如果一件事没有价值，光是紧急，并没有解决的意义；
2. 排序承诺的是交付顺序，也就是承诺前面的事情一定会在后面事情前完成，但并不是说所有事情最终都能做完；
3. 预期交付时间一定要有一个估计，要留有一点余地，原因是你可能还会临时接到更高优先级的需求；
4. 当新需求进来时，按原则重新调整顺序和交付时间，并通知被影响的人。

第三节：留出高价值工作专有时间。短期需求自带紧迫感，一旦做不完短期需求，就永远没有时间做长期高价值工作。因此文档里要明确写出长期事在什么时间做。常见有两种方法：

1. 每天留出固定两小时；
2. 每周留出固定一两天。

一定要按比例守住高价值工作的投入时间下限。如果高价值工作投入不够，在下一天/下一周开始时，必须优先补上。

第四节：顺手做超短期事。对于十分钟内能解决、不需要切换上下文的事，可以当场做掉。这个十分钟是参考值，可以按自己的情况调整，但必须有一个明确数字，否则所有事都会被归入顺手。对于必须当天处理的顺手事，可以承诺集中在下班前一个固定时段开始处理。

写完以上四节，工作准则文档就完成了。

公开

原则如果无法取得共识，矛盾则会继续。但原则公开之后，局面就反过来。只要原则有合理性，提需求的人会先看第一节，做一轮自我筛选，再结合第二节理解你给出排期原因和预期交付时间。

对方如果坚持自己的需求更重要，就需要解释为什么应该插队，这就必须和排在前面的所有需求逐一PK，而不再由你解释为什么交付慢。让论证的责任倒置。这种做法，还能更有理有据地避免老板给你临时加上不重要的事。

应用

陷在执行里的人常有一个共同的毛病：来事就接，不分轻重。碰到事的第一反应永远是"这件事是怎么回事，我应该怎么解决"；却回避了思考”这件事该不该做，有多重要，什么时候做“。

所以凡遇事要做到：

1. 花精力彻底弄清，这件事在文档里属于哪一节和哪一类，应该如何确定顺序。这需要围绕文档确立的原则，进行沟通、深入了解事情、并对需求方做必要的解释；
2. 分析文档中，不够适合现状的地方，持续优化文档和原则，逐步把例外变成常例，让常例更有效。

衡量

还需要一组指标来检查它是否真在生效。我建议分三层看，从低到高：

三层是递进的。但真正要看的是价值层，上面两层是出问题时用来定位是哪一环失效的：只看执行层会误判，因为高吞吐可能只是在快速处理低价值需求；只看结构层也不够，长期事的时间花到了，不等于做出了新东西。

结尾

写这页文档之前，你和需求方之间没有共同的依据，每次新需求来都要从头谈一次优先级。文档挂出去之后，争议有了可以对照的规则，沟通从一对一的反复解释变成了围绕同一份原则的取舍。事情依然做不完，但被推着跑的状态会停下来，人能跳出来看价值。