기획이 끝나고, 개발자에게 일은 어떻게 넘길까?
WBS 활용법과 이슈 쪼개기
WBS는 Work Breakdown Structure의 약어로 '작업 분류체계'라고도 하며 프로젝트에서 수행할 작업을 계층적으로 정의한 표이다. 예를 들어, 집을 건축하는 것을 하나의 프로젝트라고 하면 디자인부터 시작해 초안잡기 > 건축 > 검토 > 최종 확인 등으로 단계가 나눠져 있다면, 각 단계에서 세부적으로 해야 할 일이 무엇인지 나눠보는 것이다.
팀이 한 번에 워크플로우와 단계가 정해졌다면, 정해진 업무 분류 체계를 가시화하는 작업이 필요하다. WBS에는 Asana에 따르면 다음이 포함되어야 한다.
1. 프로젝트 계획, 설명, 이름을 비롯한 프로젝트의 기준이 되는 정보
2. 프로젝트 이해관계자
3. 체계적으로 계획된 프로젝트 일정
4. 프로젝트 결과물 및 하위 작업
이를 기준으로 하나씩 차근차근 알아보자.
1. 프로젝트 개요를 분명히 하기
우선 다른 사람들과 공유할 수 있도록 프로젝트를 '설명'하는 문서를 적어내야 한다. 사용자 입장에서 알아볼 수 있도록 쉽게 프로젝트 '이름'을 짓고, 설명과 계획을 적어낸다. 프로젝트에 필요한 모든 걸 적어낸다고 보면 된다. 나의 경우 아래의 정보를 적는다.
프로젝트 이름, 짤막한 개요, 추가 필요한 설명
프로젝트에 투입되는 팀원들 이름, 역할
프로젝트를 제안한 마케터 이름
개발자들이 개발 시 필요할 정보가 담긴 모든 사이트 링크들 첨부
프로덕트 오너가 디자이너와 업데이트한 와이어프레임 및 기획 문서
배포 후 개발본부 팀원들이 피드백을 주고받으며 채워 넣을 프로젝트 리뷰용 엑셀표 링크
배포 후 마케터들이 프로젝트 관련하여 사용자와 소통할 때 참고할 수 있는 문서 (개발 문서를 사용자 입장에서 쉽게 정리하고 설명한 문서인데, PM 팀이 담당하여 적어낸다)
슬랙에 관련된 모든 대화 링크들
정말 많아 보이지만 필요한 걸 다 적으려다 보니 조금씩 발전시켜 완성한 목록들이다.
2. 프로젝트 이해관계자 넣기
이해관계자란 프로젝트에 관여해야 하는 모든 사람들을 의미한다. 누가 참여하고 미팅이 잡힐 때마다 리뷰해야 하는지 정의하는 것이 중요하다. 그래야 모두가 만족하는 결과물을 만들어낼 수 있다.
프로젝트를 제안한 마케터의 이름
프로젝트 개발 사항을 중간에 리뷰할 지원자(제안한 마케터, 혹은 PO가 전체 맡을 수도 있다)
프로젝트 매니저
개발자, 디자이너
배포 후 사용자에게 해당 기능 소식을 전달할 팀 혹은 팀원
담당자를 확실히 정하기3. 체계적으로 계획된 프로젝트 일정, 하위 작업
프로젝트 마감일을 정해야 한다. 개발자, 디자이너가 어느 정도 시간이 걸릴지를 같이 확인하고, 얼마나 일이 어려울지, 어떤 리소스가 필요할지 확인해주어야 한다. 이후 Daily standup이라고, 매일 일이 잘 진행되고 있는지 모니터링하며 마감일이 잘 지켜지도록 PM이 적극 도와야 한다.
개발자와 디자이너와 정확한 마감일을 정하려면 각 이슈를 쪼개 주어야 한다. 이도 실무진과 함께 진행해야 한다. 예를 들어 디자이너가 디자인을 완성하는 것은 [기능 UI 디자인 > 피그마 업로드 > PM이 최종 컨펌 > 개발자 전달] 같은 절차가 필요하다. 그렇다면 여기서 [기능 UI 디자인 > 피그마 업로드]가 디자이너가 해야 할 일이니, 절차를 이슈로 변환해 두 개로 쪼개면 될 것이다.
절차를 이슈로 변환하는 것은 우리 팀의 편의를 위해 하고 있는 방법이니 무조건 지켜질 필요 없다. 실무자들과 상의하여 어떻게 업무를 쪼개드리면 좋을지 함께 확인하도록 하자. 훌륭한 WBS가 만들어질 것이다.
절차가 만들어졌고, 각 단계에서의 일이 세분화되었다면 아래 이미지에서 설명하는 세 방법으로 가시화될 수 있다.
출처: Asana우리 회사의 경우는 타임라인과 칸반 보드를 개발 본부 내에서 사용한다. 타임라인은 말 그대로 스케줄을 줄로 표시해놓은 것이고, 칸반 보드는 단계를 [시작 > 개발 중 > 배포] 같이 단계로 나누어 그 안에서 이슈들을 넣는 것이다.
캘린더는 마케터들을 위해 프로젝트 배포일만 업데이트한다.
4. 프로젝트 결과물
프로젝트 결과물이 나오면 아래와 같은 정보가 모두에게 전달되어야 한다.
개발된 프로젝트의 개발적 특징이 적힌 문서 > 개발자 참고용
개발된 프로젝트의 사용법이 적힌 문서 > 마케터 참고용
개발된 프로젝트의 개선점 > PO, PM 참고용.
개발자의 용어, 마케터의 용어가 다름을 감안하고 회의를 진행하고, 문서를 각각 작성한다첫째는 후에 다른 개발자들이 작업할 때 참고할 수 있도록, 둘째는 마케터들이 사용자들과 소통할 때 참고할 수 있도록, 셋째는 다음 배포 때 참고하도록 PM팀이 보게 넣어놓는 것이다.
찾은 개선점들이 보통 추가 작업으로 들어간다. 기획이 필요할 때도 있다. 굳이 개선해야 하느냐 마느냐는 PM과 PO가 우선순위를 확인해 아닌 건 쳐내고, 필요한 건 리소스를 확인한 후 개발자에게 할당해야 한다.
