先求有，再求好？
相信大家一定常聽到這句「名言」，不管是從老闆、從主管、或同事、甚至是有些開發方法如 MVP，也提出類似的觀點。
在前三天了解基本概念後，可能有人會覺得奇怪：這句話跟 CI 有什麼關係呢？如果有仔細閱讀並思考前三天內容的話，大家應該猜想得到，魔鬼可能就在這句話的細節裡。這句話在軟體開發的世界裡，絕大多數的場景都沒錯，因為軟體開發在改善流程上，比起其他實體產業是非常快的。因此確實可以考慮早點進入市場，再求改善，甚至是原先沒有的功能都可以在未來改善時加入。咦？沒有的東西未來都可以加入的話，那一開始到底要「有」什麼呢？
這是今天想跟大家一起討論的：什麼才是「有」？
什麼才是「有」？
下面以 MVP 來當範例說明。
一般 MVP 是設計者先做需求假設，再提出解決需求的產品，只要目標使用後需求有被解決，就會持續使用產品。目標使用後，通常會有回饋給設計者，如果回饋跟設計者思考方向一致的話，設計者就能參考回饋再為產品加上更符合需求的功能；反之，代表一開始需求假設是錯誤的，設計者依然可以參考回饋，並思考下一個可行的產品。
舉個例子：假設醫院的病人會想利用網路來線上掛號，因此我們應該要有線上掛號產品來服務病人，病人使用覺得滿意，下次自然會願意繼續使用，或給一些回饋。不滿意的話，就不會繼續使用，甚至連回饋都懶得給。所以對最終使用者來說，毫無疑問地，一個「有」解決需求的產品，才能回饋設計者設計「好」產品。
而對設計者來說，什麼才是「有」？從上面的描述可以大概了解，對設計者而言，一個能解決需求的產品，並能提供回饋資訊的產品，就「有」了！
重點來了！試著思考一下，如果最終使用者所使用的產品，與設計者所預期的不同；或是更白話的：產品有瑕疵的話，會發生什麼事？
常見的就是 bug 回報，如醫院掛號時間與通知時間不符，這代表使用者的思考是符合設計者的概念；可怕的會是使用者用了有問題的產品後，但給予了錯誤回饋，這會讓設計者改善產品的方向錯誤。比方說：原本設計是送出表單前會再次確認，但實際產品沒有實做，使用者回饋也是正向居多，設計者會誤以為這是使用者接受的做法，於是思考改善流程或動線時，可能就會被忽略。
產品有瑕疵，會使團隊無法得到上述「先求有，再求好」的好處，甚至還會讓產品越改越差。
正確的產品才是「有」
「先求有，再求好」，那什麼才是「有」？答案很明顯，正確的產品才是「有」，瑕疵的產品跟沒有一樣。在趕上線時，常會聽到「先求有，再求好」，這句話是對的，但把魔鬼細節加進去會更好：
「先要對，才會有，再求好」
趕上線的時候，要記得檢驗一下產品有沒有「對」。那要如何確保產品有對呢？這時 CI 精神就非常重要了！當團隊有了 CI 精神，團隊會常常對產品做驗證，不正確要立即修正，以確保交付出去是正確的產品，是對的，「才會有」！甚至，不但產品是正確地交付出去，在未來「再求好」的時候，常常驗證也能保護產品原本功能的正確。這才是真的「先求有，再求好」，也是這句名言與 CI 之間的關係！
Agile 的「有」
Agile 有些方法也是確保交付的產品是正確的，如：
很多 Agile 方法的初衷，都是為了要確保產品正確。因此可以發現，其實 Agile 不只在講因應改變，同時也在講如何提升品質。當然，CI 也是！
未來在討論 CI 要領時，也會專注在「確保產品正確」，而上述的 Agile 方法都很適合拿來參考並使用。
非開發人員的 CI
這裡以企劃人員當範例，其他公司類似的職務可能像是 PM 或設計師等。
分工比較明確的公司，通常會分開發人員與企劃人員。開發人員的工作是產出正確的產品；而定義正確的產品，是由企劃人員決定。這會有類似 Dev 與 Ops 之間的衝突，但 See the whole，從整體產品的角度來看，「確保產品，人人有責」，開發人員本來就需要了解什麼是正確的產品，企劃人員則應該要用各種方法讓開發人員知道，自己心中的正確產品。
所以什麼是非開發者的 CI ？一樣是 Continuous Integration，持續整合資訊到開發人員上，並確認預上線產品或上線產品是否正確。整合資訊與確認的過程或多或少會有問題，比方說企劃人員沒發現新舊功能衝突，或開發人員誤會企劃人員的意思，但一樣 See the whole，這都是要一起克服並解決的。更重要的是，這些都是本來就該做的事，不會因為不持續做，就可以不用做。持續做的好處是每次資訊同步與確認的量少，問題會比較明確好解決。
Dropbox 又來了：就像第一次同步 Dropbox 的檔案也會很久。當完成後，同步就會非常快速了。
今日回顧
- 「先求有，再求好」沒錯，但「先要對，才會有，再求好」會更好！
- CI 是達成「先要對」的最佳實踐！
- Agile 也有很多方法在討論如何「先要對」！
- 非開發人員也要有 CI 的觀念：持續跟開發人員同步資訊！
下一篇：簡單的好習慣，是 CI 的一大步