​

長期開發並維護一個產品跟短期衝刺生產出一個專案，最大的差別在於開發流程。負責小元件或小專案在開發上是同步進行的，而產品或大系統在開發上是異步進行的。開發元件可以用土法一路衝到最後，但開發系統沒有完善的基礎設施，案子很快就會出現許多問題導致開發窒礙難行。

如果以往是開發小系統，但突然有一天有機會接觸大系統的開發或規劃，沒有這些概念先Keep in mind，開發路上就會很辛苦了。

同步進行

小專案需求訪談後產生工作說明書然後簽字畫押好，只要規格寫的好範圍是可以被確定的，也不可以隨意亂改，改了可以再收錢。所以開發者一開始就能清楚界定專案的範圍，大部分未知的風險比如技術瓶頸可以被事先預知，開發時間可以被事先規劃。所以實務上從撰寫規格書界定專案範圍，再來實際開發最後到測試與驗收，流程上是以同步(sync)的方式進行。

異步進行

而大部分產品會給多個客戶使用那就會有多重意見和偏好，再來因為想做的功能多，甚至很多功能是要做但現在還沒辦法做，一開始也就是先畫出WBS圖來大略上界定範圍，很難一開始就寫好完整版規格書，界定所有API。而是隨著時間發展，常常是先寫好幾個客戶緊急需要的模組，然後就出貨給客戶，之後陸續再Release新版補給客戶其他沒有那麼緊急或重要的功能。而一但把時間因素拉長並考慮進去，開發上很多問題就會浮現了。

緊急事件

有緊急狀況發生比如出貨的產品臨時被要求在上線前要提供弱掃報告與修正，那這時後原先預定的下一個版號要新增的功能就要被置換成修正弱掃缺點。原本要被Merge回來的Feature支線就要暫緩，並且火速開一個Feature來修改弱點並發布成一個版本。

Feature要不要Release的抉擇

如果有很多新功能都接近完成，這時候要Release那些到下一版？通常第一個要考慮的是客戶的安心感。比如新功能要犧牲效能來換取穩定度，這時候要犧牲多少效能？這數字是客戶可以接受的嗎？客戶搞不好寧願犧牲穩定度來換取效能？如果客戶有多個有的可以有的不行呢？

上述沒有考慮到就貿然Release出去，如果驚嚇到客戶，讓客戶對我們信心感和安全感下降這都是很嚴重的損失。

本版間的關係管理

隨著時間迭代，A客戶是0.8版，B客戶是0.9版，這時候怎麼從0.8升級到0.9？兩個版本之間又有什麼差別？如果是好幾10個版本分散在各地有辦法處理嗎？如果沒有搭配文件、程式碼版本控管、環境印象檔化，不用多久整個案子就會無法維護。

文件記錄各版本的Release note，並且要有規範，標明新功能和已知問題等。版本控管Git要有Git Flow如Release branch在程式標明版本號，和Tag標註方便切換不同版本。運用Docker把運行環境標準化Infrastructure as Code，除了確保開發時與上線的反應相同，也避免環境升版降版時遺漏了設定造成的錯誤。

眾多協同開發會遇到的協作工具

Product version control document、Git、Auto test、CI Server、Project Management Know How(WBS etc…)、Document Guideline、Issue tracking等，以上這些就像是現代產品開發所必備的基礎設施，少了這些要開發大型系統或隨著時間迭代成長的產品是不可能的事情，沒有這些整個技術Team無法持續成長，也會欠下一堆技術債，累積到最後整個產品開發寸步難行，而對風險的忍受度也會異常的低，比如一個關鍵開發人員走了整個產品開發就無以為繼了。

從開發元件與小APP到現在開發產品，遇到的問題很多已經不是單一技術面，更多是如何管理這堆技術生老病死的問題，僅記錄一些最近遇到的實際問題與想法。