需求管理做不好，等著 9-12-7 吧
本文閱讀時間大約7分鐘。
在實際工作中，大家很少有機會經歷從0到1的專案，絕大多數情況是加入到一個已經發展了一段時間的團隊，參與維護已經運行了幾年的專案。
回想起來，我這幾年來經歷過多種多樣的專案：從0到1的專案、已經成熟處於維護期的專案、需要重構的核心專案、需要一步步廢棄和下線的專案等等，可以說是專案經驗十分豐富了。
經歷了這些專案之後，我認為，站在開發團隊的角度，評判一個軟體專案成敗的因素，最關鍵的就是兩個點：需求管理和可行性分析。
-
需求管理做不好，體現在兩個方面：需求分析不足、需求隨意變更，這會讓開發團隊做一些臆想的、半成品的需求，做到一半發現沒想清楚，然後陷入到邊做邊改、邊改邊做的魔咒。
-
可行性分析做不好，會讓開發團隊為了一個不可實施的方案去努力，最終獲得的不是成就感，而是挫敗感。
今天這篇文章，是我閱讀和學習《軟體工程之美》中關於需求的兩篇文章寫的閱讀筆記，主要想學習下寶玉老師對需求管理的看法。下面這張圖，是我針對文章的內容梳理的腦圖。
閱讀摘抄
需求是整個產品的源頭，所以說需求分析的結果往往決定了產品的成敗。如果沒有正確把握客戶需求，可能就會一步錯，步步錯！
產品需求是在分析提煉使用者的真實需求後，提出的符合產品定位的解決方案。
軟體專案的需求不是一個需求，而是一系列的需求，所以軟體專案的需求分析需要使用下面這幾個迭代迴圈的步驟：收集需求、分析需求、評估需求、需求設計、驗證需求。
使用者需求背後的真實需求有三個層次：表層需求，使用者對解決問題的期望，例如馬車更快；深層需求，使用者的深層次動機，訴求產生的原因，例如對出行速度的要求；底層需求，人性本能的需求，這裡還可以參考馬斯洛需求層次理論。
評估需求的優先順序，可以使用“緊急重要四象限法”來區分，在專案中要優先做緊急重要的事情，再做不緊急但是重要的事情，這個理論同樣可以用於個人的工作內容管理。
在軟體工程中，還有一個專業的模型，可以用來評估需求的優先順序——kano模型。它把需求分成三個型別：必備屬性、無差異屬性和魅力屬性。
-
必備屬性來說，是你必須優先做好的，你不做好，客戶就會不滿意，你做好了，客戶的滿意度只能達到基本的水平；
-
無差異屬性來說，它的客戶滿意度增長曲線是線性的，也就是說，做到一定程度，對客戶的滿意度提升就趨於0了，例如，某個場景的可靠性只需要做到3個9，你努力做到5個9，其實對客戶的滿意度提升並沒有很明顯的作用；
-
魅力屬性，屬於客戶自己沒想到，你幫客戶發現了他之前沒有意識到的需求，iphone的出世就屬於這種需求的例子。
在需求變更這件事上，沒有贏家，每個人都是受害者。 對於軟體工程這樣偏理論知識的學習，你一定不要僅僅停留在瞭解有什麼樣的解決方案上，而是要追本溯源，研究問題背後的原因，研究理論背後的來龍去脈。因為，就算你記住了再多的解決方案，換個專案環境可能就不適用了，所以我們要多去分析、歸納、總結背後的邏輯，這樣遇到類似的問題，才可以做到對症下藥，甚至在沒有現成解決方案的情況下，能自己創造合適的解決方案。
需求變更的管理，作者提出了三個解決方案
-
提升需求確定性，減少需求的變更。這種方案的優勢是對需求理解透徹，後期返工少，缺點是對產品經理的需求分析能力要求高；
-
提升需求變更的成本，規範需求變更流程，減少需求變更的頻次。 這種方案的優勢是可以立馬起到效果，缺點是過於繁瑣的流程不利於專案協作。
-
降低響應需求變更的成本，積極響應需求變更。這種方案的缺點是對軟體架構和專案管理要求比較高。
閱讀心得
-
你瞭解AB測試嗎，有在專案中使用過AB測試嗎？聽說過AB測試，但是沒有再實際專案中使用過。目前公司的基礎設施支援藍綠部署，可以很方便得進行AB測試。
-
極客時間的課程為什麼要支援音訊？從讀者角度來考慮，主要是為了解決使用者有一定自己的時間，但是又沒有辦法閱讀的場景，例如：上下班開車路途中；從專欄作者角度考慮，有些話用文字和圖片寫出來，可能還需要再配合著講解一遍，效果會更好。另外，支援音訊，也增加了作者和讀者之間的另一種溝通媒介，提升了讀者的使用者體驗，例如有些專欄會將“作者口述”作為一個賣點來推廣。
-
你工作中有沒有遇到因為需求分析沒有做好而導致專案失敗的 案例？有，邊改變做、邊做邊改的感覺太酸爽，最後專案雖然推進到了下一個階段，但是團隊的士氣不可避免得受到影響。
-
你參與的軟體專案中，需求變更多嗎？有多有少，都經歷過。
-
你們是怎麼管理需求變更的？文中提到的三種方式，我們主要使用的方案1+方案2，目標是使用方案3。在做需求分析的時候，我們一定會有需求評審階段和會議，提升需求的確定性；做需求變更的時候，我們會在需求迭代會上進行評估，提升變更的成本。不過對於技術團隊來說，如果只是滿足於使用這兩個方案應對需求變更，那是不夠的，因此，我們團隊的目標是利用方案3，在產品中可能經常變動的地方提供配置化的能力，靈活響應需求的變更。
廣告時間
這門課已經進行了三分之二，這是我的第9篇讀書筆記，說實話，對我的幫助非常大，在工作多年後進行了一次軟體工程理論的回爐重造。在這段時間，我有時候會在實際工作中應用在這門課中學到的方法和技巧，對於我的工作效果提升也很大。你是不是在軟體專案中被各種瑣事纏身，但是又不得其法，這門課應該可以提供一定的理論指導。
在這篇文章中，寶玉老師提到解決需求變更的第三個方案是：積極響應需求變更，提供配置化的軟體架構方案，但是對軟體架構和專案管理的要求很高。這裡說到了軟體架構，同時我們在工作中還會接觸到另一種角色——系統分析，系統分析和軟體架構的區別在於，系統分析師面對的是固定的需求，而軟體架構師面對的是未知的、可變的需求。最近七牛雲的CEO許式偉在極客時間開課了——《許式偉的架構課》，這門課一出來，我就訂閱了，這兩天把第一篇音訊聽了三四遍，許大大講得是真的好，我對這門課非常期待，是我另一門準備持續跟下去的課程，歡迎你也一起來學習。
本號專注於後端技術、JVM問題排查和優化、Java面試題、個人成長和自我管理等主題，為讀者提供一線開發者的工作和成長經驗，期待你能在這裡有所收穫。
