hectorlee369

前題

重點

避免

業務主管

因為主管的時間有限，而且一定不會給明確又詳細的指示，故訪談的過程常會在空中打轉

1. 會議結束一定要有目標的定論。

2. 不斷提問去驗證你的想法與主管指示相同

3. 找出與會者可與主管同步想法的人員

4. 要求主管指派單一負責窗口來談細節(不一定與2.同一人)

5. 談定未來需求確認的人員、流程及文件格式及表述方式。

6. PM要注意時程、範圍、成本３重限制。

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. 不可因他不回覆就Pedding issue。

3. 不要用太多的IT語言，而是用他可理解的字彚。

4. 若他邏輯陷入 LOOP不該再用原本的方式說明，而考慮其它方式。

5. 不該忽視特殊的例外狀況。

資淺業務人員且很懂電腦

此種類型很２極化，有的超Nice，有的超機車，而關鍵在於邏輯能力的強弱，有的自以為強，但實際反之。

1. 一定要先做業務方面的功課。

2. 就事論事，談流程就直接在白板上把流程圖畫出來。

3. 要確認他可不可以做決定。

4. 僵持不下時，應由其主管裁示。

5. 最好是拿End User的需求想法來處理他的堅持。

6. 用IT語言時要注意他是真懂還是假懂。

7. 一般而言，不需要開會前會。

1. 討論的重點不該被他拉到IT，而是針對業務討論。

2. 不要預設他的邏輯能力很強。

3. 不該忽視特殊的例外狀況。

系統維護人員

IT間的溝通需要明確。另外一提，通常這類人也很被動。

1. 業務語言可協助討論但仍然應以技術範圍為主要。

2. 要先確認維護人員的強項及弱項，以利溝通時需加強的點。

3. 需先取得該公司的IT規範。

4. 用IT語言時要注意他是真懂還是假懂。

5. PM對於維護性功能仍需要注意時程、範圍、成本３重限制 。

6. 一般而言，不需要開會前會。

1. 若有舊系統的包袱，應該要詳細的訪談出內容。

2. 不該有新技術一定最好的先入為主觀念。

3. 不可因他不回覆就Pedding issue。

4. 不可忽視他的需求，不然會在驗收時找你麻煩，而且往往會動到架構。