進工作，定期召集會議，討論制度流程的改進。老子說："治大國若烹小鮮"，煎小魚兒，必須經(jīng)常翻，不翻就煎糊了；但也不能翻得太勤，翻得太勤就會破環(huán)小魚兒的形狀。制度流程也是一樣，不應該變動太頻繁，讓員工不知所措；但也不能永遠"以不變應萬變"。
2. 軟件開發(fā)項目組，包括：項目經(jīng)理、項目成員、質(zhì)量控制專員、項目秘書等，負責具體的軟件開發(fā)。
3. 質(zhì)量保證人員，相當于"檢察院"。其工作主要保證制度流程的順利執(zhí)行，一個質(zhì)量保證人員監(jiān)控幾個項目組了。質(zhì)量保證人員不僅是事后檢查，還必須強化事前和事中控制。質(zhì)量保證人員要主動協(xié)助項目經(jīng)理以及項目組成員理解這些流程、模板、規(guī)范，譬如寫代碼前，質(zhì)量保證人員可以給項目組介紹編程規(guī)范，寫文檔前，介紹文檔的標準、模板等。質(zhì)量保證人員保證公司的質(zhì)量體系在項目組內(nèi)得以實施，每個階段結(jié)束后，都要對該階段的進行質(zhì)量以及流程執(zhí)行情況的總結(jié)，監(jiān)控項目按照質(zhì)量計劃（質(zhì)量計劃是項目經(jīng)理制定的）執(zhí)行。質(zhì)量保證人員還要通過項目組成員搜集數(shù)據(jù)，分析數(shù)據(jù),給出分析報告，等等。

六、需求分析
需求分析貫穿項目始終，在項目過程中會不斷產(chǎn)生新的需求，也會不停地發(fā)生需求變更。需求分析是項目管理的重點和關(guān)鍵，需求分析常見的問題有：
1. 需求膨脹。希望一次解決所有的問題，項目范圍不斷擴大，"把海水煮沸"，最終導致項目失控，偏離原來的項目目標。
2. 需求曲解
a) 需求鍍金。對用戶需求進行了包裝和拔高，"用戶需要的是一輛自行車，而不是寶馬"。
b) 選擇性地過濾用戶的需求，"對一個拿著榔頭的4歲小孩來說，滿世界都是釘子"，需求分析人員可能因為自己的價值觀而片面分析問題。
3. 需求分析人員過早給出解決方案，失去了尋找更好解決方案的機會。
需求分析的"5C"和"5T"原則
1. Correct（正確）：表述的內(nèi)容一和包含的信息應該是準確無誤的。
2. Clear（清晰）：言簡意賅，意思明確，無需別人絞盡腦汁這個需求到底是要表達什么意思，措辭不可含糊不清，模棱兩可，更不能讓人感覺話里有話，引起岐義。
a) 易引起岐義的需求表述句式通常是否定式，而不是肯定式。
b) 不要隱含假設 -- 所有假設都應表述清晰。
c) 對所有需求要進行優(yōu)先級排序。一些需求會比另一些重要，如果需求分析人員已有了這樣的判斷，就應該也傳遞給別人。
3. Complete （完備）：每條需求都應完整無缺，避免漏缺或不必要的重復。
4. Consistent （前后一致）： 需求應能與上下文保持一致。需求應包含關(guān)鍵字或標識符，如"應"代表必要的需求，"將"代表導向性需求，而且全文保持這一種優(yōu)先級定義原則。
5. Changeable（可變更）：對單個需求的更改不會對其他項造成過多影響。
6. Traceable（可追溯）：所有需求的來源都要明確，應可追溯到其他相關(guān)文檔。
7. Tenable（合理）：所表述的需求必須是可實現(xiàn)的和可操作的。 能否在項目預算范圍內(nèi)，利用有限的資源，按時實施這些需求？一條需求是否與其他需求有沖突？是不是正當需求？ 需求實際上都應是必要的。也許需求用"將"來描述更好一些，也就是指，導向性或非基本功能。某個需求是否只是一般描述，與系統(tǒng)功能沒有什么關(guān)系？某個需求是否超出系統(tǒng)控制范圍，或根本不是需求？ 對每個需求，是不是都能找到用途或用戶？有沒有存在的理由？
8. Testable （可測試）：確定每一條需求都可以通過某種方法去測試其是否能實現(xiàn)。是否已量化？容錯性和誤差范圍是否說明？能不能想到一個合理的方法去測試它？ 這個需求的結(jié)果是否可見？
9. Tool （工具性）：需求管理的工具化。
10. Terminology（項目術(shù)語表

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://www.vanceur.cn/pmqhd/index.html