我的第一次專案管理--一次慘痛的教訓

新一發表於2018-02-11

  最近總想發點時間寫些東西但抽不出時間,趁著放年假並且今天剛開完專案的年前回顧會議趕緊寫出來,其實挺不好意思講的,有點尷尬。

莫名的專案負責人:

  由於公司逐步發展,專案越來越多,沒有人有時間來負責這個專案,我的老闆們可能看我比較順眼於是便讓我來負責這次的專案開發,於是我便莫名其妙的變成了專案負責人,一開始我是拒絕的,讓一個什麼都不懂的人來管理專案真的是太可怕了。哦,忘了說明,我們的專案成員就幾個人並且每個人都身兼多個專案開發任務,因為是小公司。

專案工作量的預估:  

  當時在做工作量預估的時候參考了像《程式設計師的職業素養》、《網易一千零一夜》等書上描述的工作量預估方法,將模組細分並採用理想人日來估算,當時算完的時候還覺得估算挺合理的。結果打臉了,我的天,大大超出了專案的預期完成時間。我們沒有考慮到專案的緩衝時間,如需求改動以及其他優先順序更高專案任務開發導致的時間延遲等。

缺乏溝通導致的專案失控:

  在確認迭代的工作內容後我們開始了二十天的第一次迭代開發,在這期間我們很少溝通除了有依賴的部分確認下,在我完成工作內容時發現另一模組的開發停止了,他們被指派去做其它優先順序更高的任務,專案組的其他成員並不知情。這個時候的我並未發起會議向上層領導反饋協商開發的時間,而是選擇催促他們,直到又過了禮拜我發覺他們的開發還是停留在原地於是才讓我的領導發起協商。

  將近耽誤了一個月的時間,很明顯責任在於我,之後我開始覺得站會、週會等的重要性,並開始實施,效果比較顯著。這些會議能讓專案組所有成員清楚的瞭解專案的最新進展、各成員的開發狀態以及專案風險的評估。

編碼質量不過關:

  上一篇部落格也有提到過我們公司目前程式碼質量的問題,我認為對於程式碼的質量是研發人員必須保證的,我們需要以讓測試人員找不出Bug為目標,尤其是目前我們公司的測試僅僅是在做一些模擬使用者行為的測試,並不像《google軟體測試之道》中描述的還有軟體測試開發人員配合我們測試。 

有效會議的重要性:

  現在公司大大小小的會議可能都需要最高層領導來參加,根據我最近一段時間參與的會議以及這次專案過程中發起的一些會議,我們在會議前總是沒有把會議想要討論的內容、通過會議我們想實現什麼目標、我們需要與會人員什麼幫助等,並且會議中沒有意識到時間的把控,我們知道會議的成本是非常昂貴的尤其是在有最高層領導的會議上,會議的把控也是今後要努力的一個方向。

總結:  

  寫的有點亂,但大致上想講的也就這些,據說公司三月份測試部門回來七個應屆畢業女實習生,據測試部內部訊息好像有幾個還挺漂亮的,所以,年假這段時間再好好充實下自己,晚安。

 

 

 

 

 

  

相關文章