原創不易，求一鍵三連
彙報是「向上管理」和「橫向資訊傳遞」的一部分，雖然逃不掉，但很多同學比較抗拒，其原因可能是：
- 沒準備好
- 對自己領域不專業
- 近期產出不行
- 不知道怎麼彙報
底層原因是怕被質疑：
專注領域認知不足、沒有超過leader或表達不清楚，是很容易被質疑的
其實工作彙報的本質是「個人舞臺秀」，是為數不多的資訊輸出口，利用得宜會很好的提升個人影響力和團隊勢能。
所以工作彙報其實是一次機會，但多數同學卻抓不住，工作彙報做得一塌糊塗，遺憾啊！
我剛好彙報一塊也做的很差，正好可以跟大家交流怎麼失敗。
彙報的認知
彙報的型別
評價彙報型別只有一個形容詞：「正式程度」
政府類彙報不能扯犢子，但公司類彙報正式程度邊界很模糊，這裡的點是：
1）「偏正式彙報開始不要扯犢子」，容易翻車；
2）非正式彙報也是彙報，內容不要全是水；
就我經歷的彙報有：
- 閉門專案彙報
很正式，需要聚焦到具體工作卡點展開，向Leader求助，認真對待，別扯犢子；
- 公司級部門工作彙報
偏正式，各部門負責人對CEO做工作彙報，其實就是各種秀自己部門多牛逼；
- 部門級個人工作彙報
偏輕鬆，可能是直接與Leader一對一進行彙報，也可能平級同學一起開彙報會；
- 升職彙報
偏正式，這是對個人比較重要的述職報告，需要清晰的把肌肉全部秀出來；
所以，除了專案卡點彙報是Case By Case的方式，其餘彙報都可以有相對通用的模式。
彙報的精髓
在彙報的時候，很多同學為了給自己乃至團隊謀福利，喜歡「誇大產出，縮小缺陷」。這種“偷雞”行為在低端局或許有用，在高階局基本沒用了......
到一定階段後，Leader對你的情況會非常清晰，不會因為一次的彙報有什麼根本改變，你要做的是用這次彙報「打破他對你的認知」！
這裡的精髓有兩點：
- 「真誠」
真誠的「剖析自己」，將自己的「缺漏和不堪」，「血淋漓的拿出來給Leader看」，你需要告訴他，自己的問題已經很清楚，並且已經站在更高維度自我審視，自我解決。
這是一種敢於扯開自己遮羞布的行為，能夠「放下無畏自尊」的人是令人畏懼的，因為你不知道他能走多遠，一旦你對自己坦誠，那麼Leader就會對你改觀，他會認為你有更多的可能。
- 「差異化」
差異化是一種「創新」，比如別人用文字，你做PPT；別人做PPT，你做視訊；別人做視訊，你做脫口秀；別人......
舉個例子，在部門彙報會上，我上一個自黑的視訊，其效果技驚四座：
水月兩忘軒差異化視訊號（傳不上來......）
建立彙報的基本認知後，我們開始進入彙報內容。
彙報的內容
內容結構
我使用的彙報結構如下：
- 自我介紹
- 概述
- 兩個案例（也可以三個）
- 昇華
- 致謝
自我介紹和概述需要快速過，彙報內容核心是「案例」和「昇華」。案例是大家認可你的點，昇華是大家覺得你能走更遠的依據；一個是對過去的認可，一個是對將來的期待。
概述開啟
雖說概述要快速過，這裡還是要描述一下，因為案例裡面也會出現類似「概述」內容，概述不是羅列一些無意義的名詞和數字。而是要讓這些大詞變得有「生命，可下鑽」。
舉個例子，如果彙報業務線一年的BUG情況，可以這樣：
1）先說全年出了多少BUG，每個月的BUG量這種最常規的表述
2）然後從每個月「異常」BUG開始深鑽，比如這樣：
3）其後可以按埠case（前後終端）分析，這樣就可以得出什麼型別專案容易出什麼型別的case
4）然後可以細化到功能模組
5）......
這樣深鑽後，大家知道了全年的case情況，也知道了有什麼樣的case，什麼埠、什麼專案容易出什麼樣的case。
然後再將一兩個大家特別印象深刻的case作為案例說明，整個概述就比較立體了。
兩個案例
一般是一大一小兩個案例，案例一般由「發現問題開始」，工作中遇到了什麼問題，在解決這個問題過程中形成了案例，最後問題解決沒有，怎麼證明他解決了，解決到什麼程度，這些就是案例的核心內容。
其中大案例要足夠幹，「足夠給力」。
如果是技術述職，那麼這個大案例可能是你做了什麼牛逼的框架，多少團隊使用了這套框架，提升了多高的效率；
如果是業務述職，可能是你做了一個什麼樣的專案，形成了什麼樣的體系，補足了公司什麼樣的缺漏，獲得了什麼樣的財報資料；
一定要注意案例相關的資料要準確、要有證據鏈，如果出現明顯的造假，那大概就黃了......
大案例出來要震驚四座，擁有絕對的說服力。
小案例要做「差異化補充」
什麼是差異化補充，比如大案例說的是專案，小案例可以說團隊管理；大案例說的是框架專案，小案例就說業務貢獻。
做技術牛逼，做業務也牛逼；做業務牛逼，做管理更是一把好手，類似這種人才會很受喜歡。
兩個案例結束至少80分，案例足夠厚重，後續只要不作死，價值觀不出問題就好，但類似於升職報告會有一個排序，排名當然是越高越好，所以昇華部分必不可少。
昇華
前面已經說了案例是Leader（彙報物件）對你過去的認可，昇華就是他對你「未來的定位」。
案例是實的、既定事實，很難說出花；昇華是虛的，認知感悟，你吹上天都行，但個人建議適可而止。
所謂昇華，多是工作過程中不斷提升認知形成的一套方法論
你需要將方法論展示出來，讓Leader或者評委「推敲、質疑、探討」。
這裡直接按照「金字塔模型」即可：
- 提出你的觀點
- 簡述幾個核心論據
- 對某個核心論據再論證形成證據鏈
- 將這套方法論應用到其他案例，證明可以橫向適用
這裡舉個例子：
如果我在昇華部分簡述的觀點是「大Leader不能下場帶專案」
那麼我就要證明這樣會有什麼問題，這裡可以是：
1）大Leader下場是搶下面同學的活幹，下面Leader吃不到經驗，梯隊會出問題
這裡接下來就可以舉例，如果後續連續5個專案過來，其他Leader由於沒有經驗，全線拉胯。
2） 大Leader下場是「做簡單的事情」，因為小Leader也能做，而人精力有限，那麼他本質工作一定沒做好
這裡接下來可以舉例，大Leader應該做的外卷類工作沒人做，整個部門沒有新的資訊輸入，沒有新的戰略提出，完全陷於內捲旋渦。
當然，我們這裡的觀點也可以是「大Leader需要下帶做專案」
1）大Leader需要做專案，形成一套方法論，以提升整體效率
這裡的論據可以是方法論落地後，後續的效率提升多高；
2）大Leader做專案，可以提升團隊的向心力
做專案拿結果是提升勢能的最好辦法；
所以，觀點沒有絕對對錯，端看你的論據是什麼。
昇華後會面對Leader或評委的發問，這裡比的就是認知體系了，只要你的認知體系是閉環的，他的問題你就會有判斷。
如果這個問題你完全沒概念，那麼就是他的問題已經超出了你現有認知，這個時候沒有太好的辦法。
確實不知道，就說下來思考，不用強行回答。
結語
我們首先在認知層面知道了彙報其實是一個「向上管理」和「橫向資訊傳遞」的工具，「表面上」他直接決定了個人乃至團隊的收益
但經過深入研究後，我們發現Leader或同事判斷的核心依據是「已發生的案例」，在彙報前他們已經有了最基本判斷，彙報好壞只會對結果產生「少量偏移」，所以收益其實與彙報關係不大。
彙報主要是給你一個舞臺，讓你有打破「他們對你的認知」，以便你在未來能「獲取更多的機會」。
所以彙報其實是挑戰更優秀的自己，要有自我重新整理的覺悟，比較好的方式是：
真誠的面對自己，血淋淋的剖析自己的錯漏給大家看，並告訴大家自己是怎麼解決的
在操作層面，要做到差異化，這裡的核心是創新，但確實找不到創新點的話那就「迴歸真誠」即可。
瞭解到彙報的本質和彙報應有的心態後，介紹了自己常用的彙報結構：「概述、兩個案例、昇華」以及表述方法論，「金字塔模型」
有了這些認識後，彙報應該不會做的太差，但依舊有一些核心坑點要說明一下：
1）「切莫自說自話」
這是個非常典型的錯誤，比如我作為技術老大在公司彙報上給他們說前端框架，給他們說微服務，給他們說DevOps，這些都是「雞同鴨講毫無意義」。
另一個稍好一點的錯誤是，大篇幅介紹「團隊內部體系搭建」
除了上下游團隊，沒人關注你們部門內部做了什麼，就算做出花來，我也不想關注，因為跟我沒有一毛錢關係。
如果非要把自己的事情說出來，那麼這件事一定是「多數人有感知的」。
比如我開發了一套系統，提升了公司多大的效率，解決了哪些部門什麼樣的痛點，這裡介紹的是大家有感知的專案本身，不是介紹專案的技術選型、框架設計！
2）「切莫自怨自艾」
一些同學，容易將彙報工作變成一個「發洩渠道」，甚至演變成「比慘現場」。
沒人關注你推動專案如何難，也沒人關注你在過程中有什麼心態變化，你的思考在部門內覆盤即可。沒人想了解你的心路歷程，除非你提出了一套方法論去解決這類問題。
比慘這種元素也不是完全不能有，尺度合適或能有其實就好。
3）「不要狡辯」
如果有人明確的提出了你彙報的錯誤，除非他肯定是錯的，否則不要狡辯，大方承認就好，記得彙報主旨是向上管理和資訊透傳，其實也是一個「建立人設的場合」，對自己真誠一些，不要當槓精。
4）「切莫當噴子」
尤其是公開的彙報場合，不要負能量、不要做噴子，不要兩句話就是這個事情沒用，所以沒必要做。
有沒有必要不是你判斷是你Leader判斷的。
5）「思維混亂」
還有一類同學彙報過程中思維混亂，這種要麼「沒提前準備」，要麼就是「能力不行」，一個是態度問題一個是能力問題，無論哪一個你都不會好過。
6）「粗獷的彙報」
我是見過有人拿著記事本去彙報並且依舊十分出彩的，但請不要這樣做，老老實實準備PPT吧，這不是差異化，這是作死。
.......
好了，今天的內容就到這，希望對各位有用，最後求分享！！！