【PM總動員】網路接案公司的專案經理都在做什麼？那些我在 25sprout 經歷的乙方生活
【PM總動員】是產品三眼怪的每月定期客座單元，挖掘邀請海內外業界產品開發相關領域的大大們和大家分享！本月邀請到的是曾仲平（Tseng Chung Ping），目前在 25sprout 擔任 PM，本身為科技產品的愛好者，創辦了科技產品與牠們的產地線上社群，提供科技產品愛好者一個分享與交流的平台。這篇文章將會從 B2B 接案專案經理的角度，分享實際的工作內容、流程與挑戰！本篇文章包含
- 什麼是網路接案公司
- 網路接案公司的業務範圍
- 網路接案公司的專案流程
- 網路接案公司的專案經理
- 網路接案公司會遇到的難題
- 利害關係複雜
- 專案變動很大
- 非專屬的團隊
- 專案類型多樣
- 身為專案經理抱持的心態
什麼是網路接案公司
在商業世界中，大家常說的甲方和乙方，大多指的是合約中立契約人雙方的代稱。其中，甲方通常指的是接受服務的一方，而乙方則是指提供服務的一方。以接案為例，甲方通常指的是負責提出需求的客戶，而乙方則是指負責承接甲方需求，提供對應商品或服務的公司或個人，也就是大家所說的接案公司或個人接案者。
網路接案公司的業務範圍
而依據產業和公司的不同，每間接案公司的業務範圍其實也都不太相同。以網路產業來說，業務範圍可以是各種與網路相關的專案需求。例如：網站、APP、iOT、互動設計、網路廣告、社群經營等等。而以我目前所在的公司來說，就是以網站或 APP 的專案為主。
這邊也特別提及一下，雖然都是網站或 APP，但每個專案的範疇、時程、預算其實都不一樣。例如：有些網站是一次性的靜態活動網站，有些網站則是需要串接前後台和第三方服務的電商網站。即便是同樣的需求或功能，在兩個截然不同的專案上，可能都會有不同的瓶頸和作法。
網路接案公司的專案流程
階段一：需求確認
每個專案開始的原因有很多，有可能是老闆的朋友，也有可能是客戶幫介紹。但不管開始的原因是什麼，一開始都會需要先確認專案中最基本的三個要素，也就是「範疇」、「時程」和「預算」，才能進一步評估是否要承接此專案。
範疇
以網站或 APP 來說，首先要確認的就是甲方期望的範疇，身為乙方的我們是否可以做到。例如：是否要做介面設計、是否要有多語系、是否要有後台串接、是否要串接第三方服務、是否要支援各大瀏覽器、是否要做 APP 雙平台、是否要用自有主機等等。
時程
確認完範疇之後，接下來要確認的就是甲方期望的時程，身為乙方的我們是否可以配合。例如：甲方有可能是今天才第一次跟你談需求，就跟你說網站下個月就要上。這時乙方的我們就要評估各方因素，來決定是否可以配合此時程。
預算
確認完範疇和時程之後，再來要確認的就是甲方期望的報價，身為乙方的我們是否可以接受。例如：甲方有可能覺得報價不應該這麼高，因為在他的認知這很簡單，或是其他專案沒這麼貴等等。這時乙方的我們就要評估各方因素，看是否可以在維持商業利益上，讓兩邊都得到雙贏的局面。
在經過多次的討論、提案甚至 POC（Proof Of Concept） 之後，如果雙方有順利達成共識並完成簽約。在專案正式開始之前，通常還會在外部和內部各開一場開案的會議，也就是所謂的 Kick-off 會議。此會議除了要向所有與專案相關的利害關係人，說明專案目標、流程、範疇和時程之外，也會藉此建立彼此的共識與信任關係，讓專案後續可以順暢地進行下去。
階段二：專案執行
完成開案之後，沒意外的話就是按照原定的專案時程進行。以一個網站建置專案來說，在網站架構確認之後，就會針對各個頁面進行流程與介面設計，再由開發者陸續進行開發和串接，最後經由內外部測試完畢後，按原訂時程將網站打包部署上線。
階段三：驗收結案
而當專案執行到一個階段之後，乙方可能需要準備對應的文件請甲方進行驗收。例如：測試文件、操作手冊、驗收單等等。而乙方也通常會在驗收之後，向甲方請款對應比例的專案費用。等當案子範疇內的驗收和請款都完成了之後，基本上這個案子就可以算是結案了，至於後續專案的保固維護要怎麼進行，因為要看合約怎麼訂定，這邊就不特別贅述了。
網路接案公司的專案經理
瞭解完業務範圍和專案流程後，你可能會好奇那專案經理要做些什麼？如果以上述的專案流程來看的話，專案經理基本上從簽約之後，都會時時刻刻參與其中。包括主持開案會議、溝通專案需求、管理專案時程、協調專案資源、測試專案成果、準備驗收文件、詢問請款發票等等所有你想得到和想不到的事情。
而以我們公司早期或其他公司來說，專案經理甚至還會負責提案比稿、功能報價、合約簽訂等工作，就看每間公司的組織結構和職責安排而定。但基本上只要你是這個專案的專案經理，任何與這個專案有關的事情，你應該都是逃不掉的（苦笑）。
網路接案公司會遇到的難題
介紹完什麼是網路接案公司之後，接下來來聊聊接案公司常會遇到的幾種難題：
利害關係複雜
甲/N ↔ 乙
雖然在前面的內容，我們一直都只有談到甲乙兩方。但如果甲方的組織規模較大，且此專案涉及跨部門的人員，甲方通常會依據部門或是派系(?)再分成 N 個區塊。此時你會遇到的難題，可能是你的窗口根本沒有實質決策權，所以之前討論好久的結果，有可能一夕之間就被其他人全盤推翻。（通常都是設計被大改，然後設計師直接崩潰）
另一種你可能會遇到的難題，是你的窗口根本不是需求單位，卻一直依照自己的想像來提出需求。結果等到整個專案進行到一半甚至快結束時，才發現需求單位根本不採用，最終案子就被中斷或被草草結束。
甲 ↔ 乙 x N
而除了甲方可能會分成 N 個區塊外，乙方也可能會有 N 個乙方。例如，甲方有可能一個專案，會同時找多個乙方進行開發。像是前後台找某廠商、金流找某廠商、POS 找某廠商等等。而這些乙方廠商除了彼此需要協作外，同時也需要劃清界線，避免後續權責問題難以釐清。
例如：大部分的電商平台都串接了不只一種的第三方服務，包括金流、物流、POS 等等。如果網站平時沒有相關的監控機制或 log 紀錄，發生問題時就會很難釐清原因。而這對其中負責主要開發的乙方就會很不利，因為甲方通常都只會找主要的乙方，如果沒辦法證明問題是其他乙方所造成，甲方對你的信任程度就會大打折扣。
甲 ↔ 乙 ↔ 丙 ↔ 丁 ↔ 戊
最後，在一個專案裡面，你也未必總是乙方的角色。你有可能某方面身兼乙方和甲方，因為你會把部分工作再外包給另一個乙方。而你也可能甲乙方兩方都不是，就只是一個層層外包之後，無法得知上層關係是誰的丙丁戊方。
這種時候就要特別注意，因為你接收到的訊息，有可能已經過了好幾手。如果訊息不夠完整甚至傳遞錯誤，就有可能會遇到專案進行到後期，才被告知上層要的和當初講的都不一樣。例如：我就有遇過專案已經進行到後期，才被告知一定要用特定程式語言來寫，或是主機臨時要改為自有主機等等。
專案變動很大
理想上專案都是安排好的事情，就順順地做下去就好。但做專案哪有不變動的，尤其以接案公司來說，那些會造成專案變動的隕石，除了時不時會來很多顆外，有時還會特別大顆，而且想避也避不掉。
為什麼會這樣呢？主要是因為接案是個非常仰賴客戶關係的商業模式（或者說 2B 都是）。你必須先維持好客戶關係，才有機會繼續合作或是被介紹給另一個合作機會。也正因為如此，站在企業經營的立場，只要獲利的前提不變，在面對客戶需求時一定是能滿足就滿足，即使現在吃點小虧也沒有關係。
但這對專案管理就會是一個很大的難題，以專案管理常用的三重限制（Triple Constraint）來說的話，只要專案的三個限制中有一個需要調整，其他的限制就有可能要跟著變動，不然就得轉而犧牲交付的品質。
舉例來說：如果某個專案的時程，突然要提前一個月上線。在預算不變的情況下，就可能得捨棄部分的功能，將專案改為分階段上線。又如果某個專案的範疇，在你的認知只包含 A，但在客戶的認知卻包含 A+B+C。在過去合約和討論都沒明確載明，預算又不變的情況下，就可能得拉長原訂時程，將專案改為延後上線。
該如何在這些互相牽制的專案限制中進行取捨，同時又讓所有利害關係人都滿意。我覺得是專案經理最具挑戰性，也最能展現價值的地方。但如果要我選擇的話，當然還是能不變動是最好。這邊也分享一些能多少避免隕石發生機率，或至少減輕隕石損傷的方式。
例如：合約更明確載明專案範圍、時程與預算，並附上但書條件；任何即便是在電話中的討論，都要隨時留存記錄在雙方都有的文件或 Email 中；凡事話都不要說太滿，才能保有一點彈性應對突如其來的變動，並主動控制客戶的期待。
非專屬的團隊
接案公司和產品公司最不一樣的地方在於，每個專案所配置的團隊，其實都不是專屬於一個專案的。不管是專案經理、設計師還是工程師，每個人手上的專案數量通常都不只一兩個。也因此，每個專案的人力配置組合其實都不太一樣，甚至有時還會因為其他因素而變動，因為人力在各專案其實是共用的。
而這對不管是專案經理、設計師還是工程師來說，都是蠻大的挑戰。以專案經理來說，你得熟悉不同團隊組合的個性和習慣，來調整你專案管理的方式。而如果你專案的設計師或工程師，臨時需要去支援（救火）其他的專案，你就得迅速評估對專案造成的影響，來決定是否要和其他專案進行協調或打一架（？）。
專案類型多樣
最後一個想聊的難題，是接案公司各式各樣的專案類型。以我們公司來說，因為我們並沒有鎖定特定幾種專案類型，所以每個專案所會需要的領域知識，其實都有很大的不同。
像如果是金融保險的專案，你可能就會需要去了解相關的專有名詞、技術限制和內外部規範，才能在與客戶溝通的時候，明確知道客戶的需求和限制是什麼。而如果是電商平台的專案，你可能就會需要去了解購物車、訂單、金流、物流、發票、退貨、折扣、紅利等機制是如何運作的，才能在規劃流程和規格時更加完善。
也因為專案類型的不同，每個專案所會遇到的問題，其實也都不太相同。以我自己接手過的案子來說，如果只是單純的活動網站，基本上只要確保設計不要跑版以及功能運作正常即可。但如果是跨國型的資料分析後台網站，就可能會遇到像是資料載入過慢、資料同步問題、多國主機部署等千奇百怪的問題。
該如何在一片未知的情況下，快速應對並找到對應的解決方案，我覺得這真的是需要時間和接觸各種專案來累積經驗值。而我自己覺得很幸運的是，我們公司的同事人都很好，只要你願意問也願意學，大家都很願意用你能理解的方式來跟你溝通和解釋，這對於尚未有很多經驗的專案經理來說，就會是個很好的學習機會。
身為專案經理抱持的心態
文章的最後，雖然還有很多議題可以討論，但因為篇幅有點太長，就來聊聊我自己身為專案經理所抱持的心態好了。
有些人會覺得專案經理就是專案的執行者，不需要主動針對專案範疇、時程和預算有任何想法或意見，反正你是在做接案而不是在做產品。但也有些人覺得專案經理就是專案的管理者，需要主動針對專案範疇、時程和預算進行管理和協調，甚至擔任一個類似顧問的角色。
對我來說，這些想法可能都對與不對。因為身為專案經理，在不同的專案背景下，面對不同的人本來就是要扮演不同的角色。但不管扮演什麼樣的角色，我覺得專案經理都必須樂於「擁抱未知」，並抱持著「當責」和「釋懷」的心態。
因為每天你都可能要面對各種千奇百怪的問題，不管是人的問題，還是技術的問題。例如：在你沒碰過歐洲客戶的專案之前，你可能一輩子都不會知道 bank holiday 是國定假日的意思；在你沒碰過大量資料寫入和讀取的專案之前，你可能也不會知道有 Queue 和 Cache 這種機制。所以你必須不排斥去學習這些新的東西，才有辦法真心喜歡這份工作（因為真的累）。
同時，你必須認知到專案不管成敗與否，怎樣都是與你有關，你能做的就是盡可能超前部署，來降低風險發生的機率，或是減輕風險發生後的損失。而那些過程中無法預料到的事情，就要學會長知識，並說服自己「這就是人生」，不然每天都會過得蠻辛苦的。
總而言之，「心存善念、盡力而為。積極樂觀、感恩惜福。」，就是我覺得身為專案經理應該抱持的心態。
最後，不管別人怎麼說，還是想和各位 PM 們說聲辛苦了，相信你不是在加班，就是在加班的路上。願我們都能早日脫離加班苦海，共勉之。
如果單純想給我們一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-30 個拍手；
如果想看更多產品心法相關的文章，請盡情長按拍手（最多50個）讓我們知道 👏🏻想要持續追蹤我們的最新文章，請記得追蹤「產品三眼怪實驗室」(◉◉◉)！
我們每週末都會認真更新文章唷！千萬別錯過了✨
