跳到主要內容

管理 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（下）

究竟新創公司應該維持怎麼樣的節奏最有利於創新？最後的結語更加精彩，是 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：匱乏 勝於 豐裕（窮會逼你想到變通方法，有錢人...
張貼留言
閱讀完整內容

敏捷的世界需要一聲驚嘆 - 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 一詞其實就是...
張貼留言
閱讀完整內容

成為讓部屬願意追隨的上司 - 重點摘要（中）

前一篇 文章 提到，因為想羅列出一份有參考性的管理者特質而去參考曾擔任日本知名企業，如： ATLUS 、 TAKARA 、美體小舖、星巴克社長一職的  岩田松雄  所寫的「成為讓部屬願意追隨的上司」一書，這本書文字量並不大，也用了很多生動的例子去說明想說的觀念，花了大約一週便讀完了，以下是第四、第五章的整理，希望能給你一些啟發，也歡迎你在下方留下自己的看法，與我交流。 Ch4. 眾人「情願追隨」的領導者決斷力 多算勝，少算不勝： 避免在尚未得到充足資訊之前就匆匆下了結論，只要在期限內，不必急著做決定。以我自身的經驗，問對問題，找到對的研究方向也非常重要，決斷時，邏輯的正確性可說是基本中的基本，弄錯這個速度再快也沒有幫助。 面子擺一邊： 決策不是為了自己的面子，而是為了公司全體員工必須做出正確的判斷，所以倘若後續有新的資訊進來，應該要毫不猶豫的加以分析、利用，就算是朝令夕改也沒有關係，作者認為決策時不需要考慮身段是否漂亮。就個人的經驗，只要講得出一套合理的理由，相信下屬應該能夠理解的，比較怕的是為了自尊而硬坳，反而會越描越黑，坦承自己也是人，也會有判斷疏失的時候，往往比較能博得下屬的信任。 相信下屬，但不可相信下屬做的每件事： 作者這邊的意思是人不是機器，難免會犯錯，或是對事情摻雜主觀意識，所以就算覺得厭煩還是得反覆檢查。關於這點我並不完全認同作者，因為隨著職位越高，下轄的工作量勢必越來越多，如果每一件事情都要親自檢查，勢必會耗費不合理的時間，我認為取而代之的做法是「價值導向」和「抽查」，前者是指越重要、越不容許失誤的事情就要花較多時間來檢查，如果是較為細小的工作應該分層授權下屬代為查核，甚至是用抽查的方式（例如一週抽一件事情來查核），同時也要利用機會跟下屬同步認知（不是人格上不信任，而是人難免會出錯）。 分清楚事實和個人判斷： 很多人往往會將個人的主觀價值判斷當成是客觀的事實而不自知（例如：「這件事我認為一定是這樣，所以請不用擔心」），進而導致上司基於對情況錯誤的認知在做決策，所以作者會要求下屬先陳述「事實」，再發表個人意見。 主動挑戰，代替猶豫不決： 只要不是會動搖公司根基的事情，如果在審視完現況之後，仍然無法做很好的判斷時（要不要做），領導者自身應該具備挑戰的精神，也應該鼓勵下屬勇於挑戰，領導者也必須勇於承擔最後成敗的...
張貼留言
閱讀完整內容