점진적 개발 방법은 정말 효과적인가?
서비스를 개발할 때 사용할 수 있는 많은 방법론이 있습니다. 특히, 변화의 속도와 대응이 중요한 현대의 모바일 서비스를 개발하는데 있어 방법론은 매우 중요한 요소입니다. 빠르게 컨셉을 실험하고 최소한의 가치있는 기능을 포함하여 서비스를 배포하는 것은 서비스 성공과 실패에 매우 큰 영향을 주게됩니다. 이 글에선 단기간에 점진적 개발 방법을 활용하여 모바일 서비스를 개발한 경험을 공유합니다.
페르소나
서비스 컨셉이 결정되었다면 페르소나(Persona)를 정의하는 일이 첫번째 입니다. 프로젝트 멤버들과 페르소나를 만들고 합의하는 것은 매우 중요합니다. 모든 아이디어는 페르소나에서 출발하고 페르소나를 통해 검증해야하기 때문입니다. 한 팀의 규모가 적은 것을 선호하는 최근의 경향은 페르소나를 멤버 전원이 동일한 수준으로 이해할 수 있는 확률이 높기 때문 아닐까? 라고 생각하고 있습니다. 멤버간에 페르소나를 이해하는 격차가 크면 클 수록 최종 결과물의 완성도는 떨어질 수 밖에 없습니다. 아래에서 이야기하게될 사용자 컨텍스트와 관련하여 페르소나는 절대적인 영향을 미칩니다. 프로젝트 진행 중에 회고를 한다면 진행된 내용과 페르소나의 정합성을 평가하는 방법을 추천합니다.
아이디어의 참신함을 유지하기 위한 노력
하나의 서비스를 실현하기위해 많은 아이디어가 필요합니다. 각각의 아이디어는 모호하지만 참신한 형태로 시작하여 여러 사람의 관점에서 다듬어지게 마련입니다. 다듬에 지는 과정에 운 나쁜 경우 초기의 참신함은 사라져 버릴 수 있습니다. 운 나쁜 경우라 했지만 사실 실무에선 이상하게도 운 나쁜 경우가 너무 많았습니다. 참신함이 사라지는 원인은 여러가지가 있을 수 있지만 저의 경험으론 머리속의 생각을 “시각화 할 때” 가장 많은 것을 잃어버렸던 것 같습니다.
시각화할 때 참신함을 최대한 유지할 수 있는 방법이 있을까요? 공상과 같이 아이디어를 형상화 하는 것 만큼 자유로울 수는 없겠지만 그와 비슷할 정도로 유연한 도구가 있다면 가능하지 않을까요? 그래서 저희는 핸드 스케치를 선택했습니다. 스케치는 그림 실력이 형편없는 사람일지라도 충분히 활용할 수 있다는 장점이 있습니다. 네모와 동그라미만 그릴 수 있다면 오케이입니다. 오히려 그림 실력이 뛰어난 사람의 스케치는 본질이 훼손될 수 있어 위험합니다. 스케치를 할 때 가능하면 이쁘게 그리지 않는것이 좋습니다. 스케치의 목적은 아이디어의 참신함을 최대한 유지하며 함께 개발할 멤버들과 커뮤니케이션하기 위해서입니다. 그림 실력을 뽑낼 기회는 다른곳에서 찾는게 좋습니다.
아이디어 스케치가 빠르게 그려지면 세 가지 작업이 동시에 진행됩니다.
- 디자인
- 앱 프로토타입
- 프로토타입용 API
어떤 경우 3번은 없을 수 도 있습니다. 애니메이션 등의 인터렉션 요소가 강한 아이디어라면 2번의 네이티브앱 구현보단 다른 방법을 활용하는 것이 좋습니다. 예를 들면 플래쉬나 웹앱 같은 도구는 네이티브앱 개발보다 빠르고 효과적으로 결과물을 검증할 수 있습니다. 도구에 집착하지 말아야합니다. 최종 버전의 플랫폼은 정해져있지만 모든 아이디어를 최종 결과물로 만드는 것은 지불해야할 비용이 너무 크고 프로젝트를 위험에 빠드릴 수 있습니다.
디자인 또한 과도한 디테일에 집착하지 않아야합니다. 어차피 끊임없이 변화해야하고 수정은 가장 중요하고 빈번한 일이기 때문입니다. 작고 어설프게 시작하여 크고, 디테일을 높이는 방식은 모든 파트에 동일하게 적용됩니다. 여기서 항상 생각해야하는 점은 초기 아이디어의 참신함을 잃지 않는 것입니다.
나무가 많아지면 숲이 되는 법
아이디어 스케치가 하나 하나 많아지고 연결되기 시작하면 컨텍스트가 중요해 집니다. 컨텍스트는 실제 앱을 사용하는 사용자의 환경에 따라 매우 다르게 작동될 수 있다는 것을 생각해야합니다. 너무나 다양한 컨텍스트에 모두 논리적으로 합당한 흐름을 제공하는 것은 불가능할지 모르겠습니다. 이 불가능한 목표를 이루기위한 첫 번째 방법은 모든 화면을 한눈에 볼 수 있도록 하는 것입니다. 바로 숲을 볼 수 있는 방법을 만들어야합니다.
모든 화면을 인쇄하든, 가위로 잘라 붙이든, 어떤 방법을 사용해도 좋습니다. 하나의 캔버스위에 모두 올려놓고 볼수 있다면 말이죠.
지금까지 얘기했던 방법들을 끊임없이 반복하여 점진적으로 서비스를 만들었고 지금도 진행중입니다. 반복하는 중간 중간 CBT 이벤트가 있었고, OBT 이벤트가 있었습니다. 많은 전문가들이 조언한 “최대한 빠르게 최초의 사용자의 피드백을 수집하라” 는 서비스를 제대로 만들기위해 가장 확실한 방법이고 서비스 페르소나를 검증하기 위한 유일한 길임에 틀림없습니다.
빠진 것들
- 파워포인트를 사용하지 않습니다.
저희팀은 일반적으로 많이 사용하는 도구인 파워포인트를 사용하지 않습니다. 스토리 보드는 앞서 얘기한 스캐치한 종이를 오려 커다란 보드위에 붙여 완성해 나갑니다. 디지털화된 제품을 만들지만 때론 아날로그적인 도구들이 훨씬 효과적일때가 많습니다. - 위키보단 구글 문서도구를 활용합니다.
언제 어디서나 협업이 가능한 웹 기반의 클라우드 문서 도구인 구글 드라이브를 사용합니다. 아날로그적인 데이타와 디지털적인 결과물을 효과적으로 결합할 수 있는 유연성을 제공합니다. 최종 완성본에 대한 문서는 위키를 사용하기도 합니다. 그러나 태생적인 한계로 협업이 불편한 위키는 지속적으로 수정되어야할 문서인 경우 사용을 지양하고 있습니다. - 보고서를 작성하지 않습니다.
일 단위, 주 단위, 월 단위의 흔한 보고서를 작성하지 않습니다. 매일 아침 짧은 데일리 미팅을 Trello 보드에 기록하고 이터레이션 계획 문서를 주단위로 업데이트 합니다. 보고가 필요한 경우 해당 시점의 결과물로 커뮤니케이션 합니다. 가장 선명한 의사소통 방법이기 때문입니다.
