Version: v0.1
首先感謝各位對我的支持，尤其是并肩的十多年的同事和業(yè)內(nèi)大咖的精神鼓勵，使我更加的堅信現(xiàn)在所做的事情是有意義的，暫且不論文筆和水平如何，謹對自己的過去的經(jīng)驗和知識做一個梳理總結(jié)也算是對自己過往的工作經(jīng)驗有個交代，過程中感謝大家關(guān)注我，給我以積極的反饋，使我不斷的完善每一篇的內(nèi)容，以求完美。
原以為可以用一篇把項目群計劃管理完成，但真正進入腦圖梳理的時候，發(fā)現(xiàn)內(nèi)容確實不少，于是分為三篇進行，分別是：
- 項目群計劃管理-1-基礎(chǔ)知識
- 項目群計劃管理-2-計劃制定
- 項目群計劃管理-3-計劃管理
特別是增加了原本我認為沒有必要增加的第一篇，原來我認為重要是實踐的總結(jié)和分享。但是有兩個小故事要跟大家分享。
- 2016年在某省農(nóng)信做監(jiān)理工作，作為總監(jiān)理師開展一個大型IT金融項目的監(jiān)理工作，在某次的一次項目群周例會中，與PMO的管理方就某個監(jiān)理風(fēng)險建議展開了爭論，其中印象比較深的是，對方某合伙人兼任本PMO項目的總監(jiān)對于一些項目管理的基本概念不清楚，例如EPG、風(fēng)險與問題的基本概念以及對項目計劃的理解簡直太樸素了。在這次爭論中處于不利地位。而最終，業(yè)務(wù)方認為監(jiān)理方提出的監(jiān)理意見合理，希望PMO認真對待，并改正。會后，客戶方的總架構(gòu)師拍著我的肩膀說，大白，看來還是你們做PMO更專業(yè)。
- 2017年城商行，該行的新核心系統(tǒng)建設(shè)項目6月份開始籌備，10月份核心開始入場，項目已經(jīng)推進到了11月底，由于前期PMO的缺少專家資源的背景下，導(dǎo)致應(yīng)與籌備期就應(yīng)該完成的里程碑計劃和項目主計劃一直沒有產(chǎn)生，且沒有被評審?？蛻魧Υ藰O為不滿，在項目總監(jiān)的領(lǐng)導(dǎo)下大家通宵達旦的進行項目計劃的制定。
- 在這個背景下，被協(xié)調(diào)到該項目進行支持。而在進入該項目的后，廠商PMO項目總監(jiān)說，大白，我們的計劃已經(jīng)三千多條了，大家的Project用的都很熟啦。然后我問項目總監(jiān)，那么咱們的{紅線}出來了嗎？沒有…………
- 之后的這個周末，行方請來一位項目管理專家，該專家也是業(yè)內(nèi)大咖，二十多年的金融行業(yè)項目經(jīng)驗，而且性格溫和，周末加班與我們一起過項目集成計劃，結(jié)果這兩天的過程中，被這么個性格溫和的項目管理專家給噴了，噴我們的計劃主講人不專業(yè)，基礎(chǔ)概念不清晰的話，將是過不了CIO的關(guān)的。
也就是這樣，被觸發(fā)，決定不再拖了，拿起筆來，開始寫V0.1版的關(guān)于大型金融IT項目管理實踐的文章，就有了之前的開篇《為什么要寫金融IT項目管理這樣一個主題的博客》。
也正是基于此兩個小案例，增加項目群計劃管理第一篇，即基礎(chǔ)知識。如果這些基礎(chǔ)的知識，在沒有統(tǒng)一認識和概念的情況下，要共同協(xié)作完成一件事情，那將是困難重重，勢必造成后期的大量返工，更可怕的是你的客戶和合作伙伴認為unprofessional。
這也是時下社會發(fā)展的一個亂象，即：快速發(fā)展下的浮躁，造成了系統(tǒng)性的不專業(yè)，讓我們進入到一個惡性競爭的惡性循環(huán)。關(guān)于系統(tǒng)性的unprofessional我將會通過我國設(shè)計師之猝和中西項目行業(yè)差異在另外的話題展開。
什么項目計劃？
我們理解的計劃
大多數(shù)情況下，我們在做一個IT項目中所述的項目計劃，通常大家的第一反應(yīng)即：一個進度（時間）計劃。多數(shù)PM認為，我們的項目計劃有工作分解，階段劃分，交付和資源清單，明確的開始和結(jié)束時間，基本也都是excel的自定義字段，有些PM可能用參照Project的字段來制定Excel，或著直接用Project制作計劃。
計劃應(yīng)該有什么？
而事實上項目計劃，不僅僅是一個進度計劃，往往是以進度計劃為主計劃，輔以以下：資源計劃（人力、設(shè)備、環(huán)境）、質(zhì)量計劃、風(fēng)險計劃、度量計劃、集成策略、測試策略等配套計劃，以及根據(jù)項目的類型不同，進行子計劃和其他專項計劃等制定。
所以說，我們認為一個完整的項目計劃，是以項目進度計劃為主，輔以一系列的配套計劃。
基礎(chǔ)知識
在實際的項目管理過程中，從事項目管理的同志們理應(yīng)具備相關(guān)的項目管理的基礎(chǔ)知識，但往往情況并不是這樣的，所以，我還是建議從事項目管理相關(guān)工作的，不管你愿來的是哪個專業(yè)的，都應(yīng)掌握通用的項目管理知識，這些基礎(chǔ)的知識在網(wǎng)絡(luò)上有大量的材料是可以獲取并展開自學(xué)的。如果希望短時間系統(tǒng)化的學(xué)習(xí)，還是建議去參加針對個人培訓(xùn)的國際項目管理資質(zhì)認證課程，如PMP、IPMP或者是Prince2，國內(nèi)的有項目管理師的培訓(xùn)和資質(zhì)。
這里這里我們不展開整個項目管理的體系介紹，我們就在制定項目計劃的實踐中，最常用到的一些基礎(chǔ)知識與大家進行一次學(xué)習(xí)和分享。
這個很關(guān)鍵，如果這些基礎(chǔ)知識不了解的話，與到不懂的客戶或者伙伴可以一次性的忽悠一下，但是長久不了。最慘的是，如果你遇到真的懂的客戶或者專家，不管我們做交流還是開展計劃制定的工作，都會被虐的，而且會很慘。
WBS到底是什么？
WBS：這個一定要講，這是做項目計劃的基礎(chǔ)中的基礎(chǔ)，搞不懂這個WBS是什么？怎么分析？就失去了構(gòu)建項目計劃的基礎(chǔ)。我們一起看看WBS的定義是什么！
WBS定義
WBS = Work Breakdown Structure = 工作分解結(jié)構(gòu)
- 組織和定義整個項目范圍的以{交付物}為目標(biāo)的項目成份組;
- WBS包括管理導(dǎo)向的{交付物}和產(chǎn)品導(dǎo)向的{交付物}。
PMBOK定義： - 以可交付成果為導(dǎo)向的工作層及分解；
- 其分解的構(gòu)成是項目可交付成果和工作；
WBS分解的原則
當(dāng)我們獲得一個項目，并明確在明確項目目標(biāo)和項目需求的情況下，我們開始進行WBS的分解，WBS分解的最底層原則如下：
- 一個清晰的任務(wù)完成
- 一個清晰的責(zé)任人
- 能夠估算工作量和工期
WBS分解的實踐技巧
下一篇將會基于項目計劃的基本認識，展開項目計劃的制定，在這里實踐中的技巧與大家進行分享，在后續(xù)的部分我們可以深入的體會：
- WBS的分解不是PM一個人的工作，而是要項目團隊一起做；
- 在做WBS分解時不要排序；
- WBS的分解粒度，分解成最低層的作業(yè)不大于1個人40小時（建議）；
- 暫時不考慮資源的限制或其他約束；
- WBS分解，面向交付進行分解，同時兼顧管理和產(chǎn)品交付；
- WBS分解的標(biāo)題描述應(yīng)采用：動+名（名+動）；
WBS的各層關(guān)系
WBS的分解是分層的，我們從項目群角度看，理論情況下我們可以參考如下的分層：
- 大型項目/項目集/項目群（Program）；
- 項目（Project）；
- 任務(wù)（Task）；
- 子項目（sub Task );
- 工作包（Work Package）；
- 活動（Activity）；
大家結(jié)合各自在行業(yè)內(nèi)的經(jīng)驗，進行適配，我這里舉個例子，如 - Program = XX銀行新一代業(yè)務(wù)核心系統(tǒng)建設(shè)工程
- Project = 外圍配套改造項目；
- Task = 渠道整合平臺集成
- sub Task = XX接口集成聯(lián)通測試
- Work Package = XX接口與核心的聯(lián)通測試
- Activity = XX接口差異分析/XX接口開發(fā)/XX接口聯(lián)調(diào)
在實踐中，針對一個具體金融IT項目的管理，我們用不到6層的分解，往往進行到了Project、Task、Activity的三層分解。但也管理成熟度高的團隊，做到WBS的四層分解，將Work Package也納入進去。
WBS的知識延展
這里只對WBS的主概念進行了介紹，如有興趣的同學(xué)們可以進行延展的研究，需要根據(jù)自身經(jīng)驗加以對應(yīng)體會，才能夠做到知行合一，而避免學(xué)了也不會做項目的尷尬境地。例如：
WBS字典（WBS Dictionary）：描述工作分解結(jié)構(gòu)（WBS）各組成部分的文件。WBS辭典包括：簡明范圍定義或工作說明、明確可交付成果、相關(guān)活動清單以及里程碑清單。
WBS組成部分（WBS Components）：工作分解結(jié)構(gòu)任意層次上的任何條目；
范圍基準(zhǔn)（Scope baseline）：由經(jīng)過批準(zhǔn)的項目范圍說明書、工作分解結(jié)構(gòu)（WBS）及相應(yīng)的WBS詞典組成。
項目交付成果（Project Deliverables）：在某一過程、階段或項目完成時，產(chǎn)出可驗證的產(chǎn)品、成果或服務(wù)。
驗收的可交付成果（Accepted Deliverables）：經(jīng)項目發(fā)起人或客戶批準(zhǔn)的可交付成果。
變更請求（Change requests）：擴大或縮小項目范圍，修改政策、過程、計劃或程序、修改成本或預(yù)算，或修改進度計劃的請求。
關(guān)鍵路徑相關(guān)概念的定義
關(guān)鍵路徑法
關(guān)鍵路徑法 = Critical Path Methodology（CPM）：一種進度網(wǎng)絡(luò)分析技術(shù)，用來確定項目進度網(wǎng)絡(luò)中各條邏輯路徑的靈活性大?。ǜ訒r間大小），進而確定整個項目的最短工期。從規(guī)定的開始時間開始，利用順推計算法計算最早開始和完成時間，從規(guī)定的完成時間（可能是順推計算所得到的最早完成時間）開始，利用逆推計算法計算最晚開始和完成時間；
關(guān)鍵路徑
關(guān)鍵路徑 = Critical Path：通常（但并非總是）是決定項目工期的進度活動序列。他是項目中最長的路徑。參見“關(guān)鍵路徑法”；
關(guān)鍵活動
關(guān)鍵活動 = Critical Activity：項目進度計劃中，位于關(guān)鍵路徑上的任何進度活動。通常由關(guān)鍵路徑法確定。雖然有些不在關(guān)鍵路徑上的活動從此點意義上說也是“關(guān)鍵”，但這一含義在項目環(huán)境中很少使用。
關(guān)鍵鏈法
關(guān)鍵鏈法 = Critical Chain Method：根據(jù)有限資源來調(diào)整項目進度計劃的一種進度網(wǎng)絡(luò)分析技術(shù)；
關(guān)鍵路徑怎么產(chǎn)生？
我們已經(jīng)對WBS和關(guān)鍵路徑的概念進行了介紹，那么WBS怎么被組合形成項目計劃，形成網(wǎng)絡(luò)圖，并從網(wǎng)路圖中找到那根{紅線}，我們還需要通過下面一系列的動作來形成項目計劃：
任務(wù)排序
這件事情非常重要：
- 完成到開始（FS）。緊后活動的開始依賴緊前活動的完成；
- 完成到完成（FF）。緊后活動的完成依賴于緊前活動的完成；
- 開始到開始（SS）。緊后活動的開始依賴于緊前活動的開始；
- 開始到完成（SF）。活動——為完成工作包而必須開展的工作。
任務(wù)依賴
任務(wù)之間存在依賴關(guān)系，這是形成網(wǎng)絡(luò)圖和關(guān)鍵路徑的重要條件：
- 強制性依賴關(guān)系（硬邏輯關(guān)系）
- 選擇性依賴關(guān)系
- 外部依賴關(guān)系
浮動
- 時間提前量（lead）：可以提前開始緊后活動。例如，新核心系統(tǒng)的開發(fā)項目中，數(shù)據(jù)遷移的數(shù)據(jù)準(zhǔn)備工作可以在接口發(fā)布2周前開始。這就是帶2周時間提前量的“完成到開始”關(guān)系；
- 時間滯后量（lag）：可以推遲開始緊后活動。例如，技術(shù)文件編寫小組可以在編寫工作開始15天后，開始編輯文件草稿。這就是帶15天時間滯后量的“開始到開始”關(guān)系。
約束
- 限制：一些會限制項目團隊選擇的因素；
- 假設(shè)：在做計劃編制時，會有一些因素被認為是真實的、客觀的或確定的；
- 例外：是一些客戶可能認為我們理應(yīng)提供的但我們不會提供的東西。
常用工具
在完成了部分基礎(chǔ)知識的學(xué)習(xí)之后和統(tǒng)一了概念之后，在下一篇計劃制定開始之前，我們有必要了解一下制定和管理項目計劃要用的工具：
單機版
PC平臺
- Microsoft Project（行業(yè)標(biāo)桿，同時也有聯(lián)機版本，但是比較貴）；
Mac平臺 - OmniPlan
Linux平臺 - OpenProj
組織級項目管理平臺
重點推薦國內(nèi)：
- VP 維普軟件（重點推薦）
- 禪道（國內(nèi)開源）
其他的國內(nèi)國際的組織級項管理平臺大家就網(wǎng)上搜索吧，就不在這里做廣告了。
