2013.5.26
需求階段的工作是專案經理最繁忙的一個階段，也是項目能否做好的一個重要分水嶺。通常此階段要完成系統需求的編寫，工作思路的整理，工作計劃的制定，人員工作的分工，並且伴有大量的評審。如果稍有不慎就很容易被拉入到漩渦中，失去了自己，不停的被別人推著走，心情苦悶不說，還會為整個項目埋下層層地雷，才是真正的悲劇。
因為使用者需求是由主管/產品經理編寫，系統需求有項目組編寫，因兩個需求工作有著一定程度的並行，因此合在一章寫。 按專案管理的五要素分解如下：
1、干係人期望-目標
使用者需求： 使用者需求通常由主管或產品經理進行編寫，主要目的站是在客戶的角度上描述遇到的問題，並將其抽象為客戶的使用情境及對應我們項目能夠提供的解決方案。 使用者需求文檔在解決方案的描述通常粒度比較粗，因為在評審中解決方案的思路有可能被變更，過多的細化解決方案，工作量返工的成本會比較高。 使用者需求的主要干係人： 1) 上級領導：評估該項目的價值，投入產出比是否合適 2) 行銷部：評估該項目如何宣傳，宣傳的成本 3) 項目組：以使用者需求為基礎細化系統需求，並理解項目意義
系統需求： 系統需求通常由項目組提供，將使用者需求評審過的解決方案具體化，此文檔的主要干係人： 1) 主管/產品經理：系統需求是否能完全符合使用者需求，是否有足夠好的使用者體驗 2) 客服部門：支援人員是否便捷，成本如何 3) 開發人員：項目具體做成什麼樣子 4) 測試人員：項目如何驗收，怎樣算通過 文檔要描述清，UI介面（及介面上約束）、關聯功能影響，已知缺陷，異常情境，非功能性影響（效能，穩定性...）等。
2、沙盤-思路 1） 項目團隊參加評審 在使用者需求和系統需求階段中，項目團隊成員應該都參與評審，雖然評審過程中不一定發言，但是會有兩個重要作用： a、強烈的項目參與感 b、對項目原始需求的理解程度 c、對各干係人的期望的瞭解 2）需求品質保證 需求品質保證有兩個很好的實踐可以採用： a、由下一階段的模組作者編寫需求文檔 這樣可以保證作者對需求的理解程度，同時在評審過程中能夠糾正錯誤理解。由於下一階段的作者通常來說更加熟悉改動或新增的模組，因此關聯改動、已知缺陷發現比較容易被他們發現。 b、測試進行需求驗收 記得前幾年參加IBM的管理論壇，當時聽到一個觀點，深有感觸。大概意思是：“只有可驗收的需求才是完整的需求”。需求很難通過描述的粒度來判斷是否完整，清晰，有看過篇幅特別長的需求文檔，寫了N多廢話，但是仔細一推敲就能發現其中的很多遺漏點。 只有當測試的同事拿到需求文檔後，能夠清晰的知道如何來驗收這些需求，沒有任何二義性和模糊的地方，這樣的需求才是完整，清晰的。 測試同事的項目全階段的缺陷預防工作在我們公司推行已久，當目前為止還是需求階段的缺陷預防產出最大。
3） 制定項目沙盤
項目沙盤有兩個重要部分 a、干係人期望分析與落實方法 例：一個項目組為了更好的體驗，翻新了系統的所有頁面。那此時產品經理/主管的期望是很明確的，就是為了客戶體驗。 此時項目組應該在需求討論時（DEMO），介面已經初步完成時，功能都已經調通時，分別各安排一次體驗，以此達成產品經理的期望。 b、項目成功的關鍵因素分析 項目的成功關鍵因素可以使用魚骨圖進行分析，對於研發項目而言主要由3根大骨刺構成：人，流程，技術 例1：一個項目組主要都是有新員工組成，項目組面臨的技術難度不大，這時候新員工的工作品質就會成為關鍵因素，此時可以做進一步分析。
例2：一個項目組效能方法改動和提升技術是最主要的瓶頸，進一步分析如下：
3、計劃制定
1）使用估算清單 項目裡總有一些例行工作，項目組在估算開始前應該整理出此清單，避免項目群組成員遺漏估算項。 一些例行工作例如：環境搭建，每日構建環境的維護，遷入代碼審核，評審時間，測試案例評審時間等 如果當前部門或公司已經提供估算清單，那隻需要根據項目特點做下修改就可以了。
2）落實沙盤 想法和計劃最大區別在於後者已經準備開始執行，不準備實施的想法終究只是想法。經過各種分析、各種集思廣益得出的沙盤是智慧的結晶，需要將他們做到計劃中。通常落實沙盤得到的計劃就是項目組的缺陷預防計劃。
3）自下向上估算，專家核對 估算的方法有很多，這是我所推崇的一種方法。詳見下節：http://blog.csdn.net/liangjingbo/article/details/9008735 估算結束後應該產生項目的詳細project及明確的裡程碑。
4、風險管理 1） 複雜系統裡的關聯影響考慮不周 對於在現有系統新增或修改模組的項目，如果當前系統非常複雜，那麼關聯性問題將很有可能在此階段被大量引入。針對這種情況可行的兩種方法： a、召集專家會診 b、模組負責人提前分析（需要項目組給予時間）
2）估算項遺漏 估算項遺漏會直接導致工作量不準，這裡常見的方法如： a、使用估算清單檢查例行工作是否有遺漏 b、使用需求根據矩陣核對需求是否有遺漏 c、專家把關估算表
3）需求評審變化，導致新增預研項 最令專案經理苦惱的問題之一就是需求的變化，其實有些時候變化的不是需求而是大家對於需求的理解。避免需求變化的帶來的影響，需要做好兩方面的工作： a、需求缺陷預防，專案經理向組員傳遞良好的客戶導向意識，將一些項目組自己能發現的不合理處盡量在前期提出，避免拖拉到後期帶來更大的影響。 b、當需求變化不可避免時，要及時評估是否要進行補充預研，我看過很多心急的專案經理通常急於按計劃推進階段，結果在這上面吃了大虧。 4）團隊的組織架構，不利於及時發現風險 每當我聽到專案經理說“項目品質要等到轉測試後才能知道到底怎麼樣”時，我都會給這個項目打上“高風險”“失控”的標籤。打個形象的比喻，項目是Team Dev的孩子，測試團隊是醫生，要想生個健康的寶寶，懷孕前期及期間的工作是最重要的。當一個孩子已經出生時，孩子的體制和健康情況已經有了基本定論，如果這時醫生才檢查出有嚴重缺陷（例如，某個模組的代碼寫得很差），那麼已經很難補救了。因此項目組必須要時刻對項目的品質、進度有很準確的把握。 對項目的品質，進度的準確把控，對於大團隊可能有多個選擇，例如： a、成立不同小組，由組長兼顧管理和技術。 b、獨立出兼職的技術專家團隊負責技術，專案經理負責管理 c、獨立出全職的技術經理負責技術，專案經理負責管理 等... 組織圖的方法可以多種多樣但是一個原則是要能夠及時有效發現風險。 在這方面我和我的搭檔嘗試過一種方法，可以作為一個實踐供大家參考，我們當時製作了一個項目模組品質跟蹤表，以及時發現風險。 跟蹤表裡的第一部分是：項目組的所有模組、負責人，涉及的專家名單 第二部分是：對模組複雜度，難易程度的自評、專家評定 第三部分是：對模組設計情況的自評和專家評定 第四部分是：對於編碼階段的代碼品質自評，專家審核評定 ...
5、團隊管理 1）團隊分工及成長計劃 團隊分工是項目需要和組員自身需求的平衡體，完全以項目為導向的團隊會缺乏向心力和持續的戰鬥力。例如： a、一個很優秀的組員，最近妻子懷孕臨盆在即，那麼項目組不應該給其安排工作量特別大的分工。 b、一個做技術很好的專家想轉型為管理員，那麼繼續安排他寫代碼也是不合適的。 好的專案經理應該瞭解項目組員的工作背景，家庭背景，工作訴求。團隊分工時能夠考慮大多數或是優秀人員的訴求，並同他們制定成長計劃，這種激勵是長期的。如德魯克所說：“管理的本質是獲得追隨的人” 2）言路暢達（尊重） 發言權涉及到尊重他人的話題。想看下節：http://blog.csdn.net/liangjingbo/article/details/9008761
3）團隊的口號、文化 團隊的口號決定團隊的文化，口號可以由大家一起討論制定出來，好的口號往往是項目成功的最關鍵的心態因素的簡寫。我經曆過兩個項目組的口號如下： a、細心，細心，我們再細心一些 （這個項目的特點是將近10個分支的代碼合并到一起） b、擔起自己的責任 （這個項目的特點是模組關聯性不高的新模組） 4）獎罰項 口號畢竟是虛的，設立了明確的獎懲措施後，比較容易讓文化落地。獎罰項可以針對個人，也可以針對小組。例如： a、強調細心的項目組，在編譯打包出問題時需要犯錯誤那個人給整個團隊買王老吉。 同樣對於代碼互審階段做得最好的人，要給予獎勵 b、強調擔責任的項目組，在項目模組沒有按期完成的情況下，模組負責人應該安排加班，優先自己搞定。 另外獎罰要做到對團隊有更大的影響，需要做到短期，及時通報當前情況。 a、短期，就是獎罰的結果不能拉得過長，不能在項目結束時在評定，這時候木已成舟，對項目本身已經起不到作用。 b、及時通報，就是要按周或按天通報當前的資料統計情況，以便更大程度的影響大家的日常的工作心態 5）裡程碑慶祝點
裡程碑慶祝的重要性，想看下節：http://blog.csdn.net/liangjingbo/article/details/9008789
6）項目團隊的例行議程 盡量將項目組能例行化的工作時間表明確下來，這樣避免大家工作總是無規律的打斷，影響工作效率。 例如： a、項目組總是周五打包，打完包後驗證準系統，如果準系統有問題，責任人需要當天排除出來，否則周末加班搞定。 b、每周日自動使用上周五的新包，升級所有測試環境 c、每周一項目周會，專案經理講述項目當前情況 d、每天下班前，需要發送當天的日報給組長，組長在第二天早上10:00批覆
