禮拜四晚上，阿偉剛走出捷運站，手機就跟催命符一樣響個不停。

是專案經理小P的訊息：「阿偉，你下禮拜一新功能能上線嗎？很重要，老闆很急。」

他看了眼時間，晚上九點半。媽的，下班了還在追進度。

但更讓他火大的是，這個所謂「很重要」的功能，是三天前小P經過阿偉的座位，突然沒頭沒腦就丟過來一句：「幫我做個會員中心的個人化推薦。」

就這樣。沒有文件，沒有設計稿，連個屁的規格都沒有。

阿偉當時還很盡責地問：「這是要推薦商品還是文章？」

小P：「都可以吧，你先做一版看看。」

「那根據什麼推薦？用戶瀏覽紀錄？購買紀錄？」

「嗯…購買紀錄吧，應該比較簡單。」

然後就沒了。阿偉當下還以為小P會再補充點什麼，結果等了半天，什麼都沒有。

他就這樣開始寫了。心想，購買紀錄就購買紀錄吧，應該不會太複雜。

結果咧？阿偉認真寫了兩天，做出一個基於購買紀錄的推薦演算法。小P看了一眼就說：「欸等等，我想到一個問題。新用戶沒有購買紀錄怎麼辦？要不我們改成用瀏覽紀錄好了，這樣覆蓋率比較高。」

「那我這兩天...」

「先放著吧，之後可能用得到。」小P已經在想別的事了。

「...」

阿偉看著螢幕上那堆code，突然覺得很累。兩天，就這樣白費了。

咖啡廳裡，阿偉攪著咖啡，越攪越用力。

「我真的搞不懂這些人在想什麼。」

「你知道最慘的是什麼嗎？明明是他自己的問題，結果他還好意思用『你是開發者欸，新用戶沒購買紀錄這麼基本的問題你怎麼沒先跟我講？』的那種口氣跟我講話，搞得好像沒sense的人是我一樣」阿偉學著小P的語氣，聲音裡滿滿的嘲諷。

我點點頭。這種事我見多了，工程師被當成萬能翻譯機，要能自動把其他人腦袋裡那些不成形的想法轉換成code。

「阿偉，你有想過為什麼會這樣嗎？」我問。

「因為他們都是白癡？」他毫不猶豫地回答。

我搖搖頭：「如果真的這麼簡單就好了。」

「不然是我的問題？」阿偉的聲音突然提高，「現在是我按照他的需求做，結果他說不對欸。當初我問他要什麼，他說『都可以』，然後最後全部重做，還要怪我沒想周全嗎？那他要是每次都這樣，我不就每次都活該要背鍋嗎！」

旁邊有人朝我們看過來，阿偉這才意識到自己聲音太大了。

「所以你打算怎麼辦？放他繼續這樣不清不楚下去嗎？」

阿偉停下來，看著我：「不然咧？」

「不然，我們把主導權拿回來吧。」

什麼意思？他疑惑地看著我。

我在餐巾紙上畫了個圈：「現在的問題是，我們處在一個被動的位置上。小P說什麼，你就做什麼。他說不對，你就重做。但你有想過，其實你可以主動出擊嗎？」

我們可以利用提問的方法來反轉局勢

「你看，小P跟你說『個人化推薦』的時候，你問了什麼？」

「我問他要推薦什麼啊。」

我在餐巾紙上寫了三個字：Why、What、How much，並推到阿偉面前。

「對，但我們只對小P問了『What』，沒問『Why』和『How much』。」

阿偉皺眉：「什麼意思？」

先搞清楚為什麼

「以我們現在碰到的這件事來說，Why，指的是為什麼要做這個功能？」我指著紙上寫的字。

「當初小P提需求時，我們問他是要推薦商品還是文章、要根據什麼來推薦，他都表現得一副自己也不是很清楚的樣子。這樣看起來，很可能是小P連這個『Why』都沒搞清楚，就貿然來找你開需求了。在這種情況下我們接了他的工作，不管怎麼做都會出錯，不是嗎？」

阿偉質疑：「那難道我不接嗎？PM 說要做什麼，我哪有說不的權利啊。」

「這不是說你不接，而是把看不見的『規格』轉化成可以一起討論的東西。」

我安撫著阿偉，「小P可能沒有不好的意圖，但如果你接受了一個不明確的需求，那你一開始做的功能就已經註定是錯的，這等於默默地接受了一個很高的風險。而且，如果小P自己都對需求不清楚，我們完全可以建議他先花一兩分鐘去找相關人員問清楚，再一起討論，這樣對大家都好。」

「嗯…確實是這樣…」

「接著幾天後，小P說老闆很急，但老闆為什麼急？是因為競爭對手有了類似功能？還是現在的用戶黏著度太低？當你知道真正的原因，就算他突然說要改用瀏覽紀錄，這件事情合不合理你心裡也會有譜。」

阿偉若有所思地點點頭。

「還有就是，我們可以從側面驗證這個需求的來源，這需求真的是老闆提的嗎? 老闆怎麼提的? 會是小P自己理解錯誤嗎? 很急是為什麼呢? 多急? 在下禮拜一要完成是為了要趕上什麼?」

把抽象變具體

「接著是 What，具體要做成什麼樣子？」我繼續寫。

「『個人化推薦』這五個字，根本有講跟沒講一樣。我們這時可以進一步追問：用戶點進這個頁面會看到什麼？是一排商品圖片？還是帶有說明的清單？新用戶沒有數據時要顯示什麼？推薦幾個商品？基於什麼數據？把所有邊界情況都問清楚。」

「我確實沒問這麼細。」

「對啊，我們要逼他把腦袋裡那團糊糊的想法變成具體的畫面。不然他自己都不知道要什麼，你怎麼可能做對？」

訂出成功標準

「最後是How much，所謂成功的標準是什麼？」

「這對我們來說是最重要的。我們總不能等做完後才發現，成品好不好完全看他的心情，他喜歡就通過、不喜歡就重來吧。」我喝了口冰水接著說，「所以在開始做之前，就必須先跟對方約定清楚什麼樣的結果就能算是成功，如果能有具體的量化指標作為評判標準是最好的。」

阿偉看起來有點疑惑：「這種東西也能量化嗎？」

「當然啦。」我說。

「比如小P這次的需求，我們就可以問他『我們怎麼判斷這功能做成功了？是看點擊率提升多少、訂單轉換率增加多少？還是想要提升客單價到多少錢呢？』有了數字，你們就有了共同目標。以後他要改東改西，你就能有立場問他了：『這樣改會不會影響我們的目標？』」

萬一他沒空或不想理我怎麼辦

阿偉盯著餐巾紙，突然抬頭：「可是...他們不會覺得我問太多嗎？而且小P這種人，你問他這麼多問題，他可能就直接用盧的『你就先做啊，有問題再調整就好啦』，怎麼辦？」

「你說得對，一開始小P確實可能會覺得你有點煩。」我直接承認，「但你應該也知道，與其花兩天做白工被質疑能力，還不如花十分鐘問清楚被嫌囉嗦來得好吧。」

「問題是他可能根本不想回答，或是沒時間理我。」阿偉有點洩氣。

「對，這確實是個現實問題。但別擔心，我們不是沒辦法，只要設法換個方式溝通就行了。」

「怎麼說？」

「文字留底，把球丟回去。」我在餐巾紙上又畫了個箭頭。「下次小P又丟一個模糊需求給你，但又覺得好像會講不過他，就不要當場答應。可以說『好，讓我研究一下技術細節』，然後馬上發個訊息或email給他。啊，可以的話，把相關的人CC進來會更好。」

「發什麼？」

「就寫我們目前對現況的理解，加上幾個關鍵問題。比如像今天的情況，我們可以寫信給他。像這樣…」

小P，我目前的理解是要把基於購買紀錄的個人化推薦功能，改成用瀏覽紀錄來做，好讓這個功能也覆蓋在新用戶上。

為了確保開發工作順利，有幾個部分想請教您：

- 我們要做這個功能的具體起因是什麼？(比如競爭對手有了類似功能？還是現在用戶黏著度太低？…等)
- 具體呈現的方式與功能會希望是什麼形式？
    - 用戶點進這個頁面會看到什麼？是一排商品圖片？還是帶有說明的清單？
    - 當新用戶瀏覽數據不足時要顯示什麼？推薦幾個商品？基於什麼數據？
    - 瀏覽數據的權重希望怎麼設置？(比如觀看文章、個別商品、產品類別...等等)
- 希望能以什麼指標來衡量這功能的成效？(例如點擊率提升比例多少、訂單轉換率增幅，或是客單價成長目標…等) 預計檢核成效的時機點是在哪些日期？
- 關於交付成果，要完成整體需求的話，希望分成幾個階段來交付？
    - 如果只要初版能上線的話，你希望我星期一能做到需求的什麼程度？
    - 初版上線後，您對後續階段開發有什麼規劃？我該如何配合您的時程安排？
    - 什麼情況與時機點下需要我預留時間資源來二次開發？

我推了推眼鏡，繼續說：

「然後最重要的是要在信件裡加上時間限制，像是…」

為了確保能趕上下週一的時程，煩請您在今天下班前回覆，讓我能盡快著手開發作業，謝謝您的配合。

阿偉愣了一下：「這樣不會太強勢嗎？」

「這不是強勢啦，這是我們展現專業態度的時候。而且這樣做有兩個好處。」我解釋道。

「第一，我們把溝通的責任轉回去給他了。如果他沒回覆，後續出了問題也不是你的錯。第二，我們把模糊的需求變成可以討論的東西。」

「所以，我們不是以一種『你到底要什麼』的態度在質問他，而是在以一種『為了讓專案成功，我們來確認點什麼吧』的友善態度在協助他了。」

「哦…我懂了。」阿偉喝了口咖啡，眼神裡多了一點希望：「這樣小P就比較不會覺得我們是在刁難，反而是在一起幫忙把想法整理清楚，對吧？」

「嘿嘿，沒錯！而且當我們與小P之間有初步的需求共識之後，後續要再圍繞這個主題開Jira或tickets也可以更順利」

「好，我看看…」

阿偉看著那張被我們畫來畫去、已經有點破破爛爛的餐巾紙，喃喃的說：「所以下次小P再丟模糊需求，我就說『好，讓我確認一下細節』，然後把這三個問題問完。不要急著寫code，先把需求問到我真的明白為止。還要記住，一定要用文字留底。」

他看了看餐巾紙上的三個問題，慢慢地點了點頭。

「嗯...好像有道理。試試看不會更糟了。」

阿偉終於笑了，這是今天晚上他第一次笑。