工作5年、4年項目管理經驗,談談我對項目管理目標的幾點理解

15 評論 88032 瀏覽 214 收藏 13 分鐘

項目管理是確保產品高質量上線的必要的手段,我們的最終目標是做出高質量的產品。

知止而后有定,定而后能靜,靜而后能安,安而后能慮,慮而后能得。這是《大學》中解決問題的思路。

意思是在我們想要做一件事情之前,先要搞清楚要達到的目標,這樣才能心里有定數(shù),心里有了定數(shù)就會比較平靜,心里平靜了才能夠比較心安,心安之后才能充分的思考,然后就會得到解決問題的方案。

從事工作5年中,有4年時間在與項目管理的工作打交道。從做程序員時在研發(fā)團隊中做項目協(xié)調、接口人開始,到后來做專職PMO項目經理,后轉崗產品經理,項目管理始終是我工作內容的一部分。我也有幸從產品研發(fā)的不同角度對IT項目管理有更為深刻的理解和認識。下面是我對于IT項目管理這一工作需要達到的目標的理解。

IT項目管理的最終目標:高質量、高產出

2017年1月份期間入職一個新的公司搭建公司的項目管理規(guī)范制度。公司屬于零售行業(yè)的電子商務公司,規(guī)模1200+、研發(fā)中心約70人。公司剛引進新的項目管理工具Teambition,一個我之前沒有用過的項目管理工具。相比之前項目管理的工作只包含事件、人員沖突協(xié)調,或者做專職項目經理的時候做協(xié)調的執(zhí)行,這次真是要站在PMO經理的角度審視整個產品、測試、研發(fā)團隊項目管理的問題。第一次面對這樣的機會感覺還是比較焦慮的。

入職的第一個周末我在家摸清了Teambition這個項目管理工具所能提供的所有功能。但是最沒考慮清楚的是這樣一個問題:

IT的項目管理要達到一個什么樣的目標?

只有徹底搞清楚這個問題,我們才能知道要做什么工作。我在本子上列出了產品研發(fā)各個環(huán)節(jié)項目管理的內容:

1. 項目管理要解決的問題:

  • 項目計劃
  • 人事沖突
  • 項目協(xié)調
  • 風險管理
  • 跨團隊協(xié)調

2. 作為產品經理負責產品線時,產品團隊的項目管理內容:

  • 單產品線需求管理(需求池)
  • 單產品線版本規(guī)劃
  • 多產品線管理

3. 研發(fā)團隊項目管理的問題:

  • 項目研發(fā)工作排期及任務分配
  • 研發(fā)風險管理,主要包括下列風險:
  • 項目計劃排期不當風險。
  • 棘手技術問題導致的延期風險
  • 跨團隊協(xié)作時協(xié)作團隊出現(xiàn)的延期風險引起的項目延期風險
  • 開發(fā)環(huán)境不穩(wěn)定導致團隊聯(lián)調延期風險
  • 需求變更導致的項目計劃變更風險
  • 線上緊急問題解決引起的當前研發(fā)產品的延期風險
  • 上線前上線工作準備不充分導致上線失敗風險
  • 上線后線上測試不通過風險
  • 跨團隊協(xié)調管理

4. 測試團隊項目管理的問題:

項目測試工作排期,包括編寫測試用例、及黑盒測試工作排期。

測試風險管理,主要包括:

  • 測試環(huán)境故障引起的測試工作阻塞風險
  • 需求變更導致的測試用例追加及測試工作變更風險
  • 研發(fā)提測產品質量低于預期,測試團隊工作延期風險

然后,我發(fā)現(xiàn)項目管理在各個環(huán)節(jié)最關鍵的工作是計劃和風險。一個計劃是為了給一個有固定需求范圍、人員的項目一個時間目標,很多的計劃是為了保證在人力資源和時間范圍有限的時候讓產出的需求范圍盡可能的大,也就是高產出。風險則是為了保證項目計劃的目標能成功達到,同時又能保證產出項目的高質量。所以,IT項目管理的目標是高質量、高產出,至于更關注高產出還是高質量,在公司發(fā)展的不同階段有著些許的優(yōu)先級調整。

IT項目管理的制度目標:透明化

在得出項目管理的目標是:高質量、高產出。

后,還是不知道怎么落地。因為客觀上來講,這個目標是包含產品、研發(fā)、測試在內的整個團隊的目標,特別是項目管理,在這里顯得很無力,因為項目管理人員既不能幫產品梳理業(yè)務些PRD、也不能擼起袖子自己敲代碼、也不能越俎代庖做測試,當然也沒這個時間。那么項目管理人員能怎么去達到這個目標呢?或者能怎么發(fā)現(xiàn)當前團隊的產出是否是高質量、高產出的呢?

似乎這個問題提到了點子上,接下來我需要搞清楚:

怎么發(fā)現(xiàn)當前團隊的產出不是 高質量、高產出的呢?

于是我在本子上列出了IT產品研發(fā)所涉及的團隊,和各個團隊中會導致不能達到高質量、高產出的一些場景。

1. 產品經理

  • 研發(fā)當前迭代上線后,無后續(xù)產品規(guī)劃。
  • 產品規(guī)劃迭代內容長期處于優(yōu)化、BUG修復等狀態(tài),對于業(yè)務的驅動沒有更為強勁的驅動和支持。
  • 線上BUG不做梳理分級分類和匯總統(tǒng)計,線上產品長期處于低質量狀態(tài)。
  • 版本規(guī)劃不合理或需求梳理不明確,研發(fā)期間大量需求變更導致項目延期、長期不能上線或低質量上線。

2. 研發(fā)人員

  • 項目排期計劃預估不當,研發(fā)人力資源發(fā)揮不充分(估長)或提測產品質量低于預期。
  • 項目研發(fā)期間遇到棘手技術問題和跨團隊協(xié)作時間問題不能及時協(xié)調,最后產品上線延期或線上低質量。
  • 上線前后準備工作不充分,產品線上故障回撤,延期。

3. 測試人員

  • 測試計劃排期不當,測試人員人力資源發(fā)揮不充分(估長)或產品匆忙上線,線上產品質量低下。
  • 測試時間不夠充分,測試用例覆蓋范圍不夠全面,線上產品質量低下。
  • 測試時間不夠充分,回歸測試的力度不夠導致的線上產品質量低下等。

在梳理場景的過程當中我發(fā)現(xiàn),提高IT產品研發(fā)產出和質量的過程其實就是為了避免這些場景的出現(xiàn),或者說在這些場景出現(xiàn)后,項目經理能及時的發(fā)現(xiàn)并協(xié)調解決,避免影響惡化。

為了避免這些風險場景的出現(xiàn),需要建立一系列明確公開透明的團隊協(xié)作流程規(guī)范,來規(guī)范產品研發(fā)的過程。對于已出現(xiàn)的風險能否及時的發(fā)現(xiàn),則取決于項目管理過程透明化的程度。透明化程度越高,產品規(guī)劃、項目計劃、人力資源安排、跨團隊協(xié)作、延期等風險就能比較快速的展現(xiàn)到整個團隊面前,項目經理就能盡早并且比較充分的時間來協(xié)調并將風險造成的影響控制到最小。

流程規(guī)范的透明化在于確保產品業(yè)務方需求接口人、產品研發(fā)、測試對流程規(guī)范有一致的理解,一套體系的流程規(guī)范的建立是為了確保各團隊在工作過程中為高質量、高產出這樣一個統(tǒng)一的目標服務。這樣的流程需要各團隊配合項目管理所做的工作要盡可能少,性價比要足夠高。

Value1 = 各團隊在項目管理中投入的時間資源價值。

Value2 = 流程規(guī)范推動產品研發(fā)產出和質量的提升的價值。

性價比= Value2 – Value1。

給予共贏的局面,參與項目的各個團隊對流程規(guī)范有一致的理解并完全接受的。

項目管理過程的透明化

可以基于下面的模板來體現(xiàn),一些常見的項目管理工具Scrum看板都可以做成包含下面屬性的卡片,也能在計劃時間的不同階段有相應的提示預警,一個版本迭代的周期控制在1-2周左右,建議最長不要超過1個月。項目周期過長則建議調整產品規(guī)劃方案。

【產品名稱V1.0.0】當前迭代核心需求范圍概述:

  1. 產品經理
  2. PRD開始時間
  3. PRD完成時間
  4. PRD評審時間
  5. UX設計人員
  6. UX設計完成時間
  7. 研發(fā)成員
  8. 研發(fā)完成時間
  9. 測試成員
  10. 測試完成時間

一個包含團隊所有項目的Scrum看板,可以充分的展示團隊處于各個階段的項目,能反映出產品規(guī)劃、研發(fā)測試進度健康狀態(tài),能反映出研發(fā)中心的現(xiàn)狀和后續(xù)計劃,能反映出人力資源的使用情況。從而能暴露出項目存在的問題和風險。

IT項目管理的過程目標:及早暴露問題和風險

一個考過PMP或者一個對項目管理工作有所了解的人都知道項目管理需要做的工作內容。但是項目延期始終是各個領域司空見慣的現(xiàn)象。更多人對延期習以為常,或者覺得不延期不正常。因為項目管理的過程最難把控。

過程的把控是為了把過程中的問題和風險造成的影響通過及早協(xié)調解決的方式降到最低,而這及早協(xié)調解決的前提則是及早的暴露問題和風險。所以,項目管理過程中的目標是及早的暴露問題和風險。

總結:

項目管理的目標在于高質量、高產出,項目管理過程的目標在于暴露問題和風險。從細節(jié)中暴露問題和風險需要流程規(guī)范和項目信息的透明化。

基于以上的思考,我制定出了適合于被我總結為矩陣團隊(多個產品線和多個研發(fā)團隊交叉迭代)的項目流程規(guī)范。配合流程規(guī)范和團隊協(xié)作情況,我制定出了三套基于Teambition這個項目管理工具的看板組織方式,和產品研發(fā)相關團隊一一溝通選擇最適合團隊現(xiàn)狀的看板組織方式(最后大家都選擇了同一種看板,這個當然是我預期之中的)。將配合項目流程規(guī)范和看板組織方式的項目管理規(guī)范制度通過培訓傳達給所有的團隊成員,1個月的時間,整個公司的項目管理就這樣落實到位了。

項目管理是確保產品高質量上線的必要的手段,我們的最終目標是做出高質量的產品。

 

本文由 @龔靈芳 原創(chuàng)發(fā)布于人人都是產品經理。未經許可,禁止轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 贊同您90以上的觀點,但是作為一個開發(fā)人員,我建議您多和研發(fā)團隊聊聊,高質量高產出,既需要能力,也需要薪水,還需要好的產品經理。任你規(guī)劃再好,任務緊湊到認開發(fā)人員一刻不停歇,短時間尚可,時間久了,隊伍就崩了

    回復
    1. 是的,您說的對,這是一個整體,一個環(huán)環(huán)相扣,相互影響的過程。

      來自上海 回復
  2. 很贊,學習了

    回復
  3. 那么對于IT項目,除了時間+質量,還有什么緯度可以作為衡量呢

    來自四川 回復
  4. 同意樓主文中的多數(shù)見解,但對于‘項目管理的目標是高質量、高產出’的觀點有些不敢茍同。一般地說,所謂項目就是指在一定約束條件下,達成具有特定目標的一次性任務。這里的約束條件主要包括且不限于時間、資源和質量。依據(jù)個人8年多的項目和項目集管理工作經驗,參照樓主總結方式,簡單總結項目管理的目標是:按計劃、可驗收。即能夠按計劃完成的,且能夠順利被驗收的項目,就是成功的項目,過度的追求進度和質量,只能造成項目成本的增加,在項目中管理粒度的粗細需要根據(jù)項目進展情況隨時調整,有時也不能太理想化,畢竟項目追求的目標還是最終的利潤。個人拙見,僅供參考。

    來自北京 回復
    1. 我覺得“按計劃,可驗收”很贊,只是更加偏向于是風險管理,過程管理。而IT這個高端人才領域中,項目管理更難的是人員的管理,這個領域1個人創(chuàng)造10個人的價值這種情況屢見不鮮,對寶一樣的人才一定要特別對待。比如,在按計劃進行的過程中,發(fā)現(xiàn)有個厲害的人工作很早的完成了,那么適當?shù)恼{整當前的工作安排以及在后續(xù)的項目計劃中適當?shù)脑黾舆@個人的工作難度或量就是有必要的,這樣優(yōu)秀的人最終的績效也會更好,對于個人和團隊都是雙贏的結果。我理解的“高質量,高產出”就是指,在人力和時間有限的情況下,盡可能合理的安排項目和計劃,在產出質量有保證的前提下,讓產出的量盡可能多。當然在激烈的競爭面前,相當于時間資源被壓縮,這時候通過補充人力資源來完成結果目標是有必要的。對于范圍一定,時間壓縮的情況,擴展人力資源的時候,需要考慮任務能拆分并行研發(fā)的最小粒度,簡單的總結就是“1個女人9個月生1個孩子;9個女人無法在1各月內生1個孩子,但可以生9個”。

      來自上海 回復
    2. “1個女人9個月生1個孩子;9個女人無法在1各月內生1個孩子,但可以生9個”改為“1個女人9個月生1個孩子;9個女人無法在1各月內生1個孩子,但可以在9個月內生9個”。抱歉裝B過頭了 ? 。這里的回復居然不能編輯也不能刪除,這是“產品經理”社區(qū)?簡直打臉

      來自上海 回復
  5. 感同身受。不過對一點提出疑慮,以高質量高產出的目標沒毛?。ó斎皇抢硐霠顩r),作為PM更應該介入PRD梳理和確定,尤其是業(yè)務類需求具有不可推卸的責任。畢竟產品/項目首先是以產品/項目為基準,再是以人為本。

    回復
    1. 贊同,方向錯了,走的越賣力只會偏的越遠。

      來自上海 回復
  6. 樓主說的看板可以分享一下嗎?

    來自廣東 回復
    1. 看板確實是落地執(zhí)行最后的成果,但是這個一方面依賴于所使用的項目管理工具會有所不同,另一方面針對產品、研發(fā)、測試團隊的協(xié)作方式也會有所不同。我可以考慮后面在寫一篇瀑布、敏捷、矩陣型協(xié)作團隊中,產品、研發(fā)、測試人員Scrum看板組織方式相關的文章。感謝關注~

      來自上海 回復
  7. 很專業(yè)。我們公司目前是產品經理兼顧項目經理的職責,當然因為我們目前團隊和項目都比較小,公司沒有資源也暫時沒有必要需要單獨的一個項目經理的崗位。但在兼任項目管理的過程中,還是或多或少遇到了很多問題。能夠系統(tǒng)性地看到文章里面列出來的各個點,非常有用。

    來自廣東 回復
    1. ??

      來自上海 回復
  8. 我想求作者聯(lián)系方式,請教一些專業(yè)問題。有些冒昧,但很認真的提出了這個請求,郵箱都ok~拜托

    來自四川 回復
    1. 歡迎勾搭,微信:angelg0426。哈哈。

      回復