[嘀咕]誰該為進度延遲負責？
我還記得一年前我們曾為了這件事情跟另一個部門開了會，重點摘錄如下：
你們窗口不夠smart，不能很快速且清楚的了解我們要表達的意思，問了一兩次之後就不想再問她了，所以我們自己埋頭研究；接著是文件不夠，缺乏文件，影響我們的產值達1/2。
那場會議後我們部門對他們的支援或者態度並沒有改變，因為連該部門主管最後都認同我說的內容：
第一點，開放該窗口的目的是在接收問題與初步排除問題，並非在徹底解決每個問題，溝通是兩個人的問題，你說的他聽不懂是他的問題還是你的問題，這很難界定。
第二點，沒有那些文件不是一天兩天的事情，三年來都是這個樣子，如果每個人都說1/2的時間花在自己摸索，那我想問，我還不被老闆抓去殺頭嗎？目前我們提供的基本類別就那幾個，而日常使用的source code也都開放可以trace，三年下來也過得好好的，如果沒有文件就無法順利工作，這樣說起來，我們公司的軟體工廠早就關門大吉了，如果覺得哪邊不夠請列出來，一句文件不夠是沒有說服力的。
如果今天我把工作無法進行歸咎於微軟提供的文件跟支援不夠、沒有開放好的窗口讓我們問問題，老闆會同意嗎？老闆應該會說：那你想怎麼解決？當然是一方面push微軟，另一方面也要從既有的程式中收集範例，或者找其他部門的人詢問是否有相關的資訊，或者上網查詢英文、簡體的網站，事情並不會因為別人無法完全配合而無法進行的。
說起來，我們在職場上很常遇到這樣的現象，遇到問題時，還沒先想清楚自己該做哪些事情，就先想到要去檢討別人，當我們所處的部門發生問題，我們本該就這些問題先行釐清，想想我們自己有什麼可以做的，並找出需要其他部門配合的內容，仔細的說明清楚，這樣別人也容易知道哪些地方改善後對我們有幫助，否則這樣的討論不只留於空談，更是一場口水戰。
誰該為進度延遲負責？
舉個例子吧，一個專案從PM-->SA-->SD-->PG，PM排定計畫、協調資源、確認進度後交由SA開始開立SA規格，SA規格完成後換SD最後輪到PG開始撰寫程式，若一個功能需要10個工作天完成，
- SA：2天
- SD：4天
- PG：4天
SA延遲了1天，SD也延遲了1天，因此PG接手時時間只剩下2天了，PG很盡責的花了4天完成，但最後還是延遲了2天，這樣的狀況誰該對進度延遲負責呢？如果SA、SD不要延遲，那進度會延遲嗎？相同的，若SA、SD準時交件，最後PG的產出卻延遲了，那誰該對延遲負責呢？你覺得是SA、SD還是PG，甚至根本就是PM了？
整件事情PM絕對有責任，但若每個角色自己可以更對自己的工作進度負責，這個問題發生的機會應該會大大的下降：
SA催促PM快點跟客戶確認完專案範圍與交期，SA準時接到需求，就可以準時完成規劃；
SD催促SA快點產出SA規格，SD準時接到需求，就可以準時完成設計；
PG催促SD快點產出SD規格，PG準時接到需求，就可以準時完成程式撰寫；
癥結點其實都在自己身上，你不願意催促，最後壓力可能就壓在你身上；你不願意確認，你可能無法有效的安排好你手上的工作，會有一段時間在閒置等待，控制讓例外不要發生，就可以免掉很多延遲的風險，畢竟太多的加班都是這樣來的，所以當初我帶PG Team時，我每兩三天會跟SA/SD確認一次進度，看看規格會不會延遲，並跟SA/SD Team leader說了，只要規格準時出來，我們的程式絕對準時交件，規格延遲你就必須要接受我們程式延遲，若不能接受，那就請把關好SA/SD規格的產出時程吧。
若自己都沒辦法掌握好自己工作上遭遇的狀況，無法檢討自己，那怎麼請別人改善呢？
 |
游舒帆 (gipi) 探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。 |
