這幾天和同事聊到一個狀況，就是要不要去協助別人，做不是自己分內該做的事情？假設情況是這樣的，我們是一個遊戲的開發團隊，到底需不需要介入營運團隊的經營？
其實，在遊戲的生命週期上，大致可以分成兩個階段【開發】和【營運】，而不管【開發階段】還是【營運階段】，都需要研發單位和營運單位的合作，才有辦法做出一個遊戲，通常只要兩邊沒辦法好好合作的團隊，不管遊戲在怎麼好，最後應該都會死掉。
在【開發階段】，應該是由研發單位為主，營運單位提共外部的建議、市場分析、玩家的喜好，讓研發單位去進行開發；而【營運階段】，則會是營運單位為主，研發單位轉為支援的角色，協助進行功能的更新、體驗的優化、系統的改良，但是，說說總是簡單的~
不同的單位，立場不同、想法不同、經驗也不同，要可以互相協助，10個團隊可能只有1個團隊做的到，起碼過去我參與過的專案，經常性都是在吵架中度過的，這幾年倒是好很多了，畢竟也受過很多傷了，哈哈。
大約在6年前，我從某間待了6年的遊戲開發公司離開後，心裡總想著，研發和營運為什麼總是會意見不合，於是我就決定要跑去營運單位學習，畢竟一直在研發單位，會有種被封閉住的感覺，這也開啟了我廣度學習的道路。
後來進到一間蠻老牌的公司工作，也順利進去營運單位，但是那個時候其實算是輔助的角色，協助營運的同事，讓他們理解要如何提出一個可以讓研發單位接受的需求，因為要完成一個項目，基本上就必須要先理解【系統的運作】，所以，在提出需求時，除了要提供需求說明，更重要的是【介面設計】、【操作流程】、【資料庫需求】，因為營運經常性會提出比較天馬行空的需求，研發就會常常說做不到、辦不到，營運根本就無法理解為什麼做不到，而研發就會經常抱怨營運提的需求太鳥…，所以爭吵不斷。我也是在那段時間親身感受到營運對研發的不滿，和無法理解的地方，現在也才能從更高的角度去思考。
其實，原因很簡單，雙方的經驗能力、專業知識，並沒有交會，也難怪爭吵不斷。之後組建團隊的時候，我就會盡量讓團隊是多元的，絕對不會只有研發人員。
在那之後，開始思考一個產品真的要成功，產品的負責人還真的是必須要什麼都知道，即使沒有到專業級別，也要有辨識哪一位的深度較足的能力。一個產品的產生，應該都會經歷過下列的階段：
發想→提案→設計→開發→運營→行銷→銷售→客服
在規模不是很大的公司，基本上
研發會負責： 發想→提案→設計→開發 ，核心負責人是專案經理
營運會負責： 運營→行銷→銷售→客服 ，核心負責人是產品經理
兩個都叫做PM，但是負責的項目天差地遠
不過，這只是我過去的經驗的切分，依據不同產業可能會有所不同
但是在現在團隊規模越來越小的環境，其實已經沒辦法切分的越來越清楚了，因為真正第一線接觸市場的是產品經理，專案經理並不完全站在前線作戰，所以專案經理要如何明白市場現在需要的、目前的市場缺口，或是具有顛覆市場的前瞻性產品？而產品經理，即便有洞悉市場的能力，要如何讓研發同仁相信他的眼光是獨到的，有機會的，是可以做出來的？
漸漸的，由其是這幾年，產品經理與專案經理的界線已經越來越模糊，甚至已經開始高度重疊的現象。回來思考一開始的問題，如果你只想要安穩的做一份工作，當然可以選擇做好份內的事就好，如果希望產品可以成功，多多參與營運的經營，會更容易理解他們需要的是什麼，也可以跟他們解釋，在技術面上，有哪些東西是做不到的。不過，這個的前提是專案經理本身必須具備研發的專業知識，我也看過很多專案經理就只是會排甘特圖，並不理解專案開發的內容，那樣的專案通常也會死的很快。
《好書推薦》
書名：穀倉效應
這本書其實蠻有趣的，有提到說為什麼SONY，這幾年的表現這麼的不太好，曾經的家電用品霸主，怎麼搞成這副德性，在職場上，也經常性的看到許多高階主管都一直在實踐書中提到的狀況，其實真的還蠻有趣的，笑。(當然也是時時在警惕自己)
在職場中看的越透徹，往往有更多的時間多做準備，我自己經常講的一句話，「永遠要比老闆多想一步」，要做到這個，就必須要更廣泛的閱讀，在商業道路上，才會走的比較踏實。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
留言