【系統分析】需求訪談，出問題時會需要專案經理的介入－TomWang的部落格

進行需求訪談時，溝通對象有時會決定著成敗

需求訪談最好的狀況是溝通對象說甚麼，照做就對了
(執行順利，驗收也順利，大家都高興，唯一的問題頂多是系統分析師的價值可能會受到質疑)

根據我的經驗，提需求的人往往不太清楚自己到底要甚麼
如果他說甚麼你照做，最後可能變成他在抱怨你做的東西不能解決他的問題
你抱怨都是依照她說的做，他可能會找些理由來推責任(例如怪你不會多想想)

理想的對應方式是系統分析師去搞清楚對方為什麼要這樣的功能
釐清對方邏輯與認知上的錯誤
替對方設計與決定這系統該長甚麼樣子，藉此讓系統能夠真正滿足對方的需求

但是這麼做會變成
1.要提出需求者承認自己認知有誤
2.提出需求者需要花更多時間思考與確認

不是每個溝通對象都能夠配合，如果對方不願意配合
我想這種問題的處理就已經超越了系統分析師的職務範圍，應該要專案經理介入處理．．．。

一般需求不明確時，工程師第一個怪系統分析師這個角色的人，但有時不是單純的因為系統分析師能力不足。

我以前參加過一次資策會的系統分析課程
當時有做個練習，
有個科技公司因為新人報到到能正式工作的流程時間太長，所以想找人開發個系統解決問題
學員們會分組扮演要標案的廠商
講師會扮演三個角色，每組可以向其中一個角色提問
回答問題的只會回答問的問題

這個練習題目有個關鍵問題是：「為什麼原本時間太長？」
整個流程牽涉到不同部門，到底哪邊有問題也不明講
我認為比較合適的做法是：安排一個會議「討論出問題原因」，而系統主要針對這問題原因進行修正
當時練習的困難點是一次只能跟一個角色進行訪談，而且有訪談次數的限制
也就是如果有人推責任，那連系統要怎麼解決問題都不知道了，更別提要滿足需求。

系統分析師可以提出一起開會這個要求，但是對方不一定要甩你，甚至就算人到也可能亂搞。
這時需要有地位的人(像是專案經理)介入來處理...
當然，如果整個需求是丟給程式設計師自己去搞定的話，大概就更慘了