[專案管理]最大的風險,總是藏在哪裡?

我認為最大的風險,總是躲在「邊界」

大家覺得,在專案進行的過程中,最困難、可能造成最大風險的部分是什麼呢?是技術難度?市場需求改變?利害關係人的支持?我認為最大的風險來源,總是躲在邊界。

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

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

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

一個充滿邊界的專案

之前的文章曾提到,我曾參加一個超大專案。

當時我提到:

這個產品線規模有多大呢?光是做伺服器的團隊就有三個不同開發團隊,做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)(死)。

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

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

(這篇文章同步刊登在專案管理雜誌八月號,這篇是修改後的內容)

關於拍手,陪我做個實驗吧!
我希望拍手除了支持之外,也能嘗試做為投票工具,所以:
如果你/妳只是單純喜歡這篇文章,請給我1–10個拍手。
如果你/妳很喜歡我的「專案管理」類型的文章,請給我這篇文章11個以上拍手,越喜歡當然可以拍越多,我之後會為你常寫的!
也要記得「Follow」我 Evonne Tsai,讓我提供更多優質文章給您
當然也可以用街口支付,掃碼請我喝杯咖啡喔!若不會用街口打賞請參考:如何用街口支付小額支持作家
(在這裡要來低調感謝一下所有有打賞的朋友們~)