排定優先順序

作者 Mitch Lacey。 擁有者 Mitch Lacey & Associates, Inc，是一家致力於 agile 和 scrum 採用及改進的諮詢公司。

2012 年 1 月

在本文中，Mitch Lacey 討論三個經證實非常有利於許多敏捷式軟體開發團隊的方法：Kano 客戶滿意度模型、Luke Hohmann 的一系列 Innovation Games，以及 Karl Weigers 的相對加權模型。 這其中任何一項都可以協助您從粗略的待處理項目優先權轉移至精確的排序，以充分權衡風險、重要性和客戶滿意度。

套用至

Application Lifecycle Management；Team Foundation Server

本文內容：

• 簡介

• Kano 客戶滿意度模型

• Innovation Games

  • 修剪產品樹

  • 購買功能

• 相對加權 - Karl Weigers

• 結論

為了保持 Agile 小組的工作效率，您必須依優先權排列產品待處理項目中的項目，然後隨著專案進展來更新這些優先權。 所有產品待處理項目都必須根據商業價值和風險來排列優先順序。 透過辨識這個優先順序，您的小組就可以更加專注於最可能列為產品成功因素的功能。 井然有序並已排列優先順序的待處理項目不僅在小組和客戶滿意度上表現卓著，同時也在營業的損益中獲得報償。 如需待處理項目的相關資訊，請參閱建置和管理產品待處理項目、建立待處理項目及整備與評估待處理項目。

當排列產品待處理項目的優先順序時，您必須考量許多因素，並能夠對決定做出合理解釋。 當您開始處理原始產品待處理項目時，這個程序看起來幾乎令人不知所措。 還好您不必立即就要完美地排列待處理項目中的每個項目。 在評估中，我提到一項稱為「大圍牆」(The Big Wall) 的技術，這是快速評估原始產品待處理項目，並與專案關係人合作取得粗略優先順序的有效方法。

這個粗略的優先順序是很好的起點，可能適用於您的情況。 不過在某些情況下，您可能會想要改進這些優先權，或是以更科學的方式取得排列優先順序的待處理項目。 您可以使用許多方法來達成目的。 在下列文章中，我將討論三個經證實非常有利於許多 Agile 小組的方法：Kano 客戶滿意度模型、Luke Hohmann 的一系列 Innovation Games，以及 Karl Weigers 的相對加權模型。 這其中任何一項都可以協助您從粗略的待處理項目優先權轉移至精確的排序，以充分權衡風險、重要性和客戶滿意度。

Kano 客戶滿意度模型

Kano 客戶滿意度模型是東京理科大學教授狩野紀昭於 1980 年代開發的模型。 他的模型提供可區分基本和不同屬性的簡單排名配置。 這個模型採用問卷，是以視覺化方式檢視產品特性並在設計小組內激發討論的強大方法。

在 Kano 中，我們會詢問一連串兩種不同形式 (功能和功能缺失) 的問題。 例如，假設我們詢問客戶對汽車 GPS 導航系統的看法。 我們先詢問功能型問題：

• 如果這輛汽車有 GPS 導航系統，您覺得如何？

我們限制回答下列答案：

• 我喜歡那樣

• 這在我的預期之內

• 不好也不壞

• 有也不錯

• 我不喜歡那樣

在這個範例中，假設我們的虛構客戶回答「我喜歡那樣」。

接下來我們將詢問功能缺失型問題：

• 如果這輛汽車「沒有」GPS 導航系統，您覺得如何？

我們的虛構客戶可以選擇列出的任何答案。 不過，答案往往且通常會不同。 在這個範例中，假設我們的虛構客戶針對「功能缺失型」問題回答「這在我的預期之內」。

當我們針對實際專案這麼做時，可以對多個客戶群組詢問這份相反問題清單，這裡的客戶群組指的是代表客戶組織中不同部門之不同個人所組成的團體。 您可以有一個行銷群組、一個會計群組、一個製造群組等。 不過，為了解這個模型，假設我們只向一個客戶群組詢問一個問題。 當我們收集好對功能型和功能缺失型問題的一組答案之後，我們會將這組答案對應到方格中，如表 1 所示。

表 1 - Kano 對應

請注意，在範例中，我們的虛構客戶對功能型問題回答「喜歡」，對功能缺失型問題則回答「預期」。 當我們將這組答案對應到方格時，我們可以看到這兩個屬性的交集為 E (如黃色醒目提示的方形所示)。 讓我們來討論這對排列優先順序的待處理項目有何意義。

• E = 刺激者 (Exciters)。 這些是客戶未預期的功能，也是讓這項產品與競爭對手與眾不同的功能。 它們不容易識別，特別是在一開始時，因為很難提出引發有趣功能的問題。 因此，刺激者通常會隨著專案進展及客戶開始提供意見而浮現，並且優先權愈來愈高。

  • 客戶會從這些功能獲得極大滿足，因此願意多付一點錢來擁有它們。 例如，Apple 的 iPod 因為具有配合螢幕方向轉動內容的直覺式功能而深受客戶喜愛。 不過，由於客戶不知道要有所期待，因此缺少這項功能並不會降低滿意度。

  • 在範例中，GPS 導航是有趣的功能。 探索這項功能 (至少到達會收到客戶意見的地步) 應該會有相當高的優先權。

• B = 基準。 這些功能必須包含在產品中， 也就是必備、高優先權功能。

  • 無論這些基本屬性的執行狀況多麼良好，客戶對產品都保持不好也不壞的看法。 例如，文字處理器必須具有「建立文件」和「儲存文件」的功能。 這些功能是入門的代價。

  • 如果我們詢問客戶群組對安全帶的看法，大多數人會回答他們「預期」新車會配備安全帶，並且他們「不喜歡」沒有配備安全帶的汽車。 如果我們將這兩個答案對應到方格，會發現安全帶屬於基準 (B) 必備功能。

• L = 線性。 線性功能 (又稱為效能需求) 會直接與客戶滿意度相互關聯。 它們的優先權剛好在基準功能之下，但必須與其成本保持平衡。

  • 增強的功能或提升的執行品質會增加客戶滿意度。 降低的功能會減少滿意度。

  • 產品價格通常與這些屬性相關。

• I = 無關緊要. 這些功能對於客戶而言最不重要，因此對於產品而言也最不重要。 這些功能可能完全沒有商業價值，或商業價值很少。

表 1 還顯示 Q 和 R。

• Q：不確定 - 問題可能不正確，或答案不可信。

• R：立場相反 - 該組答案不合理。 以 GPS 導航系統為例，如果有人回答這在預期之內，卻又回答沒有也喜歡，則屬於 R 答案。

如果答案組列為 Q 或 R，您應該更深入調查問題或答案組。

Innovation Games

Innovation Games 是協助您發展主要市場調查的工具。 客戶可以利用這些工具玩「遊戲」，其目的是為了產生有關產品或服務的意見和投入。 Luke Hohmann 在其所著《Innovation Games》一書中建立並說明 12 種以上的遊戲，這本書值得任何圖書館收藏。 我最喜歡玩的兩個排列待處理項目優先順序的遊戲是「修剪產品樹」(Prune the Product Tree) 和「購買功能」(Buy a Feature)，Luke 在該書的這段摘錄中提供說明 (經許可使用)：

修剪產品樹

園丁會修剪樹木來控制其生長。 有時候修剪是項藝術，修剪後的灌木形狀可能會類似動物或有趣的抽象圖案。 但大多時候，修剪的目的是為了平衡樹木，以生產高品質的水果。 這不是「剪下」的程序，而是「造形」的程序。您可以使用這個隱喻來協助建立客戶想要的產品。

遊戲

首先在白板或牛皮紙上繪製一棵大樹，或是像大型海報那樣印出樹的圖形。 粗樹幹代表系統中的主要功能區。 樹的邊緣 (最外側的樹枝) 代表目前版本中可用的功能。 在數張索引卡上寫下可能的新功能，索引卡最好使用葉子形狀。 請客戶在樹上放些想要的功能，並定義成長的下一個階段。 這些功能所建構的樹是否以平衡的方式成長？ 是否有哪根樹枝 (或許是產品的核心產品) 的成長幅度很大？ 樹木未充分使用的部分是否會變得更強韌？ 我們知道樹根 (您的支援和客戶服務基礎結構) 至少需要延展到與天同寬。 您的是這樣嗎？

產品樹 - Hohmann

為何有用

您和客戶都知道功能的重要性有所不同。 因此，我們通常會想在最重要的功能背後投入大量心血，也就是提供客戶最大價值的功能。 可惜的是，有時候這表示我們在完成產品所需的功能背後投入的心血太少。 「修剪產品樹」遊戲提供客戶一個方法，藉由整體查看組成產品的一組功能，為決策制定流程提供意見。

購買功能

哪一項功能會誘使客戶購買您的產品？ 哪一項功能會促使客戶升級？ 哪一項功能會讓客戶樂於忽略或容忍他們希望您修正或移除的其他功能？

產品規劃人員一直以來不斷地在討論這些問題和其他類型的問題。 選擇要加入發行版本的一組正確功能，通常是造成您短期失敗或長期成功的原因。 可惜的是，太多產品規劃人員在選擇時沒有加入影響最深遠的人員意見，那就是他們的客戶。 「購買功能」遊戲藉由邀請客戶協助您制定決策，來改善這項決策的品質。

購買功能 - Sterne

遊戲

建立可能的功能清單，並提供各項功能的價格。 就像是實際的產品，價格可以根據開發成本、客戶價值或其他原因來訂定。 雖然這個價格可以是這項功能要收取的實際成本，通常這不是必要的。 客戶使用您提供的虛擬貨幣，購買他們希望在您下一版產品中推出的功能。 確定某些功能的價格訂得夠高，使得沒有任何客戶會購買。 鼓勵客戶集資購買特別重要和/或昂貴的功能。 這有助於鼓勵客戶就哪項功能最為重要進行協商。

這個遊戲最適合四到七個客戶組成的群組，以便您可以創造更多機會，讓客戶透過協商來集資。 不同於「產品包裝盒」(Product Box) 遊戲，「購買功能」遊戲是以開發藍圖中可能會有的功能清單為基礎。

為何有用

產品規劃人員通常會誤以為客戶已清楚定義產品優先權。 雖然有些人是如此， 大多數人則不然。 當出現一組選項時，許多客戶只會說「我全部都想要」，然後將排列要求優先順序的責任丟給您。 或者，產品經理通常會與客戶一對一合作，並在程序中收集功能優先權，但可能甚至不知情就再次承擔排列功能優先順序的責任。 您可以將客戶當做群組成員來共同參與，並提供他們有限的資源，讓客戶有機會以群組成員的身分排列其需求項目的優先順序。 但不只如此， 透過建構交談，您的客戶還可以針對特定功能彼此協商。 正是這個交涉，讓您進一步對客戶真正需要的是什麼有所了解。

相對加權 - Karl Weigers

排列優先順序的另一個好方法是 Karl Weigers 於 1999 年所引進的「相對加權」(Relative Weighting)。 這個方法不僅提供根據使用者投入和意見排列需求優先順序的機制，也包含小組的專業判斷。 就像 Kano 模型和 Innovation Games 一樣，相對加權可讓產品擁有者更精確估量要實作哪些功能以及依照何種優先順序。

第一個步驟是對功能的相對效益指定加權。 效益是使用者在最終產品中具有這項功能的優點。 接著指定相對損失。 損失是使用者在最終產品中沒有這項功能的結果。 (評估效益和損失可達成與 Kano 方法之功能型和功能缺失型問題同樣的效果。)加權是任意數字，代表您的公司如何評估功能的效益和風險。 這很像是老師如何判斷指定給決定整體成績之功課、出席率、小考和測驗的加權；加權會因老師而異。 如果您決定效益遠大於損失，請將效益的加權設得比損失的加權高出適當的比例。 如果您決定損失遠大於效益，請相應調整加權。 在表 2 的範例中，我們指定效益的相對加權為 2，而損失的相對加權為 1，表示效益在決定最終優先權時是較大的因素。

我們以同樣方式來決定成本百分比和風險百分比的加權。 在下列範例中，風險不是專案的主要顧慮，因此得到的成本百分比加權為 1，而風險百分比加權為 0.5。 (請注意，雖然效益和損失是在計算價值百分比之前進行加權，成本和風險還是以百分比進行加權。)如果您有高風險的專案，您可能將風險加權高過成本。

設定好加權之後，我們請每位使用者對每個功能的相對效益和相對損失評分。 每個效益和損失會依照既定的等級來評分 (Weigers 建議使用 1-9)，但您可以選擇不同的等級，只要一致就好。 相對效益是這項功能所提供的價值，而相對損失是未執行這項功能的潛在負面影響。

例如，假設有一個可能的功能是「使 Widget 符合沙賓法案的規定」。這對使用者幾乎沒有相對效益，但對公司的相對損失卻很大 - 「不」執行這項功能可能會使公司停業。 因此，我們可能會看到相對效益的分數為 1 或 2，而相對損失的分數為 8 或 9。

在下列範例中，使用者將「查詢廠商訂單狀態」功能的相對效益評分為 5， 並將其相對損失評分為 3。 為了衍生出該功能的總值，我們將兩個數字乘以其相對加權，然後相加：

(Benefit * Weight) + (Penalty * Weight) = Total Value

(5 *2) + (3*1) = 13

在這個範例中，這項功能的總值為 13 點。

當我們取得這項功能的總相對值和值百分比時，我們將焦點從使用者轉移到「小組」，了解小組的見解。 我們請小組使用相同的等級，來評估實作每項功能的相對成本。 Karl Weigers 說明：「開發人員會根據各種因素對成本進行評分，例如需求的複雜度、必要的使用者介面工作範圍、重複使用現有設計或程式碼的潛在能力，以及需要的測試和記錄程度。」

在評估相對成本之後，我們會評估相對風險。 Weigers 再次重申：「開發人員會以 1 到 9 的等級，來評估與每項功能相關之技術或其他風險的相對程度。 評估為 1 表示您可以輕鬆編寫程式，而 9 表示非常重視可行性、具備所需專業知識的人員可用性，或未經驗證或不熟悉之工具和技術的使用。 試算表會計算每項功能的總風險百分比。」

記下相對效益、損失、成本和風險的值之後，我們會總計每一欄。 所得總計會用來計算百分比。

• 總值百分比：將相對效益和損失的總和值除以最下方的總和。 在下列範例中，結果是 13 / 154 = 8%。

• 相對成本百分比：將相對成本值除以最下方的相對成本總和。 在下列範例中，結果是 2 / 42 = 4.8%。

• 相對風險百分比：將相對風險值除以最下方的相對風險總和。 在下列範例中，結果是 1 / 33 = 3%。

• 優先權：將值百分比除以 (成本百分比 * 成本加權) + (風險百分比 * 風險加權)。 在下列範例中，結果是 8.4% / ((4.8% * 1) + (3% * 0.5)。 如此可求得優先權值 (1.345)。

取得優先權值之後，我們會依遞減順序排列優先權欄位，讓最高優先權的項目出現在最上方。 當項目加入產品待處理項目，或是出現更多劇本的相關資訊時，我們需要重新評估優先權。

最後，工作表看起來就像是這個表格：

透過這種方式，您可以深入了解小組和專案關係人的適用範圍。 這也有助於提供較好的討論依據，因為客觀分析產品因素 (例如效益、損失、成本和風險等項目) 可能很困難。

Weigers 說明如何讓模型更符合現實：

「根據舊版產品中的一組已完成需求或功能，校準這個模型以供您自己使用。 調整加權因素，直到計算後的優先順序與您對需求在測試集中之重要性的追尋事實 (after-the-fact) 評估一致。 當您評估建議的新需求時，這個模型也可以協助您進行取捨。 使用這個模型評估其優先權，告訴您這些需求與現有需求的吻合程度，讓您可以選擇適當的實作順序。 您可以採取任何行動將需求的優先順序從政治舞台移至客觀分析的領域，這都會讓專案更能夠以最適當的順序交付最重要的功能。」

Karl Weigers 已撰寫兩本書，更詳細說明相對加權：Software Requirements (第二版) 和 More About Software Requirements: Thorny Issues and Practical Advice。

無論您是使用這些方法的其中之一或其他方法，請記住產品待處理項目是會變的。 您不能只排列一次優先順序之後就加以忽略。要保持良好的待處理項目，就必須重新排列優先順序。 為了確保專案依照進度完成，您必須不斷重新評估劇本、劇本對專案的重要性，以及新資訊對待處理項目所造成的影響。 您必須盡力讓專案關係人和客戶參與整個專案。 此外，您必須記住，項目的評估對決定其優先權來說是不可缺的。 不要讓您的待處理項目變成過時和無效。 投入時間和精力在維護和整備您的待處理項目，您不僅會在最終產品上，也會在您的營收上看到成果。

請參閱

概念

共同作業 (更深入的探究) [重新導向]

共同作業 [重新導向]

要求和檢閱利害關係者意見反應，藉由使用Team Web Access

追蹤工作和管理工作流程 [重新導向]

1. Agile Software Requirements, Dean Leffingwell, Addison Wesley

   “Attractive Quality and Must-be Quality” Noriaki Kano, Quality JSQC, Vol. 14, No.2, October 1984. Kano 的原始文章。

2. Karl E 的 First Things First: Prioritizing Requirements Wiegers