【避坑】初次接項目的血與淚，扎坑了老鐵（二）

上一篇: 覆盤 | 初次接項目的血與淚，扎坑了老鐵

上篇文章主要講踩坑。初次接項目，在項目開始前夕遇到的一些坑，並提供了一些我的建議。最後說到原型的遲遲交付、需求方對接人員的變動、硬件開發團隊人員離職等等，各類因素都在拖累項目的進度。

固然，項目中也不是隻有坑，也有一座高山。今天就繼續回顧接下來項目過程，講講如何爬這座山。

既然選擇了遠方，便只顧風雨兼程。 —— 汪國真 《熱愛生命》

萬事開頭難

中間由於需求整理、原型設計、經歷長假一連串的折騰，等到原型最終交付出來，距離合同簽定時間已通過去了一個月。若是按照合同上的交付時間來算的話，也意味着咱們開發時間已經少了一個月。

合同上寫明自簽定日期開始項目正式開始，直到 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，不包含新功能的開發和功能變動。若有相應需求，可追加相關協議。

最後總結

項目到此也結束了，回過頭看看，整個項目最花費時間精力的地方，仍是開始時和對方溝通整理需求，由於相隔兩地，線上溝通效率又不高，花費了大量的時間和精力在業務層面。

固然，如今通常的外包項目都是需求很明確，只須要將之由需求層面實現出來就好，這樣讓專業的人作專業的事。因此建議你們想圖省心的話，仍是上正規的外包平臺接活，由於作一個外包項目要當項目經理、產品經理、開發人員，真的太累了:(