適合中小型團隊的免費開發工具 — Trello

文章重點不在介紹如何使用 Trello,而是介紹開發團隊如何善用 Trello 的優勢:簡單、免費,來架構一個完整的開發流程,基於資訊透明、公開及避免干擾、打斷開發。另外,要強調的是本篇文章以 PM 管理產品、專案的角度為主要的切入點,但會涵蓋如何與營運(客服、行銷及相關維運)單位互動及建立開發週期專注、減少被打擾的流程。

有幾個運用的前提及建議。

  1. 不管你的開發團隊有沒有在敏捷開發(或者自認為的敏捷),都建議與成員一起定義開發週期,即所謂的 Sprint,不管是 1 個禮拜還是 2 個禮拜,都有助於團隊成員聚焦在現有的短期目標上,而且務必讓營運同事了解這個週期,避免總是急於滿足未妥善進行時間安排的需求,而需要抽換開發項目,打亂開發節奏。
  2. 介紹並邀請營運同事或大部分的公司同事一起使用 Trello,減少內部電子郵件或單純口頭需求上的交流。但不需要著急,推動改變有時候不是那麼容易,先從好講話的部門、同事下手。

Trello 不僅免費,未付費幾乎所有基本功能都是沒有操作限制,善用卡片、看板、成員無上限,讓合適的工作流程帶你上天堂。首先,先思考一般開發流程會是什麼樣的資訊流通?並且把這些節點都轉為一個看板(Board),代表需求或問題從匯集、討論、開發、上線版本紀錄都在同一個地方,隨時可以跨看板去查詢所需的資料。下圖為一個看板流程範例,本篇會著重在 Product backlog 及 Sprint board 看板說明,其餘可參考 Buffer 的這篇文章,介紹的相當完整,本篇就先不花版面來重複涵蓋,有需要可以再寫另外一篇來補充(如果這篇反應不錯的話 😛)

Trello 看板流程

Trello boards flow ・Link (小型團隊未必會需要開啟這麼多看板)

Product backlog

各種長、中、短期需求、待辦事項的集中看板。如果公司只有一個產品,應該只有一個 Product backlog 看板;如果開發團隊較大,可以依照拆分小組目標的不同,而有不同的 Sprint boards,但應有著共同的產品願景(註)。該看板主要由 PM 或 PO 進行維護,依照 OKRs 或團隊的目標設定來寫不同粒度的 story。或從營運、客服需求的看板,判斷是否將需求卡片移入。如果有公開的需求看板或者功能調查,可參考用戶回饋(透過 Voting Power-up)協助排序功能開發的優先順序。

列表左到右以可分為 Vision、Ideas、Mid-term、Short-term、Upcoming、Sprint planning。依照順序時間來定義清單的排序。讓公司成員進入看板即可清楚理解,產品功能開發的大致時序。當團隊進行 Sprint Planning 時,開啟這個看板進行討論,從 Upcoming 列表中的卡片拉進 Sprint Planning 列表,待確認所有卡片的開發內容後,再將列表上所有卡片移至 Sprint backlogs 看板。(略過很多細節,要詳細寫下來又是另外一篇文章了)

建議開啟的強化功能(Power-Ups):

  • Teamgantt or Planway Calendar:如果需要概略的視覺化產品路線圖,啟用這類的強化功能,會比維護另外一份 Excel、Google sheet 容易些,也避免資料同步問題。
  • Card Aging:看板上的卡片 PM 或 PO 應該不定期進行更新、移動,太久沒動的卡片也許需求已不存在,可幫助判斷是否要從 Product backlog 移除或封存卡片。
  • ICE Score:用來排序開發項目的優先順序,當拉入太多卡片在 Upcoming 列表中時,可以與團隊透過 ICE Score 來給予排序。(如果貴公司用隕石式開發或常常啟用執行長按鈕,就不用考慮了這個強化功能)關於 ICE Score 的介紹,可參考 Trello 官方網誌這篇這篇文章。裡面會介紹如何啟用這個強化功能。
  • Custom Fields:自訂欄位屬性,例如增加指標下拉選單,清楚的理解改善範疇屬於轉換還是獲取新用戶等。自訂彈性非常高,因為是官方強化功能,Trello 行動端 App 也支援,非常建議啟用。

Sprint board

Sprint board 清單範例,這裡有 範例看板

顧名思義即該開發週期的工作項目,在 Planning 會議結束後,由小隊隊長將卡片移入看版。這個看板為開發週期 Sprint 內主要的工作看板,小隊的跨職能成員也是花最多時間在這個看板上。看板範例可從這裡連結。

列表左到右定義為工作流程,Sprint board 列表依序如下:

  • 📃 Sprint backlog:每次 Sprint Planning 討論完,從 Product backlog 移入所有 User story 或 Tasks 卡片的目標列表,當然還有 bugs。理想上,是每次 Sprint 結束都要清空。
  • 🛠 In progress (doing):當工程師或設計師開始對卡片上的需求進行開發時,將卡片移動到這個列表。原則是,真的在進行才移入,這邊不是個人的 Backlog。完成時註明更新,並交接給其他成員檢視或移動到下個工作流程列表。
  • 🆘 Blocked:當卡片的工作事項,因為外部因素或任何阻礙無法由團隊成員解決,將卡片移動到這個列表。PM 務必了解原因,協助儘快解決阻礙。
  • 🔄 Ready for Verify:非必要的列表,但如果有些工作需要交接給下一棒,比如 UI/UX Review、Code review 或準備給 SQA 驗證時,會比較清楚。當然也可以透過留言的方式來提醒下一棒成員。
  • 🚥 In Review (Reviewing):開始 Review 時移入,問題回饋可透過新增代辦事項來逐一標註。修正時再移回 In Progress 列表,重複上述流程。
  • Done:功能在非 production 環境驗證正確符合預期,相關的問題也已修正,已具備可推上線的準備。但 Sprint 結束,卡片的功能也推上線,可以將卡片修改命名加上 Sprint 代號,如 ✅ Done — Sprint 12,將整個列表移入 Release board 備查。每個 Sprint 結束重複一樣的動作。再建立新的 Done 列表。
  • 📊 Analyzing:如果團隊有在進行 A/B test,可將卡片移入 Analyzing 列表進行後續追蹤成效,記得設定到期日提醒。
喔,沒錯,你可以在列表名稱上加上 emoji,讓每個列表狀態看起來更生動點!

標籤使用

  • 過去經驗標籤主要拿來區分 Story、Tasks、Bugs 及職能類型,如 UI/UX、User research/Usibility test、iOS、Android、Web(Frontend)、Backend、Growth 等,用來標註那些卡片是那些領域的成員需要參與的,成員可利用篩選卡片功能快速出需要認領的卡片來安排工作。Product backlog 看板可套用相同的標籤。

建議開啟的強化功能(Power-Ups):

  • Custom Fields:如上方所提,只要有開啟 Custom Fields,在 Product backlog 輸入的資訊,在移動卡片時會一併帶過來。可在依照團隊需求,增加客製化欄位,例如 bug 卡片的回報時的必要資訊等。
  • Zeplin or InVision:在描述或留言貼上 Zeplin 連結,會直接帶入連結的標題方便討論;也可以在卡片直接附加 Zeplin 專案、標籤或單一畫面。
  • Github:將 PR 附到卡片上,方便進行 Code view 時的資訊對照。
  • Google Drive:如果公司有用 Google Suits 可以開啟,主要是可了預覽縮圖;跟從附件按鈕再選 Google Drive 的流程其實一樣。
  • Bulter:如果需要一些自動化的規則,可以研究看看,比如說卡片移動到某個列表就把某個使用者加入,或卡片移動到 Done 列表就把到期日自動打勾。
  • Booklet by Vince:可批次調整卡片,如複製、移動、添加移除標籤。另外,可以挑選列表或標籤匯出 excel 或 markdown 格式簡報,在整理 Release/Version log 時很方便。

OKRs & team goal-setting

以往這塊資訊在大部分公司都是最不明確,或者沒有清楚呈現的地方。管理階層應有個明確的策略下訂立產品季度目標,並與中階主管或 team lead 一起討論期望的結果,有共識的情況下,轉換為團隊目標設定,那麼接下來所有的開發、營運工作內容的重點,都應該要圍繞在這個主軸上。將資訊簡單、清楚的呈現在看板上,公司所有的成員都可以隨時進入觀看、檢視是否偏離軌道。

Public feature requirements & Public roadmap

公開的看板提供對產品有興趣的用戶留言進行意見回饋,類似產品討論版,需要花時間跟心力進行維護及回應。可依照人力考慮是否設立、開放此看板。提供 Roadmap 也讓對產品熱衷的客戶,可以清楚了解接下來產品的發展,重視他們的意見,並給予回應,這些客戶有機會幫你介紹更多新用戶。

這三個看板不在本篇重點,又覺得應該要概略描述,就點到為止。


工具應用觀念

不管用什麼工具輔助開發,都需要團隊成員有著共同的運作認知,讓每個人不至於遺漏資訊,註記幾個基本操作觀念,適用任何專案、產品管理工具:

  • 自言自語:不定時更新自己工作進度的現況到卡片上,以撰寫評論的方式進行紀錄,不要覺得麻煩,這也一種彙整自己思緒的方式,同時也讓資訊保持透明,不會僅維持在與你開會或討論的成員之間而已。有時候看起來真的會像是不斷在自言自語。PM 或其他小隊成員,就算沒參與討論,也可以透過這樣的方式瞭解進度,或提早發掘可能的問題(曝險)。
  • 更新卡片描述:當然,小隊不是每個人都有時間可以將卡片上的評論串爬完,所以記得把評論中最新的情況或規格改變更新回描述上,維持描述在開發流程結束前都是反應最新的決策結果。
  • 更新卡片狀態:在 Sprint backlog 中,亦即將卡片移動到下個列表。讓 Sprint board 一開就可以清楚理解每個卡片的進度。
  • 設定到期日:到期日作為提醒用,作為事情不同段落的檢查時間點。人很難多工又把每件事情都做好,善用工具來提醒,以免一忙或突發事情就忘記回來繼續處理。到期日不是世界末日,但也不別不當一回事。

Trello 操作小技巧

了解幾個 Trello 的小技巧,會讓你工作上更如魚得水。加上 Trello 不斷的改進,目前除了開啟看板上的強化功能外,我已經沒有安裝任何瀏覽器外掛來改善 Trello 不足的地方。當然,還是看每個人、團隊的需求而定:

  • 每個看板啟用 3 個強化功能:一人啟用 Trello 黃金會員,團隊所有看板受惠!一人年費只要 45 美金(或邀請新成員加入 Trello 可免費體驗一個月),該名黃金會員就可以依照看板特性去啟用合適的強化功能,加上 Trello 沒有人數限制,有那一套工具這麼便宜的?啟用強化功能比瀏覽器套件有利的地方,是一旦啟用,所有加入看板的成員都可以馬上享用。避免操作體驗上的落差。
  • 卡片封面:不喜歡圖片附檔顯示在卡片封面佔據太多空間?沒問題,在看板顯示選單→更多→設定→取消勾選「卡片封面照片已啟用」即可。但其實可以善用圖卡或色塊的圖片來作為列表說明或卡片視覺強化,可參考上面提到的 Buffer 文章,裡面有很好的例子。
  • 卡片標籤文字:列表卡片上的標籤文字預設是隱藏,可點按卡片上的色條即可顯示或再關閉文字,參考下圖。養成習慣,為卡片標記標籤,在篩選、搜尋時會方便很多。
顯示或隱藏標籤文字・來自 Trello Help
  • 顯示列表卡片數量:在篩選卡片(快捷鍵:F)鍵入符號,如 . / 等,列表名稱下方就會出現該列表的卡片數量資訊!
  • 建立卡片雙向關聯:以往最 Trello 麻煩的就是建立卡片間的關聯,因為卡片間沒有任何主從關係(Parent、child、siblings)。還好目前可以透過附加檔案的方式來建立雙向關聯。從卡片的附件列表中選擇 Trello 即可附加卡片或看板來建立連結。附加卡片後可在 Trello 附件中找到,只要再按下「連結卡片」即可完成卡片的雙向連結。雖然還是無法做到卡片間的主從關係,但透過卡片狀態預覽,也已經堪用。
連結卡片建立雙向關聯
  • 關閉電子郵件通知:Trello 可針對看板、列表、卡片進行訂閱通知,當活動過於頻繁時,容易造成電子信箱塞滿通知的郵件。近期 Trello 更新了通知中心,可以逐一確認更新狀態再設定為已讀,已足以掉取代電子郵件通知。非常建議去個人檔案設定中,將電子郵件通知更改為「從不」。
個人設定通知選項

本篇小結

使用專案、產品開發工具,不單純為了問題、需求紀錄及進度追蹤,更重要的是資訊的集中、透明所來帶的幫助。至於什麼工具,則看團隊需求、大小來選擇,並不是用 Jira 就比較潮,開發技能可以馬上 +20%。合適的工具可以事半功倍,幫助團隊內的資訊交流更流暢,避免過度複雜的操作流程,造成運作上的負擔,營運團隊也容易因為複雜的功能敬而遠之。

加上大部分的 PM 在產品、營運需求的彙整,總不是在開會,就是在去開會的路上。如何清楚、有條理的收集需求並掌管開發進度是工作相當重要的一環;一心二用或用加班來處理大小事,都不是好的做法。定義有效率的工作流程、共識,可以大大減少拉一大群人到會議室進行冗長會議的次數,讓 PM 或 PO(Product Owner)可以更多時間思考產品策略及願景。

Trello 工具本身並不完美(沒有工具是完美)。

有些人也因為其過於簡單的設定而不知道該如何去使用這個工具,畢竟沒有任何的預設流程,要憑空去想像及定義也是有點不知該從何下手的情況。即使 Trello 彙整了各種看板的變化作為範例,並集成為 Trello 使用靈感,但更覺得應該把這個範例中心整合進建立新看板的流程當中!

本篇僅以過去實際使用經驗(讓 KKTV 這個產品在半年內上線)並綜合網路上各種應用技巧來進行介紹。因為篇幅的關係,其實還有很多細節沒有提到,也歡迎對於 Trello 應用在專案、產品開發上有興趣的朋友,提出你的想法或疑問來進行討論。

註:如果只有一個跨職能的開發團隊,在 Planning 會議上,應該已經對卡片上的每一則使用者故事有詳細的討論;如果有 2 個以上的開發團隊,則依照團隊的目標設定,進行 Sprint Planning 2 的會議,Sprint Planning 1 會議,僅讓全體開發團隊大概了解彼此的工作項目、分工及 Sprint goals 是什麼。

Like what you read? Give Vic Chen a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.