專案管理有許多可以探討的議題，隨著新創風氣在許多育成單位協助後蓬勃發展，但不盡然都是資訊呈現為主的網站，在工具上更是雨後春筍般不斷有針對特定流程、特定目的、特定對象產生的第三方服務，那這些到底該怎麼選擇？用了這些工具就能做到他所說的效果嗎？其實並不其然。
目標先決比工具先決重要
相信許多 PM/管理者 一定都有過該遵循哪種管理方式比較好？專案管理服務幾十種該怎挑選？該怎麼樣確保上線的品質？該怎確保工程師成就感？等等的心中小劇場。筆者也經歷過這樣的過程，甚至試用了 10 幾套專案管理工具，最終才發現，這些服務、心法還是管理方法，終究只是達到我們管理目標的一個工具/方式，還是要問問自己，想要打造怎麼樣工作模式與氣氛的產品開發團隊。
當時在尋找工具前，希望管理方式能做到三大目標：
- 工程師能有不斷完成工作的成就感，團隊也能有一個時間區間的共同成就
- 一旦規格訂好討論好後，減少開發過程間的溝通
- 開發內容與討論過程都能公開透明並保留記錄
工具的挑選
現在專案管理服務非常的多，像是 JIRA, Trello, Asana, Redmine, Notion, Basecamp, Phabricator 等等，筆者都有實際上去測試且將某功能的 issues 搬上去玩玩。但形式非常的多，有適合敏捷的、Scrum、待辦事項的、指派工作為主的，甚至有連文件管理跟 CI/CD 統包的服務。蘇格拉底說：「我唯一知道的就是我一無所知」，這句話的奧妙就在我們生活隨處都在遇到，知道太多時就像無頭蒼蠅，不知道該往何處去。
目標先決重要就在於莫望初衷，我們想要的就如 Scrum 的模式，一開始大量溝通與規劃，每日隨時的校正，最後不斷透過每個 Sprint 檢核團隊成果，並檢討與改進，獲取不斷往前的成就感累積。但，小團隊與創業剛起步時，有的是許多的想法….就是沒有人、沒有錢、沒有客戶。這時需要的是快速的演進，根據客戶與市場需求不斷快速的開發，是產品 0-20 分很重要的過程。
最終，我們則是選擇了 Trello 作為管理工具，簡單、有彈性、有標籤、有篩選器、有指派功能，還有許多 browser extensions 能夠擴展功能，更重要的是，免費。
（後記：若有使用github 作為主要管理程式碼的服務，可以試試看Waffle.io，基本功能與 trello 一樣，差異最大在於他的每張卡等同於 github issue，且有做同步的整合）
先簡單定義一下 Trello 功能搭配專案管理上的連結關係：(參照範例圖)
- board（看板）：代表一個專案
- list（列表）：代表開發流程中的一個步驟
- card（卡片）：俗稱的票（issue）。
這定義尤其重要的是 board，過去在使用 trello 上因忽略背後設計理念，以 board 為團隊，將所有專案的票都開在一起，最後沒了流程性，每張票的流程與進度都得進去看內容才知道；每個 list 也因爲各專案的工作很多，整合在一起時便多到讓人嫑嫑的，導致整個管理失敗。在吸取過去與其他團隊的經驗下，我們有了幾個原則：
- 各自為政，一同努力
- 每一個 board 代表一個專案，有多個專案就需要開多個 board，讓各個負責人專心瞭解他們該做的工作就好。
- 另外，若同專案有不同目的也應拆成兩個 board，像我們有個 A 產品開發版，以及 A 產品規劃版，讓 PM 規劃每個功能也有流程可以跑供大家檢視。
- 列表只用作為流程的步驟使用
- 分工合作，逐步完成
- 每張卡片盡可能切細，最多半天能處理完的大小
- 卡片在切分時盡可能降低耦合、增加內聚力，讓每張卡的相依性降低（這很難我知道，所以盡可能）
- 透明公開，彼此瞭解
- 以卡片在 trello 的 url slug 作為 git branch name（例如：https://trello.com/c/wIdo3qXx/732-system-should-apply-only-one-automatic-coupon-when-checkout，就會以最後粗體字處作為分支名稱，甚至在分支切換時也可透過前面的數字做到 auto complete）
- 每張卡片完成後，都需要在 github 上開 pull request（後簡稱 PR），並且將連結貼回至卡片中，讓 code review 以及其他對此工作有興趣的夥伴，都能直接連結過去。
（範例圖）
在這樣的原則下，我們的 lists 大致為：（參照流程圖）
- Sprint to do：每個 Sprint 團隊要一起完成的工作。
- Blocked by：若有張票開發到卡住，則丟進此處並標記被卡住的卡片連結，相對該卡片也應標記此張卡片，以便未來完成後可再持續解決這張卡。
- Developing：當工程師要開始開發時，則將卡片移動，作為一個開始動作，同時也可讓大家知道目前每個人正在開發什麼內容。
- To revise：開發流程最後一定都會需要有他人進行 review，不論是 coding style, architecture 或是 user flow，有需修正的地方，我們都會在 PR 中註記，並將此卡片丟至此處。
- Done：已完成開發的卡片，等待後續 review。
- To Deploy：代表 review 完成沒問題，並已完成 merge 等待最後確認（e.g. staging, CI auto testing）上線。
- Deployed：功能正式上線後，卡片就會丟到此處算流程完整跑完，大家也能在此看到已上線哪些功能。
（流程圖）
成效如何？
在新流程導入後，工程師都反饋比起過往在執行每個卡片時，需煩惱 branch name 如何命名，以及在想瞭解過往夥伴執行的工作時都還得打斷對方做詢問等狀況，在簡單一個統一的 branch naming rule 下，讓整個團隊運作的彼此瞭解，能透過工程師的共同語言：「程式碼」做溝通，減少許多不必要的溝通。
實際開發上，因為卡片的大小有一定規範，獲得兩個顯著的收穫。第一個是，每天工程師都能有完成些什麼的成就感，作為不斷持續的動力；code review 上也因為卡片的大小限制，讓進入成本（時間成本、心理成本）大幅降低，可以將可用資源最大利用的將功能完成測試上線。對於 PM 與管理人員來說，能更確實在功能上線前都一定會經過檢核，還能明確掌握每一位成員手中在執行的任務，協助每個成員對準團隊目標。
實際上在跑有遇到幾個比較特別的狀況，假設真的這個功能較大很難拆出每張可以獨自被 merge 到 master 的票，可以在卡片中溝通哪幾張票都應該 merge 到某一個 branch，等到最後完成時再一次回到 master；前端與設計該怎進入此流程？一樣將設計與切版都開票，走一樣的流程；若需要其他後端協助，再將後端拉進票中一同幫忙。
小結
我們團隊（後端*2、設計/前端*2、Tech lead/PM）依照這樣流程跑了超過半年，平均每週能上版超過10個大大小小版本。在聽過中國大公司其中一個小組分享他們一年上版150-200個版本，相比之下 10+/週算是很不錯的一個成績。
產品開發管理就這樣嗎？
此篇著重在從規劃完成後，票的建立到完成上線如何有效的被實踐。其他像是 standup meeting（我們用 jell 各自紀錄同步 slack 取代）、程式碼品質檢驗（code climate）、自動化測試、持續性發佈（CD）等等；非工程面，像是像是怎麼訂版本號、如何根據市場設定戰略目標、如何製作商業模式的營運報表等，又是另外一門學問了，讓我們下次見。
若有更多好奇的細節或是議題，歡迎來信或填以下問卷與我們討論。
問卷裡有神祕的Trello聚會活動喔～
