기대와 우려 워크숍: 프로젝트를 시작하기 전에 생각 나누기

기대와 우려 워크숍은 두 가지 질문으로 시작합니다. “이 프로젝트를 통해 무엇이 가능해지길 바라나요?”, “어떤 일이 생길까 걱정되나요?” 먼저 각자 생각을 적고, 메모의 의미를 이야기한 뒤 관련된 주제를 묶습니다. 그다음 일을 시작하기 전에 구체적인 대응이 필요한 기대나 우려를 몇 가지 고릅니다.

같은 목표를 가진 팀이라도 성공의 모습은 다르게 생각할 수 있으므로 프로젝트 시작 단계에 활용하기 좋습니다. Boardmix 공유 화이트보드에서 기대, 우려, 합의한 내용을 함께 볼 수 있게 정리하세요. 어떤 걱정은 미해결로 남아도 됩니다. 모든 우려를 긍정적인 문장으로 바꿀 필요는 없습니다.

이 워크숍은 무엇을 위한 활동인가요?

기대와 우려 워크숍은 각자의 기대를 대화의 주제로 꺼내는 활동입니다. ‘새 지식 베이스를 구축하자’는 목표에 동의해도 어떤 사람은 반복 업무 감소를, 다른 사람은 답변 품질 개선을 기대할 수 있습니다. 또 다른 사람은 감당하기 어려운 유지 관리 업무를 걱정할 수 있습니다. 이런 차이는 일을 어떻게 운영할지에 영향을 줍니다.

IBM Enterprise Design Thinking 도구 모음(영문)은 Hopes and Fears를 새로운 일을 시작할 때 팀의 목표와 우려를 드러내는 활동으로 설명합니다. 기본 방식은 기대와 우려 영역을 나누고, 개인별 메모를 작성한 뒤 주제를 묶어 함께 검토하는 것입니다.

이 보드는 조직 전체를 대표하는 설문 결과도, 확률 모형도, 팀이 합의했다는 증거도 아닙니다. 다른 사람이 언급하지 않은 우려 하나도 중요할 수 있습니다. 메모는 의미를 더 정확히 확인하기 위한 출발점으로 봅니다.

구체적인 상황을 제시하기

프로젝트, 이야기할 기간, 이번 세션에서 영향을 줄 수 있는 결정을 적습니다. ‘우리의 미래’는 너무 넓습니다. ‘공유 고객 지원 지식 베이스를 사용하는 첫 한 달’이라고 하면 같은 상황을 떠올릴 수 있습니다.

이번 예시에는 지원 상담원, 콘텐츠 편집자, 팀장, 검색 경험의 유지 관리를 돕는 개발자가 참여합니다. 진행자는 다음과 같이 시작합니다.

지원 대기열 하나를 대상으로 지식 베이스를 작게 시범 운영하려고 합니다. 오늘은 첫 한 달 동안 얻고 싶은 결과와 사용을 어렵게 만들 수 있는 문제를 이야기하겠습니다. 시범 운영의 업무 방식은 조정할 수 있습니다. 더 넓은 인력이나 예산 문제는 별도의 결정이 필요합니다.

누가 보드를 볼 수 있고 워크숍 이후에는 어떻게 사용할지 설명합니다. 답하지 않아도 되며, 민감한 문제는 적절한 비공개 채널로 전달할 수 있다고 안내하세요. 공동 편집 공간에서 익명성을 약속하거나 개인 인사 정보를 공개하도록 요구해서는 안 됩니다.

토론 전에 각자의 생각을 모으기

메모 하나에 생각 하나를 적도록 요청합니다. 잠시 조용히 쓰는 시간을 주면 첫 발언자의 방향을 따르기 전에 자기 생각을 정리할 수 있습니다. 진행자는 다음과 같은 문장을 제시할 수 있습니다.

• “이 프로젝트가 우리에게 도움이 되었으면 하는 점은…”
• “실제로 일하는 사람에게 유용한 결과는…”
• “제가 걱정하는 것은…”
• “제가 기여하려면 필요한 것은…”

기대와 우려를 같은 개수로 쓰게 하지 마세요. 여러 걱정과 하나의 중요한 기대를 가진 사람도 있습니다. 리더가 메모마다 바로 답할 필요도 없습니다. 어떻게 대응할지 정하기 전에 전체 의견을 먼저 살펴봅니다.

누군가 ‘소통’이라고 썼다면 이 프로젝트에서 어떤 뜻인지 묻습니다. ‘지난 근무 이후 문서가 바뀌었는지 쉽게 알고 싶다’는 구체적으로 다룰 수 있는 기대입니다. 특정 도구나 해결책을 미리 정하지 않으면서도 논의할 지점을 알려 줍니다.

행동을 정하기 전에 뜻부터 확인하기

아래 메모는 지식 베이스 프로젝트의 가상 킥오프 예시이며 실제 고객 조사 결과가 아닙니다. 막연한 느낌을 팀이 답할 수 있는 질문으로 바꾸는 과정을 보여 줍니다.

뜻이 분명해진 뒤에 메모를 묶습니다. 오래된 문구와 관리 시간 부족은 모두 유지 관리와 관련되지만 원인은 다릅니다. 주제 아래 개별 메모를 남겨 이 차이를 보존하세요.

비슷하게 들리는 두 메모를 합치기 전에는 “같은 문제를 말하는 건가요?”라고 묻습니다. 아니라고 답하는 사람이 있다면 차이를 유지합니다. 보드를 깔끔하게 만들겠다는 이유만으로 소수의 우려를 지워서는 안 됩니다.

몇 가지 업무 약속으로 구체화하기

다음 단계로 가기 전에 팀이 대응할 수 있는 기대와 우려를 고릅니다. ‘소통을 잘하자’, ‘문서를 최신 상태로 유지하자’ 같은 약속은 피하세요. 확인 가능한 행동, 책임을 수락한 사람, 도움이 되었는지 살펴볼 시점을 적습니다.

모든 메모가 행동으로 이어질 필요는 없습니다. 어떤 기대는 바라는 결과이고, 어떤 우려는 추가 정보가 필요합니다. ‘열린 질문’을 ‘합의한 행동’으로 오해하지 않도록 글자로 구분합니다. 팀의 권한 밖에 있는 우려라면 결정을 얻을 경로를 남깁니다.

Boardmix에서 단순하게 구성하기

Boardmix 보드 위쪽에 프로젝트 질문을 적습니다. 아래에는 ‘기대’와 ‘우려’라는 큰 영역 두 개를 만들고, 옆에 ‘합의와 열린 질문’ 영역을 둡니다.

참여자가 앞의 두 영역에 메모를 추가합니다. 논의하면서 관련 메모를 가까이 옮기고 각 묶음에 이해하기 쉬운 제목을 붙입니다. 합의와 질문은 글자 표기로 구분합니다. 색은 위치를 찾는 데 도움이 될 수 있지만 의미를 전적으로 색에만 맡기지는 마세요.

최종 약속은 관련 메모 옆에 배치합니다. 댓글을 이용하면 원래 메모가 복잡해지지 않도록 설명을 보탤 수 있습니다. 참여자는 약속이 어떤 우려에서 나왔는지 찾아볼 수 있어야 하며, 아직 해결하지 않은 문제도 볼 수 있어야 합니다.

영역, 주제별 묶음, 약속은 팀이 직접 정리합니다. 이 활동에 자동 감정 분석이나 위험 점수 계산이 필요한 것은 아닙니다.

다른 워크숍이 필요한 경우

우려가 “무엇 때문에 프로젝트가 실패할 수 있으며 어떤 신호로 알 수 있을까?”라는 질문으로 바뀌면 프로젝트 사전 부검 워크숍에서 다룹니다. “어떤 믿음을 먼저 검증해야 할까?”가 질문이라면 가정 매핑을 활용합니다. 두 방법은 다른 질문을 다루므로 킥오프 대화 안에 모두 압축해서 넣지 않는 것이 좋습니다.

다음 프로젝트 점검 때 약속과 열린 질문을 다시 확인합니다. 일이 시작된 뒤 기대가 달라진 부분이 있는지 묻습니다. 원래 메모를 남겨 변화를 볼 수 있게 하세요. 모두가 결과를 예상했던 것처럼 킥오프 기록을 고쳐 쓰지 않습니다.

세션을 준비하려면 Boardmix 보드를 열고 프로젝트에 관한 구체적인 질문부터 적습니다. 두 영역은 그다음에 만들면 됩니다. 먼저 할 일은 이 팀이 실제로 바꿀 수 있는 업무 방식을 정하는 것입니다.