對曾於海上生活的我而言，我會比較喜歡用「領港」或是「引水人」(但主要還是「領港」啦)，而不是用「領航員」，因為我在思考「專案領航員」這個概念的時候，其實就是源自於「領港」或「引水人」，但為協助讀者的聯想，我才使用「領航員」一詞。
　
　　不論是商船或軍艦，在離靠碼頭或者是進出港口的時候，風險通常都是比較高的，正所謂「行船走馬三分險」，尤其正當進入一個陌生的港口，或者是船老大(船長或艦長)履新不久，對於自己帶領之船艦的物理特性不是非常熟悉的時候，通常會向該港口管理單位，申請領港協助完成離靠碼頭及進出港的整個過程。當船舶要進港前，船舶會在港外等待，等到領港登船，了解船的吃水深度、動力狀況(車舵狀況)、物理特性(通常是旋迴圈、受風面等)，於下達「領港接替操作」後(航泊日誌做成記錄)，領港代替船長老大下達一連串的車舵令，操縱船舶進入港口航道，駛向預先安排好的泊位(碼頭、船渠、或者繫水鼓)，直到船停泊好為止。當然這期間，發生的任何問題，例如船擱淺了、在航道上與他船發生碰撞、或者因為風與流的影響，撞到停靠在碼頭的他船，責任就要由領港來負責了。當然船長自己如果發現有危機存在，而自己可以處理，當然也可以當下下達「船長接替操作」以取回操控權，解除危機。當領港的人也非泛泛之輩，通過考試，而且當過多年的船(艦)長，有非常豐富的海上經驗(起碼也有二十年以上的海上經驗)，當然他的薪水可是非常高的，因為風險很高，出事時他要賠償。

　　在資訊業裡，現在幾乎都是賠錢的專案，軟體廠做一個案子賠一個案子，只能用硬體供貨的微薄利潤來填補一下，純軟體的專案，都因為問題處理及相關的重工，造成時程大幅延誤所衍生之成本，吃掉了原來應該有的利潤。其主要的原因包括 : 工程開發沒有制度、沒有良好的工作常規(習慣)、專案經理沒有管理經驗，專案經理還兼負分析、設計、程式撰寫之責，沒有能力也無暇做好專案經理的角色。由於業界普遍缺乏觀念正確、能力良好的軟體專案管理人才，軟體專案的問題叢生，為此，政府於是想以導入CMMI的方式，以提振我們的資訊軟體競爭力。

　　經過一段時間以來的觀察，雖然有許多的公司導入了CMMI制度，但是除了為了評鑑準備的專案之外，有幾個公司或機構真正用CMMI實踐在軟體發展的專案上了？沒有使用的理由，半多是說 : 因為成本太高所以不能應用，或者專案比較小所以不需要，中小型專案呢？因為客戶東西要的比較急，用CMMI的流程制度會趕不上期程！所以，就是通通不適用啦。理由看似正當，但是個人認為通通都只是藉口而已，真正的原因是專案經理沒有經驗，對於裁適沒有信心，不知道如何應用PAL內部的東西，或者說公司也沒有持續在做相關的教育訓練；另外，顧問的經驗、能力、輔導的方式也是一大問題。

　　基本上，國內的資訊軟體業不似美國制度化的公司，這個意思是，國內的軟體業普遍體質偏弱，因此如果顧問只想動嘴巴及審查文件就完事，可能不能真正為國內的資訊業帶來正面的效益。為什麼顧問只想動嘴巴？我想是因為國內環境的關係，使得絕大多數投入這個領域的顧問，根本沒有(因為沒有機會)真正使用正規工程與管理制度做過專案，就算曾經是參與CMMI導入EPG的人好了，他們也沒有真正應用過那套自己建立起來的制度，更別說用那個制度來帶領專案了，因此，被輔導者儘管可以將文件寫出來，然後照著遵循，苦撐一下渡過難關通過評鑑，但是接下來的實際運用與持續改善就有大問題了。所以這也難怪國內尚無導入CMMI的廠商，真正從制度的運用上賺到錢的。

　　為了解決這些問題，個人覺得應該可以用「專案領航員」的作法來改善一些現象。所謂專案領航員，是在專案中除了自己的專案經理外，再從管理顧問公司僱請一位專業的管理員來擔任「專案領航員」的角色，此專業的專案管理員會直接協調運用專案資源、操作專案的規劃、執行與管理的工作，而專案經理則是觀察這位「專案領航員」的指揮、處置、管理等等的作法，同時擔任協調者的角色，必要時要取代專案領航員。一方面這個專案領航員可以用正確的方法帶領專案，使專案如期如質如預算完成，也可以為公司建立一些典範，若公司有意要導入CMMI，那這些成果都可以成為未來導入時的最佳範例。

　　專案領航員就像前面提到的「領港」，對於他的港口(系統工程、軟體工程與專案管理)應非常了解，他在很多不同的船上當過多年的船長(帶過很多不同的團隊、做過很多的專案)，對於當下港口附近的風向風速，海流的流向流速掌握得很清楚，並能運用車舵與相關的船藝(Seamanship)解決問題及處理碰撞的危機(軟體專案可能的風險及實際的問題能掌握而且懂得採取有效的行動)，並且對於港口的所有的航道狀況都很清楚(軟體或系統的生命週期模型)。

專案「領航員」與CMMI輔導

　　公司要導入CMMI時，想找個合適、具有專業能力的顧問其實並不容易，我們常常會發現，找了半天，找到的顧問可能只是懂得CMMI Model(更糟的是只懂一部分，其他的要由別的顧問來幫忙)，只會照本宣科(理由是：「SEI希望Model的使用者在解釋時，不能脫離CMMI Model」，但這個理由不應該被當成無限上綱，作為拒絕提供進一步有效解釋的盾牌)，但是對於CMMI在實際工作上的規劃與應用卻沒有深刻的體會(就算上過SEI所提供的各項正式進階課程也無法保證透澈了解CMMI框架，因為CMMI來源的理論基礎相當複雜，真正要放到專案裡使用時，會需要更進一步考慮到原始的基礎)，最後所有的痛苦將由被輔導公司的全體人員一起來承擔。被輔導公司若是向顧問抱怨，顧問則會說：「是你們自己沒有好好做！不是我的問題！」(這也是個「好理由」，但顧問在說這些話時，或許需要思考一下，自己在輔導期間，是否已經讓客戶知道相關的問題，並且對於導致制度導入缺乏效益的風險，提出避免或是解決的建議呢？)被輔導公司要如何克服這些問題呢？很多公司打算導入CMMI時，都會對於效益問題有所疑慮的，因此，聰明的公司其實可以要求顧問公司提供預計擔任公司輔導顧問的人員，以一個實際的專案(一年左右的開發專案)，請該顧問擔任「專案領航員」的角色。用CMMI的觀念與常規帶著執行專案，還有顧問公司建議的自動化工具也可以在該案子中一併試行(或許有人要提出質疑，但是既然專案計畫都寫出來了，程序清楚了，應該就容易結合於專案中使用了，如果很麻煩，就算導入了該工具，後續大概也不會有專案去使用了，那對於公司而言，是一種浪費)，以展現自動化工具的效益。專案所執行的PA範圍除了ML2的6(7)個之外，還有就是ML3屬於工程類、專案管理類與DAR等八個PA，均採取能力等級二的方式執行(就是凡事要有計畫、執行、監督與管理)。這樣做可以到幾個好處，被輔導公司可以了解顧問的能力(何時了解？在開始規劃的時候，就可以看出其能力了)，了解顧問的個性(好不好相處，有什麼怪毛病，會不會藏私，是不是能傾其全力)；而顧問也可以透過這個專案，了解到客戶公司的組織文化、公司既有那些的基礎建設、人員的能力如何，並且與公司的所有人員建立關係，而由於這樣的做法，專案領航員對於所有的資源是有處分權的，被輔導公司也可以比較一下，CMMI所強調的管理與公司現行的管理有何不同，甚至於預先看到可能的問題。專案若如期如質結案了，可以展現顧問的管理與問題處理的能力，增加大家對顧問的信心，若不能，至少可以很容易而且客觀地檢討出問題何在。這是「專案領航員」的價值之一。因此，「專案領航員」的概念，對於資訊業界現在經驗不足的問題可以做有效的解決，另外對於顧問公司及預劃導入CMMI的公司事先有所準備，以免貿然投入CMMI導入，非常可能會鎩羽而歸。

專案領航員作法的可能問題

1. 責任歸屬 - 事實上，在規劃階段就可以開始檢視專案領航員的能力了，不行的話就趕快撤換。但是即使專案做到fail掉也沒關係，因為基本上絕大多數的專案都是賠錢的，公司你為什麼要導入CMMI，因為制度不好賠錢了，所以想要有好的制度來提升自己的能力，所以沒有領航員的話，其實狀況會更糟。
2. 顧問公司不願意這麼做，因為這是很耗時間的，而且，這麼做會限制了顧問公司大量搶佔CMMI市場的策略(其實顧問公司大量搶佔市場的結果，常常會使顧問的品質降低)，同時顧問的收入其實也不是很豐厚的，至少我的體認是如此(因為激烈的競爭下，大家削價求售，有案子做，收得到錢就不錯了)。因此個人建議，一個CMMI導入的顧問合約，最好可以簽成兩年半，第一年是由被輔導公司補助顧問的薪水(而且個人也建議，在如期如質如預算結案之後，按該案的營餘比例給專案領航員bonus)，這樣，一方面除了是帶專案外，另一方面也是試用及磨合，為接下來的一年半的CMMI導入奠定基礎。
3. 專案領航員一定要有相關的認證嗎？其實不盡然，目前的PMP有當然是加分效果，但是最好是與軟體本業有關的專案管理認證，因為軟體的特性與建築可不同喔，PMP是以土木建築專案為基礎的PMBOK為認證標的的。

　　專案領航員是一個可以實作的概念，公司就算不想導入CMMI，而只是希望加強專案管理能力，也可以採取這個做法。而有心做好專案管理的公司，也可以僱用專業人士來擔任專業領航員，相信有專業人員的帶領，專案應該有更有機會可以如期如質如預算完成。

----------------
引文: