2019-07-25|閱讀時間 ‧ 約 8 分鐘

[D5] 當你不小心踏入PMI-PBA的陷阱之後,要知道專案是沒有結束的一天的。

別以為解決方案上線之後就不關你的事了,事情才剛開始…

結案人人要,不過人人做不到。你的名字不是”人人”,你的名字是 BA,榮耀的 BA,此稱呼可見另一篇文章:[D4] 當你不小心踏入PMI-PBA的陷阱之後,要知道你的本分不是挖掘也不是管理需求。
PMI 這張 PBA 證照大概是我到目前為止,覺得少數真的最貼近實務經驗的證照了,這倒不是說其他證照(例:PMP)就是打空砲,而是相對其他證照來說(例:或是 ACP),PBA 不需要非常多的經驗就能夠了解到,這張證照的內容根本就是很實際地描述 BA 每天的生活…
當翻開 BAG 之後,你看到的目錄就是 BA 實際上全部要做的事情,一直到 Solution 上線階段該做的,一個一個的細節就怕你一不小心搞砸了 PMI-PBA 這張證照的光環,喔,這裡講的不是你操到掛之後,頭上的那個光環喔。
當我們循序漸進隨著 BAG 的腳步到了 Chapter 6 (Domain 5,簡稱 D5) 之後,其實已經可以準備放炮慶祝迎接下一個挑戰了(咦?不是慶祝結案?)
在這個最後的階段,講來講去只有三件事情要做:
  1. 準備結案。(Prepare Evaluation)
  2. 結案。(Evaluation)
  3. 追蹤結案結果。(Trace results after the Closure)
講完,以上就是 D5 在做的事,解散。如果我這樣講,應該不會有人相信,畢竟,眼睛隨便往下一掃,就可以看到還有一大篇文章等著荼毒你的眼睛。
怎麼可能就這樣結束呢?
Mindset during Development — 在開發過程中隨時該保持的心態。
在一開頭的 P.158 就千叮嚀、萬交代你四件在最後的評估階段必須要注意的四件事:
  1. Evaluate Early and Often:越早開始、越頻繁評估越好。雖然理論上說,這件事必須要看你們團隊採用的 Project Life Circle 而定,但說實話,即使你們採用的是 Adaptive 或用 Agile,在解決方案開發的過程中,你一定還是會發現一大堆會造成開發方向偏離的事,像是工程師突然覺得:「誒?這功能好像可以再放到另一個地方用,所以我小改一下拿去另一個專案用用好了。」這種事常不常見?只要你一不注意就會天天發生。雖然這個偏差似乎和你正關注的 Solution 無關,但可是要記得,注意力這個寶貴資源可是一不小心就會失控的。
  2. Treat Requirements Analysis, Traceability, Testing and Evaluation as Complementary Activities:分析、追蹤、測試和評估都是相輔相成、缺一不可的,千萬不要自作主張覺得哪些部分是可以簡化或是略過不做。但我相信經驗豐富的你,不會這樣幹的,嗯?為啥明知道你不會這樣幹還要寫?啊我不就是湊版面而已…哈哈哈。
  3. Evaluate with the Context of Usage and Value in Mind:要知道,一個 Solution 完成之後是要給人用的,所以你必須隨時注意 Solution 是否滿足當初所期望的用途和價值,在開發的過程中,如果你哪天忘記了這件事,有超過 90 % 以上的機率,那天做的事情幾乎等於做白工,更慘的是後面還救不回來,很嚇人嗎?不,這還算好的,就像順口的白蘭地喝多了一樣,你就會知道後勁是不是強到讓你把胃都吐出來了。
  4. Confirm Expected Values for Software Solution:確認確認再確認,就像在第三點中談到的事情一樣,在最後的最後,你更加必須確認 Solution 的確達成期望中所帶來的價值。
當你很順利…通常是不太可能啦,總之,當你爬過爛泥巴、挺過天堂路終於來到這個審判台的時候,通常一個正常的 BA 已經快要被操到語無倫次,不知道該怎麼獻出自己的心臟來面對巨人的挑戰了。
開始準備結案了…那~該用什麼標準來結案呢?
BAG 其實非常貼心地幫你列出幾個你可以放上審判台的評估方向,包含Business Goals and Objects、Key Performance Indicators (KPIs)、Project Metrics、Customer Metrics、Sales and Marketing Metrics、Operational Metrics and Assessments、Functional and Non-functional Metrics。這些方向都只是方向而已,裡面的內容要看各公司自己的定義。
至於這些評估標準,要用什麼方式去得到答案呢?BAG P.165 的最上面已經幫你列出七個方法(下面我把功能性和非功能性放在一起講):
  1. Surveys and Focus Groups:烙一大堆或核心顧客來直接決定你生死。
  2. Exploratory testing and User Acceptance Testing(UAT):隨便亂點、亂測,目的就是要搞死這個 Solution。
  3. Day-in-the-Life:從睡醒到晚上睡覺,用個一整天(或是好幾天、幾個月)來看看這個 Solution 能不能正常運作。
  4. Integrating Testing:和其他系統一起並行個好一段時間。
  5. Functionality and Non-functionality:功能性和非功能性和預期中想要的是不是一樣?
  6. Outcome and Financial benefit:有沒有賺錢。
結案!Dead or Live!
根據上面這些測試的結果,再來開一個 Go/No-Go 審判大會決定這個 Solution 是不是要上線還是打回修改、重做,或是直接因為浪費了太多錢而把你 Fire。
如果你真的很幸運地在審判台上被高高舉起、輕輕放下,那你就可以比較安心地看著老闆們在 Document 上真正地簽下他們的名字,Sign-off了!
等等…別急著開慶功宴。你現在才剛度過第二階段而已,你只能高興自己目前還活著,但沒辦法保證你還可以活多久…
因為事情永遠不會這麼簡單就放過你…專案永遠沒有結案的一天。
接下來你還得評估如何將 Solution 上線、如何替換原有的系統或是和它共存、追蹤後續所有可能發生的效益。
簡單來說(希望這是我最後一次用這詞),無論你的 Solution 做得有多棒,得到多少世界金牌獎、是多麽地強大又好用,你還是得面對如何汰換掉舊有機制的問題,你還得規劃、溝通、設計、佈建、教育訓練、追蹤、緊急應變,這些都包含在系統上線計畫之中。
有沒有聽起來又像是另一個專案?對,那就是另一個專案的開始,而且等到它結束之後,代表你的系統已經被用了一段時間,所以又會有新的需求誕生,然後又再另一個無窮迴圈下去,這就是 BA 所要面對的一切。
恭喜你!熬過了冬天之後,下一個還是冬天。BA 要做的事情就是讓自己的心充滿溫度,不要被繁雜又鋪天蓋地的大雪,掩埋在充滿文件、衝突和雜務的戰場下了。
你是 BA,低調又榮耀的 BA。

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

如果你覺得這篇文章不錯,值得拍拍手,可以拍五下 Like 給我一些鼓勵:
分享至
成為作者繼續創作的動力吧!
© 2024 vocus All rights reserved.