나만 사용하는 프로젝트 관리 툴, GitHub로 문제를 해결하다.
이론과 실무 사이의 간극을 좁히기 위해, PM/PO로서의 첫 발걸음을 사이드 프로젝트에서 시작했다. 올 상반기에 PM/PO라는 업을 이해하고, 이론 공부하는데 시간을 많이 썼다면 하반기부터는 이론을 직접 적용해보고 싶어서 사이드 프로젝트에 참여하게 되었다. 사실 초짜인 내가 어떤 사이드 프로젝트에 그냥 참여했으면 좋았겠지만, PM이라는 롤로 일반적인 사이드 프로젝트에 참여했을 때 협업자 위주의 팀원분들을 이끌어나가야 하는데 분명 무리라고 판단했다. 그렇다고, PM을 2명씩 구하는 사이드 프로젝트는 많지 않았다. 결국 내가 직접 낮은 난이도의 프로젝트를 계획하고 내가 능숙하지 못해도 이해해줄 수 있는 성장 단계에 있는 팀원분들을 모아 "브루버즈"라는 프로젝트를 시작했다.
[프로젝트 관리의 실패]
프로젝트를 진행하면서 단연 여러 어려움이 있었지만, 현재 가장 큰 문제는 프로젝트 관리가 제대로 되지 않는다는 점이다. 최초 프로젝트 계획 시 유지 보수를 고려하지 않았고, 버그(이슈) 트래킹 시스템에 강점이 있는 Jira를 사용하기보다는 나를 포함한 다수의 팀원분들이 익숙한 Notion을 프로젝트 관리 툴로 선정했다. 프로젝트 초기에는 쉬운 문서화 기능과 더불어 최근에 추가된 스프린트 및 업무분류체계(Work Breakdown Structure, WBS) 관리 기능을 이용하면, 충분히 프로젝트를 관리할 수 있다고 판단했다. 결론부터 말하자면, WBS를 지키지 못했을 뿐더러 제대로된 프로젝트 관리가 이루어지지 않았다.
[실패의 원인 분석]
내가 파악한 원인은 크게 2가지 인데, 첫 번째는 프로젝트에 할애할 수 있는 개인의 일정이 유동적이라는 것이고, 두 번째는 개인의 퍼포먼스를 사전에 파악할 수 없다는 점이다. 해당 프로젝트가 사이드 프로젝트로 진행되는 만큼, 본업이 있는 팀원분의 경우 매주 프로젝트의 할애할 수 있는 시간에 변동이 있었고, 나를 포함해 개인의 퍼포먼스를 객관적으로 판단하기 어려워 계획한 과제를 정해진 기간 내에 끝내지 못하고 늘어지는 경우가 많았다.
[GitHub 도입 결정]
더군다나, 팀원분들이 Notion의 신규 기능인 WBS를 사용하는 데 어려움을 겪었고, 결국 나만 사용하는 기능이 되어버려 기능의 활용도가 떨어져 결국 작업의 진행 상황을 파악할 수 없는 지경에 이르게 되었다. 디자인 파트의 경우 화면 단위로 과제가 진행되는 만큼, 결과물을 직접 확인할 수 있어 작업 트래킹에 용이한 반면, 개발 파트의 경우 결과물을 확인하기 어려워 작업을 트래킹하는 데 어려움을 겪었다. 고민이 있던 와중에 요즘 듣고있는 수업에서 디렉터님께서 본인은 GitHub로 프로젝트를 관리한다고 말씀해주셨는데, 이거다 싶었다.
Jira를 도입해볼까 고민했지만 지금 당장 유지 보수를 고려하지 않는다는 점과 나를 포함한 팀원분들 모두 Jira를 사용해본 경험이 없어 당장 적용이 불가하다는 점이 나를 망설이게 만들었다. 더군다나 개발이 한창이기 때문에 개발자분들이 큰 리소스를 들이지 않고, 내가 개발 작업의 진척도를 파악할 수 있는 프로젝트 관리 방법이 필요했다. 그런 측면에서 GitHub에서 제공되는 여러가지 상태(status)와 뷰(view)를 이용하면 큰 무리없이 프로젝트를 관리할 수 있겠다고 생각했다.
[WBS와 GitHub 학습]
GitHub를 이용해 프로젝트를 관리하기 앞서, WBS에 대한 산출물에 대한 이해와 더불어 GitHub 기능에 대한 학습이 필요했다. 앞서 언급했듯, 우리 팀이 WBS를 지키지 못한 이유는 첫 번째 워킹 아워(working hours)의 확보가 어렵다는 점, 두 번째 나를 포함한 팀원분들 모두 개인의 퍼포먼스(performace)를 파악하기 어려워 업무 완료까지 산정한 기한을 계속해서 초과한다는 점이다. 하지만, 그전에 가장 큰 문제는 PM의 롤을 맡고있는 내가 WBS라는 산출물에 대한 이해가 낮고, 심지어 어떤 기준을 토대로 업무를 작업(work package) 단위로 쪼개야 하는지 감을 잡기 어려웠다.
[문제 해결을 위한 시도]
차근차근 WBS에 관한 학습을 개인적으로 진행하고, GitHub 계정을 생성과 함께 새로운 조직(organization)에 리포지토리(repository)를 만들고 기능에 관한 학습을 했다. 핵심은 내가 놓친 진행상황을 팔로업(follow-up)하고 기존에 운영하고 있는 조직 내 리포지토리를 건들이지 않고, 프로젝트를 관리하는 방법을 찾는 것이다. 따라서 2가지 방법을 생각했는데 방법은 아래와 같다.
- 방법 A. 기존 리포지토리(R1)를 새로운 조직(O1)으로 옮기기
- 방법 B. 기존 조직(O1)에서 새로운 리포지토리(R2) 생성 후 워크 아이템(work items) 추가하기
[해결 과정에서 시행착오]
기능에 대한 학습을 진행하면서 생성한 리포지토리(R1)에 등록한 워크 아이템이 많아서 방법 A를 우선 시도했는데 실패해 버렸다. 정확히 말하면 리포지토리 전송(transfer)은 성공했는데 내가 필요한 건 리포지토리 전송이 아닌, 프로젝트(project) 내 워크 아이템을 전송하는 것이었다. 결국 방법 B를 선택했고, 이는 의외로 간단한 해결책이었다. 개발자분들의 리소스 소모를 최소화하면서도 효과적인 프로젝트 관리가 가능한 방법이었는데, 바로 기존에 등록된 워크 아이템을 새로운 프로젝트에 추가하고 이슈로 전환한 후 프로젝트를 복수 선택하는 것이었다. 다만 이 과정에서 프로도님의 이슈 상태를 건드리는 실수를 해버린 탓에 프로도님의 도움이 필요했다. 다행히 큰 문제는 아니었고, 프로도님의 도움으로 이러한 방식을 안정적으로 구현할 수 있었다. 결과적으로 개발자분들의 리포지토리를 건드리지 않으면서도 나는 프로젝트 진척도를 효과적으로 확인할 수 있게 되었다.
[함께 사용하는 환경 구축]
이와 더불어 모든 팀원분들이 함께 사용할 수 있는 환경을 만들기 위해 두 가지 노력을 했는데, 첫 번째는 커스텀 필드와 상태를 세분화하여 작업자가 보고 싶은 정보를 빨리 찾을 수 있도록 했다. 두 번째는 사용 방법 문서화이다. 일전에 나는 팀원분들에게 제대로 된 문서 없이 구두로만 Notion의 WBS 기능을 설명했는데, 돌이켜보면 이 부분이 "나만 사용하는 기능"이 된 가장 큰 계기가 아닌가 싶었다. 개발자분들은 GitHub에 익숙하실지 몰라도 비개발자 파트의 팀원분들은 사용하는 데 어려움을 겪을 수도 있다는 생각에 최대한 상세히 기능 설명과 사용법을 문서화해서 전달했다.
[문제를 해결하며 배운 점]
아직 문서화한 내용을 전달한지 얼마 되지 않아 팀원분들의 반응을 지켜봐야 하겠지만, 특히 개발 진척도를 실시간으로 확인할 수 있게 된 점이 가장 고무적이다. 얼핏 보면 간단해 보이는 해결책이었지만, 모든 게 처음인 내게는 이 모든 과정이 도전이었다. 그럼에도 WBS와 GitHub에 대한 이해를 넓힐 수 있었고, 무엇보다 프로도님과 함께 고민하며 이 문제를 해결해냈다는 점이 뿌듯하다. 앞으로도 이런 작은 성공들이 모여 더 나은 PM/PO가 되어갈 수 있길 바란다.