後悔沒有早點讀完這章，回想團隊專案剛開始時做的需求分析，深深感到我們實在太天真、太理想。畢竟沒有理論指導，按習慣做調研是容易碰釘子的，不過現在專案還未正式啟動，亡羊補牢，為時未晚。
我們踩中了哪些坑？
①未能充分引導使用者表達需求
我們採用了問卷調查的方式，但沒有做進一步的深入調研。問卷調查有其好處——簡單方便、調查速度快、資料易統計，但也有固有的弊端，那就是容易形式化，不易讓受調查者充分表達自己的觀點、問題或是訴求。出於節約受調查者時間的目的，題目基本設定為多項選擇，這會有什麼後果呢？填問卷的人看完題目便根據自己的第一反應或最近（最近多久也無法確定）的狀況作出選擇；同時，我們並未進一步的詢問情況，答者也就不會花更多的時間給我們建議或說明實際情況。做完這些後，我們看似獲得了不少資料，作出了一些立即的結論，但這些都是膚淺的。反之，我們損失的是更深入的使用者體驗，而這往往決定著軟體的生死。總而言之，我們把「人」想象的太簡單了，只從片面去考慮問題，得到的結論也將是不完全的。
②理想化思考，調研不夠嚴格
在調研之前，我們確實可以提出自己的想法，暢所欲言，不過，有些決定做得太早卻不是好事。結合之前的討論，我們有不少「我覺得……，所以我們就要/
不要……」的言論，可能我們是將要開發的軟體的目標人群，但充其量只是其中乙個渺小的子集，不能代表廣大使用者群體的需求，除非是一些普遍達成共識的結論，不然都需要經過充分調研才可得出，這也是需求分析的意義所在。過多的「我認為」會帶來先入為主的錯誤，從而降低了軟體功能與使用者需求的覆蓋率，如果因此恰巧錯過了「殺手功能」那就真是追悔莫及了！
③功能分類不明確，缺乏主次
之前我們設想了一大筐可以新增的功能/模組，彷彿吃火鍋一樣，食材怕少不怕多，感覺什麼都能往裡加，然後沉浸在頭腦中建好的羅馬城裡，自我感覺很棒，要是真的做出來了，必定大受歡迎。不知不覺中，我們又犯了理想與樂觀主義的錯誤，試問，這些功能全部做完需要多長時間？這些功能都能真正吸引到使用者嗎？我們的技術（考慮學習新技術的時間及預計的掌握程度）能完成所有模組的開發工作嗎？那麼，我們要怎樣做？進行功能和需求的分類！書中提到的做法我覺得是可取的和行之有效的。按功能分為「殺手功能」和「外圍功能」，按需求分為「必要需求」和「輔助需求」，而這些當然是要根據細緻的調研結果得出的。
當然，這些「坑」只是我們前期存在的比較嚴重的問題，還有其他一些細小的問題就不在此一一枚舉了。
我們該怎麼辦？
對於問題①和②，我覺得可以重新開展調查，至少應該抓住重點物件進行進一步調查。畢竟，我們的軟體可能不是大眾必需品，所以我們要提高對使用者的粘性。在設計問題是，我們需要充分引導答者，讓他們說出心裡話，表達出自己的需求，這樣我們才能充分判定哪些功能是適合開發（有人會用）的。這還不夠，我們還需要看出哪些使用者對這款軟體特別期待或感興趣，再對他們進一步調研，要結合他們的想法來規劃乙個模組具體怎樣設計才是令人滿意的。前者，相當於在一塊地上建東西，到底是建公園還是建大樓？後者，則是具體落實要怎樣建，如果建公園，公園裡該有什麼？如果建大樓，大樓幾層比較好？建成什麼形狀？這都是要通過調研來確定的。
對於問題③，我認為書中提出的解決方案是比較實用的，即按功能分為「殺手功能」和「外圍功能」，按需求分為「必要需求」和「輔助需求」。必要的殺手功能要投入最大的力量去開發，爭取做成自己的特色，與類似軟體拉開差距。必要的外圍功能則可參考其他同類軟體，做到差不多即可。輔助功能則抱完成就好的態度，甚至可以在時間不夠時放棄，之後再陸續新增並改進。
《構建之法》讀書筆記第8章 需求分析
一場戰爭開始前，最重要的就是情報。正所謂知己知彼，方能百戰百勝。而軟體開發前最重要的一點，莫過於使用者需求的分析。做好了需求分析，才能有的放矢，避免開發出為開發而開發的軟體。如何準確的獲取需求呢？書中給出以下步驟 獲取和引導需求 elicitation 分析和定義需求 驗證需求 軟體產品的生命週期中...
構建之法讀書筆記
場景 故事 版權 版本 維護人 1.背景 a.典型使用者 姓名 性別 年齡 職業等 b.使用者需求 痛點 c.假設 2.場景 關於這個場景的文字描述角色 與軟體互動的角色，如使用者等其他實體，甚至時間 主要成功場景 一系列步驟 步驟 描述每一步的互動 擴充套件場景 描述一些意外情況 軟體功能說明書 ...
《構建之法》讀書筆記
乙個軟體除了穩定 功能強大，使用者體驗也很重要。程式開發人員和測試人員在強調其功能和效能的同時，還有一點很注重的就是使用者體驗。在我們學習的最初階段老師們就強調對於軟體開發來說使用者體驗的重要性，無論軟體還是硬體，都有很多功能部件，各個部件還要郵寄的結合起來，才能滿足使用者的需求。其中有一點特別，就...