Overview

언제나 그렇듯 글을 쓰는 건 가장 어려운 것 중에 하나다. 평소에 글을 쓸 기회가 있는 것도 아닌 데다, 재밌게 쓸 재주도 없기 때문이다. 게다가 원고 마감만 다가오면 ’개발자가 아닌데 기술 블로그에 무엇을 써야 하나’ 하는 정체성의 혼란도 겪는다. 그래도 마감은 지켜야 하는 법! 고민 끝에 PMBOK(Project Management Body of Knowledge, 프로젝트관리지식체계)를 기준으로 브랜디에서 프로젝트 매니징하는 방법을 이야기하고자 한다.

브랜디에서는 어떻게 할까?

브랜디에서 통합관리(Project Integration Management)는 트렐로(Trello)로 진행한다. 통합관리에 대한 자세한 설명은 이전 포스팅인 PM, 대충하면 큰일납니다(1)의 1번 항목을 참고하면 되므로 생략하겠다.

브랜디는 R&D본부를 제외하고 15개의 팀으로 구성되어 있다. 각 팀은 저마다의 KPI를 달성하기 위해, 개발을 요청하는데 생각해보라. 팀마다 하나씩만 요청해도 R&D본부는 15건의 개발 업무를 진행해야 한다. 아찔하다. 자칫 헷갈릴 수도 있다. 그렇기 때문에 각 팀의 요청은 무엇인지, 언제까지 진행해야 하는지 등 한눈에 보이도록 정리하는 건 당연한 일이다. 트렐로는 소리 없는 아우성으로 가득한 통합관리를 완벽히 정리해주는 도구다.

우선 위의 이미지처럼 각 팀별로 중요한 개발 요건들을 카드로 만든다. 요청한 개발 내용과 건수를 한 번에 파악할 수 있다. 하지만 더 중요한 건 요청에 대한 우선순위를 지정하는 것이다. 빨리 요청한 업무가, 빨리 처리되는 건 아니다. 어느 회사나 개발 자원은 한정되어 있기 때문에 조직은 가장 효율적으로 운용할 수 있는 방법을 찾아야 한다. 그 방법 중에 하나가 우선순위를 지정하는 것이다. PM팀은 매주 월요일마다 팀별 개발 요건 카드들을 나열하고 우선순위를 정한다. 그리고 그 다음에 프로젝트 계획서를 만든다.

[정리]효율적인 통합관리를 위하여
1) 요청한 개발 내용들을 카드로 만들자, 이쪽저쪽 옮기기 쉽게!
2) 가장 중요한 업무를 파악해 우선순위를 지정하자.
3) 프로젝트 계획서를 만들자.

정리, 정리, 또 정리

서두에서는 15건의 개발 요건만 예로 들었지만, 세상 일이 그리 호락호락하진 않다. 하루에도 수십 개의 요청카드가 쌓이는 걸 보면 이따금씩 타노스의 능력으로 삭제 버튼을 클릭하고 싶은 마음이 굴뚝같다. 그래도 어쩌랴. 이왕 하는 거 깔끔하게, 그리고 가능한 헷갈리지 않게 해야 한다. 여러 팀이 함께 쓰는 보드인 만큼 PM팀의 역할이 중요하다.

1. 프로세스를 잡자!

여러 팀과 미리 약속을 잡아두지 않으면 혼선이 생기기 마련이다. 개발 요건 카드는 이리저리 날아다닐지도 모른다. 트렐로를 세팅할 때, PM팀은 카드들이 날아다니지 않도록 List를 설정해야 한다. 브랜디에서 세팅했던 초기 List는 아래와 같다.

1) 팀별 요건 List
팀마다 List가 있다. 트렐로에 참여한 직원들은 각자가 속한 팀의 List 외에는 건들지 않아야 한다. R&D본부에서 요건을 처리할 때마다 카드가 이동되기 때문에 처음 카드를 만들 때 요청자의 팀명과 중요도 등을 정확히 기재하면 좋다. 더 나아가 아예 카드에 적을 양식을 미리 정하면 다른 팀과 R&D본부 모두 평화롭게(?) 지낼 수 있다.

트렐로 카드 양식 예시
* 우선순위(사용빈도수)
* 요건위치 : 앱/관리자 페이지 위치
* 이슈내용 : Why?! 개발요건 발의의 목적
* 요건 상세 내용
* 신청자(팀)
* 관련 이미지, 파일 첨부 여부

2) PM팀 우선순위 List
PM팀은 요건을 발의한 각 팀장님들과 머리를 맞대고 수많은 요청 카드 중 우선적으로 처리해야 할 업무들을 PM팀의 우선순위 List에 옮긴다. 어느 조직이든 자신의 조직 업무가 가장 중요하다고 여기므로 PM팀은 이를 잘 중재하고, 관리할 수 있어야 한다. 이 List로 옮길 수 있는 권한은 당연히 PM팀에게만 있어야 한다.

3) 기획 중 List
우선순위 List로 옮긴 요건들에 대한 기획을 진행한다. 이때 기획 진행 상황을 알 수 있도록 PM팀은 별도의 List를 생성해 관리하면 좋다.

4) 개발 진행 / 상용 반영 List
배달 앱에서 ‘주문 접수 중-조리 중-배달 중’의 프로세스가 보이는 것처럼 요건 처리 과정을 확인할 수 있는 List로 활용한다.

5) 보류 / 확인 List
모든 카드에 대해 무작정 개발을 진행할 수는 없다. 개발 시 이슈가 있거나 우선순위에서 누락된 카드는 사유 Comment를 달고 보류시킨다.

2. 과감히 버리자!

PM의 인재상은 머리부터 발끝까지 미니멀리즘으로 무장을 해야 한다는 거다. 굳이 나중을 위해 카드를 남겨둘 필요는 없다. 어차피 미뤄진 요건은 (언제가 될지 모르는) 훗날 개발을 시작할 때 상황에 맞게 다시 정리해야 한다. 다시 말해, 보류된 카드들이 다시 빛을 보는 일은 거의 없다는 것이다. R&D본부에 요청한 분들에겐 잔인한 이야기지만 PM팀은 미련을 가질 여유가 없다. 필요 없거나, 중복되는 카드는 삭제하는 것이 좋다. 언제든지 Archive를 클릭할 준비를 하자. 물론 Archive는 카드 생성자가 직접 하는 것을 원칙으로 하되, 함께 있는 자리에서 사전 협의를 거쳐 진행하는 게 에티켓이다.

브랜디에서는 매주 카드 정리하는 시간을 갖는다. 요청했던 팀과 요청을 파악하는 R&D본부의 팀원이 한자리에 모여 카드를 정리하면 핵심 파악이 빨라지고, 현재 브랜디에서 진행해야 할 우선순위가 눈에 보이기 시작한다.

3. 모르면 물어보자!

너무 당연한 이야기라고 생각하겠지만 의외로 질문을 쉽게 하는 사람은 드물다. 다들 바쁜데 질문하면 괜히 눈치 보이고, 미안하다는 등등의 이유로 혼자 고민하는 사람들이 많다. 이 행동이 반복되면 결국 트렐로는 망가지고 업무는 산으로 갈 것이다. PM팀은 지속적인 회의를 통해 다른 팀과 호흡을 맞추면서 개발 요건을 파악해야 한다. 분명 더 좋은 결과물이 나올 수 있을 것이다.

[정리]트렐로를 관리하는 PM의 역할
1) List와 규칙을 만들어 개발 프로세스를 구축하자.
2) 보류된 개발 요건은 미련 갖지 말고 당당하고 과감하게 버리자.
3) 모르면 질문하자. 다른 팀은 경쟁자가 아니라 함께 호흡을 맞춰야 할 대상이다.

Conclusion

정리하면 짧은 내용이지만, 실은 트렐로를 세팅하기까지 많은 혼선이 있었다. 협업을 거치면서 브랜디 업무에 가장 최적화된 List를 구축하고 나니 업무 History관리도 쉬워졌고, 요청자 파악도 명확해졌다. 게다가 이미지나 파일을 첨부할 수 있어 트렐로는 통합관리도구로 적절하다고 생각한다.

다만 통합관리 이외의 일정관리나 품질관리까지 트렐로로 관리하긴 어렵다. 브랜디에서는 다른 관리는 다른 툴을 사용하고 있다. 무엇인지 궁금하다면? 다음 포스팅을 기대해주시길 바란다.

글
문경민 | 커머스 개발팀
moonkm@brandi.co.kr

브랜디, 오직 예쁜 옷만