지라의 타임라인과 보드를 통해 태스크를 관리하고 추적하는 것도 매우 중요하지만 ‘흐름(Workflow)’을 어떻게 설계하는지도 중요합니다.
외주의 경우, 프로젝트마다 흐름이 다를 수 있기에 케이스에 맞게 적합한 흐름으로 설계할 필요가 있습니다.
워크플로우 개념을 쉽게 이해할 수 있도록 예시를 가져왔습니다.
예시 워크플로우
To Do (할 일) → In Progress (진행 중) → Done (완료)
To Do
해야 할 일로 등록된 상태. 백로그에 할 일들을 쌓아두었다고 말하기도 합니다.
In Progress
담당자가 할당된 작업을 진행 중인 상태. 이때, PM은 어떤 티켓이 진행 중에 얼마나 머물렀는지를 트래킹해야 합니다.
Done
최종 완료된 상태로, 작업을 완료했거나 배포를 완료한 상태. 이때, PM은 작업이 잘 완료되었는지 검토를 해야 합니다.
PM은 매일 각 티켓이 어떤 단계에 머물러 있는지 확인하며 일정 지연 요소가 없는지 체크하고 관리해야 합니다. 워크플로우는 프로젝트와 상황에 맞게 설계할 수 있다는 점을 기억해 주세요.
Confluence는 정보의 허브 역할을 하며, 프로젝트를 기록하고 공유하는 곳입니다.
Confluence 활용 예시:
API 정의 및 백엔드 구조 설명
기능 정의의 배경과 논의 내용
데일리 스크럼 기록
클라이언트 미팅 회의록 및 결과 요약
QA 전략, 테스트 케이스 정리
운영 매뉴얼 및 전달 문서
PM은 단순히 문서를 정리하는 것에 그치지 않고, 기록된 내용을 팀원들에게 공유하고 빠진 내용은 없는지, 더 채워야 할 부분은 무엇인지를 함께 점검하고 보완해가야 합니다.
현재 제가 실무에 적용하고 있는 방식이 정답이라고 보기는 어렵습니다. 저 또한 프로젝트의 성격이나 팀의 구성에 따라 도구를 활용하는 방식이 각기 다르기 때문인데요.
프로젝트마다, 팀마다 상황이 다를 수 있기에 중요한 것은 도구 자체보다, 그 도구가 만들어진 개념을 이해하고 우리 팀과 프로젝트에 맞게 유연하게 활용하는 자세라고 생각합니다.
어떤 툴이든 그 자체를 목적으로 두기보다는 프로젝트를 더 나은 방향으로 이끄는 수단임을 기억하고 전체를 바라보는 시야를 가지려는 노력이 필요합니다.