我是如何帶崩一個專案的
文章目錄
我是一名SM,在過去的一個月裡,我把一個專案帶崩了。在最近的幾天,我每天都在反思自己,我都在問自己以下幾個問題:
- 我做錯了什麼?
- 我在其中佔有多重的因素?
- 為什麼團隊每個組員都累趴下了?
以下內容,我將回答以上問題,並在最後說一下我的補救措施。
一、專案和團隊背景
首先給大家說明一下專案背景,以便各位對此專案有更清晰的瞭解:
1.該專案是政府專案,由我帶領開發。
2.需求頻繁變化,需求方對需求也不甚瞭解。曾在一個月內需求變更超過3次,都是主流程變更。
3.專案大小按照最初需求估算,約300人天左右,由於需求的增加,工作量增加到1000人天。
4.專案採用前後端分離、微服務架構,而我們團隊沒有足夠的前端開發人員,並且沒有測試人員。
5.我前期進入開發,後期僅負責需求對接和管控進度。
6.團隊成員共10名,團隊臨時元件,組員之間缺乏默契。
二、我做錯了什麼
1. 除了監控進度,還要管理質量
在專案的開發初期,我制定了一份詳細的開發計劃,用於指導整個開發過程。開發計劃交付與了客戶,而答應了的事情就要做到,所以在整個專案過程中,我對進度管控很嚴。我定期檢查功能是否完成,定期和PO彙報情況,保證了開發進度順利推進。但也由此埋下了禍根,僅僅看需求是否完成,而未關注完成的質量如何。
2. 專案質量出現了許多細節性問題
比如:
1.部署後,測試發現兩條主流程都走不下去,就是登陸都有問題;
2.有些功能,系統提示成功,但實際上並沒有真的成功,排查問題花費了太多時間;
3.程式碼提交流程混亂,程式碼覆蓋的問題較多;
4.有些流程狀態是錯誤的;
5.業務邊界混亂,缺乏統一的流程標準,導致開發人員隨意跨越邊界;
等等問題,就不一一列舉
反思:
1.進度和開發速度固然重要,但以質量換速度不可取
2.如果開發時間和質量衝突,優先保質量,畢竟你埋下的坑,總是要坑你自己的
3.再困難的情況下,也要保證基本測試
4.時間極其不允許的情況下,也要保證主線功能順利執行
3. 既要給予信任,也要保持警惕
專案中的幾名成員,都是合格的開發,對使用的框架非常熟悉。其中兩名還是基礎版本開發成員,對需求也很熟悉。所以專案中,我放心的把整個專案交給了他們。基於對他們的放心,加上其他專案事情繁雜,對此專案關注度,對他們的關注度就不夠了。
我在專案中給予了他們非常充分的信任,信任他們可以把一切事情都做好。但我沒有在正確的時候給予他們正確的指引,專案中出現的困難點,我也沒有幫助他們解決,甚至於沒有給出思路。所有的一切,都靠他們自己完成。我在這個專案裡做的,就是對接PO,催進度。再無第三件事。
反思:
1.不論什麼原因,都要關注到專案成員的狀態
2.給予信任沒錯,但也要適當保持警惕,他們多少會因為經驗問題疏忽遺漏一些問題
3.給予信任,也要給予幫助,不以時間為理由推脫你應該對他們進行的指點和幫助。畢竟現在剩下來一分鐘,以後要花一個小時去彌補。
4. 缺乏全域性掌控,指派專人負責
這是我在專案中做的最錯誤的地方。
由於種種原因,我無法掌握到專案的每個要點和細節。而專案中有三個開發。我並沒指明其中某一個來負責整個專案,所有事情都讓他們自己商量。從客戶對接來的問題,我也是僅告知對應的開發。整個專案中,沒有一個人對專案中的每個要點了如指掌。
反思:
1.手裡捏著管理的權利,卻沒有做到管理的事情。是我在這個專案裡最大的問題
2.授權!授權!授權!如果自己無法親力親為投入專案管理工作,就授權給團隊某個成員管理許可權,讓他代替你去做管理工作
3.管理一人,總比管理多個人輕鬆,也更有效
5. 要控制需求,更要控制流程
初開始針對專案的需求,感覺專案工作量不大、時間夠。基於以上原因,我掉以輕心,沒有在專案初期進行專案的設計和規劃,未指定任何開發規範。僅僅告訴開發的同事要多複用,也未檢查他們是否真的複用了。
專案開發中的需求變更,客戶反饋意見,我我都僅僅是告知他們一聲,未做詳細的修改規劃,所有事情都靠嘴說,所有變動都放在了我和他們的腦子裡。未對客戶的需求變更做控制和管理。所有變更都壓給了開發的同事。
整個專案以及其不規範的方式在執行,我也未在其中起到控制作用,專案開發一團亂麻。
反思:
1.不做設計,不進開發
2.以管理工具指導開發進行,開發過程中所有變更、反饋做記錄
3.控制需求變更,拒絕不合理的需求
4.需求變更規範化操作,統一變更,而不是直接壓給開發
6. 無論什麼情況下,都要進行code review
整個專案過程中,我主抓需求,忽略了檢視程式碼,未指出程式碼的任何問題。這也導致出問題後來我花了成倍的時間來處理code review的工作,並且專案成型後的程式碼修改困難。專案開發過程中,也未讓開發間互相進行程式碼review,也沒有進行程式碼評審會。
其實程式碼中出現了很多問題,最後檢查程式碼的時候,發現各種命名不規範、程式碼複用不到位、簡單邏輯複雜寫等等。而這些問題,很大一部分都是早期未做規定,未指定人負責專案、未進行早期code review造成的。開發各自為戰,難免造成程式碼問題。
程式碼質量的問題,淋漓盡致的體現的在專案中,專案中的諸多bug,都是因為程式碼不規範引起的。甚至於開發人員自己對自己寫過的東西,都有些拎不清了。
反思:
1.程式碼質量非常重要,程式碼越規範bug越少
2.程式碼互評能讓開發更注重自己程式碼的質量
3.code review非常有必要,越早期的code review越能有效的節省後期的時間
三、 柳暗花明
1. 我怎麼填坑的
專案部署後問題頻出。花了8天時間來處理這個問題。幸虧有其它專案組的人員抽調出來救火,問題得到了解決。
目前暫時解決完畢,我簡單說一下我是怎麼填坑的:
- 和開發主流 程的同事詳細熟悉了所有需求要點
- 基於我對專案需求的熟悉,我花了三天把所有主流程的所有程式碼分析完畢,做出了我認為應該的修改,並實施部署到生產環境測試(這是在給開著的飛機換引擎)
- 每天花超過12個小時來進行code review 和修改,幾乎每天code review + 修改到凌晨2點多(僅修改了問題較大且影響較小的地方。小問題未修改、牽涉面較廣的地方未修改)
- 每次上班時間的修改讓開發同事坐在旁邊和我一起進行,我進行修改,開發同事在一旁監督。
- 優化功能點,把我發現的提示問題,和優化點都同步修改進程式碼中,確保使用者體驗不要太糟,以期能挽回一些使用者心態
2. 我所吸取的教訓總結
- 先設計,後開發
- 管理權下放,專案中必須有人全身心負責
- 無論什麼情況都要進行code review
- 壓縮質量得到的進度保證不可取
- 開發週期不合理決不答應客戶。否則坑了自己坑了同事,更坑了客戶。