킥오프 미팅과 요구사항 명세서 고도화
개발 주제를 정하고 요구사항 명세서 초안을 작성한 뒤에는
본격적인 개발에 들어가기 전에 팀의 공통 기준을 맞추는 과정이 필요했다.
같은 문서를 보고 있어도 각자 떠올리는 화면과 기능의 범위가 다를 수 있기 때문이다.
그래서 킥오프 미팅에서는 프로젝트의 방향성과 요구사항을 더 구체적으로 정리하는 작업을 진행했다.
킥오프 미팅은 왜 하는걸까?
개발을 시작한 이후에 각 팀원마다 기능에 대한 해석이 달라지면,
구현에 대한 비용보다 중간중간 생각을 정렬하는 비용이 더 커지기 때문이다.
특히 짧은 기간의 팀 프로젝트에서는 처음부터 완벽한 문서를 만드는 것보다,
처음부터 팀이 같은 그림을 보도록 만드는 것이 더 중요하다.
프로젝트의 기준점 만들기
가장 먼저 정리한 것은 이 프로젝트가 어떤 서비스인지 한 문장으로 설명할 수 있는 기준이었다.
프로젝트를 진행하다 보면 기능 단위의 논의에 집중한 나머지
처음에 왜 이 서비스를 만들기로 했는지 흐려지는 경우가 많다.
그래서 요구사항을 세부화하기 전에,
팀이 동일한 기준으로 판단할 수 있도록 아래와 같은 항목을 먼저 정리했다.
- 서비스가 해결하려는 문제
- 사용대상
- 핵심 기능
이 과정을 통해 우선순위를 정하는 기준이 생겼다.
예를 들어 어떤 기능을 넣을지 고민될 때도
'이 기능이 우리 서비스의 핵심 경험과 맞는가?'를 기준으로 판단할 수 있었다.
요구사항을 기능 단위로 구체화하기
초안 단계의 요구사항 명세서는 서비스에 어떤 기능이 필요한지를 정리하는 수준에 가까웠다.
하지만 실제로 개발을 진행하려면 각 기능이 어떤 흐름으로 동작하는지,
어떤 화면이 필요하고 어떤 입력과 결과가 오가는지를 더 구체적으로 정의해야 했다.
그래서 킥오프 미팅에서는 요구사항 명세서를 기반으로 기능 단위를 다시 나누고,
각 기능을 팀원별로 하나씩 맡아 구체화하기로 했다.
위와 같이 화면단위가 아닌, 도메인 단위로 핵심 기능들을 나열하고
각 팀원이 한가지씩 기능을 맡아 와이어프레임을 그려오기로 약속했다.
와이어프레임 작업을 하다보면, 다른 기능과 연계된 화면들이 있을텐데,
해당 부분은 관련있는 기능을 맡은 팀원끼리 유기적으로 소통하여 작업해보기로 했다.
와이어프레임 취합 후 스토리보드까지 작업한 과정 보러가기
프로젝트 포지션 나누기
요구사항 명세서에서 정리된 핵심 기능을 바탕으로, 프론트와 백엔드를 3:3으로 나누었다.
역할을 프론트와 백엔드로 명확하게 분리하여 작업을 하자는 의견이 있었었기 때문에
본인은 풀스택으로 지원하였지만, 팀원들의 의견을 따르기로 했다.
프론트 인원이 부족하여 프론트를 맡게되었고,
이번 프로젝트에서 디자인 시스템을 적용해보기로 결심했다.
기획자로 일 할 땐 개발팀이 디자인시스템을 편하게 적용할 수 있도록 서포트만 해주고 끝났었는데,
이번에는 나와 팀원들이 사용할 디자인 시스템을 만들 수 있다는 사실이 설레었다.
디자인 시스템 셋팅은 시간이 좀 걸리는 작업이지만,
초반에 해두면 추후에 UI쪽 QA에는 거의 시간을 투입하지 않아도 될 것이다.
하지만 해당 작업에 많은 시간을 사용할 수 없기에 이에 익숙한 본인이 빠르게 셋팅을 할 예정이다.
기능 구현을 위한 로드맵 수립하기
현재는 기능을 상세하게 정의한 것이 아니기 때문에, Day 단위의 로드맵을 작성할 순 없었다.
때문에 마일스톤을 잡아서 대략적인 로드맵만 논의하였다.
마일스톤은 크게 4가지로 나누었다.
- 프로젝트 사전 준비
- 기능 구현
- QA / 배포
- 발표 준비
전 직장에서 1주에 앱 1개씩 배포하는 사내 사이드 프로젝트를 진행했을 때,
생각보다 3번에 많은 시간이 소요되었었다.
현재 진행하는 프로젝트는 손발을 맞춰야하는 팀원들이고,
스케일과 github 협업 측면에서 처음인 팀원들이 있기 때문에
3번에 대한 기간을 최소 1주 정도는 확보하자고 제안했다.
또, 기획이 탄탄해야 프로젝트의 방향성을 잃지 않고
개발 기간에 개발에만 집중할 수 있기에 1번에 대한 기간도 1주를 확보하기로 했다.
