實例化需求不僅解決了需求分析和撰寫的問題，也給出了需求溝通和澄清的方法。本文介紹了一些關於實例化需求的學習和工作體會。
之前聽了一場何勉老師的線上分享課程，他是敏捷和精益開發方面的專家。聽完之後，我最為好奇和想要去實踐的是實例化需求。
於是，這之後，基於線上培訓關於實例化需求的闡述，做了一個更為深入的瞭解。
以下是一篇學習筆記和心得，希望能夠幫助大家解決一些困惑，也為了自己後續工作的實踐。
一、需求中的“之乎者也”
產品經理在日常的工作中，大約80%的時間都在跟需求打交道。
- 2C領域，我們需要了解，分析，拆解，跟進用戶需求；
- 2B領域，我們需要了解，分析，拆解，跟進業務、客戶需求。
需求與產品有一種天然的“唇齒相依”的關係。
為什麼這麼說呢？
在我看來，需求是產品的前置驅動，而產品是需求價值的具象體現。在實際的工作中，產品開發源於，基於需求，也就是需求是產品開發的輸入。
如果輸入源頭缺乏保障，就會變成GIGO（Garbage in，garbage out）：輸入是垃圾，輸出也是垃圾。
需求的分析，澄清和溝通是產品順利落地的保障。於是為了保證源頭的準確，可靠，在我們日常的工作中，通常需求文檔中會堆砌大量的規則、約束條件，這些通常需要很拗口，複雜的文字去書寫。
實踐表明：用文字去書寫規則是件“狗帶”的事情，用語言去講規則更是件“狗帶、狗帶”的事情。
比如一個關於下拉選項的規則：顯示第一個有有效狀態的活躍選項的對應的有效內容。
這個規則無論給用戶、客戶去看，還是給開發和測試同事澄清，都會覺得特別彆扭。前者難以理解，後者難以澄清。
其實不難發現，有時候一些規則就是一些特定情況下的實例，你會發現寫了大半篇幅去說明清楚的幾個規則，舉幾個例子就很輕而易舉的搞定了。
所以，面對需求中的這些“之乎者也”，語言變得那麼的蒼白無力。
二、實例化需求
為了解決上述需求實施過程中的一些問題，實例化需求應用而生。
到底什麼是實例化需求呢？看下圖：
上圖中可以看出實例化需求的三個特徵：
- 用例子來澄清需求；
- 這些例子成為測試用例；
- 開發完畢，用這些例子來驗證需求。
不難發現實例化需求，從始至終都在強調例子。
做產品需要好用易用，溝通需求也需要通俗易懂。
這是我從這次培訓中受益最大的地方，也是最切實可操作的方法。
為什麼要基於實例去溝通需求？一切都源於一種叫做“知識的詛咒”的東西。
人們在溝通的時候不自主的認為別人擁有和自己一樣的背景知識，從而帶來了溝通的障礙和誤解
產品人員對業務比較瞭解，但是對開發知識就比較缺乏；開發人員對開發技能比較專業，但是對業務知識可能並不深入。
這就是知識的詛咒，而例子則可以打破這個魔咒。
實例化的需求，從基本的需求分析開始，到最後的需求交付，整個過程可以基於已有的資源，比如已經上線的系統，然後用可視化的方法進行需求澄清。
在我看來這種方法尤其適用於對於業務規則較多，且複雜的場景下進行需求文檔的編寫和需求澄清。
三、實例化需求的實施
那知道了實例化需求的典型應用場景之後，我們再看一下一個需求中一般包含哪些內容？
先看下面的需求金字塔：
（圖片來之何勉老師分享）
需求金字塔則講述了一個完整需求應該包含哪些內容？
需求金字塔包含了三個層次，這三個層次既是需求分析的層次，也是需求編寫和表述的層次。
需求的目標：需求從溝通目標開始。所謂需求的目標，你可以稱述為這個需求解決誰的問題，什麼問題，當前的現狀，不解決會帶來哪些後果。
操作和操作步驟：為了實現上面的目標，系統需要支持用戶哪些操作？這些操作的先後順序是什麼樣的？
業務規則：基於用戶的操作步驟，在什麼情況下，用戶做什麼操作，會產生什麼樣的結果。這些規則可能是對應一個操作步驟，也可能是對應多個操作步驟之後的綜合的結果。
基於上述需求的三大部分，我們可以分別對其進行落地操作。
（圖片來之何勉老師分享）
如上圖所示，三個步驟：
1. 澄清價值。
澄清當前需求的背景和現在；澄清當前需求想要實現的目標和解決的問題。
其實，這塊我們在平時的工作中特別容易忽略的部分，以為澄清需求只需要把功能點，邏輯，交互和規則講清楚就行。這就是為什麼在需求澄清會上產品經理經常會受到莫名其妙的挑戰，開發和測試同事對需求目標的理解不一致有很大的原因。
2. 識別操作以及操作步驟。
列出相關的操作；畫出各個操作的用戶使用工作流。
這個時候我們需要注意以下幾個問題：
（1）比如流程是否合理和高效？任務走查是一個非常好的驗證方法，這塊後續再議。
（2）是否覆蓋所有場景，異常場景有無考慮，是否全面？
（3）流程是否可以更簡單？
示意圖，流程圖在這裡是一個很好的表現方式，直觀且易於工程師理解。
3. 定義業務規則。
規則其實就是輸入觸發輸出的一個結合。通俗的說就是在什麼情況下，做什麼操作，產生什麼樣的結果。
業務規則是需求文檔中必不可少的內容，因為它關係到邏輯的嚴謹性，進而影響系統的穩定性，最終直接關係到產品的用戶體驗和企業的利益。這個步驟需要考慮的是規則是否完整？是否考慮的各種情況，比如異常、出錯情況等。
對於規則的編寫時最考驗一個人邏輯是否嚴謹的時刻，也是最能體現漢語博大精深的地方。但是如何能夠更直觀，形象的表達出來就是實例化需求的用武之地了。
我工作中的實踐經驗就是：
在傳達信息的效果上：視覺>聽覺>感覺。
所以，在嘗試編寫複雜，拗口的規則時候，多用圖例的方式，少用語言。
四、結語
以上大概就是關於實例化需求的一些簡單學習新的和工作體會。實例化需求在我看來既解決了關於需求分析和撰寫的問題，又給出了需求溝通和澄清的方法。
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
