需求分析讓人頭禿，筆者針對這個問題展開了通俗易懂的闡釋，希望給大家以幫助。
你有沒有因為需求分析四個字，而感到頭髮日漸稀少？你有多少個失眠的夜，是在思考領導說的“把系統優化一下”這句簡單的話？你又有多少次面對客戶無休止的需求變更，而想要拔刀相向的衝動？
這一切的背後，到底是人性的扭曲，還是道德的淪喪？
朋友，你的福音到了，歡迎來到大型情感類專題：如何進行有效需求分析？
左腦喜歡邏輯，右腦喜歡故事；最好的陳述一定是起於故事，終於邏輯。
今天的內容，就讓我們從一則生活中的故事開始吧。
生活故事
有一天夜裡，資深需求工程師老餘剛忙完一個重要的項目，帶著放鬆的心情進入了夢鄉。
這時他年僅3歲的小孩夜裡醒來，吵著要吃餅乾。孩子的媽媽首先被吵醒，帶著情緒訓斥了小孩：“半夜三更吃什麼餅乾，好好睡覺！”
沒想到小孩不依不饒，繼續哭鬧著。不久老餘被吵醒了，他安靜地走到客廳，找了一小會兒，果然沒找到餅乾。
他隨手拿了兩塊吐司麵包走進臥室，臉上掠過一絲自信的微笑。“小子，沒有餅乾了，吃點麵包填肚子吧！”老餘邊說邊把吐司塞到小孩手中。
果然，小孩接過麵包後就不再哭鬧了，吃完一片就乖巧地躺下。不一會兒，老餘家又歸了平靜。
分析
從故事中我們可以看到：
- 小孩子提了一個需求，即要吃餅乾。
- 而媽媽考慮的是，家裡沒有餅乾了，並且是半夜，想要實現這個需求的話，肯定還要起床下樓，並且找到24小時營業的便利店。這個實現成本太高了，於是斷然拒絕。
- 而爸爸則透過現象看本質，小孩子半夜要吃餅乾，這並不一定真的是想吃餅乾，極有可能是餓了。這樣的需求，可以通過其他更易實現的方式更好地解決。於是，隨手的兩塊吐司麵包，就讓這個家庭又重歸了平靜。
典型的三類人群
孩子=客戶
那你也許會問，為什麼小孩子不能夠直接說“我餓了”，而是一定要“吃餅乾”呢？
因為，這就是典型的客戶思維方式。
我們先給出這樣一個結論：在方案級的探討，客戶是感性的；而在問題級的探討，客戶是理性的。
你是否有過這樣的經歷：
客戶說，xxx功能我們想要，你給我們加一下吧。
這樣看似非常明確的需求，但往往很容易發生顛覆性的需求變更，到最後客戶自己明確說明的這個功能，自己又把它給親手砍掉。原因可能很簡單，也許就是三個字：不好用。
這種經歷，能給我們帶來什麼樣的啟發呢？
這句話很關鍵：客戶是問題專家，而非解決方案專家，他提出的方案未必能夠完美解決他遇到的問題。
小孩子提出想吃餅乾，這是一個方案級需求，這極有可能是因為小孩子腦海中突然回憶起了餅乾的味道，並且小孩子才3歲，客戶的感性思維，在這裡體現的淋漓盡致；而小孩子餓了，這是問題級需求，這才是需求的本質。
我們可以看到，以“吃餅乾”這樣的方案來解決“餓了”這樣的問題，顯然是不合適的。
我們再來說客戶的理性一面，當你跟客戶溝通這樣的話題：“在當前工作中，有哪些方面你會覺得有困難呢？”
這個時候，你會發現，客戶表達出來的內容，就像滔滔江水、連綿不絕，如黃河氾濫、一發不可收拾，並且還會加上各種事例來佐證他的觀點。如果可以，他可能更希望拿個U盤，把他遇到的這些困難直接傳到你腦子裡。
而這些內容，往往都是理性的，都是客觀存在的事實。當然，這也是我們需求分析的突破口，我們後面也會提及。
媽媽=程序員
典型的技術思維，關注的是“方案級需求”，即吃餅乾這個方案能否實現。
我們脫離這個故事，在我們的實際工作中，究竟什麼是技術思維呢？
- 關注點：實現方式、技術架構、技術價值、開發成本。
- 定義：從功能和工程實現出發，在滿足產品需求的同時，尋找可複用技術架構和低開發成本。
爸爸=產品經理
典型的產品思維，關注的是“問題級需求”，即小孩子遇到的本質問題是餓了。
同樣，我們看一下在實際工作中，產品思維是怎樣的定義？
- 關注點：用戶價值、使用場景、商業價值、業務閉環。
- 定義：從用戶價值出發，在滿足商業戰略和業務目標的同時，尋找產品路徑滿足用戶需求。
需求打開的正確方式
通過開篇生活中的故事，我們可以體會到，要做好軟件需求工作，業務驅動需求思想是核心。而作為產品經理或者是需求分析師，我們不是簡單的“需求傳遞者”，我們是“問題解決者”的角色。
那麼，在與客戶進行溝通時，需求打開的正確方式是怎樣的呢？
澄清問題→瞭解背景→建議並確定解決方案
1. 澄清問題
- 想要解決誰的，什麼問題？
- 用戶現在遇到這個問題會採用什麼樣的解決方案？
- 這個問題中有需要進一步細化和明確的概念嗎？
2. 瞭解背景
- 該需求誰使用？什麼時候使用？具體怎麼做？
- 有需要澄清的業務術語嗎？它們的格式是什麼？
- 不做誰生氣？多久生氣一次？多久用一次？
3. 建議並確定解決方案
- 要解決這個問題有哪些可行的解決方案？
- 這些方案的實現成本分別有多大？
- 你覺得哪種最合適？
- 該解決方案對用戶而言有什麼優缺點？
- 有其他需要挖掘的需求嗎？
需求全景圖
寫到這裡，不由地想起之前面試的經歷。
面試官問我，一個產品研發完整流程分為幾個階段，每個階段的佔比是多少。
我當時做了這樣的回答：一個完整的產品研發流程中各部分的佔比，大概50%做需求，30%做開發，20%做測試。
然後，面試官緊接著問我，既然需求分析佔比這麼高，那說一下需求分析的方法論吧。
我突然發現自己對於這方面方法論的研究幾乎空白，只知道最終的產物，是利用Xmind列一個功能清單，但至於這個功能清單是如何得出來的，我當時的認知是具體問題具體分析。
當我看到《有效需求分析》這本書中，提出了“需求全景圖”的概念時，真猶如哥倫布發現了新大陸一般，不禁驚喜萬分。需求全景圖，包含了諸多內容，但自己感觸最深的還是“功能主線”這一項，畢竟我們每天都在與“功能”打交道。
回到我面試的那個問題，最終的功能清單是如何得出來的呢？
最好的思考角度，就是釐清系統中的所有功能是因何而存在的，這也正是我們前面所說的，需求分析的突破口。
功能主線的梳理，無外乎以下三個角度：
1. 業務支持
- 固化優化業務流程，因此業務流程是核心；
- 業務延伸到新的通道（諸如手機端），這從本質上來說也是一種流程的重構，核心還是業務流程；
- 將個人能力轉化為組織能力，這種能力存在於具體的業務場景中，因此“專家場景”是核心（後續的文章會詳細論述）。
2. 管理支持
- 事前風險避免，通過增加管理流程；
- 事中風險控制，通過“規則”和“審批”；
- 事後總結優化，通過“數據分析”。
- 前兩種通常會在業務支持分析中統一處理，第三種則應該獨立進行分析。
3. 維護支持
系統投入使用之後，還需要對其進行維護，最典型的包括初始化、配置、排錯等，而這些運營維護場景也都需要有相應的功能來支持。
當然，功能是我們的最終落腳點，但需求分析不單單是功能，這裡先把需求全景圖展現給大家吧：
結語
需求不是一場簡單的頭腦風暴，也並非高深的諸如馬斯洛需求層次理論，更不是領導交代的任務、運營提供的方案或是客戶要求添加的功能，需求是一項系統的工程，更是一門生活的藝術。
我們經常在電視中看到，古代的那些位高權重的大臣，幾乎每一個都是需求分析高手，沒事就在那犯嘀咕：“皇上今天說的這句話是什麼意思呢？”
由此可見，需求分析不僅僅是軟件領域的方法論，更是存在於我們生活的方方面面，讓我們一起探索需求全景圖的奧秘吧！
注：我們探討的需求分析，是基於B端產品。當然，C端的小夥伴也是可以參考的。
#專欄作家#
曉莊同學；公眾號：曉莊同學產品筆記，人人都是產品經理專欄作家。智慧校園領域的B端產品經理。
本文原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議
