2. 내 생에 첫 기획서 만들기 (feat. QA Driven Development)
첫번째 이야기 <1. 우리 조직의 얼굴을 만들자> 이후 두번째 이야기입니다.
1. 역할 분담하기
공적인사적모임 조직의 플랫폼을 만들기로 아이템을 정했으니, 누가 어떤 일을 할지 역할을 분담해야했다. 현재 우리 팀원들은 대략 아래와 같은 상황이었다.
플래시 : 스타트업 3년차 개발자. 비전공자. 안드로이드 개발로 시작해서 지금은 백엔드 개발 2년째. 초기 스타트업에서 0부터 1까지 만들어 1년 넘게 서비스를 운영한 경험이 있음
테츠오 : 스타트업 1년차 개발자. UI/UX 엔지니어로 일하고 있으며 디자인까지 가능.
구름모자 : SI 1년차 개발자. 컴퓨터 공학 복수전공. 현재 좋은 개발자 분들과 함께 성장하는 중. 주로 백엔드 개발을 하고 있음
먼저 각자 어떤 일을 하고 싶은지 물어봤다. 당연히 프론트 개발자는 1명밖에 없으니, 테츠오가 맡게 되었고, 백엔드 개발은 누가할지 정해야 했다. 마침 구름모자님은 현재 큰 조직에서 큰 프로젝트를 맡아서 하고 있기에, 개인적으로 0부터 1까지 만들어 런칭해보는 경험을 하고 싶어하셨다. 나는 이미 현재 조직에서 충분히 경험했으므로 구름모자님에게 백엔드 업무를 양보하고, 나는 필요할 때마다 서포트를 하기로 했다. 나는 처음부터 끝까지 혼자서 기획해본 경험이 없으므로, 이번 기회에 기획에 대해서도 많이 배울 수 있을 것이라는 생각이 들었다. 평소부터 관심이 있기도 했어서, 내가 기획을 맡기로 했다.
2. 다른 팀들은 어떻게 일하나
팀으로써 합을 맞춰보는 것이 처음이여서 우리는 각자의 회사에서는 어떤 방식으로 일하고 있는지, 다른 팀들은 어떻게 일하는지 이야기를 나눠보았고 카카오 팀의 시니어 개발자이신 테오님의 블로그에서 <figma를 이용한 더 나은 기획-디자이너-QA-개발 협업 방법> 글을 보게 되었다.
요약하자면, 기획서 따로, 디자인 파일 따로, 테스트 케이스 따로 관리되고 있어서 싱크도 안맞고 너무 채널이 많으니, 아예 피그마라는 공간에서 한번에 기획 - 디자인 - 개발 - QA 가 협업해보는 것은 어떨까? 하는 아이디어로 생겨난 협업방법이다.
처음 이 글을 읽자마자, 너무 똑똑한 방법이라고 생각했다. 당장 팀에 공유해보니 반응은 일단 성공적. 정기 회의에서 이번 프로젝트를 이렇게 일해보는 게 어떻겠냐고 의견을 제시했고, 다행히도 팀원들 모두 오케이가 되어 그렇게 진행하기로 했다.
3. QDD 방식으로 처음 작성해보는 기획서
기획 문서를 작성하기 전에, 먼저 마인드 맵으로 메뉴트리와 플로우를 정리해보았다. 마인드맵은 손쉽게 추가하거나 삭제하는 것이 가능해서 머리 속의 기획을 빠르게 정리하고 시각화하기에 유리하다.
전체적인 그림을 그렸다면, 기획문서를 작성할 차례이다. 팀원들과 약속한대로 일명 QDD(QA Driven Development) 라는 방식으로 기획서를 처음 작성해보게 되었다. 혼자서 기획 문서를 만들어보는 것도, 피그마를 써보는 것도, QDD 방식으로 화면 설명을 적는 것도 처음이었다. 하지만 개발을 하면서 익숙하지 않는 개념을 빠르게 공부해서 적용하는 것은 거의 일상적이었기 때문에 이번에도 그냥 무작정 시작했다.
피그마로 이것저것 그려보다가 모르는 부분이나 필요한 기능이 있으면 구글링을 해가면서 결국 만들고자하는 구성을 만들어냈다. 무엇보다 화면 description 을 작성하는 부분을 TDD 케이스 적듯 작성을 해야했는데, 워낙 개발을 하면서 테스트 코드를 작성하는 것에 익숙했었다보니, 이 부분은 적응하는 것에 그리 힘들지 않았다. 오히려 더 명확하게 의미를 전달할 수 있어서 쉬웠던 것 같다.
이렇게 기획서를 한번 만든 뒤에는 기존 기획된 문서를 디자인 파일로 대체해나간다. 그렇게 되면 중간에 변경사항이 생겨도 기획자는 화면 설명 부분만, 디자이너는 디자인 파일만 수정하면 되고, 기획서-디자인 간의 싱크를 맞추거나 할 필요도 적어지게 된다. 문서를 보는 주체인 개발자와 QA 는 문서상 오류가 적으니 문서 자체를 신뢰하고 작업을 진행할 수 있다.
4. 느낀점
생각보다 기획서를 작성하는 일은 힘들다.
기능의 필요성을 말했던 주체 조차도 본인이 무엇을 원하는지 명확하게 모르는 경우가 있다.
최소한의 범위를 정하는 것이 참 어려웠다. 어디까지가 최소한의 기능인가?
우리는 완벽한 팀이 아니다. 처음만난 사람들이다. 그렇기에 서로를 존중하고 배려하면서도, "좋은게 좋은거지"하면서 타협하는 방향으로 나아가지 않도록 주의해야한다. 좋은 일을 하기 위해 만났지만, 일의 퀄리티 는 좋게좋게 타협하면 안된다.
언제나 그렇듯, 답은 사용자에게 있다. 그리고 이 경우, 우리는 미래의 사용자와 이미 같은 공간에 존재한다. 적극적으로 묻고 피드백을 받자.
다시 한 번 느꼈다. 모든 의사결정의 이유는 사용자여야한다. 그들이 외면하는 순간 프로덕트로서의 존재 가치는 없어져버린다.
아직까지는 QDD 방식이 마음에 든다. 불편한 점을 못찾았다. QA 및 런칭까지 해보고 난 뒤, 이에 대한 회고는 다시 해보도록 하자.
Last updated
