Labs Practices Site – Tanzu 사례

Practices: 영향 분석

Fri, 28 Oct 2022 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

영향 분석을 수행하여 기준선을 수치화할 주요 측정지표를 식별합니다. 예를 들어 프로젝트 또는 제품의 비즈니스 목표가 특정 수작업 프로세스에 소요되는 시간을 줄이는 것이라면 이 활동을 시작할 때 그 내용을 다시 진술합니다.

예: "인보이스 생성 프로세스에 대한 영향 분석을 수행하여 시간을 효율화할 기회가 있는지 알아보겠습니다."
팀이 워크플로우를 매핑할 개인을 식별합니다.
팀이 매핑할 특정 워크플로우를 식별합니다. 계약 흐름 또는 이벤트 예약이 예로 포함될 수 있습니다. "행복 흐름" 워크플로우 매핑을 시작하겠다고 말합니다. "행복 흐름"이란 기업이 특정 흐름 또는 프로세스를 수행할 때 일반적으로 이루어지는 워크플로우라고 정의할 수 있습니다.

예: "먼저 인보이스 생성 프로세스를 매핑하겠습니다. 최적의 워크플로우는 생성 중에 변경이나 인보이스에 오류가 발생하지 않는 것이라고 가정하겠습니다."
참가자와 함께 접착식 메모 하나에 워크플로우의 단계 하나씩 씁니다.
첫 번째 워크플로우 초안이 매핑되면 참가자와 함께 각 단계를 살펴보면서 제대로 매핑되었는지, 단계가 잘못 해석되거나 무시되지는 않았는지 확인합니다.
워크플로우의 각 단계에 대해 논의하고 수치를 추가합니다.

예: "이 단계는 매번 25초가 소요됩니다", "이 단계에서는 거래할 때마다 회사에 $1.25의 비용이 발생합니다"
"행복 흐름" 워크플로우에 소요되는 총 수치를 산출합니다.

예: "계약 수작업 프로세스는 계약을 생성할 때마다 회사에 125분의 비용을 발생시킵니다", "수작업 채용 프로세스는 신규 채용을 할 때마다 회사에 $1,432의 비용을 발생시킵니다"
발생할 수 있는 극단적인 사례를 고려하여 워크플로우에 매핑합니다.

예: "인보이스 생성 중에 단계 X로 인해 수치가 잘못되는 경우 '이상적인 흐름' 워크플로우에서 추가 단계를 수행해야 합니다."
"행복 흐름"에서와 마찬가지로 극단적인 사례 각각에 소요되는 총 수치를 산출합니다. 그러면 "이상적인 흐름" 워크플로우에 추가할 수 있는 다양한 영향을 이해할 수 있습니다.

예: 계약 생성 중에 계약을 수정해야 하는 경우, 해당 작업은 기준 추정치인 125분에 30분을 추가합니다.
선택사항: 참가자가 각 단계에 메모나 위험을 추가할 수 있습니다. 그러면 개선할 수 있는 영역을 더 식별하는 데 도움이 됩니다.

성공/예상되는 성과

전체 워크플로우에서 주요 비즈니스 측정지표에 미치는 영향의 추정치를 파악하면 작업이 완료됩니다.

주요 비즈니스 측정지표의 예시는 다음과 같습니다.수작업 계약 프로세스를 실행하는 데 소요되는 총 시간은 215분입니다.

또한 제품 관리자는 주요 비즈니스 측정지표에 수치를 연동해 제품의 목표 및 측정지표를 자신 있게 조정할 수 있어야 합니다. 그러면 제품 관련 의사 결정과 우선순위 지정 작업에 더 좋은 영향을 줄 수 있습니다.

진행자 메모 및 팁

영향 분석을 통해 여러 변수를 발견할 수 있지만, 영향 분석 활동별로 하나의 변수에 집중하는 것이 좋습니다.
수작업 프로세스를 수치화하고 비즈니스 기회를 식별하다 보면 직원을 중복해서 세는 경우도 있습니다. 비즈니스 측정지표에 인원 수에서 발생하는 운영 비용이 포함되는 경우, 주의를 기울이고 심사숙고해야 합니다. 참가자 앞에서 분석을 얼마나 깊이 있게 수행하기를 원하는지, 그리고 어떤 부분을 개인적으로 논의할 것인지에 대해 이해관계자와 논의하는 것이 좋습니다.
단계가 누락되고 추정치가 부정확해지는 일이 발생하지 않으려면 이 실습에 최소 2명의 실무 전문가(Subject Matter Expert)가 포함되어 있어야 합니다. 워크플로우를 매핑할 때 여기 있는 기존 Tanzu 사례(여정 맵)를 참고 자료로 사용할 수 있습니다.
비즈니스 영향을 측정하는 여정이 제품 주요 사용자의 여정과 동일하지 않을 수도 있습니다.
선택사항: 워크플로우의 단계에 메모(통찰력, 해결 과제)를 추가합니다. 이렇게 하면 향후 제품 개발에 유용할 수 있습니다.

실제 예시

위의 예에는 온라인 양식 제출을 통해 고객 운영 팀이 고객으로부터 인보이스를 조달하는 수작업 워크플로우가 자세히 나와 있습니다.

Practices: 사용 편의성 테스트

Fri, 15 Apr 2022 00:00:00 +0000

이 방식을 활용하는 방법

가정:

테스트하려는 기능이 설계되었으며 프로토타입으로 바뀌었습니다.
대면 또는 화상 회의로 진행되는 사용 편의성 테스트 세션의 대상 사용자 5명을 이미 모집하고 스케줄링했습니다.
진행자 1명과 회의록 작성자 1명이 있습니다.
진행자와 회의록 작성자는 동일인일 수 없습니다.

샘플 안건 및 메시지

소개(5~10분)
- 사용자에게 녹화 관련 동의를 요청합니다.
- 사용자에게 일반적인 정보를 요청합니다.
  - 이름(예: “성함이 어떻게 되십니까?”)
  - 나이(예: “나이가 어떻게 되십니까?”)
  - 직업(예: “직업이 무엇입니까?”)
- 테스트와 관련된 기타 데이터(예: “이전에 음식 배달 애플리케이션을 사용해 본 적이 있으십니까?”)
- 테스트 대상자에게 테스트 중이 아니며 같은 편이라고 말하여 안심시킵니다. 다음 반복 과정에서 설계가 개선될 수 있도록 진심 어린 피드백의 가치를 상기시킵니다.
- 사용 편의성 테스트를 진행하면서 테스트 대상자가 자신의 생각, 행동, 의견을 밝히도록 격려합니다.
  - 도와주는 사람 없이 애플리케이션과 처음 상호 작용하는 사람을 모방하고자 하므로 끝날 때까지 질문에 답변할 수 없음을 알립니다.
- 사용자가 테스트를 진행하기 전에 질문할 수 있도록 합니다.
작업(25~30분)

사용자에게 각 작업을 제공하고, 각자에게 적합한 방식으로 작업을 수행하려는 동안 지켜봅니다.

현실성 있고 실행 가능한 작업을 제공하십시오.

편견을 방지하기 위해, 설계에서 제시된 대로 작업을 완료하는 방법에 관한 힌트를 사용자에게 제공하지 마십시오.
질문과 끝맺는 말로 마무리합니다(5~10분). 다음과 같은 질문을 생각해 볼 수 있습니다.
- 방금 진행한 이 프로세스에 대해 어떻게 생각하십니까?
- 일반적으로 사용하는 툴과 비교해서 방금 경험한 툴은 어떠했습니까?
- 덧붙이고 싶은 사항이 있으십니까?
리서치 결과를 종합합니다(사용 편의성 테스트를 모두 수행한 후).
- 사용자 피드백과 작업 전반에서 추세를 파악합니다.
- 통과/실패 표를 만들어 설계상 효과적인 부분과 그렇지 않은 부분을 빠르게 확인합니다.
- 이해관계자에게 보다 개괄적으로 결과를 발표하는 경우 프레젠테이션으로 만들어 결과를 시각화합니다.

성공/예상되는 성과

사용 편의성 테스트에서 수집한 결과를 통해 현재 진행하고 있는 반복 작업에 따라 설계를 효과적으로 조정하고 개발을 시작할 자신감을 얻었다면 성공한 것입니다.

진행자 메모 및 팁

스크립트 팁: 사용 편의성 테스트를 진행하기 전에 소개, 작업, 마무리 질문을 포함해 스크립트를 작성해 보십시오. 그러면 회의록 작성자가 템플릿을 사용해 더 쉽게 기록할 수 있고 팀은 테스트를 모두 수행한 후 종합할 수 있습니다.

또한 진행자는 일관된 형식을 사용하여 각 세션 간을 원활하게 전환할 수 있습니다. 이를 통해 진행자는 주어진 시간을 더 효율적으로 활용할 수 있습니다.

권장 자료

사용 편의성 테스트 사례를 효과적으로 숙지하려면 Nielsen Norman Group에서 게시한 다음 게시글을 읽어보시기 바랍니다.

Practices: 플러스 /델타 피드백

Wed, 19 Jan 2022 00:00:00 +0000

이 방식을 활용하는 방법

플러스/델타를 활용하면 그룹 설정에서 생성된 팀이나 그룹 기반의 작업보다는 개인 작업에 피드백의 중점을 둘 수 있습니다. 플러스/델타는 소규모 대상 그룹의 빈번한 피드백에 집중합니다.

현재 피드백 문화가 없는 팀의 경우 플러스/델타는 1:1 개인 수준의 정기적인 피드백 주기를 도입하기 위한 가벼운 기술입니다.

샘플 안건 및 메시지

준비: 하루 중 3~5분을 마련하여 사소한 주제부터 큰 주제까지 플러스/델타에 대해 생각해 봅니다.프

예시(플러스):
- “보안 팀과의 외부 회의를 잘 치렀어요.”
- “바로 가기 키를 알려 주셔서 감사합니다.”
- “다음 사용자 스토리를 시작할 때 설계 책임자에게 전달하라고 제안해 주신 내용이 적절했습니다.”
예시(델타):
- “오늘 하루 종일 전혀 쉬지 못했습니다.”
- “오늘 페어 프로그래밍 세션 동안 키보드에 아예 이용하지 않은 것 같습니다.”
- “항상 회의에 5분 늦으시는 바람에 회의를 제 시간에 마칠 수가 없습니다.”
두 명만 있을 수 있는 조용한 공간이나 화상 회의 세션을 찾습니다.
차례대로 플러스/델타를 번갈아 이야기합니다.
피드백에 따라 향후 업무 세션에 대한 변경 사항을 제안합니다.

예를 들면 다음과 같습니다.
- “내일은 오전 11시와 오후 3시에 10분간 휴식 시간을 갖도록 합시다.”
- “내일은 포모도로 기법을 시도해 보고 보다 균형 잡힌 페어링 세션이 되는지 확인해 봅시다.”
- “회의가 연이어 있다면 다음 회의에 늦지 않도록 첫 번째 회의를 제 시간에 끝내도록 합시다.”

성공/예상되는 성과

두 사람 모두 명확하고 간결한 방식으로 균형이 맞게 서로 피드백을 주고 받는 것을 편하게 느끼며, 이를 통해 이상적으로는 플러스/델타 세션 동안이 아니라 필요한 경우에 피드백을 제공할 수 있도록 발전합니다.

플러스/델타 세션 후 두 사람 모두 일상 업무를 수행하면서 계속 진행할 작업과 개선할 활동을 알아갈 것입니다.

진행자 메모 및 팁

프로세스가 10~15분 넘게 걸린 경우 좀더 길고 공식적인 피드백 세션이 이루어질 수 있습니다.

이 활동을 매일 진행하다가 두 참가자가 편안하게 느끼면 빈도를 줄이십시오.

둘 중 한 사람이나 두 명 모두 델타 또는 기타 건설적인 피드백을 주는 것을 불편해할 수 있습니다. 플러스/델타 세션에서 지속적으로 델타가 도출되지 않는 경우 다음 기법을 시도해 보십시오.

먼저 하루가 어땠는지 설명하며 세션을 시작합니다. 두 참가자는 이러한 설명을 기반으로 하며 협업을 통해 플러스와 델타를 도출할 수 있습니다.
더 체계적이면서 비난하지 않는 방식으로 두 사람 모두에게 델타를 제안하기 위해 “플러스 2개, 델타 1개” 형식을 구현하십시오.

스피드백 피드백

권장 참고 자료

Thanks for the Feedback(저자: Douglas Stone, Sheila Heen) – 사람들이 피드백을 해석하는 방식을 이해하기 위한 방법으로서 권장되는 자료입니다.

REwork(저자: Jason Fried, David Heinemeier Hansson)

Practices: 팀 업무 합의

Thu, 06 Jan 2022 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

물리적 또는 디지털/온라인 화이트보드에 같은 크기의 열 3개를 만들고 왼쪽에서 오른쪽 순으로 “아이디어”, “업무 합의”, “아이스 박스”라는 레이블을 표시합니다.
그룹별로 협업하는 방법을 안내하기 위한 기준과 일련의 행동을 함께 만들고 이에 동의하게 될 것임을 팀에게 설명합니다.

팁: 팀에게 열린 자세를 유지하고, 모든 사람이 참여하고, 다른 사람을 방해하거나 혼자만 이야기하지 않도록 요청합니다.
스티커 메모에 작성하기 전에, 팀으로 일할 때 팀에 중요한 사항을 잠시 생각해 보도록 모두에게 요청합니다. 메모를 개인적으로 작성하도록 합니다.

팁: 훌륭한 팀에서 일한 시기, 팀에 우수한 성과를 가져온 요소, 팀의 당면 과제, 이러한 당면 과제를 해소하는 요인과 당면 과제와의 차이점을 되돌아보도록 권장합니다.
팁: 팀원이 메모를 많이 작성하지 않은 경우 진행자가 직접 관찰한 주제를 제안할 수 있습니다. 예를 들면 다음과 같습니다.
- “핵심 업무 시간에 대해 동의한 적이 없습니다.”
- “원격 스탠드업 동안 일부 사람들의 카메라는 켜져 있었고 일부는 꺼져 있었는데 이에 대해 어떻게 생각하십니까?”
- “무계획적인 방식으로 회의를 스케줄링하는 것에 대해 어떻게 생각하시나요?”
이제 각 팀원에게 성공적인 팀을 만드는 데 도움이 될 것이라고 생각하는 합의점을 하나 적고 “아이디어” 열에 추가하도록 요청합니다.

팁: 팀 인원이 5명 미만인 경우 모두가 2개의 합의점을 작성해도 좋습니다.

팁: 모두가 활용할 수 있는 예시 목록을 추가하거나 말합니다. 이러한 예시 목록에는 통화 중 카메라 켜기, 스탠드업 동안 휴대폰 사용 금지, 시간대 간 유연성 등 팀에 필요하나 간과할 법한 적절한 가치가 포함됩니다.

팁: 참가자 수 대비 합의점 수를 확인하고 두 수가 같아질 때까지 그룹이 참여하도록 노력할 수 있습니다.
그룹별로 합의점을 읽은 후 유사한 합의점을 하나의 합의점으로 통합합니다.

팁: 합의점을 대략적으로 작성하고 세부 사항보다는 가치에 중점을 두도록 하십시오. 예: “점심은 항상 오후 12시(EST)에 먹기”는 “매일 점심 휴식 시간 갖기”로 바꾸는 것이 좋습니다.
업무 합의점은 다음과 같은 주제를 포괄하는 것이 좋으므로, 이러한 내용이 화이트보드에 없다면 추가하도록 합니다.
- 핵심 업무 시간
- 회의 스케줄
- 휴식
- 통화 에티켓
- 피드백 제공 방법 및 시기
제안이 너무 구체적이거나 업무 합의 정신과 관련이 없다고 생각되는 경우 제안을 “아이스 박스” 열로 옮깁니다.
각 합의 사항을 팀으로 살펴보고 큰 소리로 읽은 다음 합의 사항 준수에 대한 투표를 시작합니다.

표결이 만장일치 되는 경우에만 합의된 것입니다. 모두 참여하도록 합니다. “반대” 투표가 발생하는 경우 해당 팀원에게 어떻게 하면 “찬성”으로바꿀지 설명을 요청합니다.

해당 팀원의 의견을 수용할 수 있는 경우 제안을 실현하고자 팀으로서 함께 할 수 있는 일을 논의하고 서면 합의 사항을 조정하여 화합을 도모합니다.

합의 사항에 대해 100% 찬성 투표를 얻는 것이 불가능한 경우 제안을 “아이스 박스” 열로 옮깁니다.
모든 합의 사항에 대해 이 작업을 수행했으면 전체 합의 사항에 동의하는 최종 투표를 실시합니다. 계속 진행하려면 다시 한번 표결이 만장일치 되어야 합니다. 만장일치가 불가능한 경우 이전 단계로 돌아갑니다.
마지막으로 합의 사항을 공개적으로 게시하고 모두가 볼 수 있도록 합니다.

팁: 합의 사항을 모두에게 e-메일로 발송하고 되돌아볼 수 있는 공간에 생각할 거리로 추가합니다.

PDF 예시: 팀 업무 합의 문서 예시

성공/예상되는 성과

팀이 모두 투표하고 합의한 일련의 명확한 업무 합의 사항을 제공했으면 이 작업을 성공적으로 완료한 것입니다.

진행자 메모 및 팁

이 연습은 진행이 너무 길어진다고 생각될 경우 시간을 제한할 수 있는 활동입니다. 위에 포함된 여러 팁은 함정을 피할 수 있도록 제시된 것이지만, 시간 지연 문제가 발생하는 경우 팀의 초점을 재설정하거나, 타이머를 설정하거나, 의사결정을 재촉하여 다음 단계로 나아가야 합니다.

또한 단순히 한 행동이 업무 합의 사항에 추가되지 않았다고 해서 팀원이 그러한 행동을 취할 수 없거나 다른 사람에게 그렇게 행동하지 않도록 요청할 수는 없습니다. 아주 드물게 합의 사항에 관해 격렬한 의견 충돌이 발생하는 경우 팀에게 이 점을 상기시키는 것이 좋습니다.

팀 가치

실제 예시

팀 업무 합의 문서 예시:

Practices: 리더십 역할 및 책임

Mon, 03 Jan 2022 00:00:00 +0000

이 방식을 활용하는 방법

참가자에 대하여: 역할을 정의해야 하는 리더십 팀의 모든 구성원이 참여해야 합니다. 예를 들어 포트폴리오 리더십 팀에는 포트폴리오 관리자, 포트폴리오 디자이너, 포트폴리오 엔지니어를 포함해야 합니다.

어떠한 팀원도 빠뜨리지 않아야 하고, 팀원의 관점을 공유하지 않은 채로 역할을 정의하지 마십시오.

샘플 안건 및 메시지

브레인스토밍

개별적으로 각 사람이 수행하는 업무를 스티커 메모에 적도록 합니다. 타이머를 5분으로 설정하고 스티커 메모 1장당 활동 하나를 적습니다. “만들기”처럼 “~하기”로 끝나는 짧은 구(3~8개 단어)를 사용합니다.영감을 얻기 위해 달력을 사용합니다. 시간이 더 필요한 경우 타이머에 5분을 더 추가합니다.
중복 제거

그룹별로 유사한 활동을 함께 모으고 해당 그룹을 그룹의 본질을 담은 한 스티커 메모로 바꿉니다.
“활동”과 “책임” 식별

일반적으로 작성한 업무는 두 그룹에 속합니다. 즉, 결과에 기여하는 활동과 그 결과 자체입니다. 이 워크숍의 첫 번째 단계는 활동과 책임을 혼합하는 것입니다. 역할이 누군가 성공하는 “방법”으로 묘사되지 않기를 바라지만, 성공에 어떤 의미가 있는지를 보여 주고 싶습니다.

활동과 책임에 각각 다른 색을 사용하여 생성된 항목을 색으로 표시합니다. 대면 활동인 경우 스티커 메모를 다시 작성하는 일을 줄이기 위해 시작 시 지침을 제공할 수 있습니다.
활동과 책임 연결

책임 아래에 기여하는 활동을 배열합니다.
연결되지 않은 활동에 대한 책임 만들기

브레인스토밍에서 모든 것을 파악할 수 있다고 기대하지 마십시오. 이 단계는 첫 번째 단계에서 놓친 항목을 파악하는 단계입니다. 책임과 연결되지 않은 각 활동에 대해 기여해야 할 책임이 무엇인지 브레인스토밍합니다. 가능성이 가장 높은 두 가지 결과는 다음과 같습니다. 1) 새 책임을 활동과 연결 또는 2) 결과로 이어지지 않는 활동 파악

팁: 활동에 대해 가치 있는 책임을 찾을 수 없는 경우 더 이상 생각하지 말고 보드에서 제거하십시오.
관련 책임을 역할로 그룹화

이 지점까지 역할의 개념을 회피하고 있었습니다. 특히 기존 역할이나 직함을 파악하는 것을 회피하고 있었습니다. 그 이유는 많은 조직의 경우 수행하는 활동에 따르는 결과를 명확하게 이해하지 않은 채로 역할을 만들고 명명하기 때문입니다. 이 프로세스는 팀으로서 성취하려는 결과로부터 역할을 발전시킵니다.

지금까지의 활동은 제쳐 고 목적, 상호 작용하는 영역 또는 책임지는 분야별로 책임을 그룹화합니다.

예를 들어 두 책임이 외부 파트너와의 관계를 고려한다고 하면, 두 파트너 관계 책임을 Partner Liaison(파트너 연락)이라는 이름의 단일 역할로 그룹화하기로 결정할 수 있습니다.

책임 그룹의 위에 각 역할의 이름을 적습니다.

팁: 한 사람이 여러 가지 역할을 채울 수 있습니다. 역할과 직함이 1:1 관계가 있는지 여부를 결정하려면 워크숍이 끝날 때까지 기다리십시오.
역할별 누락된 책임 찾기

연결되지 않은 활동을 누락한 책임을 찾은 그때가 바로 앞선 브레인스토밍에서 놓친 책임을 상기시키기 위해 새로 이름을 지정한 역할을 활용할 기회입니다.

역할의 목적을 이해하면 추가 책임을 명확하게 밝히는 데 도움이 됩니다(다음 단계 참조).
각 역할의 목적 정의

역할이 존재하는 이유를 정의하고 역할 아래에 씁니다. Partner Liaison(파트너 연락)의 목적은 “파트너 참여를 성공으로 안내”하는 것입니다.
선택 사항: 격차 확인

일에 대해 져야 할 책임을 만들었지만 아무도 책임을 지지 않는다면 이 단계에서 그러한 격차를 다루는 방법을 논의합니다. 이 격차를 다루는 방법을 논의하기 위해 후속 작업 세션이 필요할 것입니다. 팀의 능력이 한계에 이르렀다면 책임을 포기하거나, 다른 사람에게 위임하거나, 새로운 팀원을 고용할 것입니까?
문서 작성 및 공유

워크숍이 끝난 후 역할, 책임 및 활동을 매핑하는 문서를 작성합니다. 워크숍 참석자, 부하 직원, 상사 및 조직에서 이러한 역할을 명확하게 함으로써 혜택을 받는 모든 사람과 문서를 공유합니다.
후속 작업

이 워크숍은 후속 작업이 생성되는 경우가 많습니다. 채용 공고를 다시 확인하거나, 성과를 관리하는 방법을 조정하거나, 조직의 요구 사항에 맞게 팀을 재구성할 수 있습니다.

성공/예상되는 성과

워크숍이 끝난 후 사람들의 역할과 책임에 대한 공동의 이해도가 높아졌을 것입니다. 격차나 결과로서 수행하려는 변경 사항을 다룰 후속 작업도 생겼을 수 있습니다.

첫 번째 단계에서 “제대로” 하는 것이 아님을 인식해야 하되 시간이 지남에 따라 발전하고 향상하는 것이 안전합니다.

진행자 메모 및 팁

역할과 책임에 대한 정보를 생성하는 데 직접 참여할 수 있도록 이 활동은 외부 진행자가 맡는 것이 좋습니다. 그러면 진행자는 공정성을 유지하고 모든 사람의 참여하도록 균형을 유지할 수 있습니다.

Practices: 스택 랭킹(강제 랭킹)

Thu, 18 Nov 2021 00:00:00 +0000

이 방식을 활용하는 방법

참고: 이 기법은 아이디어와 문제의 우선순위를 정하고 조율하는 데 매우 효과적이지만, 더 이상 직원 성과에 대한 모범 사례로 간주되지 않습니다. 자세한 내용은 다음 두 게시글을 참조하십시오.

샘플 안건 및 메시지

우선순위를 지정할 모든 옵션을 모으고 각각을 스티커 메모(또는 동등한 디지털 메모장)에 적습니다.
이러한 옵션을 평가하고 우선순위를 정하는 기준을 함께 결정합니다.

예: 사용자 만족도, 기술적 복잡성, 비즈니스 추진 요인 영향
세로줄을 긋고 선택한 기준에 따라 레이블을 지정합니다.

예: “사용자 만족도 향상”, “비즈니스 추진 요인에 대한 영향 감소”

여기에서, 이 단일 축을 따라 옵션을 전체적으로 배치할 때 팀의 논의를 불러일으킬 수 있는 여러 가지 기법이 있습니다.

변형 - 버블 정렬 기법: 10개 이하의 옵션

옵션을 하나 임의로 선택하여 세로줄 중간에 배치합니다.
두 번째 옵션을 임의를 선택하고 “기준에 따르면, 이 옵션은 첫 번째 옵션보다 높습니까,아니면 낮습니까?”라고 팀에 질문합니다. 팀의 우선순위 결정에 따라 두 번째 옵션을 첫 번째 옵션의 위나 아래에 배치합니다.
모든 옵션이 줄을 따라 세로로 쌓일 때까지, 4단계와 5단계에서 수행한 다른 항목과 관련하여 나머지 옵션을 계속 배치합니다.

변형 - 분류 기법: 10개 이상의 옵션

그룹별로 기준에 따라 옵션을 세 그룹(높음, 중간, 낮음)으로 나눕니다. 그에 따라 그룹을 세로축에 배열합니다.
가장 높은 스택부터 시작하여 각 항목에 대해 논의하고 가치가 높은 항목을 가치가 낮은 항목 위에 두면서 각 항목을 축에 세로로 배치합니다. 스택의 모든 항목을 줄을 따라 세로로 배치합니다.
작업할 충분한 옵션이 줄을 따라 세로로 쌓일 때까지, 필요한 경우 또는 시간이 되는 경우 나머지 스택 작업을 계속합니다.

변형 - 개별 랭킹 및 그룹 비교: 3~9개 옵션, 그룹에 불균형한 직급 역학이 있는 경우

옵션 사본을 만들고 그룹의 개인별로 기준 축을 만들어 각자 순위를 매깁니다.
5분 타이머를 설정하고 각자 기준 축에 따라 옵션의 순위를 매깁니다. 기준에 따라 가장 가치가 높은 옵션을 가장 위에 배치하고 그 아래에 그보다 가치가 낮은 옵션을 세로로 배치합니다.
모두 각자 스택 랭킹을 마치면 직급이 가장 낮은 사람부터 최종 결과를 묻습니다. 모든 사람의 결과를 비교하고 중요한 차이의 이유를 토론합니다. 그룹의 모든 사람이 지지할 수 있는 최종 스택 랭킹을 만듭니다.

성공/예상되는 성과

그룹이 우선순위가 지정된 옵션 스택을 내림차순으로 만들고 가장 우선순위가 높은 옵션을 식별할 수 있으면 성공한 것입니다.

진행자 메모 및 팁

항목이 20개 이상인 경우 선택한 기준과 관련이 없는 옵션을 제거해 보십시오.
모든 참가자가 서로 이해할 수 없다면, 먼저 논의하고 기준이 의미하는 바를 정의하는 것이 좋습니다(예: “비즈니스 영향”이란 무슨 뜻입니까?) 그러면 우선순위 지정 작업을 더 원활하게 진행할 수 있습니다.
의견 일치(모든 사람이 우선순위에 100% 합의)는 거의 실현 불가능합니다. 목표는 집중할 항목을 조정하는 것입니다.
이 방법은 오른쪽 위 사분면의 항목을 사용해 논의되는 항목의 실행 가능한 공격 명령으로 바꾸기 위해 2x2 우선순위 지정 세션 마지막에 사용할 수 있습니다.

실제 예시

권장 자료

Bubble Sort(버블 정렬)

Practices: 서비스 Blueprint

Fri, 08 Oct 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

워크숍을 준비합니다.

고객 인터뷰를 통해 고객이 여정의 어떤 단계에 있는지 파악합니다. 고객 작업 행에 이 단계를 기록합니다.

이해관계자와 작업자를 워크숍에 초대합니다. 작업자가 디지털 서비스인 경우 SME(실무 전문가)를 초대합니다.

팁: 고객 여정 맵의 단계를 끌어옵니다.
워크숍을 진행합니다(1~2시간).

워크숍을 시작하기 전에 고객 여정을 입력합니다.

첫 번째 열에서 시작합니다. 각 작업자에게 행을 채우는 데 5~10분을 줍니다.

단계에 동의하고 다음 고객 작업으로 이동합니다.

마지막으로, e-메일, UI, 텍스트 또는 알림 등 상호 작업에서 나온 실재하는 증거를 기록합니다. 물리적 또는 디지털 증거는 서비스에서 사용하거나 제어할 수 있는 환경의 일부입니다.

팁: 사용자가 이미 알고 있는 내용을 파악하기 위해 증거에서 제시하는 데이터를 살펴보는 것이 좋습니다.
개선 영역을 구분하여 고객 경험을 평가합니다.

경험: 시스템 중단의 원인이 될 수 있는 실패 사항을 가려내거나 워크플로우를 간소화합니다.

최적화: 시간과 비용을 기록하여 기준 측정값을 만듭니다.

이중화: 데이터를 통합하고, 증거를 간소화하고, 해결 과제를 기록하고, 기준을 도입합니다.

팁: 비즈니스 결과와 연결된 측정지표를 사용하십시오. 단계 수, 사용자 불만 등 미래에 비교가 가능할 것 같은 항목을 평가하십시오.
경험을 개선하고, 서비스를 최적화하고, 이중화를 줄일 기회를 찾음으로써 기존 서비스에서 반복합니다.
기존 또는 향후 서비스를 조정하기 위해 팀과 Blueprint를 공유합니다. 피드백을 통해 격차를 해소하고 질문에 답할 수 있습니다.
서비스 설계가 향상되었다고 생각하면 사용 편의성 테스트 또는 솔루션-가정 테스트를 통해 새 모델의 가정을 검증합니다.

팁: 개략적인 수준에서 서비스를 반복하는 경우 단순한 개념으로 작업한 다음, 세부 사항을 생각할 때 더 세분화된 수준에서 작업하십시오.

성공/예상되는 성과

측정값을 비교할 수 있거나, 단일 버전의 서비스에 대해 조율했거나, 서비스 작동 방식을 명확하게 이해했으면 성공한 것입니다.

진행자 메모 및 팁

팀이 단일 버전의 서비스에 대해 조율되면 이 활동의 이점을 최대한 활용할 수 있습니다. 린(Lean) 상태를 유지하고 낮은 충실도로 작업하기 위해 Blueprint는 Miro, 화이트보드 또는 스프레드시트에 작성할 수 있습니다.

비동기 Blueprint 작성

같은 위치에 있지 않은 여러 소규모 그룹을 종합할 때는 워크숍의 Blueprint를 비동기적으로 만듭니다. 이렇게 하면 시간은 더 소요되고 전체 Blueprint가 만들어질 때까지 더 많은 반복이 필요합니다.

용어:

서비스 설계는 (1) 직원의 경험을 직접적으로 개선하고, (2) 고객의 경험을 간접적으로 향상하기 위해 비즈니스 리소스(직원, 툴, 프로세스)를 계획하고 정리하는 활동입니다. NNGroup Service Design 101을 참조하십시오.
작업자는 리소스를 사용하거나 리소스를 다른 작업자에게 제공함으로써 궁극적으로 고객에 도달하는 사람, 디지털 인터페이스 또는 백엔드 시스템입니다.
상호 작용 라인 - 전면에서 고객과 서비스가 상호 작용하는 지점입니다.
가시성 라인 - 이 라인 너머에서 고객은 후면의 서비스를 더 이상 볼 수 없습니다.
내부 상호 작용 라인 - 단계가 타임라인 외부에서 발생하는 지점이며, 일반적으로 서비스를 지원하기 위해 파트너 단계가 발생하는 지점입니다.

선택적 측정:

시간 - 일부 서비스는 다른 시간에 제공되거나 완료까지 다양한 시간이 걸리는 단계가 있습니다.
생각/감정 - 두려움/걱정의 감정에 대한 이해는 고객 결정에 대한 컨텍스트를 제공합니다.
단계 - 대여, 사용, 반환과 같이 서비스가 시간 경과에 따라 밝혀집니다.
백스테이지 분할 - 백엔드 기술을 직원, 데이터, 애플리케이션, 인프라, 부서/팀의 이름으로 나누면 서비스의 다양한 영역이 명확해집니다.

대체 행:

사진/스케치 - 팀은 사진이나 그림을 사용해 단계를 시각화할 수 있습니다.
당면 과제 - 팀은 기존 프로세스 내에서 문제를 논의할 수 있습니다.
아이디어 - 팀은 문제를 해결하는 솔루션을 만들 수 있습니다.

고객 여정 맵

이벤트 스토밍은 비슷하지만 다릅니다.

권장 자료

Service Blueprints: Laying the Foundation, Cooper의 Izac Ross

Service Design 101, NNGroup

Miro’s Guide to Service Blueprints, Miro

Practical Service Design’s Guide to Service Blueprints, Erik Flowers 및 Megan Miller

Practices: 사용자 스토리 작성

Wed, 06 Oct 2021 00:00:00 +0000

이 방식을 활용하는 방법

세 가지 기본 프로젝트 단계에 대해 스토리를 준비해야 합니다.

사용자 스토리를 다듬고 다음 반복 계획 회의 준비(1~2주)
고품질 설계를 위해 사용자 스토리를 준비하지만 일부 세부 사항을 완료하지 않음(2~4주)
제품이 나아갈 방향을 암시하고 리서치 작업에 정보를 제공하기 위해 사용자 스토리를 개괄적으로 구상(1~3개월)

샘플 안건 및 메시지

아이디어, 기능 또는 사용자 스토리로 세분화할 사용자 흐름을 검토하여 시작합니다. 팀과 함께 스토리 매핑 연습을 수행하거나 가벼운 아이디어 세션을 수행하여 기능이나 사용자 흐름을 생성할 수 있습니다.
제목을 작성합니다. 짧고 설명 형식의 제목을 작성합니다. 실행 가능한 제목은 전체 팀이 백로그를 이해하기 쉽습니다.

제목 예시: 영업 담당자가 영업 제안서를 PDF로 다운로드 가능
설명을 작성합니다. “[역할]로서 ...할 수 있도록 ...하기를 원합니다” 형식을 사용하여 이 사례가 사용자 관점에서 제공할 가치를 설명합니다.

설명 예시:

Alex는 영업 담당자로서

잠재 고객에게 e-메일을 보낼 수 있도록

영업 제안서의 PDF 버전을 다운로드하기를 원함

설명을 통해 팀은 누구를 위해 사용자 스토리를 작성하며, 해당 사용자가 소프트웨어에서 이 기능을 원하는 이유, 해당 사용자가 완수하는 데 도움이 되는 사항을 이해할 수 있습니다. 설명에서 이름을 사용하는 경우 이름은 “영업 담당자 Alex”처럼 팀에서 만든 역할을 나타내야 합니다. 또한 임의의 이름일 수 없으며 해당 역할이 의도된 사용자인 모든 스토리에서 일관되어야 합니다.

팁: 애플리케이션 외부에서 발생하는 일에 대해 스토리에서 “...할 수 있도록” 부분을 사용해 보십시오. 이를 통해 가치를 이해하고 있다고 사용자에게 확신을 줄 수 있습니다. “...할 수 있도록” 부분을 작성하는 데 문제가 있는 경우 스토리가 정말 유용한지 자문합니다.

팁: 사용자가 반드시 사람일 필요는 없습니다. 시스템의 작업자와 소비자가 다른 시스템, 소프트웨어 또는 기기인 경우도 있습니다. 이는 이벤트 기반 또는 사물 인터넷 시스템에서 흔한 일입니다. 이러한 시스템의 스토리 작성 방법에 대해서는 이벤트 기반 시스템의 사용자 스토리 작성에 대한 Tanzu 가이드를 참조하십시오.
검증 기준을 작성합니다. 엔지니어가 개발 중 자동화 테스트를 작성하는 데 사용할 시나리오이며, 제품 관리자가 스토리가 제공될 때 검증 테스트에 사용할 시나리오입니다. 검증 기준은 사용자의 관점에서 “수행한” 작업이 어떻게 보이는지 설명합니다. 검증 기준을 통해 팀은 수행해야 할 작업을 이해하고, 방해 요소와 종속성을 파악하고, 복잡도를 파악 및 추정하고, 작업을 테스트하고, 검증 방법을 이해하고, 테스트 기반 개발 방식에 대해 생각할 수 있습니다.

검증 기준 예시:

제안서 요약 페이지 방문한다면

“PDF 다운로드” 버튼 클릭하면

그런 다음 영업 제안서 PDF 파일이 내 컴퓨터에 다운로드됨
필요한 경우 지원 문서와 메모를 추가합니다. 필요한 경우 추가 정보를 포함하여 사용자 스토리를 명확하게 만듭니다. 설계 모형을 포함하는 경우가 가장 많지만, 스토리에 관한 일반적인 메모, 통합과 관련된 문서 등을 포함할 수도 있습니다.

경우에 따라 스토리에 포함되지 않는 사항에 관한 메모를 추가하면 유용합니다. 범위를 벗어나는 사항을 모두 작성하지 마십시오. 스토리에 포함될 수도 있지만 포함되지 않은 한두 가지 덕분에 스토리가 더 명확해질 수도 있습니다.

다음은 전체 예시입니다.
스토리 제목: 영업 담당자가 영업 제안서를 PDF로 다운로드 가능

설명:

Alex는 영업 담당자로서

잠재 고객에게 e-메일을 보낼 수 있도록

영업 제안서의 PDF 버전을 다운로드하기를 원함

검증 기준:

제안서 요약 페이지 방문한다면

“PDF 다운로드” 버튼 클릭하면

그런 다음 영업 제안서 PDF 파일이 내 컴퓨터에 다운로드됨

참고 자료:
- 다른 제품 중 하나에서 이 기능에 대한 예시: <예시 링크>
- 개발자 메모: 다른 팀이 사용하는 PDF 변환 라이브러리: <리소스 링크>
팁: 명료성과 고품질 구현을 위해 사용자 인터페이스 구성 요소가 있는 대부분의 사용자 스토리는 디자이너의 모형 또는 문서를 포함해야 합니다. 와이어프레임부터 고품질 모형, 클릭 가능한 프로토타입 또는 설계 시스템의 구성 요소에 대한 참조까지 무엇이든 가능합니다.

성공/예상되는 성과

다음과 같은 경우에는 훌륭한 사용자 스토리를 작성한 것입니다.

전체 팀이 스토리를 읽고 스토리가 사용자에게 제공하는 가치가 무엇인지 이해할 수 있습니다.
IPM의 스토리에 관한 토론이 원활하고 세부 사항을 명확하게 설명하며 전반적인 방식이 무엇인지 의문을 갖지 않습니다. 이와 관련하여 문제가 있다면 원활하게 스토리를 다듬을 수 있도록 IPM 사전 계획을 고려하십시오.
엔지니어가 개발을 완료하면 스토리를 구분할 수 있습니다.
스토리가 제공되면 쉽게 받아들일 수 있습니다.
팀이 매주 여러 사용자 스토리를 제공합니다.
백로그에 있는 대부분의 스토리를 독립적으로 그리고 다른 스토리와 함께 완료할 수 있습니다.
스토리가 구현 세부 사항을 자세히 이야기하지는 않지만 대신 무엇이 빌드되는지(빌드 방법이 아님)를 설명합니다.

진행자 메모 및 팁

INVEST는 좋은 사용자 스토리의 품질을 기억하기 위한 연상 기호입니다.

독립형 – 제공되는 다른 스토리와 종속성이 없습니다. 제공되는 모든 스토리는 스토리를 제공하기 위해 다른 스토리와 종속성이 없어야 합니다. 한 쌍의 개발자는 백로그의 맨 위에서 스토리 하나를 골라서 백로그의 다른 스토리를 건드리거나 코드에 다른 개발자의 코드를 넣지 않으면서 스토리가 설명하는 가치를 전달하기 위해 필요한 모든 사항을 수행해야 합니다. 자신의 백로그 내에서 종속성을 방지하는 데 문제가 있는 경우 스토리를 보다 독립적으로 만들기 위해 다시 분할하는 방법을 생각하십시오.

협의 가능성 – 기능에 대한 특정 약정이 없습니다. 스토리는 제공될 사항에 관한 엔지니어와 PM 간(또는 제품 팀과 이해관계자 간)의 계약된 합의 사항이 아니라, 제공할 가치를 함께 이해하는 가벼운 문서입니다. 스토리는 개발이 시작될 때까지 필요한 때마다 사용자와 이해관계자의 새 정보 또는 팀의 입력을 기반으로 업데이트되어야 합니다. 개발이 시작되면 스토리를 작업하는 사람들이 변경 사항을 인지하고 이해하지 않는 한, 스토리를 변경하지 마십시오. 그런 경우라도 범위 증가와 새로운 검증 기준 및 구현을 기준으로 재평가의 필요성에 주의하십시오.

가치 제공성 – 사용자에게 기술의 가로 조각(horizontal slice)이 아니라, 진정한 가치를 제공합니다. 전달된 각 스토리는 진정한 가치를 제공해야 합니다. 스토리는 가로 조각(예: 프론트엔드, 백엔드)으로 분할되어서는 안 됩니다. 전체 스택 스토리는 애플리케이션이 항상 배포 가능한(그리고 잠재적으로 릴리스 가능한) 상태임을 보장하고, 팀이 코드 제공이 아니라 작업의 결과에 집중할 수 있도록 합니다.

추정 가능성 – 적절한 근사치를 추정할 수 있습니다. 팀의 개발자는 스토리의 범위를 충분히 이해하여 관련된 노력이나 복잡도를 추정할 수 있어야 합니다. 추정하기 위해 지나치게 자세히 설명하지 않도록 하십시오. 구현 세부 내용은 스토리로 작성되지 않고 개발자에게 남겨두어야 합니다.

간소 – 반복에 적합하도록 가능한 한 작게 만듭니다. 스토리는 가치를 제공하면서 최대한 짧아야 합니다. 이상적으로 각 반복에서 여러 스토리를 제공할 것입니다. 그 결과 피드백 주기가 짧아져서 팀이 더 빠르게 배우고 필요한 경우 궤도를 수정할 수 있습니다. 또한 짧은 스토리는 테스트 또는 스테이징 환경에 지속적인 제공을 지원합니다.

팁: 여러 블록의 검증 기준이 있고(특히 많은 “그리고”), 개발자로부터 복잡성이 높다고 평가받거나(피보나치 점수 8), 반복 계획 회의 동안 의견이 갈리는 대화가 계속되면 스토리가 너무 방대하다는 신호입니다. 긴밀한 피드백 고리와 명확한 테스트 시나리오를 보장하기 위해 너무 방대한 스토리는 짧고 독립적인 스토리로 나누어야 합니다.

테스트 가능성 – 아직 테스트가 작성되지 않았더라도 원칙적으로 평가해야 합니다. 이는 스트를 이미 작성했음을 의미하지는 않지만, 스토리를 제공한 후에는 스토리를 테스트할 방법이 있어야 합니다.

이전 단계

다음 단계

실제 예시

권장 자료

Tanzu 가이드: 이벤트 기반 시스템에 대한 사용자 스토리 작성

Tanzu 학습 과정 - 최신 애플리케이션 개발 사례 기초: 영향력 있는 결과의 우선순위 지정: 사용자 스토리, 평가, 속도

Practices: 사후 분석

Wed, 28 Jul 2021 00:00:00 +0000

이 방식을 활용하는 방법

먼저 인시던트를 정의하겠습니다.

라이브 제품에서 사용자와 제품 간 상호 작용을 중단하는 이벤트
개발 프로세스에 큰 영향을 미치는 예기치 못한 부정적인 이벤트
오류 예산 위반

샘플 안건 및 메시지

세션 전에 인시던트에 관한 정보를 최대한 많이 수집합니다. 예를 들어 관련 팀에 정보를 요청하는 설문조사를 보낼 수 있습니다. 팀에서 진행 중인 인시던트에 관해 메모한 경우 해당 메모도 수집합니다.

또한 세션 전에 타임라인을 만든 다음 사후 분석 세션을 진행하는 동안 검증하면 유용합니다.

타임라인 예시:

사후 분석 세션에 적합한 사람들을 초대하십시오. 예를 들면 다음과 같습니다.
- 핵심 팀: 제품 관리자, 엔지니어, 디자이너
- 관련 당사자로, 주요 역할을 수행하며 인시던트와 관련된 사람 예를 들면 다음과 같습니다.
  - 플랫폼 팀 구성원
  - 보안 팀 구성원
사후 분석의 목표 설명(5분)

다음과 같이 말할 수 있습니다.

“최근 인시던트의 원인은 무엇입니까? 어떻게 해결하셨습니까? 향후 이런 인시던트를 방지하기 위한 작업 항목을 정의하고 사후 분석 문서에 문서화하려고 합니다. 비난받을 사람을 찾으려는 것이 아닙니다.”

팁: 어떤 일이 발생했으며 향후 이러한 일이 일어나지 않도록 방지하기 위한 방법을 확인하고자 하므로 비난하지 않는 문화를 포용하십시오. 각 팀원이 심리적으로 편안하도록 하십시오.
인시던트 타임라인 제시(5분)

인시던트 타임라인을 표시하고 팀과 함께 확인합니다.
사후 분석 주제 브레인스토밍(5분)

팀에게 스티커 메모 또는 디지털 워크스페이스에 다음을 작성하도록 요청합니다.
- 잘못된 사항 - 최근 인시던트의 원인은 무엇입니까?
- 효과적인 사항 - 인시던트를 해결하는 데 효과적이었던 작업은 무엇입니까?
- 운이 좋았던 경우 - 도움이 된 이벤트/항목이 있습니까?
빠른 주제 클러스터링(5분)

팀에게 비슷한 주제를 기반으로 스티커 메모를 클러스터링하도록 요청합니다.
각 클러스터 논의(20분)

각 클러스터에 대해 논의할 시간을 충분히 줍니다. 특정 클러스터에 시간이 더 필요한 경우 해당 주제에 관한 후속 세션을 고려해 보십시오.

“잘못된 사항” 열에 있는 클러스터의 경우, “왜 이런 일이 발생했습니까?”와 “이런 일이 다시 발생하는 경우 어떻게 해야 영향을 줄일 수 있습니까?”도 질문합니다.

팁: “5 Whys” 방법을 사용해 보십시오. 개인을 비난하지 말고 프로세스로 인한 근본 원인에 집중하십시오.
작업 항목 논의(15분)

인시던트를 해결하고 향후에 발생하지 않도록 방지하기 위해 수행할 수 있는 작업은 무엇인지 팀과 논의합니다. 이러한 작업의 소유자를 정의합니다.
사후 분석 소유자 관련 합의(4분)

팀으로서 다음과 같은 책임을 담당하는 사후 분석 소유자를 결정합니다.
- 향후 참조를 위해 다음을 포함하는 사후 분석 문서 작성
  - 인시던트 개요
  - 인시던트를 해결하기 위한 작업 항목
  - 근본 원인 분석
  - 교훈 및 향후 인시던트 발생을 방지하기 위한 다음 단계
- 사후 분석 상태에 관하여 이해관계자와 커뮤니케이션
- 사후 분석 회의의 모든 작업 항목이 수행되었는지 확인하기 위한 검토 회의 계획
후속 작업 스케줄링(1분)

작업을 검토하기 위해 후속 사후 분석 세션에 대해 팀과 합의합니다. 팀이 모든 사후 분석 작업을 완료할 때까지 인시던트를 종결해서는 안 됩니다.

성공/예상되는 성과

이 활동이 끝나면 팀은 인시던트가 무엇이었으며 어떻게 발생했는지 명확하게 이해할 수 있습니다. 또한 팀은 인시던트 재발을 방지하거나 그 영향을 줄이는 계획을 수립했을 것입니다.

진행자 메모 및 팁

사후 분석 문서 예시:

Google의 사후 분석 예시: Shakespeare Sonnet++ Postmortem
@dastergon의 사후 분석 템플릿
의
Google GitHub의 “sredocs”

권장 자료

Atlassian Incident management

Google Postmortem culture

책: Life of a production system incident(출간 예정)

Practices: 반복 사전 계획

Wed, 14 Jul 2021 00:00:00 +0000

이 방식을 활용하는 방법

시작하기 전에 팀으로서 IPM(반복 계획 회의)의 결과에 따라 반복 사전 계획의 필요성을 결정합니다. 일반적인 조짐은 다음과 같습니다.
- IPM이 속도를 따라가기 위해 필요한 것보다 적은 스토리 평가로 끝나는 경우가 종종 발생합니다.
- IPM이 할당된 시간을 초과하여 진행되는 경우가 종종 발생합니다.
- 평가가 “바이크쉐딩”으로 인해 주안점에서 벗어나는 경우가 많고 이는 미참여나 불만 야기로 이어집니다.
- 평가 전에 스토리 범위를 조정하는 경우가 많습니다.
- 평가 전에 스토리에 중요하거나 필요한 세부 사항이 없는 경우가 종종 있습니다.
- 팀이 IPM 중 스토리를 광범위하게 수정하는 경우가 종종 발생합니다.
이러한 문제의 원인을 파악하는 데 세심한 기술 전문가나 자원봉사 엔지니어를 초대하십시오.
그룹별로 IPM에서 평가하려는 첫 번째 사용자 스토리를 선택하고 자세히 읽습니다. 오타, 자리 표시자 또는 기타 간단한 수정이 필요한 경우 읽으면서 수정합니다.
엔지니어에게 질문하고 의견을 묻고 필요하거나 팀을 위해 필요할 것으로 예상되는 명확한 설명 등을 요청하여 평가할 준비가 되었는지 결정합니다. (IPM까지 스토리를 평가하지 마십시오.)
우려 사항을 최소화하기 위해 그에 따라 스토리에 대해 논의하고 스토리를 수정합니다.

이 회의 시간 동안 필요한 변경 사항을 해결할 수 없는 경우(예: 더 많은 리서치가 필요한 경우) IPM을 위해 준비한 스토리 목록에서 해당 스토리를 제거하고 나중에 후속 조치합니다.

모든 우려 사항을 파악해야 하는 것은 아닙니다. 결국 엔지니어링 2명이 팀 전체의 통찰력을 복제할 수는 없습니다. IPM 동안 문제가 되거나 방해가 될 가능성이 가장 큰 항목을 신속하게 해결하는 데 집중하십시오.

향후 이러한 문제를 방지하는 방법에 대한 논의도 적절합니다.
이 회의를 위해 준비된 나머지 사용자 스토리에 대해서 2~4단계를 반복합니다.

성공/예상되는 성과

IPM을 위해 마련한 모든 스토리가 참석한 엔지니어에 따라 평가될 준비가 되면 성공한 것입니다. 1단계에서 확인된 문제가 개선된 것으로 관찰되면 제대로 하고 있는 것입니다.

진행자 메모 및 팁

반복 사전 계획은 비교적 편안한 논의인 경향이 있습니다.
결과가 완벽할 필요는 없으며, 원치 않고 관련 없는 사항에 대한 낭비를 유발할 가능성이 높은 문제를 파악하는 “첫 번째 과정”으로서의 역할만 수행하면 됩니다.
반복 사전 계획에 참석하는 엔지니어는 스토리 작성에 참여했기 때문에 IPM 중 스토리에 표현된 제품 방향을 지지하는 입장입니다.
반복 사전 계획은 스토리 품질에 대한 자세한 피드백을 받을 수 있는 좋은 기회이며, 참석한 모든 사람에게 스토리 작성자로서 발전할 기회입니다.

변형

현재로서는 없음

이전 단계

현재로서는 없음

다음 단계

IPM(반복 계획 회의)

실제 예시

권장 자료

Practices: IPM(반복 계획 회의)

Thu, 17 Jun 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

회의를 위한 대화의 틀을 마련하는 것부터 시작합니다. 최근 승인된 스토리와 진행 중인 스토리나 검증 환경에서 최신 기능의 현재 상태를 간략하게 요약하여 필요에 따라 전반적인 프로젝트 컨텍스트를 설정하여 이 다음 반복을 시작할 때 모든 사람이 현재 상황을 파악하고 있도록 합니다. 제품에 추가할 사항을 요약하여 새로운 사용자 스토리를 검토합니다. 사용 가능한 경우 사용자 인터페이스 모형을 제시합니다.
첫 번째 사용자 스토리를 꼼꼼히 읽고 비즈니스 가치, 사용자 가치, 검증 기준을 설명합니다. 참가자에게 질문하도록 허용하고 필요한 경우 명확하게 설명합니다.

팁: 모든 팀원이 편안하게 평가할 수 있도록 필요한 설명을 얻을 수 있도록 하십시오. 대화를 이어나가는 개인의 성격 또는 전체 팀의 이해를 방해하는 방식에 주의하십시오.
엔지니어가 사용자 스토리를 평가할 준비가 되면 알려주도록 하고, 준비가 되면 동시에 스토리 점수 평가에 투표하여 스토리의 상대적인 복잡도를 평가하도록 유도합니다.

평가와 관련된 팁은 아래에 있는 간단한 평가 가이드를 참조하십시오.
평가에 대한 의견이 일치하면 평가 결과를 사용하여 사용자 스토리에 레이블을 지정하고 백로그에 승격하여 팀에게 이 스토리의 우선순위를 보여 줍니다. 또는 의견이 일치하지 않는 경우, 팀이 만족하는 의견 일치가 나올 때까지 토론하고 필요한 경우 다시 평가하도록 엔지니어를 유도합니다.

팁 1: 대화가 너무 길어지거나 해당 사용자 스토리의 범위에서 너무 벗어나지 않도록 하십시오. 명확하지 않은 부분이 많거나 해당 스토리의 범위에서 의견이 일치되지 않는 경우, 향후 IPM에서 합리적으로 평가할 수 있으려면 조사 또는 실험을 위해 제품 백로그에 작업을 추가해야 할 수도 있습니다.

팁 2: 사용자 스토리는 구현에 구애받지 않아야 합니다. 상대적인 복잡성을 평가할 때 구현에 대한 논의가 당연히 발생하지만, 이러한 논의를 개괄적인 수준으로 유지하고 구현에 관한 자세한 논의는 보류하십시오.
이 회의를 위해 준비된 나머지 사용자 스토리에 대해서 2~4단계를 반복합니다.

팁: 가능한 시간을 활용하여 준비된 사용자 스토리를 최대한 많이 논의하고 평가하십시오. 필요한 경우 일부 사용자 스토리를 다음 반복 계획 회의로 연기할 수 있습니다. 계획한 것보다 많은 시간을 들여 팀의 소중한 에너지를 소모하지 마십시오.
회의 마지막 10분 동안, 엔지니어링 작업을 포함하여 제품 백로그 항목의 상대적인 우선순위를 검토하고 논의합니다.

팁: 엔지니어가 제품 백로그로 승격하려는 작업의 범위와 중요성에 관해 조언하도록 유도하십시오.

성공/예상되는 성과

첫 번째로, 팀은 논의된 제품 백로그 항목의 범위와 상대적인 복잡성에 대해 다 같이 이해해야 합니다. 두 번째로, 제품 백로그에 항목을 추가하여 현재 우선순위에 따라 정렬되어야 합니다. 팀은 다음 반복에서 나올 작업에 대해 일치되고 활기를 얻은 느낌으로 IPM을 마쳐야 합니다.

진행자 메모 및 팁

IPM을 보다 효과적으로 진행하기 위해 회의에서 논의될 사용자 스토리가 사전에 적합하게 다듬어져 있는지 확인하십시오. 디자이너 및 엔지니어와 협업하여 스토리가 실행 가능하며 INVEST 기준을 충족하도록 만드십시오. 회의 중에 스토리를 급하게 작성하지 마십시오.
필요한 작업을 생성하도록 엔지니어를 격려하고, 필요한 경우 엔지니어와 협업하여 IPM 전에 해당 작업의 우선순위를 정하고 다듬으십시오.
평균 팀 속도에 따라, 논의 및 평가할 사용자 스토리를 이미 준비했으며 제품 백로그에 3회 이내의 반복 작업이 포함된 경우에만 IPM을 진행하십시오. 지나치게 평가하는 경우, 평가의 정확성이 떨어지고 팀이 해당 사용자 스토리에 대한 작업을 시작할 때까지 컨텍스트를 잊어버릴 수 있습니다.

간단한 평가 가이드

제품 백로그에 3회 이상의 반복에서 전에 평가된 사용자 스토리가 있는 경우, 팀이 도움이 될 것이라고 동의한다면 IPM에 대해 스케줄링된 시간을 활용해 다음 사용자 스토리를 검토하고 다시 평가하십시오.
복잡성은 제품 백로그의 다른 사용자 스토리와 비교해서 또는 기준 사용자 스토리와 비교해서 평가될 수 있습니다.
상대적인 복잡성은 작업 완료에 걸리는 시간에 비해 사용자 스토리의 크기를 평가하는 보다 쉽고 신뢰할 수 있는 방법입니다.
평가는 일반적으로 “스토리 점수”를 사용해 수량화되고, 팀은 프로젝트 전체에서 사용할 점수 척도를 미리 일치시켜야 합니다(예: 피보나치, 직선, 지수).
편견을 방지하기 위해 평가를 동시에 수행하는 것이 중요합니다. 동시에 수행하는 좋은 방법은 셋을 세면 참가자가 투표하도록 하는 것입니다.
큰 스토리 점수 평가는 분할된 스토리가 여전히 사용자에게 유용한 경우, 사용자 스토리 분할을 제안할 수 있습니다.
검증 시험/검증 이후 수행할 작업이 거의 없거나 없는 사용자 스토리의 경우 스토리 점수 0점으로 평가될 수 있습니다.
스토리 점수 평가가 정확하지 않아도 괜찮습니다. 같은 제품을 작업하는 같은 팀은 일반적으로 시간이 지남에 따라 더 정확하고 일관되게 평가합니다.
일반적으로 평가는 엔지니어 또는 작업을 제공할 사람만 수행해야 합니다. 테스터나 아키텍트 같은 기타 역할은 상대적인 복잡성을 충분히 이해하면 평가할 수 있습니다.

스프린트 계획 대 반복 계획

스크럼 “스프린트”와 “반복”은 모두 시간이 제한된 활동이지만 계획 수행 방식에 영향을 미치는 차이점이 있습니다.

	스프린트 계획	반복 계획
사전 요건	• 스프린트 목표 • 우선순위가 지정된 제품 백로그	• 우선순위가 지정된 제품 백로그 • 검토할 사용자 스토리
목표	• 스프린트 목표 일치 • 스프린트 범위 협의 및 계획(스프린트 백로그)	• 현재 범위 및 우선순위에 대한 공동의 이해 유지(제품 백로그)
활동	• 사용자 스토리 검토 • 제품 백로그의 스토리를 스프린트 백로그로 이동	• 사용자 스토리 검토 • 사용자 스토리 평가 • 우선순위에 따라 사용자 스토리를 제품 백로그로 승격
출력	• 팀이 스프린트 마지막에 제공하고 보여주기 위해 전념하는 우선순위가 지정되지 않은 스프린트 백로그	• 우선순위가 지정된 제품 백로그 • 반복 중 제공되고 보여줄 수 있는 작업에 대한 평가
참가자	• 제품 소유자 • 엔지니어	• 핵심 팀

이전 단계

반복 사전 계획(선택 사항)

권장 자료

Agile Estimating and Planning(저자: Mike Cohn)

Yesterday’s Weather

Planning Poker

Chapter 12 of Extreme Programming Explained의 12장(저자: Kent Beck, Cynthia Andres)

ExtremeProgramming.org

Practices: 2x2 우선순위 지정

Tue, 15 Jun 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

준비: 그룹별로 관련성 높은 2가지 우선순위 지정 조건에 동의합니다.

예: 영향 대 가능성, 가치 대 복잡성, 리스크 대 완화 용이성
수직으로 서로 교차하는 축 2개를 만들고, 선택한 기준 중 하나를 사용하여 각 축의 레이블을 지정합니다.

팁: 오른쪽 위 사분면이 가장 중요한/우선순위가 가장 높은 것을 나타내도록 축에 레이블을 지정합니다. 이 사례를 반복해서 사용할 때 용이하게 만드는 규칙입니다.
임의로 옵션을 선택하여 가운데 근처에 배치합니다.
그룹별로 다른 옵션을 선택하고 그리드의 다른 옵션과 관련해서 세로로/가로로 배치합니다.

팁: 두 옵션을 같은 열이나 행에 배치하지 마십시오. 각 옵션은 모호함을 방지하기 위해 각 축의 고유한 가로/세로 위치에 명확하게 배치되어야 합니다.
모든 옵션이 그리드에 배치될 때까지 4단계를 반복합니다. 우선순위가 가장 높은 옵션은 오른쪽 위 사분면에 배치되어야 합니다.

팁: 옵션이 특정 절반 또는 사분면에 몰리는 경우 절반가량이 각 축의 양쪽에 놓이도록 옵션을 재배치할 수 있습니다. 그러면 모호성이 없어지고 우선순위를 결정하기가 더 쉬워집니다.

성공/예상되는 성과

그룹이 집중할 옵션(또는 옵션들)을 결정했으면 성공한 것입니다.

진행자 메모 및 팁

오른쪽 위 사분면에 우선순위 솔루션이 너무 많으면 해당 사분면 내에 축을 다시 그려서 솔루션을 또 나눕니다. 축은 절대적인 것이 아니라 상대적이기 때문에 이렇게 해도 괜찮습니다. 관리 가능한 지점에 도달할 때까지 계속 조정하십시오.
옵션이 너무 많으면 이 사례가 더 어려워지고 시간이 많이 걸릴 수 있습니다. 항목이 20개 이상인 경우 선택한 기준과 관련이 없는 옵션을 제거해 보십시오. 선택한 우선순위 기준에 대해 평가할 수 있는 사람을 참여시킵니다(예: 디자이너는 유용성에 대해 이야기할 수 있고, 엔지니어는 기술 복잡성에 대해 이야기할 수 있음).
X/Y축 전에 2x2에 대한 프롬프트를 개발합니다. 축에 대한 프롬프트가 없으면 그룹은 배치와 집중이 힘들 것입니다.
X축과 Y축에 대한 검증 요소를 선택할 때는 다음을 고려합니다.
- Y축의 경우 논란의 여지가 별로 없는 검증 요소를 선택합니다. 강력한 예/아니요 표현의 검증 요소는 사람들이 처음 배치할 때 도움이 되며, 이러한 검증 요소를 통해 그룹은 토론이 별로 없는 항목의 자격을 박탈할 수 있습니다(X축 아래로 이동).
- X축을 따라 토론하기를 원하므로 토론의 여지가 더 많은 검증 요소를 선택합니다.

통찰력 우선순위 지정

문제 우선순위 지정

솔루션 우선순위 지정

실제 예시

권장 자료

ProductPlan의 2×2 Prioritization Matrix

Practices: 린(Lean) 실험

Mon, 10 May 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

팀에 린(Lean) 실험 소개

린(Lean) 실험이 무엇이며 수행하는 이유를 설명하고 일반적인 실험 유형을 소개합니다.

“린(Lean) 실험은 극도의 불확실성 조건에서 새로운 제품과 서비스를 만드는 린 스타트업(Lean Startup) 접근 방식을 기반으로 합니다. 린(Lean) 실험은 신속하고 경제적으로 증거를 수집하도록 설계되어 제품에 관한 위험한 가정을 검증하거나 무효화합니다.”

일반적인 실험 유형:

A/B 테스트

제품 또는 기능의 두 버전을 비교하여 성능이 가장 우수한 버전을 파악합니다. 실험 및 비즈니스 모델의 점진적인 최적화를 위해 사용자가 많은 경우 적합합니다.

컨시어지 테스트

복잡한 자동화 기술 솔루션을 고객과 직접 상호 작용하는 사람으로 바꾸는 기술입니다. 누구나 제품을 원하는지 여부를 검증하는 데 도움이 됩니다.

오즈의 마법사 테스트

제품 백엔드를 사람으로 바꾸는 기술입니다. 고객은 자동화 솔루션과 상호 작용하고 있다고 생각합니다. 누구나 제품을 원하는지 여부를 검증하는 데 도움이 됩니다.

스모크 테스트

일반적으로 제품의 가치 제안을 설명하고 제품 출시 전에 고객에게 제품에 등록하도록 요청하는 웹 사이트입니다. 누구나 제품을 원하는지 여부를 검증하는 데 도움이 됩니다.

팁: 소개 자료와 예시를 자유롭게 만드십시오. 올바른 방향으로 생각할 수 있도록 추가 예시를 말하십시오. 고유한 제품 영역과 비교할 만한 예시를 찾을 수 있으면 더 좋습니다.
팀의 “맹신” 가정에 대한 카탈로그 작성

팀이 연습 전반에서 참조할 수 있도록 이 용어를 정의와 함께 화이트보드에 추가합니다(가정이 잘못되면 제품이 실패할 가능성이 높음).

2분 동안 스티커 메모에 맹신 가정을 브레인스토밍하도록 팀에 요청합니다. 팀원이 가정을 3개 이상 찾으면 가장 중요한 것으로 스스로 줄여보도록 요청합니다.

화이트보드에 제품의 검증되지 않은 맹신 가정을 작성합니다.

팁: 부정적인 가정(누구도 낯선 사람의 자동차에 타고 싶지 않음)보다는 긍정적인 가정(사용자가 낯선 사람의 자동차에 타는 것을 안전하다고 느낌)을 만들어 보십시오. 그러면 증거를 얼마나 가지고 있는지 또는 증거가 얼마나 필요한지 생각하기가 쉬워집니다.

맹신 가정을 두 개 이상 생각해 냈으면 가장 먼저 집중해야 할 가정을 우선순위 1번으로 지정합니다. 가정 사례를 사용하거나 Y축에 “프로젝트를 중단할 가능성 높음” vs. “프로젝트를 중단할 가능성 낮음”과 X축에 “더 많은 증거 필요” vs. “많은 증거가 있음”의 2x2를 사용해 보십시오. 더 많은 증거가 필요한 프로젝트를 중단할 가능성 높음 가정이 대상입니다.
가정을 반증 가능한 가설로 전환해야 함을 설명:

[구체적인 테스트 가능한 작업]으로 [기대하는 측정 가능한 결과] 도출

가설, 실험 및 측정을 추적하는 데 사용할 형식/템플릿을 소개합니다.

예를 들면 다음과 같습니다.
- 린(Lean) 실험 템플릿(PDF)
- Strategyzer 테스트 카드(PDF)
다음 각각이 나타내는 것을 설명합니다.
- 가설 — 진실이라고 믿는 것
- 실험 — 가설을 검증하기 위해 실행할 테스트
- 측정 — 검증을 위해 살펴볼 신호
- 결과 — 성공 및 실패 기준
팁: 실험 시간을 제한하는 것을 잊지 마십시오. 실험 실행 시간의 길이를 미리 정의해야 합니다.

팁: 팀이 좋은 측정지표를 만드는 것에 익숙하지 않은 경우 기본 지침서나 예시를 제공하십시오.
실험 생성

각 팀원에게 종이 한 장을 나눠 주고 다음과 같이 하도록 지시합니다.
- 가설 및 실험 템플릿 형식 복사
- 반증 가능한 가설로 맹신 가정 작성
팁: 참가자가 5명 이상인 경우 팀을 나눠 실험을 생성하십시오.

팁: 워크숍 전에 템플릿을 인쇄하거나, 팀에 e-메일을 보내 공유하거나, 디지털 워크스페이스에서 제작 및 공유하십시오.

다음 Miro 보드를 자유롭게 복사하십시오. Miro에서 검증 리서치/MVP 실험

모든 사람이 5분 동안 개별적으로 가설과 관련 측정 가능한 결과를 테스트하는 실험에 대해 생각해 보도록 합니다.
실험 공유

시간이 다 되면, 그룹 토론을 위해 각 팀원(한 명씩)이 벽에 종이를 붙이고 실험 세부 내용을 공유하도록 합니다.

팁: 팀 피드백의 실험 반복이 권장되어야 합니다.

모두 5분 동안 실험을 공유하도록 합니다.
실험 선택

가장 좋은 실험은 최소한의 노력으로 최대한 많은 것을 얻는 것이라고 설명합니다. 팀원에게 가장 잘 실행한 실험에 조용히 점 투표를 하도록 합니다(그룹 규모와 실험 수에 따라 1표 또는 2표).

팁: 실험이 개선되어야 한다고 생각하는 경우 팀에게 실험을 다시 설계하도록 말하십시오. 여러 팀원을 지정하여 동일한 가설에 대해 $200로 2일, $2,000로 2주, $20,000로 2달이 걸리는 실험을 만드십시오. 실험에 적합한 규모를 찾고 작은 규모로 배우는 방법을 권장하는 데 도움이 됩니다.
실험을 평가하는 방법 논의

실험을 선택하고 평가 방법에 대해 이야기합니다. 일반적으로 실험은 세 가지 학습 결과로 이어지는데 각각에는 예상되는 다음 단계가 있습니다.
- 불확실성 > 추가 테스트 및 실험 반복 가능
- 검증됨 > 진행
- 무효화됨 > 회전
모든 결과에 대해 실험 결과와 계획된 다음 단계를 기록합니다. Strategyzer의 The Learning Card를 활용하면 좋습니다.

팁: 실험에 대실패 조건을 설정하는 것은 좋은 방법입니다. 완전히 실패해서 실험 자체가 문제임을 나타낼 수 있습니다. 우리는 무언가를 테스트하기 위해 그것이 진실이라고 믿기 때문에 대실패는 발생할 가능성은 낮습니다.
다음 단계 및 작업 항목 계획

브레인스토밍한 다음 팀원에게 실험을 실행하기 위해 수행할 작업을 할당합니다.
실험 추적기 만들기

이 세션에서 선택되지 않았던 백로그의 실험을 계속 추적합니다. 이 실험을 정기적으로 검토하고, 특히 제품 방향이 변경된 경우 관련 실험을 실행하여 제품 방향을 검증합니다.

성공/예상되는 성과

전체 팀이 실행할 준비가 된 문서화된 린(Lean) 실험을 조율했으면 성공입니다.

진행자 메모 및 팁

검증할 가정이 많은 경우, 위의 마지막 단계에 제시된 것처럼 가정/실험 추적기를 사용한 후속 작업을 고려하십시오. 어떤 가설을 어떤 순서로 테스트해야 하는지 시각화하고 관련 실험을 시각화하는 데 도움이 됩니다.

가정

이전 단계

가정

실제 예시

권장 자료

Lean Startup(저자: Eric Ries)

Lean Product Playbook(저자: Dan Olsen)

Practices: 3열 회고

Mon, 03 May 2021 00:00:00 +0000

이 방식을 활용하는 방법

원격 팁: 분산된 팀의 경우 Miro 또는 이와 유사한 “디지털 화이트보드”를 사용하고 디지털 환경에 그리기 및 스티커 메모 사용과 같은 대면 환경의 요소를 도입하십시오.

팀의 회고를 지원하는 여러 가지 온라인 툴이 있습니다. 아래 ‘원격 팀의 경우’ 섹션에 몇 가지 툴이 나열되어 있습니다.

샘플 안건 및 메시지

화이트보드 또는 디지털 워크스페이스에 열 3개를 그립니다.
- 효과적인 사항(“만족함”)
- 질문(“궁금함”)
- 기회(“별로 훌륭하지 않음”)
각자 10분 동안 각 열 아래에 항목을 추가하도록 합니다. 카드당 아이디어 1개입니다. 추가할 수 있는 카드 수에 대한 제한은 없으며, 모든 사람이 자유롭게 항목을 추가하고 아이디어를 내고 우려를 표명할 수 있어야 합니다.
5분 동안 팀원에게 토론하기에 가장 중요하다고 생각하는 카드에 투표하도록 합니다.
한 열부터 시작하여 득표수가 가장 많은 카드에 대해 토론합니다. 진행자는 “효과적인 사항”부터 시작하여 긍정적인 관점에서 회고를 시작할 수 있지만, 시작 위치는 개인에게 달려 있습니다. 카드 작성자에게 작성한 내용을 다듬을 시간을 더 주십시오.
후속 작업이 필요한 항목의 경우, 카드를 “작업 항목” 섹션/열에 추가하고 지원자에게 각 작업을 책임지도록 요청합니다.

팁: 한 명이 혼자서 작업 항목을 책임질 수 없으므로 지원자에게 짝을 지으라고 요청하십시오.
다음 열로 이동하고 득표수가 가장 많은 카드를 논의합니다.
모든 카드를 다룰 때까지 또는 5분만 남을 때까지 5~7단계를 계속합니다.

팁: “효과적인 사항” 항목으로 회고를 끝내십시오. 긍정적인 관점에서 회고 논의를 끝내는 것입니다.
나머지 5분 동안 작업 항목을 검토하고 각 항목이 개인 또는 두 사람에게 할당되었는지 확인하십시오.

성공/예상되는 성과

핵심 팀이 다음 사항을 다 같이 이해했으면 성공한 것입니다.

한 주, 스프린트, 프로젝트 계획 반복 또는 어떤 기간이든 해당 기간 동안 발생한 가장 중요한 일이 회고 주제임
현재 직면하고 있는 당면 과제
개선하기 위해 시도할 실행 가능한 단계

진행자 메모 및 팁

이번이 팀의 최초 회고인 경우 배경을 제공하고 회고에 수반되는 기대를 설정합니다.
건설적이고 존중하는 대화 자세를 유지합니다.
수요일마다 회고 시간을 갖습니다. 그러면 몇 가지 이점이 있습니다. 첫 번째, 작업 항목을 다음 월요일이 아니라 즉시(다음날) 이행할 수 있습니다. 이를 통해 팀원 간 진행 상황을 더 잘 추적할 수 있습니다. 두 번째, 팀원들의 참여율은 주말보다 주중에 더 높은 경향이 있으므로 모든 사람의 참여율을 높일 수 있습니다.
작업 항목을 성공적으로 관리하려면 동사로 시작하고, 구체적으로 지시하고, 달성 가능한 목표 날짜를 포함하고, 소유자를 최소 한 명 이상 두십시오.
각 회고의 작업 항목을 관리하는 것은 중요합니다. 팀이 회고 후 팀의 활력을 높이기 위한 조치를 취하지 않는다면 회고에서 얻을 수 있는 이점이 없습니다.
격주 회고를 수행할 수도 있지만, 매주 수행하는 회고를 통해 최적의 피드백 루프 빈도를 제공하면 사전 예방적으로 팀의 역동성을 개선할 수 있습니다.
각 카드의 시간 제한 논의를 통해 회고에서 최대한 많은 카드를 다룰 수 있습니다.
이전 회고의 작업 항목을 효율적으로 추적하기 위해 전체 팀이 볼 수 있는 Kanban 보드(‘백로그’, ‘진행 중’, ‘완료’)를 만드십시오(또는 원격으로 수행하는 경우 Miro 보드).
가능한 경우, 팀원이 일상적인 업무와 분리해서 회고에만 집중할 수 있도록 회고를 수행할 때에는 다른 환경을 만드십시오. 다른 층으로 이동하거나 팀에 간식을 제공할 수 있습니다.
회고가 끝나면, 논의하고 싶었으나 다루지 않은 카드가 있는지 물어보십시오.

‘돛단배’ 형식의 미래 회고

변형

원격 팀의 경우

사용할 수 있는 무료 회고 툴이 많이 있습니다.

Atlassian의 팀 회고 Miro 템플릿
Trello 템플릿 - Glad, Sad, Mad
Postfacto - 오픈 소스로, 배포 가능
스프레드시트 - Google Sheets 또는 Excel을 사용하여 간단한 3열 회고 보드를 만들 수 있습니다.

적극적으로 관리되고 개선되는 유료 툴을 사용하는 것도 괜찮습니다. 몇 가지 옵션은 다음과 같습니다.

이름	가격	참고
Fun Retro	GBP £84/월, 6팀 사용 가능(팀당 £14/월)	인정받는 툴
TeamRetro	USD $90/월, 6팀 사용 가능(팀당 $15/월)	다양한 기능을 갖추고 인정받는 툴
Retrium	팀당 USD $29/월	다양한 기능을 갖추고 인정받는 툴
ScatterSpoke	사용자 100명당 USD $225/월(사용자당 $2.25/월)	다양한 기능을 갖추고 인정받는 툴
Neatro	팀당 USD $17/월	단순한 UI
Parabol	사용자당 USD $6/월	오픈 소스. 인정받는 툴
goReflect	사용자당 USD $2.67/월	단순한 UI
Reetro	무료 등록, 유효 업그레이드 기능	다른 옵션에 비해 덜 인정받는 툴

실제 예시

Postfacto 사용 예시

사용할 수 있는 무료 회고 툴이 많이 있습니다.

Miro를 사용하는 재미있는 테마의 3열 회고

이러한 온라인 툴을 통해 사용자는 재미있는 테마로 참여율을 높일 수 있습니다.

권장 자료

Agile Retrospectives - Making Good Teams Great(저자: Esther Derby, Diana Larsen, 서문: Ken Schwaber)

How to Run a Really Good Retrospective - Nicola Rushton의 블로그 게시물

Measure Success in Agile Retrospectives – Enrico Teotti의 비디오

Practices: 가치 스트림 맵

Wed, 28 Apr 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

워크숍의 목적을 설명합니다.

제품 개발 수명주기를 예로 사용합니다. 다음과 같이 말할 수 있습니다.

“제품 개발 수명주기를 확인하기 위해 사용자가 피드백을 제공하는 순간부터(예: 스토리 작성) 운영 시 배포까지 기능을 따라가 보겠습니다. 향후 상태 전에 현재 배포 프로세스에 집중하겠습니다. 현재 어떤 일이 발생하고 있는지 파악하는 것이 실제 방해 요소를 신속하게 밝히고 이해관계자에게 이상적인 워크플로우를 빠르게 제시할 수 있기 때문입니다. 또한 단계뿐만 아니라 각 단계의 역할과 리드 타임도 알아보겠습니다.”
현재 제품 개발 프로세스로 시작합니다. 화이트보드 한쪽 끝이나 디지털 공동 작업 보드의 섹션에 선택한 가치 스트림의 첫 번째 단계를 적습니다. 다른 쪽 끝에 마지막 단계를 적습니다.

제품 개발 수명주기에 대해 첫 번째 단계로 “사용자 피드백”을 적고 마지막 단계로 “운영 환경에 릴리스”를 적습니다.

팁: 팀이 엔드포인트를 결정하는 데 문제가 있는 경우 “이 여정에 대한 작업이 언제 끝날까요?”와 같은 질문을 하십시오.
그룹이 가치 스트림의 처음부터 끝까지 발생하는 개괄적인 단계를 가능한 한 자세하게 파악하도록 합니다. 스티커 메모에 각 단계를 적고 화이트보드에 순서대로 배치합니다. 필요한 경우 반복합니다.

팁: 이상적으로 처음부터 끝까지 이동할 수 있겠지만, 스티커 메모를 간편하게 이동시킬 수 있으므로 순서에 얽매이지 마십시오. 팀으로서 아이디어를 내기 시작합니다.
그룹이 모든 개괄적인 단계를 올바른 순서로 파악했다고 만족하면 이 흐름을 다시 반복합니다. 이번에는 다른 스티커 메모 또는 화이트보드의 각 단계에 대해 다음과 같은 정보를 파악합니다.
- 이 단계에서는 무슨 일이 발생하는가?
- 이 단계는 어디서 발생하는가?
- 이 단계는 누가 담당하는가? (예: 자동인가 수동인가, 언제 참여해야 하는가, 직원인가 제3자인가)
- 이 단계는 언제 발생하는가? (예: 진행되려면 어떤 일이 발생해야 하는가)
- 이 단계는 얼마나 지속되는가? (예: 프로세스 시간)
- 리드 타임은 얼마나 필요한가?
- 이 단계에 관한 효과적인 부분이나 문제 부분은 무엇인가?
- 이 단계가 완료되었는지 어떻게 알 수 있나?
- 전체 가치 스트림은 얼마나 지속되며 팀은 이에 대해 어떻게 생각하나?
팁: 위 질문은 예시입니다. 컨텐츠에 적합한 모든 “렌즈 데이터”를 사용하여 문제를 전체적으로 파악하십시오. 핸드오프를 신경 쓴다면 명확하게 파악하십시오. 시스템 터치 포인트를 시각화하고 싶으십니까? 서비스 Blueprint 형식의 세부 사항을 포함하십시오. 간단히 말해서 중요한 사항을 파악하십시오.
팀이 뒤로 물러서서 흐름을 검토하고 잘못된 점을 조정하도록 합니다.
가치 스트림 맵이 현재 프로세스의 적절한 가상화라고 생각하면 전체 프로세스의 총 리드 타임을 계산하고 팀과 함께 토론하여 개선할 영역을 찾습니다.
“향후” 프로세스에 대해 2~6단계를 반복합니다.

성공/예상되는 성과

화이트보드에 시각적 가치 스트림이 있고 팀이 현재 프로세스를 정확하게 나타내고 있다고 확신한다면 성공한 것입니다.

진행자 메모 및 팁

일부 팀은 프로세스에서 “낭비”라고 불리는 아이디어에 민감합니다. 이 활동의 목적을 규정하는 또 다른 방법은 효율성을 높이는 기회로 삼는 것입니다.

제품 개발 관련 7가지 낭비

부분적으로 수행한 작업(릴리스할 수 없기 때문에)
추가 기능(지금 당장 또는 아마도 항상 필요하지 않기 때문에)
재학습(새로운 것을 배우고 작동하는 소프트웨어를 릴리스하느라 시간을 빼앗기기 때문에)
핸드오프(대기로 이어지고 커뮤니케이션이 추가되기 때문에)
지연(팀의 작업 속도를 늦추기 때문에)
작업 전환(집중을 흐리고 작업 속도를 느리게 만드는 컨텍스트 전환으로 이어지기 때문에)
결함(작업 주기를 추가하기 때문에)

이벤트 스토밍

서비스 Blueprint

변형

운영 환경 경로 연습

실제 예시

제품 개발 수명주기 예시

권장 자료

Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation(저자: Mike Osterling & Karen Martin)

The Seven Wastes of Software Development - Michael Szul의 블로그 게시물

Software Development Waste - Todd Sedano의 학회 논문

Lean Software Development: An Agile Toolkit(저자: Mary Poppendieck & Tom Poppendieck)

DevOps Processes: Value Stream Mapping(Mandy Storbakken 작성)

Practices: “돛단배” 형식의 미래 회고

Fri, 16 Apr 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

다음 메시지를 쓰거나 그룹에게 표시합니다.

“지금부터 반년 후를 상상해 보십시오. 제품 사용자로부터 아주 만족스러운 피드백을 방금 들었습니다. 기대한 모든 것이며 그 이상이라는 피드백입니다.”

팀에게 10분 동안 목표나 비전이 어떻게 보일지에 대해 스티커 메로 한 장당 아이디어를 하나씩 작성하도록 요청합니다.
5분 동안 논의하고 팀원이 아이디어를 낸 목표 중 가장 좋은 목표에 투표합니다.
다음 메시지를 쓰거나 그룹에게 표시하여 생각해 보도록 합니다.

“앞서 말한 목표나 비전을 달성하기 위한 작업을 수행했다고 상상해 보십시오. 어떤 사례를 어떻게 사용했습니까? 팀으로서 이해관계자, 고객 및 사용자와 어떻게 협업했습니까? 효과적인 작업을 위해 어떻게 했습니까?”

팀에게 10분 동안 이러한 긍정적인 사례를 작성하도록 요청합니다.
다음 메시지를 쓰거나 그룹에게 표시합니다.

“다음으로, 그 과정에서 발생한 문제(닻)와 더불어 이러한 문제를 어떻게 해결할지 상상해 보십시오.”

10분 동안 팀원에게 상상의 과거에서 경험한 문제 및/또는 장애물을 쓰도록 합니다.

10분 동안 팀에게 문제를 해결한 방법을 쓰도록 요청합니다.

다시 말해, 팀은 목표나 비전을 달성하는 것을 방해하는 미래에 발생할 수도 있는 문제를 완화하거나 최소화하기 위해 지금 무엇을 할 수 있습니까?

성공/예상되는 성과

팀에 긍정적인 사례 그룹이 있고 활동 끝에 작업을 할당했다면 성공한 것입니다.

진행자 메모 및 팁

미래 회고 템플릿(돛단배, 경주용 자동차 등)을사용하여 팀이 활동을 더 잘 시각화하도록 지원합니다.
일부 미래 회고에는 목표나 비전을 달성하는 방법에 관한 대화를 보다 용이하게 하기 위해 추가 섹션이 필요할 수 있습니다(예: 사전 대응식으로 해결해야 하는 발생할 수 있는 리스크).
활동 동안 혼란을 피하기 위해 시작할 때 회고와 미래 회고의 차이점을 토론해 봅니다.
템플릿(공개): 미래 회고를 비롯하여 여러 회고 유형이 있는 공개 Trello 보드

실제 예시

권장 자료

경주용 자동차 미래 회고 Miro 템플릿

Practices: 스피드백 피드백

Fri, 26 Mar 2021 00:00:00 +0000

이 방식을 활용하는 방법

팀 외부 사람이 신속한 피드백 세션을 진행하는 것이 좋습니다. 이 사람은 미리 스피드백 개념 소개(관련 준비 작업 강조 포함), 공간과 순서 계획(누가 누구에게 언제 어디서 이야기하는지), 시간 준수/강제 전환 등을 담당하고, 요청한 경우 피드백 세션 진행을 지원할 수 있어야 합니다. 기본적으로 이 사람은 피드백 세션에 참가하지 않습니다.

팁: 두 사람당 10분이 시작하기에 좋지만, 시간은 조정할 수 있습니다. 경험이 있는 노련한 팀의 후속 스피드백 세션은 5분으로 줄일 수 있습니다.

원격 팁: 분산 팀의 경우 이러한 피드백 세션을 위해 화상 회의와 “소회의실”을 사용하십시오.

추가 원격 팁은 아래 변형 섹션에 있습니다.

샘플 안건 및 메시지

필요한 경우 15분 세션 동안 아래 자료를 사용하여 스피드백에 대해 설명합니다. 팀이 스피드백 스타일의 피드백 세션에 처음 참가하는 경우 특히 도움이 됩니다.

VMware Labs Practices Site 슬라이드의 스피드백
스피드백 세션을 진행함을 팀에게 알리고 준비하는 방법을 알립니다.

팁: 진행자 메모 및 팁 섹션의 e-메일 템플릿을 자유롭게 수정하고 사용하십시오.
캘린더 초대를 보내 시간과 장소를 정합니다. 원격인 경우 화상 회의 세션을 포함합니다. 두 명씩 짝을 이룰 것이므로 참가자 수 절반에 해당하는 수의 회의실 또는 화상 회의 세션이 필요합니다.

예: 8명으로 구성된 팀의 경우 회의실 4개를 예약하거나 전용 회상 회의 세션 4개를 설정합니다.
스피드백 세션 전에 참가자에게 피드백을 준비하도록 미리 알립니다.

팁: 세션 전에 모든 팀원이 다른 팀원에 대한 서면 피드백을 준비하는 것이 좋습니다. 그러면 세션이 빠르고 원활하게 진행되고 팀원에 대한 존중을 나타낼 수 있습니다.

피드백은 이상적으로 긍정적인 생각과 하나 이상의 건설적인 생각을 포함해야 합니다. ASK(Actionable, Specific, and Kind) 프레임워크처럼, 링크가 제공된 스피드백 슬라이드 자료에 설명된 피드백 프레임워크 중 하나를 사용해 보십시오.
일정을 설정합니다. 예를 들어 4명의 참가로 구성된 팀에서는 다음과 같이 설정할 수 있습니다.
- 오후 1시~오후 1시 5분 회의실 1: 다 함께 시작, 질문 시간 - 모든 참가자
- 오후 1시 5분~오후 1시 15분 회의실 1: 참가자 A와 B
- 오후 1시 5분~오후 1시 15분 회의실 2: 참가자 C와 D
- 오후 1시 15분~오후 1시 25분 회의실 1: 참가자 A와 C
- 오후 1시 15분~오후 1시 25분 회의실 2: 참가자 B와 D
- 오후 1시 25분~오후 1시 35분 회의실 1: 참가자 A와 D
- 오후 1시 25분~오후 1시 35분 회의실 2: 참가자 B와 C
- 오후 1시 35분~오후 1시 45분 회의실 1: 다 함께 마무리 - 모든 참가자
- 오후 1시 45분~오후 2시 15분: 휴식/반성 시간 - 팀 나들이 또는 업무로 돌아가기 전 휴식
스피드백 시간. 지정된 세션에서 참가자 한 명이 다른 참가자에게 피드백을 주고, 5분간 논의합니다. 참가자는 메모를 작성하면서 참여할 수 있습니다. 5분 후 서로 역할을 바꿉니다.

팁: 필요한 경우, 참가자는 후속 세션을 스케줄링하여 피드백을 자세히 논의할 수 있습니다.
10분이 지나면 다음 스피드백이 시작되고 각 참가자는 다른 팀원과 짝이 됩니다. 모든 참가자가 서로 피드백을 줄 때까지 이 과정을 계속합니다.
진행자는 시간을 엄수합니다. 짝이 역할을 바꾸지 않거나 할당된 시간을 초과하면 이를 알리고 마무리하도록 합니다.

성공/예상되는 성과

일대일 상호 작용이 끝나면 팀을 모두 모아 스피드백 세션을 어땠는지, 학습한 내용 중 공유하고자 하는 사항, 세션 개선을 위한 제안 사항, 다음 세션 일정, 그 밖에 생각나는 사항에 대해 요약합니다.

스피드백은 높은 집중력을 필요하고 분위기가 압도적일 수 있으며, 스피드백 이후에 약간의 휴식이나 반성 시간을 갖는 것이 중요합니다. 각자 자신만의 활동을 하거나, 팀이 커피나 아이스크림을 먹으러 나갈 수 있습니다. 무엇을 할지 마무리 시간 동안 결정할 수 있습니다.

팁: 팀 나들이 또는 기타 업무 외(원격 참가자도 가능한) 사회적 활동을 미리 계획하십시오. 피드백 세션으로 카타르시스를 느낄 수 있습니다. 세션 후 친해지는 시간을 갖는 것이 좋습니다.

진행자 메모 및 팁

주저하는 팀원을 참여시키기 위해 스피드백을 어떻게 제시할 수 있습니까?

주저하는 팀원에게 팀원이 개별화된 피드백을 주고 받으면 프로젝트에 직접적인 가치가 창출된다고 설명합니다. ASK 피드백 시스템을 설명하고 참여하는 모든 사람이 비슷하게 느낄 가능성이 많다는 점을 설명합니다.

또한 스피드백 세션을 보고 참가하는 행동 자체가 시간이 지남에 따라 팀원이 변경되더라도, 팀 내에서 지속적인 피드백을 권장하는 유용한 프로세스/툴입니다.

스피드백은 다른 피드백 방법과 어떻게 다릅니까?

참가자는 짧은 시간 동안 다양한 피드백을 받습니다. 한 시간 동안 다른 세 명에게 비슷한 피드백을 받는 것이 피드백을 한 달에 걸쳐 세 번 받는 것보다 훨씬 더 영향력이 강합니다.

스피드백은 모든 사람이 팀에서 개인으로서 어떻게 하고 있는지 빠르게 상태를 점검하고 피드백을 바탕으로 목표를 설정할 수 있는 좋은 방법이기도 합니다.

스피드백은 외부자가 시작하고 외부자가 진행하며 모든 참가자가 같은 입장이라는 점에서 보다 민주적으로 보이는 장점이 있습니다. 피드백 세션은 A라는 사람이 B라는 사람과 함께 명확하게 시작하기 때문에 보기보다 위압적이지 않습니다.

스피드백이 만병통치약은 아님

스피드백의 단점은 시간이 제한된 특성 때문에 한 가지 주제를 깊이 살펴보기가 어렵다는 것입니다. 참가자는 언제든지 후속 세션을 스케줄링하여 대화를 계속할 수 있습니다.

스피드백은 팀이 어려움을 겪고 있을 때나 팀의 상태가 침체하고 있는 조짐이 있는 경우에 매우 효과적일 수 있습니다. 그러나 팀 상태나 사기가 이미 떨어졌거나 대인 관계가 악화된 경우 스피드백은 문제를 해결하기에 좋은 형식이 아닙니다.

e-메일 템플릿

다음 e-메일 템플릿을 자유롭게 사용하고, 스피드백 세션의 규모에 따라 필요한 경우 수정합니다.

[팀 이름] 여러분, 안녕하세요.

다음 주 여러분이 모두 가능할 때 “스피드백” 세션을 진행하려 합니다. 스피드백 세션이란

피드백이지만, 스피드 데이팅 스타일입니다. 모든 사람이 시간이 제한된 방식으로 다른 사람과 피드백을 주고 받을 기회가 있습니다.

작동 방식

사람들이 짝을 지어 서로 10분간 피드백을 제공합니다. 각 사람은 약 5분 동안 피드백을 주고 약 5분 동안 피드백을 받은 다음 짝을 바꿉니다. 이 팀에는 팀원이 4명 있습니다. 즉, 각각 10분 동안 3명의 사람들과 이야기할 수 있습니다. 저는 진행과 시간을 엄수하는 역할을 합니다. 캘린더에 45분을 기록했습니다. 회의실을 바꾸고 질문에 답하는 데 시간이 더 걸릴 수 있기 때문입니다.

사전에 준비해야 할 것이 있습니까?

물론입니다. 스피드백은 피드백을 생각해 내는 시간이 아니라 제공하는 시간입니다. 회의 전에 모든 팀원을 위한 피드백을 생각하는 데 시간을 할애하고 내용을 적어 두십시오. 스티커 메모 3개나 메모 앱에 글머리 기호를 사용하여 각 사람에 대해 다음과 같은 형식으로 메모를 적어 두는 것이 좋습니다.

해당 사람이 잘 수행하고 있다고 생각하는 것

해당 사람이 개선할 수 있다고 생각되는 영역

해당 사람에게 할 질문 또는 제안

그런 다음 해당 사람과 함께 그 글을 읽고 차후에 메모를 건네주거나 전송합니다. 원하는 방식으로 피드백을 제공할 수 있지만, 기억에 의존하거나 최악의 경우 말하면서 말을 만들어 내는 것보다는 피드백을 적는 것을 권장합니다. 세션이 열리기 전에 피드백을 적어 둘 수 있도록 미리 알려 드리겠습니다.

제 피드백이 가치 있으려면 어떻게 해야 합니까?

이와 관련하여 여러 가지 문서가 있습니다. 사람 간 피드백 - 말하기와 워크샵 데크에는 자세한 제안 사항이 담겨 있습니다.

칭찬을 기반으로 하는 것이 쉽습니다. 모든 사람을 위해 건설적인 피드백을 적어도 한 가지 생각해 두십시오.

변형

원격 팀의 경우

팀 전체가 같은 곳에 위치해 있다면 대면으로 스피드백을 개최해 보십시오. 하지만 팀이 부분적으로라도 원격 환경을 사용할 경우 화상 통화를 이용하여 전체 세션을 원격으로 준비하십시오.

팁: 대면과 화상 통화를 혼합하여 세션을 개최하는 것은 좋지 않습니다. 형식을 전환하느라 시간을 낭비하게 될 것입니다. 한 명이 원격 환경에 있다면, 모두가 원격 환경을 사용하는 것처럼 세션을 취급하십시오.

화상 통화를 영리하게 준비하고 채팅으로 참여를 촉진하면 사람들이 가상으로 회의실에 들어와 피드백을 주고받을 수 있으며, 진행자는 채팅 앱이나 화상 회의 툴을 사용하여 사람들에게 전환을 알릴 수 있습니다.

원격 관련 팁: 많은 화상 통화 시스템은 보다 긴밀한 협력을 위해 일시적으로 대규모 그룹을 더 작은 그룹으로 분리하는 “소회의실” 또는 이와 유사한 수단을 지원합니다.

8명 이상의 참여자가 있는 대규모 팀에서 이 기능은 어떻게 작동합니까?

그룹이 대규모라면 스피드백을 준비하는 것이 논리적으로 까다로울 수 있습니다. 또한 일부 팀은 엔지니어만으로 이루어진 그룹 같은 분야별 세션이 효과적일 수도 있습니다.

2개 이상의 소규모 세션을 마련하여 사람들이 보다 긴밀하게 협력할 수 있도록 하십시오(일주일 내의 기간 동안).

예를 들어 5명과 같이 팀의 참여자 수가 홀수인 경우에는 어떻게 합니까?

각 라운드에서 언제든 특정 시점에 사람 한 명이 혼자 앉게 됩니다. 이 사람은 이 시간 동안 이전 사항을 되새기고 다음을 준비하거나 휴식을 취할 수 있습니다.

권장 자료

사람 간 피드백 - 말하기와 워크샵 – 프레젠테이션

VMware Tanzu 개발자 센터 슬라이드의 사람 간 피드백 - 말하기와 워크샵

Practices: 성과 중심 로드맵

Tue, 02 Mar 2021 00:00:00 +0000

이 방식을 활용하는 방법

고정된 기능과 날짜를 중심으로 로드맵을 구성하지 않고 성과 중심 로드맵을 사용하면 우리가 달성하고자 하는 가치가 무엇인지 시각적으로 소통을 주고받으면서 동시에 구현 방식을 유연하게 유지할 수 있습니다.

성과 중심 로드맵은 일반적으로 시작 시나 그 직후에 작성되며, 즉각적으로 초점을 맞추기 위해 MVP의 틀을 구축할 때 여러 문제와 기회의 우선순위를 지정하는 데 도움이 됩니다. 그러나 로드맵은 시간이 지나면서 변화하는, 말하자면 살아 있는 문서입니다.

이 세션은 일반적으로 제품 임무와 비전, 그리고 전략이 이미 있거나 제품이 기여해야 하는 비즈니스 목표와 측정지표를 알고 있는 경우에 효과적입니다.

샘플 안건 및 메시지

성과와 결과의 차이점 설명(5분)

결과는 제품이 수행하는 행위이며, 기능 같은 것입니다.

성과는 비즈니스 결과를 견인하는 측정 가능한 행동의 변화입니다. 성과는 일련의 기능과 이러한 기능이 제공하도록 의도된 가치의 ‘이유’를 설명합니다.

팁/예시: 예를 들어 악기 소매점의 경우 성과는 '고객이 여러 가지 악기를 보도록 하는 것'일 수 있습니다. 하지만 이 성과는 우편으로 주문 카탈로그를 보내거나, 고객이 살펴볼 수 있는 웹 페이지를 구축하거나, 악기 연주가가 자신이 사용했을 때 악기의 모습을 확인할 수 있는 증강 현실 제품을 개발하는 등 여러 결과를 거쳐 달성할 수 있습니다. 이 모든 결과는 성과를 달성하는 데 도움이 될 수 있지만 특정 결과가 다른 결과에 비해 보다 성공적인 성과를 내는 경우도 있습니다.

너무 초기에 잠재적으로 성공적이지 않을 수 있는 결과에 과도하게 집중하는 것보다는 로드맵을 작성하면서 성과(“이유”)를 명확하게 그리는 데 초점을 맞추어야 합니다.

이해관계자는 특정 기능이 필요한 이유의 맥락과 관계없이 해당 기능과 정해진 제공 날짜에 초점을 맞춰 시간에 따른 기능과 관련한 로드맵에 익숙할 수 있으며, 가장 가치 있는 것을 우선으로 릴리스할 유연성을 가지고 있지 않을 수 있습니다. 반면에 성과 중심 로드맵을 사용하면 우리가 구축하는 것의 가치를 명확하게 규정하고 가장 가치 있는 것을 먼저, 이후에 가치가 덜한 것은 차후 점진적으로 릴리스할 수 있습니다.
비전 및 전략 이해(5~15분)

제품에 대한 비전 선언문이 있다면, 선언문을 적어 보드에 붙여 봅니다. 그리고 모든 사람이 선언문을 이해하는지 확인합니다.

팁: 비전 선언문이 준비되지 않았다면, 15분가량의 비전 연습(사례 제공 예정)을 안건에 추가하여 팀이 이해할 수 있도록 지원하십시오.

이 비전을 달성하기 위한 전략을 요약하여 집단 전체의 이해를 보장합니다.
성과 브레인스토밍(10분)

3명끼리 그룹을 나누어 전략적 접근 방식에 부합하는 잠재적인 성과를 신속하게 생성한 다음 출력하거나 Miro 보드를 사용하여 대형 스티커 메모 또는 성과 카드를 통해 비전을 달성하십시오.

팀원에게 비전과 관련하여 제공하고자 하는 성과가 무엇인지 향후 6~12개월로 스스로를 제한해서 생각해 보라고”

이때 자세하게 설명할 필요는 없습니다. 여기에서는 질보다 양이 중요합니다.

이러한 성과는 성과 중심 로드맵의 단계를 형성할 것입니다.
신속한 우선순위 지정(10분)

그룹이 자신의 생각을 빠르게 공유하도록 지원합니다. 이를 통해 다른 그룹에게도 아이디어를 제공할 수 있습니다.

구성원들이 가장 중요하다고 생각하는 성과 2, 3개를 그룹별로 논의하십시오. 모든 그룹을 합쳐서 10개의 성과를 만들어 내는 것이 목표입니다. Zoom 소회의실 기능은 시간이 제한된 원격 소규모 그룹 논의에 적합합니다.

10개 이상의 성과가 도출되면 보드에 적고, 중복되는 항목을 합치고, 투표를 통해 관리 가능한 수까지 줄여 보십시오.

팁: 팀이 대규모인 경우 각 그룹에게 1, 2개의 성과만 도출하라고 요청하십시오.
각 성과에 대해 성과 카드 작성(40분)

이제 그룹이 다음을 고려하여 성과를 살펴보고 각 성과에 대해 카드를 작성할 차례입니다.
- 해당 성과가 가져다주는 가치/사용자 혜택
- 성공 시 해당 성과의 모습
- 사용자에게 이 성과가 필요할지 여부에 대해 얼마나 자신 있는지
- 이 성과가 사용자/비즈니스에 얼마나 가치 있는지
- (선택 사항) 잠재적인 기능
- (선택 사항) 리스크
- (선택 사항) 종속성/방해 요소
- (선택 사항) 대상 사용자
- (선택 사항) 가정
카드당 최대 4분까지 할애하십시오.

팁: 팀이 구축할 항목에 대해 정해진 아이디어를 수립했다면, 이는 자신들의 아이디어를 세분화할 좋은 기회입니다. 해당 항목이 제공하는 가치를 생각해 보고 가치 제공 여부를 평가할 측정지표를 설계하십시오.
성과 우선순위 지정(20분)

2x2 표를 구성하고, 회의실에 있는 경우 파란색 마스킹 테이프를 사용하여 각 축에 레이블을 지정합니다.
- X축 - 노력이 덜 필요한 항목(오른쪽)에서 더 많은 노력이 필요한 항목(왼쪽), 또는 비전 및 성과의 특성에 따라 지정
- X축 - 달성하기 쉬운 항목(오른쪽)에서 달성하기 어려운 항목(왼쪽)
- Y축 - 고객 또는 비즈니스에 더 많은 가치를 가져다줄 것으로 생각되는 항목(상단)에서 고객 또는 비즈니스에 더 적은 가치를 가져다줄 것으로 생각되는 항목(하단)
전체 팀과 함께 이 사분면에서 필요한 노력과 제공하는 가치에 따라 성과 카드를 구성합니다. 원형으로 한 바퀴 진행하거나 한 사람씩 진행할 수 있습니다. 한 성과를 다른 성과와 정확히 동일한 가치를 제공하거나 동일한 노력이 수반되는 것으로 구성해서는 안 됩니다. 그렇게 되면 우선순위를 지정하기 어렵습니다.

팀원에게 이 과정이 가치와 노력에 대한 완벽하거나 최종적인 판단이 아님을 상기시킵니다. 이는 당시의 정보를 기반으로 판단한 팀의 대략적인 생각일 뿐입니다.

팁: 때때로 고객 가치와 비즈니스 가치가 충돌할 수 있습니다. 예를 들어 데이팅 사이트에서 고객은 가능한 빨리 적절한 사람을 찾는 것을 더 가치 있다고 여기는 반면, 비즈니스에서는 이들을 더 오래 플랫폼에 머물게 하는 것이 더 가치 있다고 여길 수 있습니다. 이러한 경우 제품 이해관계자가 이러한 가치 간의 우선순위를 지정하도록 하고, 그들이 우선적으로 고려하는 가치를 분명하게 명시합니다.

이 시점까지 가치가 무엇인지, 성과가 얼마나 가치 있다고 생각하는지, 이를 구축하는 과정이 얼마나 힘들거나 쉬운지, 이 성과가 필요하다는 점에 대해 얼마나 확신이 있는지를 나타내는 2x2 표를 작성했습니다.
로드맵 구축(30분)

“현재”(향후 몇 주간) 수행하고자 하는 항목부터 “단기”(3~6개월)와 “장기”(6개월 이상)에 걸쳐 수행하고자 하는 항목까지 성과를 제공할 순서의 우선순위를 지정하여 팀이 로드맵을 구축하도록 지원합니다(25분). 실제 보드 또는 Trello/Miro 보드에 이를 작성합니다.

팁: 먼저 상단 오른쪽 사분면에 있는 성과, 즉 가치가 높고 노력은 덜 들며 더 많은 확신을 가진 항목에 집중합니다.

여기에 적용할 수 있는 몇 가지 원칙은 다음과 같습니다.
- 로드맵에 모든 성과를 추가하지 않습니다.
- 제공 가치가 낮고 노력이 많이 드는 것은 수행하지 않습니다.
- 일반적으로 제공 가치가 높은 항목을 우선시하는 것이 좋습니다.
- 그 자체로는 제공 가치가 낮아 보이는 항목을 먼저 수행해야 할 수 있습니다. 제공 가치가 높은 성과가 우선 배치되어 있는 다른 항목에 영향을 받기 때문입니다.
- 가치가 높은 성과 중에 어떤 항목은 더 리스크가 높거나 알려지지 않아 우선적으로 검증해야 할 수 있습니다. 따라서 알려지지 않아 리스크가 높은 비즈니스 크리티컬 성과를 로드맵에서 먼저 구축하고 테스트한 다음 우선적으로 처리하는 것이 좋습니다.
- 한 번에 너무 많은 성과를 고려하지 않는 것이 좋습니다. 이 연습에서는 그룹에 한 번에 한 번의 성과를 제공하는 것만 고려하라고 요청하는 것이 도움이 될 수 있습니다.
- 미래(6개월 이후)에 수행할 항목보다 지금 수행할 항목에 관해 보다 견고한 아이디어를 구축하는 것이 일반적입니다. 더 먼 미래의 일은 수행할 필요가 없게 될 수도 있습니다.
팁: 더 많은 내용을 학습함에 따라 로드맵의 우선순위를 주기적으로 다시 지정해야 하며(9단계 참조), 팀은 장기 로드맵 작성에 부담을 느낄 수 있습니다.
첫 번째 로드맵 초안 검토 및 필요에 따라 조정(10분)

다음 메시지를 사용하여 논의합니다.
- 이 로드맵이 비전을 향해 나아가는 데 도움이 됩니까?
- 이 항목이 우리가 가장 많은 가치를 제공하며 가장 먼저 달성해야 하는 성과입니까?
답변이 분명한 '예'가 아니라면 팀원이 어떤 변경 사항을 제안하는지 알아봅니다. 필요에 따라 6~7단계를 반복하십시오.

팀이 성과 중심 로드맵을 반복적으로 구축하고 나면 잊지 말고 팀원들을 축하해 주십시오. ??
세션 후

팀을 대상으로 각 성과의 진행률에 대한 로마식 투표를 진행하여 정기적으로 로드맵 프로세스를 검토합니다.
- 엄지를 올리면 성과를 달성한 것입니다.
- 엄지를 수평으로 눕히면 아직 성과 달성을 위해 노력하는 중입니다.
- 엄지를 내리면 이 성과를 향한 작업을 시작하지 않았거나 이 성과가 더 이상 관련이 없는 것입니다.
이 투표는 진행 상황에 대한 팀의 평가에 발맞추기 위한 조치입니다. 엄지를 눕히거나 내리는 표를 받은 성과에 대해서는 조치 항목이 정의되어야 합니다(예: 성과 세분화, 더 효과적으로 초점 설정, 관련성 재검토).

혹은 팀은 측정지표를 검토하여 성과의 달성 여부를 평가할 수 있습니다.

팀이 각 성과의 진행률을 포착할 수 있는 방법을 찾습니다. 색상 코딩(예: 녹색, 주황색, 빨간색), 진행 표시줄(예: 75% 달성)을 사용하거나 팀에 적합한 다른 방법을 통해 이를 수행할 수 있습니다.

이 조율 세션을 따라 로드맵을 업데이트합니다. 3~8단계를 반복하여 이를 수행할 수 있습니다.

팁 1: 주기적으로(최대 매월) 시간을 구분하여 로드맵을 검토하고 로드맵을 최신 상태로 유지하십시오. 또한 반복적인 계획 수립 회의나 내부 및 이해관계자 업데이트 시에 모든 사람이 확인할 수 있도록 사무실의 벽이나 원격 작업 보드의 눈에 띄는 위치에 로드맵을 배치하십시오.

팁 2: 성숙도가 낮은 제품 아이디어는 성과가 검증되거나 실격됨에 따라 종종 빈번하게 업데이트해야 할 수 있으며, 일반적으로 다음으로 수행해야 할 작업에 대한 확실성이 낮습니다. 주기적으로 업데이트하거나 변경해야 하더라도 괜찮습니다.

성공/예상되는 성과

이 연습의 마무리 시점에 이르면 다음과 같은 방식으로 순차적으로 구성한 제품 로드맵을 갖추게 됩니다.

진행자 메모 및 팁

MVP: 최소 기능 제품(MVP)이란 제품의 가치 제안을 테스트하기 위해 설계된 제품입니다. 가능한 가장 작은 제품 버전으로, 가작 적은 노력을 들여 고객에 대해 최대한 많은 정보를 알 수 있게 해 줍니다.

추가 참고 자료:

이전 단계

비전, 임무, 전략 – 곧 제공 예정

린 비즈니스 캔버스

문제 우선순위 지정

실제 예시

기업은 다양한 형식의 로드맵을 채택합니다. 대부분은 특정 유형의 성과/혜택을 최소한으로 작성합니다. 속도에 보다 자신이 있는 기업은 구체적인 기간을 설정해 놓았을 수 있고, 이미 OKR을 제대로 확립한 기업(예: 영업 대상 등에서 측정됨)이 있을 수 있습니다. 여기에 일부 예시가 나와 있으며, 최소한 성과와 우선순위는 있어야 합니다.

권장 자료

바로 사용 가능한 제품 로드맵 - Roman Pichler

애자일 제품 로드맵의 형태 - Jeff Gothelf

Practices: Boris

Thu, 11 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

이벤트 스토밍을 진행한 후 한 색상의 스티커 메모를 사용하여 각 경계 컨텍스트를 생성합니다. Blob의 보드에 이들을 배치합니다.

팁: 경계 컨텍스트, 주제/대기열, 외부 시스템, UI를 식별하는 범례를 생성합니다.
흐름의 씬 슬라이스를 논의하고 각 경계 컨텍스트가 어떻게 서로 소통하여 흐름을 완성하는지 매핑을 진행합니다. 만족스러운 경로에서 시작하여 만족스럽지 않은 경로로 이동합니다.

팁: 시스템을 따라 둘 이상의 슬라이스를 매핑할 경우 각각에 대해 서로 다른 색상의 화살표를 사용합니다. 만족스러운 경로라는 측면에서 “to-be(달성 목표)” 경계 컨텍스트는 서로 어떻게 소통해야 합니까? 만족스럽지 않은 경로 관점에서 “to-be” 시스템은 장애 시에 서로 어떻게 소통해야 합니까?

이벤트 메시지 페이로드를 논의할 경우, 최소한의 고유 키로 가능한 한 가장 작은 메시지를 사용하여 동기 웹 서비스 조회(“린 이벤트, 풍부한 API”)를 통해 고유한 경계 컨텍스트를 식별하도록 권장하십시오.
대화를 진행하면서 동기 및 비동기 의사소통에 서로 다른 색상을 사용하여 시스템 간에 선을 그립니다. 화살표를 추가하여 이들이 푸시하는지 혹은 풀링하는지 표시합니다.

고려해야 할 질문:
- 이 경계 컨텍스트의 입력과 출력은 무엇입니까?
- 의사소통이 이벤트나 웹 서비스 중 무엇을 통해 이루어져야 합니까?
- 포함해야 할 교차 통합에는 어떤 것들이 있습니까(예: 알림, 모니터링, 밸런싱, 회계 등)?
대기열/주제에 대해 동일한 색상의 새로운 스티커 메모를 추가하여 대기열이 필요한지 여부를 표시합니다. 시스템에서 소통하는 대상에 선을 추가합니다.
다른 색상의 새로운 스티커 메모를 사용하여 흐름의 일부인 외부 시스템이 있는지 여부를 표시합니다. 흐름 내의 의사소통 방식에 대한 선을 추가합니다.
큰 시트에 SNAP 목록을 작성합니다.

SNAP는 Boris 다이어그램에 대한 이해를 바탕으로 새롭게 제안된 아키텍처 하에서 모든 경계 컨텍스트의 구체적인 요구를 파악합니다. 각 경계 컨텍스트에 대해 SNAP 연습이 수행되어야 하며 API, 필요한 데이터, UI, 해당 경계 컨텍스트에 적용될 리스크를 언급합니다. 제품의 백로그는 식별된 항목을 기반으로 생성됩니다.

고려해야 할 질문:
- 경계 컨텍스트에 대해 어떤 API를 구축해야 합니까?
- 경계 컨텍스트와 통합할 외부 시스템은 무엇입니까?
- 경계 컨텍스트에 포함해야 할 데이터 요소는 무엇입니까?
- 경계 컨텍스트에 대한 UI가 있습니까?
- 경계 컨텍스트의 주요 리스크는 무엇입니까?
- 작업을 위한 계정에 대해 생성해야 할 백로그 스토리는 무엇입니까?
- Boris 진행 중에 일반적인 대화 속에서 도출되는 사항을 발전시킬 수 있도록 SNAP 시트에 항목을 기록하는 작업을 담당할 사람을 지정하면 도움이 됩니다.
흐름 및 시스템과의 상호작용에 대한 논의를 진행하면서 각 경계 컨텍스트의 시트에 정보를 추가할 수 있습니다.
새로운 색상을 사용하여 이를 나타내는 다음 흐름으로 이동합니다.
더 큰 경계 컨텍스트 시트에서 새로운 색상의 스티커 메모로 새 흐름에 정보를 추가합니다.
경계 컨텍스트 시트에 누락된 특정 영역을 언급합니다.

성공/예상되는 성과

Boris 연습의 마무리 시점에서 이르면서 서비스, API, 데이터 및 이벤트 코레오그래피, 작업 백로그가 분명해지기 시작합니다.

SNAP는 실시간으로 Boris의 성과를 빠르게 문서화하는 데 사용됩니다. 정보는 종종 API, 데이터, Pub/Sub, 외부 시스템/UI, 스토리, 리스크로 그룹화됩니다. 핵심 아티팩트는 회의실 벽 또는 이와 유사한 디지털 워크스페이스에 부착한 포스터 크기의 스티커 종이이며, Boris에 노드 또는 서비스당 하나의 SNAP가 표시됩니다. 일반적으로 Boris에는 노드 혹은 서비스당 하나의 SNAP가 표시됩니다. 각 SNAP는 API, 데이터, 외부 시스템/UI, 외부 시스템/UI, Pub/Sub, 스토리, 리스크라는 6개의 카테고리로 된 문서로 이루어져 있습니다.

진행자 메모 및 팁

Boris, 이벤트 스토밍 및 기타 기술은 대규모 시스템에서 “실제” 문제를 파악하고 현대화된 시스템의 목표를 향한 방향을 발견하는 데 사용하는 Swift 방식의 일부입니다. 수사적인 질문을 통해 솔루션이 자연스럽게 드러나도록 해야 합니다. 솔루션을 견인하는 것과 대상 아키텍처를 조직적으로 발전시키는 것 사이의 균형을 세밀하게 유지하는 과정을 연습하십시오. Boris 연습을 수행할 때 미리 최적화해서는 안 됩니다.

당면 과제 플레이북

당면 과제: 언제 이벤트 스토밍에서 Boris, SNAP로 전환해야 할지 확실하지 않습니다.

회의실에서 비즈니스 이벤트를 진행하느라 진행이 느려졌으며 명시적으로 한 라운드 이상의 해결 과제를 지정했을 때, 집합체 경계의 파악을 시도할 수 있습니다. 이 시도가 어려운 것으로 드러날 경우, 한 발 물러서서 여러 정보를 알려줄 이벤트가 더 있는지 살펴볼 수 있습니다.

Boris 및 SNAP는 종종 병렬 구조로 수행됩니다. 이때 SNAP는 Boris 다이어그램을 중심으로 유기적으로 발생하는 대화의 카탈로그를 구축하는 형식으로 이루어집니다.

당면 과제: 때때로 이벤트 스토밍 세션의 마무리 시점에 명확한 경계 컨텍스트가 없을 수 있습니다.

이것은 사안을 너무 자세히(경계 컨텍스트 내에서 하나의 프로세스 또는 프로세스의 일부만 검토) 또는 너무 폭넓게(회사의 전체 또는 대부분을 매핑함) 범위를 살펴보고 있기 때문일 수 있습니다. 이 경우라면 대개 회의실에 있는 참여자에게 질문하여 문제의 범위를 좁힐 수 있습니다. 사안을 지나치게 자세히 살펴보고 있다고 느끼는 경우 두 번째 세션에서 더 많은 관련 이벤트의 이해관계자들과 함께 다시 살펴볼 수 있습니다.

당면 과제: 세션을 마쳤는데도 보편적인 언어에 대한 합의에 도달하지 못할 때가 있습니다.

경계 컨텍스트의 내부 엔지니어링 및 비즈니스 팀이 용어에 관해 서로 동의한다면 이런 경우에도 문제가 되지 않을 수 있습니다. 여전히 모호함이 존재한다면 모든 명사 및/또는 동사를 수집할 지점을 모색하고 워크샵에 이 과정을 포함시킬 수 있습니다(세션 중에 라운드로 또는 향후 핵심 팀과 함께 전용 세션으로).

당면 과제: 회의실에 있는 대부분의 사람이 참여하지 않거나 대화가 한두 명 사이에서만 이루어집니다.

사람들에게 노트북이나 휴대폰을 치워 달라고 말합니다. 초기에 참여에 대한 기대치를 설정합니다. 전체 그룹 모빙(mobbing)을 진행하는 과정에서 일부 구성원들의 목소리가 묻히는 경우 대상 청중의 특정 분야를 언급함으로써 그들의 구체적인 관점을 기반으로 이벤트 스토밍 또는 Boris 라운드를 수행합니다. 특히 각 사람이 회의실에 있는 이유를 파악하기 위해 준비 작업을 수행했다면 그들 각자에게서 무언가 필요한 것입니다. 이렇게 파악한 이유를 참여하고 있지 않은 동료들에게 특정 유형의 정보를 제공해 달라고 요청하는 데 활용할 수 있습니다.

당면 과제: 프로세스의 각 단계에서 우리 모두에게 필요한 사람이 누구인지 알기 어렵습니다.

준비 작업 섹션에서 초대할 사람에 관한 설명을 확인하십시오. 실제, 또는 임시적으로 상상한 균형 잡힌 팀과 더불어 이해관계자와 소비자를 대표할 직원을 목표로 하십시오.

당면 과제: 조직이 확장함에 따라 세션 진행을 지원할 촉진 경험이 있는 사람을 찾기가 어렵습니다.

이는 모든 연습에서 여러 방면으로 사실이므로, 유사한 사례에서 얻은 지혜나 최적화를 여기에 적용할 수 있습니다. 특정 역할을 지니고 있지 않은 누군가가 나타나기를 기다리는 것보다는 준비 단계가 진행자를 찾고 프로세스에서 의도를 띄는 과정이라고 생각하십시오.

또한 “I do, we do, you do(점진적 책임 이양)” 프로세스를 진행하려면 여러 세션을 거쳐야 한다는 사실을 인정하십시오. 더 많은 기회를 촉진하면 이러한 과정을 완화할 수 있습니다.

Boris는 Swift 방식에 포함된 활동입니다.

이전 단계

이벤트 스토밍

실제 예시

Uber Eats와 같은 유형의 애플리케이션을 위한 현대화의 Boris 및 Swift 방식에 대한 자세한 설명은 이벤트 스토밍 및 Boris 훈련 Miro 보드를 참조하십시오.

권장 자료

Swift 방식: 이벤트 스토밍, 거미 같은 Boris와 기타 기술(유튜브 동영상), ExploreDDD 2019에서 Shaun Anderson 진행

미션 크리티컬 애플리케이션을 클라우드로 이전하기 위한 현대화 패턴 심층 탐구(유튜브 동영상)

기업에서 위협적인 모놀리스 방식을 제거하는 툴(블로그 게시글)

Practices: Swift 방식

Thu, 11 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

비즈니스 및 기술 인력이 이해하는 언어를 사용하여 시스템을 이벤트 스토밍합니다.
시스템의 기능 간 관계를 모델링하는 Boris 연습을 수행합니다. Boris 중에 식별된 기술적 기능을 실시간으로 문서화하는 SNAP를 수행합니다.
현대화의 씬 슬라이스를 식별합니다.

씬 슬라이스는 짧은 도메인 이벤트 흐름입니다. 수직 슬라이스는 핵심 도메인에서 짧은 도메인 이벤트 흐름을 선택하고 해당 이벤트를 생성하기 위해 Boris에서 파생된 서비스를 활용하여 식별됩니다. 이러한 이벤트를 생성하는 데 필요한 아키텍처 구성 요소로 생각하면 됩니다. 씬 슬라이스에는 이벤트 스토밍, Boris, SNAP 활동을 통해 정보가 제공됩니다.

팁: 수직 슬라이스는 아키텍처의 모든 계층을 다루지만, 기능의 일부만을 구현합니다. 예를 들어, “사용자가 암호로 로그인할 수 있도록 허용” 수직 슬라이스는 사용자 인터페이스에 사용자 이름과 암호를 추가하고, 서버 측 논리를 구현하고, 데이터베이스 기록에 최종 로그인 필드를 업데이트할 수 있습니다. 개발자가 가장 익숙하지 않을 수 있는 애플리케이션 내 영역과 상호작용해야 하기 때문에 수직 슬라이싱은 애자일 방식을 처음 접하는 팀이 사고를 전환하기가 어렵습니다.
비즈니스 가치와 기술 리스크, 작업량 간의 균형을 조정하면서 씬 슬라이스의 우선순위를 지정합니다. 목표는 점진적으로 시스템을 “원하는 방식으로” 행동하도록 이동하는 것입니다. 연속적인 각 슬라이스의 구현을 통해 이 목표에 더 가까이 다가갈 수 있습니다.
씬 슬라이스는 백로그에서 MVP(최소 기능 제품) 또는 스토리의 컬렉션으로 캡처되었을 때 실행 가능해집니다. 때때로, Pivotal/Tanzu Labs는 고객 팀과의 파트너십을 통해 비즈니스 가치와 기술 리스크, 작업량 간의 균형을 조정하면서 씬 슬라이스를 식별하고 이들의 우선순위를 지정합니다.

팁: 시스템에 적합한 MVP를 정하기 위해 이러한 도메인이 서로 상호작용하는 포괄적인 수직 씬 슬라이스를 고려해야 합니다. MVP는 “모놀리스 제거”와 전술적 패턴의 활용으로부터 경로를 매핑하고 새 도메인 및 서비스와 상호작용합니다.
슬라이스를 정의할 때 신규 또는 제거된 서비스가 이전의 레거시 시스템과 공존할 수 있도록 부패 방지 계층, Facade, Docket 기반 코레오그래피, Strangler와 같은 전술적 구현 패턴을 활용하십시오.
우선순위로 지정된 사용자 스토리의 백로그를 다시 목표(사례 곧 제공 예정)/OKR에 연결합니다. 사용자 스토리를 MVP 또는 릴리스에 매핑합니다.

팁: 사용자 스토리 영향 매핑은 스토리를 MVP와 릴리스에 매핑하는 데 적용할 수 있는 기술입니다. DDD와 사용자 스토리 매핑을 결합하는 방법에 관한 블로그 게시글을 읽어 보십시오.
실습 실험과 피드백, 반복 프로세스를 시작합니다.

성공/예상되는 성과

현재 시스템 기능을 빠르게 발견하고, 영감을 주는 대상 아키텍처를 생성하고, 우려되는 기반 영역을 파악하고, 우선순위에 대해 합의
개념적 솔루션, 전술적 수정, 잠재적인 절충 사항을 점진적이고 측정된 방식으로 논의 및 이해
가정을 검증/실격 판정하고 솔루션/수정에 정보를 제공하기 위한 아키텍처 작업
점진적으로 서비스를 현대화하는 접근 방식 구축
“모든 것을 테이블에 두는” 접근 방식을 사용하는 관련 비즈니스 성과로 솔루션 정의
작게 시작하여 확장되고 고객 개발자와 아키텍트를 지원하는 전술적 단계 계획을 통해 확신을 향해 전진

진행자 메모 및 팁

우수한 진행자는 DDD 관점에서 비즈니스 기능의 지원을 기준으로 시스템을 설계하는 방법을 이끌어내야 합니다.

이 개념적인 아키텍처는 이제 시스템의 우수한 첫 번째 진행 방향을 나타냅니다. 기존 시스템을 현대화하는 툴로 사용될 때 Boris는 가능성 있는 대상 아키텍처를 보여줍니다. Swift 방식의 다른 활동은 현재 상태에서 현대화된 상태로 이동하는 방법을 정의하는 데 도움을 줍니다.

Swift 방식에는 다음을 비롯한 많은 활동이 포함됩니다.

실제 예시

Uber Eats와 같은 유형의 애플리케이션을 위한 현대화의 Boris 및 Swift 방식에 대한 자세한 설명은 이벤트 스토밍 및 Boris 훈련 Miro 보드를 참조하십시오.

권장 자료

수개월 혹은 수년이 아닌 며칠 또는 몇 주 만에 애플리케이션 현대화 실현(백서)

Swift 방식: 이벤트 스토밍, 거미 같은 Boris와 기타 기술(유튜브 동영상), ExploreDDD 2019에서 Shaun Anderson 진행

미션 크리티컬 애플리케이션을 클라우드로 이전하기 위한 현대화 패턴 심층 탐구(유튜브 동영상)

기업에서 위협적인 모놀리스 방식을 제거하는 툴(블로그 게시글)

EventStorming.com(웹사이트)

Practices: 이벤트 스토밍

Thu, 11 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

그룹에게 이벤트 스토밍의 목표를 설명합니다. 필요할 경우 아래의 이미지를 보여줍니다. 이벤트, 경계 컨텍스트, 서비스 및 해결 과제에 대한 설명에 포함할 범례를 식별합니다. 모든 스티커 메모에 대한 범례를 그리고 기본적인 DDD(도메인 주도 설계) 용어를 설명합니다.
그룹에 대한 “도메인 이벤트”를 정의합니다.

예시: “‘도메인 이벤트’는 도메인에서의 상태 전환을 나타내며, ‘주문 처리됨’ 또는 ‘환불 개시됨’과 같은 과거 시제의 동사로 표현됩니다.”
도메인 이벤트 하나당 하나씩 일련의 주황색 스티커 메모를 적어 그룹이 “비즈니스 프로세스를 브레인스토밍”하도록 합니다.
- 이벤트 스토밍 세션의 시작과 끝을 식별하여 일련의 이벤트 생성
- 과거 시제인 이벤트에 대해 생각
- 먼저 만족스러운 경로부터 시작
- 스티커 메모를 측면으로 45도 기울여 질문이나 명확히 밝혀야 할 모호함이 있는지 표시
벽에 도메인 이벤트를 왼쪽부터 오른쪽으로 시간순으로 배치
스토밍 세션을 진행하면서 기존 비즈니스 프로세스의 다양한 측면을 발견하게 됩니다. 다음과 같이 이 측면을 포착합니다.
- 문제 지점을 빨간색 스티커 메모로 표시
- 새로운 색상의 스티커 메모로 외부 시스템을 강조 표시하고 이들이 트리거하는 작업/이벤트 가까이에 배치
- 수직 공간을 사용하여 병렬 처리 표시
- 설정된 기간(배치 프로세스 또는 크론 작업 등)으로 인해 야기되는 모든 사항을 새로운 색상의 스티커 메모로 강조 표시하고 이들이 제어하는 트리거 옆에 배치
모든 이벤트를 게시한 후에 도메인 전문가와 짝을 지어 국부적으로 순서가 지정된 일련의 이벤트를 게시하고 타임라인을 적용합니다. 진행하면서 피드백을 크라우드소싱합니다.

팁: 타임라인을 적용하면 오래 기다린 대화가 트리거되며 결과적으로 구조가 형성됩니다.

크라우드소싱된 피드백으로 놓친 요소를 발견할 수 있습니다. 필요에 따라 스티커 메모를 추가합니다.
타임라인을 적용한 상태에서 경계 컨텍스트(즉, “도메인 집합체”)를 찾습니다. 이벤트 그룹을 찾고 이들이 작업을 수행하는 대상이 무엇인지, 그리고 다음 부분으로 전환되는 것이 무엇인지 확인합니다. 하위 도메인 간 전환을 나타내는 중심 이벤트를 파악합니다.

일반적으로 큰 그룹에 더 적은 스티커 메모가 있으며 더 큰 그룹의 스티커 메모는 새로운 경계 컨텍스트로의 전환을 나타냅니다. 경계 컨텍스트 또는 비즈니스 역량을 나타낼 수 있는 수직 스윔레인 이벤트를 찾습니다.

팁: 경계와 화살표가 있는 선을 그려 모델링 표면의 흐름을 나타냅니다. 경계 컨텍스트에는 실선을 사용합니다. 화살표 머리가 있는 선을 그려 경계 컨텍스트 간의 도메인 이벤트 흐름의 방향을 나타냅니다.

덜 두드러지게 모델의 경계를 짓고자 한다면 스티커 메모를 사용하여 일반적인 영역을 표시하고 확신을 얻을 때까지 영구 마커로 경계를 그리지 마십시오.

이벤트 스토밍 보드에 표시된 명사의 식별을 크라우드소싱하고 측면에 이를 배치할 수도 있습니다. 이러한 명사를 관련 데이터 트리로 한 덩어리로 묶으면 집합체를 형성하는 데 도움이 됩니다.
이러한 이벤트 덩어리 또는 공통 그룹은 개념적 서비스 후보(얼마나 팀이 견고하게 DDD 정의를 수립했는지에 따라 행위자 또는 집합체)를 제공합니다. 이들은 Boris 연습 중에 사용됩니다.
선택 사항: 사용자가 작업을 수행해야 할 다양한 뷰를 식별하고 여러 사용자의 중요한 역할을 파악합니다. 밝은 노란색 스티커 메모를 사용하여 사용자 역할 또는 사용자 유형을 식별합니다. 스티커 메모를 사용하여 사용자 역할, 사용자 유형, 현금 또는 도메인에서 중요한 다른 항목을 점증적으로 표시하여 이벤트 스토밍을 강화합니다.
추후에 사용할 수 있는 결과를 포착할 수 있도록 결론을 내리는 시점에 사진을 많이 찍어 두십시오.

성공/예상되는 성과

다음을 수행했으면 과정을 완료한 것입니다.

경계 컨텍스트 및 이와 연계된 도메인 식별
비즈니스 하위 도메인과 각 경계 컨텍스트 매핑(일반적으로 1대1)
각 경계 컨텍스트/하위 도메인을 대상 아키텍처에서 서비스로 매니페스트화

진행자 메모 및 팁

이벤트 스토밍은 모놀리식 애플리케이션의 도메인과 문제 영역을 과학적으로 살펴보는 그룹 연습입니다. 이벤트 스토밍 프로세스에 대한 가장 간결한 묘사는 Vaughn Vernon의 서적 Domain-Driven Design Distilled에 담겨 있으며, Alberto Brandolini의 서적 Event Storming에서 영감을 받은 프로세스를 중심으로 VMware에서 색상을 개선했습니다.

이벤트 스토밍은 복잡한 시스템과 프로세스를 시각화하는 데 사용되는 기술입니다. 종류는 모놀리스부터 가치 흐름까지 다양합니다. 게임스토밍에서 영감을 받은 이벤트 스토밍은 그룹의 사고에서 확보한 정보를 활용하고 포착하기 위한 기술입니다. 복잡한 시스템의 충돌과 다양한 관점을 드러내며 최상위 제약과 문제 지점이 노출됩니다. 이벤트 스토밍 진행자에게는 한 가지 임무가 있습니다. 아이디어와 데이터의 교류와 결과물을 위해 안전한 환경을 조성하는 것입니다. 업무의 절반은 기술적 촉진이며 나머지 절반은 신체 언어를 읽는 소프트 인력 촉진입니다. 한 명의 진행자는 일반적으로 15~20명으로 이루어진 그룹을 조율할 수 있습니다. 30명 이상의 그룹에는 진행자가 두 명 필요합니다.

이벤트 스토밍은 대개 두 단계로 수행됩니다. 개략적인 수준의 이벤트 스토밍을 진행하여 도메인을 파악한 다음 최고 제약 사항인 핵심 도메인에 대한 후속 이벤트 스토밍을 진행합니다.

이벤트 스토밍은 스티커 메모로 구현됩니다. 가장 단순한 형태의 이벤트 스토밍은 일반적으로 그룹 스토리텔링에 의해 촉진됩니다. 스티커 메모는 도메인 이벤트 혹은 과거에 발생한 일을 나타냅니다. 문제 지점은 빨간색 스티커 메모로 식별됩니다. 스티커 메모의 색상은 중요하지 않습니다. 중요한 것은 단순하게 시작하여 점증적으로 표시를 추가하는 것입니다. 단순하게 시작한 다음 정보를 계층적으로 추가하십시오. 이벤트 스토밍은 모놀리스를 해당 구성 요소인 경계 컨텍스트로 세분화하거나 직원을 온보딩하는 수단으로 가치 흐름을 생성하는 등, 여러 목표를 지원할 수 있습니다.

이벤트 스토밍 스타일에 단 하나의 정답은 없습니다. 원하는 목표와 성과에 따라 모든 세션은 서로 다르기 때문입니다. 따라서 올바르게 수행하지 못한다고 걱정하지 말고 각자의 스타일대로 수행하십시오. 필요한 성과를 실현하려면 다양한 추상화 수준에 대해 이 활동을 여러 번 반복해야 할 수 있습니다.

이벤트 스토밍은 적절한 사람이 참여할 때에만 성공할 수 있습니다. 이벤트 스토밍은 비즈니스 도메인 전문가, 고객 경영진, 이해관계자, 비즈니스 분석가, 소프트웨어 개발자, 아키텍트, 테스터, 그리고 운영 중인 제품을 지원하는 인력이 함께해야 합니다. 개발자 애플리케이션 도메인을 알고 이해하는 실무 전문가, 제품 담당자가 필요합니다. 이 프로세스를 거치면 팀 전반에서 서로 다른 관점 간에 소통이 가능하며 기술 팀과 그 외 다른 팀원들이 사용하는 용어에 대한 표준 정의를 수립할 수 있습니다.

이벤트 스토밍에 앞서 신데렐라 연습을 진행하는 것이 긴장을 푸는 데 도움이 될 수 있습니다. 이 연습에서는 신데렐라의 이야기를 지도에 그립니다. PM은 시작과 끝 지점을 선택하고 참가자들에게 영화에서 발생한 사건을 적어 보라고 요청합니다. 이 과정 끝에는 스토리텔링으로 모두가 영화의 내용을 상기하게 됩니다. 이 연습은 팀이 실제로 이벤트 스토밍을 진행하지 않고도 이 연습에 대해 학습할 수 있는 안전한 환경을 제공합니다.

이벤트 스토밍은 Swift 방식에 포함된 활동입니다.

서비스 Blueprint는 이와 유사하지만 다릅니다.

Boris는 종종 이벤트 스토밍을 따릅니다.

실제 예시

도메인 주도 설계로 모놀리스 해체

모의 WeBeFoods 예시(Miro 사용)

권장 자료

이벤트 스토밍 연습의 동기:

Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers - Dave Gray, Sunni Brown, James Macanufo

어린이용 도서 형식의 이벤트 스토밍에 대한 개괄적인 설명:

이벤트 스토밍: 어른들을 위한 게임 방식의 설명

Event Storming - Alberto Brandolini(EventStorming.com에서 관련 정보를 찾을 수 있음)

DDD(도메인 주도 설계) - 모놀리스를 분할하는 이론적인 기반을 제공합니다. Vaughn Vernon이 집필한 Domain-Driven Design Distilled는 DDD의 과학과, ES가 여러 사항의 더 큰 계획에 들어맞는 방식, 다시 말해 ES 아티팩트가 소프트웨어 설계, 아키텍처 및 실제 백로그로 전환되는 방식을 이해하는 데 완벽한 책입니다.

Practices: 가정

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

원격 팁: 분산된 팀의 경우 Miro 또는 이와 유사한 “디지털 화이트보드”를 사용하고 디지털 환경에 그리기 및 스티커 메모 사용과 같은 대면 환경의 요소를 도입하십시오. 예를 들어 실제 화이트보드를 사용하기보다 2x2 디지털 표를 그립니다.

샘플 안건 및 메시지

팀의 “가정”을 정의하고 팀이 이 워크샵을 진행하는 이유를 설명합니다.

“가정은 우리가 참이라고 믿지만 사실 또는 증거를 기반으로 하지 않은 것을 말합니다. 지금 가정을 확인하면 연구를 통해 답변하는 데 필요한 질문을 결정하는 데 도움이 됩니다.”

팀에게 3~5분 동안 가정을 생각해 내라고 요청합니다.

팁: 그룹이 대규모인 경우(예: 시작 단계에 있는 경우) 더 적은 시간을 할애해야 합니다. 그러지 않으면 방대한 수의 스티커 메모를 훑어보느라 오랜 시간이 소모될 것입니다.
팀에게 하나는 가장 중요한 가정을, 다른 하나는 가장 덜 중요한 가정을 모은 2개의 동일한 스티커 메모 더미를 만들라고 요청하십시오.
각 사람이 가장 덜 중요한 가정의 더미를 버리도록 합니다. 실제 스티커 메모를 사용할 경우 종이를 찢어버리는 쾌감을 즐길 수 있습니다.
상단에 “높은 리스크”, 하단에 “낮은 리스크”가 표시된 화이트보드에 수직선을 긋습니다. 대면 상황인 경우 마스킹 테이프 또는 화이트보드용 마커를 사용합니다.

팁: “리스크”는 가정이 잘못된 것으로 드러날 경우 프로젝트에 미칠 수 있는 부정적인 영향을 나타냅니다.
그룹을 지어 가정을 공유하고 줄을 따라 각 가정의 순위를 매깁니다. 이때 2개의 스티커 메모가 동일한 수직 공간을 차지해서는 안 됩니다.

팁: 중복된 아이디어가 떠오를 경우, 다른 아이디어 위에 쌓거나 잉여 아이디어를 버리면 됩니다.
완료되었으면 왼쪽에는 “많이 알고 있음”, 오른쪽에는 “거의 모름”이 표시된 화이트보드에 수평선을 긋습니다.
리스크는 앞서 다루었으므로 세로 축의 어떤 것도 이동하지 않도록 주의하면서 새 축을 따라 각 가정을 수평으로 퍼트려 놓습니다.
연습의 마무리 시점에 이르면 작업을 수행해야 할 가정이 무엇인지(상단 오른쪽 사분면), 그리고 시간이 허락된다면 구체적으로 어떤 작업을 수행하고 누가 이를 담당할지 대략적으로 설정할 수 있는 강력한 아이디어를 얻게 됩니다.

팁: 모든 사분면을 다룰 시간이 부족하더라도 괜찮습니다. 가장 리스크가 높은 가정부터 먼저 처리할 수 있도록 가로 축 상단에 있는 것부터 시작하십시오.
마지막으로 2x2 표를 사진, 스크린샷 또는 공유 업무 공간에 저장하기 등 특정 방식으로 기록합니다.

성공/예상되는 성과

연구를 통해 해결해야 할 가장 리스크가 높은 가정을 매핑하는 완벽하게 정리된 2x2 표를 작성하면 성공한 것입니다.

진행자 메모 및 팁

가정이 많거나 각 가정의 순위를 매기는 데 어려움을 겪을 경우 이 연습은 오래 걸릴 수 있습니다. 여러분의 임무는 논의를 간단히 유지하고 팀에게 (a) “완벽한” 정답은 없으며 (b) 순위는 상대적임을 상기시키는 것입니다. 연구를 수행하는 과정을 통해 놓쳤을 수 있는 어떤 사항을 발견할 수 있습니다. 앞으로 나아가는 추진력을 유지하도록 최선을 다하십시오.

실제 예시

Practices: 리스크 및 완화

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

그룹에게 이 팀이 마주할 수 있는 프로젝트 리스크와 장애물을 조용히 적어 보도록 요청합니다. 스티커 메모당 하나의 항목을 적습니다.

팁: 리스크 또는 장애물의 예시를 제공하십시오. 예를 들어 이렇게 말할 수 있습니다. “다른 팀과 다른 속도로 코드를 출시할 예정이며 종속성 문제와 방해 요소가 발생할 수 있습니다.”

팁: 여러 가지 리스크 유형을 나열하면 도움이 될 수 있습니다. 기술 리스크와 더불어 비즈니스 리스크(“규정 준수 표준으로 인해 제공 접근 방식이 변경될 수 있음”)와 팀 리스크(“구성원이 다른 시간대에 있음”)를 고려해야 합니다.
각 사람에게 상위 리스크와 장애물 5개를 선택하도록 요청합니다.
그룹을 쌍으로 나눕니다. 각 쌍에게 함께 축을 그리고 그 위에 리스크를 구상하도록 요청합니다.

원격 팁: 여러 화상 채팅 시스템이 보다 긴밀한 협력을 위해 일시적으로 대규모 그룹을 더 작은 그룹으로 분리하는 “소회의실” 또는 이와 유사한 수단을 지원합니다.

각 쌍은 종이 한 장이나 디지털 화이트보드의 섹션에 축을 그립니다.
- X-축: 마이그레이션하기 쉬운 것에서 마이그레이션하기 어려운 것
- Y-축: 낮은 리스크에서 높은 리스크
팁: 여러 그룹을 확인하고 특정 그룹이 다른 그룹보다 진도가 빠르다면 계속 진행하도록 하십시오.
각 팀에게 높은 리스크 섹션에서 공유하고자 하는 상위 리스크 2개를 선택하라고 지시합니다.
팀에게 상위 리스크 2개 각각에 대해 1개의 완화 전략을 브레인스토밍하도록 요청합니다.
회의실을 돌면서 각 쌍이 1개의 리스크와 1개의 완화 전략을 읽도록 합니다.
유사한 리스크/완화를 카테고리로 그룹화합니다. 예를 들어 “기술 리스크”, “비즈니스 리스크”, “제품 리스크” 등의 카테고리가 있습니다.

성공/예상되는 성과

가장 큰 리스크에 대한 이해를 공유하고 시작해야 할 일련의 작업 항목을 갖추었으면 성공한 것입니다.

진행자 메모 및 팁

현재 존재하는 서로 다른 분야에서 동일한 표현이 사용되도록 보장합니다.
간결성을 유지하기 위해 설명에 시간 제한을 설정하는 것이 좋습니다.
세션에 대해 올바른 맥락을 설정하여 사람들이 편안한 분위기에서 솔직히 말할 수 있는 공간을 조성합니다.
삿대질을 하거나 불친절한 피드백을 제공하지 않도록 해당 행위를 차단합니다.
작업이 실행 가능하며 너무 일반적이지 않도록(예: “이런 행위를 하지 마세요”) 합니다.

실제 예시

Practices: 린 비즈니스 캔버스

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

화이트보드에 린 비즈니스 캔버스를 그립니다.
일반적인 비즈니스(예: Yelp)를 사례로 사용하여 한 번에 한 섹션씩 린 비즈니스 캔버스를 설명합니다.
설명이 끝난 후 각 참가자에게 한 섹션에 채워 넣어야 할 내용을 적으라고 하여 아이디어 구상을 시작합니다(“문제”부터 시작).

팁: 대규모 그룹으로 작업하는 경우 각 사람에게 캔버스를 채우라고 하는 대신 3명씩 그룹을 나누는 것도 좋습니다.
2~3분 후에 회의실을 한 바퀴 돌며 아이디어의 “중복을 제거”합니다(예: Joe가 읽는 자신의 스티커 메모와 동일한 내용을 Sally가 적었으면, Sally는 자신의 차례가 왔을 때 해당 내용을 읽지 않습니다).
“중복을 제거한” 모든 스티커 메모를 보드에 붙이고 캔버스 밖에 “점 투표”를 진행합니다.
가장 많은 점을 받은 스티커 메모 하나 또는 여러 개를 해당 메모가 속한 섹션으로 옮겨야 합니다.
다음과 같은 순서로 각 섹션에 대해 4~6단계를 반복합니다.
- 문제
- 고객 부문
- 가치 제안
- 솔루션
- 채널
- 수입원
- 비용 구조
- 고객 측정지표
- 비즈니스 측정지표
- 불공평한 이점

성공/예상되는 성과

제품의 시장 적합성, 고객의 관점에서 우리가 제공하는 가치, 비즈니스를 지속하는 방법에 대한 아이디어를 서로 합의하고 이해했다면 연습이 성공한 것입니다.

진행자 메모 및 팁

그룹이 소규모인 경우 점 투표는 불필요할 수 있습니다.
참가자들이 일련의 공유된 답변을 내놓을 수 있기 때문에 추후 섹션에서 그만큼 많은 아이디어 구상 시간이 필요하지 않거나 아예 필요하지 않을 수도 있습니다.
수익은 성공을 측정하는 한 가지 수단이며, 이 상자는 성과라고 칭할 수도 있습니다.
시간의 흐름에 따라 사용할 수 있도록 매주 비즈니스 모델을 업데이트하십시오.

이전 단계

실제 예시

권장 자료

비즈니스 모델 생성 북

비즈니스 모델 캔버스 Yelp

Practices: 목표 및 안티 목표

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

화이트보드에 각각 한 가지 유형의 목표를 나타내는 4개의 열을 그립니다. 다음에 소개하도록 안티 목표 열을 옆으로 밀어 놓습니다.
다음과 같은 메시지를 따라 보드에 목표 유형을 작성합니다.
- 제품 목표 - “제품 공간에 어떤 영향을 미치려고 합니까?”
- 비즈니스 목표 - “비즈니스 관점에서 성공은 어떤 모습입니까? 고려해야 할 중요한 날짜가 있습니까?”
- 프로젝트/컨설팅 참여 목표 - “팀으로서 함께하는 시간 동안 이루고자 하는 것이 무엇입니까?”
- 안티 목표 - “지금은 팀의 역량을 저해하지만 언젠가 이루고자 하는 목표가 무엇입니까?”
7분 동안 브레인스토밍할 시간을 제공합니다. 모두에게 스티커 메모 하나당 1개씩 최대한 많은 아이디어를 적도록 요청합니다.
2분 후 각 사람에게 각 카테고리에 대해 8가지 최상위 목표를 고르고 나머지는 찢어 버리도록 합니다. 찢어 버려도 괜찮다는 점을 꼭 언급하십시오.
회의실을 한 바퀴 돌면서 모두가 각자 선택한 목표 8개를 공유하게 합니다. 공동 진행자를 배정하여 보드의 해당하는 열에 스티커 메모를 붙이도록 합니다.
각 참여자가 목표를 공유할 때 다른 사람들에게 중복된 항목이 있는지 질문합니다. 유사한 목표는 함께 그룹화합니다.
모든 사람이 목표를 공유하고 나면, 한 명당 6개의 점을 나누어 주고 모두에게 상위 2개 제품, 비즈니스, 프로젝트/컨설팅 참여 목표(안티 목표에는 투표할 필요 없음)에 대해 점 투표를 진행하도록 요청합니다. 상위 목표 2개에 동그라미를 칩니다.
핵심 이해관계자들과 함께 놓치고 있는 중요한 다른 목표가 없는지 확인합니다. 만약 그런 목표가 있는 경우 해당 목표에도 동그라미를 치거나 적어 놓습니다.

성공/예상되는 성과

핵심 팀과 이해관계자들이 최상위 제품, 비즈니스, 프로젝트/컨설팅 참여, 안티 목표를 확실하게 이해하고 이를 공유했으면 연습이 성공한 것입니다.

진행자 메모 및 팁

시작할 때 사람이 여러 명인 경우(예: 15명 이상), 모두에게 3~4명의 그룹으로 팀을 구성하도록 요청하는 것을 고려해 보십시오. 그룹으로 팀을 나누면 도출된 목표를 공유하고 선호도 매핑을 작성하는 프로세스가 간소화됩니다.

실제 예시

Practices: 문제 우선순위 지정

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

연구를 통해 발견한 모든 문제를 수집합니다.
참여자가 많은 경우(대략 20명 이상), 먼저 스스로에게 “이 문제가 목표와 관련이 있습니까?"라는 질문을 던져 선별 연습을 수행합니다. 각 문제/해결 과제를 “아니요” 또는 “예” 더미로 벽에 분류합니다.
마스킹 테이프를 사용하여 2x2 표를 만들고 다음과 같이 축에 레이블을 지정합니다.
- X-축 –> 적은 사용자 문제(왼쪽)에서 많은 사용자 문제(오른쪽)
- Y-축 –> 낮은 빈도(하단)에서 높은 빈도(상단)
팁: 선택적으로, 팀에게 “이 문제를 해결해야 하는 이유는 무엇입니까?”와 같은 질문을 하여 다른 2x2 기준을 생성할 수 있습니다. 다른 2x2 예시로는 더 많은 사용자 문제 대 더 높은 영향(예: 대부분의 사용자에게 영향을 미침), 더 많은 사용자 문제 대 더 높은 비즈니스 문제(예: 수익 손실의 측면에서), 더 많은 영향 대 더 많은 즉각적 요구 등이 있습니다.
2x2 표에 문제/해결 과제를 표현합니다.
각 문제/해결 과제의 크기에 따라 상위 3~5개 문제/해결 과제의 목록으로 마치도록 노력하십시오.

팁: 오른쪽 상단 사분면에 우선순위인 문제가 너무 많은 경우 사분면 내에 축을 다시 그려 문제를 더욱 세분화합니다. 축은 절대적인 것이 아니라 상대적이기 때문에 이렇게 해도 괜찮습니다. 관리 가능한 지점에 도달할 때까지 계속 조정하십시오.

성공/예상되는 성과

팀이 초점을 맞출 상위 3~5개 문제에 동의하면 성공입니다.

진행자 메모 및 팁

이 활동을 하기에 적절한 시점은 연구 프로세스에서 식별된 문제의 수에 따라 다르므로 상황에 따라 준비하십시오. 팀이 추진력을 유지하기 위해 각 문제에 대한 대화의 시간을 정하는 것이 유용할 수 있습니다.

변형

2x2 우선순위 지정

이전 단계

연구 합성

다음 단계

실제 예시

Practices: 보편적인 언어

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

회의의 목표를 명확하게 구상합니다.

예시: “우리는 도메인 전문가가 사용하는 언어와 코드베이스에서 사용되는 언어의 괴리라는 기술 부채에 대해서 자주 놓치고 있습니다.”

예시: “오늘 우리의 목표는 팀의 용어 사용에 있어서 의미 체계가 아닌 이해에 초점을 맞춘다는 공통의 이해 관계를 구축하여 이러한 부채를 청산하는 것입니다.”

팁: 팀이 함정에 빠지지 않도록 하는 데 도움이 되는 안티 목표를 제시할 수도 있지만, 이는 선택 사항입니다.
모든 사람에게 10분 이하의 시간을 주고 개인적으로 스티커 메모당 용어 1개씩 최대한 많은 용어를 적도록 합니다.

팁: 이 활동에 여러 명이 참여하는 경우 작은 그룹으로 사람을 나누십시오. 그러면 결과를 보다 수월하게 관리할 수 있습니다.
다음으로, 30분 동안 타이머를 설정하고 모두에게 자신들이 작성한 각 스티커 메모에 대한 간략한 정의를 적도록 합니다.

팁: 마지막까지 남는 용어가 너무 많을까 봐 염려되는 경우, 참가자들에게 팀이 가장 까다로워할 것 같은 용어의 정의만을 적도록 요청하는 것도 좋습니다.
각 사람에게 자신들이 식별한 용어와 정의를 공유해 달라고 합니다. 이들이 적은 내용을 읽을 때 화이트보드 또는 벽에 유사한 용어끼리 분류합니다.
의미 체계에 대한 이해의 공유에 중점을 두면서 정의의 모든 변형을 논의합니다. 용어를 명확하게 정의하는 단계까지 파고들지 않도록 유의하십시오.

팁: 동일한 정의에 대해 여러 이름을 사용하는 경우가 있습니다. 이러한 경우 하나의 이름과 정의로 통일하십시오. 하나의 이름과 정의가 존재하지 않는다면, 함께 새로운 표현을 만드십시오.
벽의 사진을 찍어 내용을 기록합니다.

팁: 모든 팀원의 업무 위치가 동일하다면 스티커 메모를 계속 붙여 놓는 것도 좋습니다. 팀 공간의 벽에 공지 공간을 만들고 이 공간에서 용어 목록을 재구성하십시오. 그러면 팀에게 언제나 활용할 수 있는 용어 참조 벽을 제공할 수 있습니다.

성공/예상되는 성과

공통 용어의 시작 목록을 식별하고 각각에 대한 정의를 내렸으면 성공한 것입니다. 축하합니다. 보편적인 언어 용어집을 완성했습니다.

진행자 메모 및 팁

공유하는 동안 시간이 부족한 경우 앞으로 예정된 작업과 가장 관련성이 높은 용어를 우선적으로 지정하는 것을 고려하십시오. 그러면 가장 임박한 스토리에서 해당 용어를 다루고 코드베이스에 구축할 수 있습니다.

가능하면 회의실에 한 명 이상의 도메인 전문가가 참여하도록 최선을 다하십시오. 주제를 대표할 수 있는 담당자가 없으면 비즈니스의 현실을 나타내는 공통 용어를 규정하기가 더 힘들 수 있습니다.

실제 예시

권장 자료

보편적인 언어와 이름 지정의 즐거움

DDD: 보편적인 언어와 관련된 질문

Domain-Driven Design Distilled 초판

Domain-Driven Design: Tackling Complexity in the Heart of Software 초판

Practices: 분자 맵

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

분자 작성 프레젠테이션을 검토하고 개념에 익숙해지는 방법, 솔루션을 도출하는 방법, 안티 패턴을 식별하는 방법을 익힙니다.

VMware Tanzu 개발자 센터 슬라이드의 분자
실제 또는 디지털 화이트보드에 예시 분자를 그립니다.
- 사용자 역할 - 지원 대상은 누구입니까? (사용자 역할 사례 사용) 아직 생성하지 않았다면 사례를 진행합니다.
- 문제 - 이들의 문제는 무엇입니까?
- 솔루션 - 우리의 솔루션은 무엇입니까?
3명으로 구성된 그룹으로 나누거나 각 사람에게 종이에 3개의 원과 여러 개의 분자를 그리도록 요청합니다. 최대한 많은 솔루션을 생각해야 합니다.

원격 팁: 여러 화상 채팅 시스템이 보다 긴밀한 협력을 위해 일시적으로 대규모 그룹을 더 작은 그룹으로 분리하는 “소회의실” 또는 이와 유사한 수단을 지원합니다. 또한, 그룹이 원격 환경에 있더라도 실제 종이를 사용하여 카메라에 비출 수도 있습니다.
보드에 분자를 테이프로 붙이거나 업로드합니다. 이들을 검증해야 할 가정으로 취급합니다.
조용히 읽고 점 투표를 실시하여 분자 1개까지 세분화합니다.

성공/예상되는 성과

팀으로서 문제와 앞으로 나아가기 위한 솔루션(스냅샷)에 대한 의견의 합치를 보았으면 연습이 성공적인 것입니다. 사용자를 사람으로 생각한다면 제대로 진행하고 있는 것입니다.

실제 예시

Practices: 사용자 역할 에코시스템 맵

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

화이트보드에 기본 사용자 역할을 그립니다.

팁: 필요한 경우 먼저 그룹을 나눌 수 있습니다.
각 추가 사용자 역할에 대해 다음을 그립니다.
- 사람
- 사람의 이름
- 각 사람들이 밤새 몰두하는 것이나 자신들의 목표를 설명하는 문장 적기
기본 사용자 역할과 협력하는 다른 사용자 역할을 연결하는 화살표를 그립니다.

팁: 필요한 경우 화살표와 함께 “다음을 지원함”, “다음에게 보고함” 또는 “다음으로부터 지원받음”과 같은 동사를 사용하여 관계를 명확히 밝힙니다.

성공/예상되는 성과

팀이 모든 사용자와 그들이 우려하는 사항, 그리고 서로의 관계에 대한 이해를 공유했습니다.

Practices: 설계 스튜디오

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

추가 원격 팁은 아래 변형 섹션에 있습니다.

샘플 안건 및 메시지

사용자 여정, 사용자 역할 또는 팀이 작성한 시나리오를 활용하여 해결하려는 문제가 무엇이며 누구를 위해 해결하려고 하는지 정의합니다.

가장 큰 해결 과제는 무엇입니까?
모든 사람이 종이를 4, 6 또는 8절로 또는 디지털 공동 작업 툴에서 이와 유사한 분절로 접도록 지시합니다. 목표는 상세한 해결책이 아니라 여러 작은 아이디어를 생각해 내는 것입니다.

팁: 참가자가 스케치를 그리는 것을 어려워한다면 10분 동안 그리기 준비 연습(기본 도형, 표현, 막대 그림, 그림의 단순한 와이어 프레임 표시, 텍스트, 상자)을 수행합니다.
다음으로 5~10분 동안 타이머를 설정하고 각 사람에게 다음과 같은 형식으로 최대한 많은 아이디어를 생각해 내라고 합니다.

“어떻게 하면 [문제]를 해결하는 경험을 설계할 수 있을까요? 종이를 사용하여 최대한 많은 아이디어를 떠올려 보고 어떻게 그릴지는 과도하게 생각하지는 마십시오.”

팁: 종이를 컴퓨터 또는 휴대폰 화면처럼 생각하지 말고 지나치게 세부 사항에 사로잡히지 않는 것이 중요합니다. 우리는 개략적인 개념의 아이디어를 많이 도출하려고 합니다.
시간이 다 되었으면 각 사람에게 자신의 생각을 공유해 달라고 요청합니다(사람당 1~2분). 팀이 질문이나 피드백을 스티커 메모에 적고 시트에 붙이도록 합니다. 모두에게 공유할 기회가 주어지도록 하십시오.
공유를 마쳤으면 두 번째 아이디어 생성 라운드를 진행합니다. 이번에는 처음부터 시작하지 않고 앞서 논의한 아이디어를 기반으로 생각을 발전시킵니다.
모든 사람이 다시 자신의 생각을 공유하도록 합니다(사람당 1~2분).
화이트보드에 모든 설계를 테이프로 붙이거나 추가합니다. 조용히 검토할 수 있도록 공간을 적절하게 할당합니다.
각 참가자에게 적절한 수의 점(예: 참가자가 8명인 경우 5개의 점을, 참가자가 이보다 적거나 많은 경우 그에 따라 적거나 많은 수의 점을 제공. 목표는 사람들이 자신의 표에 대해 심사숙고하도록 유도하는 것임)을 할당하고 5~7분 동안 타이머를 맞춘 후, 그들에게 전체 스케치가 아닌 구현될 경우 가장 성공적일 것으로 생각하는 스케치 요소에 점을 부착하도록 합니다.
완료되면 점의 분포를 살펴보고 가장 많은 점을 받은 항목에 대해 논의합니다. 그룹에게 해당 스케치에 점을 찍은 이유를 설명하고 화이트보드, 종이 또는 디지털 워크스페이스에 각각에 대한 근거를 분류해 보라고 요청합니다.

성공/예상되는 성과

특정 문제를 해결하는 방법에 대해 각 참가자가 가지고 있는 아이디어를 분명하게 파악했으면 성공한 것입니다. 이러한 아이디어를 “종이에” 적고 그룹별로 이에 대해 논의했으며, 팀이 사용자 가치를 가장 잘 창출할 것이라고 느끼는 항목을 투표하고, 근거를 확인했습니다.

실제 솔루션의 모습은 이러한 스케치와 다를 가능성이 높습니다. 따라서 팀이 특정 요소에 대해 수행할 작업에 대해 어떻게 느꼈는지에 대한 이유를 파악하면 설계 팀이 반복 작업을 수행하면서 올바른 선택을 내리는 데 도움이 됩니다.

설계 스튜디오에서 도출된 최상위 아이디어는 차후에 추진되고 설계자에 의해 더욱 통합될 것입니다.

진행자 메모 및 팁

스케치에는 검은 색의 네임펜 또는 끝이 뾰족한 펜을 사용하고 코멘트에는 색깔이 있는 펜을 사용합니다. 권장 색상은 빨간색입니다.
보다 간편하게 참조할 수 있도록 사람들에게 각 아이디어에 제목을 붙이도록 합니다.
사람들에게 아이디어를 시각화하기 위해 그리기 실력이 필요한 것은 아니라고 독려합니다.
긍정적인 태도를 보이되 언제든 절충 사항에 대한 건설적인 의견을 제공해야 합니다.
사용자 여정에 초점을 맞추도록 합니다.
다양한 크기의 종이와 사각형을 사용할 수 있습니다. 중요한 것은 세부 사항이 아니라 아이디어의 양입니다.

변형

원격 팀의 경우

팀이 원격 환경에 있더라도 이 워크샵을 추진할 수 있습니다.

많은 온라인 협업 솔루션이 그리기 기능을 갖추고 있지만, 디지털 기술을 덜 사용하고 종이와 카메라를 더 많이 사용하는 것이 좋습니다.

사람들에게 위에 설명한 대로 실제 종이를 접고 그 위에 그림을 그리도록 지시합니다.
다음으로, 팀에게 휴대폰으로 사진을 찍고 공동 작업 공간에 올리라고 요청합니다.

또는 채팅 앱, e-메일이나 텍스트 메시지를 통해 진행자에게 사진을 보냅니다. 사람들은 웹캡으로 자신의 그림을 찍을 수도 있습니다. 이 경우 진행자가 스크린샷을 찍고 이미지를 공동 작업 공간에 올리면 됩니다.
점 투표를 비롯한 기타 모든 단계에서 그림 사진과 함께 디지털 화이트보드를 사용하십시오.

이전 단계

실제 예시

Practices: 설계 크리틱

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

프로젝트 팀이 크리틱 대상인 설계 아티팩트의 인쇄물을 거는 동안 구체적이고 친절한 언어를 사용하여 모든 사람에게 오늘 참여한 사람들의 임무는 프로젝트 팀이 솔루션이 아닌 설계와 관련된 당면 과제를 찾는 과정을 돕는 것임을 상기시킵니다.

팁: 필요할 경우 프로젝트 팀에게 논의한 사항을 메모하고(예를 들어 Sketch 또는 텍스트 편집기에) 특정 작업을 옹호하지 말라고 상기시키십시오. 팀원은 프로젝트의 맥락에서 어떤 작업을 수행하거나 수행하지 말아야 할지 결정할 수 있습니다.
모든 사람이 자리에 앉으면 프로젝트 팀에게 다음 질문을 묻고 모든 사람이 볼 수 있도록 화이트보드에 각 질문에 대한 답변을 적습니다.
- 크리틱 대상인 애플리케이션의 이름은 무엇입니까?
- 애플리케이션의 목표는 무엇입니까? 다음과 같은 답변을 예로 들 수 있습니다. “‘Super Bowl Land’는 미식축구 경기 시즌 동안 미식축구 팬의 비용 청구와 계정 정보를 관리하는 콜 센터 상담원을 위한 일련의 화면 구성입니다.”
- 사용자는 누구입니까?
- 어떤 종류의 피드백을 찾고 있습니까?
팁: 여기에서 제품 가치 제안과 기능을 언급할 수 있습니다. 이 전체 도입 과정을 몇 분 길이로 유지하십시오.

프로젝트 팀이 너무 많은 것을 설명하게 되면 시간을 낭비하고 회의실에 있는 모두가 의욕을 잃어버릴 수 있습니다. 이 경우 팀에서 얻을 수 있는 피드백이 “이것을 이해하지 못하겠습니다”나 “무슨 말인지 모르겠습니다”

모든 사람이 크리틱 대상인 애플리케이션과 원하는 피드백에 대해 이해했으면 8분 타이머를 설정하고 크리틱 담당자들이 조용히 다음에 대한 크리틱을 진행합니다.
- 화면 검토
- 건설적이며 긍정적인 코멘트를 담은 스티커 메모 작성
팁: 작업 시간에 침묵을 유지하면 모든 사람이 설계에 대해 보다 깊게 생각하고 스스로 경험할 수 있으며, 이 경험이 곧 실제 환경에서 설계를 경험하는 방식으로 이어집니다.

별도의 의견을 남기지 않아 설계의 긍정적인 부분이 이후에 삭제되는 일이 없도록 좋은 점을 찾으려고 노력하십시오.

8분의 시간이 흐르면 크리틱 담당자들이 자신의 스티커 메모를 적절한 화면에 붙이도록 하십시오.

팁: 자신의 의견을 공유하기 전에 종이에 적으면 모두가 동일한 의견을 제시하거나 “그룹 사고”에 빠질 가능성을 줄일 수 있습니다.
메모를 검토하고 논의할 핵심 주제를 개시하여 여러 번 언급된 패턴과 영역을 찾습니다. 부정적인 의견과 긍정적인 의견을 혼합하고 의견이 불분명한 경우 그룹에게서 의견에 대해 더 자세한 설명을 요청하십시오.

팁: 사람들이 문제에 대해 서로 다른 솔루션이나 관련 설계에 대해 말하기 시작하면, 모든 사람이 문제에 관해 프로젝트의 설계자와 동일한 맥락에 있거나 같은 수준의 지식을 보유하고 있지 않다고 상기시키십시오.
그룹이 각 주제에 관해 논의할 때 다음 주제로 넘어가기 위해 핵심 작업/업무를 화이트보드에 적습니다.

팁: 문제가 작업으로 전환되면(“만능 해결사 위젯은 존재하지 않습니다. 대체 설계를 찾아보십시오.”) 해당 항목에 대한 논의를 멈춰야 합니다.

성공/예상되는 성과

모든 의견을 검토하고 모든 문제를 작업으로 전환했으면 작업이 완료된 것입니다.

진행자 메모 및 팁

설계 크리틱을 진행하는 방법과 관계없이 회의실을 예약하고 스티커 메모, 네임펜, 테이프 등과 같은 모든 용품을 준비해야 합니다.

실제 예시

권장 자료

Discussing Design - Adam Conner, Aaron Irizarry

Practices: 솔루션 브레인스토밍

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

원격 팁: 분산된 팀의 경우 Miro 또는 이와 유사한 “디지털 화이트보드”를 사용하고 디지털 환경에 대면 단계를 도입하십시오. 예를 들어 종이를 나누어 주는 대신 각 팀원이 공유 디지털 화이트보드에 있는 자신의 섹션 내에서 작업하도록 하십시오.

샘플 안건 및 메시지

각 문제 또는 통찰력을 각각 타블로이드지(11"x17")/A3 용지와 같은 큰 종이 또는 디지털 워크스페이스의 섹션에 붙입니다.
문제 또는 통찰력이 부착된 종이를 각 팀원에게 분배하거나 할당합니다.
팀원들에게 자신에게 할당된 문제 또는 통찰력을 “어떻게 하면 ~할 수 있을까요?” 형태의 문장으로 변환하고 새로운 색상의 대형 스티커 메모에 내용을 명확히 적은 다음 원래 문제 또는 통찰력 위에 붙이도록 요청합니다.

팁: 팀원보다 문제와 통찰력의 수가 많은 경우 팀을 쌍으로 나누고 각 쌍에 여러 문제 또는 통찰력을 할당할 수 있습니다. 이 방법은 문제와 통찰력보다 많은 수의 사람이 있을 때에도 유용할 수 있습니다. 여러 화상 채팅 시스템이 보다 긴밀한 협력을 위해 일시적으로 대규모 그룹을 더 작은 그룹으로 분리하는 “소회의실” 또는 이와 유사한 수단을 지원합니다.
그룹을 한 바퀴 돌면서 각 사람 또는 짝에게 자신들의 원래 문제 또는 통찰력과 해당 항목에서 생성한 “어떻게 하면 ~할 수 있을까요?” 문장을 공유하도록 합니다. 모든 문장에 만족할 때까지 팀 단위로 조정을 수행합니다.

팁: 이 과정이 오래 걸릴 수 있으니 공유의 시간 제한을 설정하십시오. 조정 또한 오래 진행될 수 있으니 역시 시간 제한을 설정하는 것이 좋습니다.
각 사람이 종이 한 장 또는 디지털 화이트보드의 섹션 하나를 가지고 있는지 확인하고, 3~4분 동안 타이머를 설정하여 모두가 조용히 “어떻게 하면 ~할 수 있을까요?” 문장을 해결할 수 있는 잠재적인 아이디어에 대해 브레인스토밍하도록 합니다. 아이디어는 원하는 만큼 단순해도, 공상적이어도 됩니다.
시간이 다 되었으면 모두에게 종이를 자신 옆의 사람에게 건네도록 요청하고(원격 환경에서는 순서를 지정) 5단계를 반복합니다.

팁: 라운드를 진행하면서 점점 더 풍부한 아이디어로 각 솔루션을 브레인스토밍합니다. 팀에게 각 라운드의 일부를 이미 존재하는 아이디어에 새로운 내용을 추가하는 데 할애하도록 제안합니다. 이를 통해아이디어의 중복을 제거하고 모두가 완전히 새로운 아이디어에 집중할 수 있습니다.
그룹을 돌며 브레인스토밍을 진행하여 시작한 사람 차례로 다시 돌아왔다면 이미 많은 아이디어가 만들어져 있을 것입니다.

성공/예상되는 성과

최상위 문제 및 통찰력과 직접 관련된 아이디어를 추출하고 이들의 추가 개선 사항을 확보했으면 성공한 것입니다.

진행자 메모 및 팁

참석한 사람의 수에 따라 적절한 시간을 조정해야 할 수 있습니다. 사람들이 아이디어를 읽고 새로운 아이디어를 생각해 낼 충분한 시간을 확보하도록 하십시오(이는 전달-브레인스토밍 프로세스를 발전시켜 나가는 과정에서 특히 중요합니다).

이전 단계

다음 단계

솔루션 다듬기 - 곧 제공 예정
솔루션 우선순위 지정

Practices: 솔루션 우선순위 지정

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

파란색 마스킹 테이프를 사용하여 화이트보드에 2x2 표를 구성하고 상황에 맞는 매개 변수를 사용하여 명확하게 축에 레이블을 지정합니다. 예를 들면 다음과 같습니다.
- X-축 - 높은 복잡성(왼쪽)에서 낮은 복잡성(오른쪽)
- Y-축 - 낮은 사용자 가치(하단)에서 높은 사용자 가치(상단)
팁: “높은 가치”를 정의할 때는 최상위 “어떻게 하면 ~할 수 있을까요” 질문과 연관시키십시오.

화이트보드 공간이 제한적인 경우, 창문에 이 연습을 수행할 수 있습니다.
2x2 사분면에 솔루션 스티커 메모를 구성하고(한 바퀴 돌거나, 필요할 경우 한 사람씩) 논의합니다.

팁: 모두(PM, 설계자, 엔지니어)가 사용자 가치를 저울질하되 엔지니어링 팀만이 상대적인 복잡성을 파악하도록 하십시오.

이 기회를 활용하여 특히 비즈니스 기반인 제품에서 모든 부동의 요구 사항을 추출합니다.
관리 가능한 수의 솔루션이 상단 오른쪽 사분면에 위치하는 것으로 끝을 맺도록 최선을 다합니다. 팀이 최종적으로 마무리된 상황에 편안함을 느껴야 합니다.

팁: 오른쪽 상단 사분면에 우선순위인 솔루션이 너무 많은 경우 사분면 내에 축을 다시 그려 솔루션을 더욱 세분화합니다. 축은 절대적인 것이 아니라 상대적이기 때문에 이렇게 해도 괜찮습니다. 관리 가능한 지점에 도달할 때까지 계속 조정하십시오.

성공/예상되는 성과

팀이 솔루션의 우선순위를 지정했으며 탐색할 상위 솔루션의 관리 가능한 목록을 식별했다는 사실에 편안함을 느낀다면 완료된 것입니다.

진행자 메모 및 팁

2x2 우선순위 지정

이전 단계

솔루션 브레인스토밍
솔루션 다듬기 - 곧 제공 예정

다음 단계

시나리오 워크스루 – 곧 제공 예정
설계 스튜디오

실제 예시

Practices: 스토리 매핑

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

매핑하기 전에 짧은 제품 또는 기능 개요를 작성하여 매핑하는 대상의 틀을 짜고 범위를 제한합니다. 이를 하나의 거대한 스토리로 생각하십시오. 생성하는 제품 또는 해결하는 문제는 무엇입니까? 고객 또는 사용자는 누구입니까? 각 사용자는 어떤 이점을 얻을 수 있습니까? 이 스토리를 구축하는 데 관심이 있는 이유는 무엇이며 자신에게 어떤 이점이 있습니까?
각 참가자에게 동일한 색상의 스티커 메모 뭉치를 나누어 줍니다. 모든 사람이 이 스티커 메모를 사용하여 사용자 작업을 통한 제품의 스토리를 이야기하게 될 것이라고 설명합니다.

팁: “기본 사용자”가 수행하는 첫 번째 작업으로 스토리를 시작해야 합니다. 스토리가 전개됨에 따라 다른 사용자가 스토리에 개입되어야 할 수 있으며, 그래도 괜찮습니다. (때때로 서사적인 관점에서 컴퓨터 또는 기기를 사용자로 엮어 넣어야 할 수도 있습니다.) 참가자들이 특정 스티커 메모에서 어떤 사용자가 작업을 수행하는지만 알 수 있도록 하면 됩니다.
모든 사람에게 몇 분간 조용히 제품 또는 솔루션의 서사적인 흐름을 함께 구성하는 사용자 작업을 생각해 내라고 요청합니다.

팁: 이 시점에서는 스토리를 얕고 폭넓게 유지하는 것이 중요합니다. 이 시점에서는 모든 세부적인 내용을 끄집어내기보다는 전체 스토리를 떠올려야 합니다.
한 번에 하나씩 개별 작업의 각 참가자에게 질문하여 화이트보드에 사용자 작업을 놓기 시작합니다. 중복 항목이 있는 경우 단계를 가장 잘 포착하는 항목을 사용하고 나머지는 버립니다.

팁: 이 단계에 대해 만족스러운 하나의 경로에 집중하십시오. 그런 다음 차후에 부차적인 작업을 통합할 것입니다.

각 작업을 추가한 후 그룹과 함께 순서가 올바른지, 그리고 중요한 작업을 건너뛰지 않았는지 확인합니다.
선택 사항: 스티커 메모를 사용하여 사용자 스토리 그룹에 해당 에픽으로 레이블을 지정합니다.
참가자들이 화이트보드 앞으로 나와 매핑 작업에 참여하도록 합니다. 이들에게 이미 개괄적으로 작성한 “만족스러운 경로”에서 변형이나 편차가 있는지 생각해 보라고 요청합니다.

팁: “~한다면 좋지 않겠습니까?” 놀이를 진행하여 원하는 만큼 공상적인 스토리를 생각해 보는 것도 좋습니다. 제안된 UI 또는 비즈니스 규칙과 같은 제품 세부 사항을 추가합니다.
참여자들에게 스티커 메모에 부차적인 작업을 적도록 요청하고 기반 스티커 메모 아래에 이를 적절한 순서로 배치합니다.
맵을 분할할 릴리스의 수를 결정합니다(이것은 나중에 언제든 조정할 수 있습니다).
상대적으로 동등한 가치를 제공하도록 테이프를 사용하여 스토리 맵을 사용자 스토리 세그먼트(릴리스)로 나눕니다.
각 릴리스의 목표를 정의하고 해당하는 각 릴리스 옆에 적습니다.
각 사용자 스토리의 배치를 재평가합니다. 필요한 경우 스토리를 옮깁니다.

성공/예상되는 성과

팀이 자신들이 구축해야 할 항목과 사용자 스토리의 백로그가 정확하게 표현되었다고 느끼면 완료된 것입니다.

진행자 메모 및 팁

사용자 작업은 “e-메일 읽기” 또는 “메시지에 응답하기”와 같은 짧은 동사구입니다. 너무 자세하게 작성하지 말고 기능적인 수준으로 작업을 유지하십시오. 이는 개인이 작업 도중에 휴식을 취하지 않고도 마칠 수 있을 정도가 작업의 적절한 규모라는 의미입니다. 예를 들어, 일상적인 루틴 스토리에서 작업은 “샤워를 하는 것”일 수 있습니다. 샤워의 “수온 변경”은 너무 상세하고(하위 기능), “출근 준비”는 너무 광범위합니다.

만족스러운 경로를 먼저 작업한 다음 심층 탐구 부분에서 사용자가 제품에 대해 수행할 수 있는 대체 경로를 포착하십시오.

Practices: 시나리오 작성

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

실제 또는 디지털 화이트보드에 4개의 열을 만들고 각각에 다음과 같이 레이블을 지정합니다.
- 사용자
- 목표
- 컨텍스트
- 시나리오
팁: 시간이 부족하거나 전체 팀이 다른 작업으로 바쁜 경우 혼자서 또는 자신의 짝과 함께 원하는 프로그램을 처리하는 단어를 사용하여 이 활동을 수행할 수 있습니다.
사용자를 정의하는 것으로 시작하고, 팀에서 생성한 사용자 역할을 사용하는 것이 좋습니다. 작성한 내용으로 다음 질문에 답변할 수 있어야 합니다.
- 이 사람은 누구입니까?
- 이 사람의 역할은 무엇입니까?
팁: 사용자 역할이 이미 있다면 처음부터 새로 만드는 대신 이 섹션에서 바로 사용할 수 있습니다.

사용자 역할 활동을 사용하여 팀이 잘 형성된 사용자 역할을 생성하도록 이끌 수 있습니다.
다음으로, 시나리오의 목표를 정의합니다. 작성한 내용으로 다음 질문에 답변할 수 있어야 합니다.
- 사용자가 달성하려고 하는 것은 무엇입니까?
- 시나리오가 완료되는 때는 언제입니까?
이제 시나리오의 컨텍스트를 정의합니다. 작성한 내용으로 다음 질문에 답변할 수 있어야 합니다.
- 이 장면이 어디에서 발생하고 있습니까?
- 이 시나리오가 발생했을 때 사용자는 무엇을 하고 있습니까?
- 사용하는 기기가 있는 경우 어떤 기기를 사용합니까?
- 사용자가 다른 사람과 함께 있다면 누구와 있습니까?
마지막으로, 다음 사항에 대해 적도록 유의하면서 처음부터 끝까지 시나리오의 개요를 작성합니다.
- 주요 작업이 시작되기 전에 사용자가 수행하는 업무와 관련된 모든 내용
- 사용자가 목표에 도달하기 위해 취하는 작업과 이러한 작업을 수행하는 이유
- 시나리오의 목표를 달성한 후에 사용자가 수행하는 업무와 관련된 모든 내용
팁: 미래 상태의 시나리오를 작성하는 경우, 솔루션을 포착하는 방법과 관련하여 너무 규범적인 태도를 취하지 않도록 주의하십시오. 팀이 폭넓게 아이디어를 구상할 수 있도록 어느 정도의 모호함을 용인해야 합니다.

성공/예상되는 성과

팀이 현재 또는 미래 시나리오의 범위를 이해하고 자신 있게 후속 활동(연구, 설계 스튜디오 등)을 지원하는 데 이를 사용할 수 있다고 느끼면 성공적인 것입니다.

진행자 메모 및 팁

현재 상태 시나리오의 예시:

목영업자가 현재 대면으로 양을 구매하는 방식

미래 상태 시나리오의 예시:

목양업자가 신제품을 통해 인터넷으로 양을 구매하는 방식

이전 단계

다음 단계

설계 스튜디오

Practices: 여정 맵

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

팀이 매핑하는 사용자 여정을 식별합니다. 기존 사용자 역할을 활용하고 사용자 역할이 여럿인 경우 시작할 가장 중요한 사용자 역할을 선택합니다.
혼자서 혹은 함께 매핑합니다(10분).
- 각 사람이 사용자 여정을 자신 앞에 생성하고 각 단계를 개별 스티커 메모로 분리하도록 합니다. 10개 내외의 스티커 메모로 구성된 가로 타임라인의 모습입니다.
팀에게 개별 여정을 공유합니다(10분).
- 각 사람은 한 번에 하나씩 자신의 타임라인을 화이트보드에 붙입니다. 첫 번째부터 모든 타임라인이 잘 정렬되도록 각 타임라인은 마지막 타임라인 아래에 덧붙여야 합니다.
점 투표를 실시합니다(10분).
- 모든 사람이 서로의 여정을 검토하고 질문이 있을 경우 질문하도록 합니다. 질문이 끝나면 모든 사람에게 점 스티커를 나누어 주고 가장 흥미롭거나 중요하다고 생각하는 단계에 투표하도록 합니다.
하나의 큰 스토리로 통합합니다(10분).
- 점이 없는 모든 스티커 메모를 버립니다.
- 중복 스티커 메모를 합치고 쌓여 있는 타임라인을 하나의 큰 타임라인으로 재편성합니다.
- 스티커 메모 사이에 화살표를 그리고 가능한 경우 각 단계 사이의 소요 시간을 표시합니다. 여러 “경로”가 존재하는 경우 타임라인을 수직으로 분할할 수 있습니다.
고객 감정과 해결 과제를 표시합니다(10분).
- 그룹을 지어 완성된 타임라인을 읽고 사용자 역할이 “해결 과제”를 경험하는 시점을 표시합니다(화이트보드 또는 스티커 메모에서 서로 다른 색상의 마커 사용).
- 뒷받침하는 데이터가 있는 경우 해결 과제에 따라 상승하고 하강하는 수평선을 사용하여 여정 동안에 역할에 따른 사용자의 감정을 추적합니다.
여정에 따른 기회를 식별합니다(10분).
- 팀에게 완성된 여정 맵을 한 번 더 읽고 모든 참가자에게 개입/개선이 가능한 순간을 발견할 때마다 “어떻게 하면 ~할 수 있을까” 문장을 스티커 메모에 적도록 합니다.

성공/예상되는 성과

여정 맵의 마무리 시점에 이르면 페르소나의 경험에 대한 종합적인 뷰를 공유하게 됩니다. 프로세스는 사용자의 해결 과제를 해결할 기회를 드러내고 “프레이밍” 프로세스 동안 잘못된 조율을 방지합니다.

진행자 메모 및 팁

사용자 역할당 하나의 여정 맵을 작성합니다. 고려할 다른 사용자 역할이 있는 경우, 이들을 단일 사용자 역할의 관점에서 접점으로 매핑합니다.
세부 사항과 복잡성을 이해하려면 서비스 Blueprint를 사용하여 개별 고객 여정에 제품/서비스의 “백스테이지 작업”과 “지원 프로세스”를 매핑하는 것을 고려해 보십시오.

이전 단계

다음 단계

서비스 Blueprint 시나리오 작성

실제 예시

권장 자료

설계 스프린트 여정 매핑 기술

여정 맵과 서비스 Blueprint의 차이점

경험 매핑에 대한 적응형 경로 가이드 PDF 다운로드

Practices: 연구 합성

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

화이트보드에 다음 카테고리를 작성합니다. 이때 많은 수의 스티커 메모를 붙일 수 있도록 카테고리 간에 충분한 공간을 남겨두어야 합니다.
- 일상적인 하루
- 해결 과제
- 목표
- 알면 좋을 사항
- 마법의 지팡이
- 조치
일반적으로 마지막으로 수행하기는 하지만 스티커 메모가 실행 불가능함을 파악할 때는 이 시점에 주차장을 생성할 수도 있습니다.

팁: 이미 사용자 인터뷰 질문을 카테고리로 그룹화한 경우 목표 결과를 더 많이 얻기 위해 합성에 기술 사용, 시스템 및 통합 등의 카테고리를 사용하십시오.
사용자를 식별하는 섹션(서로 다른 색상의 스티커 메모에 각 사용자를 적은 메모)을 포함하여 스티커 메모 결과를 해당 카테고리 아래에 붙입니다.

팁: 여러 명이 메모를 작성했을 수 있으므로 중복된 항목이 생기는 것은 자연스러운 현상입니다. 이러한 경우 팀과 함께 어떤 스티커 메모가 의견을 가장 잘 포착했는지 의논한 다음 중복 메모를 버립니다.
모두 붙였으면 스티커 메모 그룹화 프로세스를 시작합니다. 이 활동은 당시 시점에 가능한 사람에 따라 팀으로, 짝을 지어서, 혹은 개별적으로 수행할 수 있습니다.
- 스티커 메모를 사용자 관점에서 적은 감정으로 그룹화합니다.
- 감정(웃는 모습, 반응이 없는 표정, 찡그림)을 적절히 포착하는 웃는 얼굴을 그립니다.
- 그룹을 구성하는 개별 사용자의 수를 적습니다.
- 완료했으면 섹션을 다시 확인할 필요가 없도록 각 그룹에 원을 그립니다.
원격 팁: 여러 화상 채팅 시스템이 보다 긴밀한 협력을 위해 일시적으로 대규모 그룹을 더 작은 그룹으로 분리하는 “소회의실” 또는 이와 유사한 수단을 지원합니다.
모든 스티커 메모를 그룹화(또는 주차장에 배치)했으면 (a) 수행할 작업과 (b) 다시 테스트해야 할 발견 사항을 식별하는 또다른 라운드를 진행합니다.
벽에 그려진 도출 결과의 와이드 사진(공유하거나 데크 배경으로 사용하기에 좋음)과 보다 명확한 클로즈업 사진(각 감정 그룹을 구성하는“글자 그대로”를 다시 읽기 위한 용도) 사진을 찍습니다.

성공/예상되는 성과

목표는 실행 가능한 통찰력으로 연구에서 벗어나 모든 연구 목적을 검증했거나 실격 판정했는지 파악하고 설계 및/또는 제품에 일련의 실행 가능한 다음 단계를 제공하는 것입니다.

진행자 메모 및 팁

필요에 따라 현재까지 확보한 사용자 역할 데이터를 기반으로 진행하십시오. 모든 새로운 사용자 통찰력을 취하고 기존 사용자 역할에 대한 가정을 검증 또는 실격 판정하거나, 이를 뒷받침할 새로운 정보를 찾는다면 새로운 사용자 역할을 생성하십시오.

가정을 추적하는 데 Trello 또는 이와 유사한 툴을 사용하는 것도 좋습니다.

이는 후속 반복 계획 수립 회의(IPM, 스크럼 스프린트 계획 수립과 유사함) 시에 발견한 결과를 공유하는 데에도 도움이 되며, 실제 연구 세션에 참여하지 않았던 모든 사람을 포함하는 전체 팀이 학습한 내용을 통해 이점을 누릴 수 있습니다.

또는 식별한 사용자 역할에 대한 질문에서 카테고리를 생성할 수도 있습니다. 이러한 카테고리는 사용자 역할이 동일한 사용자에게만 적용되는 경향이 있습니다. 예를 들어 합성 중에 사용자 인터뷰와 이해관계자 인터뷰를 혼합하지 마십시오.

이전 단계

가정

Practices: 이해관계자 맵

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

시작할 때 모든 참가자에게 큰 스티커 메모를 나누어 주고 다음을 적으라고 합니다.
- 이름
- 제목
- 부서
화이트보드에 스티커 메모를 정렬한 다음 활동을 시작하고, 중앙에 핵심 팀을 배치하고, 모여 잇는 부서와 프로젝트 스폰서들이 그 주변을 둘러싸도록 합니다.

참고: 핵심 팀 구성원은 프로젝트를 전담할 사람들입니다.

팁: “허수아비” 버전의 이해관계자 맵을 작성하면 처음부터 맵을 작성하는 것에 비해 참가자들이 그들이 보는 것을 간편하게 편집할 수 있습니다.

사전에 사람들이 이름표를 달도록 하면 호명할 때 유용합니다.
각 “허수아비” 그룹을 돌아다니면서 참가자들에게 어떻게 핵심 팀을 지원할지 묻습니다.
각 부서와 팀을 원으로 그리고 선과 화살표로 사람들이나 팀을 연결합니다.
특히 원으로 표시된 부서에 사람이 여럿 있는 경우 주요 연락처에 별표를 그립니다.

성공/예상되는 성과

관련된 이해관계자들이 공유된 이해를 바탕으로 팀이 관계를 확립하고, 필요한 경우 심층 탐구하고, 적절히 소통했으면 성공적인 것입니다.

진행자 메모 및 팁

이 연습은 시간이 길어지는 경향이 있습니다. 여러분의 역할은 각 설명을 간결하게 유지하고 팀에서 후속 작업을 진행할 사람을 지정하는 것입니다.

Practices: 제품 평가

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

다양한 이유로 소요 시간은 크게 달라집니다. 예를 들어 데이터를 이미 보유하고 있으며 상대적으로 개략적인 수준의 추정치를 생성하는 경우 반나절이 걸릴 수 있습니다. 제품이 복잡하고 많은 데이터를 수집해야 하며 상세한 추정치를 생성하는 경우 몇 주일이 걸릴 수 있습니다.

샘플 안건 및 메시지

가치 브레인스토밍(30분)

전체 핵심 팀을 불러 모읍니다.

5분 동안 조용히 자신의 팀이 창출하고 있다고 믿는 가치를 생각해 내도록 합니다. 다음과 같은 메시지를 사용하여 참여자들이 집중하도록 도울 수 있습니다.
- 어떻게 다른 사람의 삶/업무를 보다 간편하게 만들고 있습니까?
- 자신의 삶을 간편하게 만들기 위해 그 사람들이 지금 무엇을 할 수 있습니까?
- 이전에 없었지만 우리가 만든 연결은 무엇입니까?
- 우리가 작업 중인 시스템이 지금 어떻게 더 효율적입니까?
그룹에서 자신들이 작성한 항목, 그리고 해당 항목과 관련된 선호도 맵(그룹)을 공유하도록 합니다. 이 항목은 2단계에서 사용합니다. 팀을 위한 메시지의 틀을 짜는 방법에 관한 예시와 추가 아이디어는 관련 Miro 보드의 “가치 브레인스토밍” 부분을 참조하십시오.

팁: 적절할 경우 이 단계 중에 이해관계자를 포함시킬 수 있습니다. 재량을 발휘하십시오.
가정 식별

계산의 기반이 될 가정을 선택합니다. 이는 일반적으로 다음을 의미합니다.
- 우선순위로 지정된 가치 조각. 1단계에서 브레인스토밍과 선호도 매핑을 수행한 가치 아이디어에서 몇 가지 상위 항목을 선택합니다. 생성된 가치가 다양하겠지만, 너무 많은 항목을 포함할 경우 이 연습이 어려워지고 가장 중요한 항목에 집중하지 못하게 될 수 있습니다.
- 단위. 일반적으로 가치는 금액을 기준으로 평가되지만, 시간 역시 자주 쓰이는 평가 기준입니다. 팀에 가장 적합한 단위를 사용하십시오.
- 시스템 경계. 매우 중요하지만 간과하기 쉬운 사항입니다. 다음을 결정해야 합니다.
  - 포함할 시간의 양(예: “차후 2년 동안 생성되는 가치 포함 예정”)
  - 가치를 생성할 사용자 수(예: 제품을 사용하는 사람들만, 또는 해당되는 사람들의 제품을 사용하는 사람 또한 포함할 수 있음)
명확한 가정을 식별하는 방법에 관한 추가 참고 사항과 예시는 Miro 보드의 “가정 식별” 섹션을 참조하십시오.
입력 숫자 식별

사용자, 전문가 등에게 질문하는 등 일반적인 사용자 연구 수단을 사용하여 데이터를 수집합니다. 다음 정보를 수집해야 합니다.
- 구축하는 범위 지원에 대한 높음, 낮음, 평균 수준 분류
- 의견의 기반이 되는 근거
“정확할 필요는 없습니다. 직관보다 나은 수준이면 충분합니다.”- The Principles of Product Development Flow, Donald Reinertsen 저

올바른 입력 숫자를 식별하는 방법에 관한 추가 참고 사항과 예시는 Miro 보드의 “입력 숫자 식별” 섹션을 참조하십시오.
가치 및 범위 계산

숫자를 스프레드시트에 넣어 최종 가치와 범위를 계산합니다. 범위를 사용하면 추정치의 정확성에 대한 투명성을 유지할 수 있기 때문에 신뢰 구축에 있어 매우 중요합니다.

팁: 가상의 제품 평가 샘플 스프레드시트를 마음껏 사용하여 샘플 수식을 완성하십시오.

예시는 다음과 같습니다.
ROI 계산

계산한 제품 가치를 팀에서 투자한 금액으로 나누어 팀의 ROI(투자 수익)를 생성합니다.

유용한 참고 사항은 Miro 보드의 “팀의 ROI 계산” 섹션을 참조하십시오.
스토리 공유

슬라이드 또는 다른 아티팩트를 생성하여 이해관계자들을 위해 수집한 정보를 보여줍니다. 클라우드는
- 단순하게 표현하고 가정을 첨부합니다.
- 투명성과 일관성이 정확성보다 중요합니다.
- 항상 반복하십시오(Always Be Iterating, ABI). 새로운 정보를 얻으면 이를 계산과 그 결과로 생성된 추정치를 업데이트하고 개선하는 데 사용하십시오.
보다 유용한 참고 사항은 Miro 보드의 “스토리 공유” 섹션을 참조하십시오.

성공/예상되는 성과

이해관계자들에게 보여줄 수 있으며 쉽게 이해 가능한 가치 제안을 설명하는 단일 슬라이드를 완성했습니다.

진행자 메모 및 팁

과정의 모든 단계에서 면밀한 검토를 진행하십시오. 이해관계자 및 다른 전문가의 의견과 발맞추고 이들이 제공하는 정보를 얻을 수 있도록 함께 확인해야 합니다.

아래에 나열된 몇 가지 우려 사항이 있을 수 있습니다.

“증명할 수 없습니다.”
“지나치게 단순화하여 상황을 정확하게 제시하지 못하는 것 같습니다.”
“누군가 제 계산에 결함을 찾아낼 것입니다.”
“상황이 변하고 이 수치가 무의미해질 것입니다.”

이에 대한 조언은 다음 사항을 기억하라는 것입니다.

제품 평가는 제품 그 자체입니다. 계속해서 사용자 테스트를 진행하고 이를 반복해야 합니다.
언제든지 가정을 활용하십시오. 여러분의 가정이 틀렸을 수 있지만, 그래도 괜찮습니다. 더 나은 정보를 확보했을 때 가정과 그에 따른 계산을 변경하면 됩니다.
제품 평가를 추정하는 것은 이 제품이 가치 있다고 여기는 이해관계자들의 직관에 세부 사항을 추가하는 과정일 뿐입니다.
가정을 수립하고, 가정을 기반으로 계산을 수행하고, 이 계산을 바탕으로 결정을 내리는 관행은 매우 흔한 일입니다. 다양한 업계의 사람들이 모두 매일 이러한 작업을 수행하고 있습니다.

1 또는 2단계에서 통찰력 우선순위 지정과 유사한 우선순위 지정 연습을 활용하고자 할 수 있습니다.

실제 예시

권장 자료

How to Measure Anything - Douglas W. Hubbard – 서적

측정 불가능한 것의 측정 – 블로그 게시글

특히 1단계에 유용한 자료

Practices: 토스트 그리기

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

DrawToast.com의 내용을 재구성한 토스트 그리기는 Tom Wujec이 만든 Wicked Problem Solving™ 툴킷의 일부이며 재미 있게 조직에서 중요한 사항을 밝힐 수 있도록 도움을 줍니다. 이 작업은 Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License에 따라 허가를 받았습니다.

모든 참가자에게 종이와 필기도구를 나누어 줍니다.

원격 팁: 분산된 팀의 경우 Miro 또는 이와 유사한 “디지털 화이트보드”를 사용하고 디지털 환경에 그리기 및 스티커 메모 사용과 같은 대면 환경의 요소를 도입하십시오.
모두에게 마커와 종이를 나눠 주고 참가자들에게 토스트를 만드는 과정의 각 단계를 그려 보라고 합니다. 2~3분의 시간을 제공하십시오.
모두가 볼 수 있도록 각자 자신의 그림을 들어서 자신의 사고 프로세스를 빠르게 설명하도록 합니다. 진행자는 해당하는 경우 공통적인 부분이나 차이점을 언급합니다. 후속 작업으로 일부 생각을 어떻게 간략하게 만들 수 있을지 또는 다른 사람들보다 더 많은 단계로 생각한 사람이 누구인지 질문할 수 있습니다.

3단계에서 개별 그림에 대해 할 수 있는 좋은 질문은 다음과 같습니다.
- 어떤 그림을 그릴지 어떻게 결정했는지에 대해 더 말씀해 주시겠습니까?
- 그림을 그 방식으로 그린 이유는 무엇입니까?
- 어디서 시작할지 어떻게 결정했습니까?
이제 모든 사람이 단순한 메시지로도 각 그림 간에 많은 차이를 이끌어낼 수 있다는 사실을 확인했으니 이 점을 다시 그룹에게 언급합니다.

예시: “이렇게 단순한 일상적인 활동으로도 우리는 공유된 비전을 조정하고 유지하는 것이 어려운 일이라는 사실을 배웠습니다. 소프트웨어 구축에서는 이 과정이 더 어려우며 그것이 바로 우리가 오늘 이 자리에 모인 이유입니다. 우리는 함께 조율하고, 복잡성의 수준을 파악하며, 공통 목표를 향해 나아가는 방법을 찾아야 합니다.”

성공/예상되는 성과

각 참여자가 이처럼 모두에게 익숙한 단순한 일상 활동에서 생겨날 수 있는 사고의 다양성을 확인했으면 작업이 성공한 것입니다.

이를 프로젝트 과정에 대한 비유로 사용하여 소프트웨어 구축이 얼마나 복잡한지, 그리고 조율이 얼마나 중요한지 확인할 수 있습니다. 예를 들어 참가자에게 다음과 같이 상기시킬 수 있습니다. “우리가 토스트를 그릴 때처럼 모두의 머릿속에는 서로 다른 아이디어가 들어 있으며, 우리가 잘 조율하려면 이 아이디어들을 끄집어내야 합니다.”

진행자 메모 및 팁

사람들이 “꼭 그림을 그려야 하나요? 저는 그림을 그릴 줄 모릅니다.”와 같이 말하는 경우도 있습니다. 보통은 그 사람에게 그림을 그리도록 독려하고 아무도 그림을 평가하지 않을 것이라 말하는 것이 좋습니다. 하지만 그 사람이 정말로 그림을 그리고 싶지 않아 하고 글로 적고자 한다면 그것도 괜찮습니다. 일반적으로 그림을 그리지 않기로 한 사람들은 회의실의 다른 모두가 자신의 그림을 완성하고 나면 후회하기도 합니다.

시간이 부족하면 모두에게 자신의 그림을 테이프로 붙이고 휴식 시간 동안 참가자들에게 살펴보라고 하십시오.

변형

원격 팀의 경우

팀이 원격 환경에 있더라도 이 워크샵을 추진할 수 있습니다.

많은 온라인 협업 솔루션이 그리기 기능을 갖추고 있지만, 디지털 기술을 덜 사용하고 종이와 카메라를 더 많이 사용하는 것이 좋습니다.

사람들에게 위에 설명한 대로 실제 종이에 그림을 그리도록 지시합니다.
다음으로, 팀에게 휴대폰으로 사진을 찍고 공동 작업 공간에 올리라고 요청합니다.

또는 사람들이 채팅 앱, e-메일 또는 텍스트 메시지를 통해 진행자에게 사진을 보낼 수도 있습니다. 사람들은 웹캡으로 자신의 그림을 찍을 수도 있습니다. 이 경우 진행자가 스크린샷을 찍고 이미지를 공동 작업 공간에 올리면 됩니다.

디지털 그림 태블릿을 사용한 좋은 예시는 다음과 같습니다.

실제 예시

권장 자료

DrawToast.com에는 TED 강연과 이 주제에 관한 다른 작업의 예시를 비롯한 풍부한 정보가 나와 있습니다. 특히 유용한 참고 자료는 A Primer in Systems Thinking PDF입니다.

Practices: 통찰력 우선순위 지정

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

연구를 통해 발견한 모든 통찰력을 수집합니다.
참여자가 많은 경우(대략 20명 이상), 먼저 스스로에게 “이 통찰력이 이 프로젝트 또는 컨설팅 참여 기간에 대해 정보에 입각한 제품 결정을 내리는 데 도움이 됩니까?"라는 질문을 던져 선별 연습을 수행합니다. 각 통찰력을 “아니요” 또는 “예” 더미로 벽에 분류합니다.

팁: “이 통찰력을 사용하여 솔루션을 만들거나 수정할 수 있습니까? 쓸모 있는 “어떻게 하면 ~할 수 있을까?”와 같은 문장으로 재구성할 수 있겠습니까?” 같은 맥락을 추가하여 이 메시지를 더욱 명확하게 만들 수 있습니다.
목록을 간소화한 후 마스킹 테이프를 사용하여 2x2 표를 만들고 다음과 같이 축에 레이블을 지정합니다.
- X-축 → 크기가 작은 기회(왼쪽)에서 크기가 큰 기회(오른쪽)
- Y-축 → 제품 결정에 덜 유용한 것(하단)에서 제품 결정에 더 유용한 것(상단)
2x2 매트릭스에서 “예” 통찰력을 구성하고 상위 3~5개의 통찰력 목록으로 끝내도록 노력합니다.

팁: 상단 오른쪽 사분면이 통찰력으로 가득 찼다면 해당 사분면 안에 두 번째 2x2 표를 그리고 떨어져 나가는 항목에 대해 논의합니다. 추가 대화를 통해 팀은 일반적으로 새로운 상단 오른쪽 사분면이 진정으로 우선순위가 가장 높은 통찰력과 연관된다는 데 동의하게 됩니다.

성공/예상되는 성과

팀이 초점을 맞출 상위 3~5개 통찰력에 동의하면 성공입니다.

2x2 우선순위 지정

이전 단계

동시 진행

문제 우선순위 지정

다음 단계

솔루션 브레인스토밍

Practices: 팀 가치

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

샘플 안건 및 메시지

화이트보드에 다음 메시지를 적습니다.
- “우리는 ____________을(를) 믿습니다."
- “우리는 ____________을(를) 가치 있다고 여깁니다."
- “우리는 ____________을(를) 존중합니다."
- “우리는 ____________합니다."
6분 동안 타이머를 설정한 다음, 팀에게 대화는 나누지 말고 보드에 적힌 메시지를 이용하여 가치 설명을 떠올려 보라고 요청합니다. 각 가치 설명은 각각의 스티커 메모에 적어야 합니다.

팁: 밝은 배경 음악을 틀어(연주곡이 좋음) 팀원들이 생각하는 동안 긴장이 풀릴 수 있는 분위기를 조성하면 도움이 됩니다.
혼자 회의실을 한 바퀴 돌며 각 팀원에게 가치 설명을 제공하고 이에 대한 자신들의 생각을 공유해 달라고 요청합니다(특히 가치 설명이 명확하지 않을 경우). 다른 팀원들의 유사한 가치 설명이 있는 경우 수집하여 화이트보드에 그룹/테마를 열로 추가합니다.
모든 스티커 메모를 공유하고 화이트보드에 그룹화할 때까지 반복합니다.
팀에게 좋은 내용에 대해 감사를 표하고 팀원들이 말한 내용을 타이핑하여 요약할 것이라고 설명합니다. 결과물의 사진을 찍습니다.
워크샵 후속 작업
- 팀이 작성한 스티커 메모를 타이핑하여 그룹으로 보관합니다. 이 내용을 문서화하고 팀의 공유 드라이브/폴더에 저장하도록 하십시오.
- 각 그룹을 하나의 가치 설명으로 요약합니다. 이는 그룹을 설명하는 포괄적인 문장이나 해당 그룹의 가치 설명 중 하나일 수 있습니다.
- 요약한 가치 설명의 목록을 작성하여 단일 문서로 컴파일합니다. 내용을 출력하여 팀 공간에 걸어 둡니다.

성공/예상되는 성과

팀 공간에 걸어 두고 프로젝트를 진행하거나 컨설팅에 참여할 때 참조할 수 있는 일련의 합의된 팀 가치를 창출했으면 완료된 것입니다.

진행자 메모 및 팁

“핵심” 팀의 모든 구성원이 이 활동에 참여해야 합니다. “핵심” 팀은 프로젝트 및/또는 컨설팅 참여의 수명주기 동안 함께 작업을 전담하는 사람들로 구성된 조직이라고 생각하면 되며, 같은 위치에서 업무를 하는 것이 이상적입니다.

이러한 팀의 가치는 업무 방식(How We Work) 전환 활동을 진행하기로 결정한 경우 프로젝트 및/또는 컨설팅 참여의 마무리 시점에 다시 활용할 수 있습니다. 이를 통해 팀은 자신들의 가치를 조정하고 참여 도중에 수행한 조정 사례를 식별함으로써 업무가 끝난 다음에도 계속 참여할 수 있습니다.

실제 예시

Practices: 프로토 페르소나

Tue, 09 Feb 2021 00:00:00 +0000

이 방식을 활용하는 방법

추가 원격 팁은 아래 변형 섹션에 있습니다.

샘플 안건 및 메시지

회의실을 작은 그룹으로 나누고 각 그룹에게 종이를 한 장씩 나누어 줍니다.

팁: 그룹이 소규모인 경우, 개인 단위로 이 연습을 진행해도 괜찮습니다. 여러 화상 채팅 시스템이 보다 긴밀한 협력을 위해 일시적으로 대규모 그룹을 더 작은 그룹으로 분리하는 “소회의실” 또는 이와 유사한 수단을 지원합니다.
회의실의 “페르소나”를 정의하고 모든 참가자에게 이 사람은 임시 페르소나라는 것을 상기시킵니다. 연구를 통해 우리가 이 사람에 대해 알고 있다고 생각하는 바를 바꾸고 발전시킬 수 있습니다.

sd

“페르소나는 인구 통계와 관련된 것이 아니라, 개인이 마주하는 문제, 그리고 당면 과제와 관련된 것입니다.”

이미지 출처: NetBase Solutions Inc.
각 그룹 또는 개인에게 종이를 사분면으로 접으라고 지시합니다.
보드에 다음의 각 사분면으로 템플릿을 그립니다.
- 왼쪽 상단 → 한 장소에서 작업을 수행하는 사람의 그림, 이름, 얼굴, 감정, 생각이 포함됨
- 왼쪽 하단 → 인구 통계(이름, 나이, 역할, 수입, 위치, 성별과 같은 사실 정보)
- 오른쪽 상단 → 행동(하는 일, 좋아하는 것, 싫어하는 것, 취미)
- 오른쪽 하단 → 요구와 목표(원하는 것, 해결 과제, 희망하는 것)
팀(또는 개인)에게 7~8분 동안 조용히 템플릿을 따라 종이를 작성하도록 합니다.
각 팀의 대표자(또는 각 개인)에게 보드 앞으로 나와 페르소나를 걸고 그룹에 대해 자신들이 생성한 각 인물을 설명해 달라고 요청합니다.
각 사람에게 4개의 점을 나누어 주고 사용자를 가장 잘 설명한다고 생각하는 사분면에 점을 부착하도록 합니다. 모든 종이의 각 사분면에 하나씩 총 4개의 점이 놓아집니다.
가장 점수가 높은 사분면을 하나의 통합된 페르소나에 함께 붙이고 그룹에게 읽어 줍니다.

팁: 재조립을 위해 사분면을 잘라야 할 경우를 대비하여 가위를 준비해 두는 것이 좋습니다.
이 페르소나가 대표하는 사람에 대한 접근 계획과 이 페르소나를 평가하기 위해 수행할 사용자 연구 활동 계획을 수립합니다. Tanzu Practices 센터에서 Discovery(탐색)로 레이블이 지정된 활동을 확인하면 다른 옵션을 볼 수 있습니다.

성공/예상되는 성과

통합된 프로토 페르소나를 생성했으며 회의실의 모든 사람이 이 페르소나가 대상 청중을 가장 잘 나타낸다고 느낀다면 연습이 성공적인 것입니다. 중요한 다음 단계는 인터뷰를 비롯한 사용자 연구를 통해 이 페르소나를 검증하는 것이라는 사실을 기억하십시오.

변형

기계 페르소나

API와 같은 “기술” 제품을 구축하고 사용자가 시스템인 경우(통합해야 하는 기존 애플리케이션 등) 기계 페르소나를 생성해야 합니다.

주요 차이점은 사용하는 사분면입니다.

왼쪽 상단 → 기계 페르소나를 의인화한 그림
왼쪽 하단 → 정보(시스템의 이름, 나이, 유형, 시스템이 이해할 수 있는 언어/형식과 같은 사실 정보)
오른쪽 상단 → 요구 및 책임(필요한 입력, 이러한 입력으로 시스템이 수행하는 것, 시스템이 일반적으로 수행하는 것)
오른쪽 하단 → 특이 사항(시스템과 통합/상호작용할 때의 모든 어려움 또는 특이점)

원격 팀의 경우

팀이 원격 환경에 있더라도 이 워크샵을 추진할 수 있습니다.

많은 온라인 협업 솔루션이 그리기 기능을 갖추고 있지만, 디지털 기술을 덜 사용하고 종이와 카메라를 더 많이 사용하는 것이 좋습니다.

사람들에게 위에 설명한 대로 실제 종이에 그림을 그리도록 지시합니다.
다음으로, 팀에게 휴대폰으로 사진을 찍고 공동 작업 공간에 올리라고 요청합니다.

또는 사람들이 채팅 앱, e-메일 또는 텍스트 메시지를 통해 진행자에게 사진을 보낼 수도 있습니다. 사람들은 웹캡으로 자신의 그림을 찍을 수도 있습니다. 이 경우 진행자가 스크린샷을 찍고 이미지를 공동 작업 공간에 올리면 됩니다.

Labs Practices Site – Tanzu 사례

Practices: 영향 분석

이 방식을 활용하는 방법

샘플 안건 및 메시지

성공/예상되는 성과

진행자 메모 및 팁

관련 사례

실제 예시

Practices: 사용 편의성 테스트

이 방식을 활용하는 방법

가정:

샘플 안건 및 메시지

성공/예상되는 성과

진행자 메모 및 팁

권장 자료

Practices: 플러스 /델타 피드백

이 방식을 활용하는 방법

샘플 안건 및 메시지

성공/예상되는 성과

진행자 메모 및 팁

관련 사례

권장 참고 자료

Practices: 팀 업무 합의

이 방식을 활용하는 방법

샘플 안건 및 메시지

성공/예상되는 성과

진행자 메모 및 팁

관련 사례

실제 예시

Practices: 리더십 역할 및 책임

이 방식을 활용하는 방법

샘플 안건 및 메시지

성공/예상되는 성과

진행자 메모 및 팁

Practices: 스택 랭킹(강제 랭킹)

이 방식을 활용하는 방법

샘플 안건 및 메시지

변형 - 버블 정렬 기법: 10개 이하의 옵션

변형 - 분류 기법: 10개 이상의 옵션

변형 - 개별 랭킹 및 그룹 비교: 3~9개 옵션, 그룹에 불균형한 직급 역학이 있는 경우

성공/예상되는 성과

진행자 메모 및 팁

관련 사례

실제 예시

권장 자료

Practices: 서비스 Blueprint

이 방식을 활용하는 방법

샘플 안건 및 메시지

성공/예상되는 성과

진행자 메모 및 팁

관련 사례

권장 자료

Practices: 사용자 스토리 작성

이 방식을 활용하는 방법

샘플 안건 및 메시지

성공/예상되는 성과

진행자 메모 및 팁

관련 사례

이전 단계

다음 단계

실제 예시

권장 자료

Practices: 사후 분석

이 방식을 활용하는 방법

샘플 안건 및 메시지

성공/예상되는 성과

진행자 메모 및 팁

권장 자료

Practices: 반복 사전 계획

이 방식을 활용하는 방법

성공/예상되는 성과

진행자 메모 및 팁

관련 사례

변형

이전 단계

다음 단계

실제 예시

권장 자료

Practices: IPM(반복 계획 회의)

이 방식을 활용하는 방법