今天在與團隊成員溝通過程中，有人提了一個問題：現在團隊的開會是不是有點多？

現在會議或者說討論會，確實有些偏多，特別中層管理者被拉入了很多討論會議中。對于這個疑問，我相信團隊中的很多人都會有。我當時簡單解釋了一下，但是事后，感覺當時解釋的還不夠清晰，于是寫這篇心得補充完善一下。

現在我們這個ZX團隊正在從一個“小作坊”戰隊形式轉變為“正規軍”形式。（很多人會說，我們要保持敏捷小團隊，這是一個誤解。轉型為正規大團隊并不是意味著不敏捷，不高效）。正規大團隊，不僅要繼續保持高效，還必須在高效的情況下，保持穩定、保持可持續。那就必須形成一套適合團隊自身的“運作結構”以及配套的各種流程、機制。

一年多前，我們還只是一個不到十人的小團隊。那時候不需要任何管理機制，僅憑借“快速溝通”和“緊密配合”，很多事情，三言兩語溝通完就卷起袖子開始干了。但今天我們已經是一個四五十人的大團隊了，要讓幾十個人朝著一個目標高速前進，唯一個方法就是“規范化、流程化、標準化”，俗稱“正規化”。（一提到“正規化”，大家本能反應就是“效率低下”。這是一個誤區，也是一個錯誤的認知。今天我們實行了幾個月的“版本迭代計劃”，就是“正規化”的體現，執行效率并沒有降低。）

但是，很不幸，我們原來沒有任何“體系化的積累”，也沒有形成一套自我合適的“正規化”體系，甚至我們周邊可以借鑒的也沒有 （同集團內的兄弟公司中，我們已經算是較為規范化在做事了，但依然遠遠達不到“正規化”的高度）。

從“小作坊”形式轉變為“正規化”形式，唯一的方式就是“宣講、溝通、演練、總結”這樣的反復循環、反復嘗試、反復總結，在這個過程中，各種討論、各種會議是必不可少。

舉個近期的例子，來和大家講解一下“規范化”和“小作坊”的區別
最近我讓Server團隊著手梳理“實時監控項”。
第一次先找了葉凱溝通，跟他講解了 梳理實時監控項的目的，讓他安排下去，我只提了要“梳理全”。葉凱組織Server團隊開會，講解并安排下去了。
三天之后，當各個模塊負責的研發把梳理的結果呈現在wiki上時，就暴露出非常嚴重的問題：
1、研發同學全部是按照“系統實現的接口”順序一個個梳理的
2、梳理的內容很多，但是卻很難直觀的判斷“監控項”是否完備了，是否能夠覆蓋真正的業務過程了

第二次我找了葉凱溝通，指出研發同學在梳理過程中的問題，要求他，讓研發必須依照“業務、實現組件、監控項”這種層次化的結構來梳理，而且是圍繞“業務流程”的。同時要求一些關鍵的業務，必須有業務流程圖或者序列圖，之前沒有的，這次必須補上。葉凱安排了黨同學（負責用戶系統）先嘗試按照這個模式梳理，當然這里面包括葉凱與黨同學的溝通。

黨同學在重新梳理過程中，與我有過2次溝通。準確講是我依據自己的理解，對黨的梳理結果進行了Review并提出改進要求。

第三次我找了葉凱溝通，讓其看了黨同學重新梳理的業務化的實時監控項，并告訴這么做的價值意義，特別對后續完整性檢驗的價值。并要求其安排下去，讓所有研發重新按照新的格式和方法重新梳理。葉凱再次組織所有研發人員學習黨同學完善后的整理格式，并安排重新進行梳理。

2天之后，葉凱組織所有Server研發對梳理的結果進行Review。其中發現一部分同學的個別模塊梳理沒有按照規范執行。安排這些同學重新完善。

接下來，我還需要對這些進行再次Review，并且找Server和運維負責人，執行上線前對監控想審核的機制和規范。估計還需要幾次溝通和討論。

看看上面，這么一件“監控梳理”規范化的事情，最終經過了至少10次以上溝通、討論。今天為了達成這樣的規范，所進行了多次溝通和開會，就是為了在未來不再開會，不再討論，只需要遵循規范的執行。大家只要遵循規范，就能夠有意識的在實現業務系統過程中，完善監控。

今天，我們缺少太多這種的“規范”和“機制”。所以我們不得不需要額外非常多的“溝通和討論”會議來確定規范，推動大家認識規范，遵循規范。