》，題圖來自：東方IC。
在工作日的清晨，用10-15分鐘，大家圍成一圈，回答類似「昨天做了什麼」、「今天準備做什麼」以及「工作遇到了哪些阻礙」這樣的問題。這是許多人經歷過的一個典型站會場景。
站會因為形式靈活、時間簡短，近些年迅速在企業產品開發團隊中流行開來。
行之有效的站會無疑是增進團隊溝通、提高工作效率的法寶。但事實上，它並不適用於所有場景，如果只是每天機械地執行站會，而不著眼於關鍵問題，有可能會議的效果大打折扣，而使許多人感覺時間遭到浪費。
站會可不只是站著開會，它適用於怎樣的情況？一場真正優秀的產品團隊會議是如何開展的？圍繞決策層面，該如何組織大家針對關鍵問題發起「進攻」？這篇文章將給你帶來有益的參考。
大多數的站會每天都會舉行，有些團隊把頻率降到了一周2-3次。會議很簡短，但時常出現的情況是，人們在會上閒談，說一些和工作無關的事情，比如分享自己周末做了什麼。這些行為不能幫助你快速開發出高質量的產品，但人們仍十分熱衷於站會，一些常用工具甚至內置了一個站會功能。
事實上，站會只有在產品即將發布時才能真正發揮作用。就如同你的軍隊已經準備好了，就要發起進攻的時候：我們準備好運行A/B測試了嗎？營銷部門準備好發布推文和宣傳文稿了嗎？客服部門準備好在產品推出後如何回復客戶問題了嗎？
——只有在你的軍隊做好準備，即將「諾曼第登陸」的時候，開一個站會為發布產品做好準備，這才是有效的。
站會沒有為做決策留出時間
在一個典型的站會上，與會人員被要求分享以下內容：
● 昨天我完成了什麼？
● 今天我要去做什麼？
● 我遇到了什麼阻礙？
這種形式存在幾個大問題：
第一，大多數時候，你不會關心別人每天在做什麼，除非另一個團隊成員昨天做的事是你進行工作的基礎或者會阻礙你的工作。大家共享的東西如果無法明確地減少你的阻礙，就會很容易被你屏蔽掉。
例如，產品經理可能會分享這樣的內容，「昨天，我進行了一次面試，制定了一些規章，還見了一位客戶。今天，我要再面試一個設計師候選人，在產品說明書中更新一些用戶故事。目前我還沒有遇到任何阻礙。」這是一次典型的在會議中分享自己工作進展的例子，顯然，這樣做對快速構建高質量產品並無幫助。
第二，為什麼每個人都要關心你今天在做什麼？同樣，只有在一個人今天做的事能減少團隊中的另一個人的阻礙時，這種分享才是有用的。但如果真的是一個很大的阻礙項，應該等到每天的站會才告訴大家嗎？為什麼不給造成阻礙的人發郵件或者走到他們的辦公桌前告訴他們，在問題出現的時候就及時補救呢？
最後來分析第三個要點，那就是分享你現在受到的阻礙是什麼。舉個例子，後端工程部門在確定他們必須實現的工程設計文檔之前，必須等待更加清晰的前端規範。還有人受到阻礙的原因是某個決策還沒有做出來。與其說「我被某個問題擋住了」，不如說「嘿，我們為什麼不一起對某問題做出決策，這樣我們才能繼續前進」呢？
站會沒有為做決策留出時間。站會被設計成只是讓「阻礙」為人所知，而不是去解決「阻礙」。然而，解決問題比意識到有問題更重要。
圍繞決策進行會議
只有圍繞關鍵決策進行會議，才能進一步提高會議的效率，加快開發周期。這裡有一個簡單的替代方案，適用於任何產品團隊和大多數會議。
在會議中，回答以下兩個問題：
1.誰需要在什麼日期前處理什麼關鍵的行動項目？
2.需要做出哪些決策？
根據要做出的決策的數量，每周召開1-3次會議。在產品開發的早期，團隊需要做出許多決策，會議的頻率較高；隨著開發的進展，需要做出的決策數量會減少，用於構建產品的時間增加，會議頻率也降低；同樣，做決策的困難程度會隨著開發的進展而變小。
隨著產品開發生命周期階段的不同，需要召開會議的頻率也不一樣。
如果團隊能夠快速、有效地做出關鍵的決策，那就可以在產品開發周期中減少幾周或幾個月的不必要的延遲。如何確保做到這一點呢？
● 收集開放性問題
在會議籌備階段，與產品團隊的每個功能負責人（設計、研發和市場等）溝通，詢問他們需要做出什麼決策，如：「是否應該向高層尋求更多資源的支持」、「誰來擔任小組的帶頭人」等，收集他們提出的開放性問題並列入議程。記錄在決策會議上要提出的一系列行動項目，以明確接下來每個團隊成員的任務。
作為會議主持者，你應該快速瀏覽一遍行動項目，以確保大家可以繼續執行自己分配到的關鍵任務，並保證能夠按時完成。在討論中出現的任何新任務都會被實時添加到列表中。通常可以用不到10分鐘的時間完成上述討論。
會議的其餘時間用來做決策。在許多情況下，團隊中的一些相關成員已經進行過一次非正式的談話了，他們可以向整個團隊介紹某個開放性問題的背景和他們想要得到的答案。決策通常是在幾秒鐘或是幾分鐘內做出的。
在少數情況下，做出某個決策才需要更充分的討論，在這種情況下，不妨要求團隊中最有能力的人和與該決策最相關的2-3名成員在當天晚些時候成立一個快速工作組，討論該項目並提出建設性的建議，然後通過電子郵件或在下一次產品團隊會議上與其他成員分享他們的建議。
利用團隊會議和小組討論來快速排除未解決的問題。
●決策日誌
另一個不錯的方法是引入「決策日誌」作為會議的一部分。可以用一個單獨的文檔來保存所有會議議程的完整記錄以及之前做出的決策。在產品發布後進行事後評估時，這些記錄就派上用場了。它可以讓你很容易地對項目進行反思，並能夠找到出現問題的根本原因。
小結
現在流行的站會雖然形式靈活，但在驅動團隊進行有效產品開發層面仍存在一定的局限性。較長開發周期的根本原因是沒能快速和頻繁地做出決策。通過用更少的決策會議代替日常會議，產品團隊可以節省大量的時間，必能更快地構建產品。