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。這些方向都只是方向而已,裡面的內容要看各公司自己的定義。