회사를 변화시킬 실험 회의를 실행하는 방법(& Workato에서 수행하는 방법)

무엇보다 나는 회의를 싫어한다.

나는 기사, 트윗, 동료들에게 여러 번 말했습니다.

주로 나는 사람들이 일을 피하려고 회의를 목발로 삼거나 회의를 제대로 운영하지 못하고 모두의 시간을 낭비하는 것을 싫어합니다.

그러나 지도자로서 나는 몇몇 회의의 중요성을 인식하고 있습니다. 특히 제 경우에는 주간 실험 모임이요.

맞습니다. Workato에서 실험 프로그램의 초석은 단 한 번의 회의입니다. 우리는 일일 스탠드업을 하지 않습니다(이 작업은 Slack에서 비동기식으로 수행). 대신 기계를 계속 움직이게 하기 위해 몇 가지 다른 인공물과 의식을 뿌린 한 주의 시작에 단 한 번의 회의가 있습니다.

이것은 내가 이 회의를 어떻게 운영하는지, 왜 그런 식으로 운영하는지, 다른 실험 프로그램 도구(예: 이메일, 지식 공유 데이터베이스, 판독값)와 균형을 이루는 방법에 대해 자세히 설명하는 첫 번째이자 유일한 기사가 될 것입니다.

회의록을 안내하기 전에 먼저 높은 수준의 질문을 하고 싶습니다. 처음에 이 회의를 하는 이유는 무엇입니까?

실험팀 회의의 목적은 무엇입니까?

모든 회의에는 목적이 필요합니다. 목적이 없다면 일어나서는 안 된다.

내 주간 실험 회의의 세 가지 유틸리티는 다음과 같습니다.

• 학습 및 통찰력 공유
• 이니셔티브의 우선 순위 지정
• 프로세스 병목 현상 식별 및 제거

이것은 우리가 회의에서 전달하지 못하는 대부분의 다른 요점을 제거한다는 것을 의미합니다.

실험은 학습을 통해 가속화됩니다.

실험 프로그램을 구축하기 시작하면 기초를 다지는 힘든 작업을 해야 합니다.

• 적절한 테스트 도구 얻기.
• 분석 도구와 통합되어 있고 데이터를 적절하게 추적하고 있는지 확인합니다.
• 실험에 대한 적절한 기대치를 설정하기 위해 경영진과 의사 소통합니다.

그러나 실험 규모 조정을 시작하면 각 실험에서 배운 내용이 나머지 프로그램에 대한 강화제 역할을 합니다.

한 달에 5-10개의 실험을 통과할 때 승자, 패자 및 결정적이지 않은 사람으로부터 얼마나 잘 배우느냐가 다음 실험 배치의 성공률에 영향을 미칩니다. 그리고 이 모든 것이 로드맵의 우선 순위에 영향을 미치는 핵심이 되어야 합니다.

시간 낭비처럼 보일 수 있지만 그렇지 않습니다. 리포지(Reforge)의 설립자인 브라이언 밸푸어(Brian Balfour)도 성장 회의를 운영할 때 학습의 중요성을 강조합니다.

그래서 우리는 회의의 많은 부분을 학습을 통해 걷고 통찰력을 공유하는 데 보냅니다.

이는 회의가 교차 기능적이거나 통화 중인 다른 팀의 구성원이 있는 경우 일반적으로 볼 수 없는 관점을 자주 얻기 때문에 특히 유용합니다.

예를 들어, 우리는 종종 제품 마케터를 실험 회의에 초대하여 고객 연구에서 발견한 최근 발견 사항을 공유하거나 다가오는 전략적 내러티브 변경 사항을 공유하게 됩니다.

모든것은 변한다; 우선순위는 민첩하다

회의에서 저는 우리가 목표로 하는 곳이 어디인지, 거기에 도달하기 위해 어떤 조치를 취하고 있는지, 누가 무엇에 대해 책임을 지고 있는지를 분명히 하고 싶습니다.

회의의 다음 부분입니다.

우리가 배운 것에서 흘러나온 질문은 “다음에 무엇을 할 것인가?”입니다.

홈페이지 실험이 실패했습니다. 그래서 우리는 무엇을 배웠고 다음에 무엇을 할 것입니까?

많은 우선 순위가 실제로 비동기식으로 분기별로 수행됩니다. 최소한 우리 프로젝트의 가장 큰 실험과 가장 광범위한 주제 버킷입니다.

그러나 우리는 전략적 변경과 과거 실험에서 배운 것을 기반으로 로드맵에 작은 변경과 반복을 위한 많은 흔들림의 여지를 남기고 회의의 일부를 사용하여 이를 반영합니다.

프로세스 병목 현상 식별 및 제거

마지막으로, 특히 실험 프로그램의 확장 단계에 있는 경우 프로세스 병목 현상을 발견하는 것이 중요합니다.

이를 위해서는 시스템 사고가 필요하며 팀 리더 또는 프로그램 관리자의 핵심 업무입니다. 효과적으로 아이디어에서 생산에 이르기까지 실험 프로세스의 각 단계를 식별하고 측정해야 합니다.

어떤 단계가 가장 오래 걸리거나 예상보다 더 오래 걸리나요? 그리고 이 주간 회의를 사용하여 이러한 지연과 시간 지연을 식별하여 나머지 프로세스에 과도한 영향을 미치지 않도록 하려면 어떻게 해야 합니까?

이것은 주간 회의의 중요한 부분이며 일반적으로 말해서 실험 훈련을 트랙에서 유지하기 위한 것입니다.

실험 회의에서 피해야 할 사항

원하는 대로 회의를 진행할 수 있지만 주간 팀 실험 회의의 경우 두 가지가 엄청난 시간 낭비 경향이 있습니다.

• 임시 데이터를 가져오거나 누군가에게 그렇게 하도록 요청
• 구조화되지 않은 브레인스토밍과 아이디어

임시 데이터를 가져오거나 누군가에게 그렇게 하도록 요청할 때 기록해 두십시오. 반복적으로 약간의 데이터를 요청하는 경우 프로세스 체크리스트에 추가하십시오. 모든 회의에 등장해서는 안 됩니다(많은 시간과 집중을 낭비함). 이때 대시보드와 보고가 유용합니다.

구조화되지 않은 브레인스토밍에 대해 저는 사실 일반적으로 그것을 싫어하지 않습니다.

그러나 광기에 대한 시간과 장소와 일반적으로 방법이 있습니다.

주간 회의 중에 아이디어를 정리하는 데 지나치게 많은 시간을 할애하면 프로세스 병목 현상을 식별하고 올바른 실험을 실행하는 데 소요되는 시간을 줄일 수 있습니다.

우연히 좋은 아이디어가 떠오른다면 괜찮습니다. 느슨하게 구성된 브레인스토밍 세션으로 넘어가면 발을 내려놓고 오프라인으로 전환해야 합니다.

주간 실험 팀 회의를 운영하는 방법

자, 그럼 실제로 주간 실험 팀 회의를 실행하려면 어떻게 해야 합니까?

물론 우리가 실행하는 실제 실험과 결과에 대한 몇 가지 세부 사항을 난독화해야 하지만 가능한 한 자세히 각 부분을 다룰 것입니다.

사람들

첫째, 매주 참석하는 사람들은 핵심 전략 실험 기능의 일부입니다. 분석가, 성능 마케터, 웹 개발자 및 제품 관리자를 포함하는 소규모 그룹입니다. 제 매니저도 아주 자주 참석하지만 모든 전화에 참석하지는 않습니다.

나는 우리 회사의 우수 센터이기 때문에 우리 디자인 팀과 별도의 회의를 합니다.

이 사람들은 정기적으로 참석하고 나는 때때로 디자인, 브랜드 마케팅 또는 제품 마케팅과 같은 인접 팀에서 "손님"을 초대합니다. 또한 이러한 게스트 통화의 경우 일반적으로 별도의 세션을 설정합니다. 그 목적은 일반적으로 새로운 아이디어, 더 나은 팀 커뮤니케이션 또는 브레인스토밍을 소개하는 것입니다.

이를 보다 일반적으로 만들기 위해 대부분의 경우 실험 회의에는 전략에 대한 결정을 내리는 사람과 해당 전략을 실행하는 사람이 포함되어야 합니다. 일반적으로 다음과 같습니다.

• 리더/프로그램 매니저
• 제품 관리자
• 개발자
• 디자이너
• 분석가

일정

매주 월요일 오후 3시에 이 회의를 진행합니다. 월요일 아침은 준비하고 깊은 작업을 완료하거나 이전 주의 느슨한 끝을 묶기에 좋습니다. 오후까지 팀은 다음 주에 대해 논의할 준비가 잘 되어 있습니다. 이것은 또한 우리가 한 주 동안 무엇을 작업하고 우선 순위를 정해야 하는지 알 수 있게 해줍니다.

그런 다음 일주일 내내 비동기식 점검과 1:1 회의를 통해 월요일 팀 회의에서 작업하기로 결정한 세부 사항을 논의할 것입니다.

현재 슬라이드 데크를 사용하지 않지만 통합할 수 있습니다. 이 경우 개별 섹션을 위에 나열된 시간 제한에 연결하고 데크를 이전 주의 금요일에 발송합니다(월요일 아침에 각 개인의 섹션을 합치는데 20분 이상 사용하지 않는 것을 목표로). . 현재 우리는 주로 프로젝트 관리에 사용하는 Airtable 데이터베이스를 살펴봅니다.

의제

내 정확한 일정은 다음과 같습니다.

회의 시간: 45분

• 비공식 따라잡기: 5-10분
• 결론적 실험/연구에서 얻은 교훈: <10분
• 백로그 우선순위 지정/정리: 10분 미만
• 병목 현상/장애 요소 식별: 나머지 시간(10-15분)

우리는 이미 위의 각 섹션과 그 목적을 살펴보았습니다.

위의 각각에 도움이 될 수 있는 몇 가지 도구와 프레임워크도 제공하겠습니다.

결론을 내린 실험/연구에서 얻은 교훈.

여기서 가장 필요한 것은 좋은 문서화 시스템입니다.

실험을 실행하기 전에 다음 섹션으로 실험 문서를 작성해야 합니다.

• 배경
• 학습 목표
• 가설
• 예측(가설과 다름).
• 실험 설계(양적 및 창의적)
• 후속 조치(결론 시 발생)

그런 다음 실험이 실행된 후 두 개의 섹션이 더 작성됩니다.

• 결과
• 학습

그리고 회의에서 우리는 결과를 간략하게 다루고 학습 섹션을 더 깊이 다룹니다. 실험의 '주인'이 누구던 간에 배운 내용을 제시한 다음 이를 적용하는 방법에 대한 간단한 토론이 있습니다. 때로는 이것은 더 넓은 규모로 테스트하거나 단순히 유사한 경험으로 학습을 확장하는 것을 의미합니다. 때때로 이것은 의미 있는 방식으로 반복하는 것을 의미합니다.

이 단계에서 선택하는 두 가지 도구는 다음과 같아야 합니다.

• 실험 문서(내 템플릿을 훔치려면 여기를 클릭하세요)
• 실험지식공유시스템 / Wiki

백로그 우선순위 지정/정리: 10분 미만

이 부분의 유용성에 대한 논쟁이 있지만, 단순한 웹 제작이나 제품 관리와 달리 실험은 많은 외부 압력, 방해 요소 및 변덕의 영향을 받기 때문에 그룹 토론을 유지하는 것이 좋습니다.

예를 들어, 우리가 계획한 특히 대규모 실험에 대한 동의가 없거나 설계를 방해하는 요소가 있을 수 있습니다. 그러나 우리는 여전히 테스트 케이던스를 유지하기를 원하므로 이 경우 민첩성을 유지하고 백로그에서 더 적은 노력으로 아이디어를 올릴 수 있습니다.

일부 조직에서는 이러한 의사 결정이 전적으로 실험 팀 리더에게만 있습니다. 나는 토론을 그룹에 공개하는 것을 좋아합니다.

왜요?

첫째, 나는 우선 순위 점수의 무게로 팀을 짓밟고 싶지 않습니다. 실험의 가치 중 일부는 학습할 것으로 기대하지 않은 것을 배우는 데 있으며 팀의 다른 사람들로부터 자율적으로 우선 순위를 지정할 수 있도록 함으로써 내가 거기에 두지 않았을 아이디어를 테이블에 얻습니다. 이것은 또한 전반적인 팀 커뮤니케이션과 관계를 개선하는 데 도움이 됩니다.

둘째, 사람들은 작업하기로 선택한 작업에 더 흥분합니다. 모든 아이디어를 할당하기 시작하면 사람들이 개별 실험에 대해 느낄 수 있는 열정이 제한됩니다(여러 면에서 실험의 성공 가능성이 제한됨).

따라서 이 섹션에서는 기본적으로 두 가지 도구로 작업합니다.

• 프로젝트 관리 간판(우리는 Airtable을 사용합니다 – 여기 훌륭한 템플릿이 있습니다).
• 우선 순위 매트릭스(PXL 사용).

병목 현상/차단 요소 식별: 나머지 시간

마지막으로 병목 현상을 식별합니다.

이것은 어렵다. 처음에는 두 가지 작업을 수행합니다.

• 배송 지연 패턴 찾기
• 팀에 질적이며 개방형 질문을 던집니다.

내 Airtable(공유할 수 없어 유감스럽게도)에는 각 카드에 4개의 열이 있습니다.

• 디자인 마감
• 디자인 전달
• 개발 예정
• 개발 제공

이것은 우리가 따르는 Kanban 단계에 추가됩니다.

• 아이디어
• 실험 문서 진행 중
• 검토 중인 실험 문서
• 개발 중
• 품질 보증
• 품질보증 완료 및 출시 준비
• 달리기
• 결론
• 프로덕션으로 푸시됨

이를 통해 일정보다 늦어지는 부분을 확인할 수 있습니다. 예를 들어, 10개의 테스트를 실행했지만 그 중 아무 것도 구현되지 않았다면 프로덕션 문제가 있는 것입니다. 또는 우리 실험이 품질 보증에서 정체되어 출시를 기다리고 있는 게시 준비 실험의 백로그가 있을 수 있습니다.

개발 단계에서 우리는 디자인이나 개발자가 경험을 만들기를 기다리고 있는지 확인하고 싶습니다. 우리가 반복적으로 뒤처지면 이러한 팀의 우선 순위를 리팩토링하거나 잠재적으로 인원을 늘려야 함을 의미합니다.

질적 질문은 다음과 같습니다.

• 이번 주에 나에게 도움이 필요한 사람이 있습니까?
• 이번 주에 목표를 달성하는 데 잠재적인 방해 요소가 있습니까?

이에 대한 답변을 통해 이러한 병목 현상을 단기간에 해결할 수 있을 뿐만 아니라 장기적으로 문제가 반복되는 패턴을 식별할 수 있습니다.

부족한 부분 채우기: 기타 유용한 실험 프로그램 도구

실험 팀 회의는 관리자의 도구 모음에 있어야 하는 유일한 도구가 아닙니다.

사실 실험 관리자들이 저지르는 가장 큰 실수는 한 번의 회의에서 모든 것을 하려고 하는 것입니다.

오히려, 당신은 당신이 성취하고자 하는 각 작업에 가장 적합한 도구를 사용하도록 당신의 의식과 유물을 퍼뜨리기를 원합니다.

실험 팀 회의는 세 가지를 수행합니다.

• 학습 및 통찰력
• 우선 순위 및 작업 할당
• 차단기 식별 및 수정.

관심을 가질 수 있는 기타 실험 프로그램 목표는 다음과 같습니다.

• 다른 팀에서 아이디어 얻기
• ROI 및 결과에 대한 루프에서 경영진 및 이해 관계자 유지
• 실험 외부에 지식을 전파하기 위해 다른 팀과 결과 공유

조직에 따라 실험 점수판을 유지하거나 데이터 과학자와 협력하여 분석 또는 플랫폼의 일부를 자동화하는 DataOps 프로세스를 구현하는 등 더 많은 작업이 필요할 수 있습니다.

그러나 위의 목적을 위해 이러한 도구가 적은 노력으로 매우 효과적이라는 것을 알았습니다.

• 실험 검토 이메일
• 다기능 실험 판독 회의
• 실험 아카이브 / 지식 공유 도구

실험 검토 이메일

실험 팀 회의는 대부분 결과를 검토하는 데 사용되어서는 안 됩니다. 이는 대시보드에서 효과적으로 수행되어야 하며 프로그램 관리자인 주간 이메일이 나머지 팀 및 모든 이해 당사자에게 발송되어야 합니다.

여기에는 다음이 포함되어야 합니다.

• 종료된 과거 실험 + 결과
• 현재 진행 중인 실험
• 미래 실험

모든 셀프 서비스 분석 및 대시보드도 여기에 포함될 수 있습니다. 저는 시각적으로 매력적인 결과 차트를 만들고 그룹의 멍청한 사람들을 위해 자세한 내용에 대한 링크를 만드는 것을 좋아합니다. 그러나 대체로 VP는 모든 개별 테스트의 자세한 통계에 대해 별로 신경 쓰지 않을 것입니다. 따라서 이 이메일은 귀하의 노력에 대한 가시성을 확보하고 높은 수준의 결과 및 학습을 공유하기 위한 것입니다.

다기능 실험 판독 회의

실험 팀은 영역 사일로 역할을 해서는 안 됩니다. 팀이 얻는 지식의 확산을 제한하고 파괴적인 아이디어의 유입도 제한합니다.

그래서 분기마다 저는 우리가 실행한 모든 실험과 높은 수준의 학습을 살펴보는 교차 기능 실험 판독을 실행하고 나머지 팀이 의견을 제시하고 아이디어를 발표할 수 있도록 마이크를 엽니다.

이것은 일반적으로 제품 마케팅, 브랜드, 제품 및 수요 창출과 같은 다른 팀에게 우리가 배운 것을 볼 수 있는 기회를 줍니다. 아마도 그들은 그것을 사용하여 작업, 메시징 및 디자인에 영향을 줄 수 있습니다.

또한 예정된 캠페인, 온보딩 흐름에 대한 실험 실행 등 우리가 알지 못했던 것들을 레이더에 포착할 수 있습니다.

실험 아카이브 / 지식 공유 도구

마지막으로, 실험 프로그램에서 가장 과소평가된 도구는 모든 결과와 학습 내용을 저장할 장소입니다. 바람직하게는 이것은 우수한 검색 및 태깅 기능을 갖춘 도구입니다.

이를 통해 관심이 많고 참여도가 높은 당사자는 실행된 내용을 간단히 확인할 수 있습니다.

개인적으로 Airtable과 Google Docs를 함께 사용합니다. 그러나 Notion, Confluence 또는 Effective Experiments와 같은 전용 A/B 테스트 아카이브 도구를 사용할 수 있습니다.

결론

실험 팀 회의는 팀의 효율성(실험 속도 및 품질)과 효율성(조직에서 팀이 얼마나 눈에 띄고 존경받는지)을 만들거나 깨뜨릴 수 있는 중요한 의식입니다.

회의와 참가자를 존중하고 그 목적에 충실하십시오. 주의를 산만하게 하거나 범위를 좁히지 마십시오. 브레인스토밍 및 보고를 위한 다른 도구가 있습니다. 그리고 곧 다른 회의를 두려워하는 대신 생산성이 매우 높기 때문에 이 회의를 고대하고 있다는 것을 알게 될 것입니다. 어쨌든 우리가 도착한 곳입니다.