기획의 충돌부터 고객을 만나 지금의 워크플로우를 가지기까지.
"우리 회사의 MVC엔 애자일이 포함되어 있어, 그러니 우리도 애자일 해야 해"
오전 조직 미팅을 진행하며 들었던 이야기다. 생전 처음 하는 사회생활, 그리고 처음 해보는 PO 업무를 담당하면서 끊임없이 듣던 단어, 애자일. 애자일은 도대체 뭘까?
(다들 그럴싸한 기획을 가지고 있다. 고객을 만나기 전까진)
과거 개발팀이 PO를 맡던 친구와 의견대립이 생긴 시절이 있었다. 만들어야 할 기능의 기획이 완벽하지 않다는 것이었다. 그 시절 모델 디자인을 맡고 있던 나도 어느 정도 동의하던 부분이었다. 그 시절 받아오던 기획의 내용은 세밀하지 못했고, 무엇을 만들어야 할지 명확하지 못했다. 그러므로 평소 기획에 대해 불만이 많았고, 기능은 완벽하지 못해 작동되지 못했으며, PO는 PO대로 개발이 느리다며 어려움을 겪었다.
이런저런 일이 있고 나서 내가 PO라는 직책을 맡게 되었을 때, 기존 디자인하며, 그리고 개발팀의 고충을 참고하여 기획에 정말 많은 시간을 투자했다. 덕분에 PRD 작성도 배우게 되었으며, 그 내용 또한 어마어마해졌다. 개발팀과는 태스크 분배 전 PRD 문서를 함께 피드백하며 기술적으로 문제가 없는지 확인했으며, 추가로 보충해야 할 부분 또한 수정해 나가며 작성했다. 이젠 우리 모두 무엇을 만들고, 어떤 기능이 어떻게 만들어야 하는지 알게 되었다. 여기 까진 괜찮았다.
하지만, 가장 중요한 부분을 놓치고 있었다. 문제는 제품 인터뷰가 시작되면서부터였다.
정성 들여 만들어진 A 기능이 고객으로선 크게 와닿지 않았다. 개발팀도 당황했고 나도 당황했다.
그동안 열심히 작성했던 PRD 가 한 줌의 재로 돌아간 기분이었다. A 기능이 필요하지 않을 거라곤 한 번도 생각해보지 못했다. 그렇지만 고객들의 반응은 다르다. 그리고 그들은 시장을 대변한다. 모든 PRD 문서에 의심을 품게 되었다.
"우리 회사의 MVC엔 애자 일이 포함되어 있어, 그러니 우리도 애자 일 해야 해"
나는 자리로 돌아와 구글링을 시작했다.
요약하자면, 기존의 거대하고 세밀한 기획에서부터 시작되는 워터폴(waterfall) 방법과 다르게, 고객과 시장의 요구에 맞춰 긴밀하게 제품을 만들어 나갈 수 있는 방법을 칭한다.
(물론 그대로 사용되는 회사는 감히 없을 거라 생각한다. 당장 내 회사 또한 빨리 해 그 이상 그 이하도 아닌 것처럼 사용되고 있었으니까...)
이를 위해 애자일은 4가지 선언문을 가지고 있는데,
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
라고 하더라. 하나하나 주옥같은 선언이었다. 열정과 파이팅이 전부인 스타트업 팀원들에겐 아주 작지만 작동되는 기능을 완성하는 건 큰 동기부여가 되며, 끊임없이 고객과 협력을 통해 제품을 개선해 나가야 되고, 이에 따라 수시로 변화하는 고객과 시장의 요구에 대응할 수 있어야 한다.
곰곰이 생각해 보니 내가 구축한 워크플로우는 애자일보단 워터폴에 더욱 가까웠고, 그다지 효율적이지 않았다는 생각이 들었다.
어떻게 하면 현 워크플로우를 좀 더 유연하게, 더 나아가 애자일 하게 만들 수 있을까?
그렇게 애자일 프레임워크를 찾기 시작했다.
--계속--