過去，Mr PM都是處在發包專案的角色，現在因為自行創業，必須將30%的力氣拿來接案來養公司，所以開始有了些接案的經驗。而同時扮演過發專案和接專案的筆者，或許有些經驗可以來分享給大家。
我們這邊來看看，最理想的軟體接案流程是什麼？
- 客戶很清楚Spec或User Scenario，詳細的告訴接案公司，雙方就依此簽約
- 接案公司設定了Schedule與Milestone，每個Milestone要交付的事項也被清楚且具體的定義
- 完美且準時達成了Milestone交付的事項，沒有拖延或爭執
- 客戶完成專案，而接案的公司也撐到專案保固結束，尾款也順利領到，皆大歡喜
事實上，大家都知道，這種類型的專案是存在的，但是這種專案一定都是非常簡單的專案，利潤不高，而且競爭者多。而大部分的接案情況並不是這樣進行的。比較接近真實的狀況如下所示（有些也是筆者在當客戶端時發生的狀況喔）。
- 客戶其實只有方向而不清楚細節，只能說出個不清不楚的Spec或User Scenario。
- 在客戶端，通常議價和專案負責人都處在不同部門。客戶端的專案負責人，為了能給趕快給老闆交代，都會先要求接案單位，在簽約議價完成之前，就會要求先開始動工，甚至在Spec與詳細的User Scenario出來之前，就要能給個大概的Milestone，好讓客戶端的專案負責人，能對上頭有個交代。
- 一扯到白紙黑字的合約，Scope就很難定案，客戶的需求改來改去，永遠都有新需求，導致合約遲遲無法簽訂。不然就是客戶針對合約裡的Scope，開始採取部分模糊詞彙的動作，來保持未來的彈性，但是也導致了往後的爭端。
- 專案進行到後來，大家對Scope文件上的爭議會越來越多，接案單位會認為這是新需求，但是客戶端會認為那是你們在硬凹，當初開會本來就有說的。然後雙方就開始了調閱會議紀錄比賽，不然就是記憶力大賽。
- 由於大家都不想背責任做決定，但是接案單位又正在等著客戶決定以繼續進行下去，所以客戶就變得常常會說「我問問我老闆」或「能不能保留彈性，讓我可以做到A也可以做到B」。一個決策的溝通路徑如此之長，花時間在來來回回上，就不知道蹉跎了多少RD寶貴的青春。
- 越複雜的專案，其專案進行時間幾乎無法估計準確，而Milestone無法達成更是家常便飯。但是一旦Milestone無法準時完成，客戶滿意度就開始降低，跟著就是永無止境的catch up plan與catch up meeting。
- delay是個專案的殺手，其實大家都是一直以來都是和平相處，直到delay的發生，就會開始互相推諉過錯。delay一旦發生之後，就幾乎不可能有哪個談判高手能談出個雙贏方案，最後通常都會是客戶端贏，接案公司只有滿頭包的份。而接案單位的PM，就得一天得面對小老闆、大老闆分批且多次對於進度的質詢，PM與RD也會被要求每天或甚至每小時進行Status report。
- 在delay之後，接案單位雖會提出的catch up plan與新版的milestone。但是還是會面臨到再次delay的問題。而當接案單位delay的越多次，就會產生越多的怪現象，諸如：「丟出一堆bug的程式給客戶，先將milestone交差，讓進度推進到issue tracking再來慢慢改」。
- delay的專案，接案單位只能不斷的加班趕工，趕工趕到士氣低落，趕工趕到沒有商譽（因為客戶老是會提醒你，沒有趕上進度，就是沒有遵守承諾），趕工趕到員工都想離職，趕工趕到不知道人生的意義在哪？
- 還有很多，歡迎補充…
身為一個接案單位的人，面對真實世界的狀況，若是以為透過教科書中教的流程管理手法，包括詳細的資料表、查核清單…等，就可以保證專案成功，那這樣接案單位的PM，大概找個機器人就可以勝任了。事實上，資料表、查核清單…等，確實是很好用的專案管理工具，但是過於在乎這些工具，反而會忘記其實接案的時候，其專案管理的重點應該在於「人」與「管理預期」。而就「人」與「管理預期」這兩個課題來說，最重視的反而是是「領導能力」與「溝通手法」。
--不想錯過我的新文章：訂閱免費電子報
我的線上課：數據化營運、產品增長 和 產品企劃力，歡迎大家報名
