.svg)
.svg)
앱 기획서는 앱 개발 프로젝트를 시작할 때 개발의 방향성을 정해주는 일종의 가이드북 역할을 합니다. 개발자들은 기획자가 작성한 기획서를 보고 기능별 상세화면을 파악하고, 각 기능들을 구성하는 작업을 하죠.
그런데 이 기획서가 부실하면 개발자의 작업이 예상한 것보다 훨씬 지연되거나, 예상하던 수준의 산출물을 낼 수 없게 됩니다. 프로젝트 일정이 딜레이 되는 것은 당연한 수순이겠죠. 즉, 기획서가 얼마나 탄탄하느냐에 따라 준비하고 계신 IT 프로젝트의 흥망이 결정됩니다.
✍️ 이 글의 순서
• 앱개발 기획서 수준별 4가지 유형
• 기획서에는 ‘모든’ 기능이 포함되어야
대부분 경험이 없는 기획자들이 처음 작성한 기획서가 이 유형에 해당합니다. 와이어프레임 안에 버튼의 위치와 포함되어야 할 텍스트만 작성되어 있는 상태인데요. 앱개발 기획서는 우리가 생각하는 것보다 기획서는 복잡한 구조를 필요로 합니다.
기획서에서 가장 중요한 것은 기능별 상세 화면 정의인데, 매 페이지마다 레이아웃을 짜놓고 각 기능들을 구성해 놓는 것을 의미합니다. 예를 들어 로그인 화면 하나에도 다양한 경우의 수가 있기 때문에 명확한 기능 정의가 있어야 하는 것이죠.
당연한 기능들은 말하지 않아도 알 수 있지 않겠냐고 생각하실 수도 있습니다. 개발자들도 기획자에게 묻지 않고 그냥 알아서 진행하는 경우도 있긴 하지만, 이 경우 기획자의 최초 의도에 맞지 않는 결과물이 도출될 수 있다는 치명적인 단점을 내포하고 있습니다.
1단계에서 약간의 설명이 포함되어 있어 조금 나은 상태입니다. 대부분 메뉴 처리 순서와 예외 처리 순서에 대한 내용을 약간 포함한 정도인데요. 그런데 각 프로세스마다 이어지는 상황에 따른 경우의 수를 전혀 고려하지 않은 케이스가 많습니다.
예를 들어 로그인을 시도했을 때 아이디를 입력하지 않은 경우, 비밀번호를 입력하지 않은 경우, 아이디에 포함된 이메일 주소를 입력하지 않은 경우, 비밀번호를 n번 이상 틀린 경우…… 등등, 조금만 생각해 봐도 수많은 경우의 수가 발생하죠.
하지만 초보 기획자들은 이런 경우의 수를 파악하지 못하고 간단한 설명으로 축약하거나 정확하게 정의하지 못합니다. 그래서 실제 구현한 후에 문제가 발생하는 일이 비일비재하게 벌어집니다.
3단계의 기획서에는 그럴 듯한 프로세스에 대한 설명이 첨부되어 있습니다. 대부분의 앱개발 업체는 이 정도의 기획서를 받고 개발을 시작합니다. 하지만 이 지점에서 개발자와 기획자의 입장 차이를 이해할 필요가 있습니다. 개발자의 입장에서는 3단계가 사실은 1단계 기획서처럼 보일 수 있습니다.
그럼에도 불구하고, 최소한의 서술이 있기 때문에 경험이 많거나 실력있는 개발자들은 필요한 추가 정보를 기획자에게 묻고 기획자의 의도가 반영된 결과물을 완성해 갑니다. 반대로 경험이 부족하거나 수동적인 개발자라면 의견을 묻지 않고 개발해 향후 작고 큰 수정, 보완 작업을 지연되는 상황이 발생되곤 합니다.
최종적으로 원활한 앱개발 프로젝트를 만드는 기획서는, 프로세스에 대한 설명은 기본이고 기획자의 의도가 명확하게 드러나는 문서입니다. 기획자의 의도가 내포된 기획서는 개발자가 어떤 방향으로 개발해야 하는지 명확하게 정의해 줍니다. 설령 프로세스에 대해 조금 더 설명 보충이 필요하더라도, 기획자의 의도에 맞는 방향으로 수정할 수 있도록 질의하겠죠.
물론 기획자는 프로그래밍 지식이 없기 때문에 기획서를 완벽하게 구현하는 데에 한계가 있을 수 있습니다. 그래서 글로 표현하기 어려운 부분은 반드시 이미지 또는 손그림으로 시각화해 직관적으로 전달해야 합니다. 좋은 기획서는 화려한 스킬과 디자인보다 모든 참여인원이 같은 결과물을 상상하고 움직이게 만들 때 그 효용이 높아집니다.
한 가지 덧붙이고 싶은 건, 앱개발 업체도 클라이언트가(비전문가가) 작성한 기획서가 반드시 완벽하다고 생각하지 않는다는 점입니다. 그렇기에 부담을 내려놓고 머릿속의 계획을 오해 없이 제대로 전달한다는 일념으로 차분히 작성해도 좋습니다. 중요한 건 내의 의도를 개발자가 잘 이해하도록 돕는 것임을 잊지 마세요.
앱개발 업체와 협업 프로젝트에서는 종종 클라이언트가 ‘당연한 기능’이 포함되지 않았음을 지적(?) 하는 경우도 보입니다. 커뮤니티 앱을 예로 들자면, 클라이언트 입장에서는 ‘공유’ 기능은 당연히 들어간다고 여길 수 있습니다. 그래서 기획서에서는 별도의 언급을 하지 않을 수 있죠.
문제는 개발하는 입장에서는 ‘기획서’대로 개발한다는 점입니다. 반대로 생각하면, 기획서를 무시한 채 개발하는 것도 앞뒤가 맞지 않는 일입니다. 이런 문제는 대개 마지막 QA 과정에서 드러납니다. 앱개발 프로젝트에서의 분쟁은 이런 사소한 불씨, 경험과 소통의 부재에서 기인하는 케이스들이 상당히 많습니다.
손해는 클라이언트 측이 막심합니다. 책임 소재를 가리다가 계획된 일정이 하염없이 늘어날 수 있습니다. 기능 추가에 드는 소요 비용 역시 물리적 손해입니다. 완료 단계의 앱은 추가 자체가 쉽지 않을 수도 있습니다. 경우에 따라 짜여진 코드 구조 전체를 살펴 고쳐야 하기도 합니다. 사실상 새로운 앱을 만드는 것과 같은 수준의 공수가 들어갈 수도 있죠.
이 같은 불상사를 예방하기 위해서는 사전 기획 단계에서 ‘필수 기능’이 무엇인지 정의하는 과정을 거쳐야 합니다. 정의된 필수 기능은 반드시 모두 기획서에 담겨야 합니다. 필수 기능에 무엇을 담아야 할지 잘 모르겠다면, 레퍼런스로 삼았던 서비스나 앱에서 힌트를 찾아 기록하는 것도 하나의 방법입니다.
완성도 높은 앱은 완성도 높은 기획으로 시작됩니다. 하지만, 경험이 부족한 상태에서 완성도 높은 기획은 부담스러울 수밖에 없습니다. 그렇다면 어려분의 구상, 여러분의 프로젝트를 위시켓에 공유하는 게 좋은 대안입니다.
국내 1위 IT 아웃소싱 플랫폼 위시켓은 ‘앱개발 외주 업체를 찾는 클라이언트’와 ‘개발사’의 매칭을 넘어, 시작부터 클라이언트의 다양한 고민과 어려움을 지원해 드리고 있습니다. 1:1로 배정된 전담 매니저가 기획서 작성부터 업체 모집, 견적 비교(적정성 검토), 계약서 법률 검토까지 진행의 전 과정을 가이드해 드립니다.
아래 링크를 눌러 진행 중인 수많은 프로젝트를 직접 확인해 보세요.
🔖 함께 보면 도움되는 글
.svg)
