隨著對專案管理理解的深入，自己對專案管理的兩點有了深刻理解：需求開發與管理、專案組織結構。
一、需求開發與管理
寬 泛地講，需求**於使用者的一些「需要」，這些「需要」被分析、確認後形成完整的文件，該文件詳細地說明了產品「必須或應當」做什麼。所以如果只有一些零碎 的對話、資料或郵件，你就以為自己已經掌握了需求，那是自欺欺人。需求是產品的根源，需求工作的優劣對產品影響最大。就像一條河流，如果源頭被汙染了，那 麼整條河流也就被汙染了。 我們經常看到的是：人們並不清楚究竟該做什麼，但卻一直忙碌不停地開發。
需求開發與管理面臨最普遍的問題是：使用者說不清楚需求。
有 些使用者真的不知道需求是什麼，或者對需求只有朦朧的感覺，他當然說不清楚需求。例如，早期的**資訊化專案使用者通常只有乙個朦朧的資訊化感覺而已，需求分 析中會這樣寫："總之，要實現那種能夠想到就能做到功能。"。如果開發方的營銷人員水平比較高，他能夠在使用者不清楚自己要什麼的情況下引導使用者「消費」。
有些使用者雖然心裡明白想要什麼，但卻說不清楚需求。 比如說買鞋子。我們非常了解自已的腳，但很難用語言說清楚腳的大小和形狀。通常拿鞋子去試，試穿時感覺到舒服才會買鞋。一些企業的資訊化專案，每個子部門對自身的需要很清楚，但不知道如何從系統角度來要求。
因 此，我們可以說專案開發最困難的部分也就是準確說明開發什麼。最困難的概念性工作是編寫出詳細的需求，包括所有面向使用者、面向機器和其它軟體系統的介面。 此工作一旦做錯，將會給系統帶來極大的損害，並且以後對它修改也極為困難。為此，需求分析員絕不能以使用者說不清楚需求為藉口而草率地對待需求開發工作，否 則會連累整個開發團隊的。
業內來看，乙個成熟、成功的專案，通常它在前期需求、系統設計投入的工作量比例會大於30%。
1、需求開發 與分析
需求開發的目的是通過調查與分析，獲取使用者需求並定義產品需求。根據需求調查和需求分析的結果，進一步定義準確無誤的產品需求，產生《產品需求規格說明書》。系統設計人員將依據《產品需求規格說明書》開展系統設計工作。 乙個良好的需求說明書，應該有如下特徵：
1.1 正確
需求規格說明書應當正確地反映使用者的真實意圖，開發者和使用者自己都不明白使用者究竟「想要什麼」和「不要什麼」。為確保需求是正確的，開發方和使用者必須對《需求規格說明書》進行確認。
1.2 清楚
清楚的需求讓人易讀易懂，包括文件的結構、段落等是否清晰。
1.3 無二義性
「無二義性」 是指每個需求只有唯一的含義。
1.4 一致
「一致」（consistent）是指各個需求之間不會發生矛盾。矛盾常常潛伏在需求文件的上下文中。
1.5 必要
開發者應當集中精力先完成必要的需求，如果條件允許則再做「錦上添花」的需求。為了避免主次顛倒，應當在《產品需求規格說明書》中將那些「錦上添花」的需求設定為較低的優先順序。
1.6 完備
「完備」（complete）是指《產品需求規格說明書》中沒有遺漏一些必要的需求，比如是否覆蓋了所有的功能、效能、交叉、安全等需求。
1.7 可實現
《產品需求規格說明書》中的各項需求對開發方而言應當都是可實現的（attainable）。
「可實現」意味著在技術上是可行的，並且滿足時間、費用、質量等約束。
1.8 可驗證
《產品需求規格說明書》中的各項需求對使用者方而言應當都是可驗證的（verifiable）。如果需求是不可驗證的，那麼使用者就無法驗收軟體，可能會發生商業糾紛。
1.9 確定優先順序
需求的優先順序其實就是需求「輕重緩急」的分級表述，例如劃分為「高、中、低」**。一般地，由使用者和開發方共同確定需求的優先順序。
1.10 闡述「做什麼」而不是「怎麼做」
開發人員常常身兼數職，可能把需求開發、系統設計、程式設計等工作從頭做到尾。他們經常在整理需求的時候習慣性將如何實現的資訊涵蓋在需求中，導致需求可讀性、可驗證性無法保證。
2、需求管理過程域
需求管理的目的是在客戶與開發方之間建立對需求的共同理解，維護需求與其它工作成果的一致性，並控制需求的變更。
需求確認是指開發方和客戶共同對需求文件進行評審，雙方對需求達成共識後作出書面承諾，使需求文件具有商業合同效果。
需求跟蹤是指通過比較需求文件與後續工作成果之間的對應關係，建立與維護「需求跟蹤矩陣」，確保產品依據需求文件進行開發。
需求變更控制是指依據「變更申請－審批－更改－重新確認」的流程處理需求的變更，防止需求變更失去控制而導致專案發生混亂。
2.1需求跟蹤
需求跟蹤的目的是建立與維護「需求－設計－程式設計－測試」之間的一致性，確保所有的工作成果符合使用者需求。 需求跟蹤有兩種方式：
正向跟蹤。檢查《產品需求規格說明書》中的每個需求是否都能在後繼工作成果中找到對應點。
逆向跟蹤。檢查設計文件、**、測試用例等工作成果是否都能在《產品需求規格說明書》中找到出處。
正向跟蹤和逆向跟蹤合稱為「雙向跟蹤」。不論採用何種跟蹤方式，都要建立與維護需求跟蹤矩陣（即**）。需求跟蹤矩陣儲存了需求與後繼工作成果的對應關係。
我們就曾經出現大家埋頭於開發，最後才發現專案協議書中的乙個小基本功能沒有開發的事故。
2.2 變更管理
需求變更通常會對專案的進度、人力資源、經費產生很大的影響。
如果在專案開發的初始階段，開發人員和使用者沒有搞清楚需求或者搞錯了需求，到了專案開發後期才將需求糾正過來，會導致產品的部分內容需要重新開發。這是要堅決避免的。
如果由於市場變化而導致產品需求發生變更，開發商大可不必為此煩惱，應當高興才對。倘若市場靜如死水，那麼開發商吃了「上一頓」就沒有「下一頓」。正因為市場在變化，才會產生更多商機，聰明的開發商才會有活幹，有錢賺。
其實需求變更並不可怕，可怕的是需求變更失去控制，導致專案混亂。所以需求變更控制是需求工程的重要活動。如果需求變更帶來的好處大於壞處，那麼允許變更，但必須按照已定義的變更規程執行，以免變更失去控制。 如果需求變更帶來的壞處大於好處，那麼拒絕變更。
需 求變更控制過程中最難辦的事情是莫過於「拒絕客戶提出的需求變更請求」。通常情況下開發方是不敢得罪客戶的，但是無原則地退讓將使開發小組陷入困境。解決 這個問題的乙個辦法是事先建立規則：如開發方與客戶方達成「事不過三」的約定，即允許客戶變更三次需求；如果客戶第四此變更需求，開發方有權提請客戶補償 開發投入。
3、深入理解需求
需求的開發和管理有一些規律或經驗可以參考，核心是溝通確認、溝通控制。
3.1認清誰才是"上帝"
我 們說客戶是上帝，是因為客戶的重要性，客戶占有決定性的地位。對於廣大不能清楚描述需求的客戶，專案開發人員負有教育客戶的義務，需要引導客戶，讓他們說 出自己的心聲。客戶往往都是領域專家，對自己的工作有很深的認識，可是由於對軟硬體開發的不了解，往往表達不清，甚至表達不出自己的需求。這時候，就是體 現你的功力的時候了，象對待上帝一樣對待你的客戶。
3.2 耐心是首要的學理工科的人，一般在邏輯思維上會比較好，可是對於客戶來說，可不一定是這樣。一些客戶在了解需求的時候，扯東扯西，含糊不清，只有耐心才能 獲得真正的需求。耐心最後會仍會體現為溝通，只有耐心的溝通，你才能揭開需求的重重面紗。人的行為總是會受到思想的指導，如果你解不開客戶的心結，你就不 可能了解他真正需要的。
3.3 參與是重要的
方 法的乙個重要實踐，就是提倡"現場客戶"（on-site customer）。也就是說，客戶應該隨時和開發人員在一起，隨時提供資料和做出決策。而這個客戶，也必須領域專家，而且能夠有權做出決策。非常的貼近 客戶，甚至可以在做遊戲的過程中完成卡片的填寫，能帶來很強的客戶參與度。
4 擁抱變化
需 求變化是開發人員最討厭的一件事了。可是，就像我們常說"哭不能解決問題"一樣，討厭能解決問題嗎？拒絕客戶的變更要求，要求客戶在需求規格說明書上籤 字。這些做法只能是適得其反。沒有任何正面的、積極的意義。需求變更要求我們的開發工作要迭代式進行，包括需求、設計、實現等階段。這樣才能將變更風險減 到最小。
5 測試
這裡的測試指的是考核軟體專案是否成功的乙個"執行性目標"。例如，開發物流系統的目的是為了縮短產品周轉週期，降低庫存；開發**鏈系統是為了加強和**商的聯絡，降低庫存。這些和具體業務有關的指標都是可以通過細化，用多種分指標來度量的，所以是可以做到的。
我們把這種目標稱為測試就是要提醒開發人員，要把滿足這種目標當作最終的測試。
有了明確的需求，我們一定竭力做如下幾件事情：
專案管理之需求管理
需求的變化問題 在軟體開發過程中如果只有一條真理的話，那一定是 需求的變化是永恆的，需求不可能是完備的。軟體開發的過程實際上是同變化做鬥爭的過程，需求的變更不一定是壞事，也有可能是好事，是商業機會，對市場敏感的人可以從需求的變化中發現市場機會。需求變化的原因很多，如 一開始沒有識別全，需要增加需求 ...
專案管理有感之需求調研
乙個專案中需求調研的充分與否是專案日後成敗的關鍵要素之一，這一點我想沒有哪位專案經理不認同吧？不過咱說的需求調研可不只是拿張紙記記客戶說什麼就完了，調研顧名思義就是調查和研究客戶的想法，我感覺應從以下幾個步驟入手 客戶想要什麼？要這幹什麼？為什麼這麼想？會不會有別的想法？這裡也說乙個最最最最基本的，...
專案管理之需求調研感悟
乙個專案中需求調研的充分與否是專案日後成敗的關鍵要素之一，這一點我想沒有哪位專案經理不認同吧？不過咱說的需求調研可不只是拿張紙記記客戶說什麼就完了，調研顧名思義就是調查和研究客戶的想法，我感覺應從以下幾個步驟入手 1 客戶想要什麼？2 要這幹什麼？3 為什麼這麼想？4 會不會有別的想法？這裡也說乙個...