실패한 경험을 통해 내가 배운 것
한동안 사이드 프로젝트에 목맸던 시기가 있었다. 좋은 사람들을 만나 끝까지 진행하여 릴리즈한 경험도 해보고 개발까지 완료했지만 QA 과정에서 프로젝트가 흐지부지되었던 마음 아픈 경험도 해봤다. 이 모든 경험이 지루하던 일상을 재미있게 해 주던 때가 있었고 이러한 경험을 통해 성장하고 있다는 생각에 보람찬 나날을 보내던 때가 있었다. 그래서 프로젝트 하나가 끝나면 다른 프로젝트를 찾는 사이클을 반복하게 되었는데 항상 좋았던 경험만 쌓였던 것은 아니었다. 이 과정 속에서 배웠던 것을 공유하고 싶다.
결론부터 말하자면 프로젝트 시작도 하기 전에 팀이 해체됐다.
첫 번째로 실패한 우리 팀의 팀원은 총 8명이었다. 2명의 기획자와 2명의 디자이너, 4명의 개발자로 이루어졌다. 아이디어가 많았던 PM 덕분에 재밌는 아이템이 많이 리스트업 되었고 마음이 맞는 또 다른 디자이너 덕분에 재밌는 프로젝트가 될 것 같았고 실제도 디자인도 퀄리티 있게 진행되었으나 업무 이해도가 서로 달랐던 것, 소통 등 여러 가지 이유로 팀은 해체되었다. 두 번째 팀도 비슷하다. 초기 기획단계에서부터 삐걱거리기 시작하더니 기획에 계속해서 구멍이 생기게 되었고 결국에는 내가 뛰쳐나오게 되었다.
데드라인이 있는 사이드 프로젝트에서 어느 정도의 볼륨으로 진행해야 실제 릴리즈가 가능한지 몇 번의 경험을 통해 알게 되었다. 각자 현업이 있기 때문에 회사 업무처럼 몰입하고 퀄리티를 내기는 어려워도 각자 원하는 목표를 가지고 합류한 만큼 실제 릴리즈를 했을 때 너무 퀄리티가 떨어지는 서비스를 내놓지 말자는 암묵적인 룰이 있어왔다. 그러나 실패한 2개의 프로젝트에서는 이 부분이 충족되지 못했고 서비스 자체보다는 마케팅, 홍보 등에 초점을 맞추거나 일정에 맞춰 완성하는 데에 급급하여 의견 조율이 매우 어려웠다.
당시에 나는 사이드 프로젝트에서 우리가 내고자 하는 서비스에 대한 책임감과 맡은 업무에 대한 책임감을 가장 중요하게 생각하고 있었기 때문에 앞서 기재한 일련의 사건들이 도무지 이해가 되지 않았다. 언성을 높이며 싸우지는 않았지만 서로의 입장에 대한 의견이 많이 오갔었고 모두가 원팀으로 집중하지 못하는 분위기에 속상하기도 했었다. 꼭 의미 있는 결실을 맺어야 성공한 프로젝트라고 생각하진 않는다. 내가 좋은 경험이었다고 생각하는 프로젝트에서 결실을 내지 못한 것도 분명 있으니까. 하지만 재밌자고 시작한 프로젝트가 스트레스가 되었고 진행하는 과정이 즐겁지 않아 의견 조율 끝에 프로젝트 진행을 멈추기로 결정했다.
나는 연달아 실패한 프로젝트를 통해 아무것도 얻은 게 없이 시간만 버렸을까? 처음에는 시작하지 말고 좀 쉴 걸 그랬다고 생각한 적이 있었다. 하지만 지금 생각해보면 이 경험에서도 분명 배운 것이 있었고 내가 미흡하게 대처했던 부분에 대해 스스로를 되돌아보게 되어 그 부분을 정리해 보려고 한다.
프로젝트가 중간에 무산되지 않으려면 명확한 워딩으로 목표를 세워야 하고
그에 따른 구체적인 계획이 필요하다.
실패한 첫 번째 프로젝트에서 가장 큰 문제가 되었던 것은 팀 목표였다. 우리는 데드라인을 정해두었던 프로젝트였기 때문에 마일스톤을 만들기가 어렵지는 않았지만 이 과정에서 문제가 있었다. 당시 우리 팀의 공통 목표는 일정 내에 MVP 버전의 서비스를 개발하자였다. 처음에는 전혀 문제 되지 않았지만 구체적인 서비스 기획과 디자인이 들어가면서부터는 이 부분에 대한 의견이 서로 달랐다. 일정 내에 서비스를 내더라도 꼭 있어야 하는 필수 기능들은 들어가야 한다, 사용자를 훅(hook)할 수 있는 차별된 기능 하나는 있어야 한다, 목표를 맞추기 위해 디자인과 개발 퀄리티를 너무 낮게 잡을 수는 없다 등 실제 명확하게 목표를 설정하지 않고 일정 내에 완수하자라고만 설정했던 목표 때문에 각자 이해하고 있던 기준과 방향이 달랐었던 것 같다고 생각한다.
프로젝트가 흔들리거나 산으로 가지 않으려면
지속적으로 우리 서비스에 대해 리마인드 해야한다.
이 두 프로젝트에서는 초기 기획 선정이 굉장히 미흡했다. 한 프로젝트에서는 서베이와 인터뷰를 진행했었는데 해당 결과에 매몰되어 초반에 반짝였던 아이디어가 사라졌고 다른 프로젝트에서는 실제 사용자를 생각하지 않고 진행하여 중간에 어려움을 겪었었다. 시간이 촉박하기도 했지만 넣고자 하는 것들이 많아 초반에 생각했던 feature들이 변경되기도 했고 일정 운운하며 중요하지 않은 부분에 집착하게 되기도 했었는데 이런 사이클이 반복되면서 서로 지치게 되었고 효율적으로 프로젝트를 진행하지 못했던 것 같다. 마무리를 잘했었던 다른 프로젝트의 경험을 되새겨보면 계속해서 서로 커뮤니케이션하며 우리 서비스의 목표나 핵심 기능에 대해 리마인드를 했었는데 이번 프로젝트들에서는 그런 모습을 서로 보여주지 못해 안타까웠고 서로 공통의 그림을 보며 커뮤니케이션하는 것의 중요함을 깨달았다.
다수결은 언제나 옳은 결정 방향일까.
이 부분은 지극히 개인적인 경험담이라 공감하지 못하는 사람들도 많을 것 같다. 두 번째로 실패했던 프로젝트에서의 경험이다. 지인들로 구성된 팀이 아니다 보니 초반에는 서로 조심스러운 부분들이 있었는데 그러다 보니 어떠한 결정이 필요할 때 다수결로 진행하는 경우가 있었다. 당시에 이러한 결정방법이 의아했었는데 워낙 초반이고 다들 이견이 없어 보여 나중에 문제가 생길 거라 생각 못했기 때문에 별 말없이 따랐던 방식이다. 결과적으로 우리는 이러한 결정 방식 때문에 중간에 아이템을 바꾸고 기획을 다시 하는 등 두 번 작업을 하게 되었고, 여기서 우리가 간과한 것은 팀원 모두의 이해도 수준이 비슷하지 않다는 것이었다. 다들 서비스에 대한 이해도나 관점이 다르고 선호하는 것들 역시 다르기 때문에 각자의 입장에서 해보고 싶은 것, 실제로 구현하기 어렵지만 흥미로워 보이는 것, 사용자 입장에서 불필요한 것 등 진행하기 어려운 것들이 선택되는 불상사가 발생하게 되었다. 서비스의 목표(goal)를 설정하려고 했었던 방식이 결국 서비스의 non-goal을 선택하는 방향이 된 것 같아 아쉬웠고 서비스의 가치를 도출하는 중요한 결정을 다수결로 했을 때 이처럼 프로젝트 방향이 흔들리는 위험이 발생한다는 것을 명심해야겠다고 생각했다.
실패한 경험에 대해 쓰다 보니 그 원인이었던 미흡했던 부분만 언급했지만 그럼에도 불구하고 배운 게 많았던 프로젝트였다. 좋았던 점도 많았다. 발산형 팀원들 덕분에 다양한 논의가 가능했던 것, 회고를 통해 우리 팀이 보완해야 할 것들을 진솔하게 이야기하며 이것을 바탕으로 명확한 이해를 할 수 있었다는 것이 가장 기억에 남는다. 서로 믿고 격려하며 적극적인 커뮤니케이션을 할 것, 욕심을 내려놓을 것 등 당연히 해야 하지만 실행하기 어려운 것들이 있다. 이러한 것들이 조금 부족하여 결국 중간에 여정을 멈추게 된 프로젝트가 되었지만 이러한 과정들이 다음 협업에서 더 좋은 영향을 줄 것이라 믿는다.