Close

기능 킥오프 회의


개발을 시작하기 전에 기능 킥오프 회의를 위해 팀을 모읍니다. 안건으로는 검토, 피드백, 그리고 문제 해결을 위한 대체 방법이 있습니다.

이 플레이를 사용하여...

새 기능의 가치에 대한 자신감을 쌓고 누군가에게 떠넘기는 대신 협업하여 사양을 다듬으세요.

If you're struggling with shared understanding, value and metrics, or proof of concept on your Health Monitor, running this play might help.

Copy link to heading Copied! 자세히 보기
이것이 필요한 이유

고객 조사 결과에 따르면 바로 이 기능을 통해 제품을 차별화하고 고객을 만족시킬 수 있습니다. 이 마지막 릴리스를 제공했어야 하므로 이제 본격적으로 시작해 보겠습니다.

이런! 잠시 멈춰 보세요. 팀이 컨텍스트를 가지고 있지 않습니다. 이 기능이 해결하는 문제를 정의할 때 아마 몇 가지 가정을 내렸을 것입니다. 기능의 성공을 어떻게 측정하는지에 대해서는 합의한 사항이 없습니다. 그리고 들떠 있는 와중에 디자인이나 기술적인 문제를 간과했을 수도 있습니다.

사용자 스토리로 백로그를 채우기 전에 팀원을 모으고 자세한 내용을 살펴볼 차례입니다. 그렇게 하지 않으면 명확한 것보다는 모호한 것이 더 많은 상태에서 개발을 시작하게 됩니다.

참여 대상

이 회의를 진행하려면 팀 전체를 모으세요.

사용자 팀
인력

6~9명

측정 시계
시간

60분

난이도 쉬움
난이도

중간

플레이 실행

킥오프 회의를 열기 전에 새 기능이 단순한 개념 이상인지 확인하세요. 하지만 디자인이 완성될 때까지 기다리지는 마세요.

준비물

화이트보드

마커 또는 펜

스티커 메모

러버 치킨

준비

개념 구축

킥오프 회의 전에 제품 소유자나 디자이너는 충실도가 낮은 사용자 여정 맵을 만들고 무엇을 성공의 측정값으로 사용할지 대략적으로 구상해야 합니다. 팀원이 준비를 갖춘 상태로 참여할 수 있도록 세션 전에 팀원과 공유하세요.

큰 벽이나 화이트보드가 있는 공간에서 기능 킥오프 회의를 예약하세요. 몇 분 일찍 도착하여 그 공간에서 여러분이 매핑한 사용자 여정을 보여주세요.

1단계

기능 개요(10분)

킥오프 회의에 참여한 모든 구성원을 환영하고 기능에 대한 개요와 관련 컨텍스트를 설명하는 것으로 시작하세요. 기능이 어떤 문제나 기회를 다룰지, 그리고 더 폭넓은 목표나 이니셔티브와 어떻게 연결되는지 설명하세요. 연구 자료를 인용하거나 배경 정보를 뒷받침하는 내용을 제시하여 대상 사용자의 페르소나와 이 기능이 그들에게 제공하는 가치를 소개하세요. 그런 다음 성공을 측정하는 방법에 대한 여러분의 생각을 제시하세요.

여기서는 기능 킥오프 전에 "충분한 정도로만" 사양 및 범위 지정을 하면 된다는 점을 기억하세요. 이 단계에는 구멍과 틈이 있기 마련이며 이 회의의 목적은 팀을 하나로 모아 틈을 메우기 시작하는 것입니다.

안티패턴

너무 늦게 공유하는 것. 사양이 "완료"로 간주되면 팀 피드백에 따라 방향을 전환할 기회를 놓친 것일 수도 있습니다.

2단계

피드백 요청(10분)

사용자 여정을 시작하기 전에 잠시 멈추고 팀의 피드백을 받으세요. 침묵이 흐르고 여러 명이 고개를 젓는다면 다음 질문 중 몇 가지를 사용하여 팀원의 대화를 유도하세요.

  • 우리는 이 기능이 무엇을 제공하려는 의도인지에 대해 공통된 이해를 갖추고 있습니까?
  • 이 기능에 바라는 점은 무엇입니까?
  • 이 기능에 대한 우려 사항은 무엇입니까?
팁
프로 팁

대상 고객 페르소나의 관점에서 기능을 소개하여 기능에 생명을 불어넣으세요.

3단계

사용자 여정 검토(15분)

킥오프 회의 전에 개발한 사용자 여정이 기억나십니까? 처음부터 끝까지 검토하세요. 사용자가 기능을 어떻게 발견할지, 어떻게 상호 작용할지, 어떻게 기능 사용을 중단할지 설명하세요. 진행하면서 이 기능이 어떻게 문제 영역을 해결하거나 고객 마찰을 줄이거나 가치를 더하는지에 대해 이야기하세요.

검토 중에 피드백을 받기 위해 잠시 멈추는 대신 모두에게 스티커 메모에 자신의 생각을 작성하도록 요청하세요. 그러면 팀원 한 명으로 인해 의도치 않게 검토가 샛길로 빠지는 것을 방지할 수 있습니다.

4단계

비평 및 대체 솔루션(20분)

사용자 여정 맵의 시작점으로 돌아가세요. 각 단계마다 모두가 스티커 메모를 붙이고 팀의 피드백에 대해 토론하도록 하세요. (스티커 메모에 새로운 질문이나 우려 사항을 적어도 좋습니다.)

각 팀원의 평소 역할은 잊어버리세요. 지금 이 단계에서는 모두가 기능이 실패할 수 있는 방법을 상상해 보고(보안 취약성, 사용성 결함, 기술적인 제약 등) 실패를 방지하는 방법을 제안합니다.

제품 소유자의 답변이나 의사 결정과 더불어 모든 질문과 우려 사항을 서면으로 캡처하세요.

5단계

마무리(5분)

팀에서 무슨 일을 왜 하고 있는지 명확하게 설명하는 데 필요한 다른 정보는 무엇입니까?

기능에 대해 답하지 못한 질문은 팀원에게 할당하고 답변을 제공할 기한을 정합니다. 보통 답변하는 데는 추가 사용자 조사를 하거나 회의 중에 드러난 예외적 사례를 구체화하거나 기술적 디자인의 부분에 대해 생각하는 일이 포함됩니다.

팁
프로 팁

팀의 백로그에 도달하기 전에 기능에 대한 정기적인 피드백 루프가 생기도록 팀의 표준 리추얼에 기능 킥오프 회의를 추가하세요.

성공하셨습니까?

팀과 함께 전체 상태 모니터 세션 또는 체크포인트를 실행하여 개선을 이루고 있는지 확인하세요.

변형

교차 지역 팀

이 플레이는 여러 지역에 있는 팀에 맞게 조정할 수 있습니다. Confluence 페이지에서 초기 단계에 개념을 공유하고 예약한 회의실에 VC가 설치되어 있어야 합니다.

후속 조치

킥오프 회의 후에 팀원이 새로운 질문을 떠올리는 경우 팀원이 생각하는 답변과 함께 질문을 사양에 추가하세요.

질문을 적절한 팀원에게 할당하세요. 제안된 답변이 마음에 들면 동의한다는 것을 표시할 수 있습니다.

더 많은 플레이북을 보고 싶습니까?

새로운 상태 모니터 및 플레이를 추가할 때 통보할 이메일을 아래에 입력 후 전송해주세요.

Thanks! Now get back to work.

의견이 있으십니까?

Atlassian 커뮤니티 사이트에 질문이나 의견을 남겨주세요.