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

刚过完年的时候,可能大家还沉浸在休假的状态中,工作并不忙。发现这段时间的自己有明显的变化。比如,虽然去年11月就准备写这篇博客,但大脑总是一片空白,不知道怎么写下去。现在却文思泉涌,各种想法都蹦出来了。又比如,讨论需求更加投入。以前忙的时候只会想着怎么才能快点结束讨论,技术上能否实现这个需求,甚至为了快点结束还会做一些妥协。现在则会思考对方的需求是否合理,坚决不妥协,而且还要说服对方接受我的方案。再比如,经常内省,这周的目标是什么,这半年的目标是什么,长期的目标又是什么。为了达成这些目标我需要做些什么,哪些地方做的还不够。这是一种非常理想的状态,因为自已一直在思考,而不是瞎忙。

但这种状态很难持续下去。一旦年过完了,工作回到正轨,自己就会变成“机器人”。机器人可能是这样度过一天的:早上到公司撸起袖子准备大干一番,打开了一段代码,刚开始思考这段逻辑应该怎么写,忽然来了电话咨询问题。解答完问题后准备回到代码上,企业微信群又反馈了一个紧急的线上bug。还没等处理完bug,一个会议马上要开始了。开完会回来刚把手放到键盘上准备开始写代码,又收到一封邮件。项目pm在邮件中写到,由于你的原因,项目整体进度延期了。这下好了,花大半天的时间跟各位老板解释,项目延期的原因是什么,为确保以后不延期我应该怎么怎么做。等复盘完这些,抬头一看天已经黑了。猛地发现代码居然一行都没动。下班路上回想这一天我都做了些什么,明明很忙很累但又好像什么目标都没达成。每天都是这样的状态,项目延期是必然的。

如同乞丐时刻担心下一顿饭怎么解决,我每时每刻都在担心怎样才能多抢一点时间。我就是时间上的乞丐,生存下去都成问题了,唯一的目标变成了抢时间,哪还有心思进行深入的思考。如何才能延续这种状态,避免变成机器人呢?

稀缺和带宽

几年前看过《稀缺》这本书,深入地研究了“穷人为什么永远缺钱,忙人为什么永远缺时间”这个问题,跟我所面临的困境非常契合。但当时看得走马观花,始终觉得作者说的都是废话,只讲稀缺是什么造成什么后果,但是不讲怎么解决。可能也是因为当时稀缺情况并没有太严重,所以没有深刻的共鸣。现在重温一遍,发现很多问题都能找到答案了。

一些核心的观点如下:

  • 稀缺是“拥有”少于“需要”的感觉,稀缺会俘获大脑,改变思维方式,强行侵入我们的思想之中,影响我们的决策。

  • 专注于某一事物就意味着我们会忽略其他事物。导致“管窥”。

  • 带宽就是心智的容量,稀缺会降低带宽的容量,让人缺乏洞察力和前瞻性,减弱执行控制力。

  • 解决组织中的时间稀缺,最重要的是,将有效的带宽最大化,而非将工作的小时数最大化。

  • 避免落入稀缺陷阱的唯一方法就是要拥有余闲。

带宽这个词用得非常精确,稀缺不会导致记忆容量(记忆对应的大概是硬盘这类存储)衰减,而是使并发处理的数量大幅下降。因为有很多事情或者难度很高的事情等着去做,所以没办法专注与当前在做的这件事。比如明明在开会,但思绪早就飘到十万八千里之外想着另外一个问题怎么解决。又比如在一个没人打扰环境中,虽然有一两个小时的空闲时间,但是一想到还有个很耗精力的事情,让我都没法专注于当下的事情。积压的事情越多,无法集中精力的情况就越严重。思绪不停的被其他事情拉扯走。

带宽的概念让我能从一个全新的角度审视“机器人状态”,其实就是稀缺陷阱。想让高效的状态持续下去,不能只关注时间,还要关注带宽占用情况,及时地作出调整。完成一项任务的成本,不仅仅只有耗时,消耗的带宽也是一个关键指标。比如设计算法和写代码这两项任务,所需要的时间可能差不多,但是前者所需要的带宽明显大于后者。在同样的稀缺状态下,有可能写完代码,但是算法无论如何都设计不出来。

除了工作本身需要的带宽,还要关注带宽余量。我发现带宽其实是周期性变化的,每个周期起始阶段,带宽最为紧张。比如每周的周一,每天早上和下午刚开始这段时间,所有人都比较焦虑,想到自己手上还有哪些事情没做。这时往往会有冲突,因为他人的目标很可能依赖自己(比如产品经理),所以这段时间被打断的概率非常非常高。如果在这个时间做类似算法设计这样的工作,基本是没法做下去的。

那应该怎么做?把带宽消耗大的任务放在带宽大的时间做就好了。比如上午11点半之后,下午5点之后,以及周五或者放假之前的某一天。这些时间段大家相对没那么焦虑,也就没人来打扰你了。

个人能做什么?

工作的分类

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

  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. 开发人员只做需求开发这一件事情,像机器一般每天只知道写代码,没有其他的事情做。

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

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

异步沟通

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

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

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

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

最后

解决带宽的稀缺问题,一是要靠主观,个人尽可能的提高自己的效率,明确自己的核心目标,优化掉隐形的工作。经常审视自己的带宽情况,是否因为带宽稀缺而忽略了长远的目标。二是要改善客观环境,团队内的每个人都应考虑他人的带宽情况。就像划龙舟一样,大家除了发力之外,还要协调节奏,这样才能划的更快更远。

comments powered by Disqus