團隊管理:如何讓團隊高效推進項目

3 評論 20772 瀏覽 99 收藏 8 分鐘

項目進度問題一般在一個小團隊中不會表現的特別突出,因為這時候團隊所有成員的目標都比較一致,并且由于人數較少,溝通成本也較低,對于磨合的較好的團隊,這時候可以遵循小步快跑的方式,不斷打磨產品。對于剛入門的產品經理來說,這段時間應該是產品生涯里最快樂的時光了。

圖片1

但當團隊規模擴大到二,三百人時,由于系統更加龐大和復雜,任務會被拆分給到更多的人去做,原來的簡單溝通模式被無情的拆分,于是人和人的關系變復雜了。這時候,看起來簡單的一個小功能很可能會牽一發而動全身,涉及很多的人。于是項目推進就不是靠晚上一起吃個飯能簡單的解決了:人太多,你請不起啊。

圖片2

既然本文是在教產品經理怎么推進項目,那么我們先聊聊項目是怎么運作的。不管是有錢的出錢還是有力的出力,在軟件開發這種需要抽象邏輯的腦力勞動面前基本是無效,因為他需要的是專業技術人員不斷的共同協作才能完成。而協作的過程其實就和打籃球一樣,對于每個人參與者來說就是一個傳接球的過程。

圖片3

你接到了一個球(任務),運球(做任務),傳球(把任務拋給下一個人)。所以每個項目參與者就做3件事兒,接到任務,完成任務,傳給下一個。在完成任務的過程中,如果碰到問題無法繼續,就像運球時半路有人攔截,這時候也必須要把球傳給能解決這個問題的人。對于項目參與者來說,核心使命就是按時按點的把球傳出去,只有傳出去了,你的使命才算完成。

需要重點說明的是什么叫傳球,所謂傳球我們可以理解成交付,也就是上家對下家的一個產出結果的交付。

例如,產品經理對開發以及設計團隊的交付是一個說明詳盡的產品需求文檔,UX/UI對開發的交付就是設計完整的交互稿,視覺稿以及切圖。而后端開發人員對前端開發人員的交付就是安全可用的接口以及詳細的接口文檔,而前后端開發人員對測試人員的交付就是提交到測試環境的代碼,測試人員對部署人員的交付就是沒有問題的測試結果,而是有問題的測試結果則要交付給前后端開發人員。

當然并不是所有的傳球都是一個明顯的產出結果交付,也會是一些信息告知,例如,開發人員在開發時碰到了第三方安全證書問題需要產品經理去解決,這時候的傳球可能就是一個郵件告知一下產品經理項目遇到障礙,需要產品經理去解決,于是球又傳到產品經理手上了。

需要說三遍:傳球才是項目往前進的最重要環節。

圖片4

到這里我們知道了項目的本質就是多人進行的一個傳接球過程,每個參與者就是做好3件事兒:

  1. 接球–任務
  2. 運球–完成任務
  3. 傳球–交接給下一個

但有時候由于任務的不明確,或者分工的不明確,或其他各類原因會導致球在傳遞的過程中球一直停在了某個人手中,而無法傳到下個環節。怎么辦呢?

圖片6

這個時候,對于產品經理來說其實也只要做3件事兒,

  • 接過球
  • 清理障礙點
  • 把球重新傳出去

重新傳出去時,也許就不再按原來的傳遞路徑了。有些產品經理在項目進入停滯狀態時,會變得很焦慮,會去不斷推項目執行者,然而并沒有任何效果,因為障礙是事實存在的,不解決是不會真正讓項目繼續前進,強推的結果只是會讓結果失控。

障礙的清除其實也是遵循傳接球原則,找到問題點以及可以解決該問題的人,然后把球傳過去就可以。但有時候,傳球對象不一定好找或明確,就需要你不斷的傳球試探,直到找到一個可以接球的人。能夠順利清理障礙當然是一件好事情,但是作為產品經理者應該在項目開始前就盡可能的暴露這些障礙點,并盡量做到提前清除障礙,越在后期發現越可能影響項目的進度。

但如果障礙就是清除不了呢?最簡單直接的方法就是盡快把球傳給你的上級。其實如果你不是最終老板,你總有傳球對象的。

對于項目參與者關注三件事兒:

  1. 接球–任務
  2. 運球–完成任務
  3. 傳球–交接給下一個

對于產品經理來說,推進項目時只需要關注一件事兒,球(任務)停在哪兒了。

如果發現有障礙,迅速做3件事兒:

  • 接球(接任務)
  • 尋找新的接球人
  • 把球重新傳出去

 

本文作者:杜松,現任點融網高級產品經理,熱衷宏觀經濟,長期投資美股。研究生畢業7年半,4年在公司,3年半自己創業。生命不息,折騰不止。

本文由@點融黑幫(微信號:DianrongMafia) 原創發布于人人都是產品經理 ,未經許可,禁止轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 比喻很好。

    來自浙江 回復
  2. ??

    來自貴州 回復
  3. 在小團隊中不也是這種方式嗎?!無非是效率更高一點。

    來自北京 回復