Search
之前有棵香草，用左個新account PM我，問我關於求職的問題。
由於那個係新account，我諗我覆左佢都未必記得check，橫掂寫開長文，就不如post上Patreon免費公開吧。
呢個係我搵工嘅心得，條條大路通羅馬，我通唔代表你一定行得到，但起碼可以作為參考。
大家加油，兄弟爬山，你黎到英國我當然拉你一把！
#平時我會建議立定志向再發展技能樹
#但依家有飯開先再講其他啦
感謝大家週二參與<<行銷與工程的迴路考驗2：行銷技能樹與產品專案的眉眉角角 Come on>>😁😁😁
還記得當天講師所分享的一些內容嗎?
在這幫大家稍微複習一下
#KM__17直播前產品經理
✍️如何運用德爾菲法（Delphi method）來思考產品的問題、以及在大型專案上又是如何運用Scrum來進行會議！
✍️建議不要在負責data的人面前講太量化數據，反而是把你所想要的情境描述的更為清楚會有助於data Team 幫助我們找到更好的數據、或是更為精準的指標。
#Zac__行銷工程經理人
✍️分享關於行銷人所需具備技能
✍️區分為分析優化、流量獲取、技術認知、工具應用四大項以及關於Product Marketing& Product Marketing兩者間差別
#Steven__愛碼市智能科技PM
✍️分享了對於風險管理的定義、控管-做產品就是要去冒險的
✍️團隊管理-如何讓團隊信任你、相信你的決定
站在舞臺上分享成功經驗的人從沒少過，而願意分享真實失敗經驗的人卻不多。
成功人士所歸咎的成功往往不超過十種，包括了：「愛、熱情、專注與投入」等等。
但失敗的原因卻有千萬種。
--------以下引用原文--------
【那一年，我當遊戲PM的失敗與反省】
就像之前寫2019 GDC失敗經驗大會時中所講到，這個世界雖然充滿了成功的案例，但事實上是由失敗所組成的。我們看業界的各種文章，很少人講到各種的失敗經驗，這一篇就來拋磚引玉的聊一下從業十多年一些失敗經驗，包含操作案例與職場體會，也許對大家會有些幫助借鏡之用。
我自己的職涯，是從遊戲產品PM經歷開始做起，因此請各自斟酌服用吧: )
--
●做活動對於不同玩家的需求差異毫無概念
我在當遊戲PM時的第一個活動，是設計每位玩家的登入、買道具、儲值可以獲得各種不同的積分卷，這些積分卷累積起來後的積分，會以伺服器為單位作服與服之間的競賽，第一名的伺服器可以獲得全服經驗值加倍七天與特定獎勵。
這個活動最大的問題是，當時的我，沒有認知每個玩家對於獎勵的需求都不同，並且高估了玩家對於自己服的使命感。當時所設計的獎勵只對於一般非付費玩家有刺激，主要是因為要讓每位玩家都獲得，很難把獎勵設計得太好，但這樣對於大戶玩家來說，吸引力並不大。
因此這個活動耗費了很多程式人力，但對於收入的幫助非常微小，這是我進入職場的第一個失敗經驗。
後來做所有活動時，就會自動在腦中對所有玩家進行各種分類，確認每位玩家的需求在哪，一直影響我至今。
--
●忽略遊戲測試時的盲點
作為發行，很重要的工作就是尋找好的遊戲產品來發行。菜鳥PM時要評估代理某個遊戲時，雖然該遊戲新手階段非常難熬，但為了要完成公司的任務，還是耐著性子玩了下去，玩了一個小時之後開始玩出樂趣，並且發現遊戲有許多機制上的亮光點，興奮之下寫了一個報告給公司推薦代理。公司也很開心的代理了那款遊戲。
結果，產品上市後大部分玩家死在了新手階段。就是我最難熬的那一小時。
作為發行，遊戲測試是最重要的一塊業務，因為幾乎80%的成功與否都會在簽下產品的那一刻決定。行銷與營運對於大部份的產品影響力度很低。從那次經驗以後，測試任何的遊戲，我都會有意識的關注自己從進入遊戲開始每一秒心理狀態的變化，並反思玩家是否也會有類似的感覺產生。
要隨時玩進去，又要隨時抽離審視自己，這是我認為做所有產品測試都要有的心理狀態。
--
●空有想法，但對於市場的「標準」審美無所知。
當時做了一款卡牌遊戲，心理想著自己也能設計了一套規則做成實體卡牌，配合遊戲上市一起推出，能對用戶有虛實整合的感覺。還很熱血的找了一些玩家試玩，前前後後弄了幾個月以失敗告終。
現在回想起來，那套卡牌不管是遊戲規則的設計，卡牌的精緻程度，印刷的精細度和市場上都有一定差距，就是自己熱血青春下的產物。
因此，在嘗試任何一項作法或策略時，先調查這項作法"影響最大的關鍵成功因素"為何? 是簡單的玩法、還是充滿力量的IP、亦或是精美的卡面?市場的標準在哪裡? 如何能用最小的成本做出嘗試?
在充滿熱血之前先問自己這些事情，腦袋會清楚一點。
--
●不要陷於眼前而忘卻長期規劃
當PM做到一定年資後，需要做的事情越來越多，開始每天都是滿檔並加班到十點以後的狀態，當時每天都像在打仗，有一次開會完同事問我："疑，這好像跟我們當初與玩家的行為模式設定越走越遠了。"
這時才突然發現，自己已經陷在各種緊急事項的泥沼，而顧不得規劃真正的產品營運策略了。
有時候"忙"這件事情是對自己潛意識的催眠，以為這樣才對得起工作所承擔的責任。事實上，適度的休息與放空，冷靜思考工作優先順序，效率才能達到最高。
不要為了表現自己很努力而忙，這對事情沒有任何的幫助。每天要安排一小段時間放下手邊工作，來去思考什麼是現在最重要的事情，什麼是現在還需要去補的洞，隨時抽離現實的泥沼，審視自己工作的狀態，這才是最重要的。
PS.聽起來也蠻像測產品時的心理狀態XD。
--
●瞧不起交際應酬與甘於當宅男
在台灣當遊戲PM的不知道為什麼，都有一種"好好努力在公司做事情，少去外面交際應酬"才是正途的價值觀。我在工作的前幾年左右也是這樣，每次老闆說要帶我去應酬接待廠商都找各種理由不想去，後來當主管所帶的PM大多也是，叫人一起跟原廠或同業吃飯臉就好像進刑場一樣難受。
埋頭苦幹的人往往會忽略「資訊交流」的重要性。當你的思考模式與體系已經固化時，沒有受到外力的衝擊，進步與變化的可能性就會變少。尤其遊戲業有的時候"就是比誰多知道一點事情的地方。"
這件事情讓我體驗最深的，就是當有一次公司產品出現某個技術問題，我花了幾個小時查國內外的資料時，一個天天應酬的同事打了電話給別的公司技術長，五分鐘之內得到解決方法，簡直不能太輕鬆寫意。
「業務能力」是一種非常有價值的才能，越早進行磨練越好。能夠找到重要的情報來源，形成自己的情報交流網非常重要。只要你等級越高，打高級副本時就更需要這項能力，因為你會不斷的觸碰未知的領域。
所以要對看起來只會出一張嘴的人懷有尊敬，這是一種很厲害的能力，這條技能樹可是又深又長，能附加的能力值與屬性可不少。(當然有些時候這類人要敬而遠之就是)
--
以上是我總結這些年做PM的一些失敗經驗與反省，年輕時總會有各種自以為是的想法(雖然現在可能也...)，不怕失敗是那時候最大的資本，每次拚搏之時，腦袋都會浮現幕之內一步的身影與館長所說的話。
「努力雖然不一定有回報，但所有成功的人都是通過努力而來的。」
現在的我會再加個附註：不要沉溺於努力，冷靜的反省與審視自我也很重要。
希望以上對你有幫助。
#老王賣瓜自賣自誇系列
#聊聊你的失敗經驗吧
#No77
#所以幕之內到底是要打多久
相隔12年重製的終極紅寶石精華來囉！
怎麼會遇到這種事我也真是太意外XD
雖然已經忘記大部分，但玩起來還是讓人懷念又感動
希望這次的影片能為你帶來歡笑:))
菜喳FB：http://facebook.com/zynxyz
實況台：http://twitch.tv/zynxyz
繁星FB：http://facebook.com/StarsRabbit
啊晋FB：http://facebook.com/oeurXstudio
魚乾FB：http://facebook.com/RedStone.Poke
Kouku FB：http://facebook.com/oeurXstudio
========以下註釋========
註釋1 秘傳機 跟一般技能不同，某些道路需要用秘傳技能才能前進，砍倒擋路的樹是經典例子
註釋2 宿敵，歷代作品都會配有一個跟著玩家進度成長的"鄰居"，通常碰到宿敵後對方都會要求跟玩家進行對戰
註釋3 技能
あまえる，撒嬌：令目標的攻擊降低2級。
なきごえ，吼叫：令目標的攻擊降低1級。
しっぽをふる，搖尾巴：令目標的防禦降低1級。
すなかけ，飛沙腳：令目標的命中降低1級。
註釋4 鯉魚王，15級前的鯉魚王只有一招毫無用處的水濺躍(彈跳)
註釋5 PP(Power points)，是一個技能可以被使用的次數。
註釋6 嚴格來說應叫"掙扎"，是所有技能的PP均為0時剩餘的技能：攻擊對手造成無屬性的傷害。自身損傷最大HP的1⁄4。
註釋7 遊戲不允許捕捉訓練家的神奇寶貝，對方會將神奇寶貝球彈開
註釋8 POE，不解釋，詳見：http://ppt.cc/NAUi
以上部分資訊來自神奇寶貝百科http://wiki.52poke.com/
產品經理(PM)職涯發展【技能樹】如何解鎖?? PM要負責產品生命週期，從來就不是一件容易的事。 PM需要擁有產品管理基本能力、市場分析能力、溝通與團隊合作 ... ... <看更多>
... 變強之路】 (只要訂閱就會先拿到Evonne 對於產品經理職涯發展趨勢的看法與職缺 技能樹 拆解的簡報) 電子報訂閱連結：https://bizthinkers.com/ivQIj ... ... <看更多>
pm技能樹 在 [討論] 產品經理(PM)需要懂技術嗎？ - 看板Soft_Job 的美食出口停車場
月經文來著。
我兩年前曾經在板上問過這個問題，
偶爾也會有人站內信找我討論，
所以就寫了一篇文章分享自己的想法、跟大家交流交流～～～
Medium 有圖有參考連結好讀版：
https://pse.is/3hk2n9
懂技術當然比不懂技術好，上知天文下知地理當然比什麼都不懂好。而會有人不斷討論這個問題的原因大概分為兩個層面：
1. 想要轉職，不知道技術知識到什麼程度才能找到產品經理的工作機會
2. 已在職中，身為 PM 不確定自己技術知識夠不夠，還能朝哪些方面加強
將問題拆解後，我們背後真正想問的是：
- 若要成為一個及格的產品經理，對技術的了解要有多少？
- 產品經理有那麼多種技能要點，技術在這所有技能中有多重要？
- 為了轉職/為了職涯發展/為了讓工作與溝通更順暢，我應該優先補足技術知識、還是精進其他技能？
【文章目錄】
- 產品經理什麼時候會用到技術知識？
- 所謂的「懂技術」是什麼意思？溝通技術的不同層次
- 怎樣才算是夠懂技術了？
- 如何跟工程師合作？
- 結語：產品經理技能樹
這邊先長話短說、下個小結，一般來說：
PM 對技術的理解，要足夠跟工程師溝通、安排資源、解決問題。
也跟工程師們喊話下：
你的 PM 亂答應需求、亂訂時程不一定是因為他不懂技術，
有可能只是因為他不懂得溝通與拒絕的藝術。
▍產品經理什麼時候會用到技術知識？
目標：加速產品開發、確保團隊在往對的方向前進
有技術知識的 PM 能夠：
- 了解產品的核心技術競爭力，對於在做的產品有正確的認識
- 分辨市場上其他競品強不強，是強在技術還是其他地方
- 在做產品決策、優先級排序、規劃與協調資源時更順利
- 跟工程師與技術單位溝通時更順暢
擁有技術知識，讓 PM 在以下工作階段更順利
- 研究問題、討論解法、優先級排序（需求方、使用者、客戶）
- 資源安排＆實作（設計師、工程師）
- 處理緊急 issues（整個團隊）
寫程式不是 PM 的工作！
有些人會有個迷思，好像 PM 必須要會寫程式才能做好自己的工作。
問了一些工程師朋友和同事，PM 的技術能力要到什麼程度？他們的答案是「可以跟工程師溝通就 OK」「了解技術限制、複雜度、成本之類的就很棒了」「不會寫程式沒什麼關係啊」「寫程式是我們的工作吧！」
如果你覺得學會寫程式就能成為一個好的產品經理，那我會說你只是在偷懶而已。
擁有技術知識、懂產品背後的邏輯，並不代表你自己需要會寫程式。會寫程式當然很好，能更懂行話、也對跟工程師溝通有幫助，但與其自己實際練習寫程式，我會寧願花時間在其他地方。
▍懂技術是什麼意思？懂技術的不同層次
PM 不用知道如何寫程式，但要知道產品背後的邏輯與技術限制。
技術知識要能輸出成為「理解能力」與「溝通能力」兩個方面才有用：聽得懂是第一步，能夠參與討論是第二步，有能力做出合理的判斷是終極目標。
我將技術知識含量多寡以及能達到的成果分成以下幾種類別。
【高】技術知識作為決策的一環
- 跟需求方討論時，可以判斷做不做得到、難易度如何、可能遇到的問題
- 排序產品與問題優先級時，能精準的將技術複雜度作為一個維度來參考
- 能夠將核心技術轉化成產品的核心競爭力之一
- 能夠從頭參與新產品、新服務的討論，包含選擇什麼技術來實作、資料庫架構的欄位與內容、是否要找第三方的服務來串接
- 了解技術團隊使用的外部服務（AWS、Sentry、CircleCI）的成本
- 了解什麼是正確的時機 refactor、解決技術債（Tech Debt）、Legacy Code 的問題
【中】良好的溝通媒介
- 接收需求時，能清楚釐清問題內容，以利後續跟技術團隊討論實作可行性跟時程
- 接收需求時，能判斷是否跟目前邏輯相違背、有沒有 dependencies 等
- 接收需求時，能描繪出改動的範圍大小，並向需求方建立正確的期待
- 討論產品解法時，能顧慮到技術限制、技術可行性
- 與技術團隊討論時，知道該問哪些問題、聽得懂對方的解釋、參與討論
- 遇到 issues 時，知道怎麼回報、怎麼重現 bug 並提出可能的原因
- 若需要跟第三方服務或客戶串接，要看得懂技術文件，或至少知道哪一部分需要跟技術團隊確認
- 在寫產品文件時，能將部分技術規格也納入其中，並搭配工程師的 Techical Spec
【初】基礎中的基礎
- 了解最基本的網路產品如何運作
- Daily Standup 時聽得懂工程師說明他在做的事、遇到的困難
- 遇到問題時不會問錯人！前端、後端、Data Team 的工作範圍都不同；就算都是後端，他們負責跟維護的部分可能也不同，要能判斷這塊需求或問題要問誰才對
- 能夠和工程師一起處理 issues & bugs
【零分】能力不足
- 聽不懂工程師說的技術名詞卻也不會問
- 不懂得釐清需求方的問題，要來來回回問工程師很多次
- 工程師回覆之後也無法好好解釋給需求方，讓需求方了解技術限制或 bug 發生的原因
- 規劃產品時沒考慮到技術問題，也沒諮詢過技術團隊
【哎呀扣分】懂技術不是讓你用來不尊重專業意見的
最忌諱的就是 PM 覺得自己懂點技術，所以就不尊重工程師的專業意見，因此自己壓時程、亂答應、質疑工程師的判斷。
有時候一個乍看很簡單的東西，可能會因為自家產品背後混亂的 codebase 而變得難以實作，或是需要先進行 refactoring 才有辦法開始開發。
每一間公司、每一個產品都會有不一樣的狀況，因此不要輕視彼此的專業、不要幫對方做決定，大家在能力上應該是互補的關係，而懂對方的語言的目的只是為了讓內部溝通更順暢。
另一種狀況是 PM 太過關注技術複雜性。我曾經因為覺得某個東西技術上應該很難實作，所以就自作主張推掉需求，但後來才發現其實工程師能夠想到其他很好的技術解法，這就是自以為懂技術的糟糕心態。
應該說，每個人各司其職、為自己的位置與角色發聲才是最好的平衡。我不應該過度幫工程師擔心技術的事情，而是應該帶著我身為 PM 的想法與立場去溝通與搜集專業意見，同時設定好雙方的期待。
PM 很常需要在中間當協調人或決策者，勢必要能夠聽懂別人說的話、了解別人在意的事情，但不是取代其他專業同事應該要做的事。
【翻譯蒟蒻】除了跟行內的人溝通，還要能夠解釋給外行人聽
當老闆、業務、客服問 PM 為什麼這個做不到、為什麼會發生這些 issues，你能不能用很簡單的邏輯與案例解釋給他聽？
當一個產品需求會被拒絕，有時候是需求本身不合理、有時候是設計上的難題、有時候是技術上的限制，PM 在接收需求的時候心中就要做簡單的分析，知道這些問題該問誰、問完之後有哪些因素影響團隊做決定（做或不做、優先級如何），跟產品團隊討論完後再回去找需求方溝通。
遇到 issues 的時候也一樣，PM 就像一台翻譯機，客服回報問題，PM 整理好問題影響範圍、重現方式並翻譯成技術語言給工程師聽；工程師找到問題後告訴 PM 背後的根本原因和可能的解決方案、PM 再翻譯回去給客服聽，討論該如何跟客戶或使用者溝通。
最後是關於一些常見的技術問題，團隊應該要建立起共同的知識資料庫，避免一樣的問答不斷重複發生。PM 總是幫忙工程師回答問題也不是辦法，文件化並分享知識給同事才是最有效率的作法。
▍怎樣才算是夠懂技術了？
標準答案：看公司！看團隊！
1. 最基本的技術知識
延續上面提到的技術與溝通等級，對新手 PM 來說，有【初】基礎中的基礎就不錯了，其中的了解網路產品如何運作包含理解以下名詞：
Backend、Frontend
Server、Client、Cloud、DNS
Database、SQL
FTP、API
Cache、Cookies、Session
Container、Docker、GitHub、CI/CD、Deployment
會使用 Browser DevTools 並大概知道每個區塊的作用
2. 技能對應到工作需求
有些公司裡面會有 Technical PM (TPM)、System Architect (SA)、Delivery Manager (DM) 的角色，在這些團隊內他們會吃下很多技術相關的工作，一般 PM 對於技術知識的理解與溝通可以透過他們來協助。
但另外一些公司則可能會希望 PM 擁有一定的技術知識與背景，所以真正的問題是，我需要多少的技術知識，才能支撐我做好在這間公司、這個產品的產品工作。在面試前可以先：
- 了解這間公司的技術架構，在使用的服務等等
- 找該公司的工程師或其他職位的 JD 來看，是否懂裡面所有的專有名詞
- 搜尋該公司的 PM 面試題目，看看是否有技術相關題目
Ref: IGotAnOffer — Product manager interview questions (the ultimate list)
如果面試的時候有跟工程師對到，在問問題階段也可以反問他們對於 PM 的技術能力的要求與期待是什麼。如果你想進去的產業跟公司的產品技術含量高，技術背景就會是標準配備。
而每間公司、每個產品的程式架構都不一樣，使用的服務、背後的邏輯也不盡相同，到了新的團隊或換新產品的時候都需要重新學習跟理解。
在《產品經理就職手冊：抓住四大學習重點，讓你快速進入狀況》中有提到，剛入職時可以請工程師帶著 PM 了解目前產品的技術架構和 Tech Roadmap。
若產品經理了解技術架構與限制，也會多少對判斷 Dependency 與了解可能的技術坑有幫助。針對這點可以請工程師跟你說明目前是使用什麼 Tech stack、前後端如何互相呼叫、有哪些主要的 API / Service / Database，以及我們是否跟其他團隊在技術層面會有高度合作關係等等。
3. 基本的撈資料、分析能力
一樣根據工作所需，有些基本的撈資料、分析是 PM 會自己做的：
- 用 SQL 撈資料（知道資料庫裡有哪些欄位、怎麼存資料、關聯性為何）
- 用 Crawler 爬資料
- 埋點、分析 Events、A/B Testing
▍如何跟工程師合作？
有的時候技術問題很複雜、或是程式過去是很多人共同在維護，技術知識學海無涯，工程師本人也不一定隨時都知道技術問題的答案，可能會需要先花時間去看一下、研究一下才能跟你討論。因此問問題與合作時先做功課、虛心請教、給對方足夠的時間研究也是很重要的。
執行細節歡迎參考我們過去的文章：
【PM夥伴攻略】如何跟工程師合作？
【PM夥伴攻略】番外篇：工程師雷區幹話大全
【PM夥伴攻略】如何與工程主管 Engineer Manager 合作？
▍結語：產品經理技能樹
在 《從入門到卓越，產品經理技能檢核表與職涯發展路徑》中提到的「Technical Sense — 對技術理解的能力」主要集中在 Senior PM 的職涯階段。不過在這個產業工作，多瞭解點技術相關知識總還是非常有幫助的。
做產品就是在商業價值、使用者體驗、技術之間取得平衡，三種技能一定都會點到，但每個 PM 的興趣和專長都不同，長遠的職涯發展朝向不同方向，相對應所需的知識和技能就會有所不同。
最重要的是，PM 跟商業團隊、技術團隊、設計團隊其實合起來是一個全方位的產品團隊，大家做好份內的專業外，自己的能力能夠跟團隊成員互補、並持續進行知識交流是很重要的，大家要一起成長，才會變成更棒的產品團隊！
以上，歡迎 PM、工程師們一起來交流，
擁有什麼樣的技術知識才足夠成為及格的產品經理。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.162.152.200 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1625481555.A.131.html
※ 編輯: annedoo (1.162.152.200 臺灣), 07/05/2021 18:40:36
※ 編輯: annedoo (1.162.152.200 臺灣), 07/05/2021 18:42:00
... <看更多>