進度條

我們在找人喔!進度條徵兼職「WordPress與PHP開發者」

有興趣參加進度條的新專案嗎?進度條誠徵「初階 - 遠端兼職」WordPress與PHP開發者。詳情可參考這個連結(請點我)。

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

需求開發如何承先啟後,讓我們用一招心法突破盲腸

作者: Vincent Ke 更新日期:

做過專案的你們,一定有遇過在需求訪談後,顧客們對還沒定型的產品,洋溢著過多的想像,透過前面的管理文章中,我們都已經充分的了解到,該如何把每篇排山倒海的需求中,轉換成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粉絲團按讚喔!!

Medium vincent

Vincent Ke

喜歡把混亂的事情變的簡單 用嘴巴做事其實很可以 但要結合靈活的腦袋思考 就一起來拆解吧