《我的專案筆記 #34》身處軟體外包公司的PM,又該怎麼辦?- 數位產品功能這麼多,要怎樣安排時程?(補充) — HeroMi

HeroMi/Jason
·
·
IPFS
·

入行軟體開發以來,大多數時間都是在開發公司或是上級長官設定的產品,直到最近這幾年才開始接觸到外包的專案。坦白說,這是蠻幸福的一件事,我是指開發公司要的產品,身邊很多朋友其實都是在外包公司打拼,總是會遇到不少事故,創造許多人生故事。如果身處軟體外包公司的話,該怎麼辦?

首先我們要先了解「產品服務的對象」是誰?如下圖。

什麼時候會是上圖的(A)?什麼時候又會是(B)?

如果我們所處的公司是專門在幫人架設官網,或是製作一些APP工具,有很高的機會會屬於上圖(A)。

如果我們所處的公司是和廣告公司、整合行銷公司合作,那很高的機會就是上圖(B),由轉發包公司去接業務,再轉包出來,這在業界也是很常見的合作方式。想想看,如果我要辦一檔行銷活動,勢必需要活動頁、宣傳頁,甚至還要開發小遊戲,所以廣告公司會和許多間軟體開發公司合作,轉發包適合的團隊,畢竟每間軟體開發公司都有各自擅長的領域,有的擅長網頁、有的擅長APP。

這兩種直接的差異,在於「和誰確認需求」?

以上圖(A)為例子,開發團隊可以直接與發案方確認需求,這時候問題通常不會太大,畢竟可以直接溝通。

《延伸閱讀:搞懂客戶需求,以及需求背後的需求

但是,如果是圖(B)問題就來了。

假設圖(B)的轉發包公司為廣告公司,那他們對於軟體開發的細節會清楚嗎?如果發案公司問了一些技術的問題,這些轉發包公司有辦法精準回答嗎?又如果轉發包公司為了可以搶下案子,而隨口答應發案方,事實上卻做不到,又該如何?

畢竟直接溝通都不一定順利了,中間隔著一個轉發的單位,溝通難度當然就會更高。

再來,要了解這次的軟體外包案,是OEM還是ODM。

OEM(英語:Original Equipment Manufacturer的縮寫)簡稱:委託製造 ,又譯原始設備製造商,指由採購方提供設備和技術,由製造方負責生產、提供人力和場地,採購方負責銷售的一種現代流行生產方式。

ODM(英語:Original Design Manufacturer的縮寫),即原廠委託設計代工,又譯原始設計製造商,又俗稱為貼牌生產,指由採購方委託製造方,由製造方從設計到生產一手包辦,而最終產品貼上採購方的商標且由採購方負責銷售的生產方式。

–《wiki 維基百科》

簡單來說,OEM就是發案方提供需求及規格文件,接案公司依據文件進行開發;ODM則是發案方僅提供需求,由接案方依據需求,進行設計與開發。

■ OEM 可能會遇到的狀況

  1. 發案方本身擁有技術團隊:這種狀況是最棒的,因為只要依據發案方提供的文件,配合開發即可,但是還是有些地方需要注意。

    • 規格文件是不是發案公司自己可掌握的:千萬別以為發案方有提供規格文件,就覺得開心,這反而是要小心的開始,過去曾經遇過一件案例,就是發案方不知道從哪邊買來的規格文件,就要求團隊照著文件開發。以發案方的角度來說,我文件都提供了,怎麼會沒辦法開發,這種時候的狀況就是,這份文件的內容須要有專人去研究、消化、理解,這是需要時間的,而且文字上的理解,是很容易有誤會的。業主負責專案的窗口,對於這份文件的了解也不深的話,那要多多小心。

      應對策略:提出需要時間研究與了解文件,避免一知半解的狀況下開發。

    • 發案方的窗口,其實不懂技術:這個狀況要特別特別小心,因為對方的窗口很高的機率其實不知道自己在寫什麼文件,於是,常常遇到的狀況就是雙方花很多時間確認需求,然後技術開發完功能後,對方卻不買單,最後對方的老闆問窗口說,技術外包的能力與品質如何,當然就是接案團隊概括承受能力不足的結果。

      應對策略:在發案方說明需求時,請務必提出一些關於系統功能的問題,確認發案方的窗口或是專案負責人的技術程度,如果對於技術的觀念稍嫌不足,這時候在簽約時,請著墨在合約的「成果交付」上,盡可能的定義清楚「交付物的通過標準」,避免到時候交付時的爭議。

    • 發案方的窗口,其實很懂技術:恭喜,如果有一個懂技術的窗口,在未來的合作上可以省下許多的麻煩,唯一的困擾就是對方想要主控太多東西,開發時綁手綁腳。

      應對策略:正式合作前,需要和對方建立好溝通的方式,並確認雙方的權責,例如:前端要用什麼語言、什麼框架,可以事先說好,但是開發時的Coding Style,是不是有特別要求、版本怎麼管理、API怎麼設計…等,需不需要也事先說好,這些能在正式合作前說清楚就說清楚,避免開發過程時的爭議。

  2. 發案方本身沒有技術團隊:這種情況就需要戒慎恐懼了,對方沒有技術團隊,卻還是可以提供一份需求規格文件,這樣的文件真的有辦法照做嗎?如果對方窗口的態度謙虛,尊重技術團隊的建議,那倒沒什麼問題,最麻煩的是對方沒有技術概念,卻一直說「我有參考OO網站,它的功能是這樣這樣、流程是那樣那樣」、「我們能不能這樣做…」,還因此寫了一份規格文件,而技術團隊看到文件或聽到後,反應「這個不能這樣做啦」、「對方懂不懂啊」、「不要亂提需求啊」,對於夾在中間的PM來說,真的是一大挑戰。

    應對策略:聽到發案方提出有點「不妙」的需求時,請先耐住性子,不要直接否定對方,並詢問「請問這樣的需求是要解決怎樣的問題」或「請問這樣的需求是要達到什麼目的」,對方會提出這樣的需求,大多數都是有某個原因,才會去參考其他的網站,覺得這樣的功能很棒,希望可以加在開發項目中。而面對技術團隊的反對聲浪時,則需要更沉住氣,解釋提出需求的原因和動機,如果一樣遭到反對,則和團隊憶起思考,是否能提出更好的解決方案。

    過去,曾經有一個案例,就是客戶提出想要知道網站上的「同時在線人數」,對於不懂技術的人來說,希望知道這個數據是合情合理的,總是會希望知道現在在線的人有多少,但是有一個狀況是,一般網站的連線方式,是當使用者連線到網站後,就會斷開和該網站的連線,不會占用連線的資源,也就是俗稱的「短連線」,而要知道「同時在線人數」,就必須要依靠「長連線」,這兩種技術概念不同,不懂技術的人根本不知道這樣的狀況。然後,「同時在線人數」又是很常見的資訊,就會覺得理所當然做得到。於是,在雙方認知不同的狀況下,就容易會產生衝突。

■ ODM 可能會遇到的狀況

ODM算是最常見、最普遍的狀況了,例如:某間餐廳委外開發一個官方網站、設計一個活動網頁、規劃一個登陸頁(LandingPage)進行促銷活動,都很有可能是這種方式。而這種時候的老闆或是發案窗口,也知道自己不是專業的技術人員,也不需要提出規格文件,要做的就是提出需求,然後驗收、付錢。這種狀況下,我們應該要做的就是簽訂一個雙方沒有爭議的契約,步驟如下:

  1. 確認專案目標、目的,及專案想要達成的成果

  2. 依據專案目標及目的,了解細部的專案需求

  3. 依據專案需求,提出專案的解決方案

  4. 依據解決方案,設計產品並制定產品規格

  5. 與發案方確定產品規格是否符合期待,並確定「驗收標準」

  6. 約定驗收交付的方式、期程

  7. 報價、議價與約定付款方式

  8. 簽訂合約,合約重點在於明訂雙方的責任、費用、開發項目與期程、如何交付及付款,最後就是專案如何終止及結案

※「驗收標準」有兩種狀況,舉個例子來說,假設有一間專門賣炒飯的店,現在你希望對方做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個大小專案。
擅長解決與工程師的溝通問題,幫你建構工程思維。如果有任何想法,歡迎留言或發信給我,希望可以幫到你
我的信箱:info@hero-mi.com
我的LINE OA:@hero-mi
歡迎加入粉絲團:數位產品開發教練 – 陳俊聖/廣三/HeroMi
*本站所有文章未經授權,請勿任意利用、引用、轉載,但是歡迎按讚、訂閱、分享。

CC BY-NC-ND 4.0 授权

喜欢我的作品吗?别忘了给予支持与赞赏,让我知道在创作的路上有你陪伴,一起延续这份热忱!

HeroMi/Jason大家好,我是 數位產品開發教練 – HeroMi/Jason 17年數位產品開發經驗。經手至少80個大小專案。 擅長解決與工程師的溝通問題,幫你建構工程思維。 如果有任何想法,歡迎留言或發信給我,希望可以幫到你 我的信箱:info@hero-mi.com 我的BLOG:https://hero-mi.com/
  • 来自作者
  • 相关推荐

《我的專案筆記 #35》軟體產品全生命週期:從商業分析到專案實現

《我的專案筆記 #33》研發或應用新技術前,請先想想「商業價值」- 數位產品功能這麼多,要怎樣安排時程?(4/4) — HeroMi未命名

《我的專案筆記 #32》開發新產品,請試試「最小可行性產品(MVP)」 – 數位產品功能這麼多,要怎樣安排時程?(3/4) — HeroMi未命名