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

還記得上一篇的案例嘛？

傳送門：與客戶談需求時，我們應該先談什麼？

 

在兩個月的時間內，完成一項大型零售企業的官方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粉絲團按讚喔!!