依據項目進度組織團隊人員
作為項目經理，如何在滿足客户需求，並在人力資源不足(員工成熟度不夠、隊伍不穩定、工程師工作積極性不高)、工期緊的情況下，有效的制定和執行項目計劃，是項目經理一個重要的能力，而要完成這一進度人員的組織非常重要。下面關於依據項目進度的人員組織實踐的文章，歡迎大家閲讀!
1. 問題的提出：項目的進度度量
1.1進度不可控的原因
在實際的項目執行過程中 ，缺乏合理的時間進度是造成項目滯後的最主要原因，原因是什麼呢?
首先，對估算技術缺乏有效的研究，很多項目經理對項目進度過分樂觀的估計，它反映了不真實的假設——一切都將運作良好。
第二，採用的估算技術隱含地假設人力和工作量可以互換，錯誤地將進度與工作量相互混淆。
第三，對自己的估算缺乏信心，軟件經理通常不會有耐心持續地進行估算這項工作。
第四，對進度缺少跟蹤和監督。跟蹤技術和常規監督程序。
第五，當意識到進度的偏移時，下意識的反應是增加人力。只會使事情更糟。
對於創造者，只有在實現的過程中，才能發現我們構思的不完整性和不一致性。在估計和進度安排中，某個任務可以分解給參與人員，他們之間需要相互的交流。子任務之間需要相互溝通和交流的任務，必須在計劃工作會考慮溝通的工作量。
溝通所增加的負擔由兩個部分組成，培訓和相互的交流。每個成員需要進行技術、項目目標以及總體策略上的培訓。因此工作量隨人員的.數量呈線性變化：按照n(n-1)/2遞增。
1.2進度的經驗性安排
項目進度和工作量的不同：工作量只是子任務的數量的簡單分解。項目進度依賴於順序上的限制，以及資源制約、培訓時間、管理成本等。
這裏有一個基於經驗的時間安排尺度。假設以一個項目的總體執行項目週期為1。對於軟件任務的進度安排的經驗法則：
·1/3計劃
·1/6編碼
·1/4構件測試和早期系統測試
·1/4系統測試，所有的構件已完成
除了系統測試，進度基本能保證。不為系統測試安排足夠的時間簡直就是一場災難。因為延遲發生在項目快完成的時候，問題才出現在客户和項目經理面前。延誤發佈，將付出相當高的商業代價。上述的二次成本遠遠高於其他開銷。
因此，在早期進度策劃時，允許充分的系統測試時間是非常重要的。開發並推行生產率圖表、缺陷率、估算規則等等，而整個組織最終會從這些數據的共享上獲益。項目經理需要挺直腰桿，堅持他們的估計。
當一個軟件項目落後於進度時，加派人手可能產生的進度災難。
·要及時聘請到多麼能幹的新員工;
·新員工需要接受培訓。有經驗的職員將投入到原有進度安排以外的工作中;
·原先劃分為三個部分的工作，會重新分解成五個部分;
·更多的交流成本、管理的工作;
·某些已經完成的工作必定會丟失，系統測試必須被延長。
2. 團隊的組織
大型項目的每一個部分由一個團隊解決，而並非一擁而上。由一個人來進行問題的分解，其他人給予他所需要的支持，以提高效率和生產力。
2.1協作成本
需要協作溝通的人員的數量影響着開發成本，因為成本的主要組成部分是相互的溝通和交流，以及更正溝通不當所引起的不良結果。所以並不是人越多越好，系統應該由儘可能少的人員來開發。
2.2成員差異
程序員最好的和最差的表現在生產率上平均為10:1;在運行速度和空間上具有5:1的驚人差異。
2.3團隊組織關係
一個項目中的兩種角色安排的三種可能的關係，他們是：
1 產品負責人和技術主管是同一個人。這種方式非常容易應用在很小型的隊伍中，可能是三個或六個開發人員。在大型的項目中則不容易得到應用。原因有兩個：第一，同時具有管理技能和技術技能的人很難找到。思考者很少，實幹家更少，思考者-實幹家太少了。第二，大型項目中，每個角色都必須全職工作，甚至還要加班。對負責人來説，很難在承擔全部管理責任的同時，還能抽出時間進行技術工作。對技術主管來説，很難在保證設計的概念完整性，沒有任何妥協的前提下，擔任管理工作。
2 產品負責人作為總指揮，技術主管充當其左右手。這種方法有一些困難。很難在技術主管不參與任何管理工作的同時，建立在技術決策上的權威。顯然，產品負責人必須預先聲明技術主管的技術權威，在即將出現的絕大部分測試用例中，他必須支持後者的技術決定。要達到這一點，產品責任人和技術主管必須在基本的技術理論上具有相似觀點;他們必須在主要的技術問題出現之前，私下討論它們;產品責任人必須對技術主管的技術才能表現出尊重。
3 技術主管作為總指揮，產品負責人充當其左右手。這種組合可以使工作很有效。不幸的是它很少被應用。不過，它至少有一個好處，即項目經理可以使用並不很擅長管理的技術天才來完成工作。
2.4團隊組成
在一個大型項目中，軟件項目經理必須為成員良好的分工，組成有層次的結構。
系統結構師，從上至下地進行所有的設計。要使工作易於管理，必須清晰地劃分體系結構設計和實現之間的界線，系統結構師必須一絲不苟地專注於體系結構。
首席程序員。他親自定義功能和性能技術説明書，設計程序，編制源代碼，測試以及書寫技術文檔。
程序職員。他負責維護編程產品庫中所有團隊的技術記錄。
編輯、祕書。首席程序員負責產生文檔。而編輯進行分析和重新組織，提供各種參考信息和書目，對文檔多個版本進行維護以及監督文檔生成的機制。
工具維護人員。測試人員。
3. 團隊交流
3.1手冊、或者書面規格説明
手冊是產品的外部規格説明，它描述和規定了用户所見的每一個細節;同樣的，它也是結構師主要的工作產物。
隨着用户和實現人員反饋的增加，規格説明中難以使用和難以構建實現的地方不斷被指出，規格説明也不斷地被重複準備和修改。然而對實現人員而言，修改的階段化是很重要的——在進度表上應該有帶日期的版本信息。
手冊不但要描述包括所有界面在內的用户可見的一切，它同時還要避免描述用户看不見的事物。後者是編程實現人員的工作範疇，而實現人員的設計和創造是不應該被限制的。體系結構設計人員必須為自己描述的任何特性準備一種實現方法，但是他不應該試圖支配具體的實現過程。
規格説明的風格必須清晰、完整和準確。用户常常會單獨提到某個定義，所以每條説明都必須重複所有的基本要素，所以所有文字都要相互一致。這往往使手冊讀起來枯燥乏味，但是精確比生動更加重要。
3.2周例會
周例會由所有的結構師，加上硬件和軟件實現人員代表和市場計劃人員參與，由首席系統結構師主持。
會議中，任何人可以提出問題和修改意見，但是建議書通常是以書面形式，在會議之前分發。新問題通常會被討論一些時間。重點是創新，而不僅僅是結論。該小組試圖發現解決問題的新方法，然後少數解決方案會被傳遞給一個和幾個結構師，詳細地記錄到書面的變更建議説明書中。
接着會對詳細的變更建議做出決策。這會經歷幾個反覆過程，實現人員和用户會仔細地進行考慮，正面和負面的意見都會被很好地描述。如果達成了共識，非常好;如果沒有，則由首席結構師來決定。這需要花費時間，最終所發佈的結論是正式和果斷的。
這種會議的卓有成效是由於：
1.每週交流一次。因此，大家對項目相關的內容比較瞭解，不需要額外培訓。
2.上述小組十分睿智和敏鋭，深刻理解所面對的問題，每個人都要承擔義務。
3.當問題出現時，在界線的內部和外部同時尋求解決方案。
4.正式的書面建議強制了決策的制訂，避免了會議草稿紀要方式的不一致。
5.清晰地授予首席結構師決策的權力，避免了妥協和拖延。
3.3電話日誌(交流日誌，BBS等記錄)
隨着實現的推進，無論規格説明已經多麼精確，還是會出現無數結構理解和解釋方面的問題。顯然有很多問題需要文字澄清和解釋，還有一些僅僅是因為理解不當。討論和解決，在BBS上做出記錄。問題的答案(對問題的認識或者想法記錄下來)必須是可以告知每個人的權威性結論。
3.4質量會議
項目經理最好的朋友就是他每天要面對的敵人——獨立的產品測試機構/小組。該小組根據規格説明檢查機器和程序，充當麻煩的代言人，查明每一個可能的缺陷和相互矛盾的地方。每個開發機構都需要這樣一個獨立的技術監督部門，來保證其公正性。
4. 為變化組織架構
每個人被分派的工作必須是多樣的、富有拓展性的工作，從技術角度而言，整個團隊可以靈活地安排。
當系統發生變化時，管理結構也需要進行調整。管理人員和技術人才的能力給予培養，使管理人員和技術人才具有互換性。
管理人員需要參與技術課程，高級技術人才需要進行管理培訓。項目目標、進展、管理問題必須在人員整體中得到共享。
