三个版本连延，谁卡了流程？

4 阶段提问练习

1. O

   客观事实

   建立共识的事实基础。问「什么/谁/何时/具体」，不带评价

   学员（教练）此刻最想问对方一个关于客观事实的问题，紧扣三个版本的具体数字和时间节点

   • 9/10好选择

     「「王婷，按你邮件里的表，v6.2延期了5天，v6.3延期4天，v6.4延期3天，这三个版本分别是在哪个流程节点第一次确认延期风险的？」」

     具体、客观、聚焦节点，不评价，引导对方一起看日历和记录

   • 5/10可以更稳

     「「你邮件里说80%是技术评估不准，那另外20%你觉得是哪些环节？」」

     虽然开放，但隐含接受了归因比例，容易滑向责任分配而非事实共识

   • 1/10试试别的

     「「你凭什么说80%是我们的问题？测试排期和发布窗口你们自己没责任吗？」」

     直接反驳加反问，引发防御和争吵，脱离客观事实

   学员（教练）想了解版本延期过程中具体的需求变更点

   • 10/10好选择

     「「v6.2从需求冻结到发布，中间经历过几次需求变更？每次变更是谁发起的、在哪个阶段提出的？」」

     具体到版本和流程阶段，引导对方用文档说话，不评价

   • 5/10可以更稳

     「「你们那边有没有记录需求变更的清单？能给我看看吗？」」

     偏索取，而非共同回顾，可能让对方觉得被质问

   • 2/10试试别的

     「「需求变更这么多，测试排期怎么可能够？你们release管理应该提前预警啊。」」

     直接归因给发布管理，带有指责，偏离事实收集

   学员（教练）想用填空方式引导双方共同确认测试排期与发布窗口的衔接情况

   我注意到____，也想了解____。

   提示：我注意到v6.3的测试排期是从X月X日到X月X日，也想了解当时发布窗口是定在X月X日，这两个日期之间有没有重叠或空档？ · 我注意到你邮件里提到开发评估不准，也想了解在测试排期敲定的时候，测试团队有没有参与评审？ · 我注意到三个版本的发布窗口都是周五，也想了解如果发现风险，有没有设过中间checkpoint来调整窗口？

2. R

   感受反应

   释放情绪、识别共鸣。问「感觉/担心/印象/触动」，承接但不修复

   学员（教练）想引导对方表达收到邮件后的情绪反应

   • 9/10好选择

     「「你早上发那封邮件的时候，心里是什么感觉？是觉得终于把问题说清楚了，还是也有点担心我会怎么反应？」」

     开放、承接情绪，不评判，给空间表达真实感受

   • 4/10试试别的

     「「你发那封邮件前，有没有想过直接先跟我口头沟通一下？」」

     隐含指责为什么不提前沟通，容易让对方防御

   • 1/10试试别的

     「「你是不是觉得就是我们技术团队能力不行？」」

     直接贴标签，激化情绪，让对方更坚定自己的归因

   学员（教练）想了解对方对近期协作氛围的感受

   • 10/10好选择

     「「这三个版本连续延期，你作为release manager，每次出问题的时候，你心里最难受或最着急的是什么？」」

     共情但不评价，引导对方说出真实压力，建立连接

   • 4/10试试别的

     「「你觉得我们两个部门最近配合得怎么样？」」

     太宽泛，容易泛泛而谈或转向抱怨

   • 1/10试试别的

     「「你是不是觉得我故意拖着不配合？」」

     假设对方有恶意，直接激化矛盾

   学员（教练）想用填空方式引导对方描述直觉反应

   当____的时候，你的第一反应是____。

   提示：当你看到v6.2又延期的时候，你的第一反应是『又来了』还是『这次有原因』？ · 当你收到客户警告的时候，你的第一反应是『技术团队要背锅了』还是『流程哪里断了』？ · 当你写那封邮件把80%归给技术时，你的第一反应是『终于有人担责了』还是『希望引起重视』？

3. I

   诠释意义

   挖掘洞察与可选项。问「为什么/意味着/有哪些方案/选 A 还是 B」

   学员（教练）想引导对方诠释延期背后的结构性原因

   • 10/10好选择

     「「抛开个人态度，你觉得这三个版本延期背后，是流程上哪个环节最容易出现盲区？是需求变更管理、测试排期弹性、还是发布窗口的硬约束？」」

     具体、结构化、引导系统思考，而非人与人之间的归因

   • 4/10试试别的

     「「你觉得要怎么做才能避免下次延期？」」

     跳太快，还未充分理解根因，容易给出表面方案

   • 2/10试试别的

     「「你们release团队有没有考虑过提前介入开发评估？」」

     给出建议而非提问，容易让对方觉得被指导

   学员（教练）想挖掘对方对『评估不准』这一归因的深层理解

   • 9/10好选择

     「「你说开发周期评估不准，如果深入看，是需求复杂度评估不准、还是技术方案选型时没识别出风险点、还是外部依赖（比如第三方SDK）没有提前对齐？」」

     细分维度，引导对方从笼统归因走向具体环节

   • 3/10试试别的

     「「那你们觉得开发评估应该怎么做才准？」」

     把问题抛回给对方，易让对方觉得被质问

   • 1/10试试别的

     「「评估不准是因为你们技术团队能力不行还是态度问题？」」

     二元对立，引发强烈防御

   学员（教练）想引导双方共同诠释『责任』与『盲区』的区别

   如果我们暂时不讨论谁该负责，而是问『这个问题的根因最可能藏在哪个流程环节』，你会指向____。

   提示：指向需求变更流程——比如v6.3在开发中期新增了一个功能点，没有重新评估排期 · 指向测试排期——比如测试资源在三个版本期间被其他项目占用，没有动态调整 · 指向发布窗口——比如窗口固定在周五，一旦错过就要等下一周，缺少弹性机制

4. D

   行动决定

   落地承诺。问「做什么/谁负责/什么时候/怎么验收」

   学员（教练）想引导对方承诺一个具体的联合复盘会日程

   • 10/10好选择

     「「下周一上午10点，我们两个部门一起开个联合复盘会，你那边能定下来吗？需要我提前准备什么数据？」」

     具体时间、具体人、具体准备，可操作、可验证

   • 3/10试试别的

     「「我们找个时间再一起聊聊吧，你觉得什么时候方便？」」

     太模糊，缺乏约束，容易拖延

   • 1/10试试别的

     「「这件事不能就这么算了，下周一之前你必须给出一个整改方案。」」

     命令式，破坏协作信任，单方面要求

   学员（教练）想明确双方在复盘会前各自要准备的数据

   • 9/10好选择

     「「为了周一复盘更有效，我这边准备三个版本的需求变更记录和实际工时对比，你那边能准备测试排期表、发布窗口记录和每个节点的风险预警时间吗？」」

     具体、对等、合作导向，各准备自己的部分

   • 2/10试试别的

     「「你把所有数据整理一下发给我的团队，我们分析完再跟你沟通。」」

     单向要求，让对方觉得被甩活

   • 1/10试试别的

     「「你先把你的数据给我，我看完再说。」」

     命令式，不尊重对方时间

   学员（教练）想引导双方约定一个具体的检查点或后续机制

   在这次复盘之后，我们可以在____环节增加一个____，来避免类似盲区。

   提示：在需求变更环节，增加一个『变更影响评估会』，无论变更大小，先对齐对排期的影响再决定是否纳入 · 在测试排期环节，增加一个『资源冲突预警表』，每周更新一次，提前识别风险 · 在发布窗口环节，增加一个『弹性窗口机制』，比如如果周五赶不上，可以在周三增加一次补发窗口