记一笔流水账
今天我打算记一笔流水账,主要记录我的一天中干的事情,并思考效率低下的原因,同时分析一些可用的解决方案。
清早·开始做计划
早上六点四十,被梦想唤醒,然后看一会书,吃早餐,送娃上学。

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

* (讲道理应该有每日站会,事实上我是xx项目的负责人,但是。。我把站会给省了,把站会取消对项目的危害非常大。后期再讨论)
* 对xx项目的周计划进行跟进和修订。
* 检查昨天完成的功能,并记录和指派bug。
* 整理文档,对昨天完成新功能的特性进行说明。
* 解决属于自己名下的bug。
* 开始两个下一阶段需要交付的新功能,比较简单的业务接口,代码行预计不超过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个小时,与体力劳动者本身没有太大区别。也许大家都差不多、总是像机器一样活着,思考都成为一种负担。总以为靠蛮力可以解决,实际上输出的或许是一种无用的解决方案。这样的付出,大概会觉得毫无价值。

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

牢记准则:“做正确的事,正确的做事”。