上篇文章主要講踩坑。初次接項目，在項目開始前夕遇到的一些坑，並提供了一些個人建議。最後說到原型的遲遲交付、需求方對接人員的變更、硬件開發團隊人員離職等等，各種因素都在拖累項目的進度。
當然，項目中也不是隻有坑，也有一座高山。今天就繼續回顧接下來項目過程，講講如何爬這座山。
既然選擇了遠方，便只顧風雨兼程。 —— 汪國真 《熱愛生命》
萬事開頭難
中間因爲需求整理、原型設計、經歷長假一連串的折騰，等到原型最終交付出來，距離合同簽訂時間已經過去了一個月。如果按照合同上的交付時間來算的話，也意味着我們開發時間已經少了一個月。
合同上寫明自簽訂日期開始項目正式開始，直到 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，不包含新功能的開發和功能變更。如有相應需求，可追加相關協議。
最後總結
項目到此也結束了，回過頭看看，整個項目最花費時間精力的地方，還是開始時和對方溝通整理需求，因爲相隔兩地，線上溝通效率又不高，花費了大量的時間和精力在業務層面。
當然，現在一般的外包項目都是需求很明確，只需要將之由需求層面實現出來就好，這樣讓專業的人做專業的事。所以建議大家想圖省心的話，還是上正規的外包平臺接活，因爲做一個外包項目要當項目經理、產品經理、開發人員，真的太累了:(