서비스 기획자가 프로젝트 일정을 관리하는 법
이건 언제까지 가능하실까요.
기획서를 완성했다고 해서 서비스 기획자로서의 일이 끝나지는 않는다. 회사마다 다를 수 있겠지만 대부분의 회사에서 서비스 기획자의 역할은 애매할 수 있다. 애매할 때면 개발과 디자인 빼고는 내가 다한다라고 생각하면 편하다.
그렇기에 보통 일정 관리도 서비스 기획자가 하게 되는 경우가 많다. 그렇기에 오늘은 서비스 기획자의 부캐인 프로젝트 매니저의 업무인 일정 관리 시에 알아두면 좋을 소소한 노하우에 대해서 알아보고자 한다.
완료 일정부터 정한 뒤 거꾸로 일정을 산정하자.
완료 일정 혹은 배포 일정부터 정하는 것부터가 일정 관리의 시작이다. 데드라인을 정하지 않으면 올해 내내 개발을 하고 있을 수 있다. 시간을 오래 투자하는 것이 서비스 퀄리티는 좋을 수 있겠지만 완료 일정에 맞춰서 개발 및 디자인 공수를 산정해야 한다.
일반적으로는 개발 일정을 먼저 검토를 하고 그 뒤 디자인, QA 순으로 일정을 확인하게 된다. 회사마다 다를 수 있겠지만 개발이 우선시된다는 부분은 비슷할 것이라고 생각된다. 초기 일정 검토 시에 완료 일정 또한 변경이 되는 경우도 있다.
일정에 대해서는 메일을 통하여 공유받는다.
서비스 배포와 개발에 관련된 일정은 매우 중요한 정보이다. 일정을 토대로 직원들의 업무 계획이 산정되며, 제대로 회사와 서비스가 움직일 수 있기 때문이다.
그렇기에 이러한 중요 정보는 메신저가 아닌 메일을 통하여 공식적으로 커뮤니케이션을 하는 것이 좋다. 메신저보다 메일로 공유하는 편이 휘발성이 적고, 히스토리 확인이 편리하다.
프로젝트 관리 툴을 통합한다.
지라, 트렐로, 구글 시트 등등 관련 부서마다 다양한 프로젝트 관리 툴을 사용하고는 한다. 여러 곳에 일정 관리 포인트가 늘어난다는 것은 체크할 포인트도 늘어난다는 이야기이다.
최대한 한 곳에서 모든 인원이 일정을 관리할 수 있도록 프로젝트 관리 툴을 통합하는 것이 필요하다. 하지만 대부분의 사람들은 기존에 익숙한 것을 계속 사용하려고 하는 경향이 있다. 그렇기에 갑자기 바꾸는 것이 아닌 조금씩 도입해보면서 변경하는 센스가 필요하다.
일정은 중요하지만 버그가 있어서는 안 된다.
일정에 맞추기 위하여 버그가 고쳐지지 않았는데 배포를 하게 되는 경우도 있다. 물론 서비스에 영향 정도가 큰 버그가 아니기에 배포를 하는 것이겠지만, 일정에만 너무 매달려서 제품의 완성도가 떨어지는 결정은 조심해야 한다.
데드라인에 맞춘다는 것은 무척이나 중요하지만, 일정에 맞추겠다고 버그가 수정되지 않은 채 배포가 되어버리면 그 이후에 발생될 운영 리소스로 인하여 더 많은 시간을 낭비하게 될 수도 있다.
서비스 완성도에 이상이 보이는 경우는 일정은 조정할 수도 있다는 것 또한 머릿속에 염두에 두어야 한다. 우선순위 1순위는 일정이 아니라 서비스 안정성이 되어야 한다.
기획자는 한국에서만 있는 포지션이라는 이야기를 듣곤 한다. 대부분 해외에서는 프로젝트 매니저라고 불리는 역할이 한국에서의 기획자와 비슷하다. 그만큼 기획자는 서비스에 대한 기획뿐만 아니라 전체 프로젝트를 리딩하고 관리하는 역할 또한 중요한 것이다.
