DMA01
預算面看,如何與外包工程師合作?

預算面看,如何與外包工程師合作?

外包工程師的大火快炒與自家工程師的細火慢燉,今晚你選哪一道!

寓意科技

身為專案經理,在每次開始專案前最重要的三件事,不外乎就是專案範疇 (Scope)、成本 (Cost)、時間 (Time) 三要素了,假設專案範疇與時程皆為固定的前提條件下,今天就來跟大家聊聊在成本面中,通常會吃掉大部份預算的工程人力成本吧!

 

"站在公司運營的立場,公司在考慮工程人力成本,是否選擇運用外包工程師資源做開發,通常可從整個公司運營的彈性,及本身可以掌握的風險能力,為主要考量因素。"

1.公司運營的彈性
請外包工程師通常就是希望可以免除人力資源在閒置期的多餘支出,在需求高峰期時短時間內全力衝刺開發公司產品 / 服務,例如:產品 MVP 、新市場試水溫、或是彌補專案臨時需求等階段,會是不錯的選擇。

2.風險程度也提高
但外包資源佔比增加,在專案控管上的風險程度也會增加,例如專案資安控管、品質無法確認、隱藏技術債、合作的不確定性等,都會讓專案失敗的可能性也大幅提高。

"那,寓意作為一個只養 PM ,不請固定工程師的商業模式都是怎麼做的呢?以 PM 的角度而言,今天就來跟大家分享下外包工程師與自家工程師合作的方式有什麼不同以及一些踩過的血淚史(備好面紙)"

如果你跟外包工程師合作..

1.合約簽訂清楚:合約的內容,要盡可能地把專案範圍、時程、合作、驗收及付款方式載明。

這是最重要可以保護雙方的方式,當然也是走到合作破裂時的最後一條底線。系統開發規格一定會被反覆修改,但是大方向不能變啊!驗收與付款方式會是合約階段相當重要的一環,是按月時間到付款、還是按功能完成驗收付款?驗收是有交出大功能就算過還是驗收期過了就算過?這些細節都是專案後期常吵架破裂的原因,最壞的狀況有可能會變成工程師中途落跑或是擺爛,PM 這時候絕對會欲哭無淚..

2.與工程師建立關係:除了合約本身的規範外,專案開始前好好認識一下你未來的合作夥伴

合約規範是死的,但專案成員合作氣氛才是會影響你整個專案的進行,還有你晚上睡不睡得著覺的關鍵啊(笑) ,在專案前期需要思考 PM 與工程師可以如何互相幫忙:例如 PM 可以協助工程端更快瞭解專案內容、在付款時程能不能有小小調整空間,前後端是不同團隊的話要如何建立起溝通機制。在專案前期若能建立起互信關係,會幫助之後專案在各種客戶需求臨時變動時,多增加一些討論空間。

3.需求及技術文件建立:專案進行中,記得將過程中的所有口頭說明、需求討論收斂後文件化
尤其是第一次合作的外包工程師,雖然他們大多擁有很強的技術開發能力,但是規格反覆、矛盾、不清楚也是巧婦難為無米之炊,文件化的好處在於雖然 PM 整理的時間會多很多,但雙方往後都能有個依據。
且外包工程師大多不會與 PM 在同一個環境下做事,平時溝通可能都是以遠端開會方式進行,在每次開會/確認時間之前的文件準備,除了方便做事之虞,也是保護好 PM 的方式。通常以往這樣的整理會讓工程師對 PM 的信任感大大加分,會認為一起做事的是夥伴而不只是甲乙方的關係。

4.終於到了專案的尾聲,究竟是期待下次見面還是老死不再見呢?
專案尾聲要結案通常也是大爆炸的階段,過往的分分合合浮上檯面到了一次算帳的時刻。尤其外包合約一定會壓專案起迄時間,為了避免專案無法收尾但工程師合約時間已到,造成專案爛尾的可能性,PM 在專案過程中需要非常注意工程師時間上的運用,大的 milestone 不能放掉,理想狀況是需要把你跟客戶的 deadline 往前切齊變成你跟工程師的 deadline,專期間內需要動態調整可能面臨的問題,不要害怕就把問題藏起來,肯定會爆炸。

如果你跟自家工程師合作:

1. 提高工程師的參與度:專案開始前除了建立互信關係外,可以多讓工程師參與核心討論提高價值

少掉合約比較硬性的約束,與原有同事合作應該已經有一定的信任與工作默契,對於 PM 來說應該會是壓力較小的合作方式。工程師身為公司的一份子,PM 在專案起始前,其實可以讓工程師更了解公司做這項產品/服務的緣由,提高工程師的專案參與度,也藉此發現專案不同的觀點,也能幫助在前期可以將團隊默契提升。

2. 建立良好的溝通及驗收方式:專案過程中仍需要建立驗收機制並且不間斷的溝通,確認雙方理解的需求一致
專案進入開發期後最擔心的就是一股腦悶著頭做,不問、不看、不確認常常會發現做下去後已經走得很偏,但是太晚發現來不及改的狀況。自家同事間的時程彈性可以拉高,若有多專案同時進行,必要時也能調動人手,但專案在走,明確的驗收機制還是要有。

3.專案即將告一段落,就意味著下一階段的開始

除非是死掉的專案,大部分的案子結束後一定會有可以優化/改善/改版的空間,這時候不是只有結案的考量,更要考慮技術債償還、更新使用技術、優化使用者體驗等規劃,這時若能從需求面及技術面多角度分析,有助於更快速的理解產品改進方向。工程師也能有機會跳脫純碼農階段,開始參與產品規劃過程,協助技術轉管理職的機會。

"不論外包工程師的還是自家工程師其實沒有好壞,只有在那個當下適不適合,但不變的是在專案中都需要不斷溝通找到適合的合作方式才是正確的資源配置。"

嘗試先了解每個工程師接專案的目的,是為了鑽研使用最新技術、為了一份養家糊口的工作、為了在公司裡有個發光發熱的舞台可以被看見,都會有不同的切入點。

如果看到這裡覺得要找工程師已經心累了的話,就來找寓意吧(笑)

寓意科技
寓意科技

寓意科技提供專業的及系統資訊科技管理顧問服務,協助企業規劃並完成軟體建置

fable寓意科技官方網站:https://www.fable.com.tw/

fable寓意科技 Medium:https://medium.com/@fableltd

Project delivery
Step 1:Go to market plan, Step 2:User onboarding flow, Step 3:Deployment plan
【產品規劃系列(二)】軟體 PM 撰寫規格書的三大工具之二,Functional Map
「Functional Map」的目的是將使用者需求變成功能規格圖表,主要用於和開發人員確認需求,通常會以心智圖呈現。俗話說:「看圖比看文字來的直覺」,Functinoal Map 提升了團隊之間對於 Spec 的溝通效率,是一個非常棒的工具。
釐清專案/產品利害關係人
本文將說明公部門常見的系統開發思維與在執行專案前,需要先釐清目的、使用者與利害關係人