人類一群聚多會相互分享消息。
這大概源自於遠古時代吧？ 在那當時，交換訊息有助於提升生存的機率。 比方說哪裡有食物、哪裡環境產生了變化、或是哪裡有安全的庇護所。 至於現在，訊息交換還有助於彼此之間的感情提升，比方說分享誰跟誰走的比較近、誰升職了、誰有參與了哪些活動等等的各類「八卦」。
基本上資訊交換大多無害，也沒甚麼太大問題。
唯一值得擔心的，只在於萬一資訊交換變成「流言散佈」，那就會有點傷腦筋了。 舉例而言，可能公司發佈一項規則調整。 原本立意良善，但因為大家都不理解為何要這樣，而發佈過程也沒有溝通清楚，那可能會因為這些誤解造成大家胡亂推敲。 甚至因為這樣的猜疑與假設而產生衝突與敵對，那不就很可惜了？
專案上更是要千萬避免這種事。
因為專案常有時間及其他限制條件，大家都在高度壓力下工作。 如果有一些不必要的誤解造成小團體的私下流言，那更可能造成執行上的傷害。
很多PM常有的一個經驗是這樣的。 當案子進行順利時，誰都不會特別來管你。 但是當偶爾有個問題發生時，狀況就不太一樣囉。 問題可能都解決好了，但卻會因為訊息傳遞的快與慢，PM會突然遭受不同高層來關切。 每個主管都把PM找去問說到底發生了甚麼事情？
有的高層因為一直知曉案子的狀況，大概說明後就沒事了。 但也可能有些人，因為聽到的消息轉手太多次，聽到的可能已經跟事實完全不同啦。 光是解說有時候他們不安心，還要你多提供報告或是其他數據證明。 這時候其實就會看出一個PM功力的好與壞。 因為如果一開始案子規劃的好、想的仔細，要報表或是資料其實多不難拿出來。 但相反的，若案子一開始規畫的不好，或是事情傳得太離譜了，要證明自己「清白」就沒這麼輕鬆啦。 因為手邊若都沒有相關數據、一切重做那就很辛苦啦。 尤其若時程壓力還很大時，還要為此多做些報告或是報表，這就讓人很困擾了。
那避免這種事情，一方面當然是盡量讓自己專案規劃想的透徹，該要的資訊都能很快統籌出來(換言之，排Schedule就要考慮之後要怎麼呈現)。 另一方面，就是盡量避免這類因為流言造成的麻煩事。 怎麼降低呢？ 就是確保資訊能直接流通，而非靠小道消息傳來傳去。 問題越是立刻且直接的反應出來，越不會有這種傳來傳去最後每個人聽到都不同的鳥事發生。
上面舉例的那類流言還好處理，畢竟影響人數還少，最怕的其實組員之間的耳語。 比方說，誤以為有甚麼人力調整、覺得主管有私心、或是認為PM做了甚麼不當的決策。 這類流言會帶來恐慌、而且降低團隊士氣。 更會讓所有參與其中的人失去信任並不再朝同一個方向邁進。
如果事情是真實的，那有人害怕當然無可厚非；但若因為誤解、想像、資訊不足，造成了流言散佈甚至集體恐慌，那就完全不必要了。
但為何會有流言？ 除了少部分的惡意捏造以外，大部分的流言多是因為「資訊不透明」。
像我自己就碰過幾次類似的困擾。 可能下達了某個命令，但這命令是為了解決一個暫時性問題的短期解決方案。 或許不完美，但最少是當時多方考量的一個相對最佳解。 但因為不完美，大家當然會有猜疑、也可能議論紛紛。 可是有時候大家只是幾個人私下討論。 雖然有猜疑、有不滿、有疑惑，可是並不主動出來詢問，只是大家討論後就做出了某個認知或結論。 這常常就會造成麻煩了。 因為那類猜測往往不正確，而源自於錯誤猜測做的結論更是與事實差距十萬八千里。
但這也不能怪大家。 因為當人掌握的資訊不相同時，資訊弱勢自然會到處探詢、猜測、作各類想像、並希望能藉此多了解真相。 而口耳相傳更是人類的天性，幾個都只有片段資訊的人湊在一起無法拼湊出全貌，反而會因為資訊的片段性，瞎子摸象的得出完全不正確的結論。 這就很傷腦筋了！
所以呢，降低流言、確保溝通管道其實也是專案負責人很重要的一個工作。 但杜絕流言最好的方法並不是讓大家更無知，也不是不准人談八卦；相反的，是要盡量把資訊公開揭露出來，另一個重要的，就是要鼓勵大家多上下溝通。
換句話說，案子上大家要盡量能開誠佈公的談事情。 這不但要是一個規則，更要能建立成是一種氛圍或是文化！ 因為很多不愉快的事情，往往真的只是因為不了解產生的。 像我，總是會一再強調「若任何人對於規則或指示不理解時，我其實都很願意加以說明」。 但饒是如此，我還是時常碰到很多猜測造成的誤解。 這樣都難以避免了，若PM根本不鼓勵團隊多詢問多溝通時，衝突與不愉快不就更容易發生了嗎？
再來是關於資訊公開這件事。 資訊公開並不是隨便公開資料。 一來，事情不免還是有機密的部分，未必甚麼事情都能毫無保留；二來，把一堆東西都塞給別人也不是有效的資訊分享方式。
如同我在「醜話先說、對事不對人那篇」有強調過，不管帶領甚麼事情，負責引領的人都要盡可能的確保溝通順暢，而且要在案子啟動前就應該思考下面幾點：
1. 誰需要甚麼資訊
2. 他們需要用甚麼方法了解
3. 需要多頻繁的知道
所謂誰需要甚麼資訊，指的是資訊層級的分類。 某些東西老闆該知道、某些東西Team Leader得知道、而某些東西則可能是所有成員該知道。 此外，問題發生了要先通報給誰、哪些問題要報告到哪一層級等，這也是要事先想好的。 甚至還要預先規劃，是否能以甚麼方式讓這些人可以輕易的取得？ 資訊可能是被動的收取，也可以都放在一個集中的地方讓有需要的人可以主動查閱。
若不先想好，專案進行中，案子的負責人就一定會被大量的資訊淹沒，更無餘力去正確的判斷並「及時」讓所有相關人知道。 隨便舉例、東西做好了且存檔入庫了、東西Delay了、有人生病了、要改掉某些製作的內容、外包詢的價錢來了、有人詢問合約是否可以調整、老闆前天看了產品後有些希望改善的建議、某些事情要調整製作順序，這些事情可能是一個早上同時發生的。
若資訊只是在PM手裡，那事情可是會很難推動的。 且收到資訊的人可能散布各階層，不可能逐項請示，一定要讓他們能自主判斷並做出正確的行動。 所以最好是事前就把可能會有哪些訊息、且該以甚麼方式通知、多頻繁的通知，等等的規則定義出來。 一但某些消息收到了，收到消息的人就可以據此判斷該通知誰，而不用專案的負責人一項一項的裁示
你可能會好奇，這類資訊有辦法變成規則嗎？ 當然可以。 比方說專案進度吧，大家總會關心專案狀況不是嗎？ 但每個公司或是每個組織，老闆關注的點都不同。 所以當你知道這案子的目的為何、老闆大致會想知道甚麼訊息後，你就能在開案前規劃。 比方說，可能每兩周都得提供一個「實際狀況與Baseline比較的差異報表」，這要提供給高階主管看。 或是每一個月提供一個金流變動的報表，這要提供給財務主管看。 而每周則要跟專案團隊開會討論一下CPM計算後的時程變動狀況，如要徑是哪些工作、下周工作得注意事項等。 只要開案前稍微花些時間想一想，不就可以大致的歸納出案子中「誰需要哪些資訊」、「以甚麼方式分享」、以及「資訊分享的頻率」了嗎？
透過這方式，你可以確保基本的認知；也可以避免不必要的猜疑、私底下的詢問、或是小圈圈式的資料交換。 或許還會有甚麼遺漏，但也就可以日後再針對狀況Case by Case的來處理。
那這是常態性的資訊匯報，但例外事情的資訊交換及處理程序也很重要。 比方說出問題時要告訴誰，就是很常見的一個例子。 一但問題發生，大家也知道馬上要讓誰知道時，這問題被妥善處理的機率就會提高。 而若同時相關負責人也都在問題被處理好後收到必要資訊，就能降低案子被過度干涉的機率。
其他還有很多類似的狀況。 比方說做好的東西發現問題要修改，這要知會哪些人？ 有哪些決策程序？ 有人來請款了，那要查哪些資料？ 誰可以查看？ 誰可以做決定？ 或是供應商說原來要的規格無法達到，想改變規格。 這OK嗎？ 誰可以說了算？ 而決定下了之後，是不是還要讓哪些人知道呢？ 這些其實都是開案前就大概可以猜到會發生，也可以先立下遊戲規則，以避免衝突的事情。
另外呢，資訊公開放置在一個大家都知曉之處，或是溝通規則清楚明白還有個好處。 雖然有些訊息一開始大家不是這麼有興趣知道，但最少當需要時(如出問題時)，大家還知道要去哪裡查閱。 尤其要避免讓資訊只在一兩個人身上，不然出了問題，萬一人不在現場或是早離職了。 那自然又會是慌亂的起因了。
只要相關訊息發佈的規則考慮周詳，並公開放置在人人都能取得之處。 那一但有任何疑慮時，最少大家還可以先取得一致的資料、了解一致的做法。 爭議或許還有，但就可以盡量降低了。
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
