文章首發於公眾號松花皮蛋的黑板報,作者就職於京東,在穩定性保障、敏捷開發、高階JAVA、微服務架構有深入的理解

有些程式設計師其實不愛和技術領域外的人過多交流，包括上級領導，很煩他們不瞭解技術又不瞭解業務然後又喜歡問之問那的，其實這種煩惱是自己造成的，因為你沒有主動和上級溝通。溝通的渠道有很多，可以面對面交流，也可以選擇在會議中同步一些資訊，可能你會跳出來反駁我的觀點，領導那麼忙，單獨找他溝通太麻煩人家了，而會議時長通常很長，容易浪費時間，導致被迫晚上加班，所以溝通乾脆就算了。

程式設計師反感開會早就司空見慣了，其他行業也一樣，通常是因為會議沒有太多資訊價值，那比如站立會應該怎麼開才合適呢？

通常覺得會議沒有資訊價值是因為會議內容和自己不相關，人在接收和自己不相關的資訊時，容易思緒發散，長而久之就會滋生厭惡。所以站會只組織相關干係人即可，人數不宜過多。站會顧名思義就是團隊站著開會，強調時間不宜過長。站會通常由領導主持，團隊成員輪流發言，講述工作事項，但是要避免長時間討論。

在站會時團隊成員應該以三段輪為模板進行講述，一是昨天做了什麼？比如昨天完成某某需求的評審、技術選型、任務分解、工時估算；二是今天要做什麼？比如今天要完成某某需求的某個子任務；三是遇到了什麼阻礙？比如今天要進行的子任務開發中需要某某輔助解決技術難點。第三點非常重要，能夠儘早暴露問題，避免默默無聞埋頭苦幹，甚至工作到一半發現你理解的和人家真正需要的其實是兩回事，那時罵娘還能怪誰呢，這不恰恰是我們程式設計時強調的快速失敗嘛！

站會同時需要對於會上內容做概要記錄，便於會後跟蹤和解決。那會上問題，誰來推進呢？極客時間的池老師總結了一句原則，誰難受誰推進原則，在團隊協作中也適用。如果這件事不做，你自己或者專案小組就會非常難受，那麼就應該毫不猶豫的主動推進。

好，今天分享了避免團隊人員覺得會議對專案進展沒有幫助的建議，希望能幫助到你，歡迎分享給你的朋友們。

文章來源：www.liangsonghua.me

作者介紹：京東資深工程師-樑鬆華，在穩定性保障、敏捷開發、JAVA高階、微服務架構方面有深入的理解

&n