如圖所示，你看到的只是那1%甚至更少，只有不斷的挖掘才能知道的更多

本次系統在迭代的時候，進入UAT階段，由使用者驗收功能的時候，使用者使用bug提交系統提交了一個bug，開發人員直接轉給了我，我一看，這哪是bug呀，這是需求，於是趕緊電話確認，聊了半天，最後發現我們的問題是，業務人員以為這個功能是理所當然必然會有的，故未在需求上進行確認和指出，最後這個功能由於缺失，上線後也無法正常使用，得呢，得再繼續優化並再繼續完善

回首望去，類似的案例有很多，幾乎每次都是相同的情況，業務總是說“我以為這個是肯定有的，這麼簡單的啊，還要提需求啊？”，“這個不是標準配置嗎？沒有這個功能我提這個需求幹嘛呢？”

而我總是解釋或爭辯說，“不是，我們聊需求的時候不是這樣說的”，“沒有，你沒有提就是新需求，最差也是個需求變更，如果是變更，就得往後排”

尤其是在系統還沒有上線，在0到1的孵化過程中的時候，這樣的案例比比皆是

我心力憔悴，他們心有怨言

現在看來，需求是沒有做完的一天，所有的需求，都得分輕重緩急，而不同的角度，不同的角色，輕重緩急的看待又是不一樣

受時間，資源限制，不可能對一個需求完完全全，透透徹徹瞭解清楚後，再開始進行開發，那樣，每個需求可能對系統的改造都是推翻從來

所以我現在的做法是，在需求範圍確定後

1、先嚼一遍需求

對每個需求先從產品的思維角度，對系統的影響程度，要修改的範圍，要測試的點有個大概的度的把握。

再自己提問題給自己，為什麼要這個需求，需求的出發點是什麼，有沒有更好的解決方案，對歷史資料是否有影響等等，儘可能的問倒自己並記錄下自己的問題和答案

通過大致的梳理後，會對這一版的需求有個大致的瞭解，整個過程不會很長，快則1至2個小時，慢則半天，期間可能還會和研發或測試的同學進行溝通，前端怎麼實現簡單又美觀，後臺現有資料是否滿足，測試的邏輯梳理是否有漏洞。

整個流程梳理下來，研發主管及測試心裡會有一個大概的底，並且在此過程中會給很多的建議和意見

2、和業務部門進行詳聊

每次詳聊，我們的業務同事已經知道我的套路，先問為什麼要提出整個需求，需求的目的是什麼，要解決的痛點是什麼，你們希望的流程是什麼樣，再他們描述的過程中，我也會逐步的丟擲我理需求時候遇到的問題，給出我的解決方案徵求他們的意見

以前是我單打獨鬥，現在整個team人員較為充足，我會拉上我們的開發，研發主管一起旁聽，從他們的角度去分析需求對系統的影響和提出他們的疑問

整個過程耗時會比較長，至少是3個小時左右的一個使用者訪談時間

3、整理文件

和使用者訪談結束後，我會用最快的速度，整理出需求文件，從需求目的，需求邏輯，和需求實現3個層面去描述需求

需求目的主要是回答為什麼要這樣做，這樣做的好處，解決的問題等等一些比較寬泛的問題

需求邏輯主要是梳理整個需求的邏輯，對資料的修改的點，對歷史資料的處理，需要測試的點，在這模組會羅列出很多邏輯性的文字，作為業務方需求確認的重要資訊，以及開發人員，測試人員的開發和測試的出發點

需求實現主要是從圖片上展示系統頁面如何實現需求，有哪些按鈕，有哪些列，有哪些欄位展示，此作為和業務部門確認介面，開發同事照此研發

4、需求總結

文件整理後，會再花點時間和業務部門進行再次確認，確認文件中的邏輯內容無誤，確認介面上展示的欄位無誤，也可能經歷多次修改。帶大家確認後，會進行歸檔，歸檔後，無大的邏輯變更的情況下，不再接受業務方的變更。我們會找時間再給研發的同事進行需求的具體講解

其實需求的整理還有很多步驟，以上4步，是我經歷過太多帶血帶肉撕裂的痛慢慢領悟總結出來並現在正在實施的一套方案

在產品的路上，我還是個小學生，還在不停的摸索，求學

望未來，更進一步