일상다반으로 일어나는 도메인 이슈가 스노우볼(머드볼)이 되지 않게 하기위해 어떠한것을 해야할까요?
작은 도메인 문제를 발견했다고 미팅을 즉시 소집을 해야할까요? 당장 계획된 업무를 하기도 바쁠수 있습니다. 우리의 일을 중단시키고 지금당장 우선순위를 바꿀수 있는 권한을 가진 역할자는 누구일까요?
여기서 이야기하려 하는것은 우선순위를 바꿀만큼 긴급도가 높지 않은 작지만 중요할수도 있는 문제에 대해 어떻게 효율적으로 처리할까란? 고민에서 시작합니다.
장애처리/계획된 개발TASK/운영처리 이슈가 아님을 의미하며 이것을 다룰수 있는 방법은 지라와 같은 협업 시스템및 협업방법이 이미 존재합니다.
팀에서 일상다반으로 발생하는 작은 도메인문제를 모양으로 만들기 ‘ShapeUP’ 이라고 부르기로 했으며 다음과같은 상태전이 단계를 먼저 정의 하였습니다.
그리고 우리만의 방식으로 문제를 해결해나가는 지속활동을 통해 우리 팀의 모양도 만들어진다는 믿음을 가지고 시작하는 활동입니다.
Discovery : 우리는 어떻게 해결해야할지 모르지만 문제를 발견했습니다.
- 구성원에게 발견한 문제를 공유합니다.
- 팀은 문제를 함께 인지합니다.
SetBoundaries :
- 해결방법이 나오지 않았지만 해결의 공간을 찾습니다.
원시 아이디어의 가치와 문제를 정의합니다.
해결에대한 아이디어가 나오면 Eureka로 이동되어 팀의 공유된 메타인지로 존재하게 됩니다.
Eureka :
고약한 문제는 문제가 완전히 풀려야 비로소 그 문제가 무엇인지 완전히 이해되는해결책이 문제의 공간 안에 있는 문제를 일컫는다. 반면 그 반대편에는 합당한 문제가 있다.합당한 문제는 정의할 수 있고, 이들에 대한 데이터를 수집해서 분석할 수 있으며,해결책을 낼 수 있는 문제입니다.
문제를 발견하고 합당한 해결책에 대한 아이디어가 있는 상태 그 자체만으로 우리에게 중요한 상태입니다.
이것은 지금 당장 일을 해야할것같은 백로그의 'Ready To Play'와 다른개념입니다.
수행방법
팀 리더가 일을 생성하는 방식이 아닙니다. 주로 구성원이 조기에 발견한 문제를 셀프로 등록을 합니다.
이 보드는 언제든 공유되고 열람을 할수 있으며 당장 시급하게해야할 일은 아니지만 지금시간을 방해 받지 않고 언제든 알수 있습니다.
긴급하게 처리할 필요없지만 숙제처럼 눈덩이가 되어선 안되기때문에 데일리미팅 때 이 보드를 중심으로 이야기합니다.
TASK가 완료되었나 안되었나? 프로젝트 리스크를 지속관리하는 활동은 분리되어 있기때문에 데일리때 이것을 다루지 않습니다.
팀에 발생하는 모든 문제를 리더가 항상 결정하고 해결해할까요? 구성원이 해결할수 있도록 리더는 환경을 만드는데 집중하며 리더 역시 그 해결 과정에 동참할수 있습니다.
지속 업데이트중….
작성방법
등록 - 메모 :
문제정의를 TODO를 통해 자유롭게합니다. 사소할수도 있지만 어떠한 문제가 있다란 사실을 모르는것 자체를 발견하는것에 중요한 가치를 부여합니다. - Discovery
주로 개발전략이슈 이지만~ 개발이슈가 아닌 도메인(기획)에서 발생하는 작은 이슈 등록도 가능하며 이것역시 중요한 가치로 생각합니다. -기획아이디어
공유 : 팀에 공유되어, 해당문제를 팀에 공유되고 함께 인지하는것에 중요한 가치를 부여합니다. - SetBoundaries
검사목록 : 내용이 어느정도 정리되고 해결책을 러프하게 제시합니다. 당장해결되는것도 중요하지만 해결책이 목록에 한가지라도 있는것을 가치있게 생각합니다. - Eureka
때로는 다른 해결책이 여러개 존재할수 있습니다. 다양한 해결책에 대한 아이디어를 존중하며 표현해주세요
팀활동의 변화
우리는 이것을 수행함으로 다음과 같은 팀의 변화가 생겼습니다.
- JIRA TASK를 아침마다 매일 보는것에서 해방되었습니다.
- TASK를 완료로 옮기기만 하는 활동은 일의 해결과정과 가치를 알수 없습니다.
- 스케줄점검은 1주일에 한번이면 충분하며 발견하지 못한 문제해결방법과 가치를 찾는것을 분리하였습니다.
- 문제를 발견했다고 오늘당장 미팅을 소집하지 않습니다.
- 지금당장 해야할 긴급한 일은 긴급도 높은 장애를 포함해 없습니다.
- 우리에게 중요한것은 오늘 계획된 일을 방해하지 않게 그냥 두는것입니다.
- 문제발견은 팀리더의 작업지시와 같은것이 아닌 구성원이 발견한 문제와 같은것입니다.
- 백로그는 우리가 하지못하는일로 가득채워져 항상 뒤처진 느낌을 받게됩니다.
- 백로그는 항상 우리가 알수없는 문제로 시작하여 작업을 추정하여 계획합니다. 이것은 항상 작업을 지연을 시키게됩니다.
- 고약한 문제로부터 해결의 초기 작은 아이디어를 미리 수집을 하기때문에 이것을 하기로 결정했다고 하면 측정가능한 TASK로 등록이 됩니다.
- 우리는 기획서가 완성되어 문서가 완벽해야하는것을 기대하지 않습니다. 장막을 조금씩 걷어 내는것은 거대한 미팅이 아니라 문제를 빠르게 발견하고 공유하고 해결의 공간을 조금씩 찾아가는것으로도 충분합니다.
- 우리가 발견한 아이디어가 진행되면 좋은 것이고 아니여도 상관없습니다. 중요하다고 협의되어 이것이 진행되 었을때 해결의 공간과 아이디어가 어느정도 있는 상태이기때문에 팀의 모양뿐만 아니라 우리의 프로덕트의 모양도 이쁘게 만들어 갈수 있습니다.
Eureka로 에서 이것이 중요한 일이라고 결정되었으면, 초기아이디어는 해결의 과정을 포함 조금더 상세한 스펙으로 기술될수 있습니다.
진행-완료-배포 같은것이 아닌 해결방법의 축적과함께 제대로하는 것입니다.
Add Comment