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