上一篇: 覆盤 | 初次接專案的血與淚，扎坑了老鐵
上篇文章主要講踩坑。初次接專案，在專案開始前夕遇到的一些坑，並提供了一些個人建議。最後說到原型的遲遲交付、需求方對接人員的變更、硬體開發團隊人員離職等等，各種因素都在拖累專案的進度。
當然，專案中也不是隻有坑，也有一座高山。今天就繼續回顧接下來專案過程，講講如何爬這座山。
既然選擇了遠方，便只顧風雨兼程。
—— 汪國真 《熱愛生命》
萬事開頭難
中間因為需求整理、原型設計、經歷長假一連串的折騰，等到原型最終交付出來，距離合同簽訂時間已經過去了一個月。如果按照合同上的交付時間來算的話，也意味著我們開發時間已經少了一個月。
合同上寫明自簽訂日期開始專案正式開始，直到 xxxx 年 x 月 x 日。因為前期準備工作耽誤了太多時間，如果就這麼下去的話，專案風險很大，且會違反合同交付時間。基於此，我和對方人員溝通一下，明確是因為前期需求整理和產品原型設計耽誤太多時間導致整體進度 delay，並確定整體進度預計會後延多少個工作日，這一切都擬定一個補充協議。
千里之行，始於足下
專案要開始，自然不能一股勁兒幹，做好開發計劃，不打無準備之仗。我們採用敏捷開發模式，所以下面這些內容很多是基於敏捷開發模式。
消化需求
首先，組織大家閱讀消化專案需求。需求的理解非常重要，我見過許多開發人員，沒有理解需求，上手就是一個字：幹，然後開發過程各種問題，手忙腳亂地開發，還抱怨時間少、進度趕，結果自然開發效率和質量難以樂觀。
仔細理解專案需求，正是磨刀不誤砍柴工。設計人員理解了，可以更好的設計使用者互動；開發人員理解了需求，可以避免後續開發中遇到因為需求不明而導致的邏輯問題；專案經理理解了，可以更好地把控專案的進度和細節，也更有效率地和團隊人員溝通，不至於因為中間出現問題專案經理表示一臉茫然。
任務拆分
在理解需求之後，我們開始進行任務的拆分。任務拆分中，基於幾個原則：
任務粒度原子化。 最小粒度確保開發目標清晰，不涉及其他任務，可以更好的評估任務複雜度和開發估時。
目標為獨立個人。避免單個任務產生人員依賴，如有需要多人蔘與的任務，可以獨立劃分給相關人員。
任務需要有優先順序。如有強依賴，可定義好前置依賴。
舉例：使用者登入的功能，需要怎麼拆分？UI設計一個任務、前端登入一個任務、後端登入一個任務？說是一個登入功能，裡面可能包含：
- 賬號密碼登入（手機號、Email、使用者名稱）
- 手機號快捷登入
- 第三方登入（微信、微博、QQ等）
- 其他方式登入（如卡號卡密登入、SSO登入等）
手機登入需要涉及簡訊 SDK（註冊申請、後臺接入 SDK）、獲取驗證碼、傳送頻率限制、黑白名單等等；Email 涉及 Email 傳送、驗證；使用者名稱涉及敏感詞檢測、唯一性檢測；第三方登入需要涉及第三方 SDK（註冊申請、後臺接入、前端接入）。
所以你看，任何任務的拆分，都應該首先從業務角度出發，列出到底有多少種應用場景和可能性，然後逐個拆分細化。只有不斷的將任務一點點地解剖到骨肉分離、細節毫髮畢現，才能避免因為經驗和時間的問題，沒有看到一些暗藏的功能和細節，導致開發過程中處處踩雷。
時間評估
任務拆分後，評估時間的時候，開發人員一般會比較樂觀，另外一般專案也因為趕進度壓縮時間，我的建議是在條件允許的情況下，儘可能預留充裕的開發時間和緩衝時間。長期地壓縮開發時間快速開發和趕進度，會壓縮開發人員深度思考的能力，當然最終影響到的還是產品的質量。
外包專案中，時間評估上儘可能細緻周全，將需求整理、原型設計、UI 設計、架構設計、專案搭建、功能開發、測試聯調、文件整理交付、交付驗收、專案上線等時間都區分開（因專案、需求而異會有不同）。
任務拆分和評估時間後，所有的資訊都輸出到專案管理工具上，然後製作燃盡圖。即使沒有專案經理也可以實現成員自我管理。如有專案經理，也可以基於此整理出一個開發排期表和甘特圖。
Let’s go!
如果一個外包專案合同已經簽訂下來，專案正式啟動，那麼就早些動手吧。避免拖延症，儘早地讓團隊齊心協力，向著完成專案的目標前進。尤其是業餘時間做外包專案，有各種理由和原因遲遲不行動，最終耽誤的時間還是會由自己埋單。
這次外包也遇到這個問題，因為前期準備工作耽誤時間太久的緣故，專案整個處於 blocked 狀態，過了一段時間詢問相關開發人員進度，得知還沒有開始。
技術選型
技術選型要貼合業務場景，外包專案更要如此。當業務初期時，技術要靈活，以便快速驗證業務模式，就是說要能靈活地改改改；當業務處於穩定期，技術要穩定，不能拖技術後腿，就是說業務正常了系統不能整天出 Bug 或者伺服器沒事就提出一個問題；當業務處於維護期時，技術要講究妥協，就是說不能還花費大量精力折騰專案，維穩就好。
總之，技術選型都是為了業務服務。比如因為對方有 iOS/Android 兩端 App 的要求，在仔細評估需求後，決定採用 Native + React 模式開發，這樣開發效率提高了，開發成本也降低了。
時間管理
時間管理上，因為是業餘時間做外包，所以本職工作和外包上的時間花費一定要平衡好，不能因為外包耽誤本職工作，當然也不能將外包置之一旁。
每個人有自己的時間管理觀念和舒適的狀態，比如我，我個人比較喜歡的狀態是早起寫一陣程式碼，如果是工作日的話大概是一個多小時，上班時間專心處理公司事情，下班回家後繼續處理外包工作一兩個小時，這樣每天可以有將三個小時左右的時間處理外包任務。夜晚務必早睡，這樣可以保證第二天的狀態，不影響本職工作。如果是週末的話，早上會運動，洗澡吃飯後精神倍爽，一口氣可以持續工作到中午。
外包過程中務必找到自己最習慣的節奏和最舒適的狀態，本職工作和外包專案一定不能顧此失彼。當然更重要的是，個人的健康狀況，畢竟身體是革命的本錢。
專案管理
前面提到，敏捷開發會採用一些專案管理工具，如Tapd、Tower、Trello、Teambition等。基本上當一個團隊有了經驗後，都可以使用這些工具實現自管理。但因為是初次接外包，和團隊成員磨合也是一個挑戰，加上每個人個性不同，和外包專案的特殊性，作為專案管理人員需要在專案管理上投入一定的精力和時間。
專案管理千差萬別，專案管理人員也千差萬別。記得以前公司有過兩任完全不同風格的專案管理人員，一個是每天晨會出現一次，其它時間見不到人，基本沒什麼存在感；另一個是每天像班主任一樣跟在團隊成員屁股後面催進度，結果導致團隊產生了嚴重的依賴性，在他突然離職後，專案基本處理停滯狀態，團隊成員也完全無法適應。
我的想法是，團隊成員可以有不同的時間管理方式，和投入方式，但是務必保證有持續性的產出。所以，在專案前期，我們便花一部分精力搭建了 CI 系統（持續整合），後臺和前端人員在實現功能提交程式碼後，可以選擇自動釋出專案或者一鍵釋出，工作成果開發團隊和外包需求方都可以檢視。使用 CI 後，專案的進度就一目瞭然，不會處在一個黑盒裡面。CI 的意義是以最小的精力，實現最大的價值。
外包專案如果週期很長，會是一個永續性的拉鋸戰。因為團隊成員都在一個城市，所以我們除了日常的開發和溝通外，定期會組織大家坐在一起工作，這樣面對面地溝通交流，將之前因非同步溝通無法解決的問題提出來解決。比如租個酒店房間，大家週末一天或者兩天時間呆在那裡，沒有其它的干擾，可以全身心地投入到專案中。一般這樣的一天，可以有幾天的產出。當然這樣高專注度、高強度的工作也會使人比較疲憊，所以不必經常這麼做。
當然主要還是大家日常開發、溝通，所以養成線上及時同步開發進度、共享開發中存在的問題很重要，我們當時是每日在微信裡面溝通進度，然後如果 CI 有更新，大家可以相互體驗測試，發現問題，有問題直接在微信裡溝通，如果落實下來，直接輸出到問題管理系統裡。
在整個開發過程中，可以將重要的、難度比較大的任務優先解決，這樣防止後續時間不充足的情況下，解決難度大的問題沒有太多的精力。
里程碑交付
里程碑交付也是外包專案中關鍵的一環，在之前任務模組拆分和評估時間後，專案經理可以根據進度安排里程碑交付，在一定週期內按時按量交付已有功能模組，避免專案週期持續太久客戶接收不到產出。儘早的交付，可以驗證一些功能，也可以暴露一些問題，甚至瞭解客戶的驗收喜好標準等等。
例如，一個購物網站，可以根據功能劃分為商品模組、會員模組、訂單模組、購買支付幾大模組，然後依據優先順序分期交付一些模組。
記得之前在雲沃客上接專案時，專案裡面會有里程碑的歷史記錄，詳細記錄了每一個階段的任務、截止日期、金額和狀態，每一個階段都會有交付工作和申請結款兩種操作，將里程碑線上化，工作者和需求方都能清晰地檢視到每個階段的工作狀況和歷史交付產品。
交付驗收
辛苦一段時間，最終將專案交給客戶手裡，因為前面已經有 CI 系統和里程碑交付，所以對客戶的驗收標準是有一些心理準備。專案中的一些問題，也儘量會在開發階段就溝通處理掉，爭取不在最後交付驗收時遺留問題。最終交付給客戶一定是包含完整功能、能穩定執行的系統。
關於後續維護，開始簽訂合同時已經約定好免費維護週期，這期間只包含處理線上問題和解決 Bug，不包含新功能的開發和功能變更。如有相應需求，可追加相關協議。
最後總結
專案到此也結束了，回過頭看看，整個專案最花費時間精力的地方，還是開始時和對方溝通整理需求，因為相隔兩地，線上溝通效率又不高，花費了大量的時間和精力在業務層面。
當然，現在一般的外包專案都是需求很明確，只需要將之由需求層面實現出來就好，這樣讓專業的人做專業的事。所以建議大家想圖省心的話，還是上正規的外包平臺（比如雲沃客）接活，因為做一個外包專案要當專案經理、產品經理、開發人員，真的太累了:(