一、過去：我是怎么做的
過去接收需求時，我大多以被動傾聽為主，很少主動發起確認動作。通常是在會議或一對一溝通中聽完需求描述，覺得自己大概理解了核心意圖，就隨手記錄下來開始推進，既不會要求需求方或執行方復述關鍵信息，也不會在執行前找相關人員核對細節。很多時候，我會默認自己的理解就是需求的真實意圖，甚至在需求涉及多角色協作時，也只和中間對接人溝通，忽略了與最終負責模塊的執行人確認，直到交付階段才發現雙方對需求的理解存在偏差，導致返工。
二、書中做法：讓責任人復述需求的好處
書中提出 “讓負責模塊的人復述需求”，能從源頭規避很多問題。最直接的好處是可以立刻暴露理解偏差，就像文中 “18 英尺巨石拱門變成 18 英寸石樁子” 的例子，通過復述能快速發現雙方對關鍵數據、功能目標的認知差異，避免后期浪費大量時間和人力返工。同時，復述的過程也是責任人梳理自身理解的過程，能讓他更清晰地明確執行標準和核心目標，強化責任共識，減少后續因 “理解模糊” 導致的推諉。此外，當需求需要多輪傳遞時，讓最終執行人復述還能降低信息傳遞中的損耗，確保一線執行者的認知與原始需求完全對齊。
三、未來：我要怎么改
未來面對需求對接，我會把 “復述確認” 變成固定動作。每次接收或傳遞需求后，不再僅憑自己的理解推進，而是明確要求對方用自己的話復述需求的核心目標、關鍵細節和交付標準，確認雙方認知一致后再進入執行環節。同時，我會主動找到需求的直接責任人，比如具體的開發、設計人員，而不是只和中間對接人溝通，確保一線執行者對需求的理解沒有偏差。另外，對于重要需求，我還會在復述確認的基礎上補充書面記錄，簡要寫下雙方確認的核心信息，比如 “已確認 XX 理解交付時間為 X 月 X 日，需包含 XX 功能”，用 “口頭復述 + 書面記錄” 的雙重方式保障需求準確傳遞。