我常收到一種陌生客戶的需求來信，一行字就講完開發需求然後請我報價，以前看到這種第一封來信就要報價的客戶，我會積極回信詢問相關的製作細節然後主動邀約會議時間，想說應該是他們太忙或是需求太複雜因此沒有辦法在信中詳述，但學了多次教訓後發現到這類案件最後 99% 都沒下文，從此之後只要是單純來信詢問報價的客戶我就一律不回覆。
之所以不回覆的最大原因是單純提供報價無法展現我的價值，如果對方沒有主動邀約會議認識彼此，可能的情況是他們已經面試太多廠商並且公司專案啟動在即，必須要盡快選擇廠商開案，因此當面臨眾多選擇時最快的評估條件之一就是價格。
也或許是負責發案的窗口沒有經驗，只將老闆的一句需求轉達給外包廠商，讓廠商來評估開發項目與報價，上述這兩種狀況的案件對接案者來說都非常危險，因為缺少了對整體專案的認識，開發需求是否為解決問題的最佳解都是未知數，如果就冒然開始進行，專案做到一半打掉重練的情況屢見不鮮。
因此為了避免這樣的問題產生，關鍵就是上一篇文章正妹助理 Emma 所提問的「需求訪談」。需求訪談有很多方式，我以我的經驗條列出該問與不該問的項目：
1.「要」問案件的目的
會議進行時，通常客戶都會說明希望要開發的功能，有些功能可以很直觀的推測背後的目的，但有些看起來「怪怪」的需求要特別釐清，我遇過一個奇怪的功能是要讓訪客買 A 商品時偷偷把 B 商品自動加入購物車進行結帳，這類違反操作直覺的功能絕對需要特別留意背後的目的。
以上面的這個案例來說，客戶希望的是可以贈送小禮物給第一次購買的訪客，所以提供的解法就是用贈品的角度來設計，並非是偷渡商品來欺瞞消費者進行購買，釐清目的後除了可以提供正確的建議給客戶外，還可以檢視客戶公司的企業文化，如果該客戶希望設計一些怪怪的手段來達成其商業目的，這樣的案件還是遠離一點比較好。
詢問客戶該需求背後的目的，可以協助客戶判斷這樣的作法是否為最好的方式，並從你的經驗來提供建議諮詢是取得客戶信任的不二法門，如果客戶開的需求都照單全收，單純的執行角色會給客戶容易取代的印象。
另外我知道很多接案者在洽談的時候都會留一手，留住一些關鍵知識讓客戶願意買單，而我傾向的做法是透明化我所知道的所有資訊，就跟我每個禮拜寫文章分享一樣，在這資訊爆炸的時代架站知識在網路上太容易找到了，不用擔心客戶知道這些資訊之後就不需要你，分享這些知識反而會讓客戶覺得你是有經驗、知道在何種情況下該用哪些工具的專家。
我每次都會跟客戶說他們要的功能已經有免費或付費的 WordPress 外掛可以做，並且在會後幫他們一一條列出來下載與購買連結，我的想法是不要做二次工，並且讓投入該生態的開發者可以多賺一點，也許今天客戶照著這個外掛列表請了一位工讀生就把網站完成了，但未來有新的需求他們想到的是我而非是那位照表安裝外掛的工讀生。
2.「要」問案件的實際使用者需求
大部分的需求都是老闆覺得應該要有的功能，而這些功能是否會真正幫助到網站的實際使用者就很難說，除非這老闆同時也是第一線的客服人員，不然由上到下所提出的需求通常會離真實世界有一段距離。
因此在釐清客戶要開發的功能時，要能理解這功能是給誰用的，他們的操作流程會是怎麼進行，操作完後會得到什麼樣的預期結果，通常客戶主要都是先想到預期的結果而忽略的使用者是誰以及操作的流程。
像是客戶希望可以幫公司的購物網站增加點數的功能，讓客人在購買後獲得點數，並用點數進行商品的折扣，老闆會有這樣的想法可能是因為看到其他競業都有這樣的功能，甚至他自己也有在使用點數來買東西，因此覺得公司的網站也應該要有。
但萬一該公司的客人多半是對線上購物不熟悉的年長者，或是根本不在意點數而是產品的品質，開發點數系統可能無法有效提升業績，或者應該思考的是該如何開發出一套連年長者都會操作的點數系統，從這角度切入會對於整個專案的發展方向有很大的不同。
3.「要」問案件的管理需求
除了要關心到前台使用者的需求，公司內部的後台管理需求也是客戶常常會遺漏的一環，當前台多了新功能後台可能也需要相對應的管理介面，讓負責的同事便於更新資料以及修改設定。
每次需求訪談時我一定會問客戶他們對於 WordPress 的熟悉程度，像是他們有沒有自己實際架過、有沒有使用過 WordPress 的後台管理介面，或是詢問他們曾經用過哪些工具，這些資訊可以讓我評估該如何設計後台的管理功能以及教育訓練的時間成本。
我常評估 WooCommerce 購物網站的開發，有時候會被客戶反問說為何評估項目裡面沒有訂單管理、商品管理、銷售報表統計等功能，我就會回說因為這些都是內建的功能不需要另外建置，並請客戶實際架起來操作看看，就能讓他們初步得知後台管理還有哪些需求沒有被滿足。
4.「不要」問案件功能的執行細節
我以前常常會以工程師的角度來跟客戶討論一些功能的具體實作細節，像是該在哪個時間點把資料寫進資料庫、讀取資料的時候該如何判斷邏輯，雖然可以展現專業感，但如果在大方向都還沒釐清時就跳入這些細節，容易讓整個會議失焦。
會議的主軸還是要得知案件的目的以及開發項目，如果被執行細節給困惑的話很容易遺漏更重要的事情，再加上會議時間都是雙方的成本，對於接案者來說花費太多沒有收入的會議時間來進行細節的討論是沒有必要的。
我會先把會議中提到的技術難點先筆記下來，如果大方向都已經討論完我會看這個技術難點是否會很大程度影響整體的時數評估，如果會的話我才會提出這個問題與客戶討論，否則這些難點就留到之後實際開發時再來思考即可。
5.「不要」問案件的預算
以前問案件的預算都是為了要打出一份能夠讓客戶一次就點頭的報價單，所以要用各種迂迴的方式來試探客戶的預算，而客戶也會用各種方法閃躲以先取得我們的報價單為目的，因此就會上演攻防的戲碼，我自己很不喜歡這種鬥來鬥去的過程。
不用報價單改用估價單之後讓我可以再也不用演這場戲，專案開發的成本就直接列出來給客戶評估，所以自此之後我不會在需求訪談時來試探對方的預算來評估該案件我是否值得承接，就算萬一客戶預算真的做不起來也沒關係，有多少錢就做多少事。
6.「不要」問案件的上線時程
通常上線時程客戶都會在表達完案件需求後丟出一個時間，就算客戶沒主動提及我也不會問他們希望何時上線，因為在還沒有開案前一切的時程預估都是用猜的，猜的準就能去買樂透，猜不準是必然的，裡面有太多因素在干擾。
萬一客戶硬是要求我給一個可以完成的時間點，通常我會說要等實際開案執行幾週後才有辦法評估，萬一他們火燒屁股了希望下個月就要完成，我會先反問哪些需求是最緊急且最迫切的，說服客戶優先處理這些待辦事項，關鍵是把大專案拆成多個子專案，通常最緊急的項目完成了，上線時間也就沒那麼重要了。
在需求訪談中搜集了上述的資料後，就能開始針對需求進行任務的分類與拆解，以及最重要的項目估時，這部分留到下篇文章繼續討論吧～
