大家覺得，在專案進行的過程中，最困難、可能造成最大風險的部分是什麼呢？是技術難度？市場需求改變？還是利害關係人的支持？我認為最大的風險來源，總是躲在邊界。
由外往內，是公司內部與外部合作夥伴的邊界；是不同團隊之間的邊界；也可能是不同人合作，負責各自事務時，分工的邊界。由於是邊界，所以容易被忽略，容易以為對方會做或權責不清，就會掉球。
尤其邊界越往外，風險越大，所以對跨公司的邊界，要用合約規範，部門間，要用會議紀錄，個人間，常常有什麼協議結論，我也都會記錄在雙方看得到的地方。
所以我對邊界都會特別緊張。而將這一切串連起來的，是溝通。
一個充滿邊界的專案
之前的文章曾提到，我曾參加一個超大專案。在之前這篇文章提到過（《當我沮喪我會想起誰》）
當時我提到：
這個產品線規模有多大呢？光是做伺服器的團隊就有三個不同開發團隊，做client的團隊也有兩個開發團隊，測試團隊也有兩個，且成員都是公司工程師的一時之選，這幾個團隊要彼此配合又各司其職，緊密整合到一套產品中，而產品是從0到1一個全新的產品線，有非常多的未知數在其中（現在想起來還是讚嘆，我到底怎麼做起來的XDDD）。
除了產品規模大之外，最重要的是這個專案的工程師都是強大的老鳥，而我還尚未贏得他們的信任，無法讓他們願意和我對等地溝通，所以總是最後一刻才被告知某個功能做不到，或是版本又要delay，後續時程不一定，簡直是完全沒有掌握度，卻又要負責對業務或客人道歉，告知後續的版本規劃，總之真是一言難盡的苦楚。
有許多人問我到底怎麼克服這種情況的？
其實，一開始在與工程師溝通時，我感覺自己在他們眼中像是個傻蛋，他們其實懶得對我解釋太多，心中大概只想著：「John Snow，你什麼都不懂」，老一點的大概在想「供到你識，嘴鬚都打結」（好啦沒這麼老！），問schedule時總是一拖再拖，產品delay常常得到的回應是，PM給的東西不夠充足、需求不夠清楚。
在這樣的情況下，說實在的我每天都過得很痛苦（要不然也不會有那篇文章），但還是盡我的全力做我該做的事。這段時間整整過了兩年，產品終於量產了。在量產的那個當下，我驀然回首，發現我已經跟團隊合作得非常順暢。這真是太神奇了！
後來我才漸漸想通，關鍵其實並不在於溝通本身，其本質在於「建立信任」，才能進一步「管理期望」，進而「達到雙方都能接受的目的」。
如何建立信任？
在讓對方相信「你的話」之前，要先讓對方相信「你」。
再讓對方相信「你」之前，要先讓你自己「值得相信」。
怎麼讓自己值得相信？
如果你有頭銜、有戰功，很容易證明自己值得相信，但大部分的狀況下PM都沒有，卻要說服一群不歸自己管的人（笑著流淚）。其實只有三個關鍵字：尊重、透明、專業。
雖然抽象，但做久了，對方會看得到。信任是從小事中累積出來的。
什麼樣的小事？
- 提供文件之前，自己有沒有先檢查過？有沒有確認文件都給齊了？還是只是丟出去？（好啦我承認我超忙時也會這樣，但是，屢試不爽，只要是沒檢查丟出去的，一定會有問題！）
- 提需求之前，有確認過使用者的需求，並思考過優先順序嗎？還是只是丟出去？
- 前端所有需求你照單全收，還是視情況提出，並能承受前端工程師的壓力？
- 得到一個新的市場資訊與走向，你是否願意和你的開發團隊分享，讓大家理解他們做的事情的價值所在？你是否有這個勇氣和你的團隊辯論自己的判斷與決定，接受他們的challenge？
- 老闆壓了一個不可能的時程，有沒有先嘗試與老闆溝通？還是同樣的時程直接拿去壓工程師？
- 出了問題，第一個反應是解決問題，思考之後如何避免，還是歸責於RD寫不好，QA沒測到？
- 產品量產了，你是將這個成功與榮譽歸結給你的團隊，也把用戶的回饋忠實回饋給團隊，還是量產完就對他們不聞不問？
- 你讓你的合作夥伴覺得，你認為他們很重要，還是你自己比較重要？
這一切，其實就是尊重、透明，專業。這代表了你是不是將自己視為團隊的一分子、有沒有站在對方的立場思考、有沒有專業做出正確的判斷與決定，而你的團隊會感受得到，進而用不同的方式對待你。
所以我理解了，之前工程師不願意對等與我溝通的原因，是因為專案真的太過複雜，而我還沒建立起他們的信任，他們認為跟我解釋我可能也不懂，懂了也不能改變什麼，再加上其實工程師都是有點害怕複雜溝通，或是尷尬場面的人，所以才會撐到最後一刻才通知延遲。
但我之後讓他們理解到，讓我知道這些資訊，我能思考前端是否有短期解法，或是與老闆調配優先次序，甚至是調動其他團隊的支援，我用行動讓他們相信，我有誠意，也有能力替他們解決問題，他們才逐漸與我分享資訊，甚至之後會來諮詢我的想法。
然後是Level Up的時刻了：好的PM善於溝通，厲害的PM創造易於溝通的環境。
好的PM善於溝通，厲害的PM創造易於溝通的環境
我有PMP證照，其實求職時沒怎麼用到XD，但他的知識框架我認為是很有價值的。
是無時無刻、在不同情境下發生的，也是雙向、要根據對方反應與回饋隨時調整的一個動態過程，要
記得在聽到PMP的 「溝通管理」時，我覺得把溝通和管理放在一起，非常弔詭。因為我認為溝通如何「管理」呢？而在對方未必願意溝通的情況下，又要如何去「控制」呢？
直到我遇到了一個厲害的PM。
他其實是RD lead，但是他主導引進了一些關於敏捷式開發的制度改動，例如看板制度、每日15分鐘站立會議、Scrum的衝刺與demo，讓各團隊有一個「即時的平台」可以交換資訊，提供反饋，也讓資訊能更有效地整合在一個綜觀的介面上。這麼多團隊之間的邊界整合，突然彌平了，許多問題，在每天的短暫會議中，都快速得到了釐清與同步。
我那時才「體會」到，什麼是一個PM應該做的溝通管理。
PMP聖經PMBOK® Guide對於專案溝通管理的界定是，「確保能適時、適當地產生、蒐集、發布、儲存、擷取及最終處置專案資訊」所需的一系列流程，包括辨識利害關係者、規畫溝通、發布資訊、管理利害關係者的期望，以及報告績效等。
也就是說，要「確保」這一切發生，這應該要是關於制度與流程層面的改動。
我理解了，好的PM善於溝通，而更厲害的PM，會製造易於溝通的制度或是環境，讓大家都能在這環境裡面，用有效的方式溝通。
剛剛講的看板，就是將資訊透明化的制度，而每日站立會議，是創造大家能溝通、同步的空間與時間。否則一個PM花再多的時間去同步各方的需求和動態，最後自己將會成為那個瓶頸，所有事情都要經過你，最後那就會纏繞成一個讓你永世不得超生的結（或是永世不得超生的PM）（死）
而我現在在處理的，是更加複雜的「跨國專案」，當一個專案有多個開發團隊，位於不同國家，需求方與測試團隊，也都分屬不同國家，這樣的專案要如何進行溝通管理，以及多方同步流程的建立？
我還在嘗試，說實在的痛苦指數超高，各種即時通訊工具每天啪啪啪跳出訊息閃著提醒（這一個專案中我們跟各方利害關係人，用到了至少四種即時通訊工具），各方壓力整天像海浪一樣席捲而來，一波未平一波又起，一波還來不及一波又來侵襲，每天都覺得厭世。也只能不停自我鼓勵，能做到這種超大型跨國專案也是難得的機會了，這麼說來最重要的溝通工具，其實只是一顆樂觀淡定，能自補熱血的心吧～（茶）（什麼結論）
發表文章
沒有留言:
張貼留言