二、故事案例
有次因為當期開發sprint大delay，中間工程師也沒有即時說。所以，趁著Retro會議，我（PM）跟工程師說：希望大家以後遇到技術問題、會delay的時候可以提早告知，不要太晚講。PM雖然很常問需要多久，但不是要工程師馬上做出來的意思，是因為可能下午或隔天就要讓老闆/客戶驗收，這之前，還要經過QA、PO驗收，沒問題才能交付。所以如果真的來不及，PM得留buffer或想好備案、跟主管討論，避免開天窗。
然後，當場有工程師馬上回說：「可是，妳之前會馬上跑過來當面問我們要多久，也沒有說過原因。」
當下我一臉尷尬，但經過那次會議，也才明白，其實大家都沒有惡意，只是有壓力或緊繃時，可能會表錯意、或用錯方法。但大家都是想把事情做好。
如果，過去溝通前，PM可以先私訊工程師，問他是不是在忙、不想被打擾，這樣真的當面溝通時，他應該會更願意表達。
又如果，PM每次都有讓對方知道：為什麼要做這件事，每個決策對彼此、對團隊來說的利益/風險是什麼，大家也會比較知道要怎麼幫忙（後來團隊有些人真的變滿積極的），而不會讓PM一個人窮焦慮。
後來，團隊也有講好，每天進度有delay、需要幫忙，站立會議都要說，做不完就儘管厚臉皮的請求支援XD
三、開發問題Q&A
寫完上頭案例後，收到另外兩個Q&A
- 部門近期人員異動，剛好沒有主管，如果規格開好了，但負責的工程師最後產出沒有按規格執行，而是用自己覺得更快的方式，該如何溝通？
- 前端工程師初期估Spec本來是1天，後來實作變成2週。工程師表示因為估的當下沒想到還有什麼要抓，也沒看過Mockup，所以就花更多時間。
PM想問：前端已經知道要做這件事，也有wireframe給他看，通常還有須要看到最後Mockup ，前端才能估時程嗎？
【不負責任回覆】
1. 先假設，沒主管的情境，是比較少發生的。沒人罩還遇到歹咖，只能說快逃（還好他逃了XD），不然就立下篡位目標，自己來當主管。又或者，這個環境是自己喜歡的，只有少數幾人不好合作，那就多跟其他能信任、有智慧的朋友/資深同事討論解法（勿找愛抱怨/八卦的）。
回到他的問題，改Spec這件事，我還是會看有沒有影響到用戶。
- 沒影響、還能更快，也不錯 （有時間的話會請教對方這麼做，未來再串後端、擴充功能有無影響之類的）
- 有影響，會趁對方心情好、或飯後、下班前等比較輕鬆能溝通的時段，去問問原因，例如：「Hi OO! 我發現OOXX這邊的設計，跟Spec不太一樣耶，可以問問你原本的設計考量是什麼嗎~」等他回答之後，PM也要說明User端要達到的目的是什麼，然後兩個人一起找到折衷解法。並再最後平和的說：「為了避免之後會這樣花你時間討論，能否你遇到要改的地方，先群組拋出來說一下，確認User痛點能被解決，工程師再執行」等等。
Ps. 如果擅自改Spec是慣性，溝通無效，那可能要分階段驗收，例如將一個功能拆成3階段，第1階段畫面完成，就先讓PM驗收。
2. 不確定其他公司經驗如何，不論一開始估的多準，只要有技術債的地方，就有「工時變數」的可能XD
然後，落差這麼大，照理工程師要在做完半天or一天後，在站立會議時，即時反應讓團隊知道 ，邀請利害關係人協助判斷價值，資源投報率太低的話就改需求，有價值就看要調其他資源幫忙，還是主管要下來幫忙做。
Ps. 趕時間的時候，會請工程師先抓1–2小時研究，跟Tech Lead討論研究結果，再決定要不要往下執行。
最後分享Evonne老師金句──
公司目標比老闆命令還要大
同理，目標應該也比我們每個員工都還重要。大家工作都有自己的價值信念，合作只是來解決問題or賺錢練功的，我們這一輩也很少人會在一間公司做到退休，沒必要互相為難。
如果用點（正直）手段、演個戲也好XD，能讓團隊達到目標，站在旁觀者的角度（畢竟我不是當事人，無法理解其他人遇到問題的全貌），會建議多試試看不同方法~ 盡力後，如果還是呈現耗損資源的趨勢，就準備幫自己換工作、拿更大包的啦！
最後，延伸閱讀推薦：空降主管平穩落地4步驟. 當職業發展走到一定階段，去到什麼公司都是要直接帶團隊打仗，「空降」這件事是怎麼樣… | by 商業思維學院院長 游舒帆Gipi
按讚+拍手
如果上述讓看官有點收穫，歡迎給作者支持與鼓勵，在「綠色圓圈」LikeCoin 按讚*5、拍手*10~50下。
腦海中有浮現想推薦的親友同事，也請幫忙轉分享給他們。
還有最重要的，有任何問題、Idea，都歡迎在底下留言交流哦！
感謝大家撥空閱讀拉~
