做不完的專案需求，我們該如何排定實現的順序?

做過專案的你們，一定有遇過在需求訪談後，顧客們對還沒定型的產品，洋溢著過多的想像，透過前面的管理文章中，我們都已經充分的了解到，該如何把每篇排山倒海的需求中，轉換成User story，並在透過這些故事把"想像"轉換成一張張待定實現的"任務"卡片。

 

但實際進行專案後，才發現不管怎麼是用看板還是Scrum，細切出來的工作總是如洪水猛獸般，排山倒海席捲而來，在盤定有限的工時後，「做不完」就轉換成每一段段加班的夢魘，想必這一定是每一位PM和工程師的心路歷程，當然我們都知道不管有再多的人力支援，時間一定還是是有限的，那我們要做的，就是把這些任務和需求，給排定出該實現的優先順序，並且一步一步的把產品架構出來。

 

 

你知道，我知道，當然獨眼龍阿不是，是顧客也知道，但當凌亂的需求一旦多了起來，整理和架構的時間也會隨著遞增，而這也必然會消耗掉我們的工時及人月，如何快速又有效的把需求整理起來呢?在這裡小編分享一招心法。

 

但在分享心法之前，要先分享一招叫做「比較法」的訣竅

 

如果今天我們要替一個人的外表評分，以1-5來做判斷，想必大家對金城武應該都可以給到個帥哥的平均標準3分吧，但如果今天舉例成自己或是街邊的路人呢?想必這個分數就難評斷了，有些人喜歡長髮飄逸，有些人喜歡短髮俐落，有些人喜歡肌肉棒子，有些人喜歡文青書生，今天不管是誰，遇到模糊的分數，大家的評斷一定都會依據喜好來做判斷，而團隊若要針對外表取得共識時，透過這樣模糊的評斷標準，一定就會更難下手。

 

那如果今天把選項變簡單呢，我們設定帥就是要帥同金城武，那判斷就會變得簡單了，你比金城武帥，就是更高分，你比金城武略遜一籌，那就只好忍痛低分了，當然，排定需求也可以用這樣的方式來做判斷，把階級變少，只留下帥、不帥、普通就好，並且運用直覺，才可以把這樣的判斷過程變得簡單，變得快速

 

接下來，我們就針對專案來實戰吧。

 

首先我們把需求攤開來，做成表格吧，並且針對需求的急迫度以及技術難度來做填寫，並依據電子商務網站來做舉例，針對急迫度來做解釋，我們可以用1、2、3這三個等級來做區分，3可以定義為客戶最在意的功能，或是產品的核心功能，那電子商務網站得核心當然就是買商品囉，也就是會影響到產品成形與否的功能，而1就是表示為不重要的，對買東西無直接關係的，可能是一些像是商品排序、篩選等，那就可以直接歸類成1，若無法在第一時間判斷的，我們就把它變成2吧!

 

 

接下來就是難度了，我們一樣可以針對難度做出選擇，例如只需要串接API的功能，或是已經有現成套件可以使用的，就把他歸類成2，作為2的原因是因為中間可能還是有串接上的難度及風險等等，那比他難的，就歸類在1吧，比他簡單的，就歸類在3，接下來大家可以參考下面小編的表格

 

No 功能 急迫度 難度 A 購物車 3 2 B 最愛商品 2 1 C 商品排序 1 1 D 商品頁 3 3 E 結帳 3 2 F 商品搜尋 1 2 G 其他類似商品列表 1 1 H 商品評價 2 2

 

記住，排序的過程，不管你是先定義難和簡單，還是先訂出中間的標準，中間每一個思考的時間，都盡量逼迫自己和團隊可以濃縮在5秒之內做出決定，這個準確度很重要，不僅可以大幅縮短排序的時間，也可以訓練我們對開發的直覺反應

 

接下來的步驟就是重點了，畫出一個座標圖，並且依序標上1、2、3，接著我們把所有開發的項目都填到對應的座標上，從座標圖上我們可以清楚的知道這些開發任務的分配，而開發順序當然是從右上角(急迫度3，最急的，但難度相對的是最簡單的，3)，依序開發到最左下角 (急迫度1，最不急的，但難度相對的是最難的，1)

 

 

除了透過圖形化來展現外，其實還有另外一個方式可以快速對項目做排序，就是把急迫度跟難度進行相乘，也可以得到一組新的數字，而這個數字就是我們的Priority，也就是項目開發的優先度，越高就表示必須要先完成的項目，越低當然就表示可以最後再完成的功能囉。

 

No	功能	急迫度	難度	優先度
D	商品挑選	3	3	9
A	購物車	3	2	6
E	結帳	3	2	6
H	商品評價	2	2	4
B	最愛商品	2	1	2
F	商品搜尋	1	2	2
C	商品排序	1	1	1
G	其他類似商品列表	1	1	1

 

 

有了這個方法，其實我們在開發時，就不容易落入了對優先度無所適從的困境，做過專案的各位想必都了解，我們很容易被客戶的需求及想法給牽著鼻子走，而當然若是都往客戶想要的核心功能做開發時，就很容易落入了傳統開發管理的一個圈套：每一個功能都很重要，但怎麼都這麼難做。

 

而其實對客戶而言，驗收的標準當然不僅僅是他們在乎的項目是否開發完成，有時候就算我們跟他解釋這些核心功能的開發難度有多高，功能有多重要，仍然卻無法贏的客戶的信任及認同，所以這招排序心法就顯得相當重要，不僅可以再開發上保有彈性，也可以讓我們從排序的過程中了解，越重要卻越好做的功能，反而是必須要先行完成的，並透過這樣的排序來做開發，儘管也許交付時我們離產品的成形還有段距離，卻可以成功的讓我們在最短時間內，完成最多的開發任務。

 

 

記得我們交付的，以及客戶在乎的，永遠不是產品的局部功能，而是產品的完整雛形，就算我們用再多的技術語言來做解釋，若是完成的功能及任務不夠多，那產品的形狀永遠無法達成客戶的驗收標準，過去小編也吃過了不少悶虧，所以一起共勉之吧!!加油

 

最後，如果你喜歡我們的文章，別忘了到我們的FB粉絲團按讚喔!!