專案外包的衝突與兩難-引言

過去,Mr PM都是處在發包專案的角色,現在因為自行創業,必須將30%的力氣拿來接案來養公司,所以開始有了些接案的經驗。而同時扮演過發專案和接專案的筆者,或許有些經驗可以來分享給大家。

我們這邊來看看,最理想的軟體接案流程是什麼?

  1. 客戶很清楚Spec或User Scenario,詳細的告訴接案公司,雙方就依此簽約
  2. 接案公司設定了Schedule與Milestone,每個Milestone要交付的事項也被清楚且具體的定義
  3. 完美且準時達成了Milestone交付的事項,沒有拖延或爭執
  4. 客戶完成專案,而接案的公司也撐到專案保固結束,尾款也順利領到,皆大歡喜

事實上,大家都知道,這種類型的專案是存在的,但是這種專案一定都是非常簡單的專案,利潤不高,而且競爭者多。而大部分的接案情況並不是這樣進行的。比較接近真實的狀況如下所示(有些也是筆者在當客戶端時發生的狀況喔)。

  • 客戶其實只有方向而不清楚細節,只能說出個不清不楚的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,大概找個機器人就可以勝任了。事實上,資料表、查核清單…等,確實是很好用的專案管理工具,但是過於在乎這些工具,反而會忘記其實接案的時候,其專案管理的重點應該在於「人」與「管理預期」而就「人」與「管理預期」這兩個課題來說,最重視的反而是是「領導能力」與「溝通手法」。

留言