最近接觸到很多產品實務上的議題，趁著記憶猶新統整，覺得從開發者的角度開始參與產品管理十分有趣，也能結合自己過去所學，來分享一些作為開發者協助執行產品管理跟上手產品的零碎紀錄。

上手專案

身為開發者對於專案通常是最了解的人，但也僅限於自己有開發過的部分，要走向產品，就必須在自己開發以外的部分也非常熟悉，要怎麼在不寫程式碼就成為最了解產品的人，我自己分為產品、產品使用者跟利害關係人三個部分需要了解，並以一個開發兼產品的視角來進行闡述。

產品

由於是開發者，先確保把軟體架構、DB Schema ¹、跟實際使用 Client 端的服務並紀錄一些問題把這幾個釐清，針對核心邏輯也可以去閱讀程式碼，甚至畫出流程圖 ² 來作為未來 FAQ 的素材，雖然這些是規格書通常不會寫到的部分，但卻是常常會被問到的環節。

接下來，我嘗試的是「看過所有規格書並進行完整的測試」，以自己遇到的狀況來說，當時的規格書有兩個問題：

• 並非所有功能都有與規格書同步
• 規格書的文件系統非常難用

所以趁著這一批次將規格書移植到 Notion 外 ³，有規格書的地方可以比對規格書並且記錄一些 Issue 跟提問跟找卡，沒規格書的地方可以補進規格書中。當補完規格的部分，接下來了解目前開發進展的狀況。

相較於規格書，由於團隊不大加上本身就是開發團隊，哪些卡在 code review 哪些這次會 release 相應比起了解其他部分要來的容易，總之嘗試要盡可能做到的是，當今天一個其他部門的同事過來問你說：

欸、這邊是先 XXX 然後再 YYY 嗎？但為什麼會 ZZZ 這樣不是很怪嗎？

能迅速的反應說「喔、你說的是 XXX 這邊嗎（拿出產品 demo）這有可能是 YYY 的原因，之前 ZZZ 已經開發到 JJJ 但因為 KKK 而 blocked ... 」，能做到這樣這樣就是初步對於產品有一定程度的了解了。

使用者

當產品的商業邏輯掌握後，接下來要了解產品的使用者，才得以規劃可能的解決方案跟重新審視功能的必要性，以我遇到的狀況是，我們屬於 B2C 公司，產品分為對內使用的後台與對外使用者使用的 app，所以會有內外使用者需要了解。

外部使用者若原先就有相關的 Persona 資料可以先去閱讀一些使用者樣貌資料，不過這次專案使用者族群與自己相去不遠，相應的就比較不急迫去補齊質化的資料，而是需要量化的行為數據來輔助決策，這時候開發者的背景可以幫上不少忙，可以實際去載資料跑簡單的統計 ⁴，看看使用者 5W1H 各種面向怎麼使用我們的產品。

另外內部使用者這一次則是安排了一輪使用者研究，分別是觀察跟訪談，透過跟設計師一同執行一次研究跟參與 User Story Mapping Workshop ⁵，了解其他部門的工作流程、限制跟需求。

有別於外部使用者，內部使用者的產品可以預期使用者有比較長時間學習且屬於專家使用者，所以相比於了解行為數據，更需要的是透過產品來協助優化工作流程、增加公司內部的執行效率，比較接近服務設計的層級。

以了解使用者來說，盡可能做到的是今天有人問你說：

欸、XXX 每週平日的時候都會在哪裡怎麼使用我們的產品？為什麼？

能迅速的反應說「喔、平日的話因為 XXX 所以他們都會用我們的 YYY 因為 ZZZ，但如果遇到 JJJ 可能會 KKK ...」這樣就是初步對於產品使用者有一定程度的了解了。

利害關係人

當產品跟使用者都有初步的了解後，要了解產品周遭的利害關係人（包含外部、即將接觸與內外部使用者們），心裡要抓著這些人之間的關係跟重要性，才得以決策功能的順位與準備需要的資料讓老闆說服他們。

以我自身的狀況，尚不需要對外部利害關係人去報告產品現況，所以對於外部利害關係人，可以盡量多從老闆口中了解他們喜歡什麼、底線是什麼之外，也可以同時了解目前業務上開發的需求，協助提出現行功能下的解決方案或安排新的功能開發。

而內部來說，則盡可能以透明公開的方式，善用內部公告 ⁶ 來進行對話，讓大家了解產品開發進展，並盡量跟大家溝通透過回報的方式來進行 Issue 的收集，以上以了解利害關係人來說，盡可能做到的是老闆問你說：

欸、今天因為 XXX 需要 YYY 可能要做 ZZZ

能迅速的反應說「喔、不過 JJJ 也會需要 KKK 這樣考慮到 HHH 覺得是不是以 KKK 優先而 XXX 可以先用 GGG 來處理 ...」這樣就是初步對於產品利害關係人有一定程度的了解了。

上述的各種狀況說的都是初步的了解，我自己期待要能更深刻的了解，可能會是能從現況到預測可能的發展：

• 以產品來說就是為未來先預先開一些打底的需求
• 使用者來說就是提供潛在可能開發的使用者數據
• 利害關係人可能是了解募資需求等等。

而以上這些都會需要對現況相關的競品、族群跟市場都有更多經驗才得以積累，領域知識的路非常漫長。

文件、開卡與小工具

初步的對於圍繞產品的一切有一些了解，但需要一些工具來輔助自己執行實際的工作，以下是過程中在日常執行 Roadmap 規劃、開卡、寫文件與討論等會使用到的工具。

文件

覺得很適合拿來作為開始文件體系的敲門磚是 Onboard 文件 ⁷，想像一個新人今天要了解公司，必須要知道哪些事情才能快速上手，透過這樣情境的視角慢慢補上公司各式各樣的大小文件，一路上補完的順序如下：

• Onboard & Onboard Checklist
• 工作流程
• 規格書
• Issue Board 與 Roadmap
• 服務架構
• 對內公告
• 會議紀錄
• FAQ

對於小團隊來說，其實文件並非第一順位重要的事情，因為轉個身就可以進行討論，其實也不失效率。但保持產品團隊可以透過文件溝通的透明公開與溝通效率，這些文件系統是非常非常重要基石。

寫文件跟寫 code 一樣，需要發揮 Git 的精神，盡可能保持版控，而這裡的版控不一定要像是使用 Confluence 一樣有實質的版本紀錄，而是對於文件版本的更動需要討論跟 memo。

有了版控後，我發現文件中一件重要的事情是不要有「堅持」，舉例來說：寫文件一定會參考很多別人的範例，開了一堆欄位發現後續很難維護，這時候就大膽的移除，並在流程反省會議中說明為什麼，讓文件成為輔助。

開卡

卡該怎麼寫有一大堆寫法，秉持著開發者的背景，設身處地的想，如果今天是我要開發，我到底要怎麼寫才能保持一些自己決定就好的彈性但又不會不知道該怎麼開發才好。

關於開卡諮詢了很多人的建議，最終暫時保持了這樣的架構 ⁸：

• Issue Overview: 這次的需求是什麼？為什麼？
• Technique Overview: 可能需要的技術或發生的問題點
• Priority: 需求的重要性、為什麼？
• Solution: 解決方案，包含: user story, UI flow

與朋友最多討論的是第二環節 Technique Overview，到底產品規劃需不需要看 code，我自己最終還是保留這個區塊，如果真的來不及就不強求，但時間允許，除了基於自己同時兼顧開發，可以更了解專案的好處外，最重要的還是：這樣決策比較快。

很多時候一個 Issue 進來，如果可以初步排錯到實作的層級，可以先針對排錯的結果提出不同的 Solution 來進行討論，一來可以刺激自己思考不同解決方案的技術限制，二來可以不用一直一來一往的釐清方案，節約工程師的時間。

小工具

專案圍繞著 Notion + Google Drive + Trello 展開，在工具選擇上，選擇大家最能接受的、最容易流通在不同部門的就是最好的工具。而個人工作上，所有可以輔助表達的工具都是好夥伴：

• 流程圖 FigJam
• 截圖 Snippaste
• 螢幕錄影 giphy / 內建
• 線上即時繪圖 whiteboardfox

另外就是大量的「模板」，舉凡各種：紀錄、回報、公告、開卡、規格 ... etc 等文字全部都模板處理，雖然有想過要不要裝 espanso 這類的服務，但因為實在太多可以客製化的地方，所以最後沒有採用只是複製貼上，簡言之能自動化的地方自動化，並開發一些腳本跟工具輔助，可以節約大量的時間。

流程

有了了解有了工具接下來就來想流程，說到流程真的非常憧憬極限編程等等的高端技巧，但是現實總是骨感，知道流程容易導入難。目前不甚成功的案例就有：

• 嘗試從 Trello 轉到 Jira 串 CI/CD 自動化，因為 Jira + Confluence 太複雜適應不良。
• 嘗試照著 Scrum Guide 跑過所有的 Scrum 會議實際上不敷需求。
• 嘗試照 Qase 寫測試案例希望可以聘雇工讀生執行 QA，結果反而更難測。
• 討論了 Trunk Based Flow 結果超級不適合小團隊，改用 Git Flow ⁹。

... etc

看起來踩爆所有的雷，但以上的迭代可能都不超過一週，有時可能還沒有發展到工程團隊只在自己身上嘗試後，就在產品會議時討論後移除了，取而代之的是帥帥的做法裡面部分好用的地方與現在的系統去銜接。

當然聽到別人說到自家流程很完整時還是有點羨慕，但流程還是以自己團隊狀況為重，最終以現在最適合的狀態：

• 一次產品會議 ¹⁰：開始下一輪的 Sprint，會討論 RoadMap、成效、這週接收到的 Issue 與預計的解決方向，並進行這輪流程的檢討。
• 一次是工程會議：會討論解決方案可行性、預計可以排入這輪 Sprint 的功能，預計的 Test & Official Release 時間。

最後就是每日的 Stand Up Meeting。過程中沒有 Review 取而代之的是產品更新公告與公開的 Issue Board 來與其他部門同步產品部門的現況。

透過上述的流程來進行開發。

團隊

有了產品的了解、有小工具輔助自己逐步建立了工作流程，接下來就是需要建立團隊、打造文化，簡言之找人進來、讓人願意留下。但文化真的很抽象，關於文化我還無法組織這段過程的改變來敘述。

基本上現在團隊還小相應不複雜，只要能兼顧現在團隊的樣子下、去打造出大家都認同的更好的團隊樣貌，我想就是一個好的文化，這其中也包含大量的個人偏好，我自己很喜歡像是財報狗、Pikabu 這種精英團隊，尤其想要打造出「沒有我也可以自我成長的團隊」¹¹ 希望自己可以建立這樣的文化。

於是尋找了大量類似這樣的案例跟找前主管或有主管經驗的人聊聊，也閱讀了一些關於團隊、mentor、coach、scrum 的書，並實際運用在流程中，適合就保留、不適合就移除。

以目前有參與到的了解部門預算、基於預算去規劃團隊組成並實際去寫徵才文、發文 ¹²，但怎麼樣才能讓人覺得想要留下可以還待驗證，過程中參考了 GitLab Onboard 設計、尤其參考了前主管大推的經理人之道 ¹³，One On One 的習慣、Demo Day、設計或工程的技術交流、溝通的透明公開、基於數據的討論習慣 ... etc。

零零總總的我想文化就是一種習慣，想要大家一起養成的習慣跟默契，繼續朝著這個方向努力。

小結

除此之外還有什麼坑要補，太多了 T皿T

除了上述提到的各種知識內容，還有財會的概念希望可以補足，產品就像是情報商，要讓自己盡可能瘋狂的被各面向的資訊洗臉、並站穩自己心中的錨又維持著彈性做流程優化跟決策。

意外的產品依舊在軌道上運行使用狀況也有了起色，有時在路上看到使用者使用自己的產品，也會覺得「啊、是我們的產品！」看到 FB、客服進線抱怨我們的產品會覺得「嗚嗚嗚、好辣 QQQ」不禁覺得兼顧開發跟產品兩件事是一個不錯而且有趣的嘗試。

參考資料

Footnotes

1. 原先使用 dbdiagram.io 最近改為同一個團隊製作的 dbdocs，可以沿用原本的語法，也可以用他們提供的 CLI 工具從 db 逆輸出 dml 檔案來建立文件，實在好用，只要再補 relation 就可以了。另外 draw.io 有架構圖元件可以使用 ↩

2. 為了 UX 文件管理所以使用 FigJAM，原先比較習慣使用 Whimsical，但文件就會分散在不同的系統裡所以作罷。 ↩

3. 原先在 Google Docs 中，但要將 Issue 跟文件 comment 拆分才有辦法管理，改用 Notion 這個上手比 Confluence 方便很多的工具，方案選擇上可以參考 這篇文章，目前使用 Personal 付費版。 ↩

4. 指標先是 PO 就有一些用 excel 實作好的指標但需要自動化，這邊提到的數據工作主要是用 python 將資料清理跟運算自動跑腳本，存到資料庫，並實作一些比較複雜的運算。 ↩

5. 博客來-使用者故事對照：User Story Mapping ↩

6. 內部公告的概念是來自於均一 這篇文章 的 Product Release Note，可以節約跟其他部門溝通的時間，也能作為 app 更新文案的參考。 ↩

7. 你在試用新人，新人也在試用你：五個科技公司提高新人留存率的 onboarding 方法 | Star Rocket Blog ↩

8. Issue 回報的模板有很多，在同樣均一的 這篇文章 也有提到，但目前對內外有 PO 作為窗口在轉述，故沒有採用這個複雜的模板供需求方填寫。 ↩

9. 當時是因為遇到需要 rollback 的狀況而有了這次討論，討論的決議點在於，我們並沒有能專門顧 Release 的 Release Developer，若遇到 Hotfix 的狀況，可能 Release Developer 會 Cherry Pick 到生氣 XDDD 所以維持經典的 Git Flow，Hotfix Branch 則壓在只有 Official Release 有問題才可以使用。 ↩

10. 小故事：原本保持 Scrum 的說法叫做 Refinement + Retrospective，但講這個面試的時候面試者會一臉不知道你在說什麼，於是這個名字就直接改叫產品會議了，同樣的工程會議原本也叫做 Sprint Planning。 ↩

11. 當工程師十年的心得感想. 從 2010… | by Yang Hsing Lin | Medium ↩

12. 我心目中的理想徵才文. 四年前是我人生中第一次求職，抱持著「之後應該不會海投了」的心態，一口氣面試了快要… | by Huli | Medium ↩

13. 博客來-經理人之道 技術領袖航向成長與改變的參考指南 ↩