PM的任務

從許多新創公司的案例中，大家或多或少都聽過一些傳奇故事，像是Facebook的馬克．祖克柏（Mark Zuckerberg）寫了第一版的網頁服務，然後就上線取得不少使用者，接著使用者逐漸成長，之後的故事就沒人在意第二號、第三號工程師，甚至整個開發團隊怎麼建立起來，大家就自動跳過了，因為一旦上線，故事的重點全都在募資、商業遊戲、政治、八卦，而管理呢？就交給PM自己慢慢吞吧。

事實上，很多產品的第一步，確實是一、兩個厲害的工程師可以協作打造出來的，我們大可把它稱為POC（Prove of Concept）或是MVP（Minimum Viable Product）的過程，用一個工具、或者一個最小的產品型態接觸到用戶，引起用戶興趣。但下一步的發展，就不再是單純一、兩個工程師可以做的事情，而是需要團隊化。

▶如何定義PM的工作項目？

近年來風行的技術包含區塊鏈相關，許多服務需要跟Instant Message（Line）串接，很多以前在APP發生的行為，都移轉到Line或是FB上，像是TaxiGo或Chatisify，就是衍生出來的服務。

不久的將來，在台灣對於支付的整合，極可能也是必經的一條路，而這每一區塊的服務，運用的語言、技術，都不盡然相同，如果讓同一組工程師來做，恐怕效率難以最大化，所以才需要團隊化。

因此團隊的協作，就是接下來所有想研發軟體的公司肯定會遇到的問題。團隊化的過程，勢必要有人經營管理相關的議題，不論這個人是工程師、PM出身，業務或是UI／UX出身，我們統稱這個人叫做PM。這裡更要特別強調，PM與Tech Lead的功用與定位十分不同，千萬別搞混。我們是這樣定義PM的工作項目：

1. PM是為了達成任務而出現

任務可大可小，可以大到產品經理，也可以小到只是辦場活動。

2. 管理最大的目的是為了控制風險，所有的根本來自於此

一個好的PM，絕不是不會失敗，而是讓失敗不會是0跟1的區別，所有問題只要可被控制，開發的過程只可能delay，而不至於到什麼都做不出來。

3. 選擇團隊的建立、規則的設定，是所有事情的第一步

團隊成員為何，需求怎麼釐清，知道我們要做哪些事情；團隊是否使用Scrum的流程，抑或是我們在過程中，大家怎麼在好的遊戲規則上彼此協作與成長。

4. 如何進行分項測試，而非東西出來才能測試

所以針對後端，需要了解API（Application Programming Interface，應用程式介面）怎麼測試；針對前端，可以做用戶測試；甚至資源充足時，可以跟工程師討論是否做自動測試。

5. 懂得運用專家的知識

很多PM並非技術出身，這也是最為關鍵的一點。也就是除了團隊內部的資源外，一定要有第三方可以協助判斷問題的高手，當然大前提是要相信團隊的判斷，但如果真的遇到衝突，也要避免自己過於獨斷，因此這資源是很重要的一環。

6. 凡事習慣建立備用資源或方案，也是相當重要的一環

因為，人算永遠不如天算！我在創業的六年時間，嘗試定義PM該有的工作型態與模式。但其實PM的領域，在不同的公司範疇是很不一致的，也因此漸漸的，我們把技術開發的每一個環節都交給了PM，讓做產品的過程，交由一個PM去經營跟處理，慢慢衍生成有些PM比較適合產品端，有些比較適合業務端，有些則是學了些UI／UX的技能，有些學了些工程師的技能，學著規畫API，但不管是哪一種，PM的核心，永遠是管理大過於執行，這點是永遠不變的道理。

如何尋找最佳平衡點

做產品的過程，幾乎沒有任何一個產品永遠都讓所有人獲益。基本上，只要是軟體產品的誕生，都意味著有些舊事物會被取代，所以當網路時代來臨，怎麼讓產品受到大眾喜歡，可說是需要天時地利人和。

例如在還沒有網路的時候，很多店家結帳都用計算機，開發票還是用手寫，直到POS機出現，也許大家理所當然以為每個店員都會喜歡用它，其實不見得。因為使用POS機，很多模糊地帶都會被發現，當帳款跟商品的銷售數量有落差時，以往可以稍微喬一下的狀況不見了，取而代之的是清清楚楚的數據化，因此並不是所有店員都喜歡這套系統；即使公司要大量運用，碰到使用者反彈，力量也是不容小覷。

POS機花費不少時間才做到大量轉移且普及化。轉移的事，有時會如期發生，有時卻不會發生，遇到斷層，沒有人繼續跟進，最後就斷炊了。所以，作為產品的管理者，除了顧慮開發層面之外，更要思考如何找到產品發展的甜蜜點！何謂甜蜜點？就是在某個時刻，會使各類使用者都願意支持產品的普及化。

創造甜蜜點，才是產品成長的機會

我們有個在中國大陸的服務，就是將一些醫療設備的訂單線上化，在開發之前，全中國的醫院還是用紙本傳真的方式向我們的客戶下訂單，即使已經到了2018年，耳聞中國多麼先進的情況下，醫院仍然用著最陽春的方式在做商品買賣的事。

直到訂單傳真出錯頻率太高，醫院相關承辦人員過於忙碌，導致沒有時間手動的應付採購設備的事務，所以在各方支持下，才把設備採購的事務全部改為手機網頁操作，也大量減少訂單出錯的情況。訂單出錯在台灣聽起來也許是小事，大不了就是回收重送，可能半天就搞定了，但在幅員廣大的中國，送錯一個貨，就得兩、三天才有辦法回收重送，成本也是台灣的好幾倍。

如果現在要一個人生存在沒有網路的世界，確實是相當痛苦的，因為我們早已習慣網路帶來的便利，沒辦法再走回頭路，套句連續劇最有名的台詞，就是──回不去了！若現在忽然沒了臉書或Line，相信有很多人會痛到不行，這種狀況的「痛點」，我認為就是被創造出來的，它是利用人的依賴感創造出來的痛。不過對於許多創新服務，其實是不存在的，真要追逐新創服務的痛點，其實有很多答案是漏洞百出的。

因此當我聽到別人在做產品時，都會盡量避免去詢問對方這產品在解決什麼痛點；反之，我會想知道你打算怎麼創造甜蜜點。當有一群人在某個時刻很願意用你的服務，自然就會慢慢影響身邊的人，如同病毒一般散播出去，這才是產品成長的機會。

※ 本文摘自《軟體專案管理的7道難題》，原篇名為〈PM的核心永遠是管理大過於執行〉＆〈如何尋找最佳平衡點〉＆〈創造甜蜜點，才是產品成長的機會〉，立即前往試讀►►►