團隊變形記（中）- 軟體產品經理的工具人自我養成計畫
不是開玩笑，飛機在往下掉，還有七秒鐘，你準備好了沒？樂觀一點，說不定你會飛。
- 夜貓組《墜機》我之前加入了一個從 20 人成長到近 200 人的團隊，經歷過第一階段的兵來將擋、水來土掩後，我們終於慢慢補齊各個團隊角色，PM 增加為 3–5 人、產品團隊 20 人，包含設計師、QA，工程師也從 Full Stack 分為專責 Backend, Frontend, DevOps 的角色。
除此之外，也投入更多 Customer Success 顧問協助教育客戶、蒐集回饋，Account Manager 會去挖掘大客戶需求、釐清問題，Marketing 團隊則正式接下公司官網優化的任務，分擔了不少工作！
我們在乎的事情變了！
此時，我們的產品已經在台灣市場做出一點成績，接下來的目標就是要獲取更多的使用者、依照現有使用者需求把產品功能開發的更完整強大，讓他們一直留在這裡。同時，我們在乎的事情也慢慢在改變：
- 工作流程分類更多元也更嚴謹，例如 BUG 追蹤、資源管理
- 團隊溝通更重要，要跟公司所有人溝通，而不是只有產品和工程團隊
- 願意撥一點點點點資源做 Code Refactoring 來避免疊床架屋、提高產品安全性與穩定性，方便未來產品擴張
為了因應這些改變，這篇要來討論我們如何利用工具來滿足新的工作需求。
對產品經理來說，知道積木怎麼堆，比自幹積木有用。
節錄自《第一份工作：KumaWash》by Eason Wu
這個階段的我們像是工具人上身，過去用 Excel 打天下的能力已經不敷使用，也很沒效率。挑選工具、快速上手、導入工作流程並協助其他團隊成員使用成為重要事項。
也幸好有許多有經驗的新成員從其他公司加入，讓我們可以第一線參考其他公司的作法。
直接進入業配主題
以下列舉的工具並沒有全部都被團隊採用喔～
早期用 Excel 就能達成大部份的目標，學習成本低是最大的優點；隨著團隊愈來愈大、資料愈來愈多、需求愈來愈複雜，我們開始自問：
1. 我想要達到什麼目的
2. 我願意付出多少成本
3. 有哪些工具可以幫助我更有效率的做事許多工具都有免費版本可試用，僅僅限制使用人數、資料量、功能量、使用時間等等，千萬不要先上車後補票、試車又忘了帶套、孩子出生了你也只能一起哇哇叫，等你都開始付這些工具年費才發現不合用就來不及了！
工具人自我養成計畫，現在開始！
對使用者的溝通 — Help Center & Release Notes
使用者開始使用產品後，更重要的是讓他願意繼續留下來。透過雙向溝通工具，我們可以更了解我們的使用者並即時解決問題。
一、降低產品學習門檻
客服團隊協助使用者排解問題、給予意見外，產品團隊同時也會建立完整的 Help Center （或稱 Knowledge Base, FAQ） 讓使用者隨時主動查找。
當然優化 onboarding 流程讓產品更容易上手也很重要，行銷部門針對不同使用情境寫的 Blog 文章也有很顯著的效果。
二、蒐集使用者回饋、持續優化
讓使用者感受到這是個持續在優化的產品，且優化的方向是符合他的需求，蒐集使用者給的功能建議是最簡單暴力的方式。這些工具通常有強大的 segmentation 功能幫助產品團隊分析不同類型使用者給的意見。
當產品開發到一個階段，也可以圈出一部分使用者來邀請他們做 beta 版本的測試者，快速蒐集回饋來迭代產品外，他們也會是口碑行銷的好幫手。
新功能全面上線時，我們會主動推播新功能給使用者，刷刷存在感並傳達最重要的訊息 — — 我的改變，你看得見。
三、培養信任感
除了上面幾種做法外，當系統即將有重大更新、遭遇 downtime 或被第三方服務商影響到時，也會使用 status.io 即時更新狀況。
對各團隊的溝通 — Product Roadmap & Prioritization
TOOL: ProductPlan, ProductBoard, Aha!, JIRA
如果看過上一篇文章，就會知道我們有很多功能性的 Slack channels，資訊也分散在各處。團隊成員變多後 PM 每天都快被這些問題煩死：
「欸！有BUG！」
「A功能有沒有要優化？現在的版本很陽春耶～」
「B功能什麼時候要推出？有客戶在問！」
「我們為什麼不先做C功能，而要先做D功能？」當時團隊內還沒有專門負責 Project Management、Product Operation 的角色，分工也不是非常明確，每個 PM 都有可能被私訊問問題，或是看到有人在 channel 問就主動去回答，一來一往非常沒有效率。
而像是「為什麼不先做 C 功能？」這種問題不只是其他部門的人會有，就連產品和工程團隊內部也常常沒有一致的答案。
因此我們開始討論如何依照目標、使用者回饋、資源等等排出清楚的 priority，建立給整個團隊參考用的 Product Roadmap（產品路線圖），將未來計劃公開。
雖然還無法解決「B功能什麼時候要出？有客戶在問！」的時程問題，但至少各部門可以看到一個月、一個Q的大方向，且只要產品部門更新資訊，大家在上面隨時可以看到最新的版本，有問題再提出來討論就行了。
這些工具強大的地方在於，他們可以跟一些使用者回饋軟體串接並分類、計算數量、給予不同權重、排名，團隊可依據「最多人回饋的功能優先」、「Key Accounts 提出的問題優先」、「資源&成本」等不同考量來決定 priority 與建立 Roadmap。
對產品團隊的內部溝通 — Project Management
專案管理工具如何使用，完全可以再講一篇！這邊先來聊聊我們從 Trello 換成 JIRA 的幾個主要原因如下：
- Trello 被 JIRA 母公司 Atlassian 收購（摁⋯⋯不是什麼重要原因，轉移期也還是很痛的⋯⋯）
- Trello 可以運用的欄位、資訊架構、階層很少；JIRA 可以設定 Epic、Stories、Dependencies，當同時有許多大功能在開發，比較容易切任務跟追蹤進度
- JIRA 有不同模式與排序方式可以讓使用者選擇，PM、工程師、QA 可依自己的工作需求設計版面和功能
- 隨著工程師愈來愈多，技術主管跟 PM 也需要對工作分配和資源運用更謹慎，JIRA 資源管理的功能不少，還有報表可以看
用了 JIRA 之後我們也直接轉移文件協作平台至 Confluence，除了把 PRD 放上去外（無痛關聯到 JIRA Ticket），也把工作流程、開發優先順序、插件處理、Hotfix 定義等文件化。
換用功能強大的工具困難點在於學習成本很高，常常需要花時間研究、調整設定，而公司其他部門也還是覺得 Trello 介面比較友善，途中也會有一段時間要同時維護兩邊的內容，豆頁痛。
換工具、自動化是最佳解嗎？
換工具是各種推力、拉力共同考量下的結果，有些隱性的成本會不小心被忽略，例如上面提到的學習成本、團隊適應狀況等等，就算換了還是要不斷調整，是場長期抗戰。
另一種提高效率的方法是「自動化」，例如原本每天的 standup meeting 會由 PM 記錄發出，改成開一個 Slack channel 並串一隻 bot 🤖 每天早上十點去問工程師三個關鍵問題，工程師回答完後直接發在 channel；又或是原本每次測試都要請工程師把新版本放到 staging，我們改用一些 工具 讓 PM、QA 只需知道 branch name 就可以自己部署到指定的 staging 環境測試，減少來回溝通和 context switch 的資源浪費。
其他更複雜的像是 deployment 流程、QA 測試流程，剛開始手動的工非常非常多，隨著有經驗的人加入後才慢慢提高自動化的覆蓋率。
但這畢竟需要時間轉換呀⋯⋯有時候覺得自己在軟體公司應該要超會用軟體解決問題、全部自動化，不想用笨方法做事，但在這階段，最有效率的方法不一定是換新工具或自動化，土法煉鋼也有可能才是當時的效率最佳解。
解決問題的能力就是平衡各種需求，找出當下的最佳解。
這個概念也不只用在團隊合作上面，解決客戶、使用者問題也同樣適用。
有時候產品發生的 BUG 需要一段時間才能修復，我們也會跟直接面對使用者的部門討論，是不是可以先用「非產品」的角度解決問題（BUG 還是會修但請再給我一點時間嗚嗚），例如手動檢查並幫客戶調整某些設定、直接去當他們的小幫手或客服、或先用 workaround 的方式緊急修復一個暫時性的版本上線等等，反正當下只要是能解決問題的方法都是好方法啦！
講了這麼多工具和做法，工具畢竟就只是工具，能夠幫助團隊達成目標時，他才會成為一個好用的工具。
下一篇會來說說關於「人」與「分工」的議題，畢竟上面提到這麼多事情，應該應該應該應該不是全部都是產品經理的工作吧吧吧吧吧？！
最後，歡迎分享你使用過超讚的工具給我 ⚒
同場加映：書籍推薦！《產品路線圖｜從革新到蛻變》毫無反應就是在講產品路線圖；《創新的用途理論》除了可以用書中提到的心態去檢視自己的產品外，在用其他工具、產品時也會很有感唷！
謝謝你的閱讀！如果有任何疑問、想聽的主題，歡迎留下 Private Note 或留言給我 📒如果單純想給我一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-20 個拍手；
如果想看更多團隊合作或工具的文章，請盡情長按拍手（50個拍好拍滿也沒問題）讓我知道 👏🏻想要持續追蹤我們的最新文章，請追蹤產品三眼怪實驗室 (◉◉◉)
每週六下午三點，會有人準時發文的～～～
