開會不是罪,開錯會才是罪!讓我們來了解如何正確地開會。
在 PMI-PBA 的證照中,商業分析的步驟和內容,其實都是由軟體背景的人設計出來的,對,就是那些人(指)!
尤其是 Chapter 4 (Domain 3, 簡稱 D3) 的部分更是明顯地看到擺明了的痕跡。在 D3 的章節中,分成3大段落:
1.「教你如何開會」:有人會說這麼簡單的事,哪還需要教?錯了,開會是一門藝術,不是那麼簡單喊喊就會的。
2.「用一大堆圖形轟炸你」:對,就是一堆圖,而且這堆圖在大部分的產業中不會被廣泛使用,只有長期浸潤在軟體業的人才會看過所有的圖形,而且還不一定全部都用過。
3.「驗證、確認產出結果」:其實講白話一點,就是找內部的人看過、找外部(客戶)的人也看過,然後雙方握握手、點點頭,畫押簽字繼續往下一起走。
所以,當你看到 D3 又臭又長篇幅的時候不用怕,只是在教你「開會」、「畫圖」還有「握握手」。就這樣,講完了。
嗯?如果真的就這樣講完,我大概會被罵到臭頭。因為這些事,看過書就知道了,還需要我講?所以,為了湊篇幅…不,不是…是為了講得更深入一些,就讓我繼續的說下去。
首先,我們來看看「如何開會」這件事。
當你看到在 D3 一開頭就教我們如何開會,就要有個警覺心,要知道PMI的那些人有多麽地重視開會這件事,重要到非在高階的證照(PBA)中,特別花了一個大段落教我們如何開會…嘖嘖…真是太~用心了。
但問題是,我們有那麼喜歡開會嗎?事情都做不完了,還開什麼屁會?還不都是老闆在那邊講,要不然就是底下的人亂哄哄鬧成一團之後,沒有結論一轟而散。
好吧,我講得太偏激了點。
開會其實是有它的必要性,開會是個為了企業繼續生存下去的「必要之惡」,這樣講,客官您懂了嗎?開會的過程中,我們可以分成四大部分來看它。
Introduction — 啟動會議
首先,你總得告訴大家要開會吧?要開什麼會,有哪些人會來、該來、必須來,會議中要討論哪些問題,要請哪些人站起來被釘,要請哪些人鼓掌叫好,要請哪些人在台下當樁腳…這些你得在開會之前都搞定,而且更重要的是,請努力地將必須要來的那些人的時程表排上他們的腦袋裡,因為既然是必須要來的人,那麼這場會議的主角當然是他們,絕對不是你。而且這麼重要的人,除非他是老闆、大主管或是很有Guts,不然通常都會躲躲藏藏不想面對戰場上發生的一切。
Body — 正式開會
接下來,就是要開會啦。在開會之前,有件事一定要做,那就是好好地將門關緊、關好,確認不會有聲音漏出來。我曾經眼睜睜地看過一場很好笑的會議,因為裡面講著講著開始數落起老闆的不是,然後,你知道的,夜路走多都會碰到鬼,門沒關好,而老闆不知道是氣還是笑地在門口附近徘徊。而我知道的是,之後很長一段時間,老闆沒有正面看過那場會議裡面參與的那些人。這故事如有雷同,純屬巧合,不要問我那些人是誰…
Conclusion — 結論
會議開著開著,總會討論各式各樣的問題、各式各樣的解法,得出各式各樣的結論,對吧?真的是這樣,對吧?有人不是這樣嗎?你說對吧?看我這麼囉唆地講同一句話,那就知道事情沒那麼單純…
開會通常有兩種:一種大家很嗨,然後沒有結論;一種大家很 Low,然後只有一個結論。這兩種哪種好?答案是兩種都很好。什麼?你說這樣哪會好?別急,想也知道我才說到一半。
沒有結論的那種,非常讚,我特別喜歡,但也特別討厭。因為如果你是會議主持人,那你得為這場會議的所有內容下結論。這樣會有什麼結果呢?那就是如果你的結論面面俱到下得好,所有人都會鼓掌叫好,然後照著你的結論去做。如果下不好,那就再等著下一場會議把同樣的議題重新吵過一遍,到時候就像舊菜重新熱鍋一樣,吃不到新鮮的味道,搞不好還會因為新加入的情況而完全走了味。
另一種,只有一種結論的那種,這沒什麼不好,但也沒什麼好處。因為沒有人會鳥你下的結論是什麼,大家離開了會議室還是各行其是。好處就是風平浪靜,壞處就是誰下的結論就誰去做事。這時候,理所當然地就是主持人,通常是 BA…想辦法去湊資源、求 PM 把事情給搞定了。啊,對了,在台灣,PM通常兼任 BA,所以,你還是得自己搞定它。
有了結論(或沒有結論)之後,會議就這樣結束了嗎?
Follow up — 後續追蹤
不,當然不是!我們還要繼續追蹤結論的施行後續成效及進展啊。會這樣說的話,代表你可能是兩種人:
1. 被 PMP 荼毒已久的人;2. 專案管理菜鳥(不是BA)。
因為會議之後對結論施行的追蹤,雖然是必須的,但施行的成效和進展並不是商業分析師(BA)的責任啊…那是 PM的…啊,不對…如果你很幸運地生在台灣,那麼也就是你的責任(PM+BA)。
到這邊為止,開會的四大階段就完美地結束了。然後,接下來才是真正的苦難開始。(尤其是對非軟體產業出身的人更是如此)
如果你覺得這篇文章不錯,值得拍拍手,也可以拍五下 Like 給我一些鼓勵: