Jira의 DACI: 모든 결정의 책임자를 명확하게 정하세요

Jira 이슈에 긴 논의가 쌓여도 결정에는 가까워지지 않을 수 있습니다. 개발팀과 지원팀은 서로 다른 방안을 추천하고 제품 책임자는 누군가 대안을 정리하기를 기다립니다. 모두 참여하지만 누가 결론을 내려야 하는지는 모릅니다.

DACI는 대화에 구조를 제공합니다. 누가 추진하고 결정하는지, 누구의 전문성이 필요하고 누가 결과를 알아야 하는지 정합니다. 이 안내에서는 가상 포털 팀이 알림 전달 방식을 결정하고 Power Pack에 역할을 기록합니다.

네 가지 DACI 역할을 이해하세요

DACI는 Driver, Approver, Contributors, Informed를 뜻합니다. Atlassian의 DACI 안내에서 Driver는 결정 과정을 조직하고 Approver는 유일하게 최종 선택을 하는 사람입니다. Contributors는 전문성을 제공하고 공유 대상은 결과를 받습니다. 출처는 아래에 있습니다.

추진자와 결정자를 구분하세요. 조율한다고 자동으로 최종 결정권을 얻지 않습니다. 반대로 결정자가 모든 증거를 직접 수집해야 하는 것도 아닙니다.

결정이 필요한 질문을 선택하세요

가상의 포털은 고객이 지원 요청의 진행을 확인하게 합니다. 팀은 다음 버전의 일반 상태 알림 방식을 정해야 합니다. 즉시 이메일, 일일 요약, 포털 내 받은편지함을 고려합니다.

제품 책임자 Maya는 방해되는 이메일을 줄이고 싶고, 개발자 Leo는 두 번째 알림 시스템 추가를 걱정합니다. 지원 책임자 Sam은 고객이 진행 소식을 놓칠까 우려하고, Priya는 출시 검증을 설계하기 전에 방식이 정해져야 합니다.

관련 이슈에 '포털 첫 버전에서 일반 지원 요청 업데이트를 어떻게 전달할까?'라고 적으세요. 일반 상태 변경으로 범위를 제한하고, 비밀번호 재설정이나 긴급 보안 알림, 모든 미래 채널까지 결정하지 않습니다.

팀의 평소 절차로 목표 결정일을 설명에 넣으세요. 예시에서는 다음 계획 회의 전 답이 필요합니다. 날짜는 조율 약속이며 매트릭스가 알림을 보내거나 기한을 강제한다는 의미가 아닙니다.

실제 불확실성에 맞춰 역할을 배정하세요

Leo는 구현 대안을 모으고 기술 증거의 빈틈을 찾을 수 있어 추진자가 됩니다. Maya는 출시 절충이 합의된 제품 권한에 속하므로 결정자입니다. Sam은 고객 지원 맥락, Priya는 검증 가능성과 실패 시나리오를 제공합니다. 고객 소통을 준비하는 Elena에게는 결과가 필요합니다.

입력 전에 각자가 역할을 수행할 수 있는지 확인하세요. Leo에게는 비교할 시간, Maya에게는 계획 전 가용성이 필요합니다. Sam과 Priya에게는 무기한 의견 요청보다 구체적인 질문이 필요합니다.

두 사람이 최종 권한을 가진다고 생각한다면 매트릭스 완료 전에 경계를 정하세요. 제품 선택과 별도 예산 결정이 섞여 있을 수 있습니다. 실제로 다른 결정자가 필요하면 나누세요. 대화를 피하려 A를 추가해도 불확실성은 남습니다.

기여자가 답할 수 있는 질문을 주세요

Leo는 Sam에게 고객이 업데이트를 오해한 최근 사례 세 개를 요청하고, Priya에게 짧은 시간에 여러 변경이 일어날 때의 문제를 묻습니다. 자신은 기존 시스템에 근거한 짧은 기술 비교를 준비합니다.

이는 설명을 위한 가상 자료이지 측정된 제품 성과가 아닙니다. 유용한 기여가 어떤 모습인지 보여주며, 각 사람의 전문성과 결정을 연결합니다.

팀은 세 질문으로 평가합니다. 고객이 유용한 진행을 알아차릴 수 있는가, 현재 역량으로 운영할 수 있는가, 출시를 설득력 있게 검증할 수 있는가? 같은 문제를 평가하도록 Jira의 대안 옆에 적습니다.

모든 고려사항을 정밀한 점수로 줄일 수 있는 척하지 마세요. 표는 대화를 정리하지만 수학적으로 올바른 답을 만들지는 않습니다. 추정의 불확실성을 밝히고 추가 조사가 선택을 바꿀지 판단하세요.

선택을 요청하기 전에 대안을 비교하세요

다음 비교는 이메일 발송이 이미 있고 포털 받은편지함은 새로 만들어야 하는 예시 시스템에 관한 것입니다.

Sam의 사례는 중요한 변화의 빠른 안내가 가치 있음을 보여줍니다. Priya는 동작을 정의하지 않으면 반복 편집이 혼란스러운 중복 메시지를 만들 수 있다고 말합니다. Leo는 이 시스템에서 요약에 일정 처리와 그룹화 작업이 추가된다고 설명합니다.

이제 Maya는 구체적인 절충을 판단합니다. 첫 버전은 의미 있는 상태 변경에 즉시 이메일을 보내고 중복 처리를 구현 티켓에 명시합니다. 사소한 내부 편집은 고객에게 알리지 않습니다. 유용한 알림도 너무 잦다는 피드백이 나오면 요약을 재검토합니다.

이 결과는 '이메일 사용'보다 의도적으로 구체적입니다. 개발, 테스트, 지원에 선택의 의미를 알려주고 재검토할 조건도 남깁니다.

Power Pack에서 DACI 매트릭스를 만드세요

이슈에서 RACI / DACI Matrix를 열고 Model을 DACI로 설정하세요. 사용할 역할은 D, A, C, I가 됩니다.

참여자 목록에 결정 관련 인원을 추가하세요. Jira 사용자 검색과 외부 참여자 항목을 지원합니다. 외부 항목은 사람을 나타낼 뿐 계정이나 접근 권한을 만들지 않습니다.

산출물 보기에서 결정 질문을 행으로 추가하세요. 인터페이스가 산출물을 행으로 쓰더라도 명확히 이름 붙인 결정은 이 DACI 사례에 적합합니다. 해석하기 쉽도록 무관한 구현 작업은 첫 행에 넣지 마세요.

Leo에게 D, Maya에게 A, Sam과 Priya에게 C, Elena에게 I를 배정하세요. 클릭하면 역할이 바뀌고 포커스가 있는 셀에서는 표시된 문자 단축키도 작동합니다.

행 표시를 확인하세요. Power Pack은 결정자 누락, 복수 결정자, 추진자 부재를 찾습니다. 역할 구조의 빈틈은 찾지만 Maya의 실제 권한이나 Leo의 증거 충분성은 판단하지 않습니다.

나가기 전에 저장 상태를 확인하세요. 로컬 또는 오프라인이라면 최신 배정이 이미 공유되었다고 가정하지 마세요. 사람들이 함께 찾아보고 논의할 수 있는 버전이 유용한 합의입니다.

사용할 수 있는 결과로 논의를 마무리하세요

역할 매트릭스가 전체 결정을 담지는 않습니다. 선택, 이유, 중요한 결과를 이슈 설명이나 Decision Log에 남기세요. 진지하게 고려한 대안도 적어 나중에 이해할 수 있게 합니다.

Leo는 평소 소통 방식으로 Elena에게 출시 내용, 포함되는 메시지, 제외 범위, 구현 위치를 짧게 공유합니다. 매트릭스의 I는 이 메시지를 보내지 않습니다.

정상 워크플로로 필요한 구현 티켓을 만들거나 갱신하세요. 예시에서는 중요한 변경 감지, 중복 처리, 검증입니다. DACI 역할은 Jira 담당자나 이슈 상태를 자동 변경하지 않습니다.

과정의 규모를 적절히 유지하세요

참여나 권한이 불명확해 실제 선택이 막혔을 때 DACI를 쓰세요. 개발자가 이미 결정할 수 있는 평범한 세부사항은 짧은 기록이면 충분할 수 있습니다. 작은 선택마다 전체 매트릭스를 만들면 유지가 어려워집니다.

질문이 바뀌면 배정도 재검토하세요. 나중에 유료 알림 공급자를 고려한다면 다른 사람이 지출을 승인해야 할 수 있습니다. 원래 제품 결정이 그 권한까지 조용히 확장되지는 않습니다.

현재 Jira 작업의 미결 질문 하나를 고르세요. 경계를 정하고 추진자와 한 명의 결정자, 필요한 구체적 의견을 합의하세요. Power Pack으로 역할을 이슈 옆에 보이게 두고 결정 후 기록과 공유를 마치세요.

• Atlassian Team Playbook: DACI 의사결정 프레임워크