有效溝通：需求說清楚，IT不跑偏（輕科技）

作爲甲方，我們經常遇到的一個問題是，如何把需求與乙方講清楚，那種“五彩斑斕的黑”式描述顯然不行，我們需要結構化的描述。什麼結構？作者給出了一個需求三棱鏡，問題層：你要解決的問題是什麼，結果層：成功是什麼樣子，驗收層：怎麼知道做到了。 整本書讀下來，我感覺這套工具絕不僅僅可以用在軟件系統開發，任何我們想與對方溝通需求的場合都可以套用，只不過有時候可以適當簡化，比如領導在佈置工作，要講清楚自己到底想要啥，怎麼才叫做好了，比如需要告訴朋友如何幫忙辦事。需求講的清楚，後面執行纔不會跑偏。馬斯克說過，根本沒有所謂的執行問題，只是需求沒有講精準。描述的顆粒度越細，執行效果越好。 具體來說，要先從問題描述出發，沒有痛點就沒有需求，這是明確我從哪裏出發，然後要想明白要做成的最終模樣是什麼，最好能夠場景化描述出來，也就是要有畫面感，這是明確要到哪裏去，最後要明確驗收標準，給出相應量化指標，以數據來判斷這個項目是成功還是失敗。 作者也給出了需求三棱鏡相應的工具。問題層，要講清楚三個問題：一是現狀是什麼，要具體詳細做事實描述，而不是一些類似“出餐慢、效率低”等主觀判斷，二是要明確問題的代價是什麼，代價決定項目的價值，三是要找到問題的根因。 結果層，要進行場景化的描述，格式是：早上/下午/項目結束後的某天，[這個人]做了[一件具體的事]，和之前不同的是[具體的區別]。” 比如： “早上10:00，店長老張打開手機，屏幕上顯示今天的午市預測：預計12:00-12:30會比平時多30%訂單，因爲附近有展會。系統給出了備菜建議。老張確認了建議，花了30秒。以前，他等到12:15發現訂單湧進來才知道今天忙，然後臨時加人，後廚還是堵了。” 驗收層，要明確出具體的驗收指標，可以從效率、成本、風險、機會四個維度給出指標，比如試運行3個月，真實離職案例中有60%以上在系統裏提前出現了預警。 作者最後還很貼心的給出了模版，可以直接複製使用： 《［項目名稱］》需求三棱鏡 填寫人：___________日期：___________ __________________________________________ 【問題層：我要解決什麼問題】 現象：_________________________________ （誰、在什麼時候、遇到了什麼問題，出現多少次） 影響：_________________________________ （這個問題讓誰付出了什麼代價） 根因（假設）：__________________________ （你認爲是什麼機制導致了這個問題） __________________________________________ 【結果層：成功是什麼樣的】 成功場景：_____________________________ （某個具體的人，在成功後的某一天，做了什麼） （不一樣的事，具體到時間、地點、動作） __________________________________________ 【驗收層：怎麼知道做到了】 驗收條件：_____________________________ （可量化的指標 + 時間範圍 + 判斷閾值） 價值估算（量級即可）：__________________ （現在的成本 vs 數字化後的改善量級） 不在本次範圍內的事：___________________ （明確邊界，防止範圍蔓延） __________________________________________ 總結來說，核心就是三句話：爲什麼要做這件事（問題入手，why，使命）？做成什麼樣子（目標，願景），不做什麼（確定做事邊界，聚焦資源）？如何判斷做的好壞（價值觀，量化指標）？至於誰來做（who），做什麼（what），怎麼做（how），在哪裏做（where），這是對方需要考慮的問題，甲方要不斷追問自己的問題，把別人的問題留給別人去思考。

數字化項目大多折戟，從來不是技術難題，而是需求溝通的錯位。本書用“需求三棱鏡”，把模糊想法拆解成可落地的精準表達，打通業務與IT協作壁壘，高效對齊共識、規避項目跑偏，職場協作必讀乾貨。

其實我也認爲，很多時候不是技術問題，是溝通問題。我們總是以爲我們瞭解了對方的需求，對方也總是認爲自己把他的需求講清楚了。其實兩者之間有一個天地之差，而作者用了需求三棱鏡的模型很好，我要解決什麼問題？成功了會怎麼樣？結，成功之後的結果又是怎麼樣的？怎麼驗收的？可量化。 這想法都很好，在IT行業特定的情景下也能做得更好。但是在不特定的情況下，我們如何利用需求三棱鏡把它做得更好呢？又是一個新的課題。

三棱鏡需求： 【問題層：我要解決什麼問題】 ①現象（需求）：：誰、在什麼時候、遇到了什麼問題，出現多少次 ②影響：這個問題讓誰付出了什麼代價） ③根因（假設）：你認爲是什麼機制導致了這個問題 完整的用用戶故事和場景描述法，描述整個事情的全貌（做出動作者和被影響者），並給出你的結論！ 【結果層：成功是什麼樣的】成功場景：某個具體的人，在成功後的某一天，做了什麼）（不一樣的事，具體到時間、地點、動作） 你期望的結果樣子（誰，地點，動作 【驗收層：怎麼知道做到了】 ①驗收條件：可量化的指標 + 時間範圍 + 判斷閾值） ②價值估算（量級即可）：現在的成本 vs 數字化後的改善量級 ③不在本次範圍內的事：明確邊界，防止範圍蔓延 具體可量化的條件，價值估計，說清楚範圍

好書好書，短小精悍！這本書不僅講透了如何提出/理解軟件需求，更可貴的是，它的思維框架完全可以遷移到各類任務場景中。 無論你是甲方提出需求，還是乙方承接需求，只需釐清三個核心問題： 1. 問題層：當前用戶的核心痛點是什麼？它帶來了怎樣的影響？背後的根本原因又是什麼？ 2. 結果層：軟件上線前後，某個具體角色的工作場景發生了怎樣的實質變化？ 3. 驗收層：有哪些可量化的指標來評判軟件是否成功？最好還能設定階段性節點，避免一路走到最後才驚覺方向錯了。 三問之下，需求自明。值得一讀！

AI時代，這個能力尤爲重要。 問題、結果、驗證，以終爲始！

數字化轉型中，各類技術僅爲落地工具，核心落腳點在於業務模式重構。本書從三大維度拆解數字化項目業務需求的梳理邏輯： 問題層：梳理現存業務痛點，明確痛點帶來的實際影響，並深挖問題根源； 結果層：描繪問題解決後的理想業務圖景，清晰界定各崗位、業務對象的工作變革； 驗收層：設定可落地、可量化的項目驗收指標，例：連續三個月業務預測準確率≥90%。

清晰的表達是高效協作的基石，精準的共識是成事的根本。多數協作的偏差與項目的落空，並非能力與技術的侷限，而是認知與需求的錯位。模糊的主觀感受無法落地執行，零散的想法難以形成統一標準。建立系統化的梳理邏輯，拆解問題根源、明確預期結果、鎖定驗收標準，讓抽象構想轉化爲可落地的清晰需求。統一溝通認知與執行口徑，消解協作中的信息偏差，讓每一次對接都精準對齊，規避無效內耗，讓所有推進都穩步有序。

目的是把問題結構化地描述出來，讓 it 團隊能理解清楚，不跑偏，保證項目成功。 爲了實現這個目的 分 3 步來做： 1.定義清楚問題（有數字支持） 2.定義清楚目的（有數字支持） 3.定義清楚驗收標準（有數字支持） 其實溝通的背後也是這些東西，難點是數字怎麼來？ 紙上得來終覺淺，絕知此事要躬行。

需求三棱鏡: 1，問題:通過現象發現問題本質，本質也需要用具體的數據去體現出來（誰在什麼時間發生了什麼事，問題的數據是什麼樣）。 2，結果:成功的案例是什麼樣，去解決問題得根因。 3，驗收:貫穿整個流程，是一個目標和框架，要從一開始就有一個具體確定的驗收標準，這樣往這個方向努力才能不跑偏。