參考地址：http://www.dotblogs.com.tw/hectorlee369/archive/2010/04/16/14640.aspx

這篇是分享我每次談需求前會Review的手冊，當然還在加強中。

以下為鐵則，不論跟哪一種人談都需要：
1.若要推翻之前的決議不要在當下回覆，而是仔細地在需求文件中驗證其變更沒有問題。
2.不應該做無法達成的承諾。
3.不應該因討論中的衝突而閃躲，往往會變成專案的原罪。
4.需求的報告書一定要有需求單位的負責人員及主管簽名。

	前提	重點	避免
業務主管	因為主管的時間有限，而且一定不會明確又詳細的指示，故訪談的過程常會在空中打轉	1.會議結束一定要有目標的定論。 2.不斷提問區驗證你的想法與主管指示一致。 3.找出與會者可與主管同步想法的人。 4.要求主管指派單一負責窗口來談細節(不一定與2.同一人) 5.談定未來需求確認的人員、流程及文件格式及表述方式。 6.PM要注意時程、範圍、成本3重限制。 7.最好先瞭解主管的喜好，有利於討論中的緩解。 8.一般而言不需要會前會。	1.自己亂下定論。 2.若主管對自己公司的文化流程很自豪，不宜隨便給意見。
資深業務人但不懂電腦	此種類型擁有強烈的商業IQ，但看到電腦會呆掉。另外一提這種人是最最終IT人員。	1.一定要先做業務方面的功課。 2.先請他將平時的紙本作業演練一次。 3.取得他完整的紙本表單跟用途說明。 4.主動為其規劃E化流程，并相互演練一次。 5.最好有畫面和表單來配合說明。 6.之前有試過順手教他Office讓訪談進行超順利。 7.一般而言不需要會前會。	1.不應該因他不懂電腦就鄙視他。 2.不要用太多的IT語言，而是用他可理解的字彙。 3.若他邏輯陷入LOOP不該再用原本的方式說明，而考慮其他方式。 4.不該忽視特殊的例外狀況。
資深業務人且很懂電腦	此中類型是我遇過最難搞的，永遠認為自己是對的，你爲什麽做不來。	1.一定要先做業務方面的功課，不能讓他覺得你什麽都不會。 2.就事論事，談流程就直接在白板上把流程圖畫出來。 3.要確認他可不可以做決定。 4.僵持不下時，應由主管裁示。 5.最好是拿End User的需求想法來處理他的堅持。 6.用IT語言時要注意他是真懂還是假懂。 7.一般而言需要有會前會。	1.不該預設立場強迫使用者接收預先設計的內容。 2.不該有過度的情緒反應，以避免離題。 3.不該忽視特殊的例外狀況。 4.討論過程不可一味的軟或硬，而是軟硬兼施。
資淺業務人員但不懂電腦	此種類型什麽都不懂，往往也沒有什麽決定權。	1.要透過其他管道瞭解其公司組織文化。 2.先行設計業務流程及架構。 3.提出其他公司的解決方案。 4.需不斷開會加強其業務觀念。 5.需不斷確認其主管與它的想法是一致的。 6.一般而言不需要開會前會。	1.不可因為他不懂就自以為是的幫他做決定。 2.不可因他不回覆就Pendding issue。 3.不要用太多的IT語言，而是用他可理解的字彙。 4.若他邏輯陷入LOOP不該再用原本的方式說明，而考慮其他方式。 5.不該忽視特殊的例外狀況。
資淺業務且很懂電腦	此中類型很2級化，關鍵在於邏輯能力的強弱，有的自以為強，但實際反之。	1.一定要先做業務方面的功課。 2.就事論事，談流程就直接在白板上把流程圖畫出來。 3.要確認他可不可以做決定。 4.僵持不下時，應由主管裁示。 5.最好是拿End User的需求想法來處理他的堅持。 6.用IT語言時要注意他是真懂還是假懂。 7.一般而言需要有會前會。	1.討論的重點不該被他拉到IT。 2.不要預設他的邏輯能力很強。 3.不該忽視特殊的例外狀況。
系統維護人員	IT間的溝通需要明確。另外一提，通常這類人也很被動。	1.業務語言可協助討論但仍然應以技術範圍為主要。 2.要先確認維護人員的強項及弱項，以利溝通時需加強的點。 3.需先去的該公司的IT規範。 4.用IT語言時要注意他是真懂還是假懂。 5.PM對於維護性功能仍需要注意時程、範圍、成本3重限制。 6.一般而言需要有會前會。	1.若有舊系統的包袱，應該要詳細的訪談出內容。 2.不該有新技術一定最好的先入為主的觀念。 3.不可因他不回覆就Pendding issue。 4.不可忽視他的需求，不然會在驗收時找你麻煩，而且往往會動到架構。

ITPub博客

【轉載】需求訪談的教戰手冊

最新文章