记一笔流水账
今天我打算记一笔流水账, 主要记录我的一天中干的事情, 并思考效率低下的原因, 同时分析一些可用的解决方案.
清早. 开始做计划
早上六点四十, 被梦想唤醒, 然后看一会书, 吃早餐, 送娃上学.
九点来到公司, 开始一天的工作. 在工作开始之前, 我会花五分钟先做一个当天的计划, 大概是这样的.
(讲道理应该有每日站会, 事实上我是 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 个小时, 与体力劳动者本身没有太大区别. 也许大家都差不多, 总是像机器一样活着, 思考都成为一种负担. 总以为靠蛮力可以解决, 实际上输出的或许是一种无用的解决方案. 这样的付出, 大概会觉得毫无价值.
然而我们必须停驻脚步, 认真思考当下的价值, 思考效率和意义的平衡, 让我们的生活更加有意义.
牢记准则:"做正确的事, 正确的做事".
来源: https://www.cnblogs.com/xiyuanMore/p/11471296.html