楠木軒

產品經理如何管理控制專案工期

由 緱風彩 釋出於 科技

編輯導語:專案前期工期評估不合理,不僅專案中難受,專案開展後更是容易出現延期風險。作為一枚產品經理,經常需要給客戶報工期、寫計劃,並且不是每一家公司都配備專案經理一職,那麼產品經理提出的工期方案就一定要提前跟開發團隊溝通,並有所依據。接下來,本文作者為大家講解一下核算工期方法,本文方法引用政府投資專案的管理標準。

一、解決方案

產品給出的需求文件和系統設計方案的最終目的就是給出解決方案,那麼解決方案也應當算在專案工期中,其中包括但不限於:前期調研、繪製原型、撰寫文件、需求審查等。

很多產品經理覺得自己的工作並不被包含在專案工期中,而給公司報了一個比較短的工期,這就容易壓縮後面開發的時間。對於已經進行了需求調研工作的專案,這部分工期就比較好估計。

對於還沒有開始調研的專案我們可以採用以下公式估算:

解決方案工期=開發時間*複雜程度係數β

複雜程度一般根據專案的硬體、軟體、網路、體系結構的層次和介面的多少來確定,有些政府投資專案會要求以功能點的難易程度來計算。

在這裡我們簡單的以整體複雜程度計算,可分為以下等級:

  • A級專案:硬體、軟體、區域網絡、體系結構三層次以下 0.7-1.2%。
  • B級專案:硬體、軟體、區域網絡、體系結構三層次以上 1-1.8%。
  • C級專案:硬體、軟體、區域網絡、網際網路以及多種介面 1.5-2.2%。
  • D級專案:硬體、軟體、網路、通訊以及資料採集裝置介面或與主系統有介面 2-3%。
二、開發

開發部分的工期一般都需要開發團隊負責人給出,但是產品經理自己也應該做到“心中有數”,由於產品經理一般不涉及實質性的開發工作,所以很難具體瞭解每個功能模組的開發時間。

我們可以透過以下公式估算個大概:

工作量=經驗值A*風險係數σ*複用係數Γ

經驗值A:東北方言叫“約摸”,舉例:我約摸很多程式設計師報工期會虛高。

風險係數σ:程式猿對專案領域、技術不瞭解,甲方對需求不明確都會影響專案的風險,一般取值1-1.5。

複用係數Γ:開發如果基於構件庫,那麼工作量就會減少。複用係數取值越小,工作量越少,一般取值0.25-1。

再說一下系統整合,其實這個是要單獨報工期的。

系統整合將整個系統所涉及的裝置、軟體、網路整和起來,能正常地執行,執行的結果能達到使用者建立該系統的目標。

整合工期=開發時間*複雜程度α

複雜程度α可分為以下等級:

  • A級:硬體、軟體、區域網絡、體系結構三層次以下 5-8%
  • B級:硬體、軟體、區域網絡、體系結構三層次以上 7-10%
  • C級:硬體、軟體、區域網絡、網際網路以及多種介面 8-12%
  • D級:硬體、軟體、網路、通訊以及資料採集裝置介面或與主系統有介面 10-15%
三、提交專案計劃/方案

產品經理得到工作量後,開始繪製專案計劃,最終要提交的計劃中需要包含但不限於:

1. 實施進度明細

包含各子任務需要完成的內容、總工期、起止時間,其中要注意扣除節假日、留有緩衝時間。

專案經理應嚴格按照進度明細推進專案,並及時調整人員應對開發風險。

(圖片來自網路)

2. 實施人員組織結構

包含人員組織結果和職能說明,專案組人員按此說明分工、執行、對接。

3. 實施團隊組成具體各實施小組內成員,如此文件對外交付只需寫明小組負責人即可。四、開發工期核算關鍵點

軟體開發專案的主要資源是人,人具有極大的不確定性,是整個專案的風險所在。

產品經理在核算時要考慮到:

  • 人員請假、人員離職、人員借調產生的交接時間;
  • 對功能複雜程度的誤判;
  • 對所需技術不熟悉;
  • 人員工作拖延;
  • 需求變更;
  • 其他不可抗力(如三災)。

為避免以上情況對專案工期產生影響,產品經理應當預留各子任務緩衝期。

#專欄作家#

無問西東,人人都是產品經理專欄作家。工商管理碩士,貓奴一枚。主導過金融公司臺賬系統、多公司OA系統;參與過二手車平臺、P2P平臺設計。

本文原創釋出於人人都是產品經理。未經許可,禁止轉載

題圖來自 Unsplash ,基於 CC0 協議