北京
如果你走进一支日本远程开发团队的冲刺复盘会，最先注意到的可能是那个"缺失"的东西：没有人指向任何人。
不是产品负责人，不是Scrum Master，也不是工程师。问题照样被提出来——而且是真问题——但矛头永远对准流程，从不指向具体的人。这不是哪条明文规定，只是这个房间默认的运转方式。
在这支小规模、全员远程的日本团队里，复盘会就是这么开的。作者在日本的开发团队待了大约二十年，对此早已习以为常。但他见过不少来自其他地方的工程师，在参加完第一次日本式复盘后，心里犯嘀咕：刚才到底有没有人说了真话？
答案是：说了。只是你得知道往哪儿看。
复盘会的固定流程：先开口，再动笔
他们的复盘会在共享白板上进行，顺序是固定的。
第一步，在任何人写任何东西之前，大家先轮流说几句话——只是对这次冲刺的大致印象。这是热身，也是在给整场会议的"温度"定调。
接着，每个人有十到十五分钟的安静时间，在白板上写卡片，分为两栏：Keep（保留）和Problem（问题）。先写、安静地写，这一步的重要性远超表面看起来的样子。它意味着性格内向的人贴出的卡片数量和爱说话的人一样多，而且没有任何人的观点会被"谁先开口谁带节奏"所锚定。
写完以后，大家一起过一遍，归类，然后投票。
Keep栏里全是感谢，这不是走过场
他们的Keep栏通常是最满的，而且很多卡片说白了就是感谢信。"感谢X帮我在部署上解决了卡住的问题。""感激有人在我请假期间接手了代码评审。"——白纸黑字，写给具体的队友。
你很容易把这当成走过场——一种用粉饰太平来回避硬问题的"复盘表演"。但作者不这么看。
在一支对"指名道姓批评"极为谨慎的团队里，Keep栏恰恰是唯一允许点名的地方，而且是被鼓励的，只要内容是正面的。它是一块配重。整个冲刺周期里，大家说话都绕着问题走；复盘会则提供了一个名正言顺的场合，让你直接说出什么做得好、是谁让它做好的。这样一来，账本两头是平的。
Problem卡片上，名字被摘掉了
到了写Problem卡片的时候，名字统统拿掉。
产品负责人、Scrum Master、工程师，所有人在这里的写法都一样：描述问题，而不是描述罪人。所以卡片上不会写"产品负责人老是改主意"，而是更接近"冲刺中途需求变动了几次，导致范围很难稳住"。信息量完全一样，只是没有靶子。
这不是那种为了回避冲突而虚伪到不诚实的做法。问题是真的，也真的扎心。举几个例子，按它们通常被写出来的方式呈现：
- "验收标准在冲刺开始前没有完全对齐，导致后期返工。"
- "代码评审集中在冲刺末尾，造成发布前的时间压力。"
- "沟通渠道有点分散，有些信息没有及时同步到所有人。"
房间里的每个人通常都知道这些卡片真正指向的是哪些决策、哪些人。但因为卡片被表述成流程问题，对话就始终停留在流程层面——怎么收紧验收标准、怎么把评审分散到整个冲刺周期——而不是变成对某个人的辩护或攻击。
在日本团队里，正是这种表述方式，让那些棘手的问题有了被安全提出的空间。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
