《梦断代码》读书笔记03

一、过去：我是怎么做的
过去接收需求时，我大多以被动倾听为主，很少主动发起确认动作。通常是在会议或一对一沟通中听完需求描述，觉得自己大概理解了核心意图，就随手记录下来开始推进，既不会要求需求方或执行方复述关键信息，也不会在执行前找相关人员核对细节。很多时候，我会默认自己的理解就是需求的真实意图，甚至在需求涉及多角色协作时，也只和中间对接人沟通，忽略了与最终负责模块的执行人确认，直到交付阶段才发现双方对需求的理解存在偏差，导致返工。
二、书中做法：让责任人复述需求的好处
书中提出 “让负责模块的人复述需求”，能从源头规避很多问题。最直接的好处是可以立刻暴露理解偏差，就像文中 “18 英尺巨石拱门变成 18 英寸石桩子” 的例子，通过复述能快速发现双方对关键数据、功能目标的认知差异，避免后期浪费大量时间和人力返工。同时，复述的过程也是责任人梳理自身理解的过程，能让他更清晰地明确执行标准和核心目标，强化责任共识，减少后续因 “理解模糊” 导致的推诿。此外，当需求需要多轮传递时，让最终执行人复述还能降低信息传递中的损耗，确保一线执行者的认知与原始需求完全对齐。
三、未来：我要怎么改
未来面对需求对接，我会把 “复述确认” 变成固定动作。每次接收或传递需求后，不再仅凭自己的理解推进，而是明确要求对方用自己的话复述需求的核心目标、关键细节和交付标准，确认双方认知一致后再进入执行环节。同时，我会主动找到需求的直接责任人，比如具体的开发、设计人员，而不是只和中间对接人沟通，确保一线执行者对需求的理解没有偏差。另外，对于重要需求，我还会在复述确认的基础上补充书面记录，简要写下双方确认的核心信息，比如 “已确认 XX 理解交付时间为 X 月 X 日，需包含 XX 功能”，用 “口头复述 + 书面记录” 的双重方式保障需求准确传递。