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

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

1. 照三餐問工程師時期

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

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

2. 話術與丟球時期

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

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

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

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

因此我做了一個專案進度更新表，希望大家每天上去更新進度，結果……根本沒有人去更新，更新了也很敷衍，根本看不懂！！

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

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

4. 只要追project lead時期，但是……

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

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

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

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

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

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

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

5. 打開心結與制度化時期

其實做為 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 等等都用過，不同公司，即使用同樣的專案管理軟體，結果也非常不一樣，差別在什麼地方？

在於團隊的溝通與信任，我之前就有寫過文章一直強調，重點是大家要達到什麼目標，信任基礎如何，而不是用了什麼工具。

總結：

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

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

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

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

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

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

3. 盡量不要由PM去追蹤進度！

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

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

4. 接著還要讓大家知道「該怎麼」運行

包含該怎麼協作、該怎麼切task到可以追蹤的狀態（有些工程師 task 很大，進度 always 90% 快做完，但總是做不完，這又是另外的問題了），還有什麼狀況可以 complete ticket，正式完工可以做下一張單。

等等，怎麼樣算完工，這很難嗎？

還真的很難。

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

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

如果真的有些問題非追不可，要看優先順序，從要徑或風險高的開始追：非到必要，不要出動尚方寶劍，追的方法不是「追殺」，而是「追蹤與找方法」，讓團隊覺得找你是有幫助的，而不是一個聽到 delay 就大叫示警的尖叫雞，才真正對你的專案有幫助。