我是怎麼把一個項目帶崩的
我是一名項目經理，在過去的四個月里，我把一個項目帶崩了（上線後頻出問題，用戶無法使用）。在最近的幾天，我每天都在反思自己，我都在問自己以下幾個問題：
我做錯了什麼？
我在其中佔有多重的因素？
以下內容，我將回答以上問題，並在最後說一下我的補救措施。
項目和團隊背景
首先給大家說明一下項目背景，以便各位對此項目有更清晰的了解：
該項目是一個二次開發項目，第一個基礎版本（列印申報系統）也由我帶領開發。
系統是需要和國家系統對接，有三條主流程。
需求頻繁變化，由於系統需要對接國家系統，需求方對需求也不甚了解。曾在 5 月份一個月內需求變更超過 8 次，都是主流程變更。
項目大小按照最初需求估算，約在 100 人天左右。
項目兩條主流程無法測試，依賴於外部 U 盾，但開發過程中並沒有 U 盾。
客戶現場使用 U 盾調試和開發時間約為 20 天左右。
我當時同時負責大大小小 4 個項目，沒有進入開發，僅管控進度。
團隊成員共 3 名，其中兩名是當時開發基礎版本的項目成員，他們對此項目較為熟悉。
項目推進過程中，需要多次去現場調試測試，由團隊中的兩名工程師共同前去。
我做錯了什麼
除了監控進度，還要管理質量
在項目的開發初期，我制定了一份詳細的開發計劃，用於指導整個開發過程。開發計劃交付與了客戶，而答應了的事情就要做到，所以在整個項目過程中，我對進度管控很嚴。我定期檢查功能是否完成，定期和客戶彙報情況，保證了開發進度順利推進。但也由此埋下了禍根，僅僅看需求是否完成，而未關注完成的質量如何。
項目質量出現了許多細節性問題。比如：
上線後，客戶那邊發現其中一條主流程都走不下去
其中申報功能，系統提示成功。但實際上並沒有真的申報成功，申報後在國家系統無法查詢到
列印功能小問題較多，列印獲取的數據錯誤
同步數據的功能無法同步或者同步的數據錯誤
執行時間過長的功能，資料庫會強制斷開連接
等等問題，就不一一列舉
反思：
進度和開發速度固然重要，但以質量換速度不可取
如果開發時間和質量衝突，優先保質量，畢竟你埋下的坑，總是要坑你自己的
再困難的情況下，也要保證基本測試
時間極其不允許的情況下，也要保證主線功能順利執行
既要給予信任，也要保持警惕
項目中的三名成員，都是合格的開發，對使用的框架非常熟悉。其中兩名還是基礎版本開發成員，對需求也很熟悉。所以項目中，我放心的把整個項目交給了他們。基於對他們的放心，加上其他項目事情繁雜，對此項目關注度，對他們的關注度就不夠了。
我在項目中給予了他們非常充分的信任，信任他們可以把一切事情都做好。但我沒有在正確的時候給予他們正確的指引，項目中出現的困難點，我也沒有幫助他們解決，甚至於沒有給出思路。所有的一切，都靠他們自己完成。我在這個項目里做的，就是對接客戶，催進度。再無第三件事。
反思：
不論什麼原因，都要關注到項目成員的狀態
給予信任沒錯，但也要適當保持警惕，他們多少會因為經驗問題疏忽遺漏一些問題
給予信任，也要給予幫助，不以時間為理由推脫你應該對他們進行的指點和幫助。畢竟現在剩下來一分鐘，以後要花一個小時去彌補
若無法全局掌控，就指派專人負責
這是我在項目中做的最錯誤的地方。
由於種種原因，我無法掌握到項目的每個要點和細節。而項目中有三個開發。我並沒指明其中某一個來負責整個項目，所有事情都讓他們自己商量。從客戶對接來的問題，我也是僅告知對應的開發。整個項目中，沒有一個人對項目中的每個要點了如指掌。
反思：
手裡捏著管理的權利，卻沒有做到管理的事情。是我在這個項目里最大的問題
授權！授權！授權！如果自己無法親力親為投入項目管理工作，就授權給團隊某個成員管理許可權，讓他代替你去做管理工作
管理一人，總比管理多個人輕鬆，也更有效
要控制需求，更要控制流程
項目是二次開發、成員對項目很熟悉、項目工作量不大、時間緊。
基於以上原因，我掉以輕心，沒有在項目初期進行項目的設計和規劃，未指定任何開發規範。僅僅告訴開發的同事要多復用，也未檢查他們是否真的復用了。
項目開發中的需求變更，客戶反饋意見，我我都僅僅是告知他們一聲，未做詳細的修改規劃，所有事情都靠嘴說，所有變動都放在了我和他們的腦子裡。
對項目上心程度不夠，未對客戶的需求變更做控制和管理。所有變更都壓給了開發的同事。
整個項目以及其不規範的方式在運行，我也未在其中起到控制作用，項目開發一團亂麻。
反思：
不做設計，不進開發
以管理工具指導開發進行，開發過程中所有變更、反饋做記錄
控制需求變更，拒絕不合理的需求
需求變更規範化操作，統一變更，而不是直接壓給開發
無論什麼情況下，都要進行 code review
整個項目過去了幾乎四個月，我僅僅花了兩個多小時簡單看了下代碼，未指出代碼的任何問題。這也導致出問題後來我花了成倍的時間來處理 code review 的工作，並且項目成型後的代碼修改困難。
項目開發過程中，也未讓開發間互相進行代碼 review，也沒有進行代碼評審會。
其實代碼中出現了很多問題，最後檢查代碼的時候，發現各種命名不規範、代碼復用不到位、簡單邏輯複雜寫等等。而這些問題，很大一部分都是早期未做規定，未指定人負責項目、未進行早期 code review 造成的。開發各自為戰，難免造成代碼問題。
代碼質量的問題，淋漓盡致的體現的在項目中，項目中的諸多 bug，都是因為代碼不規範引起的。甚至於開發人員自己對自己寫過的東西，都有些拎不清了。
反思：
代碼質量非常重要，代碼越規範 bug 越少
代碼互評能讓開發更注重自己代碼的質量
code review 非常有必要，越早期的 code review 越能有效的節省後期的時間
我在其中佔有多重的因素
100%
我怎麼填坑的
項目上線，問題頻出，用戶不滿。花了 8 天時間來處理這個問題。幸虧項目不大，我一個人也能夠挽回。
目前暫時解決完畢，我簡單說一下我是怎麼填坑的：
和開發主流程的同事詳細熟悉了所有需求要點
基於我對項目需求的熟悉，我花了三天把所有主流程的所有代碼分析完畢，做出了我認為應該的修改，並實施部署到生產環境測試（這是在給開著的飛機換引擎，但需要 U 盾才能測試，僅有生產環境的機器有 U 盾，別無他法）
每天花超過 12 個小時來進行 code review 和修改，幾乎每天 code review + 修改到凌晨 2 點多（僅修改了問題較大且影響較小的地方。小問題未修改、牽涉面較廣的地方未修改）
每次上班時間的修改讓開發同事坐在旁邊和我一起進行，我進行修改，開發同事在一旁監督。確保我不出錯
優化功能點，把我發現的提示問題，和優化點都同步修改進代碼中，確保用戶體驗不要太糟，以期能挽回一些用戶心態
我所吸取的教訓總結
先設計，後開發
管理權下放，項目中必須有人全身心負責
無論什麼情況都要進行 code review
壓縮質量得到的進度保證不可取，開發周期不合理決不答應客戶。否則坑了自己坑了同事，更坑了客戶
作者：zer0Black
https://www.cnblogs.com/zer0Black/p/9463206.html
TAG:JavaScript |