2013年3月20日

第7章-講座中的Q&A

    

        很少人會在演說之後提問;同樣的,對那些願意在演講會中舉手的人,我們就應該無條件稱讚他們的勇氣、好學、好奇心。
    光是有勇氣舉手發言其實就已經不錯了。「發問本身就是一股力量」

節錄自《開口就能說重點》

「發問本身就是一股力量」,我非常喜歡《開口就能說重點》一書作者的這句話,無論聽眾的問題多麼模糊、無趣、惱人或具挑戰性,其實都帶著一股力量,而且是需要被鼓勵與尊重的。

***

問答可以提高聽眾的參與度
總歸來說,IT人員在台上進行分享或講授的過程中,適度安排一些問答,可以有下列多項好處:

  • 提高聽眾的參與度
  • 強調重點
  • 打破唱獨角戲的局面
  • 刺激聽眾思考
  • 確認聽眾的理解情況

問題可能引發新解
前面談的是講者主動提問,聽眾被動思考並回應的情況;現在,我們反過來談另一種情況是,聽眾主動提問,講者回答問題。有些講者喜歡挑戰新問題,總是歡迎聽眾丟出一堆奇奇怪怪的問題;有些講者防衛心較重,比較不喜歡聽眾拋出自己事先沒準備的問題。
不過,我總是認為,所謂的「教學相長」不就是這樣磨練來的嗎?講者在第一時間點,應該要能夠承接的住聽眾拋過來的各式怪異問題,不要逃避。講者可以在現場跟聽眾一塊討論問題,引發一些新的想法、看法、說法、做法、解法,這也算是一種有實質回饋的教學相長啊!
講者在現場遇到沒思考過的問題,可以跟著台下聽眾一塊討論,這時講者不是沒事幹,而是要主持整個討論過程,包含:控制時間、分派發言權、引導討論過程,同時要不斷聚焦並且做些適度的整理和回饋,最後還要總結這個討論,如圖7-1所示。

7-1:主持討論

時間是所有聽眾共享的
講者不畏懼新的問題,也能夠把問題拋給聽眾,帶領大家思考,這是非常棒的一件事。唯一需要特別提醒IT人員的是「時間是所有聽眾共享的」,所以要特別注意整個問題的討論時間,以及個別聽眾的發言時間,否則可能會冷落了對這個問題不感興趣的其他聽眾,或者讓對這麼問題有興趣的聽眾沒有發言的時間。
還有另外一種情況是,某一位聽眾頻頻舉手要求發言或發問,或者只要一開口就口若懸河地說了一大堆。《有聲有色做溝通》的作者建議遇到這種狀況時,不要將目光停留在這位聽眾身上,這樣對方就無法發言了。

當你發現看起來坐立不安、急於插嘴或表示異議的聽眾(說不定會把手伸出來)時,不要把注意力放在他們身上,也不要目不轉睛看著他們,因為一旦你直視他們,他們就會以為你允許他們發言。所以,如果你不想受到干擾的話,就將目光移向別處。

節錄自《有聲有色做溝通》

不過,若是這位聽眾舉起手來,一直揮動的話,講者就得處理一下了,不然不只會干擾到周遭的聽眾,也會干擾到在台上講者的表達氛圍。況且,講者如果一直不理會的話,也會形成一種漠視,有些聽眾可能會開始同情欲發言的聽眾,因而認為講者不夠尊重台下聽眾的發言權。
遇到這種情況,在台上的IT人員要懂得適度安撫急著發言的聽眾,並且將這位聽眾引導到中場休息時間才來聊聊,這樣可以只佔用到講者以及有興趣討論的聽眾的時間,而不會一次佔用到大量的講堂時間,並且讓其他不感興趣的聽眾覺得無聊甚至浪費時間。舉例來說,講者可以做這樣處置,如下:

    李大任已經發言多次,佔用了許多時間,現在又舉起手來要求發言了。
    這時,講者伸出手來請李大任把舉高的手先放下,接著說:「我想,我有一點時間壓力,剛才我們花了太多時間討論,我開始擔心課題會講不完。所以,現在就先不讓各位發言了,等一會兒中場休息時間,有問題的聽眾再來找我討論。」
    李大任聽了講者的話之後,就識相地暫時放下高舉的右手。

不要迴避問題
對了,千萬別迴避問題,也別口頭說休息時間要討論,但是卻沒有真的付諸實行。聽眾是很聰明的,眼睛也是雪亮的,會聽得出來講者在迴避問題,也會看得到講者在敷衍聽眾。講者要說了休息時間討論,那休息時間一到,就應該趕緊去跟剛才那位聽眾談一談。
如果,講者遇到過去沒思考過的問題,千萬別迴避問題。有些問題,可以拋回台下與聽眾一塊討論,若需要更多時間的討論,就可以結合前述的圖7-1適度主持一場討論。總歸來說,講者遇到無法回答的問題,大約有下列四種因應方式,條列如下:

  1. 現場大家討論-多數聽眾會感興趣、且無固定答案的問題,可以現場花一些時間討論,這時講者要主持討論,不要只是一言不發地讓聽眾自己去討論。
  2. 休息時間討論-可能只有發問的聽眾或者少數聽眾才感興趣的問題、且無固定答案的問題,可以邀請聽眾中場休息或講座結束後再來討論。這樣才不會把其他不感興趣的聽眾晾在一旁,白白花費了多數聽眾的時間。
  3. 現場詢問答案-多數聽眾會感興趣、且有固定答案的問題,講者可以先徵求現場聽眾的答案。若現場沒有答案,講者可以回家做功課、找答案,再把答案補寄給聽眾。若現場聽眾有答案,講者還是要回家確認一下,不要白白失去一次找尋答案的機會,況且,下回還是有可能遇到相同的問題。
  4. 事後補寄答案-少數聽眾會感興趣、且有固定答案的問題,就不需要詢問其他聽眾的答案,直接承諾事後會補寄答案給聽眾。

挑選問題的準則
如果,現場的問題很多,講者要懂得四兩撥千金,具體明確、攸關眾人的問題,可以直接回答。其餘問題,諸如:描述的模糊不清且無法立即釐清的問題、只有特定少數聽眾關切的問題、或者根本就是講者自己認為重要、或是講者自己專精或有興趣的問題,這些問題都可以押後,空檔或中場休息的時候,再來談論。
最後,歸納一下,當現場的問題很多時,IT人員要當機立斷,每一個問題過來,先判斷是否要立即回答,建議優先回應下列問題:

  1. 描述具體明確的問題
  2. 多數聽眾攸關或有興趣的問題
  3. 很多聽眾會誤解的問題

整理出問答集
針對聽眾常問的問題,講者可以在講座後整理成「問答集」,或者在簡報最後的Q&A處,直接羅列常被問到的問題。像我自己的例子,我就發行了兩集名為《UML答客問》的電子書,裡面就整理了常見的一些問題。再者,我也會在簡報的Q&A部分,把我曾經被聽眾問過的問題和討論,一一羅列出來,講座如果有空檔就拿出來講,沒空檔就讓聽眾帶回家自個兒看。

回應問題5步驟
其實,講者沒耐心地遽下判斷,跟有耐心地聽完聽眾說出盤根錯節的問題,兩者是一樣有改善空間的。先說第一種狀況,講者沒有耐心聽完聽眾的問題,就輕率地遽下判斷,以為自己對問題早就瞭若指掌,立即劈哩啪啦回覆了一堆。這很可能會出現下列窘境:

  • 沒聽完聽眾的問題,所以搞錯重點,答案沒有搔到癢處,甚至答非所問。講者可能會因此失去了人氣,同時講者和聽眾也可能失去了一個好問題的討論機會。
  • 講者展現出過於強烈的自信與優越感,可能會引發部分聽眾的反感,嚴重一點的話,可能會不再願意敞開心胸接受講者的論點。
  • 講者雖然展現出滿滿的自信,卻因此忽略了對聽眾勇敢發問的尊重和鼓勵,可能會讓聽眾受挫,不再好學、好奇並主動發問。

至於,第二種狀況,雖然講者展現出無比的耐心聽完迂迴糾纏的問題,但是如果講者沒有協助聽眾整理、釐清並引導出真正問題所在,那也沒用。只能說講者可能太過軟弱、沒有主動主導全場,或者是經驗不足、不懂得協助聽眾找出真相。
總歸來說,無論是第一種狀況,還是第二種狀況,我都會建議IT人員可以依照圖7-25個步驟來回應聽眾的問題。

7-2:回應問題5步驟

此處,我們先來簡單解釋一下這五個步驟,稍待一會再來做一些示範,說明如下:

  1. 傾聽-講者要用心傾聽聽眾真正的問題所在,不要只是聽到表面的現象或問題,就遽下判斷。這樣輕率回覆的答案,有時會讓聽眾覺得講者沒有真正理解問題所在,或者誤以為講者的功力和程度爾爾,所以才會無法講到重點。
  2. 簡述-講者傾聽完聽眾的問題後,必須使用自己的話,整理並簡述問題,讓問題可以更具體明確,並且便於跟聽眾確認問題。如果,遇到喜歡長篇大論的聽眾,一定要在適當的時機先中斷,然後簡述一下聽眾的語意或問題,必要時,也可以先行回覆。
  3. 澄清-對於聽眾問題中一些模糊、不明確、多意涵的詞彙,可能都有必要做進一步的澄清,這樣才能在一片模糊的描述和情境下,辨識出聽眾的真正問題。
  4. 確認-講者不能一心以為自己抓到的問題,就一定是聽眾真正的問題所在,所以一定要先經過確認。一旦,辨識出問題之後,講者可以先簡述問題,然後向聽眾確認。
  5. 回覆-講者在回覆問題時,盡量把握住明確、具體,先簡答,再詳解。回覆太長的話,最好還能做重點整理與回顧。最後,講者別忘了跟聽眾確認這樣的回覆,是否有回答到問題的重點、是否有解決他的困惑、或者是否對他有幫助。

在實際運作上,回覆問題前的傾聽、簡述、澄清、確認這4個步驟,經常是混在一起運作的,不需要嚴格遵守順序。再者,這5個步驟這樣說起來簡單,要真正落實在工作或生活中,其實相當不容易。IT人員別忘了提醒自己,隨時隨地做練習,這樣不僅對表達有幫助,對人際溝通也很有幫助的。
最後,我們來做一個簡單的示範,如下:

    程又清舉起手來,講師看到了,便示意著說:「有問題?請說。」
    這時,程又清說:「老師,您剛才說參與者是位於系統外部,而且會與系統互動的實體。』然後又說『參與者常見的種類有:人類用戶、其他系統、外部資料庫、外部服務、硬體設備。』所以,只要是位於系統外部,而且會與系統互動的實體,通通都是參與者。還是說,除了位於系統外部、會與系統互動外,還必須符合剛剛說的那五大類,才能是參與者。

聽眾一連串說了一堆,所以講者可以先制止聽眾往下說,先做局部澄清,再讓對話繼續下去:

    講師說:「我先澄清一下。」
     「『參與者是位於系統外部,而且會與系統互動的實體。』這是參與者的基本定義,換句話說,參與者必須滿足兩項特點:一、位於系統外部;二、會與系統互動。」講師繼續說著。
     「再來,『參與者常見的種類有:人類用戶、其他系統、外部資料庫、外部服務、硬體設備。』這只是UML規格書上對參與者的描述,不是定義,所以參與者要是不在這五個種類中,也是可以的。」

        講者在做完澄清之後,再把發言權丟回給聽眾,如下:

    講師說:「好,我的澄清完畢,所以您剛才要問的問題是?」
    在講師的示意下,程又清再度開口說:「喔,我懂了,沒問題了。」

即便,講者誤打誤撞回覆了聽眾的問題,也要請聽眾做簡短的回饋,否則其他聽眾甚至是講者,可能會處在莫名其妙的一頭霧水當中。我們繼續來看範例接下來的發展:

    講師俏皮地說:「喔,換我不懂了,您本來的問題是什麼?」
    程又清呵呵笑,她說:「我本來是要問如果考題中出現的參與者符合,位於系統外部而且會與系統互動這兩項特徵時,其實就有可能是參與者,不一定要是人類用戶、其他系統、外部資料庫、外部服務、硬體設備這五類之一,是嗎?』」
    「所以,答案是?」講師鼓勵程又清繼續用自己的話,來把這個問題整理一次,做一個總結。
    程又清說:「

        針對聽眾的問題或許就這樣結束了,但是講師還可以順勢補充一些觀念,讓聽眾從這個問題學到更多。

    在程又清做完總結之後,講師接著說:「針對UML初級認證考試的話,您們要記得參與者的這兩項特徵,以及UML規格書上描述的這五個常見的參與者種類。」
     「而在實務應用上,系統分析師在找尋參與者時,一開始可能不知道要從何處下手,這時,別忘了UML規格書提醒我們的,可以先去找找系統外部的人類用戶、其他系統、外部資料庫、外部服務、硬體設備,看看這其中有哪些實體會跟系統產生互動的,這些實體就很可能是重要的參與者。」講師補充了實務上的經驗和知識。
    講師一口氣把這個實務經驗補充完畢:「另外,如果系統分析師找到了這五種以外的參與者,也別忘了回饋給公司和專案團隊,提醒其他的系統分析師也可以注意這一類的參與者。」

***

        講座或課程結束時,詢問聽眾有沒有任何問題,似乎已經是慣例,就跟演唱會結束時,台下粉絲一定要大喊安可一樣。如果講座結束時間已經到了,那不妨就順勢結束講座;倘若還有一段時間才到尾聲,也不適宜立即結束的話,那講者也可以說:「各位都沒有問題,那我來請問您們一些問題。」開啟一小片段的Q&A,當然,講者一定要隨時備妥口袋問題啦!

沒有留言: