上周開會時,我請同仁回去重新整理資料再私下找我討論。這對我來說,已經是比較嚴格的指正了。
事情是這樣,最近預計導入新系統功能。週會報告時,同仁說經過種子學員測試後,發現系統有問題,要推遲系統上線的時間。我心想,怎麼可能有問題,在測試前我已經跟負責同仁順過重要功能後才進行下一步種子測試,怎麼會有問題?
同仁說的含含糊糊的,於是我請同仁把測試紀錄打開,我一個一個看回饋到底問題出在哪裡。
當我把前幾個看完時,我跟負責同仁說:這是種子的期望,不是系統本身的問題、按鍵是亂碼,這早就反映給系統商了,所以也不是系統問題、這是權限設定,也不是系統問題。我總結到:那你覺得哪裡是系統問題?對我來說系統問題是重大流程功能才是系統問題。因此,我請她把所有回饋分類後再跟我重新討論一遍。
你可能會覺得,是我太武斷了。難道主管覺得是系統問題才是系統問題嗎?主管怎麼不接受員工的想法呢?
其實我不是故意要刁難他,而是要給他學習分類與重新組織資訊的機會。
在會議中進行口頭報告時,我們不能把獲得的「資料」一字不漏的陳述出來。因為會議的場合是要讓主管做決策或是掌握專案進度。因此你應該表達的是加入自己的理解,甚至是具備論據的「資訊」。
主管的角色就是故意挑戰你的觀點,看你說法是否真實以及符合邏輯。這其實就考驗了你對於事情的掌握與理解、用心程度。如果你說的支支吾吾,那代表你連自己的訊息都沒有消化過,那報告怎麼說服別人呢?
最近看到劉潤文章中重談結構化能力的重要性,剛好又能讓我拿來當教材。劉潤說:
「人與人之間的差距,有時就是結構化的能力。同樣一件事情,能結構化思考和表達,可以節省雙方更多時間,提高效率。越高階的管理者,越優秀的人,越重視結構化的能力。」
那麼我們在會議中,要如何具有結構化的進行口頭報告呢?
他引述《結構思考力》一書中論、證、類、比的技巧:
結論先行在工作、報告、溝通中,先提出結論,讓對方迅速抓住核心內容。結論先行有助於突顯重點信息。心法是:先框架後細節,先總結後具體,先結論後原因,先重要後次要。
以上統下提出結論後,需要提供支持結論的依據和論證,否則主管還是不會買單。這種以上統下的方式有助於建立完整的邏輯結構。有些人一眼就可以看出問題,就是看邏輯,看結構是否一致。
歸類分組歸類分組,也是為了提高效率。否則一下子說太多別人也記不得。將資料整理成「相互獨立、完全窮盡」的3-5個類別,以提高效率和記憶。
邏輯遞進結構化思考和表達除了提高效率,還為了目標和目的。運用邏輯遞進的方式,如:時間順序、結構順序和重要性順序,以有效組織和表達信息。
因此這位同仁可以重新的說:目前系統已經完成種子學員的測試,但因為有幾項重要的回饋,建議延後系統上線的時間。第一,同仁許願的功能可能會影響使用者體驗,跟系統商確認是否有評估相關功能開發。第二,權限設定需校對,不同的同仁出現不同權限。第三,部分按鈕仍是亂碼,尚未修復。以上將與系統窗口討論後再回報結果。
結構化的口頭報告,除了能夠幫助自己整理資料、整理思路外,更可以幫助對方快理解你的陳述,甚至同意你的觀點。還有,對你處理業務的能力加分。