進度條

專案一直被修改?可能是沒有找到客戶真正的需求。

正因為客戶不了解專業,所以才會花錢請專業的來解決。

作者: Vincent Ke 更新日期:

還記得上一篇的案例嘛?

傳送門:與客戶談需求時,我們應該先談什麼?

 

在兩個月的時間內,完成一項大型零售企業的官方APP開發,在前次需求訪談裡,我們已經釐清了對方的預算和期程。

 

"五十萬,兩個月APP要上線"

 

 

 

當大方向和目標已經擬訂之後,接著就要切入會議的重點了,也就是"需求的重點"

 

要做什麼(what),要給誰用(who),為什麼要做(why)。

其實就是在網站開發上最常使用的開發導向法則,也是所謂的需求模型建立(Requirement Modeling)

 

這就是Requirement Modeling的3W原則,透過模擬使用者最真實的模樣,來定位網站最真實的需求,以及相因應要開發出來的功能。

 

當然功能的複雜程度也就是我們抬高產品價格及時程的扣打,只是在這中間,更必須要和客戶的預算及時間做拉扯,當中若是越有模糊的地帶,卻容易在產品開發前夕,產生出糾結與紛爭。

 

 

千萬要記得,不是每一個問題客戶都有辦法給我們答案。

在供需法則裡,正因為客戶不了解專業也沒有預算和人力來了解何謂專業,才會把需求(開發)外包,這也是我們在這裡討論的主要原因。

在詢問之前,究竟我們該怎麼做,才可以切中要害的得到我們想要的答案。這不單只是專業的展現,更多了些溝通的邏輯和技巧。

 

(用錘子捶螺絲、用板手轉釘子)

 

「釐清問題的模型-單刀直入,再套用3W原則」

 

根據Standish Group的調查,近10年軟體專案成功率都不到3成,美國一年約損失500億美元於不良專案。

 

在民國97年,國內主計處也對台灣二百多家政府機關作了幾次類似的調查,最近一次的數據是,六成多的受訪單位曾 發生專案無法如期驗收的情況,其中「需求變更」 與「需求不明確以致雙方認知不同」是起因的第1、 2 名,各占四成之多。(參考文章)

 

 

如果我們把技術分成各種不同的車款,也許Java就像是Toyata,而React就像是特斯拉,但是不管我們開什麼車款,應該要先考慮我們要開往哪裡,目的為何,接著在思考多久要到,多少預算,來決定我們要從哪一個車款下手,才可以對「問題」對症下藥。

透過產品導向來釐清主要的期程和開發預算,是必須解決的當務之急,就像買車前,一定要先釐清用途和預算一樣。

 

 

那又該怎麼釐清「問題」呢?

 

 

通常問題可以被區分為3大W

WHO:誰

WHAT:(這個需求)做甚麼

WHY:為什麼(要這個需求)

 

 

而這3大W就是會影響專案的三大要素

"期程(時間)"、"成本(價格)"、"需求(功能)"

 

 

每一個專案(或產品),都在和上面三大要素做拉扯,但產出必須切中需求,還需要符合成本,我來舉一個例子吧!

 

 

「問題就像解題任務,只有分析完才明白下一步要做什麼」

 

 

相信有玩過網路遊戲的你們,一定對解任務這個詞彙並不陌生

"我們的村莊飽受北邊的盜賊叨擾,請你一定要制裁他們"

 

此時若是接受任務,就會發現這些被分析過後更明確的指示

"請勇者(who)去北邊打倒盜賊首領(what),來解決村莊被騷擾的問題(why)"

 

 

而時間就是我們一天遊玩遊戲的總時間,估算成8小時來計算的話,那我們可以有多少的利潤,就要來看這些需求任務的CP值高不高。

當然任務時間和獎勵,就靠對遊戲經驗老道的你來決定是否承接這個任務,如果我們可以簡單扼要的打倒首領,也許就可以短時間內領取高額獎金,這樣就可以被被歸類在高CP值的任務了。

 

 

但倘若把任務修正如下:

 

"請勇者(who)去北邊打倒50個盜賊(what),來解決村莊被騷擾的問題(why)"

"hmmm..,打死一支盜賊可能要2分鐘,這樣需要至少100分鐘來解這樣的任務,這個What似乎有點不划算呢。"

透過明確的方式來把時間和成本分析化,做為我們決策分析的最大權重,才可以在有效的時間內,去創造出最大的利潤。

 

 

 

「活用經驗法則,來思考現實案例的時候,我們該怎麼抉擇」

 

 

回到我們的問題案例本身吧!

 

「客戶表示"我們主要是想要貴公司開發一個APP,如同市面上的網購APP,可以購買公司的產品,並且要可以有效管理產品庫存和上下架,兩個月開發完成,預算為50萬"」

 

各種應用面的擴展和零瑯滿目的功能,都只是客戶想要產品裡面附加的應用價值,而產品本身其實相當單純:一個APP可以前台購買商品,而我們也研判需要讓客戶可以上架商品販售。

 

在此先進行重點歸納

 

1. 前台APP必須可以販售商品,馬上套用3W原則來進行分析

Who:網站會員

What:購買、下單

Why:實現購買需求

當然若是直接照著這樣的架構來開發當然是NG的,商品哪裡來,資料從哪裡串,這些都是伴隨著3W裡面會出現的疑問,也就是不在規格書載明的「隱性問題」,我們一樣透過3W點列出來。

 

 

2. 後台系統上架

Who:店家(就是客戶)

What:商品上架,增加庫存

Why:把商品上架到網站上

 

這就是這次專案的基本盤,一但把這兩點攤開,我們才有跟客戶對談的籌碼

 

「在50萬元的預算和兩個月的期程內,這些基本盤到底做不做的到」

 

若是建置兩套系統,開發時間和預算也會隨之提升,更別提後台管理是不是還有權限,登入,檢視購買歷程等等。

這些都是系統開發上會遇到的地雷,若是沒把問題釐清,只會在交付產品時產生更多不必要的爭執。而其他附屬價值的華麗功能,在主要產品開發完成前,實在非屬必要。

 

 

而拿捏公司開發資源以及現實面的考量後,在兩個月的時間裡,光是開發一個APP(包含設計)就相當吃力。更別提到後台系統需要使用的server成本以及開發資源,而身為資深專業RD的我們,更應該在得到訊息的時候,馬上把「我們的疑問」給拋出來。

 

 

 

「不要勉強,畫大餅,不如直接把問題實際化」

 

百分之九十的客戶,對自己產品本身的模樣一定是模糊的,但團隊所想像的模樣,未必和客戶所期望的會相符相成。會議一定要有結論,在一定的時間及預算內,可以作什麼,作不到什麼馬上劃分。一來是保護開發團隊不用陷入加班地獄的迴圈,二來也是保護客戶在期程內可以得到他們期待的商品,先和客戶對產品的需求,有了基本的同步,才能決定要用什麼樣的技術。而透過什麼樣的技術,才能知道我們在應用面上的瓶頸和極限是什麼,由大到小,由淺入深,才是開會的目的與初衷。

 

 

"在這樣的時程和預算裡,若是同時開發兩套系統確實不可行,我們建議透過API的方式去跟貴公司現有架設起來的官網來進行串接,這樣對方也只要維護官網並透過欄位的回傳,就可以同步把商品更新至APP上。

貴司官網本身也具備購物功能,購買訂單也可以透過API的方式來把資料串回,不但可以節省開發和維護成本,好讓之後APP的開發重點可以放在應用面的身上,例如如何辦促銷,如何推播促銷等。"

 

 

「透過3W達成第一次的共識,才有了下一次會議該開始的範疇」

 

 

透過3W把產品定型後,想必在第一次的會議裡,我們就和客戶的想法有了基本上的同步。接著再來判斷這樣的需求同步後,與期程和預算是否會有相符。

 

 

"兩個月做一支APP,50萬,看起來似乎可行呢"

 

 

當專案開始滾動之後,接下來要做的就是消化需求,並且提出對需求來說相因應的技術。然後我們也清楚,各種需求在完整了解前,絕對不會輕易的了解每個開發上會遇到的技術範圍(scope)有多大。

 

 

這也是接下來會議裡的攻防,哪些需求該捨,哪些功能該留,功能的受眾是誰,該做些什麼?

一樣可以透過3W原則來做初步的判斷,而這些原則的釐清,也就是來讓我們更近一步的了解使用者的行為和雛型,

也就是所謂的 - 使用者故事(User Story)。

 

 

「User Story - 透過使用者行為來決定產品功能及定位」

 

 

接著我們會在下一篇告訴各位,如何透過各種使用者需求的模擬,來擬定產品的原型,由淺入深,由大到小,進而完成產品的開發。

 

 

"下一篇,用User story取代規格書,做一個符合期望價值的產品"

 


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

Medium vincent

Vincent Ke

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