眾所周知，在項目管理的過程中，我們需要非常注重溝通，而每日例會作為溝通管理中的一項最佳實踐，非常適配互聯網項目短頻快的特點。成功地在項目中建立例會制度，能帶來以下好處：

1）讓研發人員相互之間了解各自的任務完成情況，以便于上下游及時銜接，發現進度異常和集成的風險；
2）讓技術難題和業務疑點及時暴露，并根據問題的普適程度，選擇在會上或會后得到支持與解答；
3）讓產品經理了解研發過程，一方面及時掌握動態，另一方面能對結果和風險抱有更深切的同理心，以便后續能更緊密地合作；
4）幫助團隊建立秩序感和紀律性，提升組織的成熟度。

作為一名在弱矩陣型組織中擁有微權力的 PM ，要在一個尚沒有形成慣例、且僅為完成當前項目而臨時組建的團隊中建立例會制度，筆者建議以如下方式邁出第一步：

一、事前摸底

可以先通過訪談對話的方式，收集項目組成員在如何透明研發進度和風險方面的認知情況，甚至可以了解一下其所屬部門的工作風格，以便采取合適的應對措施。

如果有成員曾經參與過項目每日例會的相關實踐，務必抓住這個機會，盡量說服 TA 作為你安插在項目組中的臥底，在必要的時候主動站出來配合你，這樣的話，其他人也更容易行動起來。

可能也有成員曾在例會中經歷過糟糕的體驗，比如：時間冗長、議題蔓延、信息過載、與之無關等，這時，你一方面要慶幸提前發現了暗礁，在自己組織的例會中要盡量避開（當然，如果你有豐富的項目管理經驗，閱會無數，那你能舉出更多的失敗案例，但無須事事防范，否則過猶不及，讓自己處處掣肘），另一方面，也要更加謹慎地實施你的想法，避免對方受到二次傷害，進而對 PM 和改進工作喪失信心。

二、承諾約定

PM 需要具備一定的主動性，在項目啟動之初（比如： kickoff meeting 上）提出例會的建議，可以介紹一下例會對項目及成員所帶來的好處，與大家（包括 PO ）約定每天在固定時間和地點同步一下各自的狀態，挑選大家都合適的時間，并獲得每個人的口頭同意。

作為交換， PM 須針對大家關切的問題作出一些承諾，比如：確保會議的質量，時間不會超過 15 分鐘，會后有文字材料輸出用于追溯。

不僅是例會制度，絕大部分的改進工作都會要求參與者走出舒適區，做出一定的讓步甚至承受陣痛，故所謂“投之以桃，報之以李”：你愿意配合我的工作，我也不會讓你失望。針對之前調研所掌握的信息，給項目團隊吃下定心丸。

三、不見不散

可以要求讓每個人創建一個日程提醒。但無論設幾個鬧鐘，剛開始幾次例會，還是會有不少人遲到甚至忘記出席，需要經過反復提醒才會慢慢養成習慣。

守時是職業操守之一，但如果遇到成熟度較低的組織，則需要不斷灌輸和教育。這時候， PM 一方面需要及時補位，在會前就做好提醒工作，另一方面也可以于會后在項目日志中做好記錄，在必要的時候反饋給當事人所屬部門的負責人，一起幫助 TA 改進。身處于某些組織文化中的讀者，可能會對這種直接了當的反饋方式抱有畏懼心理，但考慮到“如果團隊尚未達到理想的成熟度，未來高階的改進工作將難以開展”這一點，就不應該回避沿途的任何困難。

另外，例會地點盡量固定，以便于大家習慣的養成，否則每次換地方都要再通知，成本很高。

四、每日三問

首次例會一般需要花更多的時間，最主要的一點是 PM 需要向大家講解和示范如何參與例會。當然，在 承諾約定 環節可以做一些鋪墊，但光是口頭解釋缺乏身臨其境的場景感，大家未必都能 get 得到。所以，也不必贅述，只要現場主動參與和切身感受一下，包教包會，屢試不爽。

為了爭取最佳的投入產出比，我們有必要把例會的環節設置得盡可能的精簡，但又不失效果。筆者建議會上所有人站成一圈，每個人（除 PM 和 PO 之外）輪流向團隊回答三個問題：1）我昨天做了什么（即：工作進度）；2）我今天打算做什么（即：工作計劃）；3）我遇到了什么困難（即：暴露風險）。

前兩個問題，上下游與之依賴的組員會特別關注，比如：前端依賴于后端的接口實現，否則他自己的功能驗證工作會遲遲完不成。而第三個問題， PM 和 PO 會比較關注，他們有義務為項目掃除障礙，比如： PM 需要協調項目團隊以外的技術顧問來做支持， PO 需要解答產品功能細節的疑惑，不一而足。通過上述三個問題，信息在項目組內部變得完全透明，成員對工作更有目標感， PO 對成功交付更有信心，媽媽再也不用擔心我的項目了！

如果組織得當，按每人三句話的速度，一次例會妥妥地被控制在 15 分鐘以內。當然，由于例會的時長非常短，為了確保會議的效率和效果，仍然要求 PM 控制好會議的節奏，同時也需要項目組成員全身心投入。

五、反饋改進

每人分享完自己的三個問題且沒有其他公共議題了的話（非公共議題應放在會后單獨進行），項目團隊的首次例會就進入尾聲了。此時，大家的精神狀態已經放松下來了，由于是第一次例會， PM 可以在宣布散會前詢問一下大家的與會感受，以便后續做改進。

也許首次例會并不如你預想的那樣完美，比如：有的成員不太善于表達、有的成員會忍不住和其他人開小會、有的成員羞于公開上報自己的風險，等等。但至少你已經邁出了第一步，項目組成員的心中已然被你播下一顆種子，后續免不了還要不停地澆水施肥，幫助他們積累如何高效參與例會的經驗，在現有最小可用例會的基礎上持續迭代。

小結

導入項目例會比較適合作為對組織實施效能改進工作早期階段的一次試探，以投石問路的方式了解組織對輕量級變革的接受情況。如果較難接受，則說明組織的成熟度不高， PM 要做好貼身輔導打持久戰的心理準備，反之則能順利推廣并賦能到組織的各個角落。

在有贊建立項目管理體系之初，筆者曾倡議試行項目例會，有幸被廣泛接納，輔之以實物看板，簡直如虎添翼。曾經有一段日子，某間狹小的會議室，在一個小時內輪番成為四五個項目的每日例會之場所，與會人員絡繹不絕，一派繁忙而有序的景象。

作為 PM ，每次參與項目管理都是一次幫助組織進化的機會，而每個為新項目所臨時組建的團隊中，都可能出現你曾經合作過的同事的身影。讓他們成為你效能改進工作過程中散在各處的星星之火，從此，你將不再是一個人在戰斗。

總結

以上是生活随笔為你收集整理的效能改进之项目例会导入实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。