기존 운영 중인 서비스가 없는 신규 앱/웹 개발 기획 예시

기존 운영 중인 asis 앱/웹이 있는 경우와 없는 경우 기획 방식은 달라져야 합니다. 기존 운영 앱/웹이 있는 경우 정책 및 기본 기능, 의도 등을 asis 분석을 통해 파악할 수 있지만 기존 운영 서비스가 없다면 그럴 수 없습니다. 이는 요구 사항을 파악하는데도 어려움을 만듭니다.

 

 

 

신규 앱/웹 서비스

 

기존 운영 중인 서비스가 없다는 의미는 신규 앱/웹 서비스 개발 상황이라는 말이 됩니다.

 

그리고 신규 앱/웹 서비스 개발을 위해서는 크게 다음 것들을 파악할 필요가 있습니다

• 앱/웹 서비스 정책
• 앱/웹 서비스 문제 해결 (제공 기능)
• 앱/웹 톤 앤 매너 (타깃 및 상호작용 포인트)

 

앱/웹을 직접 개발하는 것은 개발자가 진행한다고 해도, 무엇을 개발할지는 기획자가 정리해야 합니다. 그러나 요구 사항만으로는 단어의 표현 한계 상 이는 다소 모호할 수 있습니다. 

 

또한 레퍼런스 기반으로 이를 표현한다고 해도 이는 어떤 앱/웹인지는 쉽게 파악할 수 있지만 구체적인 앱/웹 서비스 전략과 맞지 않을 수 있습니다.

 

같은 서비스 시장의 앱/웹이라 해도 다 다르고 다양하기 때문입니다.

 

그러므로 요구 사항 정리에서는 정확한 정리를 할 필요가 있습니다.

 

 

 

요구 사항 기반 정리

 

만약 신세계나 롯데쇼핑 같이 오프라인 전문 커머스 기업이 이커머스 앱과 웹을 개발한다고 가정해 봅시다.

 

이들은 TFT를 발촉 시켜서 개발을 진행할 것입니다. 그러나 TFT는 쇼핑 서비스 전문가들이지만 온라인 쇼핑에 대해서는 모르기에 다양한 조사 작업을 할 것입니다.

 

이렇게 모은 자료를 기반으로 TFT는 요구 사항을 공유하게 됩니다. 그리고 이러한 요구 사항은 앞서 진행한 관련 시장 조사에 의한, 레퍼런스(참고 앱/웹) 기반 요구가 될 가능성이 큽니다.

 

사실 요구 사항 상세화만 잘해도 이 유형의 기획 작업의 거의 다 한 것입니다.

 

반대로 요구 사항 상세화를 잘하지 못하면 이후 진행되는 기획 작업이 혼란스러워질 것임을 의미합니다. 기획 마지막 단계인 스토리보드 작업은 그냥 유사 앱/웹 따라 화면 그리기 정도에서 그치게 될 수도 있습니다

 

asis가 없기 때문에 부실한 요구 사항 상세화를 보완할 것이 없습니다.

 

그러므로 요구 사항 상세화 작업에서 위에서 언급한 앱/웹 서비스 정책, 기능 관련 사항, 앱/웹의 디자인 및 UI 컨셉 등을 구체화할 필요가 없습니다.  

 

 

의도와 현실의 차이

 

왜 요구 사항 상세화가 더욱 중요한지 사례를 통해 정리해 보겠습니다. 그리고 기존 서비스 기반 레퍼런스 기획이 어떤 점에서 개발에 문제를 만드는지 생각해 보겠습니다.

 

과거 GS25에서 알뜰폰(선불 휴대폰)을 판매하는 것을 하려고 했습니다. 그래서 저는 이에 대한 GS25에서의 알뜰폰 가입 서비스 프로세스를 설계한 적이 있습니다.  

 

이미 GS25 담당자는 다른 알뜰폰 관련 기업들과 미팅을 한 상태였습니다. 더하여 해외 사례까지 출장을 통해 자료를 수집한 상황이었습니다.

 

그러므로 저와의 미팅은 GS25 담당자의 의도 및 진행 내용에 대한 협의 비슷하게 진행되었습니다. 일종의 요구 사항 회의 같았습니다. 그래서 그런지 미팅 이후 제안서 형태로 GS25에서의 알뜰폰(선불 휴대폰) 가입 프로세스를 정리하여 전달하게 됩니다.

 

오래된 것이라 생각나는 것 중에는 실제 스마트폰 및 피처폰을 GS25에 비치한 후 바로 개통 후 제공하자는 것이 있었습니다. 이는 해외 사례 및 국내 다른 알뜰폰 기업에서 가능하다고 한 것이라 했던 것으로 기억합니다.

 

CU와 국내 편의점 시장 1~2위를 다투고 있던 GS25에서 알뜰폰을 판매하게 되면 순식간에 수천 개의 대리점이 생기는 것입니다. 영세한 알뜰폰 사업자 입장에서는 달콤한 유혹이었으므로 가입 스마트폰/피처폰을 제공하겠다고 했을 것입니다.  

 

그러나 시장 현실은 이루어질 수 없는 약속이라는 것이 분명했습니다. 

 

선불폰을, 그것도 알뜰폰을 가입을 유치하기 위해 대부분 중고폰을 제공합니다. 이 또한 알뜰폰 업체 자본 여력 상 kg으로 구매해 분류/수리한 후 무료로 제공하는 것입니다.

 

그렇다고 GS25에서 신제품 스마트폰/피처폰 가격을 미리 매입하지는 않을 것입니다. 이점에서 좋은 의견일 수 있지만 현재 국내 유통 상황 상 불가능한 프로세스였습니다.

 

제가 있었던 알뜰폰 회사의 경우 나름 규모가 있었던 곳이었습니다. 그 당시 저는 지마켓과 협상을 통해 알뜰폰 카테고리를 독자적으로 받기로 했습니다. 단지 내부 품의를 위해 초기 수백만 원 상당의 광고를 함께 진행하기로 했습니다. 이 수백만 원이 없어 이 거래는 무산됩니다.

 

그런데 전국 GS25에 스마트폰/피처폰을 종류별로 가져다 놓는 것은 불가능한 것입니다.

 

이를 위해 가입 서류만 비치하고 전화 및 온라인으로 가입을 하면 택배로 전달 또는 해당 편의점에서 받을 수 있는 프로세스를 제안했던 것으로 기억합니다. 유심만 개통하는 경우 더 간단해집니다.

 

여기서 기획적으로 레퍼런스(기존 서비스 참고) 기획이 가지는 한계를 알 수 있습니다.

 

이 때문에 신규 앱/웹 개발의 경우 요구 사항 상세화는 더욱 자세히, 그리고 실제 개발 상황에 비추어 진행하여야 하는 것입니다.

 

각각의 기업이 가진 개발 역량과 자원은 상이하고, 활용할 수 있는 네트워크 자원도 다를 수 있습니다. 이런 이유로   레퍼런스(기존 서비스 참고)만으로 기획을 할 경우 상당한 손해를 보게 될 수 있습니다. 심지어 개발에 실패할 수도 있습니다.

 

 

 

신규 앱/웹 개발 기획    

 

요구 사항 상세화만 잘 진행되었다면 이후 기획 내용은 기존 온라인 서비스가 있는 케이스와 크게 다르지 않습니다. 단지 여기서 asis가 아닌 요구 사항 상세화만 참고하면 됩니다.

 

• 요구 사항 상세화
• 상세화 기반 기능 정리
• 상세화 기반 IA 정리
• 표준 UI 및 인터페이스(사용자와 앱/웹 간, 앱/웹 화면과 서버 간) 정리
• 기능+IA를 통해 화면 배치
• 주요 화면 구조 정리

 

asis가 없으므로 참고할 메뉴가 존재하지 않습니다. 그러므로 IA를 앞서 정리한 요구 사항의 정책, 제공 기능, 사용자 상호작용 내용을 통해 정리합니다.

 

기능 정리는 개발 관점의 프로세스가 아닌 사용자 이용 측면의 플로우 기반으로 정리하고, 이를 개발자와 구현 방법을 정리합니다. 이를 위해서는 어떤 기능인지, 어떤 사용자 문제 해결을 위한 기능인지 정확히 파악할 필요가 있습니다.

 

 이렇게 보면 일반적인 앱/웹 개발을 위한 기획과 크게 다를 것이 없을 것입니다.