时间块不是日历涂色:分块、被打断,以及怎么回来
我试过把日历涂满,结果只是把会议变多。后来我把一天切成三段 90 分钟的深度块,加上两段 30 分钟的缓冲区,并给每次打断留一条记录。这篇文章写清分块比例、缓冲区怎么留、被打断后回到状态的三步。
个人工作经验分享
我是罗文,在技术岗位上做了几年事。这里记录我关于工作方法、项目复盘、职场协作和行业变化的观察:先写具体怎么做,再谈为什么这么想。
按发布日期倒序排列,共 12 篇,分布在四个栏目里。
我试过把日历涂满,结果只是把会议变多。后来我把一天切成三段 90 分钟的深度块,加上两段 30 分钟的缓冲区,并给每次打断留一条记录。这篇文章写清分块比例、缓冲区怎么留、被打断后回到状态的三步。
一个内部审批系统,需求不多,却返工了三次。原因不是技术难,而是我们把「谁在什么情况下点通过」当成了细节。这篇复盘写需求确认阶段漏掉的四类问题、返工的实际代价,以及后来加进流程的一张状态表。
一对一最容易变成进度汇报。我改成提前准备五个问题:进展、卡点、判断、需要什么、下一步想试什么。文中给出每个问题的具体问法,以及会后十分钟内要做的记录。
拆得太粗估不准,拆得太细又变成写文档。我用的标准是:每一步都能在半天内给出可验证的产出。文中给出拆分的三层结构、估算偏差的记录方式,以及偏差超过多少就该回头改拆法。
每个栏目各有一条主线,文章之间尽量相互引用,而不是彼此孤立。
更新于 2026 年 11 月 · 每两三周写一篇
谁在写。罗文,技术岗位,做过需求评审、方案设计、开发上线,也做过事后复盘。不是管理者,也不是行业专家,只是习惯把过程记下来,隔几个月回头看哪些判断错了。
写什么。写具体动作:一个时间块怎么划、一次返工怎么避免、一句反馈怎么开口。每篇文章尽量留下步骤、清单或判断标准,让读过的人当天就能试一次。