跳到主要內容

管理 Product Backlog 是一門技術活



相信稍微了解過敏捷進行方式的人，都知道負責制定 Product Backlog（產品待辦清單）的人是 Product Owner，這和傳統的專案開發中 PM（專案經理）的工作差不多，要對現有的策略保持『方向感』，除了透過 User Story 描繪想滿足的需求是什麼、驗收標準為何，我覺得最難的是取捨什麼事要優先做，諸多的因素要考量，就算是最老練的產品負責人有時也難免感到力不從心，加上新創公司裡常常瀰漫著一種積極的氛圍，以至於「做比不做好」、「埋頭苦幹最起碼有一些產出物」，這樣的想法很容易就壓過了事先仔細評估的聲音（那些娘娘腔的懷疑論者）畢竟誰能對一個忙得筋疲力竭的人多說什麼呢？

然而，真的是如此嗎？《工作大解放》一書用簡單、不吊書包的方式來向讀者闡明「少就是多」的哲學，在「有時放棄是對的」這個短篇中提及了數個好問題，協助我們判斷計畫要做的事是否至關緊要，每當產生取捨障礙時，可以問問自己...

  1. 為什麼要這樣做？更明確的來說，就是回答：目的是什麼？誰能得到好處？背後動機為何？在其他人提出質疑之前，先把這些基本的問題想清楚吧！
  2. 這解決了什麼問題？問題是什麼？是顧客的疑慮還是你的疑慮？如果這問題以前就討論過了，那客觀條件有什麼改變，導致你認為現在做得到了？
  3. 這真的有用嗎？要怎麼儘早證實？對於網路新創服務來說，現今有很多的科技（例如：Google Analytics、Google Optimize、Sketch、Invision... etc）可以在安排正規軍進場開發之前就能有效驗證所做的假設了。 
  4. 你正在增加「價值」嗎？顧客能從你正在做的事獲得比以前更多的好處嗎？添加東西很容易，但增加價值很難。除了真正找到焦點團體做訪談之外，也該評估做這件事受益的人有多少、要解決的問題發生的頻率有多高，新創公司永遠都有想做的事，它們看起來都能解除某些情境下面臨的問題，但要做取捨就必須靠一把相對公正的尺才有辦法做衡量。
  5. 有更簡單的辦法嗎？問題通常有比我們想像中更簡單的解決方案，只是需要對問題有更深的洞察才行（可以由 PO 帶領跨職能小組一起做腦力激盪）。
  6. 這真的值得嗎？這問題乍聽之下有點像廢話，其實就是總結前述的考量點，再反問自己一些問題，好比：這工作值得全員熬夜趕工，還是可以明天再完成？ 值不值得為對手發布的一則新聞稿而備感壓力？ 這個部分的程式碼有必要現在就全盤優化嗎，還是先做到夠用就好？有時雖然已經付出很多沈沒成本，但那不應該是你做決策時該考量的。

除了優先順序之外，我也參考了篇文章關於如何更好的管理 Product Backlog，搭配自己的實務經驗跟大家分享：

  1. 先弄清楚產品策略：好的 Productt Backlog 應該是和好的 Product Roadmap 一致的，而好的 Product Roadmap 則奠基於一個清晰的產品策略（且文獻中建議 Roadmap 應該三週到三個月檢視一次），關於產品策略要講起來篇幅會很長，我之後會單獨寫一篇關於策略的文章（參考文獻）。
  2. 將 Product Backlog 的數量控制在一個範圍內：在 Product Backlog 中塞入過多的項目（例如：一兩百個）可能會讓事情看起來不可控且絕望，此時身為 PO，可以用以上幾個問題再次審視現在的 backlog，做出取捨，並將項目分門別類，排出項目內最為優先的 5 ~ 10 個項目之外，也要決定大分類之間的優先順序。
  3. 找開發團隊討論：定期找開發團隊一起討論 Product Backlog，這會有助於 PO 釐清一些實作上的工作量、該注意的風險、釐清相依性（這可能會影響該項目的優先順序），將模糊的大故事切分成比較明確的較小故事，也幫助開發團隊更加了解接下來要做的事（因為這些項目大部分將會排入 Sprint 中），也因此有一些敏捷的書上會建議要有一週一小時的 Story Time（故事時間會議）為的就是定期與開發團隊一起消化 Backlog 上的項目。總之，定期「維護整理」Product Backlog 對於 Sprint 的效率是有正面幫助的，小酒館現在的制度也正朝著這個方向演進。
  4. 定期和利益相關者（stakeholders）同步：Product Backlog 應該要為公司帶來價值，所以它不應該是 PO 一個人決定就結束了，應該要和給相關同仁定期討論，以確認這樣的開發項目確實能為他們帶來價值，他們的反饋往往也會是 PO 做決策時的參考來源。
  5. 使之視覺化並排序：小酒館是使用 Asana 這個專案管理工具，其它還有像 Trello、Hygger、 craft 等工具也可以達成類似的效果，Hygger 還將待辦事項分成四個區塊，我覺得滿有意思的，這邊列出供讀者參考，分別是 Time Sinks（耗時又無法帶來立即好處的工作）、Maybes（可以帶來一些好處且工作量不大的）、Big Bets（可以帶來巨大價值但實作也較為費工）、Quick Wins（可以帶來顯著價值又不費工），就實作優先度來說應該是 Quick Wins > Big Bets > Maybes > Time Sinks。

好了，這次的主題是 Product Backlog 管理的種種，大概先說到這邊，也歡迎你與我交流你的想法喔～

留言

張貼留言

這個網誌中的熱門文章

敏捷的世界需要一聲驚嘆 - AHA Manifesto（上）

前言 上週二參加了一場預先不太清楚主題是什麼的 分享會 ，是由一位敏捷社群的大大邀請的，這次的活動有幾點引起我的興趣： 名額極為限量，主辦單位想排除掉一些已經聽過類似主題的人，把機會讓給沒聽過的，感覺機會非常難得。 活動禁止拍照、錄影、錄音（後面結語時例外）。 活動介紹頁不斷的提到 AHA 這個沒聽過的詞彙，網路上也查不到。 在介紹的末尾寫到：「本次分享不太適合大公司的螺絲釘員工、只願意沉溺於技術細節的工程師、只浮於抽象層面不願意解決實際問題的老司機、自己不改變只想改變別人的Change Agent。」 上述的種種吊足了我的胃口，而且門票只要 300 塊，買不了吃虧、買不了上當，便心一橫決定去聽看看。 由於時值下班尖峰時間，當天我大概晚了十分鐘入場，一坐下就感受到這場講座與眾不同之處，講者 Daniel 是一個能量四射的天才，而且場子並不大（大概 30 多個人），所以他和台下的互動非常頻繁，大概是講五句話就會問台下一個問題的狀態，一般來說台下聽眾都會和講者有一段距離，所以這種問答往往只有小貓兩三隻，更慘一點就自問自答，但 Daniel 透過他對講題的熱情，還有逗趣的反應（BTW 台下似乎有很多人認識他）， 在過程中你會不自覺感染他對於自己在做的項目 - G2Rail.com （一個提供多國鐵路票券的訂票網）的熱情，很自然的試著回答他的問題，隨著他熱情的分享很自然的將他三年來如何迭代演進這個網站的歷程很生動的走過一遍，最後半小時再聽他總結從這些裡面獲得的 AHAs，高潮迭起，整個過程 3.5 小時（從 6:30 一路講到 10:00 ）幾乎沒有人起來上廁所，講師也沒有要中場休息的意思，是我人生中罕有的聽講經驗。 講座內容 他講了什麼？我覺得用簡單的話來形容是「一個有快速程式實作能力的商業駭客，如何駭入鐵路票券販售的商業空隙」，如果按照一般的分工，應該會有 PM、UI 設計、前後端工程師，甚至是做系統架構的人，還有客服人員、使用者資料分析師負責接收反饋意見，但在 G2Rail.com 這些事情全給 Daniel 包辦了，兼之他又是創辦人之一，有足夠的決策權，每天都可能有新資訊進來、新的領悟、新的想法產生、新的功能上線，所以他在過去這三年的迭代有多快，學到的東西會是一般正規團隊的幾倍速可想而知，而所謂 AHA 一詞其實就是...
張貼留言
閱讀完整內容

敏捷的世界需要一聲驚嘆 - AHA Manifesto（下）

究竟新創公司應該維持怎麼樣的節奏最有利於創新？最後的結語更加精彩，是 Daniel 這三年創業在不斷嘗試中歸結出的心法，我想對於每一個產品人、商業策略制定者，乃至於工程師都很有幫助： AHA Inhibitors（抑制創新的因素） Prediction & Perfection：過早試圖預測與最佳化、加入很多 KPI 和 Metrics（衡量指標）、加入很多組織架構，這些都會讓事情變得不好玩，Daniel 的玩法是有了想法要搞獨奏，不依賴他人能力、自身快速迭代，他稱之為「Playful Solo」，就像一個人在獨奏某樣樂器似的那樣忘我，當然啦，我覺得這點會隨著組織狀況和個人能力不同而不同，一個多元能力的人要搞獨奏容易，但一群人要同時進入這種狀態，能一同往好的方向創新，那又是另一個層次的問題，但不論組織大小如何，就個人經驗來說的確過度預測和最佳化多半只是為了讓自己安心而已，並不能為事情帶來實質幫助（還記得 之前這篇 寫的暑假計畫表嗎？）。 Knowledge Shield：這邊指的是組織中有太多的專家，他們對於某項東西已經太熟了，以至於對任何創新的點子都多少帶有成見，讓一些想法在萌芽階段就被各種抨擊打掉了，所以他認為組織中應該要有專家 / 創新者的平衡，不具備專業但具備研究辦法的人是很需要的。 Concrete Reasoning：要有推論，但不要鑽牛角尖，決定論也會扼殺創意。 Velocity vs Speed：追求速率的同時要看看是否在正確的方向上，否則速度再快，方向錯了也無濟於事，去思考看看你的工具箱中是否有不同維度的工具，而不是用人工去拼，如：把 Jenkins 自動部署轉個彎，便能自動化生成多國語言文章。 AHA Manifesto（創新宣言，仿敏捷宣言格式 XD）： Trivial & Detail over Big & Abstract：瑣碎的具體細節 勝於 大且抽象的概念，捲起袖子去做很多具體而微小的事，不要整天吹高大上的概念。 Continuous over Do It Once：連續性的執行 勝於 一次做完（他會一件事先做一點，想一陣子再做一點，很像敏捷的小量快速迭代），做很多重複且具聽的事。 Shortage over Abundance：匱乏 勝於 豐裕（窮會逼你想到變通方法，有錢人...
張貼留言
閱讀完整內容

敏捷治百病？我只知道敏捷治好我的拖延症

前言 上週受朋友之邀到某知名企業做敏捷文化的分享，雖然只是企業內部的內訓課程，人數並不算多，但能藉由這個機會整理一下近三年來接觸的敏捷相關知識，又能了解大企業內部導敏捷遇到的困難點，我其實滿期待的，為了準備這次分享，六月以來讀了大量的參考資料以及參與了幾次敏捷社群的聚會，慢慢在腦中建構了和那些不同於我平常工作所熟悉的例行性會議（如：Daily Scrum、Sprint Review、Sprint Planning、Retrospective...等）的幾個核心信念，分別是：價值導向、自組織團隊、快速迭代與調整、實際互動，其中我特別留下深刻印象的是「快速迭代與調整」這點，而之所以會產生深刻的印象，是因為七月底的去聽的一場演講 -- David Tung 董大偉  主講的 Agile work x Agile life ，裡面提及的一個新穎的觀念叫做「人生敏捷法」，和我這幾年來對抗拖延所悟出的心法有 87 分像。 那些年的暑假計畫 其實長期以來自己都不是那種可以按步就班完成事情的人，小時候每到暑假，大概從國小高年級開始一直到高三吧，大多頭一個禮拜家父就便會找我去訓話，大意就是說如果沒有好好規劃這段時間，日子很快就會過去，然後接著就要面對現實的高中、大學聯考，沒有充分準備的話很難考到理想的學校，沒考到理想的學校就會失去競爭力，時間很快就過去，最終會成為漫無目的的大人... 等等，話都說到這份上了，我終究只能配合來列出一張暑期計劃表，上面就是按日期排列的格子，然後下面列出當日要做的事，一直列到八月底暑假結束，大概就像下圖： 出處： https://christine327324.nidbox.com/diary/read/9785159 但就實際結果來看，這樣的計畫沒有任何一次真的發揮它的功效，總是第一天完成度最高，接著開始逐日遞減，直到最後和我的實際生活完全脫鉤 XD，當然最終暑假作業還是必須得交出來，但往往都是最後半個月才在趕，暑假作業目的就是設計來讓我們溫習或是預習用的，最後半個月的囫圇吞棗效果其實並不太好，如此一來變成前面的時間沒好好玩到（因為心裡會一直惦記著計畫沒做）後面應付式的學習成效很差的困境。 上述的情況一直延續到於出社會的這幾年，當然非得做的事情會趕在 deadline 之前做好，但對於那些長期來說真正重要...
張貼留言
閱讀完整內容