商業分析真的沒那麼難,只要你在對的時間找到對的人(3/7)

2019/07/28閱讀時間約 12 分鐘

對的人難找,但人找到了,才是災難的開始?

讓我們跨越時空往過去飛到 2013 年,在台北內湖某棟辦公大樓的7樓大會議室,站在小小白板前的我,正口沫橫飛地講著新產品的規劃,在台下的是一整個產品開發團隊,正帶著迷濛的眼神看著我手舞足蹈地在白板上畫圈圈。
對,我不是在角落畫圈圈,是在白板上。這也不是一場對老闆說明市場趨勢、產品規劃的會議,而是一場和開發團隊討論產品範疇和規劃的會議,但與其說是討論會議,還不如說是我在台上演講。
當時我是產品開發處的處長兼任產品經理,所以在台下的專案經理、技術主管和主工程師,雖然聚精會神地聽我在那邊噴口水,但我心想他們的靈魂恐怕已經不知道飛到哪邊去了,所以也該是時候放過他們了。
我看著團隊的專案經理問:「誒,Bryan,對這樣的規劃有沒有想法?」
「嗯…啊…Vick 你覺得呢?」他有點答不上來,所以轉頭問技術經理 Vick。
「這個…」Vick 看著我,似笑非笑地欲言又止。「Tom,你覺得呢?」
『怎麼換我中槍了?』我們的主工程師Tom心裡這樣想著(我猜的…)。
「這個看起來是不錯啦,但是要做下去才知道,那時候再說。」
哇咧靠X累…繞了一圈不等於白講嗎?我是想問你們對這樣的產品規劃,有沒有什麼更好的建議和想法,不是繞來繞去結果跟我說做了才知道,廢話,我也知道做了才知道有什麼問題,但今天開這個會議就是想避免做下去浪費時間和資源才開的,你們是在那邊給我推個什麼五四三?
好,停~當時的心裡抱怨就不再跨越時空拉到現在的時間繼續下去了。現在是 2019 年,距離當時已經整整 6 年了。而當時那場會議的情景依然就像才剛開過一樣清晰。
現在想起當時的情景其實覺得很好笑,好笑的不是同僚們的反應,好笑的是我自己,也許當初那個自己換成現在的我,那場會議的開頭就不會這麼地尷尬又好笑了。

在 PMI 的商業分析證照(PBA)中,Domain 3(簡稱 D3)講的是需求引出與擷取(Elicit and Analysis Requirements),並且也提到開發到一個階段後要做的驗證與確認 (Validation and Verification,簡稱 V&V)。
然而,有趣的是 D3 中一開頭談到的就是「如何正確開會」這件事,更詳細的說明可以看我「[D3–1] 當你不小心踏入商業分析(PMI-PBA)的陷阱之後,要記得開會是一門很重要的藝術。」這篇文章。
為什麼開會這件事這麼重要?其實,不是菜鳥的你,我想連講也不用講,在整個商業分析的過程中,身為 BA的你(商業分析師-Business Analyst),要肩負起的不只是分析的細膩度、廣度和深度,還有無止盡的會議要開,而且當然不用說,既然我這個系列的文章講的是「找對人」,那想也知道我們接下來要談談的就是在 D3 這個階段中,我們要「找對的哪些人」。
Part 3:需求引出與擷取(Elicit and Analysis Requirements)
首先,不可免俗地,在開會之前我們得先弄清楚究竟要開的是什麼會?才能夠知道究竟要找的是什麼樣的人?而在這個「需求引出與擷取」的階段中,我們開會的目的就是為了要找客戶來聊聊他們想要做些什麼。
所以,也許有些人會覺得奇怪,為什麼明明這個段落的英文明明寫的就是 Elicit and Analysis Requirements,Analysis 的中文其實是叫做「分析」,怎麼我反而翻譯成擷取了呢?難道這個 DK 的英文只有幼稚園畢業?
話說,有看過我其他文章的朋友們也猜得到了,對,這個傢伙很喜歡埋梗,而且明明就是翻譯錯了還要硬凹。最好是這樣啦…如果是翻譯錯了,打開文章編輯一下、裝作沒事就沒人發現了。
在這個階段中,對需求分析的目的就是為了要從中「擷取正確的需求」,所以我刻意不講「分析」而是「擷取」,為的就是避免這個段落名稱,變成一條比臭暈人的大便還要長的標題。而既然是為了「擷取正確的需求」,所以我們得做至少兩件事:
  1. 找對客戶的關鍵人物,問出需求。
  2. 將需求轉化為圖形語言作為溝通工具,用以跟客戶和團隊確認。
第一條「找對客戶的關鍵人物」我在前一篇文章「商業分析真的沒那麼難,只要你在對的時間找到對的人(2/7)」已經舉了個慘痛的案例,當然,我還沒講那故事的結局是什麼,但聰明如你,應該比當時的我更清楚後面的發展。
第二條就是今天這篇文章要談的主軸了。
然而當這篇文章寫到這邊的時候,其實我早就發現不太對勁了,因為在 PBA 這張證照的規劃中,除了需求引出會議(Requirements Elicitation)之外,有點莫名其妙地在 D3 的結尾塞了 V&V 這件事進來,什麼是 V&V,同樣地,可以參考我「[D3–3] 當你不小心踏入商業分析(PMI-PBA)的陷阱之後,要知道文件不是寫來擺好看的。」這篇文章。
簡單來說,V&V 就是開發產品或解決方案到某個階段的時候,要和 Stakeholders、其他 BA和 Team member 開會驗證並確認開發成果對不對。
然而這需求引出會議和需求驗證確認會議是完全的兩回事,所以找的人也不太一樣,那…這樣我文章要怎麼寫啊?唉~要知道,這年頭作者難當,PMI在給我亂搞,那我也只好跟著亂來,啊,不是啦。首先,我們先來看需求引出會議需要哪些人?
  1. 最高主管(執行長/總裁/部門主管)Master Manager:
    負責跳舞開場,不是,他是來作為宣示目標之用的,簡單來說叫做吉祥物,認真來說叫做 Sponsor,也因為通常 Master Manager 只做為吉祥物的關係,所以當它出現在需求引出會議的時候,其實只是為了宣告:「這場會議很重要,認真開!我要看到成果。」

    所以想也知道,Master Manager 這麼重要、這麼忙,怎麼可能每場會議都到場?所以,他通常都只出現在第一次的需求引出會議,並拍拍在場的產品經理的肩膀,意思就是說「我要去吃香喝辣忙其他的事,接下來靠你了」,接下來,就看到產品經理的臉抽蓄到很奇怪的角度,然後大家頭也不回地繼續把會議開下去。
  2. 產品經理/Product Manager:
    負責掌握解決方案的大方向,作為老闆們的代理人坐鎮在會議中。雖然說有了吉祥物的拍肩加持,但也不代表會議就會順利地進行下去。

    這時候產品經理通常都會化身成一般講的「大PM」,把整個系列會議的重責大任交給「小PM」,也就是一般說的專案經理(Project Manager)。
  3. 專案經理/Project Manager:
    好啦,經過一連串的責任推卸,不,不是推卸,是責任交辦之後,真正要做事的人就在這裡了,也許這時候你會問:「這文章不是在講商業分析?怎麼都已經第三篇了,商業分析師(BA)怎麼都不在人物列表之內?」嗯?真的會有人這樣問嗎?如果真的你會這樣問,那代表你要嘛就是不住在台灣,要嘛就是你們公司的人真的好好(哭)。

    在商業分析中,除非很清楚地明定PM和BA分屬於不同職位,不然,當你看到 PM 的時候,請直接把 BA 連接到 PM 這兩字後面,也就是 PM+BA 其實指的是同一個人,那麼也就是說需求引出會議的過程中,如果沒有 PM 在場,那就是 BA 的責任了。
  4. 技術經理/架構設計師/SA&PL:
    前面講了這麼多,現在終於來到一個真的有在認真做事的人身上了,對,那就是技術經理。當我們在討論使用者需求的時候,說實話,不會有使用者會很清楚明白、條理分明地跟你講述他們的需求,而整場會議中講到最後腦袋勉強還算清楚的人,大概只有技術經理了。

    原因在於很簡單的一件事,當使用者在談論需求的時候,他的腦袋裡開始滑過各式各樣的系統功能情境,一顆顆的按鈕、要用的技術、系統架構就要開始在腦袋中飛翔、組合,當你能夠找到這樣的技術經理,基本上就是上輩子祖先有積德到這輩子,整整兩輩子的福報全都灌到你身上了。

    雖然說,講得好像這樣的人是萬中選一,是位擁有打通任督二脈的練武奇才,可以用 5 塊錢賣他一本如來神掌一樣。但身為 BA 的你,千萬不要覺得技術經理一臉正經、看起來有在思考,但其實如果使用者講的內容是他從來沒做過的系統,那我可以跟你保證,他打出來的如來神掌恐怕連蠟燭都吹不滅,更何況是一株樹幹比大象腿還粗、名為「使用者」的大樹了。
  5. 關鍵使用者/Key Users:
    上面囉哩叭唆講了四種角色,講到這裏,你會不會覺得自己好像在浪費時間一樣?這篇文章看了10 分鐘,結果什麼人都不能用,從吉祥物到如來神掌沒一個在認真做事的。對,你說對了,其實整個需求引出會議的重點人物都在關鍵使用者,也就是真的會用這個系統的人。

    但是問題來了,這個系統是你規劃、你們團隊要做的,關這些使用者什麼事?什麼?你說怎麼可能不關他們的事?如果,你真的會這樣想,那就太弱了…我寫文章的套路到現在妳還沒看懂嗎?一定是有問題,我才會這樣問的。

    原因很簡單,這系統是你在規劃、開發,不是使用者做的。如果做得出來,老闆開心、你開心,但對使用者(或客戶)來說,那叫做理所當然。看懂了嗎?使用者並不會關心一個他們還沒能夠用的系統,在還沒能在手邊用之前,使用者並不在乎你能不能好做事,因為他們自己也有手頭的事情在忙,不會那麼好心地來告訴你他們要的是什麼。

    很簡單地來說,使用者是關鍵,但這個關鍵通常不太想出席需求引出會議,因為那會議對他們來說叫做浪費時間。
你文章看到這裡,我很了解你的挫折和被耍了的感覺(拍肩),但請相信我,我絕對不是故意耍你的,而是必須在這個時候認真地告訴你,在大部分的情況下,需求引出會議只會在第一次的時候有效,也就是吉祥物出現的時候有點用處。
其他的時候,請把需求引出會議直接拉到使用者身邊,也就是說想要找出真正的需求,請 BA 或 PM+BA 親身地到 Key User 未來將使用這個系統的環境中去深刻體驗,並且透過現場搜集、彙整、規劃資訊之後,在每次使用者有空的時候,用圖像的方式快速地與使用者確認彼此的想法是否一致,並且不定期地(間隔時間不要拖太久)集合上述的人物,彼此確認一下大家共同的認知是否正確,並且當場畫押,這樣才是真正的需求引出會議。
總結來說,需求引出會議需要的只有一種人:關鍵使用者。其他人只是來當吉祥物、跳舞開場、當擋箭牌、練如來神掌的。
所以,身為 BA 的你,千萬要記得一件事,不是說開會就一定是要借個會議室,大家繞圈圈、坐得好好的,甚至人手一杯咖啡,還順便有些小點心擺桌上才叫做開會。
真正的會議通常都不在會議室中,而都是在關鍵人物的身邊,會議室只是用來吹冷氣、畫押的好地方,千萬不要把目的當結果,開會不是目的,找到真正的需求才是。
關鍵使用者,就是 Part 3 中最重要的需求引出會議的唯一重點。
嗯?如果你還算清醒的話,這時候可能會問:「那…V&V 呢?都講到這邊了,V&V 的 Stakeholder 要找誰?」這時候,請你用 45 度角望向遠方那個即將落下的夕陽~你看,我們才剛拿到需求而已,還沒動手開發呢,這時候 V&V 連根毛都還沒長出來。
當我們將所有的需求全都畫押之後,在 V&V 之前還有一大堆開發會議要做,但是偉大崇高的 PMI 並沒有指示 BA 在開發會議中應該扮演的角色,而是列了 26 個圖形叫 BA 畫而已,如果你有興趣了解這些圖形,可以到這篇文章看看:「[D3–2] 當你不小心踏入商業分析(PMI-PBA)的陷阱之後,記得在對的時候用對的圖形表達你的想法。
在開發會議中,其實連想都不用想就知道有一大堆人要參與,所以,這篇文章都已經寫得這麼長了…你還想繼續看下去?別虐待自己幼小的心靈了,請先讓我的手指休息一下,然後再讓我們繼續看下去…

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

如果你覺得這篇文章不錯,值得拍拍手,可以拍五下 Like 給我一些鼓勵:
為什麼會看到廣告
DK 耀尊
DK 耀尊
AGI人工智慧科學家 &商業與產品規劃顧問|分享關於策略思維、企業管理、商業開發、組織領導的知識與技巧,還有一些有點腹黑又真實的人性+人生經驗談。
留言0
查看全部
發表第一個留言支持創作者!