如何舉辦一場將改變你的公司的實驗會議(以及我在 Workato 的做法)
已發表: 2022-05-27在大多數情況下,我討厭開會。
我在文章、推文和我的同事中說過很多次。
主要是,我不喜歡人們使用會議作為拐杖來避免完成工作,或者人們開會很糟糕並浪費每個人的時間。
但作為領導者,我認識到一些會議的重要性。 特別是,就我而言,每週一次的實驗會議。
沒錯——Workato 實驗計劃的基石只是一次會議。 我們不做每日站立(我們在 Slack 上異步做這些); 取而代之的是在一周開始時舉行一次會議,並加入一些其他的人工製品和儀式來保持機器的運轉。
這將是我的第一篇也是唯一一篇深入探討我如何舉辦這次會議的詳細信息、我為什麼以這種方式舉辦會議以及我如何與其他實驗程序工具(如電子郵件、知識共享數據庫和讀數)平衡的文章。
在向您介紹會議記錄之前,我想先問一個高層次的問題——為什麼首先要召開這次會議?
實驗小組會議的目的是什麼?
每次會議都需要一個目的。 如果沒有目的,就不應該發生。
我的每週實驗會議的三個實用程序如下:
- 學習和見解分享
- 舉措的優先順序
- 識別和消除流程瓶頸
這意味著我們從會議中消除了大多數其他無法兌現的談話要點。
通過學習加速實驗
當你開始建立一個實驗程序時,你必須努力打好基礎。
- 獲得合適的測試工具。
- 確保它與您的分析工具集成,並且您正在適當地跟踪數據。
- 與高管溝通,為實驗設定適當的期望。
然而,一旦你開始擴展實驗,你在每個實驗中學到的東西將成為你程序其餘部分的增效劑。
當你每個月通過 5-10 次實驗時,你從勝利者、失敗者和不確定性中學到的東西將影響你運行下一批實驗的成功率。 所有這些都應該是影響您如何確定路線圖優先級的核心。
這似乎是在浪費時間,但事實並非如此。 Reforge 的創始人 Brian Balfour 也強調了學習在召開成長會議中的重要性:
因此,我們在會議的大部分時間裡都在學習和分享見解。
如果您的會議是跨職能會議或有來自其他團隊的成員參加電話會議,這將特別有用,因為您經常會獲得通常不會獲得的觀點。
例如,我們經常會在我們的實驗會議上邀請產品營銷人員加入並分享客戶研究的最新發現或分享即將到來的戰略敘事變化。
事情會改變的; 優先級是敏捷的
在我的會議上,我想明確我們的目標,我們正在採取哪些步驟來實現目標,以及誰對什麼負責。
這是會議的下一部分。
從我們所學到的知識中產生了一個問題,“我們接下來要做什麼?”
我們的主頁實驗失敗了——那麼我們學到了什麼,接下來我們要做什麼?
許多優先級實際上是按季度異步完成的——至少是我們項目中最大的實驗和最廣泛的主題桶。
但是我們確實為基於戰略變化和我們從過去實驗中學到的東西的路線圖的小變化和迭代留出了很大的迴旋餘地,我們利用會議的一部分來移動事情以反映這一點。
識別和消除流程瓶頸
最後,發現流程瓶頸很重要,尤其是當您處於實驗程序的擴展階段時。
這需要係統思考,是團隊領導或項目經理的核心工作。 實際上,您需要識別和衡量從構思一直到生產的實驗過程的每個步驟。
哪些步驟花費的時間最長,或者更確切地說,比預期的時間更長? 您如何利用這個每週例會來識別這些延遲和時間滯後,從而確保流程的其餘部分不會受到過度影響?
這是每週會議的關鍵部分,一般來說,這是為了讓您的實驗訓練保持在軌道上。
在實驗會議上要避免什麼
你可以隨心所欲地召開會議,但對於每週一次的團隊實驗會議,有兩件事往往會浪費大量時間。
- 提取臨時數據或要求任何人這樣做
- 非結構化頭腦風暴和構思
當您提取臨時數據或要求某人這樣做時,請記下這一點。 如果您反复詢問一些數據,請將其添加到您的流程清單中。 它不應該是每次會議都會出現的東西(它會浪費大量時間和精力)。 這就是儀表板和報告有用的地方。
在非結構化的頭腦風暴中,我實際上並不討厭它。
但是有一個時間和地點,通常是一種瘋狂的方法。
當您在每週會議期間花費大量時間來落實想法時,您可以減少識別流程瓶頸並確保您進行正確實驗的時間。
如果有一個隨機的好主意出現,那很好。 如果它演變成一個結構鬆散的頭腦風暴會議,你必須放下你的腳並讓它離線。
我如何召開每週的實驗團隊會議
好的,那麼我該如何召開每週一次的實驗團隊會議呢?
當然,我將不得不混淆我們運行的實際實驗和結果的一些細節,但我會盡可能詳細地介紹每個部分。
人民
首先,每週參加的人員是核心戰略實驗職能的一部分。 這是一個包括分析師、績效營銷人員、網絡開發人員和產品經理的小組。 我的經理也經常出席,但不是每次電話都出席。
我與我們的設計團隊單獨開會,因為他們是我們公司的卓越中心。
這些人定期參加,然後我不時邀請相鄰團隊的“客人”,如設計、品牌營銷或產品營銷。 此外,對於這些來賓電話,我們通常只設置一個單獨的會議,因為其目的通常是介紹新想法、更好的團隊溝通或集思廣益。
為了使這一點更通用,在大多數情況下,您的實驗會議應該包括制定戰略決策的人員和執行該戰略的人員。 通常,這是:
- 領導/項目經理
- 產品經理
- 開發者
- 設計師
- 分析師
日程安排
我每週一在中部時間下午 3 點召開這個會議。 週一早上非常適合準備和完成深入的工作,或者整理前一周的未完成任務。 到下午,團隊已經做好了討論下一周的準備。 這也讓我們都知道我們應該在一周內工作和優先考慮的事情。
然後,在整個一周內,我們將進行異步檢查和 1:1 會議,討論我們決定在周一的團隊會議上開展的工作的細節。
我們目前不使用幻燈片,但我們可能會合併它。 如果是這種情況,我會將各個部分與上面列出的時間限制聯繫起來,然後將在前一周的星期五發出甲板(目標是在星期一早上不超過 20 分鐘將每個人的部分放在一起) . 目前,我們主要瀏覽我們用於項目管理的 Airtable 數據庫。
議程
這是我的確切議程:
會議時長:45 分鐘
- 非正式追趕:5-10 分鐘
- 從已完成的實驗/研究中學習:<10 分鐘
- 優先處理/整理積壓:<10 分鐘
- 識別瓶頸/阻礙:其餘時間(10-15 分鐘)
我們已經介紹了上述每個部分及其目的。
我會給你一些工具和框架,這些工具和框架也可能對上述每一個都有幫助。
從已完成的實驗/研究中學習。
您在這裡需要的主要是一個良好的文檔系統。
在運行實驗之前,我需要在實驗文檔中填寫以下部分:
- 背景
- 學習目標
- 假設
- 預測(不同於假設)。
- 實驗設計(量化和創意)
- 跟進(結論後會發生什麼)
然後在運行實驗後,又填寫了兩個部分:
- 結果
- 學習
在我們的會議中,我們簡要介紹了結果並更深入地介紹了學習部分。 誰是實驗“所有者”,誰是展示學習成果的人,然後就我們如何應用它們進行了簡短的討論。 有時這意味著在更廣泛的範圍內進行測試,或者只是將學習擴展到類似的經驗。 有時這意味著以一種有意義的方式進行迭代。
您在此步驟中選擇的兩個工具應該是:
- 實驗文檔(點擊這裡盜取我的模板)
- 實驗知識共享系統/Wiki
優先處理/整理積壓:<10 分鐘
關於這部分的實用性存在爭議,但我喜歡將其保留為小組討論,因為與簡單的網絡生產或產品管理不同,實驗受到許多外部壓力、阻礙和突發奇想的影響。
例如,我們可能沒有為我們計劃的一個特別大的實驗買單,或者我們可能有一個設計障礙。 但是我們仍然希望保持我們的測試節奏,所以在這種情況下,我們可以保持敏捷,並從積壓工作中提升一個較低工作量的想法。
在某些組織中,此決策完全由實驗團隊負責人決定。 我喜歡向小組開放討論。
為什麼?
首先,我不想在我的優先級分數的重壓下壓垮團隊。 實驗的部分價值在於學習你沒想到會學到的東西,並且通過允許團隊中其他人自主確定優先級,我們得到了我不會放在桌面上的想法。 這也有助於改善整體團隊溝通和融洽關係。
其次,人們更願意從事他們選擇從事的工作。 如果我開始分配所有想法,我就會限制人們對單個實驗的熱情(這在許多方面限制了實驗獲勝的潛力)。
所以在本節中,我們基本上使用兩個工具:
- 項目管理看板(我們使用 Airtable——這是一個很棒的模板)。
- 優先級矩陣(我們使用 PXL)。
識別瓶頸/阻礙:其餘時間
最後,識別瓶頸。
這很難。 一開始,它做了兩件事:
- 在延遲交付中尋找模式
- 詢問團隊的定性和開放式問題
在我的 Airtable 中(很抱歉我不能分享),每張卡片中有四列:
- 設計到期
- 設計交付
- 開發到期
- 開發交付
這是我們遵循的看板步驟的補充:
- 主意
- 實驗文件進行中
- 審查中的實驗文件
- 開發中
- 質量保證
- 質量檢查並準備發布
- 跑步
- 總結
- 已投入生產
這使我能夠看到事情落後於計劃的地方。 例如,如果我們運行了 10 個測試,但沒有一個測試被實施,那麼我們就有了生產問題。 或者,也許我們的實驗在質量保證方面停滯不前,並且我們有大量待發布的實驗等待啟動。
在開發階段,我們還想看看我們是否在等待設計或開發人員來創造體驗。 如果我們一再落後,這意味著我們需要重構這些團隊的優先級或可能增加員工人數。
定性問題聽起來像這樣:
- 這周有人需要我的支持嗎?
- 本週實現我們的目標是否有任何潛在的障礙?
這些問題的答案既可以讓您在短期內解決這些瓶頸,也可以在它們重複出現以長期解決時識別模式。
填補空白:其他有用的實驗程序工具
實驗團隊會議並不是經理工具包中應該包含的唯一工具。
事實上,我看到實驗經理犯的最大錯誤是試圖在一次會議上完成所有工作。
相反,您希望分散您的儀式和人工製品,以便為您想要完成的每項工作使用最好的工具。
實驗組會議完成了三件事:
- 學習和見解
- 優先級和工作分配
- 攔截器識別和修復。
您可能關心的其他實驗計劃目標如下:
- 從其他團隊獲得想法
- 讓高管和利益相關者了解投資回報率和結果
- 與其他團隊分享結果,在實驗之外傳播知識
根據您的組織,您可能還有更多工作要做,例如保留實驗記分牌或與數據科學家合作實施 DataOps 流程以自動化部分分析或您的平台。
但出於上述目的,我發現這些工具省力且高效:
- 實驗審查電子郵件
- 跨職能實驗宣讀會
- 實驗存檔/知識共享工具
實驗審查電子郵件
在大多數情況下,你的實驗團隊會議不應該花在討論結果上。 這應該在儀表板和您(項目經理)發送給團隊其他成員和任何相關方的每週電子郵件中有效地完成。
它應該包括:
- 過去的實驗已經結束+結果
- 目前正在運行的實驗
- 未來的實驗
任何自助式分析和儀表板也可以包含在此處。 我喜歡為小組中的書呆子創建視覺上吸引人的結果圖表並鏈接到更多細節。 但總的來說,您的 VP 不會太在意每個單獨測試的詳細統計數據。 因此,這封電子郵件旨在讓您了解您的努力並分享高水平的成果和經驗。
跨職能實驗宣讀會
實驗團隊永遠不應充當領土孤島。 你限制了你的團隊獲得的知識的傳播,你也限制了破壞性想法的流入。
所以每個季度,我都喜歡運行一個跨職能的實驗讀數,我們會在其中遍歷我們進行的所有實驗和高水平的學習,然後我們打開麥克風讓其他團隊發表評論和提出想法。
這讓其他團隊——對我來說,通常是產品營銷、品牌、產品和需求生成——看看我們學到了什麼。 也許他們可以用它來影響他們的工作、消息傳遞和設計。
它還允許他們將我們可能不知道的事情放在我們的雷達上——即將到來的活動、在入職流程上運行的實驗等。
實驗存檔/知識共享工具
最後,實驗程序中最被低估的工具是存儲所有結果和學習的地方。 優選地,這是一個具有良好搜索和標記功能的工具。
這使得高度感興趣和參與的各方可以簡單地查看已經運行的內容。
就個人而言,我使用 Airtable 和 Google Docs 的組合。 但是你可以使用 Notion、Confluence 或像 Effective Experiments 這樣的專用 A/B 測試存檔工具。
結論
實驗團隊會議是一個重要的儀式,它可以決定或破壞您團隊的效率(實驗速度和質量)和有效性(您的團隊在組織中的知名度和尊重程度)。
尊重會議和與會人員,不忘初心。 避免分心和範圍蔓延——還有其他用於頭腦風暴和報告的工具。 很快你就會發現,你不再害怕再次開會,而是期待這次會議,因為它非常高效。 無論如何,這就是我們降落的地方。