題外話
在此以前，筆者主要從事傳統IT企業的研發技術管理工做，對項目管理雖然有必定的經驗，但純粹摸石子過河，沒有系統的學習過項目管理理論，也很容易犯下技術人員對項目管理的一系列毛病。前端
以前帶的項目通常都是非產品型項目，功能通常以實現爲主，對細節沒有太多要求。項目通常採用瀑布模型，項目之初通常會制定一個很是詳細的研發計劃，涵蓋需求分析、設計、研發、測試、驗收的全過程。因爲用戶驗收測試每每須要花大量時間，所以會輸出一份沉甸甸的需求說明書，而後讓客戶簽字，並在驗收階段，在現場維持長時間的駐場開發，以便實時跟進需求的變化。曾經創造了帶領10人研發團隊、連續3個月，天天維持12個小時以上工時的工做記錄。（堪稱土勞模）程序員
這是第一次參與互聯網項目的開發，有明確的迭代週期和需求計劃，可是因爲各類緣由，卻逐漸走向失控，過程當中究竟發生了什麼緣由？數據庫
失控全過程
話很少說，直接進入正題。後端
我將盡可能以第三人稱視角記錄一個失控的項目，但事實上我實際是項目負責人，因此不免有失偏頗。工具
這是B公司一個面向特定行業的虛擬建站平臺產品，雖然市面上建站產品很是多，但因爲B公司在該行業很有地位，可以得到一些比較實用的數據，這些數據是目標用戶羣體很是渴求的寶貴資源，所以若是將這些數據作成可視化組件而後打造這樣的精準型建站產品，顯然具備獨特性的優點，可以爲目標用戶帶來便利。學習
產品於2月底開始啓動會，由研發部門內部碰頭後，直接開始啓動項目。（該公司管理比較扁平化，產品、研發、測試、設計分屬技術部四個不一樣的團隊）。測試
因爲是互聯網產品，所以每每會選擇競品。競品爲爲3個比較熱門的互聯網建站平臺，其目標是要知足這些建站平臺的特性，包含一個功能強大、效果優雅、流程簡單的設計器；實現自動化建站部署等。在項目初期僅明確了總功能點的約40%，初步估計須要完成大大小小的頁面15個，設計數據庫20幾個表。網站
（最終作出的頁面數量雖然沒增長，可是前端的邏輯也很是複雜、後端邏輯也有點複雜，數據庫有45個表，大小接口將近80個）spa
技術總監指示：採用敏捷開發模式。總工期爲8周，按2週一迭代。項目啓動時，共有後端開發者3人，前端1人、產品1人、設計1人，測試1人。由本人擔任整體負責人和後端開發者。設計
這個配比自己不太合理的項目，顯然8周時間不可能完成，但領導沒有進一步的時間計劃，只能基於現有資源制定爲期八週的先啓階段，其目標是搭建符合流程的最小可行版本(MVP)。因爲大部分功能都在前端，可是實際上僅配了一位前端，並且這位前端是公司的前端負責人，天天僅能花不到40%的時間投入到項目研發過程當中。後端則能夠開始根據現有需求進行數據庫、接口的設計。
這個MVP版本包含網站定義、網站編輯、網站設計器和發佈流程、目前需求範圍內的接口功能開發，工期爲8周。
項目組還需另外招聘3位前端開發者。
到五月底最終完成整個MVP功能開發花了十週時間。由於前端部分的工做量大於預估，僅設計器就花了6周。5月完成簡單的演示，基本符合主體流程。
此時項目需求已經明確了60%，技術總監認爲7月底能夠完成功能的開發。
因而從5月開始，到7月底，共有10周時間，開始進入倒排期。慶幸項目組成員已經配齊，至少是有人能夠用。但在需求池裏面的需求很是多，因此你們得加班。因而集體開始進入加班狀態。
項目很給力，動做交互和邏輯很是多，許多樣式和動做都須要前端開發，幾乎沒有任何能夠複用的經驗，因爲設計器自己是趕工期趕出來的，功能不完善，並且還有不少組件功能須要開發，最終於7月20幾號左右完成主體功能的開發，可是有較多量的bug，推遲到8月6日才能交付測試，而後還剩餘的40%功能點。
因爲項目已經嚴重滯後，上線目標定在9月中旬，又是一輪加班，堅持到8月底。
需求勉強控制住了，可是bug卻愈來愈多，已經遠遠不可能在9月交付了。
一句話總結：開始時，沒人，趕時間；後來人來了，可是任務多，趕時間；最後，任務多，bug多，也趕時間。 程序員們的996,就是這麼產生的。
項目結局
進入9月，公司高層對項目提出了新的要求，項目需求將進一步增長。
因爲負面情緒的影響、以及對在這家公司的發展前途迷茫、沒法忍受高強度的工做、轉Java等緣由，本人提出離職；
而擔任前端開發工做的核心開發者也一樣由於待遇問題、發展前途、技術路線不匹配等緣由提出離職。
項目完全失控。
問題分析
- 未能及時的向上級彙報可能存在的風險，未能考慮補償資源等問題。未能實時的進行問題的跟進，彙報和溝通，直到最終問題沒法彌補而爆發。
- 項目管理過程當中過程數據不完善，沒法造成有效的經驗教訓知識庫，容易形成組織過程資產的流失。
- 這個項目前期需求範圍雖然比較明確，可是技術細節多，人員不足，設定工期內明顯完不成。
- 項目團隊屬於從新組建的團隊，都是入司未滿一年的新員工，且還有一半是在項目期間組建的新員工，彼此缺少磨合。
- 項目任務優先級不明確，對MVP的粒度劃分也不合理。（由於設計器功能很複雜，花費了大量的時間去開發）前期的功能粒度劃分不合理，測試沒法第一時間介入，問題積累到後期爆發。
- 功能邏輯複雜，細節頗多。拍腦殼式的工時估算和計劃不適合此類項目。
- 異地溝通自己存在時延，影響了項目執行效果。
- 因爲爲了完成不可能完成的任務，項目組成員被迫趕工期，爲了盲目應對需求變化而投機取巧，不免會改出新問題。
- 公司內部對代碼質量和工期提出了新要求，延遲這麼兇的項目顯然不會得到高績效；除此以外，內部政策變更，要求實施9116的工做制度，加上提出了封閉項目等政策，讓內部消極情緒開始佔上風。
- 自己存在一些技術問題。
結論
使用好項目管理工具備利於知識的傳承和積累，對項目管理過程來講尤其重要，這個項目雖然使用了Jira做爲項目管理工具，設定了迭代目標和週期，可是未能妥善使用，依然是用excel進行項目管理，措施不科學，也沒法直觀的觀察項目進程。
互聯網產品致力於爲用戶提升更高的用戶體驗，所以須要花更長的時間和精力進行UI級的打磨、開發者也一樣須要花更大的時間來完成對應的開發任務，做爲項目經理要學會作好上下溝通，遇到問題應該給出本身的專業意見，有問題應該儘早向領導彙報風險，積極的反饋意見，哪怕收不到積極的響應，也能起到提早預防的做用。
進度和計劃當然是很重要的，可是要認識到人才是企業的核心競爭力，一支對產品精益求職的產品設計團隊、一支天天願意花10小時耐心寫代碼、努力提升研發產出的軟件工程師團隊是互聯網產品成功的核心關鍵。
一味的壓縮工時來完成產品的研發不現實，在時間、進度、質量之間，必須找到一箇中間點，這就要求作好客戶的預期管理。
