先求有，再求好？
相信大家一定常聽到這句「名言」，不管是從老闆、從主管、或同事、甚至是有些開發方法如 MVP ，也提出類似的觀點。 在前三天了解基本概念後，可能有人會覺得奇怪：這句話跟 CI 有什麼關係呢？如果有仔細閱讀並思考前三天內容的話，大家應該猜想得到，魔鬼可能就在這句話的細節裡。這句話在軟體開發的世界裡，絕大多數的場景都沒錯，因為軟體開發在改善流程上，比起其他實體產業是非常快的。因此確實可以考慮早點進入市場，再求改善，甚至是原先沒有的功能都可以在未來改善時加入。咦？沒有的東西未來都可以加入的話，那一開始到底要「有」什麼呢？ 這是今天想跟大家一起討論的： 什麼才是「有」？ 什麼才是「有」？ 下面以 MVP 來當範例說明。 一般 MVP 是設計者先做需求假設，再提出解決需求的產品，只要目標使用後需求有被解決，就會持續使用產品。目標使用後，通常會有回饋給設計者，如果回饋跟設計者思考方向一致的話，設計者就能參考回饋再為產品加上更符合需求的功能；反之，代表一開始需求假設是錯誤的，設計者依然可以參考回饋，並思考下一個可行的產品。 舉個例子：假設醫院的病人會想利用網路來線上掛號，因此我們應該要有線上掛號產品來服務病人，病人使用覺得滿意，下次自然會願意繼續使用，或給一些回饋。不滿意的話，就不會繼續使用，甚至連回饋都懶得給。所以對 最終使用者 來說，毫無疑問地，一個「有」解決需求的產品，才能回饋設計者設計「好」產品。 而對 設計者 來說，什麼才是「有」？從上面的描述可以大概了解，對設計者而言，一個能解決需求的產品，並能提供回饋資訊的產品，就「有」了！ 重點來了！試著思考一下，如果最終使用者所使用的產品，與設計者所預期的不同；或是更白話的：產品有瑕疵的話，會發生什麼事？ 常見的就是 bug 回報，如醫院掛號時間與通知時間不符，這代表使用者的思考是符合設計者的概念；可怕的會是使用者用了有問題的產品後，但給予了錯誤回饋，這會讓設計者改善產品的方向錯誤。比方說：原本設計是送出表單前會再次確認，但實際產品沒有實做，使用者回饋也是正向居多，設計者會誤以為這是使用者接受的做法，於是思考改善流程或動線時，可能就會被忽略。 產品有瑕疵，會使團隊無法得到上述「先求有，再求好」的好處，甚至還會讓產品越改越差。 正確的產品才是「有」 「先求有，再...