別以為解決方案上線之後就不關你的事了，事情才剛開始…
結案人人要，不過人人做不到。你的名字不是”人人”，你的名字是 BA，榮耀的 BA，此稱呼可見另一篇文章：[D4] 當你不小心踏入PMI-PBA的陷阱之後，要知道你的本分不是挖掘也不是管理需求。
PMI 這張 PBA 證照大概是我到目前為止，覺得少數真的最貼近實務經驗的證照了，這倒不是說其他證照(例：PMP)就是打空砲，而是相對其他證照來說(例：或是 ACP)，PBA 不需要非常多的經驗就能夠了解到，這張證照的內容根本就是很實際地描述 BA 每天的生活…
當翻開 BAG 之後，你看到的目錄就是 BA 實際上全部要做的事情，一直到 Solution 上線階段該做的，一個一個的細節就怕你一不小心搞砸了 PMI-PBA 這張證照的光環，喔，這裡講的不是你操到掛之後，頭上的那個光環喔。當我們循序漸進隨著 BAG 的腳步到了 Chapter 6 (Domain 5，簡稱 D5) 之後，其實已經可以準備放炮慶祝迎接下一個挑戰了(咦？不是慶祝結案？)
在這個最後的階段，講來講去只有三件事情要做：
- 準備結案。(Prepare Evaluation)
- 結案。(Evaluation)
- 追蹤結案結果。(Trace results after the Closure)
講完，以上就是 D5 在做的事，解散。如果我這樣講，應該不會有人相信，畢竟，眼睛隨便往下一掃，就可以看到還有一大篇文章等著荼毒你的眼睛。
怎麼可能就這樣結束呢？
Mindset during Development — 在開發過程中隨時該保持的心態。
在一開頭的 P.158 就千叮嚀、萬交代你四件在最後的評估階段必須要注意的四件事：
- Evaluate Early and Often：越早開始、越頻繁評估越好。雖然理論上說，這件事必須要看你們團隊採用的 Project Life Circle 而定，但說實話，即使你們採用的是 Adaptive 或用 Agile，在解決方案開發的過程中，你一定還是會發現一大堆會造成開發方向偏離的事，像是工程師突然覺得：「誒？這功能好像可以再放到另一個地方用，所以我小改一下拿去另一個專案用用好了。」這種事常不常見？只要你一不注意就會天天發生。雖然這個偏差似乎和你正關注的 Solution 無關，但可是要記得，注意力這個寶貴資源可是一不小心就會失控的。
- Treat Requirements Analysis, Traceability, Testing and Evaluation as Complementary Activities：分析、追蹤、測試和評估都是相輔相成、缺一不可的，千萬不要自作主張覺得哪些部分是可以簡化或是略過不做。但我相信經驗豐富的你，不會這樣幹的，嗯？為啥明知道你不會這樣幹還要寫？啊我不就是湊版面而已…哈哈哈。
- Evaluate with the Context of Usage and Value in Mind：要知道，一個 Solution 完成之後是要給人用的，所以你必須隨時注意 Solution 是否滿足當初所期望的用途和價值，在開發的過程中，如果你哪天忘記了這件事，有超過 90 % 以上的機率，那天做的事情幾乎等於做白工，更慘的是後面還救不回來，很嚇人嗎？不，這還算好的，就像順口的白蘭地喝多了一樣，你就會知道後勁是不是強到讓你把胃都吐出來了。
- 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 的最上面已經幫你列出七個方法(下面我把功能性和非功能性放在一起講)：
- Surveys and Focus Groups：烙一大堆或核心顧客來直接決定你生死。
- Exploratory testing and User Acceptance Testing(UAT)：隨便亂點、亂測，目的就是要搞死這個 Solution。
- Day-in-the-Life：從睡醒到晚上睡覺，用個一整天(或是好幾天、幾個月)來看看這個 Solution 能不能正常運作。
- Integrating Testing：和其他系統一起並行個好一段時間。
- Functionality and Non-functionality：功能性和非功能性和預期中想要的是不是一樣？
- 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 給我一些鼓勵：
