1. 程式人生 > >我的第一次項目管理--一次慘痛的教訓

我的第一次項目管理--一次慘痛的教訓

編碼 估算 一段時間 ogl 幫助 而是 延遲 今天 向上

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

莫名的項目負責人:

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

項目工作量的預估:  

  當時在做工作量預估的時候參考了像《程序員的職業素養》、《網易一千零一夜》等書上描述的工作量預估方法,將模塊細分並采用理想人日來估算,當時算完的時候還覺得估算挺合理的。結果打臉了,我的天,大大超出了項目的預期完成時間。

我們沒有考慮到項目的緩沖時間,如需求改動以及其他優先級更高項目任務開發導致的時間延遲等。

缺乏溝通導致的項目失控:

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

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

編碼質量不過關:

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

有效會議的重要性:

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

總結:  

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

  

我的第一次項目管理--一次慘痛的教訓