사이드 프로젝트가 망했어요 - 2

⬆️ 이전 글 보기

시작은 좋았다.

테오의 스프린트라는 활동에서 아이디어를 정하고, 팀원을 모아 기획하고 개발했다. 평소 만들어보고 싶던 내 아이디어를 사람들에게 어필하고, 설득에 성공해 나를 포함한 6명이 모여 약 6일간의 스프린트를 진행했다.

나는 테오 스프린트가 두 번째였는데, 첫 번째 때는 사람들이 사용하는 프로젝트를 만들어 피드백을 받아보자는 소기의 목적을 달성하는데 성공했었다. 이미 해봤기 때문에 이번에도 쉬울 것이라 생각했을지도 모르겠다.

어쩌다 보니 프론트엔드 개발자이자 PL(Project Leader) 역할을 맡았다. 처음에는 합의를 통해 PL로서 사람들에게 업무를 적당히 분배했다고 생각했는데, 갈수록 그게 아니었나 하는 생각이 들기 시작했다.

일이 병렬적으로 진행되지 않았다는 문제가 가장 컸다.

누군가는 맡은 일을 일찍 끝내 추가적으로 할 일을 찾고 있는데, 누군가는 일이 끝날 기미가 보이지 않았다. A업무가 B업무에 의존성을 갖고 있으면 B업무가 끝나야 A업무를 할 수 있다. 그런데 B업무를 맡은 사람이 업무를 끝내지 못하면 A업무는 진행할 수가 없게 된다. 이렇게 스케쥴이 꼬이기 시작한 것이다.

여기서 PL로서의 내 역할이 중요했었다. 일정이 밀리는 팀원을 좀 더 푸시하거나, 업무가 과중했다면 나눴어야 했다. 그러나 그 당시에는 특히, 주말에 각자의 개인 시간이 중요하기도 하고 돈 받고 하는 일도 아니었기 때문에 딱 잘라 요구하지 못했다. 업무를 나누는 것도 다른 사람 업무는 잘 모를 거라는 이유로 하지 않았다.

그러나 지금 생각해 보면 짧은 시간 안에 데모를 만들어야 했고 본인들도 그걸 알고 참여한 것이기 때문에 좀 더 시간 투자를 요구했어야 했다.

업무를 나누는 것에 관해서는 혹여나 잘 모르는 분야일지라도 그냥... 하면 된다. 안 하고 가만있는 것보다는 낫다. 게다가 개발한지 기껏해야 하루 이틀이었다. 코드를 다 까보면 대충 로직을 파악할 수 있기 때문에 한 업무가 너무 거대하다면 추가 인력을 투입했어야 했다.

돌이켜보면 제대로 된 의사 결정을 내리지 못한 일이 나비 효과로 인해 결과물을 내는 데 실패한 결정적 이유가 되었다. 차라리 팀원들은 드럽게 닦달해도 결과물은 어떻게든 뽑아내는 PL이 됐어야 했을지도 모른다. 무능력해 아무것도 만들어내지 못한 PL보다는 나았겠지.

PL에 뽑혔을 때는 별거 아닐 줄 알았다. 초기에 역할 분배만 하면 끝난다고 생각했다. 사실은 프로젝트 내내 가장 중요한 역할이었다. 이렇게 인생 첫 PL을 경험해 봤고, 쓴맛을 맛봤다. 함께 한 팀원들에게는 역할을 제대로 해내지 못해 미안한 마음이 든다.