專案救援投手
閱讀時間約 19 分鐘
新的舊專案
在我顧問公司PM最後工作的印象，都是做救援投手。在棒球比賽中的救援投手，都是先發投手或是主力投手已經沒辦法繼續投球的時候。不管現況是贏是輸，都要想辦法在後面的比賽中不要失分，贏得比賽。而在ERP顧問這個行業，前一個PM沒辦法繼續現在的專案而要救援投手上陣的理由很多。眾多的理由裡面，因為自己心力交瘁而不想做這個案子的不會理由。因為每一個ERP專案都是PM的重要履歷，除非這個PM不想在這個圈子混了，不然再苦也會想辦法把專案做完。遇到比較多需要我這種救援投手的案例一般都是和客戶無法繼續合作下去，我們一般都說被退貨。
不管多有經驗的PM，都可能因為能力；和客戶磁場不合；專案無法交付等原因被客戶要求換PM。也有一些case是對於一些簽約時談到的模糊的需求有爭議時，因為PM要替公司爭取權益而被迫和客戶發生衝突，我們業界叫這種是犧牲打。
我這次救援的案子比較特別，是因為多次系統上線測試都不順利而沒辦法上線。公司已經換了三個救援投手都陣亡。我已經是第五隻砲灰。由於這個客戶是業界的標竿。第一次去客戶那裡的時候，還是公司總經理帶我過去見客戶的。我到客戶公司的時候正值最熱的八月底，系統上不了線，甲方(就是客戶方)和乙方(就是我們顧問公司)為了釐清(推卸)責任已經吵架吵了兩年多了(專案執行一般是十個月)。接待人員把我和總經理進到會議室時，我覺得一個裡面坐了二十幾個中高階主管的會議室的溫度彷彿比外面低了十度。每個高階主管臉上寫的都是無奈。”老娘我事情這麼多，顧問公司又派一個來送死的PM為什麼還要我出席”。我嘗試很熱情的做完自我介紹以後問大家有沒有問題。會場上的主管們連轉頭看其他人的動作都沒有，只是靜悄悄地看著我，那時我心裡只有一個念頭”我死定了”。
信心建立
客戶端PM
接了這個專案以後，我第一件事情就是尋求客戶端的PM的支持。客戶端的PM一般是一開始在他們公司推動這個專案的核心人物，因為專案是她說要做的，所以這專案的成敗也關係到他的烏紗帽。從某個角度來說，我和客戶端PM是生命共同體。在這次專案，客戶端PM是IT部門的第二把交椅，他負責調配資源和向上溝通。除了她以外還有一個副PM是負責判斷專案執行細節的， Scheduling整理；議題管理；各項報告本來就是我們顧問公司PM要做的事情，但是這個副PM姐姐因為對工廠系統很熟悉，所以要判斷很多技術上的細節。
因為這專案拖太久，所以兩位姐姐很有結構的跟我解釋了這個專案到目前的瓶頸。主要問題在於資料品質和客製程式開發的問題無解。這裡科普一下，其實任何系統都是資料和邏輯的互動，如果一套系統資料或是資料的運作邏輯沒辦法搞定就不能執行。而我這專案很榮幸的同時有這兩個問題。身為有經驗的PM，在我跟姊姊們熟了以後，也開始問每一個專案關係人(stakeholders)對於這專案的態度和個性。聽起來像是聊八卦，但是要了解專案的每一個關係人是PM最重要的工作(沒有之一)。當然，姐姐們也會很主動的跟我抱怨我之前所有PM的不是。這專案甲乙方已經對立成這個樣子並非一日之寒，台灣的產業都是OEM起家的，大家都是對產品品質負責，不會像日本企業一樣重視客戶的聲音。而台灣的顧問公司的人都是美國體系訓練出來的，配教育要重視合約精神，但是台灣顧問公司自己又不把合約寫清楚。所以誤會越來越大。我很認真的聽兩位姐姐抱怨，取得他們的信任，是我避免成為砲灰的最重要一步。
顧問團隊
我在取得姊姊們信任之後。第二件事情就是要取得自己團隊的信任。自己的團隊和客戶同等重要。這麼大的一套ERP，不管是工作量和專業技術，都不是我一個PM可以處理的。如果團隊願意合作，我就只要做專案管理的工作就好。如果團隊不願意合作或甚至內部有矛盾，我就得自己跳下去處理技術問題。更恐怖的，是如果有一些資深的顧問對PM不服，就會像病毒一樣把負面的情緒和對於PM的不信任擴散到團隊其他成員以及甚至客戶那裏(擴散到客戶那裏就是職業道德問題)。
在顧問公司，顧問團隊都是臨時組隊的。有點像是航空公司的飛行員。只要任務一結束，大家都分別被派到其他的專案。所以也理所當然的PM對於這些顧問的考績是沒辦法評價的。我的Case的好處是這個團隊非常團結且專業，壞處是他們對前一個PM很信任。所以對於新來的我的能力有嚴重懷疑。依照某些教科書的教法，是要把PM批評一頓，建立自己的權威。我的方法則不是，我的方法則是蕭規曹隨，既然之前配合得很好就繼續依照原來溝通方法做。
ERP這種案子，一般會有FI, CO, MM, PP, SD這五大模組，原則上都會有五個主顧問帶著副顧問執行他們模組的工作。五個主顧問原則上會依照在業界的經驗年數論資排輩。如果最大的兩個顧問年資都很高的話，CO模組的顧問講話會比較有份量，因為ERP系統最重要的目的是要計算成本。
我這個案子的兩大支柱是FI模組以及MM模組。所以我就以這兩位的意見為團隊的主要意見。技術團隊對於”服不服從PM”的態度都是以PM對ERP的熟悉程度為主。我是碼農(就是像農夫一樣的底層工程師)出身，我對ERP的設定很弱，所以在團隊裡我把自己扮演成一個對客戶溝通的橋樑。至於技術面的專業判斷，除非嚴重跳脫我的邏輯與常識，不然我都尊重顧問們的決定。也就是民主化專案管理。
Stakeholders (專案利害關係人)
建立完自己內部團隊的共識以後，又要回來重建客戶團隊的信心。客戶的ERP團隊一樣依照模組分成五個，我就請PM姊姊幫我借了第一天差點被凍死的大會議室。讓這些User們把問題列出來，我做完紀錄以後一一詢問細節。一般來說，user對於重複性的問題會覺得很煩。”每陣亡一個PM就要問我一次，你為什麼不去問那些陣亡將士”。但是我的問法會帶著我的愛。我不只是問他們目前作業方式怎麼做；為什麼這樣做。我還會問問題問到心坎裡”你每天單這麼多，要弄到幾點才下班?” “所以你到月底要結帳的時候，小孩幼稚園怎麼辦” “系統導入之前你一定要撐住，這公司不能沒有你”。就是這些看似聊天的對話中，我就可以慢慢套出專案無法執行的很多政治面或是溝通上的原因。有很多資深的PM或是顧問因為對於技術太熟悉了，所以問問題的時候都沒有溫度，這樣只能處理表面的問題而不知道實際原因。這些看似無關緊要的關心和閒聊，不但讓我知道很多系統開發窒礙難行的的問題的背後原因；也讓我取得這些user的信任。不只是在會議中和團隊建立信任感。
我幾乎每兩週都會寫信給所有團隊成員，快要六十人。目的是要像是做廣告一樣持續刺激這些成員對於專案的重視。讓他們每週一一打開信就看到這個專案。
當然，這方法不是對每一個人都有效。例如這個客戶的業務副總就不好搞。這副總除了對專案團隊不滿以外；和工廠也有心結。我特別抽了一天時間到業務辦公室去跟他開會。我在我的報告中尋找任何和這副總可以共鳴的話題。我試著用國際化；資訊化；客戶關係等話題都看不到她有共情的眼神。直到我快要放棄，說到客製化議題的時候，我不經意地說”我從來不相信同一套ERP可以套用在任何公司，如果每個公司都用ERP都能執行他們的業務，那每個公司都跟我XXX公司一樣，這樣我們XXX公司還有什麼競爭力”。這時我注意到她不但眼神融化了，而且開始把所有的想法傾囊而出。那時我暗自想，我很有可能不是第五個砲灰了。
專案反抗份子
最後一個要解決的是IT團隊中的反抗份子。固然User中也有很多人牴觸新的ERP，但是IT自己牴觸會是最棘手的。IT之所以會牴觸是因為他們依賴著原來的ERP可以在公司作威作福，一但換了新的ERP他們就要跟菜鳥一樣從頭開始學習(這觀念其實不對，ERP重要的是流程而非程式)。有了姐姐的支持，我就開始要求IT單位在做資料轉檔以後要寫資料檢查程式，這樣才能再把資料匯入ERP之前確保資料夠乾淨(專有名詞叫data cleansing) 。反對派首領當場告訴我說這種程式很難寫，他沒空陪我弄這個(合約上是沒說要做這個)。我不等姊姊幫我罵人，我當場拿了他們的data在會議室花十分鐘把sample程式的主架構寫出來，質問反對派首領說，剩下的程式連大學剛畢業的都會寫，你要我陪大家繼續寫下去嗎? 反對派首領當場不敢講話，事後姐姐也誇獎我，說，這種做黑手的人就是要比他還黑才制得住。
解決問題
我永遠相信，專案成功最重要的關鍵在人心。但是並不是建立了信任關係專案就成功了。前幾代PM留下來的問題不會因為有決心就奇蹟般的自然消失，還是要付出實際行動。
文件品質
前代PM們留給我的第一個問題是專案文件品質的問題。ERP的顧問的時薪很高，所以客戶對顧問公司交付文件的要求也會很高。和一般的文件不同。ERP的規格與教育訓練文件會隨著這套系統使用十年二十年，即使是未來剛入職的員工也會用到這份文件。所以如果文件有令人誤會或是甚至錯誤的地方，這些錯誤就會跟著系統遺臭二十年。
顧問們都長這麼大了，雖然寫錯字在所難免，但是被人家指出錯字這種低級錯誤，誰都會面子掛不住。”客戶是故意找我碴嗎?幾千個字的文件要我自己確認錯字!”。
PM有很多種，有些強勢專制的PM會跟顧問說”寫錯字就是寫錯字，我不管你的文件有幾千字，把字寫對就是你的責任。你知道你自己的價值嗎?”。但是我的”民主PM”風格在接這個案子的時候就已經定性了。我不能跟顧問來硬的。我唯一辦法就是另外找一個人幫我檢查時幾個顧問共同寫的幾萬字文件的錯誤。但是公司怎麼可能派這種小秘書給我?
小秘書沒有，虛擬秘書卻不是不可能。我觀察到顧問群會犯的文件錯誤有兩種。一種是中文錯字，尤其是電腦拼音輸入法的Bug造成的；另一種是對於同一個系統專有名詞，因為一開始都是英文，所以每個人對同一個字的翻譯會有差異。
我建立一套”錯字與同義字字典”，和顧問們一起定義好所謂的錯字和英文翻譯過來的字之後。就讓電腦程式去看著字典掃描那幾萬字的文件，讓電腦告訴我哪個文件的哪裡有哪些問題字詞就好。就這樣，本來是甲乙方的文件交品質的政治問題，就讓我用資訊科技的技術問題給解了。
資料品質
如果說文件品質問題是阻礙專案進行的小坑，那麼後面資料和客製程式兩個問題則是阻礙專案進行的大山。
資料是專案成敗的核心之一，而資料的責任在合約上明顯寫著資料是客戶的責任。所以只要碰到和資料有關係的事情。顧問公司就會把防火牆設定好。顧問公司對待客戶的資料就像對待輻射物質一樣，客戶把資料放到顧問公司的指定位置，然後顧問公司小心翼翼地把資料送進系統，結果是陽性就跟你說你失敗；陰性就恭喜你。絕對不會關心客戶是怎麼做；什麼方法；什麼心情把那個資料做出來。顧問公司都假設客戶在正常的狀況下提供合約上期望看到的完美資料。如果不完美，也是客戶自己要負責。這就是顧問公司所謂的"合約精神"。
其實Data cleansing的觀念和技術早在三十年前就已經有了，也是大學資訊專業的必修課。如果客戶不理解這套技術，就花點時間教他們這概念就好。顧問公司也沒有必要真的下手幫他們寫程式。但是顧問公司為了確保這個"資料的責任屬於客戶"這合約條款的防火牆沒有漏洞，所以連這種簡單的知識都不願意說。
我其實不是為了避免成為下一個砲灰而教客戶這觀念，只為了那個合約的防火牆限制而不能分享我的知識我會很難受。我真心地認為如果我能分享的知識可以解決眼前的問題，就可以和客戶一起讓專案成功。所以我不但教他們怎麼寫。也親自下手做一些資料檢查程式的示範。就這樣，因為資料品質的大幅改善，資料轉檔時間從過去的超過一個月簡化到只需要一天半。解了我第一個大問題。
客製化程式
再來就是客製化程式。主要是因為這案子的客製程式太多了，完全沒有預算可以完成專案所需要的客製化程式。一般ERP的套裝程式，主要都希望客戶儘量用ERP的原有功能，不要因為過去的習慣而修改ERP的功能。但是像給客戶的訂單格式，或是會計公司要求的報表，或是自動拋帳這類的，很難因為系統更換而更換。
ERP專案很難在專案開始以前就知道客戶需要什麼客製化程式，是必須要在充分理解客戶的需求之後才有辦法提供客戶客製化的價格。為了讓客戶放心未來顧問公司不會在專案開始之後對客製化程式獅子大開口，顧問公司的業務也會提供軟體開發工程師的每小時報價(這報價和業界其他程式差不多)。然而，在專案的藍圖階段結束，我們顧問公司提供的客製化程式報價還是遠高於客戶的預期。原因之一是: "所謂報價是單價乘以時數，我在時數上灌水就好啦"。
客製化程式也是顧問公司的重要收入之一，我們顧問公司的這套ERP使用的電腦語言和外界不同，所以花的程式開發時間沒辦法和外界大家使用的電腦語言(python, Java這類的)相提並論。台灣島這麼小，能寫這種特殊電腦語言的公司也只有其他同類型顧問公司。而其他同類型顧問公司都不願意接競爭對手的客製程式開發的專案。換句話說，從這個專案和我家顧問公司簽約那一刻起，客製程式要多少錢就是我家顧問公司說了算。這就是現實。
而兩個PM姊姊就是吞不下這個現實，硬要用外界系統開發公司的價格和ERP的開發成本比。就這樣，這個矛盾對峙了一年多。最後前代PM就體貼的把這個企業合作的結構性問題放在我的手上。和資料的技術問題不同。這是甲乙方的認知差異問題。打破這個僵局，我要有一個第三方公正人，讓甲方知道這ERP的程式的開發成本就是比其他程式高。我也要讓乙方(我自己的公司)知道，客戶有能力選擇其他方法解決問題。
解決方法是業界的另一個特殊領域，叫做freelancer。中文翻譯成"自由職業者"。這些人不隸屬於任何顧問公司。他們透過人脈自己去找寫程式的case來賺錢，一般來說，他們接的案子比較是顧問公司把系統導入之後幾年，客戶要增加功能的時候幫忙寫(他們也不想得罪顧問公司)。但是在這個案子上，他們可以當我的第三方公正人。
當然，顧問公司不可能允許任何顧問(尤其是PM)去自己找freelancer。從某個角度看，PM不讓自己公司賺錢就是吃裡扒外，要是Freelancer價格真的比較低，這部分利潤丟了怎麼辦。但是PM的天職就是要讓專案成功，如果我再陣亡，公司也收不到原本專案的錢。所以，我就找了台灣和大陸認識的freelancers，打好招呼以後，在某個場合中"不小心"把這些freelancers的聯絡方式掉在桌上，被姊姊們"撿走"。姊姊就會積極地和這些人聯絡。最後，果然證明我們顧問公司的價格還是太高了。雖然我不樂見公司以外的第三方團體合作專案(設計和開發永遠都有很多衝突)。但是為了專案。這是必要的犧牲。
信心的建立不是只有靠三寸不爛之舌到處哈拉就能建立的。當PM就是要表現解決問題的能力和態度才能建立客戶對PM的信心。這兩座大山被我剷除了之後。兩位姐姐看到前面廣闊的平原，也對我越來越好了。有一次甚至在我印文件的時候，身為IT處長的PM姊姊還把我工作搶去做，要我去忙其他的。
幫更多的忙
顧問公司很忌諱任何顧問回答專案以外的知識。檯面上的理由是無法承擔顧問提供錯誤答案而對客戶造成的損失；其實應該又回到契約精神，寫在契約以外的服務都要付費。我都是再三跟姊姊們宣稱我的協助是個人行為，和公司無關以後，在時間允許的前提下，我會像是OPEN AI一樣協助回答了很多問題 如何建立產銷會議；如何規劃IT團隊；如何用AI做生產排程；幫忙設計一個IT職位的考試題目等等，只要是我知道的答案我都會分享我的看法和經驗。
危機管理
專案不會永遠一帆風順，移開了大山就和公主過著幸福快樂的生活，而這次我遇到的是百年一遇的COVID 19危機。那時候所有公司老闆談COVID 19都色變。恨不得把所有員工都關在無塵室裡，每個人用保鮮膜包起來，最好是都不要呼吸。對於公司來說，最大病毒的未知進入渠道就是員工的家庭和外部廠商。我們顧問公司也是外部廠商。姊姊們拿出專案合約裡寫的”遇外部不可抗力因素XXXX，可以在雙方同意下終止合約”要我暫停這專案。但是我們顧問公司的成本就是時間，所以直接拒絕。客戶公司的原則就是”廠商不准進場”，所以這問題變成無解。
後來姊姊們幫我想到一個解法。他們花了幾十萬把一個大貨櫃屋搬到他們工廠外面，把網路水電都接到貨櫃裡。並且在貨櫃裡面裝了冷氣和飲水。為了確保這種貨櫃可以工作，我先讓顧問在家上班幾天，自己在貨櫃屋裡工作了一週；把貨櫃屋工作的照片寄給顧問們看，讓他們放心以後才讓他們進駐貨櫃屋。
然而，進駐的第一天顧問們就罷工了。關鍵在廁所。因為甲方的規則就是不能進公司，所以當然不能用工廠內的廁所。姊姊們幫我在貨櫃屋外面做了一間移動式廁所。但是移動式廁所式手動沖水的。不像工廠的那種馬桶(其實在顧問進駐以前我也解釋過)。顧問們覺得自己的工作權利受到汙辱，所以一狀告回公司。公司在沒有跟我求證與溝通的情況下直接叫顧問撤回。剛好那天我跟PM姊姊剛簽完階段付款單。所以從姊姊的角度來看，就是我一拿到了錢就把顧問撤回去。這就是背叛。我也不可能跟姊姊們說我也是被背叛的受害者，畢竟我就是PM，什麼決定理當是我下的。女生最討厭背叛的男人。我就這樣夾在中間變成烏龜王八蛋的背叛者暨馬桶獨裁PM。當初建立的信任灰飛煙滅。
後來我花了很多時間跟姊姊們道歉；甚至動用專案團隊成員的力量幫我求情，說不管我是不是渣男，大家還是要一起把專案完成。也跟自己的顧問公司溝通，用顧問公司的錢在外面租了一共用辦公室，建立線上線上專案執行規範之後。姊姊們後來也終於決定原諒我。
我執行了我們顧問公司有史以來第一次的ERP線上整合測試。並且大獲成功。結案後來，COVID禁令也放寬很多。顧問在上線的時候已經都能進工廠協助Stakeholder們進行新系統的操作。在ERP系統上線後的一個月，姊姊們幫我安排了一場盛大的結案會議。一百多個人的會議室裡，所有和專案有的Stakeholders都參加這場盛會。我站在台上訴說著這近一年來大家的辛苦。我也從大家的眼神看到我過去所有努力的回報。
結語
什麼是顧問? 對我來說，當別人在某個領域的專業能力和知識受限的時候，拿自己的專業去幫別人截長補短並一起解決問題，這就是顧問。
顧問的生存哲學就是展現人溺己溺人饑己饑的基本人性發揮。靠著專業知識和發揮基本人性來產生利潤。是一個令人快樂的職業。專案契約，則是讓客戶和顧問公司甲乙能合作的扭帶；而不是雙方推卸責任的界線。專案契約，是為了建立雙方的合作默契的概括性文件；而不是建立敵對關係的訴狀。
誠然，台灣確實有不少企業為了自身利益拼命壓榨自己以外的其他合作公司。我本人也確實親身體會那種翻臉比翻書還快，不顧情面的老闆。但是即使遇到這種客戶也要不改初衷才是顧問公司應該要有的精神。
什麼是顧問? 對我來說，當別人在某個領域的專業能力和知識受限的時候，拿自己的專業去幫別人截長補短的，這就是顧問。顧問的生存哲學就是展現人溺己溺人饑己饑的基本人性發揮。靠著專業知識和發揮基本人性來產生利潤。是一個令人快樂的職業。
在我顧問公司PM最後工作的印象，都是做救援投手。在棒球比賽中的救援投手，都是先發投手或是主力投手已經沒辦法繼續投球的時候。不管現況是贏是輸，都要想辦法在後面的比賽中不要失分，贏得比賽。而在ERP顧問這個行業，前一個PM沒辦法繼續現在的專案而要救援投手上陣的理由很多。眾多的理由裡面，因為自己心力交瘁而不想做這個案子的不會理由。因為每一個ERP專案都是PM的重要履歷，除非這個PM不想在這個圈子混了，不然再苦也會想辦法把專案做完。遇到比較多需要我這種救援投手的案例一般都是和客戶無法繼續合作下去，我們一般都說被退貨。
不管多有經驗的PM，都可能因為能力；和客戶磁場不合；專案無法交付等原因被客戶要求換PM。也有一些case是對於一些簽約時談到的模糊的需求有爭議時，因為PM要替公司爭取權益而被迫和客戶發生衝突，我們業界叫這種是犧牲打。
我這次救援的案子比較特別，是因為多次系統上線測試都不順利而沒辦法上線。公司已經換了三個救援投手都陣亡。我已經是第五隻砲灰。由於這個客戶是業界的標竿。第一次去客戶那裡的時候，還是公司總經理帶我過去見客戶的。我到客戶公司的時候正值最熱的八月底，系統上不了線，甲方(就是客戶方)和乙方(就是我們顧問公司)為了釐清(推卸)責任已經吵架吵了兩年多了(專案執行一般是十個月)。接待人員把我和總經理進到會議室時，我覺得一個裡面坐了二十幾個中高階主管的會議室的溫度彷彿比外面低了十度。每個高階主管臉上寫的都是無奈。”老娘我事情這麼多，顧問公司又派一個來送死的PM為什麼還要我出席”。我嘗試很熱情的做完自我介紹以後問大家有沒有問題。會場上的主管們連轉頭看其他人的動作都沒有，只是靜悄悄地看著我，那時我心裡只有一個念頭”我死定了”。
信心建立
客戶端PM
接了這個專案以後，我第一件事情就是尋求客戶端的PM的支持。客戶端的PM一般是一開始在他們公司推動這個專案的核心人物，因為專案是她說要做的，所以這專案的成敗也關係到他的烏紗帽。從某個角度來說，我和客戶端PM是生命共同體。在這次專案，客戶端PM是IT部門的第二把交椅，他負責調配資源和向上溝通。除了她以外還有一個副PM是負責判斷專案執行細節的， Scheduling整理；議題管理；各項報告本來就是我們顧問公司PM要做的事情，但是這個副PM姐姐因為對工廠系統很熟悉，所以要判斷很多技術上的細節。
因為這專案拖太久，所以兩位姐姐很有結構的跟我解釋了這個專案到目前的瓶頸。主要問題在於資料品質和客製程式開發的問題無解。這裡科普一下，其實任何系統都是資料和邏輯的互動，如果一套系統資料或是資料的運作邏輯沒辦法搞定就不能執行。而我這專案很榮幸的同時有這兩個問題。身為有經驗的PM，在我跟姊姊們熟了以後，也開始問每一個專案關係人(stakeholders)對於這專案的態度和個性。聽起來像是聊八卦，但是要了解專案的每一個關係人是PM最重要的工作(沒有之一)。當然，姐姐們也會很主動的跟我抱怨我之前所有PM的不是。這專案甲乙方已經對立成這個樣子並非一日之寒，台灣的產業都是OEM起家的，大家都是對產品品質負責，不會像日本企業一樣重視客戶的聲音。而台灣的顧問公司的人都是美國體系訓練出來的，配教育要重視合約精神，但是台灣顧問公司自己又不把合約寫清楚。所以誤會越來越大。我很認真的聽兩位姐姐抱怨，取得他們的信任，是我避免成為砲灰的最重要一步。
顧問團隊
我在取得姊姊們信任之後。第二件事情就是要取得自己團隊的信任。自己的團隊和客戶同等重要。這麼大的一套ERP，不管是工作量和專業技術，都不是我一個PM可以處理的。如果團隊願意合作，我就只要做專案管理的工作就好。如果團隊不願意合作或甚至內部有矛盾，我就得自己跳下去處理技術問題。更恐怖的，是如果有一些資深的顧問對PM不服，就會像病毒一樣把負面的情緒和對於PM的不信任擴散到團隊其他成員以及甚至客戶那裏(擴散到客戶那裏就是職業道德問題)。
在顧問公司，顧問團隊都是臨時組隊的。有點像是航空公司的飛行員。只要任務一結束，大家都分別被派到其他的專案。所以也理所當然的PM對於這些顧問的考績是沒辦法評價的。我的Case的好處是這個團隊非常團結且專業，壞處是他們對前一個PM很信任。所以對於新來的我的能力有嚴重懷疑。依照某些教科書的教法，是要把PM批評一頓，建立自己的權威。我的方法則不是，我的方法則是蕭規曹隨，既然之前配合得很好就繼續依照原來溝通方法做。
ERP這種案子，一般會有FI, CO, MM, PP, SD這五大模組，原則上都會有五個主顧問帶著副顧問執行他們模組的工作。五個主顧問原則上會依照在業界的經驗年數論資排輩。如果最大的兩個顧問年資都很高的話，CO模組的顧問講話會比較有份量，因為ERP系統最重要的目的是要計算成本。
我這個案子的兩大支柱是FI模組以及MM模組。所以我就以這兩位的意見為團隊的主要意見。技術團隊對於”服不服從PM”的態度都是以PM對ERP的熟悉程度為主。我是碼農(就是像農夫一樣的底層工程師)出身，我對ERP的設定很弱，所以在團隊裡我把自己扮演成一個對客戶溝通的橋樑。至於技術面的專業判斷，除非嚴重跳脫我的邏輯與常識，不然我都尊重顧問們的決定。也就是民主化專案管理。
Stakeholders (專案利害關係人)
建立完自己內部團隊的共識以後，又要回來重建客戶團隊的信心。客戶的ERP團隊一樣依照模組分成五個，我就請PM姊姊幫我借了第一天差點被凍死的大會議室。讓這些User們把問題列出來，我做完紀錄以後一一詢問細節。一般來說，user對於重複性的問題會覺得很煩。”每陣亡一個PM就要問我一次，你為什麼不去問那些陣亡將士”。但是我的問法會帶著我的愛。我不只是問他們目前作業方式怎麼做；為什麼這樣做。我還會問問題問到心坎裡”你每天單這麼多，要弄到幾點才下班?” “所以你到月底要結帳的時候，小孩幼稚園怎麼辦” “系統導入之前你一定要撐住，這公司不能沒有你”。就是這些看似聊天的對話中，我就可以慢慢套出專案無法執行的很多政治面或是溝通上的原因。有很多資深的PM或是顧問因為對於技術太熟悉了，所以問問題的時候都沒有溫度，這樣只能處理表面的問題而不知道實際原因。這些看似無關緊要的關心和閒聊，不但讓我知道很多系統開發窒礙難行的的問題的背後原因；也讓我取得這些user的信任。不只是在會議中和團隊建立信任感。
我幾乎每兩週都會寫信給所有團隊成員，快要六十人。目的是要像是做廣告一樣持續刺激這些成員對於專案的重視。讓他們每週一一打開信就看到這個專案。
當然，這方法不是對每一個人都有效。例如這個客戶的業務副總就不好搞。這副總除了對專案團隊不滿以外；和工廠也有心結。我特別抽了一天時間到業務辦公室去跟他開會。我在我的報告中尋找任何和這副總可以共鳴的話題。我試著用國際化；資訊化；客戶關係等話題都看不到她有共情的眼神。直到我快要放棄，說到客製化議題的時候，我不經意地說”我從來不相信同一套ERP可以套用在任何公司，如果每個公司都用ERP都能執行他們的業務，那每個公司都跟我XXX公司一樣，這樣我們XXX公司還有什麼競爭力”。這時我注意到她不但眼神融化了，而且開始把所有的想法傾囊而出。那時我暗自想，我很有可能不是第五個砲灰了。
專案反抗份子
最後一個要解決的是IT團隊中的反抗份子。固然User中也有很多人牴觸新的ERP，但是IT自己牴觸會是最棘手的。IT之所以會牴觸是因為他們依賴著原來的ERP可以在公司作威作福，一但換了新的ERP他們就要跟菜鳥一樣從頭開始學習(這觀念其實不對，ERP重要的是流程而非程式)。有了姐姐的支持，我就開始要求IT單位在做資料轉檔以後要寫資料檢查程式，這樣才能再把資料匯入ERP之前確保資料夠乾淨(專有名詞叫data cleansing) 。反對派首領當場告訴我說這種程式很難寫，他沒空陪我弄這個(合約上是沒說要做這個)。我不等姊姊幫我罵人，我當場拿了他們的data在會議室花十分鐘把sample程式的主架構寫出來，質問反對派首領說，剩下的程式連大學剛畢業的都會寫，你要我陪大家繼續寫下去嗎? 反對派首領當場不敢講話，事後姐姐也誇獎我，說，這種做黑手的人就是要比他還黑才制得住。
解決問題
我永遠相信，專案成功最重要的關鍵在人心。但是並不是建立了信任關係專案就成功了。前幾代PM留下來的問題不會因為有決心就奇蹟般的自然消失，還是要付出實際行動。
文件品質
前代PM們留給我的第一個問題是專案文件品質的問題。ERP的顧問的時薪很高，所以客戶對顧問公司交付文件的要求也會很高。和一般的文件不同。ERP的規格與教育訓練文件會隨著這套系統使用十年二十年，即使是未來剛入職的員工也會用到這份文件。所以如果文件有令人誤會或是甚至錯誤的地方，這些錯誤就會跟著系統遺臭二十年。
顧問們都長這麼大了，雖然寫錯字在所難免，但是被人家指出錯字這種低級錯誤，誰都會面子掛不住。”客戶是故意找我碴嗎?幾千個字的文件要我自己確認錯字!”。
PM有很多種，有些強勢專制的PM會跟顧問說”寫錯字就是寫錯字，我不管你的文件有幾千字，把字寫對就是你的責任。你知道你自己的價值嗎?”。但是我的”民主PM”風格在接這個案子的時候就已經定性了。我不能跟顧問來硬的。我唯一辦法就是另外找一個人幫我檢查時幾個顧問共同寫的幾萬字文件的錯誤。但是公司怎麼可能派這種小秘書給我?
小秘書沒有，虛擬秘書卻不是不可能。我觀察到顧問群會犯的文件錯誤有兩種。一種是中文錯字，尤其是電腦拼音輸入法的Bug造成的；另一種是對於同一個系統專有名詞，因為一開始都是英文，所以每個人對同一個字的翻譯會有差異。
我建立一套”錯字與同義字字典”，和顧問們一起定義好所謂的錯字和英文翻譯過來的字之後。就讓電腦程式去看著字典掃描那幾萬字的文件，讓電腦告訴我哪個文件的哪裡有哪些問題字詞就好。就這樣，本來是甲乙方的文件交品質的政治問題，就讓我用資訊科技的技術問題給解了。
資料品質
如果說文件品質問題是阻礙專案進行的小坑，那麼後面資料和客製程式兩個問題則是阻礙專案進行的大山。
資料是專案成敗的核心之一，而資料的責任在合約上明顯寫著資料是客戶的責任。所以只要碰到和資料有關係的事情。顧問公司就會把防火牆設定好。顧問公司對待客戶的資料就像對待輻射物質一樣，客戶把資料放到顧問公司的指定位置，然後顧問公司小心翼翼地把資料送進系統，結果是陽性就跟你說你失敗；陰性就恭喜你。絕對不會關心客戶是怎麼做；什麼方法；什麼心情把那個資料做出來。顧問公司都假設客戶在正常的狀況下提供合約上期望看到的完美資料。如果不完美，也是客戶自己要負責。這就是顧問公司所謂的"合約精神"。
其實Data cleansing的觀念和技術早在三十年前就已經有了，也是大學資訊專業的必修課。如果客戶不理解這套技術，就花點時間教他們這概念就好。顧問公司也沒有必要真的下手幫他們寫程式。但是顧問公司為了確保這個"資料的責任屬於客戶"這合約條款的防火牆沒有漏洞，所以連這種簡單的知識都不願意說。
我其實不是為了避免成為下一個砲灰而教客戶這觀念，只為了那個合約的防火牆限制而不能分享我的知識我會很難受。我真心地認為如果我能分享的知識可以解決眼前的問題，就可以和客戶一起讓專案成功。所以我不但教他們怎麼寫。也親自下手做一些資料檢查程式的示範。就這樣，因為資料品質的大幅改善，資料轉檔時間從過去的超過一個月簡化到只需要一天半。解了我第一個大問題。
客製化程式
再來就是客製化程式。主要是因為這案子的客製程式太多了，完全沒有預算可以完成專案所需要的客製化程式。一般ERP的套裝程式，主要都希望客戶儘量用ERP的原有功能，不要因為過去的習慣而修改ERP的功能。但是像給客戶的訂單格式，或是會計公司要求的報表，或是自動拋帳這類的，很難因為系統更換而更換。
ERP專案很難在專案開始以前就知道客戶需要什麼客製化程式，是必須要在充分理解客戶的需求之後才有辦法提供客戶客製化的價格。為了讓客戶放心未來顧問公司不會在專案開始之後對客製化程式獅子大開口，顧問公司的業務也會提供軟體開發工程師的每小時報價(這報價和業界其他程式差不多)。然而，在專案的藍圖階段結束，我們顧問公司提供的客製化程式報價還是遠高於客戶的預期。原因之一是: "所謂報價是單價乘以時數，我在時數上灌水就好啦"。
客製化程式也是顧問公司的重要收入之一，我們顧問公司的這套ERP使用的電腦語言和外界不同，所以花的程式開發時間沒辦法和外界大家使用的電腦語言(python, Java這類的)相提並論。台灣島這麼小，能寫這種特殊電腦語言的公司也只有其他同類型顧問公司。而其他同類型顧問公司都不願意接競爭對手的客製程式開發的專案。換句話說，從這個專案和我家顧問公司簽約那一刻起，客製程式要多少錢就是我家顧問公司說了算。這就是現實。
而兩個PM姊姊就是吞不下這個現實，硬要用外界系統開發公司的價格和ERP的開發成本比。就這樣，這個矛盾對峙了一年多。最後前代PM就體貼的把這個企業合作的結構性問題放在我的手上。和資料的技術問題不同。這是甲乙方的認知差異問題。打破這個僵局，我要有一個第三方公正人，讓甲方知道這ERP的程式的開發成本就是比其他程式高。我也要讓乙方(我自己的公司)知道，客戶有能力選擇其他方法解決問題。
解決方法是業界的另一個特殊領域，叫做freelancer。中文翻譯成"自由職業者"。這些人不隸屬於任何顧問公司。他們透過人脈自己去找寫程式的case來賺錢，一般來說，他們接的案子比較是顧問公司把系統導入之後幾年，客戶要增加功能的時候幫忙寫(他們也不想得罪顧問公司)。但是在這個案子上，他們可以當我的第三方公正人。
當然，顧問公司不可能允許任何顧問(尤其是PM)去自己找freelancer。從某個角度看，PM不讓自己公司賺錢就是吃裡扒外，要是Freelancer價格真的比較低，這部分利潤丟了怎麼辦。但是PM的天職就是要讓專案成功，如果我再陣亡，公司也收不到原本專案的錢。所以，我就找了台灣和大陸認識的freelancers，打好招呼以後，在某個場合中"不小心"把這些freelancers的聯絡方式掉在桌上，被姊姊們"撿走"。姊姊就會積極地和這些人聯絡。最後，果然證明我們顧問公司的價格還是太高了。雖然我不樂見公司以外的第三方團體合作專案(設計和開發永遠都有很多衝突)。但是為了專案。這是必要的犧牲。
信心的建立不是只有靠三寸不爛之舌到處哈拉就能建立的。當PM就是要表現解決問題的能力和態度才能建立客戶對PM的信心。這兩座大山被我剷除了之後。兩位姐姐看到前面廣闊的平原，也對我越來越好了。有一次甚至在我印文件的時候，身為IT處長的PM姊姊還把我工作搶去做，要我去忙其他的。
幫更多的忙
顧問公司很忌諱任何顧問回答專案以外的知識。檯面上的理由是無法承擔顧問提供錯誤答案而對客戶造成的損失；其實應該又回到契約精神，寫在契約以外的服務都要付費。我都是再三跟姊姊們宣稱我的協助是個人行為，和公司無關以後，在時間允許的前提下，我會像是OPEN AI一樣協助回答了很多問題 如何建立產銷會議；如何規劃IT團隊；如何用AI做生產排程；幫忙設計一個IT職位的考試題目等等，只要是我知道的答案我都會分享我的看法和經驗。
危機管理
專案不會永遠一帆風順，移開了大山就和公主過著幸福快樂的生活，而這次我遇到的是百年一遇的COVID 19危機。那時候所有公司老闆談COVID 19都色變。恨不得把所有員工都關在無塵室裡，每個人用保鮮膜包起來，最好是都不要呼吸。對於公司來說，最大病毒的未知進入渠道就是員工的家庭和外部廠商。我們顧問公司也是外部廠商。姊姊們拿出專案合約裡寫的”遇外部不可抗力因素XXXX，可以在雙方同意下終止合約”要我暫停這專案。但是我們顧問公司的成本就是時間，所以直接拒絕。客戶公司的原則就是”廠商不准進場”，所以這問題變成無解。
後來姊姊們幫我想到一個解法。他們花了幾十萬把一個大貨櫃屋搬到他們工廠外面，把網路水電都接到貨櫃裡。並且在貨櫃裡面裝了冷氣和飲水。為了確保這種貨櫃可以工作，我先讓顧問在家上班幾天，自己在貨櫃屋裡工作了一週；把貨櫃屋工作的照片寄給顧問們看，讓他們放心以後才讓他們進駐貨櫃屋。
然而，進駐的第一天顧問們就罷工了。關鍵在廁所。因為甲方的規則就是不能進公司，所以當然不能用工廠內的廁所。姊姊們幫我在貨櫃屋外面做了一間移動式廁所。但是移動式廁所式手動沖水的。不像工廠的那種馬桶(其實在顧問進駐以前我也解釋過)。顧問們覺得自己的工作權利受到汙辱，所以一狀告回公司。公司在沒有跟我求證與溝通的情況下直接叫顧問撤回。剛好那天我跟PM姊姊剛簽完階段付款單。所以從姊姊的角度來看，就是我一拿到了錢就把顧問撤回去。這就是背叛。我也不可能跟姊姊們說我也是被背叛的受害者，畢竟我就是PM，什麼決定理當是我下的。女生最討厭背叛的男人。我就這樣夾在中間變成烏龜王八蛋的背叛者暨馬桶獨裁PM。當初建立的信任灰飛煙滅。
後來我花了很多時間跟姊姊們道歉；甚至動用專案團隊成員的力量幫我求情，說不管我是不是渣男，大家還是要一起把專案完成。也跟自己的顧問公司溝通，用顧問公司的錢在外面租了一共用辦公室，建立線上線上專案執行規範之後。姊姊們後來也終於決定原諒我。
我執行了我們顧問公司有史以來第一次的ERP線上整合測試。並且大獲成功。結案後來，COVID禁令也放寬很多。顧問在上線的時候已經都能進工廠協助Stakeholder們進行新系統的操作。在ERP系統上線後的一個月，姊姊們幫我安排了一場盛大的結案會議。一百多個人的會議室裡，所有和專案有的Stakeholders都參加這場盛會。我站在台上訴說著這近一年來大家的辛苦。我也從大家的眼神看到我過去所有努力的回報。
結語
什麼是顧問? 對我來說，當別人在某個領域的專業能力和知識受限的時候，拿自己的專業去幫別人截長補短並一起解決問題，這就是顧問。
顧問的生存哲學就是展現人溺己溺人饑己饑的基本人性發揮。靠著專業知識和發揮基本人性來產生利潤。是一個令人快樂的職業。專案契約，則是讓客戶和顧問公司甲乙能合作的扭帶；而不是雙方推卸責任的界線。專案契約，是為了建立雙方的合作默契的概括性文件；而不是建立敵對關係的訴狀。
誠然，台灣確實有不少企業為了自身利益拼命壓榨自己以外的其他合作公司。我本人也確實親身體會那種翻臉比翻書還快，不顧情面的老闆。但是即使遇到這種客戶也要不改初衷才是顧問公司應該要有的精神。
什麼是顧問? 對我來說，當別人在某個領域的專業能力和知識受限的時候，拿自己的專業去幫別人截長補短的，這就是顧問。顧問的生存哲學就是展現人溺己溺人饑己饑的基本人性發揮。靠著專業知識和發揮基本人性來產生利潤。是一個令人快樂的職業。
2會員
9內容數
留言0
查看全部
你可能也想看
Google News 追蹤
這個秋，Chill 嗨嗨！穿搭美美去賞楓，裝備款款去露營⋯⋯你的秋天怎麼過？秋日 To Do List 等你分享！
秋季全站徵文，我們準備了五個創作主題，參賽還有機會獲得「火烤兩用鍋」，一起來看看如何參加吧～
美國總統大選只剩下三天， 我們觀察一整週民調與金融市場的變化（包含賭局）， 到本週五下午3:00前為止， 誰是美國總統幾乎大概可以猜到60-70%的機率， 本篇文章就是以大選結局為主軸來討論近期甚至到未來四年美股可能的改變
Faker昨天真的太扯了，中國主播王多多點評的話更是精妙，分享給各位
王多多的點評
「Faker是我們的處境，他是LPL永遠繞不開的一個人和話題，所以我們特別渴望在決賽跟他相遇，去直面我們的處境。
我們曾經稱他為最高的山，最長的河，以為山海就是盡頭，可是Faker用他28歲的年齡...
專案管理師是專案團隊中的靈魂人物，負責規劃、執行和控制專案，以達成專案目標。一名優秀的專案管理師需要具備多項硬實力，才能帶領團隊克服挑戰，完成專案。那麼，專案管理師究竟需要哪些硬實力呢？一起來認識五項專案管理師必備的硬實力，並分享如何培養這些硬實力
專案管理師需要與不同的
本文介紹了基礎建設碳管理專案管理的重點和行動建議，包括計畫慢行動快、模塊化設計、主動規劃與早期協作、持續改進與迭代、風險管理與數據驅動決策等。並提出了制定全生命週期的碳管理策略、強化供應鏈管理、投資於新技術、教育和培訓等建議。
王吉達吉言吉語：
隨著在組織裡工作的時間越長，參與跨部門協作的機會就越高，甚至有機會被要求籌組一個跨部門的小組。
在《橫向管理高爾夫》（製造業版本）的步驟 1.1就有這麼一個狀況：
你是某部門經理，上司李大為總經理指派你負責籌組一個跨部門的專案小組，
透過 Google Sheets 和 Make 打造專案任務自動提醒系統，當一到專案任務重要時程，系統便自動寄發專案任務的提醒信件或行事曆邀請，給專案任務負責人和相關團隊成員，確保專案進度如期完成，有效提升跨部門溝通協作效率！不再花費時間人工追蹤時程進度，釋放時間及專注力，專注在更重要的工作上！
在面試中專案經理需要注意面試官可能問的問題和套路，以及如何準備自我介紹，情境考題是面試官常問的問題，透過回答這些問題，面試者同時也可以了解公司面臨的挑戰，並評估是否適合進入這家公司。
講到專案管理，你會想到什麼 甘特圖、專案組織圖、專案計畫？ 這些都只是專案管理的工具
回歸到專案管理的目的
就是要讓專案如期完成
以前的我不斷追求工具的效率化
希望用看板管理、快速畫出甘特圖的工具
因為這些是專案管理者，也就是PM能獨自完成的事
但，專案絕對不止是PM的事
與其埋頭苦幹這些
經過查找，我發現要在 Google 試算表上實現甘特圖會很複雜，也要花很多時間研究，困難難度實在不亞於使用 Excel 來建置甘特圖。
誤打誤撞下，我發現了一個開放資源，可以透過簡單的 Markdown 語法來建置甘特圖，或是其他流程圖的套件：Mermaid.js。
本文從專案管理的角度，剖析如何有組織性的將『新事業規畫』專案順利完成。是一篇專案管理實戰案例好文。
流程亮點: 專案管理五大步驟
1. 子彈筆記、日誌、每日待辦清單checklist
把當天要做的進度列出來，如果有事情延後就挪到隔天繼續紀錄(用雲端文件打字複製項目很快，要搜尋以前的紀錄也很方便)。自己使用覺得的缺點是可能比較沒有大局觀(沒有設一個確切的完成時間，只能用體感估計)。優點就是能夠集中於當天要做的事，如果是主管處理事
俗話說好的開始是成功的一半。專案一開始也需要有個好的開頭，後續專案做起來才容易上軌道，而這個開頭就叫做啟動會議或是Kickoff meeting。
這個秋，Chill 嗨嗨！穿搭美美去賞楓，裝備款款去露營⋯⋯你的秋天怎麼過？秋日 To Do List 等你分享！
秋季全站徵文，我們準備了五個創作主題，參賽還有機會獲得「火烤兩用鍋」，一起來看看如何參加吧～
美國總統大選只剩下三天， 我們觀察一整週民調與金融市場的變化（包含賭局）， 到本週五下午3:00前為止， 誰是美國總統幾乎大概可以猜到60-70%的機率， 本篇文章就是以大選結局為主軸來討論近期甚至到未來四年美股可能的改變
Faker昨天真的太扯了，中國主播王多多點評的話更是精妙，分享給各位
王多多的點評
「Faker是我們的處境，他是LPL永遠繞不開的一個人和話題，所以我們特別渴望在決賽跟他相遇，去直面我們的處境。
我們曾經稱他為最高的山，最長的河，以為山海就是盡頭，可是Faker用他28歲的年齡...
專案管理師是專案團隊中的靈魂人物，負責規劃、執行和控制專案，以達成專案目標。一名優秀的專案管理師需要具備多項硬實力，才能帶領團隊克服挑戰，完成專案。那麼，專案管理師究竟需要哪些硬實力呢？一起來認識五項專案管理師必備的硬實力，並分享如何培養這些硬實力
專案管理師需要與不同的
本文介紹了基礎建設碳管理專案管理的重點和行動建議，包括計畫慢行動快、模塊化設計、主動規劃與早期協作、持續改進與迭代、風險管理與數據驅動決策等。並提出了制定全生命週期的碳管理策略、強化供應鏈管理、投資於新技術、教育和培訓等建議。
王吉達吉言吉語：
隨著在組織裡工作的時間越長，參與跨部門協作的機會就越高，甚至有機會被要求籌組一個跨部門的小組。
在《橫向管理高爾夫》（製造業版本）的步驟 1.1就有這麼一個狀況：
你是某部門經理，上司李大為總經理指派你負責籌組一個跨部門的專案小組，
透過 Google Sheets 和 Make 打造專案任務自動提醒系統，當一到專案任務重要時程，系統便自動寄發專案任務的提醒信件或行事曆邀請，給專案任務負責人和相關團隊成員，確保專案進度如期完成，有效提升跨部門溝通協作效率！不再花費時間人工追蹤時程進度，釋放時間及專注力，專注在更重要的工作上！
在面試中專案經理需要注意面試官可能問的問題和套路，以及如何準備自我介紹，情境考題是面試官常問的問題，透過回答這些問題，面試者同時也可以了解公司面臨的挑戰，並評估是否適合進入這家公司。
講到專案管理，你會想到什麼 甘特圖、專案組織圖、專案計畫？ 這些都只是專案管理的工具
回歸到專案管理的目的
就是要讓專案如期完成
以前的我不斷追求工具的效率化
希望用看板管理、快速畫出甘特圖的工具
因為這些是專案管理者，也就是PM能獨自完成的事
但，專案絕對不止是PM的事
與其埋頭苦幹這些
經過查找，我發現要在 Google 試算表上實現甘特圖會很複雜，也要花很多時間研究，困難難度實在不亞於使用 Excel 來建置甘特圖。
誤打誤撞下，我發現了一個開放資源，可以透過簡單的 Markdown 語法來建置甘特圖，或是其他流程圖的套件：Mermaid.js。
本文從專案管理的角度，剖析如何有組織性的將『新事業規畫』專案順利完成。是一篇專案管理實戰案例好文。
流程亮點: 專案管理五大步驟
1. 子彈筆記、日誌、每日待辦清單checklist
把當天要做的進度列出來，如果有事情延後就挪到隔天繼續紀錄(用雲端文件打字複製項目很快，要搜尋以前的紀錄也很方便)。自己使用覺得的缺點是可能比較沒有大局觀(沒有設一個確切的完成時間，只能用體感估計)。優點就是能夠集中於當天要做的事，如果是主管處理事
俗話說好的開始是成功的一半。專案一開始也需要有個好的開頭，後續專案做起來才容易上軌道，而這個開頭就叫做啟動會議或是Kickoff meeting。