上一期提到一個能綜觀全覽的Schedule以及歷史資料是PM彌補自身技術經驗不足的重要依靠。

這兩個武器對從事顧問業的我而言，更是關鍵。 在一些大型的導入案中，我會跟客戶PM一起去帶案子，以便能在過程中協助辨識出瓶頸、並找出最合適客戶的管理流程。

可是我未必懂各類型不同的專案，在面對技術問題上不免好似矮人一截。 一般人會以為，好PM必須自己要有能力在技術上也獨當一面。 但我是覺得，技術上你怎麼樣也不可能取代那些十幾二十年資歷的專業主管(除非本來就是從技術人員升為PM)。 事實上，PM也不需要取代他們。 因為專案要成功，本來就需要技術專家的input，除了實際工作與監督外；預估工期、安排工作、調度員工這類事也都需要他們的支援。 所以專案要成功，其實不是誰壓倒誰，而是技術與管理兩邊要取得平衡。

PM的價值，更涉及「如何讓大家一起合作」。 所謂合作，指的是怎麼能讓工作順利接續、辨識那些工作最重要、事先排除風險、確認工作有正確傳遞、確認資訊有正確分享、並排除執行者碰到的問題。 更重要的，是PM要能「幫大家聚焦」。 畢竟時間有限，怎麼把精力放在最重要的事情上，學會抓大放小，這才能讓組織更有效率，並降低衝突。

所以我通常會先理出整個專案的「規劃骨幹」(也就是整體Schedule)，然後跟不同的技術主管合作，並透過正確的「資料收集」方式盡快能掌握案子全貌。 在一起經歷一兩個案子後，我會累積足夠的歷史資料。 如此，我可以越來越少去煩技術人員，我甚至可以開始跟技術主管討論如何調整工作配置，讓事情能朝向更有利於專案的方向進行。

當然，這樣講可能太含糊了，所以我把自己過去碰過的一件事在此分享出來。 在那案例中，我曾經跟客戶的技術主管爭論過「同仁在某個案子上到底該投入多少時間」。 正常來說，這類爭議，如果PM沒有相關技術背景，大概是只能接受那些更有經驗主管的指令。 但我在毫無技術背景的狀態下，卻能跟客戶的技術主管取得共識，並同意照我的規劃進行。 這次爭議解決的關鍵，靠的並不是我懂他的技術，而是我有完善的Schedule規劃以及小心累積的歷史資料作為舉證所達到的效益。

要詳細說明這過程，得先解釋一下案子的背景。

這案子的背景是個3D動畫案。

沒參與過3D動畫的朋友，可能會覺得動畫專案好像不夠高科技，但實際上你這印象絕對是錯的。 3D動畫專案是個非常技術導向、人力導向、以及資金導向的產業。 不但需要大量受過訓練的技術人才(這類資深人才培育大多需要5-10年)，更需要非常高檔的電腦設備(也就是錢)。 比方說能統一校色的螢幕，一台就需要台幣兩萬。 CPU、RAM及顯示卡的要求也很高。 製作完成後的輸出計算，則需要大量伺服器等級的工作站串聯做所謂算圖(Rendering)的動作。 光是算圖用的設備，就不是幾百萬可以搞定的。 為完成一部十三集每集五分鐘的作品，可是需要70-80人一整年的工作投入。 整個案子的金額規模我雖然無法在此透露，可是光以上這些訊息，你大概也有辦法判斷這絕對不會是小案子。

在我親自帶這案子之前，我已經跟這間公司的PM斷斷續續的經歷過一兩個小案子，所以對於整個3D動畫製作流程是先有粗淺認知。 雖然我對工作細節還是不瞭解，但光從平時主管監控進度所用的表單，我就已經察覺原本習以為常的專案流程與時程規劃其實有優化的空間。

舉例而言，動畫中每個角色、道具其實都是獨立的組件。 要真正開始進入製作前，所有製作物必須都得設計並建模完成(註：我在本文中的描述是有稍微把製程簡化，畢竟在這篇文章裏頭動畫的製作流程並不是我要談的重點)。 舉例而言，圖一是史瑞克這部電影靴貓的Model。 在真正能開始表演故事前，相關角色的設計以及3D物件的建模工作都必須完成。 若這段話對你很難理解，你也可以想像是要拍電影。 在真正拍攝前，每個角色是必須來到現場、化妝好、並準備妥當，不然不能拍攝的。 3D動畫也一樣，當各類表演要拍攝前，角色、道具、以及場景的3D模型都得事先製作好才行。

(圖一，史瑞克的靴貓。 照片取自網路。)

但設計與建模因為是兩個部門，所以過往其實是分部門在管控(如圖二)。 這就可能造成幾個問題：

1. 設計部門覺得困難所以先設計的物件，未必在建模也困難。
2. 建模困難的，可能設計部門覺得不重要而延後做。
3. 換言之，先設計的未必是瓶頸的製作物；被設計團隊忽視的有可能反而是瓶頸。
4. 設計出來的有些部分建模會難執行，兩部門有時候來回往返很長時間。
5. PM無法看到整個全貌的Schedule。
6. 工作何時會做完無法被預估。

(圖二，原本的結構。 過往是各部門獨立運作。 設計部工作的人力安排及派工優先順序由設計部主管安排；建模部也一樣。 除非有特殊狀況，才會抽出單項工作安排專人緊急加班。 雖然有Deadline，但通常都不會達成。)

所以我自己接手後，一方面跟幾個主管談流程的重新定義，另一方面我自己案子的WBS就用新的概念來切割(圖三)。

(圖三，這是我親自管理時，開始導入的專案管理系統，並在上面界定了WBS結構。 Character是角色的交付項目，而所有編號01.3.3.1-01.3.3.8的則是本季中要完成製作的角色。)

再來，所有製作角色相關的工作，不分哪個部門，我都集中在同一工作包下。 這樣規劃所繪製出來的Schedule，會類似圖四。

(圖四，我採取的排程概念。 角色A的工作包下面涵蓋了所有完成角色A必須執行的工作。 這包含設計部的工作，也包含建模部的工作。 而最後所有角色完成都接續到Animation的開始處。 好處在於，我隨時能監管在Animation製作開始前要徑是哪個角色？ 其進度如何？ 若角色進度落後會推延到製作時，會造成多大的影響？ 這類問題是一個PM最起碼要能回答，且該隨時關注的議題。)

當把所有製作物的工作包都展開並跟相關集數的製作工序連結完成後，整個專案時程就很清楚了。 比方說圖五就是一個考量了範疇、工作、工作順序後的專案網圖(實際上，在圖上沒呈現的，還包含了人員名稱、人員等級、工時預估、成本等資訊)。

(圖五，專案的網圖。 這東西其實很有用，因為時程之後若有任何狀況發生，我們PM團隊都能及時了解此狀況對整體的影響。 此外，動畫製作過程往往有很多例外或是變動，我們也能分析這些意外、例外、變動、導演改變主意等事項對我們後續的影響。)

各項工作的天期預估我是沒辦法自己來的，所以得請各部門主管協助我預估。 這案子因為是原創(可以直接想像這是個內部研發案的意思)，所以完成時間略有彈性，但還是得多方協調，以產出一個合理且大家都能有辦法達成的Schedule。 最後我再把相關資料都做成Baseline，並放在我們的專案管理系統內。

之後除了定期收集進度外，每週還跟各部門主管討論進度，並決定優先的工作順序。 如此可以確保要徑工作會是由團隊中最強的人員在進行，萬一落後到危險狀態時，我也能請主管協助排除(比方說多加人幫忙，或是請他親自來排除問題)。

如此，在專案進行中，任何變動都能反映在我的Schedule上，無論是進度延遲造成的後續變動，人員的Loading增加、人員離職或是新人加入後對Schedule的可能分析、人員抽調的分析、要徑的變動、甚至我還某種程度的以EVM的精神做出一些產能報告。 這報告是給自己去評估目前人力效率對於後續時間把握度的分析。

(圖六，彙總到第二層WBS的專案總體檢視。 在此可以看到各集數的進展，以及後續的預估完成時間。)

有這些東西後，雖然我還是不懂其中的技術，但是我已能掌握全貌，並在任何變動的初期就讓我看到此變動的「可能影響」。 有任何問題，我也就能第一時間的去找主管討論。 (你看，這不就是專案管理之是有價值之處嗎？)

某天，我被PM Team的同仁回報，說「設計部門的主管在會議上提出要改其中幾項工作的工序，部分人員的工作也打算重新配置。 因為他準備把其中一批人調去另一個案子。」

請問，你若是PM，你會有甚麼反應？ 又會打算怎麼處理這問題呢？

讀者可以先想想，礙於篇幅有限，我的做法等到下期再跟大家分享。