無論是向新人介紹專案，又或者是上到乙個新的專案，我們都需要事無鉅細地列出乙個個的關注點。既然如此，那麼為什麼建立乙個檢查清單，用來幫助我們乙個個的檢查一遍呢。
在過去的日子裡，經歷了幾個不同的專案，每個專案都有自己特有的特色。它們往往也包含了一些不同的背景，在成功的交付專案之後，有的還要解決技術難題，有的要的是解決業務難題，有的複雜的部分在於跨團隊的協作。正是因為這些情況，也導致了在不同的時候，我們需要著重考慮這些不同的因素，上乙個業務複雜的專案，需要重點關注業務問題；來到乙個專案團隊結構複雜的專案，則重點解決團隊複雜問題。
可是呢，對於每個專案來說，它們都存在一些相似的共同點。而這些共同點，即是我們開始乙個新專案要做的，也是我們來到乙個新的專案時，所需要了解的。於是，當我看到一篇 tech lead 的新專案檢查清單時，我也想寫乙個面向開發人員的新專案檢查清單。
在那篇《專案初期的最優技術實踐》中，我總結了專案的三步曲：技術準備期、業務回補期、成長優化期。而後在那篇《邁向 tech lead 之路》裡，我將 tech lead 要做的事情，結合到了三步曲中，便有了下圖：
tech lead 在專案的實踐
為此，我們將乙個 tech lead 要做事情分為了三個部分，即：process、people、programming。 這一點對於新專案的檢查清單來說，也有些類似。稍有不同的是，我們需要在其中加入關於業務的維度。此此，我們可以劃分為四個維度：
作為檢查清單的第乙個版本，它的維度設計可能並非那麼完善。但是隨著時間的改進，我們可以一起把它變得更好。
0. 技術遠景
說明：在技術上，我們有什麼追求？
1. 文件
說明：文件即**——好的文件應該是版本管理的。
2. 架構
3. **庫
4. 測試
5. 專案演進
6. 安全
0. project process
1. path to development
說明：不同的的組織包含自身特別的情況，如 pc 埠、網路許可權、**庫許可權等的開通都需要一定的流程。
2. path to production
說明：**中的 path to production 只是乙份說明——針對於開發人員的，而這裡的則需要乙個更詳細的說明。
3. path to roll off
說明：換乙個專案時，需要哪些東西？
1. 團隊成員
2. 利益相關者
3. 跨團隊協作
4. 使用者
0. 業務遠景
說明：我們在做什麼，我們要去**？
1. 業務需求
2. 跨功能需求
為了方便我未來在新專案使用它，我建立了乙個專案來更新這個清單：
與此同時，建立了乙個 web 應用來檢測：
如果我們的清單不是那麼完善，那麼作為乙個 tech lead 又或者是乙個額外的關鍵角色，我們應該完善相關的部分。
未來，我們是否還會有這樣的工具，來幫助我們更好地做相關的工具呢？
專案管理檢查清單 專案規劃
編號 檢查項1 是否了解客戶 資訊中心和業務處室 對專案的期望？2是否制定了專案管理計畫 專案總體計畫 3是否根據招標書和投標書編寫的軟體需求說明書初稿？4是否制定了需求管理計畫？5是否建立了需求跟蹤矩陣？6是否確定了專案範圍？7是否建立了工作分析結構wbs？8是否確定了專案里程碑？9是否制定的專案...
專案管理檢查清單 專案啟動
編號 檢查項備註 1是否了解了專案的基本情況 專案大概做什麼，是誰提出來的，解決什麼問題 2是否已經確定專案團隊成員及其分工？3是否已經確定專案資源需求？4是否有了專案總體規劃？5是否了解專案存在的風險及其應對策略？6是否了解公司領導對專案的期望 是否重視，想達到什麼目的 7是否召開了專案內部啟動會...
機器學習專案流程清單
這份列表可以知道你部署自己的機器學習專案。總共有八個步驟 首先你要有乙個要解決的問題 獲取解決問題需要的資料 探索資料，對資料有乙個清楚的理解 預處理資料以便更好地輸入給機器學習演算法 探索不同的模型並且找到最好的那個 調整你的模型引數，並將這些引數組合成乙個更好的解決方案 展示你的結果 對你的系統...