今天來聊聊FID的開發技術週期，我猜這應該是大部分人最想知道的吧。

快告訴我怎麼做就好，好吧，那麼今天就把大家當做新人來介紹。

整個過程我們分成四個部分來看

搭配第一章的開發流程，我們標示一下。

可以明顯看到，色塊和流程並非完全對齊，因為在準備的過程中，我們很可能在翻新其他專案。

進入專案前

在進入開發前，我們需要預先就對公司或組織有一定的了解，事先做好我之前說的「區域分類」的步驟。

要注意的是這個分類都是你的預測，當你真的投入資源和進入開發後，很可能會有所不同，但我們可以隨時調整，都是沒問題的。

主導者必須要對未來的開發有事先的準備，嚴格競爭再沒有準備的情況下承接需求。

因為你不斷無法即時給予有用可靠的建議，當下也沒有辦法做出承認和計畫安排，這無形中就是浪費了其他人的時間。

進入專案中

行前會議

在專案開發前，主導者需要和專案開發的人確認幾個事情。

1. 這次專案會用什麼機制/框架
2. 業務邏輯會用什麼方式處理
3. 用戶流程的資料流會如何處理
4. 如果業務發生變化會如何處理（這個明天會獨立說一篇）
5. 下一個階段我們對這個解決方案做什麼改善（這個也會獨立說一篇）

最後兩個特別重要，也是最常被人忽略。

這個會議非常重要，我們需要在會議中，和專案執行者有一個認知上的一致，而且大部分時候，主導者必須給予明確的方向和效果。

執行者則是需要思考細節中的各種疑難雜症。

譬如說我們要做一個電影院售票系統

主導者的規劃大綱

• 需要一個選座位的機制，包括資料流
• 需要一個管理機制，票務資訊
• 需要一個行銷機制，票需要搭配各種封裝📦成另外一個虛擬產品
• ⋯

你可以不斷的往下列，最後再收斂成第一階段要做的事情，按照我們前面說的重要性排序。

執行者需要實作並給出建議

座位是一個物件，裡面有xy軸和meta data等資訊，利用這個變形可以排列出各種排列組合
每次進去選座位的時候電腦就會自動選好座位，並記錄在資料庫lock起來，以免同一個時間搶座位的問題。
⋯

等等所有故事的細節，當然很多時候主導者其實已經有答案知道怎麼做，但是也可能會忽略很多細節，需要做的人在開發中才會發現。

這些差異就需要在每次會議中提出來。

這一步除了能盡可能討論出方案的漏洞和可能會出現的問題之外，還可以避免之後的修改面目全非。

當然一切有限的情況下，我們只能選擇性的執行，而那些被我忽略的事情，很可能就是「重要但不緊急」的事。

例如說，我們有一個「熱門清單」這個選項他應該是由系統演算好給我們的，但是沒辦法我們只能先寫死一份清單，按照清單隨機或時間排序出現。

這裡只是比喻，但展現出來的效果，有看出明顯的差別嗎，起碼用戶是看不出來。

那這個事情很重要，但他很緊急必須要馬上處理嗎，也不見的是。

會議結論我們可以得出幾個結論

1. 有些東西我們需要放在專案結束後做，並有計畫的覆蓋這些問題。
2. 有些bug已經知道，但他的重現步驟很複雜，解決它也很難，可以先砍斷這條路，以免發生用戶錯誤。
3. 有些情境現在的需求不需要，但以後很可能就要，如果要，那可以怎麼做，必須可以做，如果不可以，這個需求是不是不應該做下去。
4. 有些需求可能之後其他地方都需要，這個必須做出標準化。

階段驗收

有了上面目標和共識，大家進入開發都是「寫code」的問題，作法和流程應該都蠻明確了。

這時候review code給的建議都是程式建議，業務建議就不會多。

重要的是，因為我們對整個專案已經做過一次思想實驗和演練。

所以我們對每個進度應該第一個預期，每週或半個月做一次內部人員demo，以確認功能和實作符合用戶端預期。

完成專案後

當專案交付之後，我們必須騰出至少一個月的時間來做整理。

這些整理包括：

1. 部分程式碼重構
2. 做重要但不緊急的事
3. 封裝上個專案的共同模組
4. 準備好v2版本

接著將這次的經驗做個總結報告，包括內容可以涵蓋但不限制於。

1. 本次專案最困難的地方和他的解決方法
2. 專案的封裝模組介紹以及他的用法和原理
3. 專案的災難管理和方法

總結報告形式可以很多元，可以是分享會，可以是寫技術文章。

最重要是我們需要思考這個專案的收穫，不僅僅是專案本身。

專案翻新和維護

假如我們真的是在非常緊急的情況下交付這個專案的。

我們根本沒有很多時間做剛剛事，但至少我們有領域區分吧。

那我們就可以來開專案翻新計畫，其實就是重新做一遍剛剛的事，當然這個時候會有人跳出來說，公司就是不給我們時間啊。

關於這個問題，我後面再為大家說明我的看法。

在這些帶團隊的日子裡，我有充分的數據證明，粗製濫造的結果花的維護時間遠遠大於我們認真走一遍FID。

那麼當然你必須真的有這個數據，例如你有明確的團隊所花的時間紀錄。

有很多專案做好丟上線之後，維護是非常困難的，關於這一點我也是還在學習中。

所以沒必要不要在公司開發非常複雜的系統，因為如果公司資源不足，而系統又非常複雜，到時候只會苦了其他人。