程序员生存指南：时间与带宽

如何得到更多的带宽？首先你得知道带宽都耗在什么地方了。如果每天忙的很但是又不知道干了啥，我强烈建议把每一项工作都记录下来，进行分类。分类之后就会对为什么这么忙有直观的认识，然后才能做进一步的优化。比如我的工作大概分为以下几类：

1. 开发需求，也就是写代码，调试，测试等等。

2. 数据统计和分析。

3. 问题排查，线上有用户投诉，要解决问题，查查问题在哪里。

4. 解答问题。之前所负责的项目，并不是上线了就不管了。人员的流动决定了这种解答问题是不可避免的。即便同一个人，解答了问题下次可能还是会再问你。

5. 新需求的讨论。是不是合理，为什么要这么做。这个事情应该谁来做。方案的讨论，怎么做。

前面两项是自己的核心目标，跟OKR直接相关，也是大家所能看到的。剩下的都是隐形的工作，这些工作同事和领导看不到也不会关注。但是又属于自己职责范围内的，不能不做。为什么自己明明很忙，但好像又什么都没干呢？正是因为这些隐形的工作一直在挤占本就稀缺的带宽。

每次需要预估一项工作多久可以完成的时候，我都很痛苦。因为隐形的工作是不确定的，无法预测什么时候又会出现bug，也无法预测什么时候他人又有问题需要我解答。所以没法预估出准确的时间。假如把这些隐形工作考虑在内，留够充足的buffer，预估出的时间就比较长，产品经理就不能理解，这么小的一个需求为啥需要这么久？预估时间短了实际上又不能完成。

如果放任不管，隐形的工作慢慢地就会变成巨大的负担。在他人看来，这些工作一没有难度二没有成绩，等汇报的时候自己都会觉得好像没啥可讲的。可是时间都已经花了出去。随着工作时间的增长，负责的项目越来越多，隐形的工作也随之增加，而且会一直持续下去，除非你把项目交接给其他人。如果不加以控制，发展到最后，隐形的工作可能会比正常的开发工作大很多倍。到这个时候，就会陷入我那种机器人的状态了。

怎么解决呢？把这些隐形的工作优化掉，就可以挽回大把的时间。首先把日常所有工作全部记录下来，进行分类。每个人的情况不同，自己分好类，很容易就会看出来哪些是隐形的工作，哪些是核心目标。再来思考哪些隐形的工作是可以彻底优化掉的。经常被咨询的问题，整理文档记录下来，下次再有人咨询直接扔个文档是不是就解决了？经常出现的bug，有没有共性，是否逻辑不合理，优化和重构是不是可以解决？日常需要我手动处理的一些事项，是否可以封装成自动化工具，由需求方来自助操作？

仔细想想，这些隐形工作基本上都是有很大的优化空间的。等优化完这些隐形的工作就彻底不会再来打扰你了。当然，优化过程本身也会耗费不少时间，但是这些优化是一劳永逸的，节省出来的时间是一笔不小的财富，为这些投入精力是非常值得的。而且这些优化也很容易汇报，大家一听就能明白其中的意义。

大脑就像堆栈，新的任务入栈了，原来的任务自然就会排到底下。一次两次不会有什么影响，再多的话就很难再回到最开始的任务上了。以前的我总是本着负责任的态度，所有需要我帮忙的人都尽可能的满足。后来发现这是完全错误的，答应所有人的要求恰恰是懒惰的做法。如果时间全部用来满足其他人的需求，我自己的核心目标怎么办？如果你觉得满足所有人的需求之后自己还有不少的空闲，那只是因为你负责的东西还太少。时间和带宽是有限的，一定要懂得拒绝，放弃那些不重要的任务。

优先关注核心目标，想明白自己想做什么事情，哪些事情重要，哪些是我自己想做的，哪些是别人的目标需要我配合的。目标一定要写下来，放在一个醒目的位置，我这周的目标是什么，今天的目标是什么，哪些是我一定要做完的，时刻提醒自己。

核心目标难度更高，需要更多的带宽和时间，所以面临冲突的时候，往往倾向于先解决那些琐碎的杂事，因为看起来比较快。我把这些杂事解决了，再来专心做我的核心目标，不是挺好的吗？真实情况是杂事会源源不断的涌进来，可能还没解决完第一件，第二件杂事又摆到你面前了。应该怎么做？把这些杂七杂八的事情往后推，先解决自己的核心目标，剩下如果有时间再来处理杂事，没时间只能算了。

一件事情是不是重要和他人催你多少次是无关的，避免按“催”分配时间。A催的紧了，我就做做A的事情，B催的紧了就放下A的再做做B的。到头来两个人都不满意。而且现实世界里可不只有两个人，有可能是20个人。正确的做法是评估出到底哪个更重要，其他的事情是不是压根都不需要做？

忙起来之后往往只关注眼前的事，而忽略战略性思考。“稀缺会降低带宽的容量，让人缺乏洞察力和前瞻性”。所以要经常反省，我最近是否一直带宽严重稀缺，是否很久都没有灵光一现的时刻，是否每天都忙着在做具体的需求，却没有想过未来的规划了？带宽越是稀缺，就越会觉得眼前的事重要，虽然每天很努力，但是却感觉这些努力都意义不大。

如果确实处于这样的状态，那就要努力让自己从这个坑里跳出来。眼前的这些事其实没那么急迫，也并不都是重要的，把所有的事情都放下。再来思考，哪些事情是符合我的长远目标的，应该在哪个方向上努力。

在我的工作经历里，经历了无数次的需求排期会议，有团队每周一次，也有团队每月一次。但我始终非常抵触这种做法，一是浪费大量的时间，二是起不到任何的效果。需求是排上了，但照样延期。能按时完成的就没有几个。只能给产品经理一个心理安慰，嗯我的需求排上了。团队里的每个人都希望自己是有成绩的，不提需求怎么体现成绩？

需求排期往往会争得面红耳赤，明明已经有很多事情同时在做，还是硬要往里塞。双方僵持不下，再继续下去就变成了专场批斗会。“为什么你的需求老是做不完”？当然你可以把最近在忙什么列出来，但是大家只关心自己的需求，其他人的事情真的是听不懂，也不想听。

需求冲突了需要协调，把产品经理拉到一起，大家pk下需求，看看哪个优先级更高，优先级低的晚点再做。但大多数情况下协调都是无效的。协调完就会发现，一顿操作猛如虎，要做的事情一件都不会少。协调可能有以下几种结果：

1. 提高简单需求的优先级。 某个需求看起来特别简单，花不了多少时间，先把这个做了吧。如果只从时间上考虑，这确实是最优策略。其他大需求往后延迟半天一天影响也不大，小需求还解决的特别的快。如果从带宽的角度思考，这是完全错误的。大需求需要大量的带宽，即便把它放到后面，带宽也不会释放。插入新的任务后，带宽变得更加稀缺。本来2+1=3，1+2却大于3了，两个需求都做的更慢。另外，“一鼓作气，再而衰，三而竭”的道理大家也都懂，刚刚进入状态就被打断，后面再拾起来的时候可就不那么顺了。

2. 压缩buffer时间。 假如专心做一件事情一天就可以搞定，但是考虑到有各种各样的其他事项需要处理，一般要留一些buffer。相对合理的时间是两天。但是协调的时候就会说，这个需求明明一天就可以搞定，软硬兼施，你可能会答应一天搞定，把留的buffer扔掉。但实际肯定做不完的。真正延期的时候，将会面临这样的挑战，“明知道做不完，当时为什么答应？”

3. 把需求交给其他人来做。 如果亲自做，可能需要半天的时间。交给其他人做，沟通的时间至少都要一天。你是没办法做到撒手不管的。方案你来出，细节需要你来把握，出了问题责任还需要你来扛。

如果需求排期能够达到预期的效果，需要满足以下两个“理想”的条件：

1. 开发人力和需求处于供大于求的状态，也就是大家都比较闲。

2. 开发人员只做需求开发这一件事情，像机器一般每天只知道写代码，没有其他的事情做。

这两个条件在现实里当然是不可能达到的。所以问题的核心还是要管理好需求，哪些是真正值得做的、意义重大的需求，哪些是锦上添花的可做可不做的需求，哪些是为了体现自己的价值而输出的伪需求？我经历过很多次，提需求的时候十万火急，但是过了几天产品自己都忘了。这种需求除了降低团队的效率之外没有任何的意义。

作为开发人员，这些问题是很难给出答案的。在大量的工作任务中进行权衡，我到底应该做哪个，这本身就非常花时间。另外，我也很难评估这个需求是不是应该做的。毕竟个人的视野是局限的，不能像老板一样站在全局思考。如果我说这是个伪需求，但实际上是老板提出来的，那不就啪啪打脸了嘛。

同步的沟通方式会大量消耗带宽。不知大家有没有这样的体会，想专注做某件事却频繁被他人打断，自己就像一张脆弱的纸，被无数人撕来撕去。以至于最后什么都不想做，放弃挣扎。因此周末去公司加班，在没人打扰的情况下一天甚至可以做完平时一周才能做完的事。

比如，有的同事需要讨论问题，事先不做任何沟通，直接带一群人来到工位上，或者是拉电话会议，恨不能让你立刻马上给出个结论。但是我的脑子一片茫然，而且如果我正在忙别的，被你打断了很不爽，我极有可能会敷衍你了事。但是另一些同事做法就截然不同，事先拉个群，发一下问题的背景、上下文信息，然后再预约个时间当面讨论，这种做法的效果就好多了。一是我心理有准备，到预约的时间我就等着你，绝对不会敷衍了事。二是问题的背景我也大概了解，甚至在讨论之前就有一些简单的思考。这不是事半功倍么。

可能有人觉得，这么做才能体现我的执行力强啊，做事情要雷厉风行。我什么都要等，还执行个啥。这不叫执行力强，这是缺乏尊重。换个角度思考，如果你需要找老板决策，肯定也想马上得到结论。但是不管你多着急，肯定不会直接跑到办公室里讨论吧。用打断他人的方式来确保自己的进度，效果并不好，也快不了多少时间，而且团队整体的效率是下降的。也可能有人觉得，你一个普通屌丝员工还跟你约时间，也太装逼了。有这样的想法，说明你还比较闲，没有体会过真正意义上的忙。

不过在这个问题上，我们除了管好自己之外，其实做不了什么。我们无法左右他人的想法，总不能上班的时候躲到某个会议室工作吧。还是需要整个团队的努力，共同营造这样的文化。