리스크의 조기 검증에 대해

신입 기획자로 입사하자마자 억 단위의 정부지원사업 프로젝트의 기획자로 사수 없이 혼자 일을 하며 허둥지둥대다 보니 어느새 프로젝트가 끝나가고 있다. 여태까지 가장 크게 느낀 것은 '리스크의 조기 검증이 가장 중요하다'는 것이다.

사실 뻔한 말이지만, 실무에서 수많은 실수를 저지르며 왜 이것이 중요한지를 실감했다. '리스크'란 무엇이고, '조기'란 언제인지 알게 되었달까. 그것은 딱 정해져 있는 것이 아니라 일의 단계, 범위 등에 따라 모두 달랐다. 하지만 그 어느 일이라도 이 '조기 검증' 법칙이 중요하지 않은 것은 없었다. 실제 내 사례를 바탕으로 작성했지만, 실제와 다른 부분도 있다.

---

Case 1. 킥오프 단계의 기획을 할 때

나는 나의 '완성되지 않은 생각'을 누군가에게 피드백 받는 것이 부끄러워서 그것이 어느 정도 구체화될 때까지 고민하며 꽤나 많은 시간을 썼다. 열심히 와이어프레임과 스토리보드를 만들어 '짜잔'하고 보여주는 느낌이었달까.
물론 완성된 기획서를 공유하고 피드백 받는 것은 필요한 과정이다. 하지만 기획서를 1차로 완성하고나서 디자이너와 개발자의 피드백을 받는 것은 너무나도 느리다. 신입 기획자의 '완성되지 않은 생각'은 사실 처음부터 불가능한 것일 수도 있다.
예를 들면, '음원의 파형을 보여준다'는 요구사항은 간단해 보이지만 개발단에선 고려해야 할 점이 많다. 다른 서비스에 떡하니 있다고 우리도 뚝딱 만들 수 있는 것이 아니다. 이 요구사항을 개발팀에서 반려한다면, '파형을 클릭해 재생 위치를 변경한다'는 요구사항도 삭제된다. 그렇다면 재생 위치는 어떻게 변경할지 다시 기획을 해야 하는 것이다.
만약 와이어프레임을 작성하기 전에 개발자에게 '음원의 파형 보여주는 거 어렵나요?'라고 물어봤다면 이것이 생각보다 간단한 일이 아님을 파악하고, 구현 가능성에 대해 더 알아봤을 것이다. 개발자분들도 한 마디씩 거들며 좀 더 일찍 반려했을 것이고 기획 리소스의 낭비는 일어나지 않았을 것이다.
피드백은 자주 받을수록 좋고, 일찍이라면 더 좋다.

그렇지 않으면 엄청나게 불어난 스노우볼에 치인다.

Case 2. 개발 일정을 산정할 때

내가 다니는 회사는 개발 일정을 산정하는 프로세스나 프레임워크가 따로 정해진 게 없었다. 개발 프로젝트는 완전 처음인 내가 임의로 일정을 산정할 수는 없었고 개발자분들에게 해당 작업이 얼마나 걸릴 것 같은지 물어보며 일정을 짰는데 이게 여간 어려운 일이 아니었다. 사실 단 한 번도 일정에 맞춰 끝난 적이 없다고 해도 과언이 아니다.
어쩌다 한 번이 아니라 매번 일정이 맞춰지지 않는다면 분명한 문제와 원인이 있는 것이다. 내가 생각하는 몇 가지 원인이 있지만, 너무 길어지므로 추후 별도의 글로 다뤄보겠다.
하나의 사례를 공유하자면 '사람들은 생각보다 많이 아프다'는 것이다. 꼭 본인이 아니더라도 가족이 간호가 필요할 정도로 아플 수 있다. 프로젝트를 진행하는 동안 병가를 내는 분이 생각보다 많았고, 심지어 가족분이 아프셔서 한 달을 휴직한 분도 있었다. 안타까운 일지만, 프로젝트 진행 관점에서는 정말 큰 타격이었다. 그 모든 것들을 예측할 수는 없지만, 연차와 병가 등을 고려하여 여유 있게 일정을 수립하는 것이 매우 중요하다.

---

 

신입인 내가 모든 리스크를 검증할 수는 없으며, 심지어 기본적인 리스크조차도 놓칠 가능성이 많다. 결국 신입에게 리스크 검증이란 '물어보는 것'이고 '공유하는 것'이다.

나는 프로젝트 중반쯤에 두 개 모두 부족하다는 사실을 깨닫고 좀 더 빠르고 적극적으로 물어보고 공유했다. 효과는 즉각적으로 나타났으며, 일처리 역시 훨씬 쉬워졌다. 하지만 초기에 놓친 리스크들은 부채가 되어 프로젝트가 끝나가는 지금까지도 영향을 미치고 있다. 초기 리스크를 잘 잡는 것은 정말정말 중요하다..!