一位996、CRUD开发者的一天

记一笔流水账

今天我打算记一笔流水账，主要记录我的一天中干的事情，并思考效率低下的原因，同时分析一些可用的解决方案。

清早·开始做计划

早上六点四十，被梦想唤醒，然后看一会书，吃早餐，送娃上学。

九点来到公司，开始一天的工作。在工作开始之前，我会花五分钟先做一个当天的计划，大概是这样的。

1. （讲道理应该有每日站会，事实上我是xx项目的负责人，但是。。我把站会给省了，把站会取消对项目的危害非常大。后期再讨论）
2. 对xx项目的周计划进行跟进和修订。
3. 检查昨天完成的功能，并记录和指派bug。
4. 整理文档，对昨天完成新功能的特性进行说明。
5. 解决属于自己名下的bug。
6. 开始两个下一阶段需要交付的新功能，比较简单的业务接口，代码行预计不超过80行。

这些任务中，除了第五项和第六项相对来说可能会耗时比较长外，其他每个单项任务基本上可以在25分钟内完成，而且也确实是按任务优先级和重要性顺序来安排的，看起来还挺合理的，总体上属于在8小时内可以完成的工作量，而且其实或许还略微有点不饱和。。。

执行任务（下面是流水账，可以略过）

于是我喝了一口水，开始完成第一项任务：对xxx项目的周计划进行跟进和修订。

（如果是周一，以前我还会根据上周完成情况对月计划和总体计划进行适度的总结，但是。。自从来到互联网公司后，我把这个好习惯也丢掉了，好吧，是因为假装要敏捷要拥抱变化，所以把总体计划和月计划省掉了）。

但是，当我开始处理这项事务时，计划外的第一件事情发生了。在测试环境下，客户端反映某接口出现了不该出现的问题，于是我被迫打断这项任务，花了一分钟时间，跟他对接口问题进行了检查，发现是对方参数传错了。

嗯。问题解决。继续开始刚刚的任务。

到哪里了？哦。。还在做计划，接着我迅速调整状态，花了几分钟就把任务完成了。

然后开始第二项任务。

这时，刚刚客户端又找我了，他说接口还是有问题。

我以为又只要花一分钟，事实上这次我花了30分钟，因为确实是原来的代码逻辑中存在缺陷，需要进行代码修改、然后发布、再测试代码。

确认这个问题已经得到解决后，还是处理之前搁置的任务。花了20分钟处理任务3。

开始处理任务4，这项任务也相对来说比较简单，所以不到五分钟解决了。

开始处理任务5。。。在我名下共有20个bug。。。以每个bug5分钟来衡量，我大概需要花100分钟才能解决。但是当我开始解决第一个bug时。

又有其他人开始找我了，运营开始找我，说xxx场景下似乎出现了xxx逻辑不对。

线上问题必须优先解决，赶紧的，仔细思考问题发生的条件、对链路服务进行跟踪和分析、查看半年前编写的代码逻辑，最终花了15分钟分析出问题，并花了10分钟将问题妥善解决。

继续开始修复bug。在bug修复的过程中，发现是产品逻辑存在缺陷，于是跟产品对任务进行进一步明确、梳理业务、设计更加具体细化的流程。花了1小时。

到中午12点，我上午共完成任务3项，修复了一个bug。

下午不属于问题的高峰期，但是又发现了产品逻辑之外的一些其他问题，最终解决了15个bug。

积压了5个bug，留到晚上来解决吧。

当夜幕降临，我需要花2个小时来解决我剩余的bug和2个未完成的新功能开发任务。

事实上等到晚上八点半时，我完成了剩余bug，新功能完成了一个，但此时效率已经差的不行了，没办法，硬着头皮也得完成今天的任务。

（会不会欠下新债，显然毋庸置疑）

晚上9点，所有任务已基本上圆满完成。

总结完成情况

总结今天完成的任务，共完成任务五项，其中修复bug20个，写了60行新代码，共耗时10小时。

显然我的工作效率是很差的，尤其是晚上效率更差，我最佩服那些自称晚上效率很高的人，尤其还有一些人特别喜欢深夜撸码，倒上一杯小酒，借着凌晨的寂静，写着爱写的代码，他们很厉害，因为他们很会自欺欺人。

来统计当天完成工作的工时占比：

工作内容	时间（分钟）
梳理日计划	5
修订周计划	10
接口联调	31
运营对接	25
修复20个bug	250
编写新功能	120
日常项目沟通	120
其他	40
总计	601

问题分析

以上流水账实际上是我们这样一家普通互联网公司的日常，当然，对我个人而言，实际上投入到运营对接中的时间相对来说是不算多的，我了解我们公司有的开发者每天需要花至少3小时与运营人员进行问题的对接，这显然会直接影响了开发者的工作效率。

（我相信一流互联网公司一定不是这样的）

从上图可以看出我们的日常工作安排存在以下问题：

• 修复bug这种还技术债的任务，耗时接近47%，占了将近一半的时间。嗯，能力确实不行，能不能采取措施让债不欠这么多，这是人才三角（专业技能、行业知识、软实力）需要达到的目标。我曾经打算在功能开发中引入TDD来减少返工率，但是最终决定还是先搁置这个想法。
• 我司项目管理的形式是虚拟团队，产品经理和测试工程师主要在深圳，而研发团队在长沙，因此，每天投入到团队沟通中的时间占比达到20%。事实上虚拟团队这种开发模式，作为目前比较新兴的项目沟通形式，已经被互联网公司广泛采用。但是虚拟团队成员间分处异地、无法面对面沟通，由于文化、工作节奏、技术等原因，容易造成比较大的沟通成本。可以采取以下措施进行优化：
• 1、打造高保真原型图，进一步拆解任务目标，让任务目标细分。
• 2、需求讨论时间前置，需求的特点是渐进明细的，应尽量将对需求的沟通在研发阶段开始前进行落实，减少对于研发阶段过程中的额外时间浪费。
• 3、快速冲刺阶段尽可能面对面沟通。
• 4、功能交付缺乏Desktop Check，意味着产品经理和测试工程师无法及时了解功能的实际开发情况，也意味着团队间对于成果的交付进度、实现方式，本身是存在疑问的，这将提高沟通成本。
• 如果按每天工作十小时，为3小时为与运营沟通问题的解决来算，占比达30%。说明对于项目成果的交付上，依然存在不少可以优化和提升的空间。或许可以采取以下措施。
• FAQ文档的进一步细化。
• 知识共享。
• 项目成果移交本身需要有更加规范化的管理措施。

 

结论

以上是一位CRUD互联网996开发者的一天，看起来似乎过得很充实， 却依然需要通过加班来完成当天的任务，而且甚至长期工作时间大于10个小时，与体力劳动者本身没有太大区别。也许大家都差不多、总是像机器一样活着，思考都成为一种负担。总以为靠蛮力可以解决，实际上输出的或许是一种无用的解决方案。这样的付出，大概会觉得毫无价值。

然而我们必须停驻脚步，认真思考当下的价值，思考效率和意义的平衡，让我们的生活更加有意义。

牢记准则：“做正确的事，正确的做事”。