題外話

在此之前，筆者主要從事傳統IT企業的研發技術管理工作，對項目管理雖然有一定的經驗，但純粹摸石子過河，沒有系統的學習過項目管理理論，也很容易犯下技術人員對項目管理的一系列毛病。

之前帶的項目一般都是非產品型項目，功能一般以實現為主，對細節沒有太多要求。項目一般采用瀑布模型，項目之初一般會制定一個非常詳細的研發計劃，涵蓋需求分析、設計、研發、測試、驗收的全過程。由于用戶驗收測試往往需要花大量時間，因此會輸出一份沉甸甸的需求說明書，然后讓客戶簽字，并在驗收階段，在現場維持長時間的駐場開發，以便實時跟進需求的變化。曾經創造了帶領10人研發團隊、連續3個月，每天維持12個小時以上工時的工作記錄。（堪稱土勞模）

這是第一次參與互聯網項目的開發，有明確的迭代周期和需求計劃，但是由于各種原因，卻逐漸走向失控，過程中究竟發生了什么原因？

失控全過程

話不多說，直接進入正題。

我將盡量以第三人稱視角記錄一個失控的項目，但事實上我實際是項目負責人，所以難免有失偏頗。

這是B公司一個面向特定行業的虛擬建站平臺產品，雖然市面上建站產品非常多，但由于B公司在該行業頗有地位，能夠獲得一些比較實用的數據，這些數據是目標用戶群體非常渴求的寶貴資源，因此如果將這些數據做成可視化組件然后打造這樣的精準型建站產品，顯然具有獨特性的優勢，能夠為目標用戶帶來便利。

產品于2月底開始啟動會，由研發部門內部碰頭后，直接開始啟動項目。（該公司管理比較扁平化，產品、研發、測試、設計分屬技術部四個不同的團隊）。

由于是互聯網產品，因此往往會選擇競品。競品為為3個比較熱門的互聯網建站平臺，其目標是要滿足這些建站平臺的特性，包含一個功能強大、效果優雅、流程簡單的設計器；實現自動化建站部署等。在項目初期僅明確了總功能點的約40%，初步估計需要完成大大小小的頁面15個，設計數據庫20幾個表。

（最終做出的頁面數量雖然沒增加，但是前端的邏輯也非常復雜、后端邏輯也有點復雜，數據庫有45個表，大小接口將近80個）

技術總監指示：采用敏捷開發模式。總工期為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小時耐心寫代碼、努力提高研發產出的軟件工程師團隊是互聯網產品成功的核心關鍵。

一味的壓縮工時來完成產品的研發不現實，在時間、進度、質量之間，必須找到一個中間點，這就要求做好客戶的預期管理。

轉載于:https://www.cnblogs.com/xiyuanMore/p/11568676.html

總結

以上是生活随笔為你收集整理的项目失控全记录的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。