<p>지라(Jira)와 같은 이슈 관리 도구를 사용할 때 하나의 이슈에 담당자(asignee)를 이사람 저사람 바꿔가면서 일을 진행시키는 경우를 많이 봤다. 예를 들어서 QA가 개발자에게 이슈를 할당하고 개발자가 이슈를 처리하면 확인해 보라고 다시 QA를 이슈의 담당자로 변경하는 경우가 이런 경우다. 기획자가 디자이너를 할당하고 디자이너는 마크업 개발자를 할당하고 마크업개발자는 어플리케이션 개발자를 할당하는 전형적인 폭포수 모델로 일이 전달되는 모습도 간혹 볼 수 있다.</p> <p>이렇게 담당자를 바꿔가면서 사용하면 누가 그 이슈를 해결했는지에 대한 정보가 없어지게 된다.</p> <p>관리 잘 된 이슈 목록을 보면 현재 프로젝트 상황은 어떠하며 비슷한 문제를 과거에 어떻게 해결했고 누구에게 문의해 보면 되고 누가 어느 분야의 전문가인지 등 굉장히 유용한 정보들을 확인할 수 있다. 프로젝트 멤버가 바뀔때 A4 한장짜리 인수인계 문서보다 훨씬 양질의 정보를 후임자에게 전달 할 수 있다. 처음 프로젝트에 투입된 사람은 커밋 로그와 최근 처리된 이슈 목록을 보고 보다 빨리 적응할 수 있다. 누가 갑자가 아파도 그사람의 최근 작업 내역을 알 수 있기 때문에 위기 대응도 된다.</p> <p>QA가 개발자에게 할당한 이슈를 개발자가 처리했다면 개발자는 그냥 이슈 상태만 처리됨(resolved fixed)으로 바꾸고 처리 내역을 댓글로 남기면 된다. QA는 자신이 보고한 이슈중에 처리됨 상태이지만 종료(close)되지 않은 이슈를 검색해서 확인하고 처리가 잘 됐으면 종료하고 잘 안됐으면 다시 열면(repoen)된다. 담당자 항목을 변경할 필요는 전혀 없다.</p> <p>기획자, 디자이너, 마크업 개발자, 어플리케이션 개발자가 모두 관여된 이슈는 너무 범위가 큰 이슈다. 이슈를 쪼개서 각 담당자 별로 나누고 이슈들간의 의존성(depend on)을 걸면 현재 업무 단계를 보다 쉽게 파악하고 부족한 부분을 지원할 수 있게 된다. 지라의 하위 작업(sub task)을 사용해서 관리할 수도 있다.</p> <p>왜 비싼 돈들여서 이슈 관리 도구를 사용하는지 한번 생각해볼 문제다. 호칭 바꾼다고 수평 문화가 도입되지 않는다. 커뮤니케이션 수단과 방법을 바꿔야 수평 문화가 안착된다. 이슈관리 도구만 잘 써도 발언자의 지위가 아니라 업무의 경중에 따라서 보다 수평한 의사 소통이 가능해 진다. 그리고 이것이 문화가 되는 거다.</p> <p>이슈 관리 도구, 제대로 알고 잘 쓰면 그 자체가 회사의 지식 자산이고 정말 잘되면 문화도 바꿀 수 있다.</p>