隨著各國人力成本日益升高，中國具有廣大及低成本的人力資源，很多跨國公司及企業思考公司策略開始以固守核心競爭力，並執行外包策略原則來運行軟體外包，對企業而言，可以立即取到兩個最明顯的效果：首先，增加ROA（Return of Assets），產生虛擬資產綜效的效果。其次，透過外包機制及磋商找到一流的人才來共同投入創造項目價值。 筆者過去曾經與一流的北京.NET好手及臺灣Architect共創夢幻團隊，來成就企業主的跨國資訊系統，這期間考驗了團隊每個成員的溝通能力、彈性程度、設計能力、實作能力及測試能力，透過同步設計（Co-Design）外包模式的運行，讓團隊每個人均能大展長才。 為達到此目的，專案管理由過去對簡單的同組織單一專案管理，逐漸發展成跨組織跨公司多專案的管理方式，本文將針對軟體外包之專案管理分享實務經驗及相關的運作策略。

從專案管理轉型為專案領導

隨者管理的成熟度跟精緻度越來越高，市面上很多專案管理的書籍、認證應運而生，例如CMMI，PMP等書籍及認證，無不是在強調專案管理的重要性。然而，有個很重要的本質讓我們不得不去注意，專案管理常常強調“人”、“事”的運作所需產生的檔、表單，但忽略與專案所需產生“物”之間的互動與管理，以至於再派工時，常常認為正確的“人”指派正確的“事” 即可以產生正確的“物”。 專案的本質是會變化，好的專案管理就是準備一順變個心境，面對每種變化都有規劃跟應變之道，並有備胎計畫的思維。 現今軟體產業師法建築，發展趨勢逐漸走向精緻專業分工及跨公司、跨領域的方向，譬如軟體設計團隊是一家公司（如同建築事務所）、軟體實作團隊是一家公司（如同工程營建公司），建築已經有百年歷史，走過的每一步都可以變成軟體的借鏡與導師。在軟體產業中，每個公司都掌握特殊的專業能力，與其它公司合作來達成專案目標，這是有別於過去專案執行都局限在個人的組織或公司內部，專案成員單純且簡單，通常成員都對自己的組織文化有某種程度的瞭解。 為此，對於這種跨不同文化組織的專案管理，首要重視的是專案管理的整體性。這與傳統專案經理的管理模式相差甚遠，後者通常以自己組織與文化利益為基礎考慮。這種強調以架構為中心的專案管理模式主要以聯合作業（Joint-Force）方式來進行，團隊的成員對聯合作業都有基本的專業素養及能力，以團隊的整體成功為目標，當發生影響到整體目標時，通常以此整體目標為導向，而非以個人或公司的部分利益為主的專案領導模式運作將主導一切。 傳統的專案管理，專案經理習慣按照專案管理的硬技術排定所有的流程及事情，專案成員按照PM制定程式執行事情，常常造成溝通不良、彈性不夠的團隊，最後資源不足，草草收場或政策性結案，造成功虧兩饋的遺憾。以架構為中心的專案管理強調不斷顧全整體、協調、回饋、I&I、規劃的過程，根據團隊的資源，協作出最佳的效果。可以想像，所有的團隊成員或許單看每個人都不是最優秀的，但是整體運作結果卻是非常理想的，這是筆者多年執行項目最受感動的地方。 在上述的專案管理的本質，我們會發現有下列幾個基本特質： 1.專案成員不再局限在公司內部，而是來自不同團隊之外部資源共同跨國組成。 2.專案成員對專案執行均有一定基本程度的瞭解，而能夠透過每次的互動定義出團隊每個反覆運算的目標。 3.項目成員均有規劃的能力，對執行計畫的規劃擅長以不同的構面運用不同的價值角度思考。 4.專案團隊的所由成員均為主動型成員，而非一般主動與被同型混和團隊。

軟體外包首重架構規劃

為了解決上述的環境變化所造成的影響，專案管理模式本著順應變化的原則及思考本質，以架構為中心之聯合作業的專案管理（Architecture-Centric Joint-Force Project Management）應運而生。在介紹其特色之前，先對架構及項目做個概略說明，用以表達Boundary。在架構思維上，以系統架構（Systems Architecture）為最大化。一個系統，又稱一個資訊，又稱一個知識，上帝所創造的世界萬物是一個系統，太陽系是一個系統，一粒沙子也是一個系統。依此觀點，組成沙子的結構與行為合一產生沙子的系統架構，而架構不再局限軟體架構、硬體架構，更擴展到企業架構、知識架構、思考架構應用上，這是一個很有趣的現象。過去架構師對架構從無法表述到可以利用許多工具方法自由地表述，如企業架構師可以利用架構框架方法來描述架構。

（點擊圖片鏈接看原圖）圖 . 利用架構框架方法來描述架構

這讓我想到一件有趣的思維，架構其實是一直存在這世界，組出世界萬事萬物的有機體。持不同觀點的人會透過各種方式來描述它，若以原子分子（Element） 的角度，這些Elements組出架構產生沙何嘗也不是一個架構觀點，而宇宙萬物均有其Elements，每個Elements之間關係組出生生不息的萬物，就是架構的一種觀點。你會發現，原來描述架構，產出架構的過程是Multiple View的組合，而架構在每個時間點所產出的只是當下“演化（Elaboration）”團隊智慧創造的結果。 再來談到項目，一個項目的人力資源會決定這個專案的成敗因素，正能量的人力資源在執行項目時若搭配應技術，通常成功的機率較負能量的人力資源高。下圖表示所有會影響專案的相關成員，跟其關係，其中Project Stakeholder雖沒有直接執行專案，但通常其展現的態度會對PM在運作項目時造成一定程度的影響。

（點擊圖片鏈接看原圖）圖 . 影響專案的相關成員，跟其關係 (資料來源：PMBOK 2003)

軟體外包實務管理特色

1.以架構為中心的專案管理 好的專案管理必須要有好的專案管理架構。專案管理架構的終極目標，是要創造高品質的系統，以架構為中心的專案管理也是一個I&I(Iterative and Incremental Development)的過程，其運作方式如下圖所示。完成該程式一次，表示完成一個Iteration，是用於產品或專案規劃。從圖中您可以發現，所有的軟體創作過程均須回到Architecture Design團隊，PM在運作排定時程的方式，需要有兩種策略，一為專案開發團隊按照軟體發展程式執行事情的先後順序，二為架構團隊依照“定時不定量”原則於每次固定時間發佈（Release）目前架構描述版本。從圖中，您可以發現架構會掌握系統的全貌來調和出符合各種觀點的系統。

（點擊圖片鏈接看原圖）圖 . 資料來源：Architecture-Centric Software Project Management, 2001

再來針對Mid-Course Corrections來做說明，一輛汽車若進維修廠維修時，常常會檢查汽車零件是否需要更換，微調讓團隊運作更順利，同理，一個團隊“找對的人上車、請不對的人下車”也是一件很自然的過程，而Mid-Course Correction就是這個作用。在每次的Iteration結束前，團隊必定從中學習到很多經驗，而這些經驗也將做為下個Iteration的基礎，因此調整團隊讓其於下個Iteration運作中更順暢是一個寶貴的經驗過程。而每次的經驗累積後就變成企業經營的智慧，能夠幫助企業成長，避免未來犯錯。 2.重視規劃藝術。 計畫總是趕不上變化，但是若沒有計劃，一定應付不了變化，所以計畫的藝術油然而生。試想，一個一直在練習計畫的團隊，組出各式各樣的情境來應變實際執行的狀況，讓項目計畫雖然有風險（Risk），但是可以掌握的，這是一件多麼美好的事情！因此，專案規劃不在於主計畫多麼完美，而在於您所準備的備胎計畫是否靈活充足，以及計畫是否可被百分之百地執行。計畫通常分為兩種，一種為Top-Down Plan，由PM制定目標與方向，一種為Bottom-Up Estimation，由Group Leader估算實際達成所需時程及資源，來共同研擬出可執行的計畫。

（點擊圖片鏈接看原圖）圖 . 以架構為中心的規劃方式

以架構為中心的規劃方式強調 Backward Planning 及 Dynamic Planning，其掌握的精神即為利用動態規劃過程，不斷修正計畫，讓計畫的結果與實際執行結果一致，這是一個整合的過程，把計畫做UPDATE整合到原計劃中，並在且Revision History記錄演變的過程，達到計畫與變化均能兼顧的目的。 3.不同的團隊文化結合 只要對團隊產出物有所貢獻的均視為Project Stakeholders，然而，專案管理者在組立團隊時需要把白領與藍領分開。兵法有雲：兵分兩路，因為常常白領有許多雜訊會影響項目的因素，但並未做決策，並不代表藍領團隊需要受到直接衝擊。成熟的專案團隊知道所有Issues只要尚未決策一律按照原定計劃執行，把這些通常會來自不同的文化團隊成員組立的過程中，團隊紀律是不可或缺的一環，也是一個關鍵的成功因素。 4.塑造敵人來營造團隊士氣 異質型的專案團隊在假設敵人時，若假設錯誤，將會造成專案問題，但若假設正確，將會獲得令人意想不到的效果。筆者過去曾執行一個異質系統整合專案，其經驗是，我們假設變動的需求是我們的敵人，同時也允許需求是可變動的。除此之外，都是我們的資源。在這樣的假設下，我們發現一件有趣的過程，客戶也一起參與變成我們的Worker，一起來把新舊系統做串接及測試。 5.先整合後分工 在臺灣，很多人習慣先分工再整合：每件工作拿過來就先做分工。這是很危險的，因為在不瞭解全貌的狀況下冒然分工，未來可能會發生很大的誤差。以架構為中心會解決這個問題，您會發現所有的資料都會彙集到架構師及專案經理那裡。雙方同時用不同的觀點為專案品質、時程、成本、風險等因素把關，強化專案成功的機會。 6.決策小組的執行力及重要性 異質團隊的專案管理有個很重要的竅門，及成立決策中心做決策，因為觀點不同，所以需要決策中心。筆者過去的經驗是將客戶、PM、Program Manager、Chief Architect組成決策小組，有投票權及否決權，然後Group Leader / Stakeholder有辯駁權及說明權，透過有效的運作決策機制，來決定專案的共同方向及執行效率，這個經驗可以分享給各位，不過決策中心一把尚方寶劍，只有在解決不了的問題才會到決策中心（團隊智慧能解決的問題就解決了，不需進決策中心），通常會由PM不定時的召開決策會議。 7.簽訂合同時會決定未來的格局發展 最後，追本溯源，一個專案的成功於否在簽約時就可以決定未來的格局發展，尤其是針對異質性整合系統，它需要甲、乙雙方均投入資源，共同成就，而在擬約過程就應該考慮雙方的責任義務，免得造成不必要的誤解及變成專案執行的絆腳石，因此團隊若能在簽約前，以架構為中心執行POC（Proof of Concept），製作雛型（Prototype），將會對簽約有很大的保證，是個降低風險的方法。 綜合上述觀點，我們清楚的知道一個成功的軟體外包專案管理實務需要以領導、授權、培育及學習的成熟態度來引領團隊，並搭配以架構為中心的專案管理技術來落實於團隊，更重要的是一個好的外包專案管理不是著重在解決問題，而是完全以預防問題發生為項目領導方向，因此于合同擬定階段到最後實現及運行整個過程，依照先整合後分工，重視規劃藝術，擅長異質團隊文化結合，塑造團隊戰鬥氣息，並利用決策小組共同做出正確的決策等策略來精緻化的完成軟體外包專案管理，共創外包協同合作團隊，來達到專案目標。 註：該篇文章已經於2007年11月刊 程序員 (CSDN, Programmer)