소개
일반인들도 전문적으로 설문을 운영할 수 있다!
편리하게 설문을 기획하고, 응답현황을 관리하고 응답결과를 시각화할 수 있는 서비스입니다.
타겟 유저층은 아래와 같습니다.
- 세미나/모임 관련 설문조사를 진행하려는 대학생/일반인
- 구상 아이템에 대한 수요조사를 사전에 진행해보려는 예비 창업자
진행 내용
1) 주제 선정
- 아이디어 회의 진행
 |  |
|---|
아이디어 주제 선정 및 주요 기능 논의, 각자 주제를 가져와서 투표를 진행했다. 괜찮은 주제가 많이 나왔었기 때문에 각자의 우선순위를 논의해봤다. 결국 취업을 위한 포트폴리오를 만드는 것이 공동의 목표였기 때문에 기업이 선호할만한 컨텐츠를 우선시하기로 했다. 결론적으로 관리자 페이지가 있고, 시각화 기능이 들어갈 수 있는 ‘설문조사 플랫폼’ 을 최종 주제로 선정했다. 아이디어를 확정한 김에 함께 기본적인 기능을 브레인스토밍해봤다. 나머지 데이터 시각화 부문은 내가 아이디어를 낸 부분이 있어서, 추후 나 혼자서 디벨롭을 진행하기로 했다.
2) 리서치/분석
- 설문 어플 분석 및 브레인스토밍
UI는 모바일 first로 협의됐다. 시중에 출시되어있는 설문 어플과 그 외 세부기능들을 구현하기 위한 연관 어플들을 하나하나 분석해보며 개선점을 도출하고 마인드맵 작성을 진행했다.
나만의 아이디어 뿐 아니라 google form을 활용한 실제 유저들의 의견들을 조금 더 살폈어야 했다. 너무 실무자의 관점에서 인사이트를 얻어갔던 것 같다. 페르소나를 조금 더 다양하게 가져갔다면 좋았을 것임. 또한 마인드맵으로부터 핵심기능을 다시한번 정의했어야했다고 생각한다.
3) 요구사항 정의
- 목표(우선순위 설정)
- 주요 사용자 정의
1) CRUD 및 시각화를 최우선 순위로 협의했다. 그외 사용자 경험을 위한 부가기능, 스타일링 등은 차순위로 미루어 우선순위를 설정했다. 2) 본 프로젝트에 Google Form 서비스와 차별화되는 지점이 필요했기에 타겟층을 정의하고자 했다. 본 서비스가 모바일 first라는 점에서 편의성, 그리고 동시에 로직커스텀이 가능하다는 점에서 약간의 전문성까지 겸비했다는 점을 고려하고자 했다. 이전 본인의 경험을 되돌아 보았을 때, 세미나/모임을 기획하고자할 때 본 서비스가 최적일 것이라 판단하였다.
4) 기획문서 작성
- 와이어프레임작성
- 스토리보드 및 기능명세서
- 작업프로세스 정의
 |
|---|
 |  |
|---|
1) 여러 레퍼런스를 참고해가며 드로잉부터 시작했다. 전체적인 레이아웃을 정의하고 그림 옆에 들어가야할 데이터, 모션 등을 명시해놓았다. 2) 스토리보드는 페이지 단위로 제작하였다. 자잘한 모달창 등은 기능명세서에서 명시해주는 식으로 작업하여 공수를 줄였다. 스토리보드를 만들면서 구현이 어려울 것으로 예상되는 부분은 개발담당자와 논의하며 진행해갔다. 그러다보니 초기 마인드맵/와이어프레임과는 다소 다른 양상으로 스토리보드 구축이 진행되었다. 3) 기능명세서를 기준으로 작업을 단위화시키고 프로세스를 정의해보았다. 오류 등 예외상황을 최소화하고 일정을 예측할 수 있도록 업무를 단계화시켰다.
내 생각에 개발자들과 소통하기 위해 기능명세서는 대충 작성하고, 백로그까지 디벨롭했어야했었다. 기능명세서 정리에 너무 치우쳐진 느낌. 그래야 각 업무의 난이도를 어느정도 직감하고 제대로된 일정 조율 및 기능협의가 가능했을 듯하다.
5) 개발자 리뷰
 |  |
|---|
DB 회의를 진행하며 동시에 구현가능성을 검토하였다. 이번 기능협의에 있어서, 내 의견이 너무 배재된 감이 있었다. 팀의 우선순위에 덧붙여 본 프로젝트를 통한 ‘나’의 우선순위도 지정할 필요가 있었다. 허나 나 역시 개발에 투입되는 입장이고, 다들 취준생인 상황에서 작업소요시간을 예측할 수 없었기에 쉽사리 의견을 관철시키지 못한 이유가 있었다고 생각한다.
전체 회고 및 의문점
당시 기획에 대해 아무것도 모른 상태로 무작정 시작했던만큼, 지금보면 아쉬운 점들이 많다. 이번 프로젝트에는 무엇보다 일정을 예측하고 계획을 수립하는데 가장 큰 어려움이 있었다. 이러한 확신이 없다보니 일정세팅이 제대로 이루어지지 않았다. 이렇게된 이유로는 필수기능(백로그)이 사전에 정의되지 않은 탓이 크다고 생각한다. 또한 초반에 작성한 문서를 남들에게 이해할 수 있도록 설명하지 못한 이유도 있다고 생각한다. 그리고 한가지 아쉬웠던 점은, 너무 욕심부려서 기획을 진행했다는 점이다. 물론 추후 개발담당자와 논의 후 많은 수정을 거쳤지만 초반 기획이 너무 빡셌던 만큼 고생을 많이 한 것 같다. 일단 공동의 KPI를 제대로 정하지 않은 문제가 있었다. 모호하게 ‘취업용 포트폴리오를 만들기 위해서’로 짚고 넘어가니, 레퍼런스를 선택하거나 스토리보드를 작성할 때, 구현가능성에 대해 고려하지 않게 되었던 것 같다. 예를들어 ‘Google Play 다운로드 수 100 달성’ 과 같은 구체적인 KPI를 설정하면 좋았을 것이다.
그런데 정말 궁금한 것이, 기획자들은 대체 WBS를 어떻게 작성하는 걸까? 일정을 미리 예상한다는게 가능한걸까? 그리고 작성된 WBS가 현업에서 얼마나 효력을 갖을지도 궁금하다. 실제 개발하다보면 데드라인에서 벗어나는 경우가 종종 있을 것 같다. 이럴 때 어떻게 대처할 지도 정말 궁금하다. 그리고 기능명세서가 정의되기 전에 WBS가 대체 어떻게 나올 수 있는 건지도 궁금하다. 세부 기능들이 모두 정의되어야 백로그라던지하는 것들이 나올 수 있는게 아닌가?
