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

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