工程师、开发团队日报的写法：不止于作业记录，把预估的偏差和卡点连接到下一步

工程师和开发团队的日报，往往只是把当天碰过的作业名称排列出来，比如“实现了搜索功能”“处理评审意见”“开会”。

作业的记录很重要，但仅靠这些，留不下“为什么比预估花了更多时间”“在哪里卡住了、下次怎样避免”。

而且，在开发现场，任务在工单管理系统里，代码的变更在版本管理的历史里，日常的沟通在聊天工具里，记录的地方本来就很多，日报很容易显得是把同样的内容再抄一遍的工作。

如果是在专注工作之后、快下班时匆忙写，读的人也不回复，写的人就会逐渐只写一句“有进展”了事。

用PDCA来说，就是停在执行（D）的记录上，评价（C）和改善（A）都脱落了的状态。

本文探讨如何把日报从“作业记录的抄写”重新定位为“回顾当天预估的偏差和卡点，连接到下一步和团队学习的工具”。请把它当作关于机制的话题来读，而不是在责怪谁。

工程师的日报，把项目精简到下面这些，就比较容易坚持。①今天的目标（哪个任务推进到什么程度）。

②预估与实际时间的偏差（与其写偏差的大小，不如用一句话写出原因，比如等待确认需求、意料之外的既有代码、环境不稳定等）。③卡住的地方，以及想向谁请教什么。

④尝试后弄清楚的事、学到的事。⑤评审或会议上决定的事情中，与自己工作有关的部分。⑥明天的第一步。

要点是，不在日报里重复工单和代码变更历史中已有的“做了什么”，而是聚焦于偏差和原因、卡点、学到的东西。

反过来，“没有确认设计的前提就开始写，中途出现了返工”“向前辈请教了日志的看法，10分钟就解决了错误”这样的发现，既不会留在工单里，也不会留在变更历史里。

这些发现只有日报才能捕捉到。栏目加得太多，写的时间会变长，空栏反而增加。先从5个左右开始，一边听取团队的意见一边增减。

日报PDCA的格式由五部分组成：P（今天的目标）、D（实际做了什么）、C（发现）、A（下一步怎么做），以及第二天的P。

下面以负责功能开发的工程师为例（内容是为说明而虚构的例子）。P写“把搜索页面的筛选功能推进到可以提交评审的程度”。

D写“实现完成了，但与既有列表显示的排序规格不一致，确认和修改比计划多花了2个小时，没能提交评审”。

C写“开始写之前没有确认排序的规格，只凭工单的说明就往前推进，是原因所在”。A写“涉及页面的工作，在开始前写出3个可能会犹豫的点，先向负责人确认”。

第二天的P写“上午提交评审。下一个任务先写出要确认的点再开始”。连接到第二天P的诀窍，是把A写成“下一步要做的具体的一件事”。

不写“彻底做好确认”，而写“开始前写出3个可能会犹豫的点”，第二天的日报就能确认是否做到了。每栏写1到3行就足够了。

刚入职的工程师或经验尚浅的成员的日报，也可以成为不独自抱着卡点、尽早说出来的地方（这是为说明而虚构的例子）。P写“找出在测试环境中能复现的缺陷的原因”。

D写“整个上午都在找原因却没能确定，下午找负责人商量后，才知道是配置的读取顺序不对”。

C写“没有给自己一个人调查的时间设限。明知道问一下会更快，却总觉得马上就能弄明白，错过了开口的时机”。

A写“开始调查1个小时后如果还没有头绪，就写下试过什么，然后去商量”。写下卡点，不是为了报告自己做不到，而是为了让团队能尽早伸出援手。

阅读的负责人或前辈，先用一句话接住对方来商量这件事，再只回一个下次调查时的线索，成员就能安心地写下卡点。要避免因为写了自己卡住的地方而受到责备的回复方式。

开发现场已经有既定的记录：管理任务进度的工单，代码的变更历史和评审记录，故障和缺陷的处理记录，以及考勤记录等。

这些都是按照公司的规则和既定的步骤，各自保存在相应的地方。日报不能代替它们。请理解为：即使在日报里写了故障的经过，也不能当作正式的处理记录来使用。

划线的基本做法是：每个任务或缺陷的事实，按规定的步骤记在工单等既定记录里；日报里写的是我们自己的行动、发现和下一步。

在日报里提到这些记录时，附上工单编号，或一句“已记入处理记录”就足够了。

一开始就划好这条线，就能减少重复书写的负担，让日报不成为“重复的进度报告”，而是作为“回顾的地方”保留下来。哪些记录保存在哪里，请遵循公司的规定和负责人的判断。

日报的C栏里，有时会出现“感觉正式环境的运行比平时慢”“发现配置文件里直接写着认证信息”这样的内容。

这些事不要写进日报就结束，而要连接到公司或团队规定的处理步骤。

注意到疑似故障或与安全有关的事情时，不要等到写日报，而要当场告诉负责人，并遵循公司的步骤和负责人的判断。同样重要的是，不要在日报里对原因或影响范围下定论。

另外，密码、密钥、访问用的信息，以及用户的个人信息、从合作方那里受托保管的数据，平时就不写进日报，会更安心。日报只是“注意到了”的入口，并不是处理本身。

在日报里写一句“已向负责人报告”，读的人就能确认它是否已连接到正式的处理。

团队负责人每天都要看成员的日报。

想把每份都仔细读完是坚持不下去的，所以先读A（下一步怎么做），再看C（发现）和卡点栏里有没有需要帮忙的事，或者今天之内必须决定的事。

回复的评论，以一句话接住事实、再加一个问题或下一步的形式，比较容易坚持。

比如：“开始前写出可能会犹豫的点，这个想法很好。请告诉我明天的任务里写出了几个。”在居家办公较多的团队里，不把日报用来监视工作时间，而是当作尽早发现卡点的工具，是大家愿意如实书写的前提。

每周一次，把一周的日报排在一起回顾。

用KPT（继续做的事、问题、要尝试的事）的形式，讨论同类的返工或预估偏差是否反复出现、尝试过的做法效果如何，一个人的发现就能连接到团队做法的改善。

使用日报PDCA的每周摘要，也可以一次性回看一周的发现。即使有没交日报的日子，也先不要责备，而是问问原因，并重新检查栏目和书写时间是否适合团队的开发方式。

在日报PDCA中，AI是帮助起草日报、提出促进回顾的问题、做每周摘要的辅助角色。在开发团队，这条线也不变。

AI可以整理成员的简短备忘、从一周的日报中挑出反复出现的卡点和返工，但如何调整任务的优先顺序、如何修正预估、把哪项工作交给谁等判断，由团队负责人或责任人来做。

密码、密钥、用户和合作方的信息等不能对外的信息，平时就不写进日报，会更安心。

日报PDCA的设计是把日报数据记录在使用本服务的企业（也就是读者您所在的公司）自己的Google云端硬盘（电子表格）中，采取不在本公司一侧积存信息的最小数据保留思路。

与既定的记录分清职责，用简短的格式，坚持写会得到回复的日报。我们相信，这样的积累正是把每天小小的卡点和学到的东西，变成下一步和团队开发方式改善的基础。