更新於 2022/11/10發佈於 2019/07/23閱讀時間約 10 分鐘

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

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

深呼吸～對，讓我們好好地深呼吸…

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

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

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

Documentation — 需求文件化

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

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

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

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

Business Requirements Document。
Solution Document (BAG 章節上是 The Solution Documentation)。
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 給我一些鼓勵：

DK耀尊 (drkurt-tw)

Reward Creativity, powered by LikeCoin

分享至

成為作者繼續創作的動力吧！

PMI-PBA-國際商業分析證照

追蹤