우선순위가 낮은 작업은 언제 처리해야 할까?

프로덕트를 만들다 보면 수많은 아이디어가 떠오른다. '폰트 디자인을 바꾸고 싶다' '탐색 기능을 더 간편하게 만들어야겠다' 같은 생각이 머릿속을 끊임없이 맴돈다. 거기에 개발자들과 유저들에게서도 수많은 피드백을 받는다. 그리고 그 내용들이 개발 태스크 목록에 차곡차곡 쌓인다.

문제는 프로덕트 개발 속도가 태스크 쌓이는 속도를 따라잡기 힘들다는 점이다. 아이디어는 하루에 수십 개 쌓이는 날도 있지만, 실제 개발은 일주일에 4~5개 완료할 수 있으면 다행이기 때문이다. '그럼 그냥 쌓아 놓으면 되잖아'라는 의견이 있을 수 있는데, 끝없이 쌓이는 순간 모두가 괴로워진다. 일단 우선순위를 정하는 데 사용하는 시간이 늘어나고, 겹치는 태스크가 없나 매번 체크해야 하며, 개발자들은 무한정 이어지는 태스크 목록을 보며 달성감을 상실한다.

모두의 기대와는 달리 '우선순위가 높은 일은 마무리했으니, 이제 낮은 태스크를 처리해 볼까?' 같은 상황은 거의 발생하지 않는다. 프로덕트를 만들다 보면 이상하게도 급하게 처리해야 할 태스크가 늘 존재한다. 그러니 우선순위가 낮은 태스크는 어쩔 수 없이 계속 아래로 밀리게 된다.

우선순위가 낮은 태스크는 언제 처리해야 할까? 아니면 애초에 처리하긴 해야 할까?

모든 아이디어를 태스크로 만들지 말자

개발 태스크는 왼쪽에서 오른쪽으로 옮기는 보드 형태로 관리하는 경우가 일반적이다. 보통 맨 왼쪽에는 여러 아이디어를 쌓아놓는 백로그(Backlog)라는 태스크 목록이, 맨 오른쪽에는 개발이 완료된 태스크를 쌓아놓는 식으로 관리한다. 문제는 백로그에 태스크가 너무 많이 쌓인다는 것이다.

제안하고 싶은 방법은 백로그에 모든 아이디어를 담아 놓지 않는 것이다. 아이디어는 아이디어일 뿐, 당장 개발할 예정이 없으면 개발팀 눈에 보이지 않는 곳에 저장해 놓는 것이 좋다. 개선점이나 새로운 기능에 대한 아이디어는 별도의 페이지에 담아놓고, 개발 태스크 목록에는 실제로 개발할 생각이 있는 태스크만 담아 놓자. 그렇지 않으면 늘 거대한 태스크 목록이 눈앞에 아른거려 모두의 피로감이 증가한다.

아이디어를 태스크로 만들 때 사용하는 시간도 절약할 수 있다. 아이디어는 아이디어일 뿐이니 문서에 쭉 적어놓는 것만으로 충분하다. 일일이 태스크로 만들어 목록에 넣어놓는 것이 보기엔 좋을지 몰라도, 굳이 그럴 필요 없는 작업일 수 있다.

사소한 변경점은 다른 태스크에 슬쩍 끼워 넣자

개발한 내용은 일단 테스트를 거친 후 실제 프로덕트에 배포하는 프로세스를 거친다. 서비스 안정성을 위해 프로세스를 지키는 것은 효과적인 일이지만, 오타 하나 고칠 때마다 색깔 하나 바꿀 때마다 배포 프로세스를 거친다면 서비스 운영 속도에 영향을 미칠 수밖에 없다.

그래서 우선순위가 낮은 사소한 변경점을 굵직한 태스크에 슬쩍 끼워 넣는 방법을 추천한다. 예를 들어 개인정보처리방침의 링크가 잘못 설정되어 있어 고쳐야 하는데, 개발팀은 새로운 검색 기능을 추가하느라 시간이 없을 수 있다.

이때는 개발팀이 새 기능 배포를 하기 전에 '죄송하지만 링크 수정도 살짝…'이라며 슬쩍 끼워 넣기를 시도해 볼 수 있다. 물론 개발한 내용을 배포할 때는 여러 변경점을 섞지 않는 것이 좋지만(배포 후 문제가 생겼을 때 어디에서 문제가 생겼는지 찾기 힘들어진다), 속도를 내기 위한 약간의 타협은 괜찮다고 생각한다. 대신 슬쩍 끼워 넣어서 완료한 태스크는 나중에 개발팀의 원망을 듣지 않도록 여러 번 확인하여 오류가 없음을 확실히 하자.

하나의 이벤트로 만들자

마치 사무실 대청소를 하는 날처럼, 우선순위가 낮은 태스크를 한꺼번에 처리해버리는 날을 만드는 방법도 괜찮다. 한 달에 한 번처럼 정기적으로 해도 괜찮고, 많이 쌓였다 싶을 때 날을 잡아 진행하는 것도 좋다.

대신 '오늘은 우선순위가 낮은 태스크를 처리해 주세요' 같은 식으로 진행해서는 재미가 없으므로 이벤트 느낌을 내는 것을 추천한다. 회의실에 간식과 술을 준비해놓고, 다 같이 처리해야 할 태스크를 정리해놓으면 시끌벅적하고 흥겨운 개발 이벤트가 될 수 있다.

만약 우선순위가 낮은 태스크가 별로 없다면 '사소한 오류를 신고하는 직원에게 문화상품권 드립니다' 같은 이벤트도 좋다. 핵심은 다 같이 태스크를 몰아서 처리한다는 명분 아래 즐겁게 떠들면서 팀워크를 쌓는 것이다.

주기적으로 리스트를 청소하자

프로덕트는 늘 변화한다. 3개월 전에 만든 태스크가 현시점에서는 아무 상관 없는 내용일 수 있다. 만약 그런 내용이 있는 경우 과감히 치워버리자. '나중에 혹시 필요하면 어떡해'라며 끝없이 보관하는 것보다 계속 갈아치우면서 신선한 상태를 유지하는 것이 좋다. 3개월 동안 건드리지 않은 태스크라면 아마 앞으로도 개발하지 않을 확률이 높다.

리스트를 청소해야 피로감이 줄일 수 있다. 계속 눈에 보일 때, 우선순위를 정해줘야 할 때, 상관없는 내용이 검색 결과에 나올 때 알게 모르게 피로감이 쌓인다. 미세한 피로감을 줄여야 중요한 태스크에 더욱 집중할 수 있다. 중요 업데이트를 하면서 자동으로 해결된 태스크도 있을 테니 관련 있는 태스크 외에는 치워버리자.

우선순위가 낮다고 안 중요한 것이 아니다

중요한 태스크라고 하면 보통 새로운 기능이나 유저 경험을 크게 개선할 수 있는 버그 수정 등을 말한다. 그에 비해 자주 묻는 질문의 오타, 못생긴 텍스트 줄 바꿈, 1픽셀 밀려난 버튼 위치 등은 높은 우선순위를 받기엔 힘든 내용이다. 그리고 개발팀이 우선순위가 높은 태스크에 집중하는 것은 지극히 합리적인 선택이다. 그러나 그렇게 높은 우선순위에만 집중하는 동안, 사용자들은 프로덕트 완성도에 아쉬움을 느끼게 된다.

핵심 기능에 대부분의 시간을 쏟아야 하는 것은 맞지만, 그에 못지않게 작은 태스크에도 신경을 써야 한다. 개발 피로도도 그렇지만, 사소한 오류들이 모여 유저들의 신경을 거스리게 만들기 때문이다. 이 글을 통해 우선순위가 낮은 작업도 본인만의 계획에 따라 잘 해결할 수 있기를 기대한다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.