文／Abby Huang

產品經理是這幾年從矽谷吹來的一個風潮，過去在台灣通常「產品經理」代表的是硬體方向的產品設計、包裝以及供應鏈管理。在台灣， CEO 多半是由財務主管或是業務高階主管出任，而矽谷早已吹向由產品經理出任的方向。在 TechOrange 的這篇文章：越來越多矽谷企業由產品經理領導！PM 對企業發展來說為何重要？ 中就提到 Google 及 Youtube 的 CEO 都已開始由產品經理出任！而這麼重要的方向在台灣目前仍少見。台灣的軟體系統服務商極少有真正「產品經理」的角色，多半為有責無權的「專案經理」角色為多，又或者是兩者都須兼具。以下我就簡單介紹這兩者的異同。

軟體專案經理

如果以製造業來舉例，純粹的軟體專案經理就可以相等為代工行業中的專案經理。例如我很會做鞋子，所以我幫 Nike 製造鞋子，但我只負責購買原料、製造、量產、QC(品質管理)，這個鞋子本身的設計應該是 Nike 要給我的，我們拿到設計後，評估製造方法、交期與成本。當然產製完後的銷售、廣告、行銷方案都是 Nike 要做。

軟體專案經理的成敗取決於專案開發期間的獲利以及保固維護期間的獲利。

軟體專案經理的重點職能

• 評估客戶要製作的軟體所需的人力、技能以及完工時間為何？
• 依照評估結果盤點目前可使用的人力(Talent)、技術或平台資源。
• 開展 WBS (Work Breakdown Structure) 粗略評估時程
• 召集專案成員，開始執行專案。在專案執行的每一步，都需要進行溝通及管理，確保成員明白自己的角色並且提供各階段每一個成員需要的資訊或資源，讓專案順利進行。
• 需求訪談 （產出需求分析文件）
• 系統設計規劃 （產出系統分析、系統設計文件）
• 系統開發 （產出週報、月報等進度報告）
• 測試與教育訓練 （產出教學手冊、測試案例、SIT測試報告、UAT 測試報告）
• 正式上線 （產出上線流程文件、上線報告）
• 驗收與交付 （產出驗收報告、UAT測試驗收報告、壓力測試等視合約規定，以及原始碼交付）
• 需求變更CR（Change Request）與品質管理（Bug）等維運管理（CR需求確認、系統設計、ＵＡＴ等都要做一遍。以及維運固定的週報或月報）

軟體專案經理的本職職能

• 軟體開發框架基礎的了解：例如前端、後端在做什麼？用哪些工具管理版本、原始碼
• 硬體網路環境的基礎了解：例如基本網路架構、地端、雲端該怎麼配置優缺點，以及資訊安全基本架構、備份還原與災害復原方案的基本架構
• UI/UX的基礎了解：例如基本的權限管理設計是如何、基本的網站會員機制應包括哪些等

在台灣的SI業界，資深的PM其實服務範圍極廣，以下為我建議最好可以有的職能

• 法務：既然是產品代工，務必會簽訂合約。而是否能順利驗收通常與合約的項目會有關係。因為權利義務都會載明於合約中。為了順利結案驗收，我通常會願意參與合約制定過程，以免驗收不成白做工又傷和氣。
• 會計：稍微明白財務會計的流程，對於開發票與請款的順利程度會差很多。
• 人資＆管理：軟體專案經理其實不是誰的經理，通常在組織職能上，與你配合的工程師並不直屬於你，所以在管理鏈上你並不握有此人的績效、薪資的決定權。在這狀況下，要如何領導變成一個很重要的關鍵職能。關於這件事我從許多傑出的 PM 前輩上學習到很多，有機會再寫一篇跟大家分享。

想轉職軟體專案經理

如果你想轉職軟體業的專案經理，以下是一些轉職建議。

社會新鮮人

先說結論：建議從專案助理開始做起，而最好有資管、資處等資訊相關或是建築工程相關的學習背景。

如果以硬體代工產業來說，如果你完全不明白這個硬體的製程、目前最新的技術與流行的框架，要能夠一肩扛起專案成敗是不太現實的。

總的來說，如果老闆願意讓你扛，那麼可能因為這個專案失敗的機率夠高，他只是需要有人可以填坑。所以在如此狀況下只會有兩種結果：一種是你從失敗機率很高的專案中拼命學習並且短時間內掌握力挽狂瀾的技能快速出師。另一種結果是你發現你不具備有打這場戰役的軍備武器，所有的努力都是以卵擊石，然後你不知道到底成功的專案應該要如何執行的狀況下灰心的想另謀高就。

非本科系上了一些課程以後想轉職

先說結論：你會一起工作的少部分工程師不是一般人類，需評估你對工作壓力的耐受度

市面上的課程多半是你教你如何做專案經理的工作，只有教『DO』的部分，但轉職人通常對於自己的作法沒有很多底氣，又或是太有底氣但不符合業界常規，會以為 PMP 教的內容就等於上數學課1+1=2 的真理，認為跟你一起執行專案的人都知道自己應該做什麼。

在上完好幾萬的昂貴課程以後認為知道應該怎麼做了，實際在執行過程中會遇到超級多溝通障礙跟落差。但我先假設這樣的轉職者已有三到五年的工作經驗的狀況下，我認為主要會遇到的障礙就是溝通：尤其是跟工程師的溝通！非本科系的人會很難分辨當前端跟後端吵架的時候、開發團隊跟網管資安團隊吵架的時候到底該怎麼調解？是誰對誰錯？

再來就是軟體專案執行中會遇到異常密集的突發狀況，每一個狀況都有可能影響進度乃至結案驗收，所以壓力的耐受程度會是主要考驗。

前後端工程師、FAE QA UI/UX想轉職

先說結論：對客戶與主管不能直接說做不到，需從整體公司利益考量最佳做法

對於原本就是在這個圈子裡面的來說，轉職的障礙可能較小。但從產線上的一個生產單位要轉為管理產線排程的角色在本質上就是一個職能轉換，除了老闆有可能希望你兼顧原本的開發職能，再兼顧PM角色會讓你壓力山大以外，PM 角色的主要溝通對象除了開發團隊外，其實是客戶與老闆。

原本作為產線的角色，拿到的工作分配只有自己這部分的工作，做完以後就做完了。但 PM 本身不負責產出，是要進行工作分配（開 Ticket ），這包括了要了解客戶需求、軟體與網路架構、時程分配甚至是預算，才能準確的知道這個變動要開哪些Ticket 才能達成目標。簡單的說，ＰＭ的目標產出是『解決問題』。跟看單辦事的工程師很不同的是，解決問題的方法不只有一個，有時可能是折價、延後付款期限、加送CR時數，有時候可能是進行 UI 調整而不需要動到程式。這跟工程師習慣的改程式、加功能會有很大差距。總的來說，就是要變得更有彈性、更有創意。

跟客戶與長官互動，是不能動不動就說『不可以，做不到』的，而是要先想方法或話術溝通，評估時間與成本交由對方決策，再來就是要評估整體專案維運與溝通成本，故無法動不動就加程式改 DB 解決問題。

軟體產品經理

如果以製造業來舉例，產品經理就是當我是 Nike 要開發一款新的鞋子時，我必須要先考慮到目前公司品牌的市場定位、品牌銷售鞋子的市場均價、請代言人的行銷公關成本、了解最新的球鞋製造技術與大致的製造成本。了解我的品牌受眾(TA)可支配所得，以及他們願意為這個代言人或為這個製造技術、設計所付出的價格。評估製造商的技術能力、品質、交期、價格，也許是我的公司就有的工廠或是外部的工廠。另外我還需要了解TA的偏好、目前遇到的問題與痛點，以確保我的球鞋推出後客人會購買。

總的來說，就是制定一整套可行的商業流程，設定預算與成本，並確保產品持續獲利能力。

產品經理的成敗在於是否能符合產品每一階段的階段性目標，而不在一時的獲利能力。

軟體產品經理的重點職能

• 市場分析：包含產品價值、價格定位 (產出人物誌 Persona& 市場需求總覽 MRD,Market Requirement Doc)
• 服務流程：需了解目前市面上主導產品的服務流程與痛點(如UI/UX)並設計符合自身產品的服務流程(產出用戶地圖 User Journey Map & 產品需求總覽 PRD,Product Requirment Doc)
• 產品生命週期管理：產品可能會從 POC (Prove of Concept) 轉到類似遊戲封測的試營運期，測驗市場接受度，然後全面開放正式營運。也有可能會因為使用者行為或法律、市場狀態等外部環境變更，而進行升級改版。(產出產品發展藍圖 Product Road Map 與產品策略 )
• 產品開發：訂出產品的 Road Map 後，當然就是要進行開發，這部分可以由產品經理擔任也可以由其他人擔任。現在流行的是『敏捷開發』並且用『OKR』管理績效，這個我之後可以再談這個階段中如果是同一人或不同人主導產品開發的時候該如何分工。(參考上面軟體專案經理要產出的文件)
• 市場化階段：進行A/B測試，收集使用者反饋後，決定哪一個部分要留到產品生命週期的下個版本進行開發。
• 產品重要指標追蹤與反饋：產品在每一個階段應要訂出重要目標，例如蝦皮在補貼階段重要的不是財務指標（賺多少錢），而是新用戶成長速度。補貼階段後期應該觀察的是黏著度與市場份額（DAU, Daily Active User）以評估是否結束補貼。最終才是進入財務指標的評估。每一個階段的目標如果不如預期，可能需要退回上一個階段持續改進再重新進入此階段。又或者需要提出更多市場觀察數據，在這個階段提出改進方案。
• 持續改進產品：產品上市後，可能會有更多新的需求進入。依照產品本身的目標（黏著度、轉換率等等）來評估是否推出新功能，或者是移除沒有人使用的舊功能，持續改善產品。

軟體產品經理的本職職能

• 對市場的基礎了解：如果你要做的產品是交友APP，那就意味著你必須對想要使用交友軟體的人有一定程度的了解，並且對市場上各種不同型態、目的的交友軟體甚至是你的線下競爭對手，例如婚友社、舉辦聯誼的個人品牌等等消費體驗要有了解。包含他們各自的定價、優缺點等等
• 對市場基準值的基礎了解：我們前面提到的轉換率、黏著度、跳出率等等，或者是官方Line帳號的封鎖率，你都需要對於其市場基礎值有一定的了解，才能知道現在自己的表現是好或是差。例如婚友社的配對成功率是否比交友軟體高？成功交往的後，交往的滿意度或是時間長短為何？如果證明婚友社配對成功度高，但是服務費也相對高很多，那麼你能設計出用某種方法接近婚友社的配對成功率，但收費低於婚友社，那就是一個產品競爭度的指標。
• 製作商轉規劃的能力：軟體產品經理就等同於這個產品的 CEO ，就像你必須要提出一個可行的商業提案，在知道定價與成本後，掐指一算要能夠有長期獲利價值的產品，公司才會投入開發與行銷成本。你預估得越準確，越能提供市場需要的價值，產品的獲利能力會越好。

想轉職產品經理

因為產品經理本身的職能比較靠近市場，所以轉職的來源有很多。但唯一我不建議社會新鮮人直接挑戰產品經理，原因很簡單：你不了解市場。 社會新鮮人不只不了解市場行情跟分佈，也不了解法律跟金流等等。除非研究所時就做很多跟該市場有很緊密相關的研究，這樣我覺得就很有優勢。我本身很推薦大人學的矽谷阿雅產品經理實戰指南，如果有想轉職的人可以買來聽，這是很好的入門課。

行銷企劃或產品企劃

原先就是有在該領域進行市場研究的行銷或產品企劃，原本就有很好的市場敏銳度，完全可以轉職產品經理！只是可能需要補足的就是更有系統地進行商轉規劃方面的能力，並且與市場研究機構或外面可以購買的資料分析報告更緊密的連結。 至於在軟體系統開發的部分，可以倚重自己公司現有的資訊人員，或是外聘軟體開發 PM 協助。

資料分析師

許多資料分析師有著敏銳的產品嗅覺，對於自己負責的資料分析領域，逐漸培養出市場敏銳度，而對於開發上線後，持續性地進行指標收集也會非常得心應手。因為本來就是在資訊領域，對於軟體產品開發的流程也有一定了解時，轉職產品經理也很適合。唯一會比較有顧慮的，可能就是『工程師心態』的突破。產品經理就是產品的媽媽，雜事會很多，並且要負責產品是否達標的成敗。無法把失敗怪到使用者不會用或是PM沒溝通清楚等等的問題上，如果要轉職必須要有這個覺悟。

軟體專案經理

原本就具有一定軟體開發經驗的 PM 或是 TPM 當然很適合往前往後包下產品經理的工作，但過去看合約或簽署的需求確認書辦事的心態就不能再有，市場是瞬息萬變的。你能觀察到的流量、跳出率、用戶留存率等，其實都已經是落後指標，你必須要培養屬於自己的市場敏銳度，才能觀察出領先指標為何，有策略性地進行版本規劃。基本上就是要更加貼近市場脈動才能真正知道用戶傾向。

產品PM V.S 專案PM 最大的不同與怎麼分工

我之所以先寫專案 PM 是因為在台灣大多數規模不大的公司中，軟體產品 PM 的職能多半包含開發時期的管理，因為一個產品的生命週期很長，但從零到一的開發時間通常比較短，而且時程上是可以分開的，所以是同一個人也很合理。

但作為 SI (系統整合)公司的專案 PM 的話，重點會在於跟客戶的交涉以及各種進度報告、驗收報告的製作。如果是產品兼專案的情況下，不會需要做這麼多的文件，只要專心做好團隊溝通即可。

在同一公司中，也可容許『產品經理』與『專案管理』有不同的角色分工。通常負責產品功能（Feature）與行銷銷售的可以歸類為 Product Owner (PO) ，而專案經理則是 PM 。PO 負責產品成敗，PM 負責整個軟體開發的進程。

在台灣比較常見的狀況是老闆下達指令要完成某一個項目，由需求單位推派一位代表，說明他想做的事情給資訊單位，並由資訊單位進行需求訪談及開發。此時資訊單位就需要主動要求 PO 用任何一種形式給予上述產品 PM 要提供的資訊，不管是用訪談的還是請需求單位找一個真正的產品 PM 來協助產出這些定義。一個成功的產品或專案一定都是團隊協同合作的成果。

產品架構必須考量的重點

作為一個長期因著各種變量需要進行產品改版更新的架構，比起照合約辦事，更需要注重的是

1. 數據追蹤：因為你會需要追蹤轉換率、停留時間、跳出率等等資訊，所以在開發時就要明確闡述要埋入追蹤碼的地方。如果有會員機制，在開發時就要明確說明會員需要如何追蹤。這樣以後才有數據可以看跟分析。
2. 資訊安全：資安是一個軟體產品非常重要的風險控管，尤其以B2C軟體產品而言。建議要導入 ISO27001 相關規範。而且不是『做文件比賽』的導入方式，而是確實要做好軟硬體的資安防禦，並且定期做弱點掃描、白駭客攻擊報告等等。
3. 個人資料保護法：以全球產品而言，需要考慮歐盟規範的個資法範圍（GDPR），台灣的個資法稍微比較簡單。
4. 自動測試：一個軟體產品的生命週期長至十年，短至三年左右，視產品規模而定。在這個狀況下以一個月上一次版來看，整個週期會經過至少36次的版本變更。導入關鍵流程的自動測試是最有經濟效益的做法。這個在產品初期就必須導入以減低成本。
5. 產品價格與價值：產品最終的商轉極為重要，做產品就是要賺錢！所以產品能提供的價值為何？他是否有『物有所值』的定價策略？ 這個是產品與專案最大的差別！
6. 不停修正的產品策略：就像威而鋼在開發時是設定為心臟用藥，因為他的副作用所以變成壯陽藥一樣。使用者如何使用你的產品有可能跟你開發的初衷不同，但你一定要隨著市場機制靈活改變產品策略，以取得對公司的最佳利益。

專案架構必須考量的重點

專案執行所賣的產品，就是軟體代工管理本身。所以在專案執行上必須考慮的點會更細微

1. 需求本身是否清晰：如果客戶告訴我他要一台車，我不會直接拿我的 Toyota 來當作樣板，而是從頭開始問他現在開的是哪一台？有哪一些不滿意的地方？並且拿一些我認為他會滿意的車子來了解他想要的模式與可以接受的預算。因為一台車可以是印度製無冷氣的新台幣6萬元的 Nano 到賓利都有可能，如果需求本身不夠清晰，預算就會抓錯。
2. 技術與人才是否具備：團隊本身是否具備該客戶需要的技術與人才，這個就是我的產品原料，如果我沒有足夠的人力或我的人才不具備這些技術，我有沒有廠商可以配合開發？因為這都會增加人力成本，所以相當重要。
3. 時程是否合理：簡單說，如果時程不合理，就不要接。又或者如果無法分階段上線，一開始就不可以接這樣的案子。因為通常專案執行都有罰款機制，罰款直接影響到獲利。時程是非常現實的事情，所以若評估後時程不合理，也要把罰款計入專案成本中，綜合評估專案獲利能力。
4. ＣＲ與維運：需求分析的一開始，就必須要在文件中寫清楚架構與操作方式，這樣一來才能清楚界定哪一些是之前沒有說，現在才要的？這些都是成本。軟體本身的設計也要能夠彈性到可以加入一些需求變更。而維運的難易度跟範圍，與當初軟體操作設計相當有關係。我們不會想要在一個已經結案的軟體專案中花太多人力進行維運，所以能夠把維運的考量在一開始設計時就考慮進去相當的重要。
5. 需留意客戶的特殊需求：軟體代工狀況下通常正式環境是客戶端的軟硬體環境，法規也須依照客戶端的法規需求。故若有維運服務的協議，最好另簽SLA(Service Level Agreement)議定服務範圍時間及責任歸屬，另外，若客戶為上市櫃公司，通常會資訊循環要求較嚴謹，或要求軟體開發規格要符合 ISO27001 相關規範。若客戶為金融機構，對於資訊安全與個資規範較嚴謹，也需要特別注意任何會提高服務成本的項目。

本文由 Abby Huang 授權轉載，原文連結

瀏覽 8,914 次