開完會之後,寫寫會議記錄就沒事了嗎?你想太多了…
深呼吸~對,讓我們好好地深呼吸…
放心,你沒來錯地方,這裡不是教你怎麼冥想、怎麼心想事成的地方,要知道每次開完會之後,最需要深呼吸的都是那個喊著要開會的人…沒錯!就是你,身為一個 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的時候憋尿…膀胱無力是很正常的(拍肩),等專案結束之後(咦?專案有結束的一天嗎?),再一起去看醫生吧。(淚)
如果你覺得這篇文章不錯,值得拍拍手,可以拍五下 Like 給我一些鼓勵: