摘要:[訪談] KRI 系統需求訪談－內省篇
以前看104的一些工作, 要求職務內容: 需求分析, 系統分析, 系統設計, 程式撰寫...
就覺得自己一定要更加倍努力, 才能達到這些要求,
但隨著年紀的增長, 發現這類神人, 已非我族類,
不是說不要繼續努力, 用這段當引言是只為了說明:
當你是需求分析師, 就暫時忘了你的其它身份吧,
雖然擁有其他功夫在需求訪談過程中某些部份是加分的,
但我個人覺得雜音比較多, 弊多於利,
而且會給User留下不好的印象: 在提需求前先要問系統做不做得到.
當User 有了這種觀念時, 要問到核心的需求就要多花費功夫了.
筆者覺得系統分析師的內功心法：
提問, 收集, 分析, 匯整, 結果.
就這幾個簡單的工作然後過程不斷的iterator，
本篇文章，以實務上的系統開發過程中的需求訪談為案例，
簡單展示如何運用這幾項工具。
情境：KRI 系統(Key Risk Indicator)開發, 已有非E化的解決方案.
<<內省篇>>
坐在客戶面前,一定要做足功課,
我們很容易聽到來需求訪談的SA,
真的是來"需求訪談",
你說我記,真的被客戶回問時,只會回答:視客戶需求而定。
1. 客戶想要的是什麼樣的SA? (提問)
要有對企業風險關鍵指標(KRI)的Domain know how, 除了聽使用者的需求外, 亦能提出建議。
2. 若我剛好是什麼都會, 也什麼都不會的SA, 這時不要亂, 老臣就是會一些撇步. (收集)
先到 Wiki 對KRI有點了解, 然後到一些風險管理的"學會"找相關文件, 還可以到一些做產品的公司查相關文件.
3. 要找到問題才能做分析, 所以幾個基本的問題, 如:
一般企業為什麼要導入KRI，KRI有什麼好處,劣處，KRI的參與者有那些，層級分別是?
4. 把自己提問, 收集, 分析的結果寫成一份讀書報告, 最好加上心智圖。 (匯整)
5. 分享自己的文件，並簡報予PM，加強對Domain的了解, (結果)
如果是走DDD, 這時也會有高階的Domain Model。
字彙集最好也先編一下, 可以當做未來的UL (Ubiquitous Language)。
這裡舉一個例子 http://www.openpages.com/solutions/KRIs_24.asp
我們會對什麼感興趣呢?
Early : 提早, 是多早? 怎麼確認他夠早.
Warning Signals : 警告訊號, 要量化, 要分級, 要如何示警, 要怎麼知道示警正確.
Risk Events : 風險事件, 怎麼描述, 實際要量化的關鍵.
organization’s risk profile : 風險事件的pool, 是多年來過去經驗的收集, 需要過濾及評選.
helping the business to reduce losses and prevent exposure by proactively dealing with a risk situation before an event actually occurs.
這句是整個系統的願景.
Operational Risk Management : 出現一個可能的邊界物件,
highlighting trends and changes in risk levels : 除了訊號, 還需做趨勢分析, 系統可能有大量圖表, (要去study報表工具)
processes : 事件成為risk 成為key 以至於變成訊號的過程, 過往經驗若客戶目前沒有執行中的方案, 可能會要求我們提出建議的方案.
linked to multiple risks and controls : 這背後應該有公式和方法論, 如果無法習得關鍵方法, 應該要建議公司找顧問進入此案, 提供專業的意見, 更重要的是, 要告知PM並由業務對客戶提出相關報價.
PS. 如果在公司沒有能力包案, 但客戶很勇敢給案, 你又很幸運地要join,
提問自己有沒有能力接, 如果有, 要去那上課, 時間上可行嗎. 如果沒有, 要去收集104, 1111人力銀行們的資訊了 :P