人數雖然並不多，但由於平台發展組以外的夥伴們對於產品開發流程較為陌生，平台發展組便和「牆外的世界」產生了許多溝通困境。也因為流程導入與優化並非一蹴可幾，太過躁進反而可能造成組織的消化不良。

在觀察了團隊運作一陣子之後，我決定從這 3 個點開始著手：

1. 持續從天上掉下來的隕石（aka 插單）
2. 需求單位不知道該怎麼提出「好需求」
3. 需求提出了、功能上線了…但為什麼要做、什麼時候做，上線了什麼，大家都不是很清楚！？

設計良好的需求開單機制

在 SOP 尚未健全的狀態下，擁有一套好的 SOP，至少可以解決組織 50% 以上的困境。需求開單機制，主要處理的就是上面提到的 (1) 隕石、(2) 不曉得如何提出好需求兩大問題。

均一業務單位過往主要用來開單的工具是 gitlab。由於工具與流程同時調整的變動成本太高，在工具方面我選擇沿用 gitlab，但獨立開出一個「需求收集區」，特別用來輔助產品經理與需求單位之間的溝通流程。

1. 依照 TA 類型，區分對應的需求模板，讓需求單位填寫

對於產品經理而言，透過上述的 7 個問題，可以更清楚的將需求「打回原形」——不僅是看到需求單位期待的表層解法，而是深入理解需求的本質及痛點，如此一來就能更精準的排序問題優先級，也才有探索更多解法可能性的空間。

偷偷說，還有一個隱藏版的好處，就是讓需求單位透過填答的過程，「想清楚自己到底要什麼」。有時在填答過程中會突然意識到自己的盲點，發現自己思考得不夠周全、這個需求好像也不那麼重要……總之，對於產品經理和需求單位來說是 win-win！

均一的需求單位，主要是負責「平台課程內容建置」與「對外合作推廣」的夥伴們，除此之外，CEO 也是很重要的需求來源，甚至可以說是最重要的需求來源；畢竟產品的發展路線必須跟組織發展目標與願景一致，才能夠確保產品的推進可以有效協助組織達成目標。

2. 規劃處理狀況的 swim lane，方便需求單位掌握進度

除了(1) 隕石、(2) 不曉得如何提出好需求之外，前面還提到了我想要優先著手的第三個問題：「需求提出了、功能上線了…但為什麼要做、什麼時候做，上線了什麼，大家都不是很清楚！？」

這個問題，在需求的部分，我透過 gitlab「需求收集區」的流程設計來解決，分成「需求提出」、「PO 接球」、「內容增補」、「排入 PBI（Product Backlog Items）」、「已進開發」、「Closed」6 種狀態。

除此之外，針對已排入 PBI 的項目，我也設計了 3 種 label，進一步呈現處理的優先順序：

1. P1：最優先開發項目，以最近 1 個 sprint 進開發為目標
2. P2：次要開發項目，以最近 2 – 3 個 sprint 進開發為目標
3. P3：次要開發項目完成之後，才會安排進入開發

透過 ticket 在泳道中的移動以及優先順序 label 標註，需求單位便能快速掌握每張 ticket 所處的狀態，例如產品經理看了沒？看完之後有沒有問題？我提的需求會被開發嗎？什麼時候才會開發？

在某些商業環境中，產品開發與行銷、業務等單位會比較對立，這也容易導致產品經理在對外溝通時藏一手，針對特別敏感的優先級問題模糊帶過。而在均一，強調透明的組織文化，讓跨部門成員之間有著更強的互信基礎與協力意願。不必擔心因為講得太清楚而被背刺，是我覺得均一很值得稱讚的地方之一。

該寫的產品文件，一定要好好寫

由於均一現行的團隊配置只有一名產品經理，可以說不論宏觀的策略面或微觀的執行面，都是我的守備範圍。抓大又不能放小的情況下，沒有時間寫千百種因應不同情境的溝通用文件，但我會非常有意識地將寫文件的時間，集中火力在特別容易掉棒、出現溝通斷點、難以知識留存的環節。（沒錯，就是優先級排序的具體實踐！產品經理的靈魂裡根本就刻著「優先級排序」五個大字吧？）

在均一，我一定會寫的文件，有以下幾項：

1. 產品路線圖（Product Roadmap）

用來和 CEO、設計師、工程師等等 stakeholders 說明未來的開發規劃。雖然名為「文件」，實際上其實是直接使用 Jira roadmap 功能拉出接下來幾個月的開發項目，以視覺化的呈現讓不同角色更容易達成認知上的 alignment。

2. 產品啟動文件（Product Kick-off Document）

主要作為和設計師溝通設計方向，以及和需求單位說明設計方案的基礎。這份文件實際上會隨著討論的開展，不斷進行內容擴張與增補。在最初期的階段（也就是對設計師傳遞想法的階段），可能只包含需求脈絡、使用情境、流程圖、開發 scope，中期會出現不同的解決方案proposal 及示意圖，後期則會加入更具體的功能邏輯說明與設計稿 demo。

因為均一上面的科目、內容越來越多了，最近開始規劃新的首頁課程選單。以上就是功能開發最最最初期的 kick off 文件節錄，內容以目標、設計方向為主；如果有我認為很不錯的 design reference，也會在此時提供給設計師。國外的線上學習平台 coursera 就是我提供的 reference 之一。

3. 產品對焦會議 agenda & meeting minutes

許多人常常會覺得 agenda & meeting minutes 不太重要，但我發現，在跨組溝通頻繁的均一裡，建立好這些文件是很有幫助的。在我加入均一之後，和最主要的兩個需求單位——影響力發展組，以及課程與教學發展組——分別建立起兩週一次的固定對焦會議，說明產品開發的規劃與進展，而需求單位也可以在這場會議中補充需求細節、同步組內正在執行的項目，以便產品經理掌握組織的動態與方向。

但一方面因為平台發展組以外的夥伴對於產品開發流程較為陌生，另一方面則是考量到均一本身的業務複雜度高，對焦會議可能會有不同的夥伴臨時加入討論，如果無法讓大家快速回溯過往的內容，或喚醒前次討論的記憶，很容易產生過量的溝通成本。這也是為什麼這個看似不重要的文件類型，會被我納入「一定要寫」的項目的原因。

4. 產品需求文件（PRD, Product requirements documents）

這份文件，就是每個產品經理的 everyday life了。目前我所採用的作法，是將最完整的需求背景（也就是為什麼我們要做）、功能規格、設計稿、驗收標準彙整成一 份 Confluence 文件，同時會再視功能場景與 RD 開發的順手程度，將完整的功能拆解成多張 user story，讓 RD 在scrum planning 時更容易估點與聚焦討論實作細節。

5. 產品上線文件（Product Release Note）

書寫產品上線文件的目的，主要是「讓外部團隊知道平台發展組到底上線了什麼功能」。如果不知道，將會衍生許多嚴重的後果：行銷不曉得有新東西，所以錯失 promote 的素材與時機；客服不知道有新東西，所以使用者回報問題時給予了錯誤的回應；未來新進的產品經理或產品設計師缺乏比較一目瞭然的產品上線紀錄，所以只能在文件海中拼湊自己對產品發展歷史的理解。

因為主要溝通對象為外部團隊，以及未來新加入產品團隊的成員，這份文件的易讀性便非常重要。目前我所使用的工具是 Gitbook，雖然 Gitbook 推出新版之後，網路上部分老用戶對於其商業模式的轉變有 負評，不過由於均一可以申請免費的 NPO 方案，所以我依然覺得方便好用。

分享到這邊，希望能夠讓大家對於均一產品開發的過程，以及均一產品經理的角色有更具體的認識。我們現在正在招募資深軟體工程師與 QA，快來加入我們，在沒有隕石的環境中一起打造更好的產品吧！

備註：

這篇文章撰寫於 2021 年 5 月，非常感謝當時的 PO Ivory，帶領均一在產品思維和合作上的成長。目前均一的產品團隊架構有所調整，與文中描述稍有不同，可參考官網「執行團隊」的介紹。