隨著對項目管理理解的深入，自己對項目管理的兩點有了深刻理解：需求開發(fā)與管理、項目組織結構。
一、需求開發(fā)與管理
寬泛地講，需求來源于用戶的一些“需要”，這些“需要”被分析、確認后形成完整的文檔，該文檔詳細地說明了產品“必須或應當”做什么。所以如果只有一些零碎的對話、資料或郵件，你以為自己已經(jīng)掌握了需求，那是自欺欺人。需求是產品的根源，需求工作的優(yōu)劣對產品影響大。像一條河流，如果源頭被污染了，那么整條河流也被污染了。 我們經(jīng)常看到的是：人們并不清楚究竟該做什么，但卻一直忙碌不停地開發(fā)。
需求開發(fā)與管理面臨普遍的問題是：用戶說不清楚需求。
有些用戶真的不知道需求是什么，或者對需求只有朦朧的感覺，他當然說不清楚需求。例如，早期的政府信息化項目用戶通常只有一個朦朧的信息化感覺而已，需求分析中會這樣寫："總之，要實現(xiàn)那種能夠想到能做到功能。"。如果開發(fā)方的營銷人員水平比較高，他能夠在用戶不清楚自己要什么的情況下引導用戶“消費”。
有些用戶雖然心里明白想要什么，但卻說不清楚需求。 比如說買鞋子。我們非常了解自已的腳，但很難用語言說清楚腳的大小和形狀。通常拿鞋子去試，試穿時感覺到舒服才會買鞋。一些企業(yè)的信息化項目，每個子部門對自身的需要很清楚，但不知道如何從系統(tǒng)角度來要求。
因此，我們可以說項目開發(fā)困難的部分也是準確說明開發(fā)什么。困難的概念性工作是編寫出詳細的需求，包括所有面向用戶、面向機器和其它軟件系統(tǒng)的接口。此工作一旦做錯，將會給系統(tǒng)帶來極大的損害，并且以后對它修改也極為困難。為此，需求分析員絕不能以用戶說不清楚需求為借口而草率地對待需求開發(fā)工作，否則會連累整個開發(fā)團隊的。
業(yè)內來看，一個成熟、成功的項目，通常它在前期需求、系統(tǒng)設計投入的工作量比例會大于30%。
1、需求開發(fā) 與分析
需求開發(fā)的目的是通過調查與分析，獲取用戶需求并定義產品需求。根據(jù)需求調查和需求分析的結果，進一步定義準確無誤的產品需求，產生《產品需求規(guī)格說明書》。系統(tǒng)設計人員將依據(jù)《產品需求規(guī)格說明書》開展系統(tǒng)設計工作。 一個良好的需求說明書，應該有如下特征：
1.1 正確
需求規(guī)格說明書應當正確地反映用戶的真實意圖，開發(fā)者和用戶自己都不明白用戶究竟“想要什么”和“不要什么”。為確保需求是正確的，開發(fā)方和用戶必須對《需求規(guī)格說明書》進行確認。
1.2 清楚
清楚的需求讓人易讀易懂，包括文檔的結構、段落等是否清晰。
1.3 無二義性
“無二義性” 是指每個需求只有的含義。
1.4 一致
“一致”（Consistent）是指各個需求之間不會發(fā)生矛盾。矛盾常常潛伏在需求文檔的上下文中。
1.5 必要
開發(fā)者應當集中精力先完成必要的需求，如果條件允許則再做“錦上添花”的需求。為了避免主次顛倒，應當在《產品需求規(guī)格說明書》中將那些“錦上添花”的需求設置為較低的優(yōu)先級。
1.6 完備
“完備”（Complete）是指《產品需求規(guī)格說明書》中沒有遺漏一些必要的需求，比如是否覆蓋了所有的功能、性能、交叉、安全等需求。
1.7 可實現(xiàn)
《產品需求規(guī)格說明書》中的各項需求對開發(fā)方而言應當都是可實現(xiàn)的（Attainable）。
“可實現(xiàn)”意味著在技術上是可行的，并且滿足時間、費用、質量等約束。
1.8 可驗證
《產品需求規(guī)格說明書》中的各項需求對用戶方而言應當都是可驗證的（Verifiable）。如果需求是不可驗證的，那么用戶無法驗收軟件，可能會發(fā)生商業(yè)糾紛。
1.9 確定優(yōu)先級
需求的優(yōu)先級其實是需求“輕重緩急”的分級表述，例如劃分為“高、中、低”三級。一般地，由用戶和開發(fā)方共同確定需求的優(yōu)先級。
1.10 闡述“做什么”而不是“怎么做”
開發(fā)人員常常身兼數(shù)職，可能把需求開發(fā)、系統(tǒng)設計、編程等工作從頭做到尾。他們經(jīng)常在整理需求的時候習慣性將如何實現(xiàn)的信息涵蓋在需求中，導致需求可讀性、可驗證性無法保證。
