「追進度」除了照三餐逼工程師,你還有更聰明的做法

「追進度」除了照三餐逼工程師,你還有更聰明的做法

今天要討論的主題是:追太緊很壓迫,追太鬆會掉球,PM該如何追蹤進度?

我還是菜鳥PM時,有一個兩難。我當時很菜,常常在RD表定出版本的時間之前,「不敢」一直去問RD進度,很怕這樣太壓迫,但是如果時間到了工程師才說做不出來,那我的專案又會因此完蛋,到底該怎麼辦呢?

不知道是幸運還是不幸,我當時服務的客人是個催狂魔,照三餐打電話來問進度,我被逼死之後,開啟了以下的「成長」之路:

照三餐問工程師時期

每次心理壓力都超大,覺得我也太廢,但沒辦法,客人要逼死我了,工程師心中應該默默對我草人插針,但不管了現在先活下來,之後就讓我們地獄見吧(誤)。

還好當時遇到菜鳥工程師,耐心比其他人多一點,會詳細而且老實地跟我解釋狀況--其實我現在回想起來,有沒有老實我也不知道XD 不過誰在乎呢?重點是他給了一些「我可以跟客戶交代」的內容,非常上道呀!XD

話術與丟球時期

被工程師「教育」一陣子之後,我學會了一些「話術」,這些話術讓我可以「不必頻繁問工程師,但又好像有一些進度給客人,讓他滿意」。

例如對方緊追的一個bug還找不到原因,但我可以跟他說:「我們現在架了幾台機器,正在用什麼方式嘗試複製,也需要你這邊提供複製成功的方法與機率blah blah」,不只給他進度,還丟球給他!讓他有事情去忙,他就不會太焦慮一直狂摳。

而且下次他狂摳時,我還可以追他進度,他沒進度之前,暫時不敢來找我XD

案子爆炸多只好想辦法升級時期

之後由於我把客人搞定得太好,我開始接下更多、更大的案子(PM日常......),工程師對口也從一兩個人,變成一個團隊,這代表著我之前每個專案逐一跟進進度的方式,會把我自己累死,所以我只好開始想,有沒有能讓工程師跟測試人員自己更新的方法?我自己看更新進度,跟客人報告,其實不用花太多跟工程師逐一確認的時間。

因此我做了一個專案進度更新表,希望大家每天上去更新進度,結果……

根本沒有人去更新,更新了也很敷衍,根本看不懂!!

RD已經習慣有PM去追進度了,而且他們都不喜歡寫表單,因此初步的嘗試應該是失敗了。

我求助工程師 project lead,project lead跟我說,以後只要找他就可以了,他來統合進度,不用個別找工程師,我那時覺得好開心呀!我可以翹腳跟專案了啊!!因此進入了我的第四個時期:

只要追project lead時期,但是……

想不到這是惡夢的開始,project lead並不會跟我更新細節的專案資訊,也不希望我去找個別工程師。

更慘的是,有delay問題時,他會非常負責任地先自己嘗試處理(我原本以為這是好事),但不會跟我舉手說有問題,會說一切正常開發中,等到了要進測的時間,他才告訴我delay了來不及!!

我曾偷偷用私人關係去問工程師,有些人會跟我說,有些要我直接去問project lead,我完全失去了對專案的掌控,比累死還要慘!!

那時的我非常痛苦,但就是問不出進度來,不夠成熟的我,認為這是「人」的問題,如果沒有那個不透明的project lead就好了?

但是,之後我發現,其實那個project lead也不是個「壞人」,只是「太負責任」,想要自己處理問題,而人常常有一種天真的傾向,就是「現在看起來有點delay了,不過加個幾天班應該可以補回來吧?」,不太願意對外求救,或是「也不知道PM能幫什麼忙,那我告訴他結果就好」(其實PM幫不了工程開發的忙,但是可以提早砍功能、橋時程、調資源阿~~~),等到後面延遲太多,也不知道怎麼補救了,只好兩手一攤,到了要進測當天才出不來。

因此還是要重申,怪「人」是沒用的,而且即使是人的問題,PM能怎麼樣呢?能把Project lead換掉嗎?如果是老闆,可能有機會一點,一般PM很難有這個權限,工程師跟PM如果掉到水中要救一個,常常老闆會選工程師啊!(而且是要另一個PM跳下水救工程師!),而且下一個人如果又是這樣,該怎麼辦呢?

還好公司之後導入了敏捷開發,我們開始有「每日站立會議」,還有「看板」,我的追進度時期進入下一個階段--

打開心結與制度化時期

其實做為Product owner的我,一般不用參加敏捷開發的每日站立會議,但我跟project lead說,我只列席不會干擾會議進程,我自己理解進度,對他來說也減少了還要跟我更新進度的工,如果工程師有要確認的問題,可以當場跟我確認,增加整體效率……等等。

總之就是減少他們的工與疑慮,增加我的價值,死塞活塞也要把我自己塞進那個會議當中!

成功參加的第一個感想是,每天的會議看似很花時間,但是其實省了很多時間,更重要的是心理負擔!我不用再去「追」人追進度,而是制度和系統在追人,工程師依循有效的機制,追蹤他們的進展,並尋求團隊的協助。

也是這時在每天的討論中,我才發現project lead也不是個壞人,他不希望讓我知道delay,除了覺得自己補得回來以外,也是因為他想「保護團隊」,我自己檢討:

是不是我的一些反應,讓他覺得「報告壞消息」會得到懲罰呢?

是的,當時的我把delay視為大敵,跟工程師又很熟,一遇到delay就口不擇言,開始跟工程師嘴砲來嘴砲去,或是跳起來問開發端有沒有什麼應變準備、需不需要我開始跟客戶或老闆溝通……等等。

Project lead跟我還沒這麼熟,他會有不安全感,覺得delay會被PM責備,甚至PM可能會highlight到老闆那邊去,所以不希望太早預警,想先自己救救看……他沒錯,是觀看視角以及誘因的問題,我跟團隊太熟了,忽略了人性。

我那時學到了,有時候你覺得是「個人」的問題,最後會發現是「人性」的問題,而沒注意到人性以及誘因,我會認為,這是我做為PM的責任。

這些結解開後,我重新設定自己應該怎麼跟project lead以及團隊協作,遇到問題時也不先急著跳起來,不急著跟老闆客戶highlight,而是先「聆聽」問題出在哪裡、風險多高,並對問題分優先順序。

不是關鍵路徑,生死攸關的delay,讓團隊先自己找出解決方案;針對很重要的問題,讓團隊理解目標與風險後,我會問他們「你們建議我怎麼做?」,他們自然會提出,能不能犧牲XX功能、能不能不解這個bug、能不能切版本出……等等,很多溝通其實問題在信任上,而信任建立在聆聽與理解上

在一次的retrospecitve meeting之後,我們決定要導入任務管理與追蹤系統,最後選擇了Redmine。團隊用Redmine建Task、溝通問題、同步進度,我們有了更透明的專案管理,可以看到每個ticket的結果,但我反而抓得變鬆了,我只去看快要到期,還有已經delay的項目,同時,我身上的項目進度,其他人也都看得到,知道如何follow。

我再也不用「追」進度,但是這卻是我跟團隊協作得最好的時期。

你可能說,我一開始就導入Redmine不就好了嗎?

在我的專案管理生涯當中,Trello、Redmine、Asana、Excel、Microsoft project、Jira等等都用過,不同公司,即使用同樣的專案管理軟體,結果也非常不一樣,差別在什麼地方?

在於團隊的溝通與信任。

我之前就有寫過文章一直強調,重點是大家要達到什麼目標,信任基礎如何,而不是用了什麼工具。

PM跨部門追進度原則總結:

所以我到底從這些年各種追進度的坑當中,學到什麼追進度的方法?

1. 互信、協作與溝通,比「追到最新的時程狀態」還要重要

進度是一個溝通、對齊的基礎,進度沒跟上,是一種預警,不是一種罪惡,重點是這代表什麼意義,專案規模太大?溝通有誤差?評估時少了什麼資訊?還有要怎麼處理,才能讓多方滿意,這些其實都是PM發揮價值的地方。

2. 不要「懲罰」說出壞消息、提出問題的人

「有沒有跟上進度」不是「獎懲」或是「判斷工程師能力」的方法,而是一個客觀警訊,讓團隊知道現在要聚焦處理什麼問題。

反映問題的人未必就是造成問題的人,PM可能會說,但那就是RD沒估好或是承諾沒做到呀!問題在於這種想法,對解決問題沒幫助,還可能讓問題無法浮現出來,等到要交付了才爆炸,對PM以及整個專案都不會有幫助,成熟的PM應該關注在誘因以及怎麼解決問題,找戰犯完全無助於解決問題。

3. 盡量「不要」由PM去追蹤進度!

不是不追進度,而是用系統或是制度來追,減少人治,但是也不要期待大家都會自動自發上去系統填,我就完全失敗過!

做為PM,你要先建立可以放心回報的環境,讓他們知道,提出問題的人不會被解決,大家真的會一起解決問題,才能期待系統或制度「有誘因」運行。

4. 制定透明、清楚的共同規則

接著還要讓大家知道「該怎麼」運行,包含該怎麼協作、該怎麼切task到可以追蹤的狀態(有些工程師task很大,進度always 90%快做完,但總是做不完,這又是另外的問題了),還有什麼狀況可以complete ticket,正式完工可以做下一張單。

等等,怎麼樣算完工,這很難嗎?

還真的很難。

工程師可能覺得是「做完功能」算完工,但你可能覺得是「QA測過,bug改完並驗收過」,兩者的可交付狀態可是差很多的,而且工程師的完工定義,可能製造出他不管bug數量的誘因,先進測再說,因為大家都有「打勾勾完工」的慾望!

PM的工作就是,把遊戲規則訂清楚,幫團隊剷除阻礙(包含心理阻礙),然後觀察運作流程,發掘可能的問題,進一步優化流程,讓團隊協作得更順暢

5. 如果真的有些問題非追不可,要看優先順序

從要徑或風險高的開始追,追的方法不是「追殺」,而是「追蹤與找方法」

讓團隊覺得找你是有幫助的,而不是一個聽到delay就大叫示警的尖叫雞,這才真正對你的專案有幫助。


本文轉貼自:Evonne Tsai(原標題:追太緊很壓迫,追太鬆會掉球,PM該如何追蹤進度? — PM下午茶#30)

本站所有文章未經事先書面授權,請勿任意利用、引用、轉載。
覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
Evonne Tsai

商業思維學院,產品人,現為商業思維學院《產品經理學程》主理人,十餘年產品管理經驗,多次創建產品從零到一,與跨國產品行銷策略,Medium 創亞洲最多追蹤人數。