Atlassain playbook 번역해보기 #2

오래전에 DACI 번역하고 이제 두번째로 번역, 정리해보는 프레임워크네요. 5 Whys 프레임워크입니다.

원글: https://www.atlassian.com/ko/team-playbook/plays/5-whys

5 Whys Analysis framework

5 Whys 프레임워크는 문제의 근본 원인을 찾아냅니다.
컨플루언스 템플릿이나 다른 템플릿들은 원글에서 확인하실 수 있습니다.

플레이북 진행

1. 준비 Prep

문제 설명을 준비하세요. 팀이 현재 직면하고 있는 문제일 수도 있고 해결해야 할 과거에 발생한 문제일 수도 있습니다.
원격 팀의 경우 협업 문서(위의 선택적 템플릿 참조)를 만들고 팀과 미리 공유하세요.

대면 팀의 경우 다음 열로 화이트보드에 레이블을 지정합니다.

• 문제 설명 1
• 문제 설명 2
• 문제 설명 3
• 문제 설명 4
• 문제 설명 5
• 어떻게 해결할 수 있는지?

2. 무대 설정

회의 시작 시 팀에 다음 사항을 알리세요.

• 우리는 문제의 근원을 찾기 위해 깊이 파고들 것입니다.
• 우리는 비난하기 위해 여기 있는 것이 아니라 조사하기 위해 왔습니다.

팁: 5 Whys Analysis Play는 호기심과 실수로부터 배우는 것을 장려하는 문화에서 가장 잘 작동합니다. 이런 종류의 환경은 비난 게임으로 변하는 것을 방지합니다.

3. 브레인스토밍

초기 문제 설명의 경우 팀에 “왜 이런 일이 발생했습니까?”라고 질문하세요.
타이머를 5분으로 설정합니다. 팀이 공동 작업 문서 또는 화이트보드에 자신의 답변을 추가하도록 합니다.

팁: 다른 방법으로 물어보세요

• 문제의 원인은 무엇입니까?
• 무엇이 문제로 이어졌습니까?
• 문제가 발생한 조건은 무엇입니까?
• 문제에 기여한 것은 무엇입니까?

4. 선택

팀으로서 다음 문제 설명으로 자세히 설명할 답변 중 하나를 선택하세요.
초기 문제 설명을 이것으로 바꿉니다.

팁: 투표하기
앞으로 나아갈 문제 진술에 투표하세요.
Trello Voting Power-Up을 시도하거나 팀이 선택한 진술에 +1을 추가하도록 합니다.

5. 반복

총 5번을 “왜?”라고 물을 때까지 3단계와 4단계를 반복합니다.

팁: WHYS
팀에서 의미 있는 수준의 근본 원인에 도달했다고 동의할 때까지 “왜”를 계속 물어보세요.

6. 솔루션 제안

근본 원인의 지점에 도달하면 팀 구성원이 최종 문제 설명에 대한 솔루션을 제안하게 합니다.
진행할 솔루션을 한두 개만 선택하고 각 솔루션에 담당자를 지정하고 팀이 담당자로부터 응답을 받을 수 있는 시점을 결정합니다.

팔로업 Follow ups

• 모든 메모 캡처
  • 전체 팀이 볼 수 있는 장소에 세션의 메모를 게시합니다.
• 작업 추적
  • Jira 또는 Trello와 같은 팀의 작업 보드에 문제 설명을 작업 항목으로 추가합니다.
• 체크인
  • 합의된 시간에 제안된 솔루션의 진행 상황을 확인하고 있는지 확인하세요.

변형 Variations

브레이크아웃 / Breakout
첫 번째 브레인스토밍 단계 후, 하나의 문제 진술에 투표하는 대신 그룹이 각 문제 진술에 대해 하나씩 팀으로 나뉩니다.
그런 다음 나머지 팀 플레이를 따라 각 팀이 끝나는 근본 원인을 확인하세요.

Playbook - 5 Whys 활동 문서 번역을 마치며

이번 플레이북 5 Whys는 내용이 어렵지 않기도 하고 본문이 길지도 않아서 금방 번역을 마쳤네요.
실제 업무에서도 5 Whys 처럼 단계를 모두 따라서 문제를 정의하는 경우가 있긴하겠지만 대부분 2-3번째 쯤에 문제가 정의되는 것 같긴합니다.
정의하기 어려운 문제는 5번 이상 원인에 대해 파악해봐야겠지만요. 😇

이 프레임워크에 대해 알게된 건 박물관 이야기였던 것 같네요.

제퍼슨 기념관(Jefferson memorial) - 대리석 지붕이 빨리 부식되는 원인을 찾자

• 왜 대리석이 빨리 부식되는가?
  • 세제로 자주 씻고 있음
• 왜 세제로 자주 씻는가?
  • 비둘기 배설물이 많아 자주 씻음
• 왜 비둘기가 많은가?
  • 비둘기의 먹이인 거미가 많음
• 왜 거미가 많은가?
  • 거미의 먹이인 나방이 많음
• 왜 나방이 많은가?
  • 직원들이 일찍 퇴근하면서 해지기 전 전등을 켜서 나방이 몰려듬

-> 기념관 직원들의 업무시간을 조정하여 해가 진 후 전등을 켬

이 외에 많은 예시가 있겠지만 여러 단계에 걸쳐서 문제 원인을 찾고 해결해나가는 기법입니다.
대부분 머리속에서 정리되는 경우가 있지만 큰 문제나 다같이 문제를 풀어야하는 경우에는 이 기법을 사용해보면 좋지 않을까 싶네요.

참고하면 좋을만한 글

• Medium PM101, Learn About the Five Whys Technique(EN)
• 5 Whys 분석법, 근본 원인을 찾는 문제 해결 기법

Flutter?

EN: https://flutter.dev/
KO: https://flutter-ko.dev/

Flutter(플러터)는 구글에서 만든 개발 프레임워크로 기존에는 모바일 앱을 개발할 수 있었으나 2.0으로 업데이트되면서 데스크탑 앱(Windows, Mac, Linux), 웹 앱까지 stable로 지원하는 개발 프레임워크가 되었습니다.

홈페이지에는 플러터를 아래와 같이 설명하고 있네요.

Flutter(플러터)는 하나의 코드베이스로 모바일, 웹, 데스크톱에서 네이티브로 컴파일 되는 구글의 아름다운 UI 툴킷입니다.

플러터는 Dart라는 언어를 사용하여 앱을 개발할 수 있으며 이 언어도 구글에서 만들었습니다.
앱을 개발할 때는 Android Studio, IntelliJ, VS Code, Emacs에 플러그인을 설치하고 가능하다고 합니다.
(iOS, Android, 데스크탑 앱 모두를 개발하고자 한다면 VS Code로 하는게 좋겠네요 😈)

2.0 업데이트 소식

https://medium.com/flutter/whats-new-in-flutter-2-0-fe8e95ecc65

이번에 업데이트된 내용을 살짝 요약해보면

1. Mobile Framework -> Portable Framework
   • 데스크탑 앱(Mac OS, Windows, Linux), Web(beta to stable) 지원!
2. Dart Null Safety
   • 자세한 내용은 Dart 2.12 업데이트를 참조하세요 :)
3. Flutter Fix를 통해 2.0 업데이트 이후 deprecated된 것 수정 가능
4. DevTool 업데이트
   • 평균 FPS, 메모리 뷰 차트, 디버거 업데이트 등
   • 자세한 내용은 DevTools 2.0

짧은 정찰 마무리

Flutter를 이용한 앱 개발은 해보지 않아서 이번에 업데이트 소식을 들은 김에 튜토리얼해보면서 앱을 한번 빌드해보는 것도 재미있을 것 같네요.
(Dart 언어도 한번 찍어먹어볼겸..)

앱 개발 강의에서도 요즘 심심치 않게 등장하고 있는 프레임워크인데 조만간 튜토리얼 돌려보고 내용 정리해봐야겠습니다. 😈

Atlassain 플레이북(playbook)?

https://www.atlassian.com/team-playbook
아틀라시안에서 일에서의 조율, 팀 활동 등 업무에서 사용할 수 있는 프레임워크의 활동 양식을 모아둔 말그대로 활동서같은 곳입니다.

어떤 활동이 있을까?

https://www.atlassian.com/team-playbook/plays

활동 중에 사람들이 가장 많이 본 활동은 홈페이지에도 있지만 다음과 같네요.

이 외에도 전체 활동 수는 46개가 있네요.
애자일 팀 되는 방법, 리모트 팀워크 올리기, 강한 관계 생성 등 여러 카테고리에 맞춰 활동들이 있으니 하나하나 보면서 참고해보면 좋을 것 같습니다.

플레이북 아쉬운 점

브런치나 미디엄에서 아름아름 찾아보는 인사이트들을 아틀라시안에서 정리해주어서 좋지만.. 한글 언어 선택해도 이 플레이북은 번역이 되지 않아서 약간 아쉽긴합니다. 😂
많은 분들이 보고 일에 적용해보고 Confluence, Jira를 사용할 수 있을 것 같은데 아무래도 한국어 지원이 안되면 접근성이 떨어지는 것은 사실이어서요.

번역을 더 멋지게 해주시는 분이 있겠지만 저라도 블로그에 번역한 내용을 올려보고 공부하면서 업무에 활용해보려 합니다. 😀
그러면서 업무에 적용했던 실제 사례도 올려보면 재미있을 것 같기도 하네요.

국문 번역이 하루 빨리 필요한지는 모르겠지만.. 아틀라시안에서도 조금이나마 신경써서 국문으로 번역된 컨텐츠를 제공해주었으면 하는 바람이 있습니다.
이만 짧은 소개를 마치겠습니다. 포스트를 읽어주신 분들도 한번 플레이북 활동을 사용해보시고 업무에 도움이 되면 좋겠습니다.

Atlassain playbook 번역해보기 #1

올해 초 부터 해보고 싶었던 Playbook 번역이었는데 조금씩 하다가 이제 정말 해보자하고 진행하고 있네요.
이번 글에서는 Atlassian Playbook에 있는 DACI 프레임워크를 소개해보고자 합니다.
되도록 글의 번역에 초점을 맞춰보고 추가할 내용은 조금씩 수정, 보완해볼 예정입니다.

원글: https://www.atlassian.com/team-playbook/plays/daci
30초 설명: https://youtu.be/68iWkZQ2Zdg

DACI (Driver, Approver, Contributors, Informed) framework

DACI 프레임워크는 그룹 결정을 효율적이고 효과적으로 내릴 수 있도록 도와줍니다.

이 플레이북 활동을 사용하면?

이 DACI 프레임워크 활동을 사용하여, 영향력이 높거나 위험이 높은 그룹 결정을 내리기 위한 역할을 정의합니다.

의사 결정, 균형 잡힌 팀 또는 건강 모니터(Health Monitor)에 대한 공유 이해에 어려움을 겪고 있는 경우 이 플레이를 실행하는 것이 도움이 될 수 있습니다.

• 의사 결정: 단기적 및 장기적 영향 모두를 고려할 때 적절한 수준의 긴급성과 논의를 통해 적절한 수준에서 의사결정이 이루어지며, 이에 대한 절충이 적극적으로 고려됩니다. 의사결정은 시기적절하고 효과적으로 전달됩니다.
• 균형 잡힌 팀: 역할과 책임은 명확하고 합의된 것입니다. 이 프로젝트에는 적절한 기술 조합의 사람들이 있습니다. 팀 구성원은 단계(stage)별로 변경할 수 있습니다.
• 공유된 이해: 비즈니스와 사용자의 관점에서 성공이 무엇을 의미하는지 분명하고, 타겟 사용자와 비즈니스에 대한 고유한 가치 제안이 있습니다. 성공은 목표와 함께 정의되며, 성공이 어떻게 측정될 것인지에 따라 결정됩니다.

DACI가 왜 필요한가요? (상황 예시)

당신이 좋아하는 샌드위치 가게의 카운터에 서서 루벤(Reuben)을 먹을 것 인지 칠면조를 먹을 것 인지에 대한 질문으로 고통받는 자신을 발견했다면, 이 보편적인 진실을 알고있을 것입니다. 결정은 어렵습니다.

직장에서의 결정은 훨씬 더 어렵습니다. 그런 다음 팀원, 이해 관계자, 고객 및 상사의 의견을 방정식에 추가합니다… 으으 😰

프로젝트에 대한 의사결정에 긴급하게 접근하지 않으면 아무도 결정을 내리지 못하기 때문에 지연됩니다.
그리고 우리가 누구의 결정이냐에 동의하지 않으면, 우리는 결국 결정을 반복해서 재검토하게 되고, 이것은 우리의 발전을 더욱 지연시킵니다.

각 의사 결정에서 누가 어떤 역할을 하는지 명확히 함으로써, 올바른 결정을 내리고 적절한 시기에 결정을 내릴 수 있는 더 나은 기회를 얻을 수 있습니다.
(항상 루벤을 선택하는 것이 옳은 것 처럼요.)

이건 작성자 개인의 취향인듯 합니다. 😂
루벤 샌드위치를 비유할만한 한국 음식은 떠오르지 않는군요. 😄

누가 참여해야하나요?

결정 및 진행을 위해 그룹 전체 인원이 참여합니다.

플레이북 활동 진행

DACI는 그룹 의사결정에 구조를 가져오는 것에 관한 것입니다.
그러니 먼저 이 활동을 자세히 복습하여 그 구조를 확실히 이해하시길 바랍니다.

준비물

• 컴퓨터(노트북)
• Confluence 용 DACI 프레임워크 템플릿
• DACI 프레임워크 템플릿 PDF (EN)

활동 시작 전에 먼저

“DACI”는 무엇을 의미하나요?

DACI는 비록 그들이 동의하지 않더라도, 그룹의 모든 사람들이 일단 결정이 내려지면 결정 뒤에 집회를 열 때만 작동합니다.
우려와 신뢰를 기꺼이 공유하지 않으면, 여러분의 팀은 끝없는 토론과 무반응의 늪에 빠질 것입니다.
팀원들은 심지어 공식적인 결정이 실패하기를 바라면서 몰래 선호하는 선택지를 추구할 수도 있습니다.
여러분이 헛소리 정치는 건너뛸 수 있도록 모든 사람들이 결정된 모든 일에 완전히 전념할 준비가 되어 있는지 확인하세요.

DACI가 필요한가요?

그것은 우리가 자주 하는 질문입니다.

그룹 의사결정에 전체 DACI 치료가 필요한지 여부를 고려할 때 적절한 시기와 영향을 고려해야 합니다.
프로젝트에서 여러 사람의 작업에 영향을 미치는 의사 결정(예: “내년에는 어디에서 사용자 회의를 개최해야 합니까?”)에는 DACI가 필요할 수 있습니다.
소규모의 고립된 결정(예: “회의의 소셜 미디어 해시태그는 어떻게 될 것인가?”)은 그렇지 않습니다.

Step 1, 결정을 추적할 페이지를 만듭니다. (5분)

대부분의 프로젝트는 검토 중인 사항, 관련 연구, 트레이드오프, 권장 사항 등을 문서화함으로써 이득을 얻습니다.
이를 통해 핵심 팀은 보다 쉽게 옵션에 대한 피드백을 제공하고 이해 관계자가 최종 결정을 이해할 수 있도록 지원합니다.

컨플루언스(또는 문서화 도구 선택)에서 새 페이지를 열고 맨 위에 2x4 그리드를 삽입하거나 DACI Blueprint for Confluence를 사용하여 페이지를 만듭니다.
왼쪽 열의 행에 드라이버, 승인자, 기여자, 알림으로 레이블을 지정합니다. 결정을 진행하는 동안 며칠/주 내에 이 페이지에 더 많은 정보를 추가할 수 있습니다.

컨플루언스 사용자가 아닌가요? 걱정하지 마세요.
대신 DACI 템플릿 PDF을 다운로드하여 사용할 수 있습니다.

Step 2, 그룹 결정을 위한 역할을 정의합니다. (10분)

운전자(Driver)는 누구입니까?

각 결정마다 한 사람씩 있는 것이 좋습니다. 이 사람들은 반드시 전체 프로젝트를 주도하지는 않습니다. 그 결정에만 있으면 됩니다.

승인자(Approver)는 누구입니까?

다시 한 번 말하지만, 한 결정당 한 명만 있어야합니다.

기여자(Contributors)는 누구입니까?

이 사람들은 결정당 여러 사람이 될 수 있으며, 심지어 핵심 팀 외부의 사람을 포함할 수도 있습니다. 관련 지식이나 경험이 있는 사람은 누구나 공정한 게임입니다.

정보 수신자(Informed)는 누구입니까?

이 사람들은 그 결정의 직접적인 영향을 받는 모든 사람들입니다. 여기에는 핵심 팀 외부의 사람들이 포함될 수 있습니다.

“운전자가 부재중이라면 누구에게 위임하겠습니까?”, “상담을 받아야 할 사람이 너무 많습니까?”와 같은 질문을 던집니다. 이에 따라 DACI를 조정합니다.

Step 3, 공격 계획을 세우세요. (15 min)

결정을 내리기 위해 수집해야 할 모든 정보를 생각해 보세요.
Confluence에 DACI Blueprint를 사용하지 않는 경우 페이지에서 다음 섹션을 표시합니다.
지금 바로 작성하실 필요는 없지만, 각 메모에 내용을 추가하셔도 됩니다.

Step 4, 팀을 참여시키기

피드백과 입력을 요청하는 페이지를 팀으로 보냅니다.
페이지의 특정 섹션을 작성하는 데 도움이 되는 특정 사용자가 필요한 경우, 지금이 바로 알려야 할 때입니다.

만약 어떤 시점에서 상황이 정체되거나 빙빙 돌고 있다고 느낀다면, 운전자와 기여자들을 방에 함께 모으세요. 결정에 가까워질 경우, 승인자를 포함시키는 것도 도움이 될 수 있습니다. 사람들이 자신의 우려 사항, 추천 사항, 고려해야 할 다른 옵션에 대한 아이디어 등을 표현할 수 있도록 합니다. 한 시간 동안 직접 해싱하면(합의에 도달하기 위해 다른 사람들과 이야기를 나누면) 며칠간의 의견(또는 - 공포! - 이메일) 스레드를 절약할 수 있으며, 결정을 다시 정상으로 되돌릴 수 있습니다.

…그럼 심호흡을 하세요! DACI 활동은 특히 결정이 논쟁적이거나 정치적 책임을 지는 경우 스트레스가 될 수 있습니다. 여러분은 함께 일할 수 있는 명확한 그룹 의사 결정 프레임워크를 구축하는 것에 시간을 할애하여 팀원들에게 훌륭한 서비스를 제공했습니다.

다른 사례 - 서비스 팀

데스크톱 지원 또는 채용과 같은 서비스를 제공하는 맥락에서, 일련의 DACI는 일선 서비스 팀 구성원들이 독립적으로 어떤 통화를 할 수 있는지, 팀원이나 관리자가 언제 참여해야 하는지 이해할 수 있도록 도와줍니다. 위에서 설명한 전체 결정 페이지가 매트릭스의 각 결정에 필요하지 않습니다. 각 시나리오에 대한 간단한 설명과 D, A, C 및 I로 충분합니다.

서비스 별로(프로젝트 별로) DACI 매트릭스를 만듭니다. 이러한 독립적 의사 결정이 이루어진 후 정보를 전달하기 위한 일련의 에스컬레이션 경로 및 절차로 제공될 수 있다고 생각하시면 됩니다.

서비스 팀의 DACI 매트릭스는 비교적 정적인 편이지만, 돌에 새겨진 것은 아닙니다. 확립되어있고 안정적인 서비스에 대해 DACI를 매년 검토하고 수정하세요. 신규 서비스 팀의 경우 DACI를 분기별 또는 1년 동안 2회 검토하기를 권장합니다.

다음 조치(Follow-ups) - 의사결정 기록

선택 사항입니다. 여러 그룹 또는 부서에 영향을 미치는 대규모 이니셔티브(리더십 팀, 리더십 팀)는 종종 의사결정 기록 페이지에서 이점을 얻습니다. 의사결정 기록 페이지는 팀 구성원과 이해관계자가 각 결정에 대한 세부 정보에 쉽게 액세스할 수 있는 포털 역할을 합니다.

의사결정 기록에 프로젝트에 대한 간략한 요약(예: 엘리베이터 피치(EN))을 포함합니다. 그 아래, 각 결정을 자세히 설명하는 페이지로 연결합니다. 또한 각 결정의 상태, 영향 수준, 운전자, 승인자 및 만료 날짜를 기록합니다. 또한 중요한 용어를 정의하는 범례도 포함할 수 있습니다. 예를 들어, 의사결정에 “높은 영향”이라는 레이블이 지정된 경우 정확히 무엇을 의미하는지 알 수 있습니다.

연관된 활동

• 프로젝트 킥오프(Kick-off)
• 역할과 책임
• 트레이드 오프 슬라이더

Playbook - DACI 활동 문서 번역을 마치며

맨 처음에 DACI라는 내용을 들었을 때, 무슨 프로세스지? 방법론인가? 하고 막연히 생각했습니다.
(프레임워크라고 해서 SWOT(강점, 약점, 기회, 위협) 같은 것으로 생각했었죠.)
다른 PM 분들이 소개해주시는 내용이나 요즘 PM과 관련한 글들을 많이 보면서 어렴풋이 알게되었고 Atlassian에 관련 자료가 있어서 마침 공부하는 겸 번역하게되었습니다.

제가 일하고 있는 곳에서 일어나는 일을 DACI에 대입해보면.. 프로젝트(작은 피쳐 또는 스펙)를 진행할 때에 PM이 보통 운전자(드라이버)로 진행을 하고
PD, 리더분들이 승인자 역할 그리고 사업 부서와 운영 부서는 기여자와 정보 수신자가 될 수 있겠네요.

사실 번역하면서 어느정도 이해는 했고 실제 업무에 알맞게 써먹을 수 있을지가 관건이겠죠.
나중에 이런 프레임워크가 있으니 한번 써볼까하는 생각은 들 수 있겠습니다. (언젠가 🙈)
이 글을 읽으신 분들에게 조금이나마 도움이 되었기를 바라며 마칩니다. 고맙습니다.

참고하면 좋을만한 글

• 브런치: DACI 팀 결정을 효율적으로 하는 방법
  • ProductPlan: DACI Decision-Making Framework(원문)
• Medium PM101, DACI Framework: a Tool For Group Decisions(EN)