SmartM 人才培訓網

由外往內，是公司內部與外部合作夥伴的邊界；是不同團隊之間的邊界；也可能是不同人合作，負責各自事務時，分工的邊界，由於是邊界，所以容易被忽略，容易以為對方會做或權責不清，就會掉球。

尤其邊界越往外，風險越大，所以對跨公司的邊界，要用合約規範，部門間，要用會議紀錄，個人間，常常有什麼協議結論，我也都會記錄在雙方看得到的地方。

所以我對邊界都會特別緊張。而將這一切串連起來的，是溝通。

其實，一開始在與工程師溝通時，我感覺自己在他們眼中像是個傻蛋，他們其實懶得對我解釋太多，心中大概只想著：「John Snow，你什麼都不懂」，老一點的大概在想「供到你識，嘴鬚都打結」（好啦沒這麼老！），問schedule時總是一拖再拖，產品delay常常得到的回應是，PM給的東西不夠充足、需求不夠清楚。

在這樣的情況下，說實在的我每天都過得很痛苦（要不然也不會有那篇文章），但還是盡我的全力做我該做的事。這段時間整整過了兩年，產品終於量產了。

在量產的那個當下，我驀然回首，發現我已經跟團隊合作得非常順暢。這真是太神奇了！

後來我才漸漸想通，關鍵其實並不在於溝通本身，其本質在於「建立信任」，才能進一步「管理期望」，進而「達到雙方都能接受的目的」

再讓對方相信「你」之前，要先讓你自己「值得相信」。

怎麼讓自己值得相信？

如果你有頭銜、有戰功，很容易證明自己值得相信，但大部分的狀況下PM都沒有，卻要說服一群不歸自己管的人（笑著流淚）。

其實只有三個關鍵字：尊重、透明、專業。

雖然抽象，但做久了，對方會看得到。信任是從小事中累積出來的。

所以我理解了，之前工程師不願意對等與我溝通的原因，是因為專案真的太過複雜，而我還沒建立起他們的信任，他們認為跟我解釋我可能也不懂，懂了也不能改變什麼，再加上其實工程師都是有點害怕複雜溝通，或是尷尬場面的人，所以才會撐到最後一刻才通知延遲。

但我之後讓他們理解到，讓我知道這些資訊，我能思考前端是否有短期解法，或是與老闆調配優先次序，甚至是調動其他團隊的支援，我用行動讓他們相信，我有誠意，也有能力替他們解決問題，他們才逐漸與我分享資訊，甚至之後會來諮詢我的想法。

然後是Level Up的時刻了：好的PM善於溝通，厲害的PM創造易於溝通的環境。

記得在聽到PMP的 「溝通管理」時，我覺得把溝通和管理放在一起，非常弔詭。因為我認為溝通是無時無刻、在不同情境下發生的，也是雙向、要根據對方反應與回饋隨時調整的一個動態過程，要如何「管理」呢？而在對方未必願意溝通的情況下，又要如何去「控制」呢？

直到我遇到了一個厲害的PM。

他其實是RD lead，但是他主導引進了一些關於敏捷式開發的制度改動，例如看板制度、每日15分鐘站立會議、Scrum的衝刺與demo，讓各團隊有一個「即時的平台」可以交換資訊，提供反饋，也讓資訊能更有效地整合在一個綜觀的介面上。這麼多團隊之間的邊界整合，突然彌平了，許多問題，在每天的短暫會議中，都快速得到了釐清與同步。

我那時才「體會」到，什麼是一個PM應該做的溝通管理。

PMP聖經PMBOK® Guide對於專案溝通管理的界定是，「確保能適時、適當地產生、蒐集、發布、儲存、擷取及最終處置專案資訊」所需的一系列流程，包括辨識利害關係者、規畫溝通、發布資訊、管理利害關係者的期望，以及報告績效等。

也就是說，要「確保」這一切發生，這應該要是關於制度與流程層面的改動。

我理解了，好的PM善於溝通，而更厲害的PM，會製造易於溝通的制度或是環境，讓大家都能在這環境裡面，用有效的方式溝通。

剛剛講的看板，就是將資訊透明化的制度，而每日站立會議，是創造大家能溝通、同步的空間與時間。否則一個PM花再多的時間去同步各方的需求和動態，最後自己將會成為那個瓶頸，所有事情都要經過你，最後那就會纏繞成一個讓你永世不得超生的結（或是永世不得超生的PM）（死）。

這是我對於溝通管理的一些心得，而我現在在處理的，是更加複雜的「跨國專案」，當一個專案有多個開發團隊，位於不同國家，需求方與測試團隊，也都分屬不同國家，這樣的專案要如何進行溝通管理，以及多方同步流程的建立？

我還在嘗試，說實在的痛苦指數超高，各種即時通訊工具每天啪啪啪跳出訊息閃著提醒（這一個專案中我們跟各方利害關係人，用到了至少四種即時通訊工具），各方壓力整天像海浪一樣席捲而來，一波未平一波又起，一波還來不及一波又來侵襲，每天都覺得厭世。也只能不停自我鼓勵，能做到這種超大型跨國專案也是難得的機會了，這麼說來最重要的溝通工具，其實只是一顆樂觀淡定，能自補熱血的心吧～（茶）（什麼結論）