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