吃了沒做需求分析的虧

　　我們產品團隊比較特殊，屬於中途接手、臨危受命，額，說臨危也不至於，但坑確實不少。當時產品1.0版本已經發布，正在規劃2.0版本，我們接手了，在三個月內更換了發動機（目標識別的核心算法）、重新設計制造了外觀（前端和UI），按時發布了2.0版本。然而因為時間有限，傳動、轉向、制動系統我們只能沿用1.0版本的部件，於是這輛看起來V587的2.0超跑戰戰兢兢上路了。真是誰開誰知道，擔心絕對不是多余的，轉向基本靠手，剎車基本靠吼，要不要了解一下？產品上線的第一個正式項目，某天遠程查了下事件報表（產品的一個核心功能是通過視頻分析，發現畫面中的車輛違法行為，並觸發相應告警和記錄），word天！半個月報告車輛違法事件30000多次，然而真實事件只占1/500左右！大量的重復報警和誤報，讓我和我的小夥伴都驚呆了，半個月，也就是21600分鐘，每分鐘都在報告事件，我們真應該站在單向玻璃背後看看客戶那復雜的表情，然而並沒有這個機會，這樣的車客戶顯然是不會開上路的。於是，我們決定找負責這個功能模塊的Dev來“祭天”，不，我們還是理智的，趕緊商量對策。

　　那麽，先看看1.0版本的該模塊是怎麽設計的，然而並沒有找到任何Spec，不管是Functional還是Technical的。需求是Dev自己分析的，設計是Dev腦中構思的，邊寫邊改，邊改邊寫，bug不斷，一直處於按下葫蘆浮起瓢的狀態。為什麽要設計這麽幾種事件類型？每種事件類型為什麽是這樣的判斷邏輯？不同事件之間有沒有優先級？相同事件需不需要合並？問題太多，Dev回答的句式基本是：“我覺得……應該是……吧”或者“當時就是……那樣想的吧”。說實話，這位Dev也挺委屈的，直接甩一個功能模塊給他（同一時期還有其他重要任務分配給他），卻沒有任何需求輸入，天知道他都經歷了什麽。沒人告訴他怎樣的用戶會使用這些功能，沒人告訴他需要實現哪些功能，也沒人告訴他用戶需要這些功能來解決什麽問題，一切都靠著自己僅有的產品和行業經驗在猜測，整個過程完全是自由發揮的。另外，我們發現1.0版本的其他幾個功能模塊基本也都有類似的問題，於是，長痛不如短痛，我們決定逐個重構。

先苦後甜

　　趁(忍)熱(無)打(可)鐵(忍)，緊接著一個周末的下午，我開始梳理該模塊的基本需求，用戶的使用場景、不同類型事件發生的場景等等，越深入越發現我們不該一味責怪那位Dev，其實真正分析起來，這麽一個看似簡單的功能模塊，場景也是非常復雜的。到了工作日，馬上叫上相關人員討論、驗證需求，先達成對需求理解的一致。過程自然磕磕碰碰（PM和Dev打架不是沒有原因的，哈哈），行業術語難理解，咱就講故事（Use Case），甚至扯到了哲學思想。最後，需求達成了一致，那位Dev還嚶嚶的說了一句：“早怎麽沒說？”對呀，1.0版本的問題，責任並不全在他。

　　後面的過程就越來越順利了，團隊的技術負責人花了一周時間做了詳細的Technical Spec，並經過兩次討論最終確定，之後一周時間編碼，一周時間編寫測試用例進行測試，集成到2.1版本的相關功能上線了好幾個項目，至今沒有大的問題。如法炮制，我們陸續對其他幾個模塊重新進行需求和場景分析，也許這部分花費了較長時間，但編碼過程反而沒有過多障礙，某些用戶場景還能直接形成測試用例供測試人員使用，重構的這些功能模塊集成後，效果也都很好。

　　另一個正面的例子：春節放假前兩天，一個項目要定制一個報表功能，客戶打電話給我講了需求，由於在出差趕路，電話溝通可能會有誤解，雖然時間很緊，但還是沒有讓公司的同事立即開始編碼，而是先用excel做了一個報表樣式（快速原型）給客戶確認，客戶認可後再開始後續工作，第二天功能順利上線後，客戶只提了一些排序意見。時間越是緊張，越是應該按正確的方法做事，節省的時間、人力不是一星半點。

反思

　　團隊中的每個成員都應該重視需求分析，熟悉用戶場景，知道自己在做什麽樣的產品/功能，PM應該知道，Dev應該知道，Test也應該知道，每個人都能利用“電梯時間”自信的講明自己在做的產品/功能。

　　PM在抱怨Dev和自己溝通不在一個頻道的時候，也應該反思一下，我們對需求的理解是對等的嗎？Dev知道這個產品/功能背後的需求嗎？

　　Dev（特別是涉及交互）也應該多想象自己在單向玻璃背後，或者自己就是客戶，看看客戶願意使用某項功能麽？是按你想像的樣子在使用麽？

以上，讀《構建之法》第8章、10章，結合實際工作有感，文筆浮誇，多有得罪。

需求分析和典型用戶場景