項目管理制度有哪些？

       對IT人員來說，尤其是做項目管理的人，難免會提出一個問題：為什么客戶總是改變需求。幾乎每天，在自己的軟件項目管理職業生涯中，面對用戶需求的變化，切身感受到，如果不能有效地處理這些變化，項目計劃會一再地調整，軟件交付日期一再地拖延，用戶的耐性逐漸消失，研發人員的士氣越來越低落，最終所有的人都在等待一個結果：項目最好立即結束。下面就由小編為您帶來項目管理制度的相關介紹，希望對您有所幫助。

DATATOM DanaStudio

0

0條點評

咨詢產品

免費試用

解決用戶選型困難的好軟件，有各維度的信息

客戶案例

暫無

合作品牌

3

項目管理制度

一、對于需求變更應該做到主動管理

1、在項目合同中，成立變更控制委員會（CCB），并規定嚴格的變更控制流程。一般而言，在合同階段，客戶是很樂意接受這種規范的管理方式的。

2、取得了合同階段的主動后，在實施階段的嚴格執行也很關鍵。不能因為嚴格執行變更流程，就影響和客戶的關系，這方面就要依靠項目經理和技術經理的的管理和溝通藝術。我們的目的不是讓用戶不提出變更，而是讓用戶不輕易，隨便的提出變更。

3、對于用戶提出的變更，可以看實際情況處理，站在客戶立場上為客戶考慮，有些需求，是可以引導客戶在后期的項目中實現，這樣也可以為公司帶來好的項目機會。

   在不斷的學習和實踐中，我總結了兩點比較有效的方法，在軟件研發階段能夠較好地解決這方面的問題。

1、需求分析階段通過原型明確用戶需求

    在軟件項目的需求分析階段，有大量需求信息需要收集、篩選、加工，這是需求管理的開始。客戶和研發兩方面的人員對需求的理解呈現“大體上共識多，細節上差異多”的特點。即使通過反復溝通，最終在時間表限制之內也能拿出一份“用戶需求說明書”，但是以實踐經驗，用戶需求的描述永遠是“不夠清晰”、“不夠明確”的。

   這主要是因為在這個階段，所謂的產品都在大家的大腦中構思，在此階段，原型開發是一個較好的輔助手段，它將存在于大家頭腦中的虛境實實在在地表達出來，一個界面，幾個控件，外觀形式固定了，功能描述明確了，這就是研發部門對用戶的需求理解。

   此時與用戶再次溝通，用戶基本上可以說出來：“這是我想要的”，或者“不，這不是我想要的，我要的是……”。一般情況下，原型之后的需求溝通就實際得多，雙方的理解迅速向一個折衷方案靠攏，一個可以指導研發過程的需求說明書正式誕生了。

2、采用嚴格的需求變更管理流程

    一旦需求分析階段結束，此后如果用戶要求有新的需求加入交付的軟件系統中，需要走需求變更管理流程。這個流程必須在軟件項目成立之初與用戶約定好，一般的軟件企業內部有需求變更的管理流程，可以向用戶解釋這種管理的必要性，直至與用戶就此問題達成共識為止。

   不必擔心用戶不會接受，有過多次成功研發軟件項目經驗的需求變更管理流程，有著它不容置疑的合理性，這正是軟件企業的經驗和價值所在，用戶最終會理解和同意的。

     在此提醒大家，切忌對用戶提出的需求拍胸脯，在此之前可以捫心自問：“如果拍了胸脯，以 后不能按時完成，我能不能負擔全部責任?”這樣冷靜一下就不會胡亂應承了。

   有一個比較好的方式減少這樣的麻煩，就是在需求分析階段之后，與用戶不要親密接觸，而是按照軟件項目的周期，或者雙方在初期的約定，定時通報軟件研發的進展。如果軟件研發采用迭代式開發，就可以在每一期交付產品發布時做這個事情，征詢到的用戶需求將納入以后某期的軟件版本中。

   要想與他人建立長期的共識，就必須遵循黃金圈法，建立真正意義上的共識，這樣才能產生長期的影響。通過與相關方建立共識，項目經理能更好地促進項目的成功。需要對項目的許多場景建立共識。如何形成共識，讓項目經理用金圈法來推薦思維模式。具體地說就是先問為什么？那問問如何？最終決定怎么做？經過這些層面的思考，項目經理就能更好地影響和激勵其他人，從而達成共識，順利完成項目。就建立共識的個案分享來說，希望大家能有所體會，了解建立共識在項目中的重要性和實踐思路，以便在以后更順利地完成項目工作。以上就是小編為您帶來的項目管理制度有哪些的相關介紹，希望對您有所幫助。