跳到主要內容

管理 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 管理的種種，大概先說到這邊，也歡迎你與我交流你的想法喔～

留言

張貼留言

這個網誌中的熱門文章

[演講摘要] 組織變革中的模式與迷思（下）

延續上一篇「 組織變革中的模式與迷思（上） 」，這篇我們繼續來看看有哪些有趣的觀點。 Myth #3：If I just had enough power I could make people change. 第三個常見迷思是 -- 如果我是主管、CEO 那麼我就可以促成別人改變（要是你不敏捷我就解僱你），用威脅的確會造成改變，但僅只是表面遵從（compliance），內心並不相信，無法讓員工真正獻出他的精力、創造力、創意... 等全心投入（commitment）他只是做，因為他必須做。 老闆多半希望員工「投入」而非「遵從」，當你掌握群眾的心，這才是你擁有力量的時候，當員工只是一昧「遵從」，此時用於監督的費用（間接費用）會越來越大，非常貴（例如：微軟在某個時期會為每個工程師配置測試師，軟體維護的費用隨時間過去有增無減），因為人們會假裝做那些你希望他們做的，但實質上並不認同，此時檢核的成本很高。作者這邊提出「與成功有約」一書中的金句： You can buy a person's hand, but you can't buy his heart. His heart is where his enthusiasm, his loyalty is. You can buy his back, but you can't buy his brain. That's where his creativity is, his ingenuity（獨創性）, his resourcefulness（機敏）. 你無法透過「遵從」得到上述這些。要讓一個人完全投入，你得要解釋  新觀念對他個人有什麼好處  才行。採用新觀念時，群體會分成五類人，採用時機不同： 1. Innovators（2.5%）：This is new so it's cool.  --> 那些一開始就非常喜歡新概念的人。 2. Early Adopter（13.5%）：It's interesting, but I want to learn more.  -->  具開放態度，要看過提出的證據和事實、誰採用過，再來決定是否跟進。 3. Early Majority（34%）：I want to know what oth...
張貼留言
閱讀完整內容

敏捷的世界需要一聲驚嘆 - 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：匱乏 勝於 豐裕（窮會逼你想到變通方法，有錢人...
張貼留言
閱讀完整內容

權力？領導力？傻傻分不清楚

自從當了 小酒館 的工程部主管後，管理上產生了一些力不從心的情況，在 CEO 花水木 的推薦下接觸「 寧向東的管理學課（得到APP） 」，每天大約十分鐘的管理學相關音頻配上課後作業，滿符合工作繁忙的現代人，用中午吃飯或是通勤的時間便可聽完，晚上工作吿一段落時，再好好思考課程中提出的問題，透過思考得到更多收穫，之後會在這裡持續分享我聽到覺得還不錯的管理課程內容（揉合自己的看法）。 究竟要怎麼成為一個好的領導者呢？我想辦法無非就是精進自己的領導力，所以我第一篇就來探討一下權力和領導力的相對關係（主要對應 「寧向東的管理學課」第 26 講）。 權力不等於領導力 很多人認為當了領導，行使職位賦予的權力便有了領導力，其實並不然，行使權力不等於具備領導力，我們接著剖析一下權力這個東西： 按照古典管理學的定義，權力分成五種，而職位帶來的權力大致上有三種： 1. 法定權力 ：指派下屬工作，指導他們工作細節的權力 2. 獎賞權力 ：透過獎賞激勵下屬的權力，甚至決定其報酬的增減 3. 強制權力 ：若不滿意下屬的工作表現，提出批評，要求其改善的權力，若遲遲未見改善也有懲罰他們的權力 感覺以上這三種權力就足以使下屬配合，然而實際的情況卻沒有這麼簡單，回想一下學生時期，學校裡成功的老師靠的是校規約束所以學生必須坐在位子上聽課，還是因為教得好學生自然認真聽課？按照上述三種權力，如果缺課現象嚴重，老師可以訓話、點名、增加小考次數、提高考試難度... 等，但上述作法往往會引來學生的反感，最後學生是基於對權威的懼怕而來上課的，人坐在那但心不在焉，授業的初衷很可能沒有達成。 要解決上面的困境，我們考慮權力的另外兩種來源： 4. 專家能力 ：領導者在某個領域夠專業，讓人服氣願意跟隨 5. 個人魅力 ：一些個人特質（相貌、談吐、性格... 等），讓下屬與之互動時感到愉快，願意追隨 以上兩種權力和職位無必然關係，且因為這兩種權力來源不需組織賦予職權，對追隨者的影響力更大、更持久，會真正走入人的內心，所以寧向東老師在這邊稱它們為「 更高明的影響力 」。 為了加深印象，課程裡提到大陸著名的英語培訓學校「 新東方 」剛創辦的時候，曾有一位北大的老師來代課，學生不買賬，紛紛表示聽不下去，創辦人俞敏洪約談他時，老師這麼說：「我在北大就是這麼講課的，你應該要嚴格要求...
張貼留言
閱讀完整內容