網際網路專案中“延遲”分析

發表於2011-07-11

在企業專案當中,專案週期主要分為兩種,即:deadline開發以及估時開發。而在專案管理當中,最重要的四點包括:時間,質量,成本以及工程師成長。所以在不同型別的專案當中,對於專案管理都具有不同的要求。

而在國內IT行業當中,專案延期推遲交付卻是時常發生。在網際網路行業當中,小步快跑,提前推出高質量產品以及持續更新產品卻是保證商業成功的最重要因素之一。本文將從目前國內專案中經常出現的情況進行分析。

deadline專案:

很多國內的開發都會認為根據deadline去反推安排整個專案進度,是一件很不靠譜的事情。原因很多,主要的是由產品部門自己YY的交付時間完全無法保證質量的完成要求。

但是,實際上,在公司內,能夠讓Boss拍板同意給定時間提交產品的專案,卻是做起來很舒服的專案。首先,這類專案優先順序較高,所以肯定可以保證專案資源。是拿著上方寶劍的專案,劍之所指,必定能夠滿足。

同時,當你作為專案經理,遇到這樣的專案,砍需求保證可以砍到自己都手軟。因為deadline的原因,專案經理本著對於專案質量的控制,必然是需要對需求進行控制,保證所做的需求都是最重要,最迫切的需求。

所以換個角度看待問題,可以更加的輕鬆。

估時專案:

估時專案存在的最常見情況,是對於已有產品的改進型需求。在這類需求當中,通常需要產品參與各方對需求進行評估,參與方一般會包括:產品經理、前端(FE)、互動、專案經理、開發工程師。

但是在這類需求當中,確實會因為某些原因,導致專案無法按照約定交付產品。首先我們來討論一下工程師在評估專案時的參考依據:

1. 專案的邏輯複雜度以及熟悉程度

2. 功能數量及技術難度

3. 專案技術目標的設定

4. 產品需要推出的目標時間

5. 個人狀態

基於上面五點,開發工程師依照自己的經驗(所以新人估值時總是無法非常準確),但是在真實的開發環境當中,會因為各種原因,導致開發進度的delay。具體原因可能有:

1. 專案難度估計不足,導致開發進度緩慢

2. 未考慮日常工作,例如:例會,部門週會

3. 溝通成本,由於開發流程當中,設計不同開發,不同部門,甚至會是不同企業之間協作溝通成本,在專案開發的過程中,由於溝通協作的原因,造成專案的delay。

4. 相關人員的delay,由於專案評估時,不同部門,如前端和後臺基本屬於分開各自評估開發時間,導致關聯人員由於評估不足,導致的delay,從而連鎖反應。

5. 業務邏輯理解不足,比如開發團隊當中有新人存在的時候,這樣的情況就更加容易產生。由於合作的默契性,需求方會根據情況,適當的縮減自己對於需求的描述,但是這樣的情況,卻會使新人無法明確需求,導致開發時間增加。

6. 直接需求變更,由於產品經理對於需求的不確定性,導致在專案後期影響整個專案進度。

7. 間接需求變更-互動方式變更。在很多專案當中,前後臺資料互動是很重要的部分,但是會產生在確定互動並給與開發工程師評估開發工時之後,對於互動方式進行變更。導致前後端互動方式改變,造成間接需求變更。

同時,最關心專案進度的,除了本身開發團隊之外,應該最關鍵的是產品經理,而產品經理對於專案的渴望,或者說是G點其實非常的簡單:

1. 開發週期越短越好,質量越高越好。對於產品經理來說,最好的情況是“剛想好產品價值,定義完產品特性”,開發就能完成。

2. 給與開發評估的機會,在評估之後,能夠至少按照約定交付符合質量的專案,儘量不要出現由於非需求原因造成的延期。

那專案經理,在專案發生delay之前,可以做的預防工作有哪些呢?根據我的經驗,通常有經驗的專案經理在專案的初期,就會有相應的措施。具體的措施如下:

1. 預留buffer。很多經驗的豐富的專案經理在開發做專案評估的時候,都會讓其預留很多開發的buffer時間,為的就是解決由於間接需求變更以及日常工作造成的delay。

2. 統一估時。現有很多公司,都是將互動,前端,開發都是分開評估。但是,由於後期開發的協作,所以很多有經驗的的專案經理,會將專案所有參與人員統一,進行專案的評估。同時增加成員之間的溝通。

3. Checklist。按照需求點列舉checklist,同時將每個checklist按照需求概述,參與人,預計完成時間,以及完成狀態進行控制。可以及時發現專案的進度。

4. 需求變更流程控制。很大一部分原因是由於需求變更造成,所以,在成熟的公司,對於需求變更的控制,都有自己嚴格的流程。從而保證專案的按約交付。

而在專案的delay已經成為事實之後,很多工程師會有一個疑問,我們應該怎麼處理這樣的問題呢,如果將問題丟擲,會不會影響自己在主管心中的能力,或許我加一下班就可以把delay的問題解決,都是因為產品經理不斷改需求,所以才會導致我的delay。

其實在公司當中,發生了delay,對於主管,對於產品經理,希望的都是能夠儘早獲得這樣的事實,所以一般會鼓勵開發發生這樣的情況進行及時的彙報。解決方案也很簡單:

需求與時間關係

1. 交付時間延期。對時間要求並沒有很強的專案,由於開發評估的不準確,造成的延期,延期交付將是一個好的解決方案。其實,如果開發能夠準確的預估開發時間,最終的結果也是在延期之後的時間點進行交付,畢竟開發能力也就是那個時間點。

2. 刪減需求。對時間要求非常強的專案,當開發無法在規定的時間完成需求,能夠做的唯一的事情,就是刪減需求,在開發團隊能力能夠滿足的情況下,儘量完成需求。

在專案管理過程中會有各種不同情況發生,專案經理也是一個需要經驗積累的崗位。希望可以不斷總結,提升自己的能力。

原文: 顧彥先

 

相關文章