進度條

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

兩個月的軟體開發,就可以賺五十萬,這樣誘人的條件,能答應嗎?

作者: Vincent Ke 更新日期:

「進入會議室開始和客戶進行第一次的需求訪談,對方是一個大型零售企業,在開發APP前本身就具備了上千間的實體零售店面,目前為了拓展市場,決意找上本公司進行官方APP的開發。

在漫長的時間拉鋸戰裡,客戶提出各種琳瑯滿目的需求,我們只有一位PM和資深RD與會,但客戶不斷的拋出需求外,更額外講了許多最近火紅的新技術,ㄧ下子要求要LBS(適地性服務)結合APP推播、促銷卷發放、會員歷程與點數計算,又要求後台管理及上架,在開口道盡各種看似相關卻又看似無關的功能需求裡,早就已經把團隊壓得喘不過氣...」

 

相信各位若是已經踏入軟體工程師的圈子時,這樣的會議鐵定不陌生,在有限的時程內,客戶對產品更是有無限想像。

 

面對客戶有如洪水猛獸般的兇猛進攻,該如何在會議中學會攻防,其實往往不只是PM的責任,身為工程師更應該要具備的專業,就是要判斷在時間和期程的壓力下,有沒有辦法順利將產品生出來,若是一昧的貿然答應,恐怕只會落入了專案開發的陷阱裡

 

 

「時間和金錢才是當務之急」


 

 

 

我們都清楚,時間和預算絕對是反比的概念,例如北高來回,高鐵是客運的兩倍貴,但旅程耗費的時間,高鐵顯然是客運的一半,更別提需求裡暗藏的未知。就像客運開上了壅塞的國道,往往成為了節省成本後,無法評估抵達時間的不確定性,也就是造成了所謂的"風險"。

 

而風險不只是來自深似海的需求,工程師們的出缺席(離職、跳Game!!?),國定假日與連假、天氣因素的颱風假、失戀傷心早成的產能下降、以及各專案的support人力狀況等,這些隱性風險都和產品交付時程息息相關,若是只用樂觀的態度來評估,最後就是自己的業障自己擔。

 

所以釐清主要期程和開發預算,絕對是首要的當務之急,就像決定交通方式前,一定要先釐清搭乘時間和預算一樣。

這時候就該單刀直入,哪怕捅死客戶也不要自己未來被合約捅死,剩下那些附加功能,才會變成經驗老道的我們,手上緊握的談判籌碼,多一些功能,就多一點錢,當然也要多一點時間。所以關於預算和時程,就單刀直入的捅下去問吧

 

 

"不如先談談預算吧,五十萬,兩個月APP要上線"

 

 

 

兩個月的開發,就可以賺五十萬,這樣誘人的條件,能不答應嗎?

 

 

 

 

通常會議到這裡時,前面深似海的需求都已經忘了大半,全部都只專注在兩個月內,要怎麼燃燒工程師們的小宇宙,把產品給催生出來,但這種看似甜蜜的開口合約裡,卻常常蘊含著許多陷阱

 

是工作天呢?還是日曆天呢? 是要做Native APP還是WebView呢?在時間與成本交叉的甜蜜點裡,到底還有多少的風險。

 

 

「在答應之前先釐清,你想的和客戶想的一不一樣」


 

校稿小編補充:
(Native 指的是使用官方提供的方式開發,在iPhone的iOS就是指Swift或是Objective-C,
Android手機就是Google提供的Android開發方式。WebView 則是指直接在APP放入瀏覽器植入網頁。
通常WebView會比較省事,但品質與效能比較難令人滿意。)

 

過去筆者曾經開發過一個旅行規劃網站,除了規劃之外,還需要協助建置景點資料庫,當初評估後覺得將客戶現有的景點資料上傳至產品上並非難事,也不會佔據開發單位太多時間,於是開口答應,以為白花花的現金就這樣入袋了。

 

結果在交付時才發現認知上相差甚遠,它們期待我們做的,並非是協助現有資料上傳,而是希望可以更鉅細靡遺的,將他們因人力因素無法補齊的景點詳細資料(如開放時間、門票價格、場景圖片..等),進行資料補遺。

 

(知名WebView framework - Cordova)

 

 

又還有一次,筆者的業主希望我們建置的網站,可以額外提供行動版網頁來支援行動載具瀏覽,所以在網站的設計上直接使用了響應式網站來開發。

然而在release(產品發布)前的會議裡,業主卻發現響應式網站不支援離線瀏覽(阿這就不是廢話..),而業主主要的客群都在訊號不佳的地方!!

 

當初只是粗心遺漏少了一個需求確認的動作,最後卻要在使用者的輪廓沒有共識的情況下,硬著頭皮延後交付時程,只為了完成因認知差異上造成的額外需求-寫一支支援離線瀏覽的新的APP

 

 

 

「爆掉的經驗絕對是助力,但讓自己爆一次而學一次乖,真的很吃力」

 

 

想當然爾,當初是在交付產品時才了解到雙方認知的差距,最後當然是悲劇收場,

俗話說的好,能用錢解決的都是小事,於是這個認知上的悶虧,最後也是賠錢收尾,因為我們都只看到了利潤,卻忽視了風險。

 

 

「別讓自以為的毛利甜蜜點,成為專案爆炸的導火線」

 

 

於是我們把重心拉回本文案例身上,在兩個月的期程內,光是UI的設計和Wireframe的擬定上(各種UI操作的功能流程設計),

就耗去很大量的時間,更別提那些設計修正以及來回確認的時間。

 

而這些都只是產品定位的第一步,若是連第一階段都無法釐清產品的走向與市場定位,又該怎麼去釐清這些附屬的功能需求,哪些是華而不實,那些是緊急迫切。

 

這時候反問自己一句:

 

"兩個月的開發,就可以賺五十萬,這樣誘人的條件,能答應嗎?"

 

 

 

 

 

時間和利潤的判斷,取決在要做什麼,要給誰用,為什麼要做?

在時程裡面你的預算是否合乎成本? 透過不斷的爆炸裡面學習的,就是了解在甜蜜點的毛利背後,我們忽視了的風險。

 

 

「談需求時,我們應該先談期程和利潤,才能透過3W原則擬定開發策略」

 

 

在時間和成本這兩個變數固定之下,接著才是切入需求的重點,要做什麼,要給誰用,為什麼要做,其實就是在網站開發上最常使用的開發導向法則,也是所謂的需求模型建立(Requirement Modeling),透過模擬使用者最真實的模樣,來定位網站最真實的需求,以及相因應要開發出來的功能。

 

接著我們會在下一篇告訴各位如何透過 3W - Who、What、Why 原則,進行產品定位及功能的釐清進而快速擬定產品的原型

 

 

"下一篇,善用3W原則,擬定產品雛形和開發策略"


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

Medium vincent

Vincent Ke

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