「Kuma 你有空嗎？我們聊一下好不？」產品部大前輩主動跑來找我，簡直蓬蓽生輝。
「好啊，那有什麼問題。」我爽快答應。
進到會議室…
「是這樣的，這款產品不是剛上線嗎？我發現乍看之下雖沒什麼問題，但仔細一看，有很多當初在我們去年提交的企劃書上的功能都沒有，有些則是長得不一樣，這品質有點堪慮吧…」前輩說道。
原來是為此事呀！幸好我早有準備。
「不是，前輩您看，我們其他產線平均不是三個半月出一個產品嗎？我們提前快一半的時間上線了不是？而且我們還沒結案呀！這不就可以隨後依真實數據每週，甚至每天地改良產品嗎？多好！而且這件事我們現在正在進行中，請放心！」我自信答道。
「是喔，但我們當初規劃的功能中，有一些在這版中都沒看到，這品質不是很 OK 啊我覺得…」前輩又說了。
「是的，這些不成問題的，我們未包含的那些規劃中功能，後續會依真實數據每週或每天分批加上去，而且是依真實用戶表現出來的喜好排序的，您不用擔心。」我覺得他應該一時沒聽懂我的話，於是我改了一點修辭重新又講了一遍。
「了解，原來如此。但你看你雖然提早一半時間上線，但這功能也少了不少，那你在追求快速的同時，這品質是不是也要顧一下…」前輩看起來非常擔心。
「喔喔不會的不會的，您看我這團隊不是沒有 QA 嗎？即便把這些人工驗測的時間成本省下來，我們上線至今也改過兩三版了，您看這數據也沒錯，系統也穩定，而且用戶數也在上升中，這品質肯定沒問題的呀！而且缺的那些功能，我們後續會依用戶表現統計來決定哪些要先上，不會不做的。」我這下確定他沒在聽我說話了，但其於對大前輩的禮貌，我還是好好地又講解了一遍。
「喔喔喔我懂了，但你這品質齁…」
…總之，當初這個談話怎麼結束的我已經忘了，我只記得我有忍住我的右手，沒讓這段談話演變成刑事案件，實為萬幸。
忍住右手示意圖。來源：網路
我記得的第二件事，就是總經理第二天跑來拍我肩膀：「Kuma，聽你大前輩說你為了要敏捷犧牲了不少品質啊？」
我：「……。」
在上面的故事中，這位產品大前輩看起來像是扮演著一個不明就理的角色，但事實上他並不是反派。他的行為只是表現出在軟體界很常見的一個思維模式，叫「越多越好」。在工廠的生產線中，假設這個產品已經量產並且在市場上確定獲利模式，這時在單位時間內當然是多做一件多賺一點，這當然沒問題。問題是這樣的思維模式有個大前題：「已證明市場需求」。
而與工廠相比，我們可以大膽地說，幾乎所有軟體開發者手上正在進行的工作，都「未被證明市場需求」，因此，沒有人可以保證多做一定會多賺。那麼，要怎麼證明市場需求？很簡單，提早上線最重要功能囉！
很多人把軟體開發者的工作比喻為工廠的生產線，但其實這個比喻並不恰當。實體商品的工廠產線開始運轉時，設計已完成，但在軟體開發領域中，整個開發過程（甚至包含測試），都只是在做「設計」，而真正的生產，只有發生在軟體被「Build」成可執行檔的那一段時間而已。
於是，當大前輩認為企劃書中的功能未能全被實現，是製程的品質降低時，其實他誤會了，這充其量只能說是第 0 期的設計沒有全部放到第一期的進階設計中而已。
話說回來了，那不把第 0 期的設計全部放到第一期的進階設計中，是一種犧牲品質的表現嗎？私以為恰恰相反，這代表我們正在提早驗證第 0 期的設計中最重要的那一部份，是否有其市場價值。因此，這應該是一個能確保每一個「Build」出來的產品的本益比都能盡量拉高的做法。
我當然可以照大前輩想像的，一口氣花好幾個月，把所有功能實作完、測完，一次發佈後閃人，薪水照領，對吧？但，這會完全阻斷我們產品的後路，因為那些原本可以依照用戶真實反應與回饋而調整的時間與成本已經全部被用完了。如果產品有「中」也就算了，萬一沒「中」，那請問…
我們多付出的那些成本，要跟誰回收？
敏捷開發不是被發明來犧性品質的，相反地，它是一種可以提早驗證初期企劃案品質是好還是壞的工具，而工具是中性的。如果真的成績不好，那就只是花了比較少的成本，提早證明這個企劃並不高明而已。這時，你要嘛持續改善，要嘛壯士斷腕，無論你選哪個，因為驗證的時間提早了，要做什麼決定都不會太匆忙，決策品質才會高。
筆著曾看過國內手機大廠的某位經理的專訪（具體是哪一間我已經忘了，但內容令我印象深刻），談到他們公司的手機部門，在現任美國籍行銷 VP 上任前後，行銷手法的不同：「原本我們看到我們工程師與技師花了好幾個月，開發出一款可折疊 10 萬次的手機，覺得這個規格棒透了，就在廣告中主打這個新功能，結果第一個月就收到很多客訴！因為用戶真的死命地折，結果手機就壞了。」該經理回憶道，「後來美國人一來，所有廣告都撤掉，換成一群年輕人開心地把手機放在絕佳位置，大家站好後不用等倒數，一起舉起手來比個「五」，照片就拍好了！」結果大賣。為什麼？很簡單。因為：
手機能折幾次年輕人真心不在乎，但能否輕鬆拍出網美照是至關重要的問題。
軟體開發不是只有開發，說到底，軟體開發幾乎總是從商業需求開始。你從技術出發去設計商品，就很容易設計出解決不了用戶問題的 Solution。當用戶問題得不到解決，你猜他會做什麼？B2C 就是用戶不用你的東西，然後 PM 叫你改，B2B 就是客戶發現用戶不用他們的東西，於是直接叫 PM 叫你改，應該不出這兩種結果吧？
既然都要改，為什麼不早一點驗證、早一點改？
設計，是一個「由上而下」的過程，在每一個抽象層，都從上一層的目的出發，分解出下一層要做的事，並用可重複的驗證方式來驗證，然後轉移到下一個目的…以此類推。
於是在產品面，發現市場需求，想一個產品的關鍵功能來滿足這個需求，如果這個功能滿足不了，你就失敗了嗎？不，你就得到新資訊，然後想一個新功能來滿足需求。
在功能面，得到一個功能的需求，想一個技術的 Solution 來滿足這個需求，如果這個需求滿足不了，你就失敗了嗎？不，你就更加了解此功能的內涵，然後再想一個新的技術 Solutoion 來滿足這個需求。
在技術面，面對一個技術 Solution 的實作需求，照著腦中的想法來寫一段程式來滿足這個需求，如果這個需求滿足不了，佚就失敗了嗎？不，你就更加了解此 Solution 的「坑」，然後再用一個新的程式設計來滿足這個需求。
聰明如各位讀者，您發現了嗎？雖然抽象層次不同，用的工具不同，但原理都是一樣的：「先畫靶，再射箭，確定射中再畫下一個靶，直到最終目標達成。」
在敏捷信徒在下不才小弟本人我的經驗中，這是用最小的努力，就能最快驗證價值，並最快調整方向以最小化損失的做法。如果您有更快更好的做法，請來信告知，我會公開造福大眾，並大肆感謝你的。
謎之聲：「我們提早證明了您的企劃並不完美，要修正還是要放棄，我們全力配合，但明人請不要做暗事。」
iThome鐵人賽
看影片追技術