《我的專案筆記 #34》身處軟體外包公司的PM，又該怎麼辦？- 數位產品功能這麼多，要怎樣安排時程？(補充) — HeroMi
入行軟體開發以來，大多數時間都是在開發公司或是上級長官設定的產品，直到最近這幾年才開始接觸到外包的專案。坦白說，這是蠻幸福的一件事，我是指開發公司要的產品，身邊很多朋友其實都是在外包公司打拼，總是會遇到不少事故，創造許多人生故事。如果身處軟體外包公司的話，該怎麼辦？
首先我們要先了解「產品服務的對象」是誰？如下圖。
什麼時候會是上圖的(A)？什麼時候又會是(B)？
如果我們所處的公司是專門在幫人架設官網，或是製作一些APP工具，有很高的機會會屬於上圖(A)。
如果我們所處的公司是和廣告公司、整合行銷公司合作，那很高的機會就是上圖(B)，由轉發包公司去接業務，再轉包出來，這在業界也是很常見的合作方式。想想看，如果我要辦一檔行銷活動，勢必需要活動頁、宣傳頁，甚至還要開發小遊戲，所以廣告公司會和許多間軟體開發公司合作，轉發包適合的團隊，畢竟每間軟體開發公司都有各自擅長的領域，有的擅長網頁、有的擅長APP。
這兩種直接的差異，在於「和誰確認需求」？
以上圖(A)為例子，開發團隊可以直接與發案方確認需求，這時候問題通常不會太大，畢竟可以直接溝通。
《延伸閱讀：搞懂客戶需求，以及需求背後的需求》
但是，如果是圖(B)問題就來了。
假設圖(B)的轉發包公司為廣告公司，那他們對於軟體開發的細節會清楚嗎？如果發案公司問了一些技術的問題，這些轉發包公司有辦法精準回答嗎？又如果轉發包公司為了可以搶下案子，而隨口答應發案方，事實上卻做不到，又該如何？
畢竟直接溝通都不一定順利了，中間隔著一個轉發的單位，溝通難度當然就會更高。
再來，要了解這次的軟體外包案，是OEM還是ODM。
OEM（英語：Original Equipment Manufacturer的縮寫）簡稱：委託製造 ，又譯原始設備製造商，指由採購方提供設備和技術，由製造方負責生產、提供人力和場地，採購方負責銷售的一種現代流行生產方式。
ODM（英語：Original Design Manufacturer的縮寫），即原廠委託設計代工，又譯原始設計製造商，又俗稱為貼牌生產，指由採購方委託製造方，由製造方從設計到生產一手包辦，而最終產品貼上採購方的商標且由採購方負責銷售的生產方式。
–《wiki 維基百科》
簡單來說，OEM就是發案方提供需求及規格文件，接案公司依據文件進行開發；ODM則是發案方僅提供需求，由接案方依據需求，進行設計與開發。
■ OEM 可能會遇到的狀況
發案方本身擁有技術團隊：這種狀況是最棒的，因為只要依據發案方提供的文件，配合開發即可，但是還是有些地方需要注意。
規格文件是不是發案公司自己可掌握的：千萬別以為發案方有提供規格文件，就覺得開心，這反而是要小心的開始，過去曾經遇過一件案例，就是發案方不知道從哪邊買來的規格文件，就要求團隊照著文件開發。以發案方的角度來說，我文件都提供了，怎麼會沒辦法開發，這種時候的狀況就是，這份文件的內容須要有專人去研究、消化、理解，這是需要時間的，而且文字上的理解，是很容易有誤會的。業主負責專案的窗口，對於這份文件的了解也不深的話，那要多多小心。
應對策略：提出需要時間研究與了解文件，避免一知半解的狀況下開發。
發案方的窗口，其實不懂技術：這個狀況要特別特別小心，因為對方的窗口很高的機率其實不知道自己在寫什麼文件，於是，常常遇到的狀況就是雙方花很多時間確認需求，然後技術開發完功能後，對方卻不買單，最後對方的老闆問窗口說，技術外包的能力與品質如何，當然就是接案團隊概括承受能力不足的結果。
應對策略：在發案方說明需求時，請務必提出一些關於系統功能的問題，確認發案方的窗口或是專案負責人的技術程度，如果對於技術的觀念稍嫌不足，這時候在簽約時，請著墨在合約的「成果交付」上，盡可能的定義清楚「交付物的通過標準」，避免到時候交付時的爭議。發案方的窗口，其實很懂技術：恭喜，如果有一個懂技術的窗口，在未來的合作上可以省下許多的麻煩，唯一的困擾就是對方想要主控太多東西，開發時綁手綁腳。
應對策略：正式合作前，需要和對方建立好溝通的方式，並確認雙方的權責，例如：前端要用什麼語言、什麼框架，可以事先說好，但是開發時的Coding Style，是不是有特別要求、版本怎麼管理、API怎麼設計…等，需不需要也事先說好，這些能在正式合作前說清楚就說清楚，避免開發過程時的爭議。
發案方本身沒有技術團隊：這種情況就需要戒慎恐懼了，對方沒有技術團隊，卻還是可以提供一份需求規格文件，這樣的文件真的有辦法照做嗎？如果對方窗口的態度謙虛，尊重技術團隊的建議，那倒沒什麼問題，最麻煩的是對方沒有技術概念，卻一直說「我有參考OO網站，它的功能是這樣這樣、流程是那樣那樣」、「我們能不能這樣做…」，還因此寫了一份規格文件，而技術團隊看到文件或聽到後，反應「這個不能這樣做啦」、「對方懂不懂啊」、「不要亂提需求啊」，對於夾在中間的PM來說，真的是一大挑戰。
應對策略：聽到發案方提出有點「不妙」的需求時，請先耐住性子，不要直接否定對方，並詢問「請問這樣的需求是要解決怎樣的問題」或「請問這樣的需求是要達到什麼目的」，對方會提出這樣的需求，大多數都是有某個原因，才會去參考其他的網站，覺得這樣的功能很棒，希望可以加在開發項目中。而面對技術團隊的反對聲浪時，則需要更沉住氣，解釋提出需求的原因和動機，如果一樣遭到反對，則和團隊憶起思考，是否能提出更好的解決方案。
過去，曾經有一個案例，就是客戶提出想要知道網站上的「同時在線人數」，對於不懂技術的人來說，希望知道這個數據是合情合理的，總是會希望知道現在在線的人有多少，但是有一個狀況是，一般網站的連線方式，是當使用者連線到網站後，就會斷開和該網站的連線，不會占用連線的資源，也就是俗稱的「短連線」，而要知道「同時在線人數」，就必須要依靠「長連線」，這兩種技術概念不同，不懂技術的人根本不知道這樣的狀況。然後，「同時在線人數」又是很常見的資訊，就會覺得理所當然做得到。於是，在雙方認知不同的狀況下，就容易會產生衝突。
■ ODM 可能會遇到的狀況
ODM算是最常見、最普遍的狀況了，例如：某間餐廳委外開發一個官方網站、設計一個活動網頁、規劃一個登陸頁(LandingPage)進行促銷活動，都很有可能是這種方式。而這種時候的老闆或是發案窗口，也知道自己不是專業的技術人員，也不需要提出規格文件，要做的就是提出需求，然後驗收、付錢。這種狀況下，我們應該要做的就是簽訂一個雙方沒有爭議的契約，步驟如下：
確認專案目標、目的，及專案想要達成的成果
依據專案目標及目的，了解細部的專案需求
依據專案需求，提出專案的解決方案
依據解決方案，設計產品並制定產品規格
與發案方確定產品規格是否符合期待，並確定「驗收標準」
約定驗收交付的方式、期程
報價、議價與約定付款方式
簽訂合約，合約重點在於明訂雙方的責任、費用、開發項目與期程、如何交付及付款，最後就是專案如何終止及結案
※「驗收標準」有兩種狀況，舉個例子來說，假設有一間專門賣炒飯的店，現在你希望對方做2人份的豬肉炒飯，你覺得最有可能評判的標準是下列哪種？
(1) 飯2碗、豬肉絲200g、雞蛋2顆、洋蔥1/4顆、高麗菜1/8顆、蔥1支、醬油20c.c.、鹽6g
(2) 超好吃/好吃/普通/難吃/超難吃，飯-有、豬肉絲-有、雞蛋-有、洋蔥-有、高麗菜-有、蔥-有、醬油-有、鹽-有
上述第(1)點的狀況，基本上是團隊內部QA測試的驗收標準，至少需要符合設定的規格才能拿給客戶看；而第(2)點是客戶的實質感受，因為客戶根本不會在意那些功能是不是真的100%實現，他更在意的是好不好用，不好用的話，功能都滿足也沒用，因此在確定「驗收標準」時，千萬不要以為QA測試通過，客戶就願意買單。
以ODM的狀況，最適合的專案管理方式就是「瀑布式開發」，因為有一個明確的交期、開發項目，曾經有人問，敏捷式開發的專案管理方法，適合用來管理外包嗎？
如果專案項目一樣是有明確的開發內容的話，用「瀑布式開發」或「敏捷式開發」沒有什麼不同；唯一會有差異的，就是專案目標不明確時。
以最近很熱的話題「AI」來說，有一個業主想要開發「AI相關的應用」，但是卻不知道要做什麼好，但是又不想養團隊開發，於是找外部團隊協助開發，這種狀況下要怎麼執行？
因為專案目標不明確，所以適合的專案方法就會是「敏捷式開發」，可能約定一個月(四周)為一個衝刺，在一次的衝刺中，用一定的預算驗證一種產品概念，也許預算是10萬元。如果這次衝刺的產品概念，確實可以滿足特定的用戶，再去發展成最小可行性產品(MVP)；如果沒有買家願意付費購買這次的產品概念，那就趕緊換下一個主題去驗證。
當然，要這樣操作，也需要有發案方願意配合。更多的是業主根本不知道什麼是「敏捷式開發」。如果，發案方的老闆懂敏捷式開發，那相對的，也需要找到能配合敏捷式開發的團隊，如果找到的是瀑布式開發的團隊，光是前期要將需求明確下來，雙方也是有得討論。
想在軟體外包公司活下來，務必掌握三件事：
1.徹底理解客戶的需求是什麼？
2. 明確定義產品驗收標準是什麼？
3. 寫一份讓自己可以安全退場的合約!!
—
大家好，我是 數位產品開發教練 – 陳俊聖/廣三/HeroMi
17年數位產品開發經驗。經手至少80個大小專案。
擅長解決與工程師的溝通問題，幫你建構工程思維。如果有任何想法，歡迎留言或發信給我，希望可以幫到你
我的信箱：[email protected]
我的LINE OA：@hero-mi
歡迎加入粉絲團：數位產品開發教練 – 陳俊聖/廣三/HeroMi
*本站所有文章未經授權，請勿任意利用、引用、轉載，但是歡迎按讚、訂閱、分享。