方格精選

[D3-3] 當你不小心踏入PMI-PBA的陷阱之後,要知道文件不是寫來擺好看的。

更新 發佈閱讀 11 分鐘

開完會之後,寫寫會議記錄就沒事了嗎?你想太多了…

raw-image

深呼吸~對,讓我們好好地深呼吸…

放心,你沒來錯地方,這裡不是教你怎麼冥想、怎麼心想事成的地方,要知道每次開完會之後,最需要深呼吸的都是那個喊著要開會的人…沒錯!就是你,身為一個 BA(在台灣,你還會是個PM),怎麼可能就這樣寫寫會議記錄就放過你?

啥?你說會議記錄怎麼會是BA在做?不是你,難道是老闆?難道是工程師?難道是主管?還是PM(如果不是你兼任的話)?最好能夠幫你配一個甜美/帥氣的小助理就最好了對吧?別想太多了,對,就是你,認命吧!

當我們很認真地用數量多到嚇死人的各種表格、圖形和模型,花了很漫長的時間開完會之後,希望你還醒著…不,不是說你講得太無聊讓大家都睡著了,而是在開會過程中,你必須用各式各樣的方法讓大家保持注意力,而且最需要保持注意力的人,對,還是你,無所不能的BA(+PM)。

Documentation — 需求文件化

在 PMI 用 Chapter 4 (Domain 3,簡稱 D3) 的開會流程和26種表格圖形摧殘荼毒我們的心智之後,接下來無論在會議上是否得出共同的結論,你,對,依然是你…都必須做出結論,而且一定要將這個結論文件化。

為什麼要幹這麼麻煩的事呢?想也知道,我不會把你假設成一個什麼都不懂、只是來看看文章笑一笑的人。有了文件,最重要的事情除了可以拿來蓋泡麵、墊椅腳之外,唯一的作用就只能拿來畫押了。這我相信不用多講,你也知道我會講這個結論。

但這位客倌…你認為我會這麼簡單地放過你嗎?要知道一份好的文件包含了多少人的心酸血淚,一份好的文件犧牲了多少人的頭顱鮮血…好好好,我講得太誇張了點,雖然在這篇文章(當你不小心踏入商業分析(PMI-PBA)的陷阱之後,要記得開會是一門很重要的藝術。)中我把會議比喻成戰場,但相信經歷過無數槍林彈火洗禮的你,絕對能感同身受,在開完會後要整理出一份行動方案的文件,真的是需要犧牲多少悲憤的血汗與兄弟姐妹們的撕裂吶喊,嗯,越講越誇張了…但簡單來說(我真的很愛用這詞),開完會後所必須遺留下來的,除了會議記錄和PM的屍體之外,就是行動方案文件了。

根據 PMI 崇高偉大思想的指示,在這份行動方案文件中,必須要有三個文件作為領頭羊,它們分別是:

  1. Business Requirements Document。
  2. Solution Document (BAG 章節上是 The Solution Documentation)。
  3. Requirement Specification。

有了這三份文件,基本上,你同事們就會把你當成神一樣在拜了。對,把你當神在拜的意思就是把你拱起來放在那邊晾著吹乾,遇到危險的時候再來求你幫忙、把你拉出來當擋箭牌。

所以人客啊~不要傻傻地認為只要產出這三份文件就行了啊!雖然這樣講起來很不負責任,但事實上是這些文件只有兩種人會看,一種是忙著寫文件的你(在寫的當下一定會看到),另一種人是太閒的人(包含老闆、工程師、來審核、審查的人)。

但是你能不寫嗎?不,當然不能不寫,你不要命了嗎?寫完這些文件之後,光靠那個厚度,你就可以拿來往偏離需求目標的工程師後腦敲下去、打扁他,而且他還不敢哇哇叫,只敢在程式碼裡面埋大便彩蛋,或是聯合其他不滿的工程師一起作亂而已。

Requirement Prioritization — 需求排序

媽呀,聽起來怎麼這些文件只有壞處沒好處啊?你會不會想說我只是想這樣講來嚇死你。我最愛用的詞又派上用場了:「事情當然還是沒這麼單純」,你傻了嗎?我會這樣鬼扯一通然後叫你別寫這些文件嗎?怎麼可能?當然是有它真正的用途的。(絕對不是暴力用途!我愛和平,拒絕暴力!)

當我們仔細往這些文件裡看進去你會發現,它們全部都圍繞在Requirement這個字打轉,看見沒?它們是為了Requirement而生,也為 Requirement 而死的。從 Business Requirement Document 裡談到什麼是 Business Requirement 之後,我們就要開始想盡辦法找出 Solution,並且把這些 Solution 以及實現方法都記錄下來,然後靠著 Requirement Specification 的協助將所有 Solution 一一實現出來。事情就是這麼簡單!

屁啦…聽我在鬼扯。世界上沒有白吃的午餐,也沒有白痴的晚餐。世界上的食物永遠有其極限,企業內的資源永遠都有一堆人跟你搶,即使你是大老闆也一樣。

因此,我們必須依靠各種辦法(MoSCow、Multi-Voting、Time-boxing、Weighted ranking) 來將這些 Requirement 決定個生死存亡的順序。

Acquire Resources — 獲取資源

決定完之後,就是你死我活、弱肉強食的時代了。別以為檯面上分配給你的資源和時間就是真的,難道你不知道穀倉裡通常都住著好幾代的老鼠嗎?你當他們可以存活那麼久是玩假的啊?

當然,你要使盡所有力氣,好好地掌握、交易、排除所有你應該或不應該使用的資源。為什麼連不應該使用的資源都要注意並且排除?因為,出來混,總有一天是要還的。

當你努力地拼死拼活陪著團隊完成 Solution 的時候,還別笑得太早,你才不過走過一半的泥巴地,天堂路還在後面等著你。啊,對,你是“陪著”團隊,不是”帶領”團隊,別搞錯了,帶領團隊是PM的責任,不是BA的,這要很清楚地分別出來,雖然,實務上你是PM+BA沒錯啦….

Validation and Verification — 驗證與確認

當你咬著牙、跪下去準備爬那條天堂路的時候,請記得再痛再苦,一個傷口爬過一個,總會有結束的一天。不要意氣用事在 V&V (Validation & Verification)的時候跟別人槓起來。不論你是在 Validation 的時候被 Stakeholders 酸到不行,還是在 Verification 的時候被其他 BA 和 Team member 死往你的痛處打,都忍住!記得爬過天堂路,你!勇猛的你!不只會變成一個真正的 BA,而且還是個滿身是傷、充滿榮耀傷痕的…BA。

Glory Business Analyst — 榮耀的商業分析師是什麼?還是商業分析師。

是的,沒人會把你當英雄還是勇士,說穿了,你仍然只是個 BA。

別說笑了,BA 這工作這麼難搞,怎麼可能會有人想做這工作還做得不亦樂乎?當然,BA不論在哪裡,都是一個只會被人晾在一邊的工作,而且這還是你的職責。你不是PM,你不是 Leader,你,就只是個商業分析師,是團隊中不一定必要,但有了你就很有效的一份子。

放心,別哭~有人告訴過你這個真相嗎?BA 是配角,不是主角。

即使商業分析的技能是從 CEO 到小主管都必須具備的,但它不是團隊做出 Solution 的必要條件,而是做出具有 Business Value 的最佳武器,雖然這武器通常只被拿出來晃一晃嚇人,就像關聖老爺的青龍偃月刀一樣,只被拿來嚇嚇人,而無法在戰場派上用處。

看到這邊,我想你心裡應該很清楚我的套路了,事情永遠不會這麼簡單…我怎麼可能浪費這麼多口舌在這裡講一個根本派不上用場的東西,拿來蓋泡麵?墊桌腳?我直接從廢紙堆裡翻一疊印壞的A4紙還比較好用。

如果你寫出來的文件真的就像剛剛說的那麼無用,或是你身為 BA 的角色就是這麼地路人甲的話,那麼我們真的別玩了~去賣雞排還比較賺。(好像真的也是如此?)

當你身為 BA 的時候,要記得你是”陪伴”團隊的角色,什麼叫做陪伴?那就是跟著大家一同爬山涉水、一同含辛茹苦、上刀山下油鍋、在前線衝鋒陷陣的角色啊,你對於團隊來說是個指南針、是北極星,你手上的這些文件就是作戰計劃指南,別搞丟了,別真的拿去蓋泡麵搞得油滋滋。

High Quality Requirement — 高品質的需求描述。

你的文件要真的能派上用場,勢必要圍繞著它的中心思想上,對,請回想或往上翻剛剛我講了什麼,它的中心就是 Requirement!你必須把 Requirement 寫得夠好、夠完整、夠接地氣、夠真實。

這就是為什麼在 BAG 的 P.123 到P.128頁裡特別提出那九個滿足高品質 Requriement 的特性要求了,還記得哪九個嗎?Unambiguous、Precise、Consistent、Correct、Complete、Measurable、Feasible、Traceable、Testable,這九個特質不是寫來讓你背背、應付證照考試而已的,你每一個列在文件裡的 Requirement 只要是滿足這九個特質的話,你的文件才會真的有價值,才會是本真正的作戰計劃指南。不然,沒有的話,你還是拿去蓋泡麵、墊桌腳吧。

講到這邊,你能夠了解為什麼 BAG 要花那麼大的篇幅講這九大特質了嗎?它們的那個標題小小的,看起來毫不起眼,但卻是你這份文件成敗的最大要素。沒有它們,整個 Solution做完之後,Business Owner 願意賭上自己的身家同意你的計畫才有鬼,嗯,這樣講不太精確,應該說要嘛他鬼上身,要嘛他已經私底下偷偷在找新工作了。

THE End — 尾聲?No…To be continue…

就這樣,能把這篇文章看到這裡已經非常了不起了,因為你經歷了許多驚嚇來到這裡。從文件的產出、Requirement的排序、V&V、九大特質的必要性以及它們對 Approval 的影響。希望你沒嚇出尿來,如果真的嚇到尿出來,放心,我不會說你偷尿尿,畢竟所有 BA 通常都是憋尿高手,寫文件憋尿、開會憋尿、V&V的時候憋尿…膀胱無力是很正常的(拍肩),等專案結束之後(咦?專案有結束的一天嗎?),再一起去看醫生吧。(淚)


如果這篇文章你想用聽的,可以在這裡找得到:
https://www.ears.tw/sounddetails/1748


如果你覺得這篇文章不錯,值得拍拍手,可以拍五下 Like 給我一些鼓勵:



留言
avatar-img
DK 耀尊的沙龍
36會員
34內容數
讓我們用輕鬆的角度來看看 PBA-商業分析在實務上會發生什麼事。
DK 耀尊的沙龍的其他內容
2019/07/31
當你咬著牙爬過天堂路之後,才會發現接下來才是考驗的開始。 好啦,如果你終於經歷過千辛萬苦,爬著名叫產品或系統開發的天堂路爬到這篇文章,那麼很高興地,我們可以恭喜自己終於走過了一半的路。什麼?才一半而已,開發完畢之後,不就準備要驗收結案了嗎?哪是一半的路?
Thumbnail
2019/07/31
當你咬著牙爬過天堂路之後,才會發現接下來才是考驗的開始。 好啦,如果你終於經歷過千辛萬苦,爬著名叫產品或系統開發的天堂路爬到這篇文章,那麼很高興地,我們可以恭喜自己終於走過了一半的路。什麼?才一半而已,開發完畢之後,不就準備要驗收結案了嗎?哪是一半的路?
Thumbnail
2019/07/29
開發會議不是重點,重要的是開完會之後有沒有照著結論做。 從第一次參與開發會議以來到今天(2019),不知不覺已經過了20幾個年頭,沒有感嘆歲月如梭,也沒有撚著白髮蒼蒼的蹉跎,唯一不變的仍然是沒有效率的會議和互相指責的場景。
Thumbnail
2019/07/29
開發會議不是重點,重要的是開完會之後有沒有照著結論做。 從第一次參與開發會議以來到今天(2019),不知不覺已經過了20幾個年頭,沒有感嘆歲月如梭,也沒有撚著白髮蒼蒼的蹉跎,唯一不變的仍然是沒有效率的會議和互相指責的場景。
Thumbnail
2019/07/28
對的人難找,但人找到了,才是災難的開始? 讓我們跨越時空往過去飛到 2013 年,在台北內湖某棟辦公大樓的7樓大會議室,站在小小白板前的我,正口沫橫飛地講著新產品的規劃,在台下的是一整個產品開發團隊,正帶著迷濛的眼神看著我手舞足蹈地在白板上畫圈圈。
Thumbnail
2019/07/28
對的人難找,但人找到了,才是災難的開始? 讓我們跨越時空往過去飛到 2013 年,在台北內湖某棟辦公大樓的7樓大會議室,站在小小白板前的我,正口沫橫飛地講著新產品的規劃,在台下的是一整個產品開發團隊,正帶著迷濛的眼神看著我手舞足蹈地在白板上畫圈圈。
Thumbnail
看更多
你可能也想看
Thumbnail
在 vocus 與你一起探索內容、發掘靈感的路上,我們又將啟動新的冒險——vocus App 正式推出! 現在起,你可以在 iOS App Store 下載全新上架的 vocus App。 無論是在通勤路上、日常空檔,或一天結束後的放鬆時刻,都能自在沈浸在內容宇宙中。
Thumbnail
在 vocus 與你一起探索內容、發掘靈感的路上,我們又將啟動新的冒險——vocus App 正式推出! 現在起,你可以在 iOS App Store 下載全新上架的 vocus App。 無論是在通勤路上、日常空檔,或一天結束後的放鬆時刻,都能自在沈浸在內容宇宙中。
Thumbnail
市場經驗拉長之後,很多投資人都會遇到同一個問題:不是方向看錯,而是部位太集中個股,常常跟大趨勢脫節。 早年的台股環境,中小股非常吃香,反而權值股不動,但QE量化寬鬆後,特別是疫情之後,後疫情時代,鈔票大量在股市走動,這些大資金只能往權值股走,因此早年小P的策略偏向中小型個股,但近年AI興起,高技術
Thumbnail
市場經驗拉長之後,很多投資人都會遇到同一個問題:不是方向看錯,而是部位太集中個股,常常跟大趨勢脫節。 早年的台股環境,中小股非常吃香,反而權值股不動,但QE量化寬鬆後,特別是疫情之後,後疫情時代,鈔票大量在股市走動,這些大資金只能往權值股走,因此早年小P的策略偏向中小型個股,但近年AI興起,高技術
Thumbnail
vocus 慶祝推出 App,舉辦 2026 全站慶。推出精選內容與數位商品折扣,訂單免費與紅包抽獎、新註冊會員專屬活動、Boba Boost 贊助抽紅包,以及全站徵文,並邀請你一起來回顧過去的一年, vocus 與創作者共同留下了哪些精彩創作。
Thumbnail
vocus 慶祝推出 App,舉辦 2026 全站慶。推出精選內容與數位商品折扣,訂單免費與紅包抽獎、新註冊會員專屬活動、Boba Boost 贊助抽紅包,以及全站徵文,並邀請你一起來回顧過去的一年, vocus 與創作者共同留下了哪些精彩創作。
Thumbnail
大家開會之後記起來就好啦,幹嘛做會議紀錄? 為什麼要做會議紀錄? 不知道你有沒遇過開完會之後,得出一個結論,下次開會發現雙方認知不一樣的情況,一個會議各自表述。 會議記錄是為了再次確認雙方認知在同一個水平線,而產生的文件。 但只有這樣而已嗎?絕對不只! 會議記錄是情報的基礎 再次確認對方的訴求
Thumbnail
大家開會之後記起來就好啦,幹嘛做會議紀錄? 為什麼要做會議紀錄? 不知道你有沒遇過開完會之後,得出一個結論,下次開會發現雙方認知不一樣的情況,一個會議各自表述。 會議記錄是為了再次確認雙方認知在同一個水平線,而產生的文件。 但只有這樣而已嗎?絕對不只! 會議記錄是情報的基礎 再次確認對方的訴求
Thumbnail
這篇主要會是將工作上的開會經驗做一個覆盤的整理。以專案管理來說,必定會經過專案的啟動、規劃、執行到最後的驗收。每一個階段都有可能會有它潛在的問題,而一個成功的專案管理在過去可能會被定義為如期、如質、如預算的完成任務,但現在環境多變,依據現狀隨時調整,逐步朝目標前進,或許才是更適合的選擇。
Thumbnail
這篇主要會是將工作上的開會經驗做一個覆盤的整理。以專案管理來說,必定會經過專案的啟動、規劃、執行到最後的驗收。每一個階段都有可能會有它潛在的問題,而一個成功的專案管理在過去可能會被定義為如期、如質、如預算的完成任務,但現在環境多變,依據現狀隨時調整,逐步朝目標前進,或許才是更適合的選擇。
Thumbnail
講到專案管理,你會想到什麼 甘特圖、專案組織圖、專案計畫? 這些都只是專案管理的工具 回歸到專案管理的目的 就是要讓專案如期完成 以前的我不斷追求工具的效率化 希望用看板管理、快速畫出甘特圖的工具 因為這些是專案管理者,也就是PM能獨自完成的事 但,專案絕對不止是PM的事 與其埋頭苦幹這些
Thumbnail
講到專案管理,你會想到什麼 甘特圖、專案組織圖、專案計畫? 這些都只是專案管理的工具 回歸到專案管理的目的 就是要讓專案如期完成 以前的我不斷追求工具的效率化 希望用看板管理、快速畫出甘特圖的工具 因為這些是專案管理者,也就是PM能獨自完成的事 但,專案絕對不止是PM的事 與其埋頭苦幹這些
Thumbnail
「簡報」的目的即根據資料整理後定義的機會去做的延伸,目的是「取得信任」。
Thumbnail
「簡報」的目的即根據資料整理後定義的機會去做的延伸,目的是「取得信任」。
Thumbnail
我當時當後輩時、有一次聽到前輩主管對我整理出來的資訊回憶起來:「當初會議中是討論到什麼?為什麼要整理這份資料啊?」
Thumbnail
我當時當後輩時、有一次聽到前輩主管對我整理出來的資訊回憶起來:「當初會議中是討論到什麼?為什麼要整理這份資料啊?」
Thumbnail
商業分析最重要的不是看數據說話,而是沿著人性的毛順順地摸下去。 好多年前的某個夜晚,大約半夜 12 點多的時候,我獨自一個人坐在公司 8 樓夾層的大會議室窗戶旁邊,看著窗外的街道,靜靜地抽著煙。
Thumbnail
商業分析最重要的不是看數據說話,而是沿著人性的毛順順地摸下去。 好多年前的某個夜晚,大約半夜 12 點多的時候,我獨自一個人坐在公司 8 樓夾層的大會議室窗戶旁邊,看著窗外的街道,靜靜地抽著煙。
Thumbnail
開發會議不是重點,重要的是開完會之後有沒有照著結論做。 從第一次參與開發會議以來到今天(2019),不知不覺已經過了20幾個年頭,沒有感嘆歲月如梭,也沒有撚著白髮蒼蒼的蹉跎,唯一不變的仍然是沒有效率的會議和互相指責的場景。
Thumbnail
開發會議不是重點,重要的是開完會之後有沒有照著結論做。 從第一次參與開發會議以來到今天(2019),不知不覺已經過了20幾個年頭,沒有感嘆歲月如梭,也沒有撚著白髮蒼蒼的蹉跎,唯一不變的仍然是沒有效率的會議和互相指責的場景。
Thumbnail
開完會之後,寫寫會議記錄就沒事了嗎?你想太多了… 深呼吸~對,讓我們好好地深呼吸… 放心,你沒來錯地方,這裡不是教你怎麼冥想、怎麼心想事成的地方,要知道每次開完會之後,最需要深呼吸的都是那個喊著要開會的人…沒錯!就是你,身為一個 BA(在台灣,你還會是個PM),怎麼可能就這樣寫寫會議記錄就放過你?
Thumbnail
開完會之後,寫寫會議記錄就沒事了嗎?你想太多了… 深呼吸~對,讓我們好好地深呼吸… 放心,你沒來錯地方,這裡不是教你怎麼冥想、怎麼心想事成的地方,要知道每次開完會之後,最需要深呼吸的都是那個喊著要開會的人…沒錯!就是你,身為一個 BA(在台灣,你還會是個PM),怎麼可能就這樣寫寫會議記錄就放過你?
Thumbnail
26 種圖形、表格和模型不是讓你用來填報告書厚度的。 PBA BAG 的 Chapter 4 (Domain 3, 簡稱D3)中,除了PMI 一開始就很熱心地告訴我們如何開會之外,最麻煩也最討人厭的就是第二部分的一大堆圖形、表格和模型了,這一大堆歪七扭八的方格線條,幾乎都是軟體業常用的工具。
Thumbnail
26 種圖形、表格和模型不是讓你用來填報告書厚度的。 PBA BAG 的 Chapter 4 (Domain 3, 簡稱D3)中,除了PMI 一開始就很熱心地告訴我們如何開會之外,最麻煩也最討人厭的就是第二部分的一大堆圖形、表格和模型了,這一大堆歪七扭八的方格線條,幾乎都是軟體業常用的工具。
追蹤感興趣的內容從 Google News 追蹤更多 vocus 的最新精選內容追蹤 Google News