你懂，但是你不做，有什麼用！？

Project Ｇ是我接手的project。接手的意思是，前面的PL被換掉了。（關於project Ｇ在上一篇文章有提到一些）

在我之前的PL Ｍ其實也不是第一個PL，只不過他是最久的一個。在我被assign接手project前二個星期就已經被老闆叫進來參與project運作，當我參加meeting時就看到一些問題，而且是PL本身的問題。會議中發現，Ｍ其實都知道問題在哪裡，甚至知道如何解決，但是最終問題並沒有被解決，因為solution只是被＜說＞出來，並沒有被＜做＞出來。

第一次參與meeting，就看到一個被highlight的問題＜ＸＸＸ功能（project最重要的功能）因為缺少ＯＯＯ部門的人，所以卡住了＞，再聽說這個問題其實已經被highlight好幾個星期了，然後就聽Ｍ說已經跟ＯＯＯＯ部門老闆反應了，但就是要不到人，現在其他部份都做的差不多了，少了ＯＯＯ那部份就無法整合。一個星期後再次meeting，那個問題還存在，而Ｍ還是說同樣的話，這次我就問ＯＯＯ的老闆怎麼說？有說為什麼人力無法進來嗎？什麼時候才可以進來？結果Ｍ的回答很支吾，因為他並沒有真的去follow up這個問題。然後我就把這個問題接下來處理，當天下午找了ＯＯＯ部門主管和ＸＸＸ功能相關的人開會討論，結果當下就把ＯＯＯ的人員定好，什麼時候進來，各自開發還需要多久，大概拉了下schedule確定整合的時間。放了幾個星期的問題，一個meeting就解決了。

另一個案例是project發現ＺＺＺ問題，Team A說是Team B造成的，Team B說不是他們造成的。

會議中Ｍ下了一個comment：＜那不就是找二個Team的owner一起找問題就好了。＞

過了30秒Ｍ沒有下文，另一個人問Ｍ：＜那是不是要找二邊來開會，誰主持會議？＞

Ｍ回說：＜你幫我hold這個meeting，看看結果怎麼樣。＞

你看出問題在哪了嗎？是的，沒有Action。要人家提醒才下Action，而且owner還直接落在提醒的人身上。跨team的協調工作，最好還是PL出面比較有說服力。

再一個案例是project Ｇ的schedule，Ｍ拉了一個半月的schedule，

會議中我就說：＜依我過去的經驗，現在才剛剛開始第一次System Test，光測試就要三個星期，還要debug，一個半月的schedule是很有問題的，更何況project Ｇ是新的IC、新的架構、新的protocol，bug會滿天飛，不可能只跑一次System Test就可以把問題全部抓出來，以二次System Test的時間加起來就要一個半月了，還沒算debug的時間咧。＞

Ｍ說：＜我知道，可是老闆就是要一個半月的schedule！＞

我說：＜你是PL，你要跟老闆反應真實的狀況，拉一個比較可執行的schedule。＞

嗯～結果是我在對牛彈琴。

簡單舉三個案例，其實問題都不是問題本身，而是在PL身上。PL能做不做，應該做不做，只是知道卻不執行，明知錯誤卻不修正，不但不能解決問題，反而製造更大的問題。對這樣的PL，project會delay、PL會被換掉，我一點都不意外。


＝＝＝＝
文章發表在2012夏日的BLOG傳說－
＜工作二三事＞你懂，但是你不做，有什麼用！？