善用你的技術力，產品經理和工程師協作必須知道的事
- 沒有技術背景能夠當產品經理嗎？
- 沒有技術背景如何和工程師協作？
- 所以產品經理要會技術嗎？達到哪種程度才行？
以上大概是許多人一直都有的疑問。擁有技術背景讓我在團隊溝通及協作上有非常大的幫助，但產品經理最重要的並不是會「技術」這個技能，希望以下的資訊希望對你有些幫助。
目錄
清楚自己的定位
團隊裡的各個職務當中，RD 規劃技術架構、交付程式；UI/UX Designer 負責介面和流程設計，但產品經理絕對會參與一個產品從無到有的各個階段：
- 起初的收集需求、Persona、撰寫 Spec(BRD, MRD, PRD)
- 開發中各階段的任務優先排序
- 完成開發後的功能測試
以上部分省略，因為產品經理這個角色會因為你所待的公司、團隊而有所差異。
有些公司職務抬頭雖是產品經理，但實際上只是在管理專案，像是：排程、追進度，完全沒涉及到產品規劃。那需求怎來的？大部分都是老闆去看競品有哪些功能、和身邊朋友閒聊得到的資訊，最後再請公司的 PM 們直接去開發類似的功能服務。
這沒有對錯，也不要絕望(笑)，還是有公司的產品經理職務和工作內容是相吻合的，也有一些方式可以去做改變，產品經理不是只有做產品規劃而已，很多時候也需要懂得向上管理，最重要的是，必須清楚在團隊當中自己扮演的角色，以及工程師理想中的產品經理等。
除此之外，因應團隊不同的開發方式（Methodology）實際的交付流程也不同，像是 Agile/Scrum(敏捷式), Waterfall(瀑布式), Kanban(看板), 當然還有 Meteo Fall Development(隕石式開發) XD
這裡並沒有要討論哪一種方式比較好，或是什麼團隊才真正利於產品經理成長等等，只要能識別出需求、打造出解決客戶痛點並提供對應的服務，絕對有讓你成長的機會，而當中所要學習的東西、付出的代價，不是你能夠想像的！
Over-Communication（過度溝通）
過度溝通不是要你 Slack, Teams 上不斷地丟訊息給夥伴們，或是很白目的 嗨！在嗎？ 然後就沒有然後了 ..
而是業務講解完一個 Domain knowledge、RD 講解完一個技術架構後，再用自己的方式內化吸收說給對方聽；反過來今天產品經理在規劃產品確保技術的可行性時，不管你的 PRD, 簡報多麽清楚，在說明完之後 RD 們有沒有完全理解這個需求？
過程就像在打打乒乓球一樣，來來回回幾輪透過這樣的方式確認 Input, Output 確保大家的理解是一致的。
懂技術對產品經理有哪些幫助？
以下當作參考，實際還是要以團隊為主，產品是 App, Web, 硬體, 韌體？ 那技術架構還是有很大的差異。
PM 不用實際動手下去寫 Code 或是做一些技術上的決策，但至少要知道團隊的技術架構，因為 RD 之間一定會用「行話」去做溝通， 若知道相關的技術性名詞和 RD 溝通就不會有太多的隔閡，也會提升團隊對你的信任感。
關於技術面大概要知道哪些東西？以下可以當作參考：
- 團隊是用 MVC 的架構嗎？還是前後端分離呢？
- Front-end（前端）和 Back-end（後端）用哪些技術框架？
- RD 知道業務邏輯後是怎麼拆分 Component 的？彼此之間的 Dependency 多深？
- 如果要做 A/B Testing，技術團隊需要 PM 提供哪些東西呢？
- 團隊的開發流程是哪一種呢？有採用 Git Flow 嗎？
- 團隊是怎麼 Deploy(部署) 程式碼的？
- Git branch 怎麼開？
還有日常工作的問題一定要非常清楚，因為開發過程如果炸掉的話，出事也比較清楚該找誰協助：
- 團隊有沒有 Code Review 機制？
- 團隊都什麼時候上 Code？有沒有職務代理人？
- 如果我有技術問題是直接找 RD 嗎？還是找 Tech-lead 呢？
- 有哪些環境(DEV, SIT, UAT, PROD)？如果明天就要給客戶 Demo，環境都可以正常運作嗎？可以請 Back-end 先倒預設資料嗎？
－所以 PM 到底要不要「懂技術」？
想必是要的，但不是真正下去寫，而是當問題發生你知道問題的根源、該尋求哪些資源去解決問題！
當你了解技術架構不僅可以建立和技術團隊的信任感，知道技術的複雜度也利於擬定：
- 替代方案
- 風險評估等級
- 概算出開發時程
我也從實際經驗當中體悟到，重點不在於到底要不要有技術背景，而是保持學習的熱情，透過手上的資源去解決當前的問題。
RD 不是你的 UberEats
- 喂！那個東西壞了，你馬上改一下
- 我 RD 出身的所以我知道這很簡單，快去寫 Code 吧！
- 這很簡單吧？3 小時？ 4 小時？應該不用半天就好了！
- 你就 VS Code 打開，看是哪一段直接摳過去會動就好啦！
如果今天你和大家還不熟，或是你根本不知道同事的底線在哪裡，對 RD 說這些話應該不用活了，這也是為什麼很多公司老闆、RD 認為 PM 就是只會出一張嘴，又裝自己真的會技術，這種溝通方式完全是自殺式行為 🤬🤬🤬。
解決問題的能力是人人在生活、職場都必點的技能，隨著遇到的問題難度不斷提升，每次遇到棘手或沒處理過的問題都是在考驗著我們。
RD 能透過他的工程角度一步步剖析，透過技術解決當前的問題，如果真的、真的有任何狀況，就直接向 RD 大大們求救，有些狀況你不知道問題出在哪，不知道該找誰幫忙，在團隊的任何人看到應該會協助你才是。
另外會議的部分，對 PM 來說一整天下來可能有好幾場會議要參加，像是：
- 參與 UI/UX Designer 的 User Interview（用戶訪談）
- 收集 Stakeholder（利害關係人）對產品的想法
- 和 UI/UX Designer 確認設計稿及流程
還有太多太多寫不完 …
但如果今天 PM 約技術團隊好幾場會議，那不用一個禮拜大家可能都不理你了，這就像有些夥伴總是在每封 Mail 附註 ASAP 一樣意思(笑)。
在需求上的協作，一定要盡可能確保 Spec, Task 是明確、齊全的情況下才和 RD 們敲定會議，或是內部有統一文件可以同步/非同步交流訊息也是方法之一。
－生命共同體，不斷和團隊更新訊息
團隊當中人人都是不可缺少的一部分，產品就是 PM 釐清用戶需求、設計師確保介面及流程以及工程師的技術所打造出來的結晶。
在開發之前的產品規劃期間讓 RD 緊密參與也有幾個好處：
- 對於設計稿有異議、技術可行性的問題能夠儘早提出並尋找其他的解決方式。
- 讓 RD 知道，透過他的精湛技術是要解決哪些真實的用戶需求，同時也灌輸產品思維給他們，和用戶建立同理心。
產品經理和 RD 之間的協作大大影響整個產品開發的有效性，除了自身的專業之外，懂一點人心，並不斷地維護彼此的信任也是同等重要的學習目標。
徵才方想要找「懂技術的產品經理」是什麼心態？
-
能夠協助團隊做技術決策
-
產品運用到比較新穎的技術（5G, AI, VR/AR, Blockchain）, 希望這位 PM 能夠知道這些：
- 技術底層的運作原理
- 技術能夠解決哪些問題
- 技術如何應用在商業層面
-
團隊 RD 還是 Junior 的程度，希望你在帶領團隊開發產品時，能在開發前自行判斷技術的可行性
目前我正在和團隊做一個公司未曾切入的領域的新產品，以上真的特別有感， 因為本身了解技術，在溝通上真的非常順暢，也能在規劃產品時預先想到技術面會遇到的問題。
不過也有可能是這些狀況，希望大家都不要遇到：
-
公司自己都不知道要找什麼樣的夥伴 （常見）
-
徵才方的主管懶得寫 JD, 請行政姊姊、人資主管幫忙寫 （常見）
-
想要凹產品經理做 PJM(Project Manager), TPM(Technical Project/Product Manager)該做的事（EX: 寫技術文件）
-
老闆在外面亂打聽，以為產品經理也要負責技術面的東西
-
產品的 技術債(Technical Debt) 太深，而這個問題起源可能是：
- 產品功能初期規劃不周又不斷地疊床架屋
- 團隊夥伴和歷屆 PM 完全忽視技術債對後續開發的影響（後續再和大家分享）
因此，需要一個會技術的 PM 來做一些 “人工智慧(Labor)“ 的廢屁事 🥲 🥲 🥲
如果因為技術債的問題不斷發生，那開發團隊交付新功能就會越來越難、越來越慢，因為 RD 需要在救火和開發新功能的工作之間分散他們的心力、注意力，這其實會間接打擊開發團隊士氣(那種氣氛真的很糟)，也對後續產品體驗產生負面影響。
－如何避免進入這樣的公司
這裡是我自己和讀書會朋友的一些經驗，當作參考就好
-
參加 Conf 和開發團隊成員閒聊
-
有人幫你內推，幫你引薦的人坦承讓你知道當前的狀況
-
面試多問、多聽，深入了解團隊到底存什麼心在找這個 Candidate
-
人資、高階主管不是要刻意隱瞞，而是自己也不知道技術衍伸的這些問題，面試時可以和資深工程師、技術主管聊聊
－從徵才方思考長遠發展
如果今天是徵才方，應該好好想想，找一個不適任（你們環境不適合他）的人，時間和金錢成本真的划得來嗎？
把公司當成是自己開的，這時候我們的思考就會以長期發展的角度來找適合彼此的人及環境。
公司到底是要找一個懂技術的 PM還是要找技術強且外向善於溝通的工程師？ 這問題值得我們好好去思考。
希望產品經理們都能夠找到自己喜歡的職務 💪🏾 💪🏾