記得前幾個月，在網路上看到一篇分享Google面試產品經理的文章《前進矽谷：Google 產品經理面試流程 & 策略》，裡面有提到Google面試會有技術相關內容，其中就包含了「系統設計」和「演算法」。畢竟，Google是科技公司的，要在Google這樣的公司任職，確實需要一些技術的知識。
前陣子，上了一門《大人學》的線上課程，叫做《用經營公司的思維經營你的人生》，裡面有提到「核心技能」的概念，簡單說就是「能把事情做好的必要能力」。看起來好像很具體，其實還是蠻抽象的。為什麼會提到這件事情呢？
事實上是這樣子的，還記得剛進入遊戲業的時候，一開始雖然負責的工作就是寫寫任務、設計關卡，很單純地當一個遊戲企劃，大概任務寫了三個月後就開始接觸系統設計，那時候有意識到一件事，就是我寫的「系統規格書」和其他企畫寫的「似乎不一樣」。但是，還不知道差在哪邊。直到有一次，公司安排了一次內訓課程，內容是「資料庫」。才驚覺，原來「資料庫」不是大家都懂的東西。因為我大學唸的科系是資管系，對於資料庫的概念並不陌生，所以，接觸到遊戲開發時的資料庫設計，不會覺得難以理解，甚至覺得理所當然。可是，對於其他遊戲企畫，似乎只有少數幾個人才能理解。後來，才知道，原來這樣的遊戲企劃是「系統企劃」。
之後輾轉在幾間遊戲公司任職，漸漸發現，原來懂「系統設計」的遊戲企劃，其實並不多。即便是遊戲製作人，對於「系統」的了解也不是太深。當然，後來有認識一些業界的朋友，也是有懂非常多「系統開發」的產品經理或專案經理，但是這些是少數，普遍是相對不熟悉的。對於，沒有技術知識背景，卻想接觸「軟體、網站或遊戲」相關產業的產品經理或專案經理們，「系統設計」就會是一個很大的門檻。
在網站平台與遊戲開發產業打滾的這些年，也大概知道了一些產品經理或專案經理，所需具備的必要知識，其實也就是工程師幾乎會天天說的東西。但是，第一次聽到這些名詞的同事，都會呆在那邊，然後就不知所措。像是「前台、後台、前端、後端」、或是「長連線、短連線」、或是「API、Token、IP、Port、Host」..等。每次討論系統開發時，都會一直反覆出現這些名詞。
後來，在招募新人的時候，都會在面試時偷偷問一下面試者，對於「前台、後台、前端、後端」有沒有概念，會怎麼去區分，或是知不知道資料庫的功用是什麼？很意外的，大部分面試產品經理的人都講不太出來，即便有5-6年的工作資歷，也是答不太出來。甚至，有些宣稱可以協助針對資料庫撈取資料的產品經理，對於資料庫設計的概念卻不是很懂，後來追問下，撈資料這件事原來是工程師有提供工具，負責執行指令而已，這樣也不能算是對資料庫有概念。
在遊戲產業的時候，遊戲企劃的工作之一，是設定遊戲的數值參數，由於開發遊戲的過程中未必會有工具或後台可以讓遊戲企劃進行設定，通常都會是使用Excel進行參數的設定，之後才匯入資料庫，而大部分的遊戲企劃，根本不知道這些可以填參數的Excel是怎麼產生的，只知道如何編輯這些Excel，更別說是設計這些資料表。
之後，就一直在思考一件事情，「產品經理或專案經理的核心技能，究竟是什麼？」，以往會覺得產品經理的核心能力是「產品設計能力」，專案經理的核心能力是「專案管理能力」。事實上，好像不太是這樣。這些年持續上了一些課程，看了一些文章，閱讀一些書籍，最後，看到《前進矽谷：Google 產品經理面試流程 & 策略》這篇文章，於是恍然大悟，因為我所處的領域是軟體、網站及遊戲開發相關的領域，而這個領域的產品經理或專案經理的核心技能，不就應該是「系統設計」嗎？不懂系統設計，如何和工程師溝通，不懂系統設計，如何第一時間就理解客戶的需求？
追根究柢，為什麼產品經理或專案經理和工程師在溝通的時候，常常不是那麼的順利？當產品經理或專案經理在描述客戶需求的時候，往往是「聽了三分、理解三分、腦補四分」，於是講出來的需求就很容易被工程師們打槍，工程師當然也會說明原因，比如說「目前架構做不到」、「要改底層很麻煩」、「這個要長連線，我們是短連線」、「這要改資料庫，現在沒辦法弄」，產品經理或專案經理聽到這邊就矇了，其實工程師講得很清楚，但是產品經理或專案經理就是Get不到，怎麼辦？而且，還要去和客戶說明呢。
這樣的狀況，是軟體、網站及遊戲開發的日常。工程師也不是故意要刁難產品經理或專案經理。只是產品經理或專案經理常常被弄得一頭霧水罷了，因為不懂工程師在說什麼。
這時候就需要好好思考「軟體業的產品經理或專案經理的核心技能，究竟是什麼？」，以我在自己軟體、網站及遊戲產業打滾了17年的經驗來看，最根本的核心技能，就是「系統分析與設計」及「資料庫設計」。
為什麼這麼說？
在台灣不管是產品經理或是專案經理，往往都是肩負「需求端」和「研發端」的溝通橋樑。
需求端：老闆、客戶、主管…等
研發端：設計、前端工程師、後端工程師、測試工程師…等
一般的溝通流程：
Step1. 理解需求：產品經理或專案經理，與需求端進行需求的確認，因為此時的產品經理或專案經理並不具備系統分析與設計的能力，在此階段必須理解老闆或客戶的需求。
Step2.確認需求的可行性：產品經理或專案經理，在此階段需要帶著理解後的需求，和研發團隊進行討論，確認該需求是否可以做到，及預計完成的時程與報價
Step3. 說明需求可行性、時程與報價：此時產品經理或專案經理必須與老闆說明，需求是否可以做到，及預計的時程與人力，若是對象為客戶，則會需要說明所需的費用。
通常在「 說明需求可行性、時程與報價」階段，往往會發現客戶或老闆的需求，無法100%的實現，而需要進行需求的調整與變更，而變更後的方案，也未必是客戶或老闆願意接受的，於是在這個階段通常都會花上許多時間。而這個階段的時間也都是無形的潛在成本，尤其此階段未必已經和客戶簽約，也還沒收到款項，可是卻已經花上不少時間在確認需求上，這些也都是團隊的成本。
具備系統分析能力時的溝通流程：
Step1. 確認需求可行性：當產品經理與專案經理具備系統分析能力時，在客戶及老闆提需求時，就可以第一時間確認需求，並討論如何實現，若是無法實現時，也可在當下討論替代方案。
Step2. 確認需求與開發時程：當產品經理與專案經理已經和客戶及老闆確認需求後，因為已經知道系統該如何設計，前端、後端的功能需求及資料庫的設計都有一定的雛型，與研發團隊討論的就剩下細部的規則確認，及預計的開發時程。
Step3. 確認時程與報價：由於需求已經在第一階段有了共識，且具備可行性，在此階段就會剩下討論時程與所需的成本，若時程太長或報價過高，也可在此階段直接進行議價，或是討論某些功能不進行開發。也因為產品經理與專案經理具備系統分析能力，也可直接判斷，移除那些功能對於系統架構的影響較小。
當然，你也可能會說，在確認需求時都帶上工程師，不就好了。這樣工程師也可以直接確認需求是否可以做到阿。別忘了，工程師的語言不是一般人可以理解的，當工程師在討論時說了很多技術術語，客戶和老闆也是會被搞得一蹋糊塗，這時候還是需要產品經理或專案經理協助進行「翻譯」。
尤其這些年，看到一些朋友從客服轉產品經理或專案經理，營運轉產品經理或專案經理，都覺得好像當產品經理或專案經理只是管管時程、派派工作，以為都能勝任。但是，都在「需求確認」這一關陣亡，把自己卡在老闆、客戶與研發團隊之間，裡外不是人，最後總是烙下一句「這是老闆要的」，然後就和研發團隊吵翻天。而「需求確認」只是PM這個職位的第一道關卡。
後來漸漸明白，原來「系統分析與設計」才是讓產品經理或專案經理，在軟體業活下來的「核心技能」。
「懂系統分析與設計不只讓你活下去，更讓你無往不利!!」
大家好，我是HeroMi，從事多年的遊戲及軟體專案開發，親身經歷大大小小專案開發的戰場，希望透過經驗分享，讓我們一起學習成長。
*本站所有文章未經授權，請勿任意利用、引用、轉載。
留言