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

기존 운영 중인 앱/웹 서비스가 있는 상황에서 개발이 이루어지는 경우에는 사용자 입장에서 어떤 상황이라도 기존 서비스를 바탕으로 개발되어 릴리즈 되는 앱 또는 웹을 인식하게 됩니다. 사용자 입장에서는 패치이든 새로운 버전이든 개발 범위와 상황과 상관없는 해당 앱/웹 인식의 문제이라는 점을 기획 시 고려해야 합니다. 

 

 

 

ASIS, TOBE

 

기존 운영하고 있는 앱/웹을 ASIS, 개발하려는 앱/웹을 TOBE라 합니다.

 

일반적으로 ASIS, TOBE라 기획 시 부르는 이유는 이 둘이 사용자를 매개로 이어지기 때문입니다. 이 개념은 앱/웹 기획의 중심이 되어야 합니다.

 

그러므로 기획의 시작은 ASIS의 파악이 됩니다.

 

 

 

ASIS 분석

 

ASIS 분석은 기존 앱/웹을 파악하는 작업을 의미합니다. 이 파악은 매우 간단합니다. 이미 앱/웹이 서비스 중이기 때문입니다.

 

운영 중인 서비스 정책, 메뉴, 화면을 파악하면 됩니다. 이에 대한 내용을 간단히 정리해 보겠습니다. 분명 해당 앱/웹 프로젝트에 따라 특수한 상황이 있을 것입니다. 이는 그때그때 적절히 대응하면 됩니다.

 

 

앱/웹 서비스 정책 파악  

 

서비스 정책은 외부에 공개된 것도 있고 공개되지 않은 것도 있으므로 서비스 운영자 또는 고객 기업 담당자 인터뷰를 통해 파악합니다.

 

앱/웹 서비스 정책 시 같이 파악해야 하는 것으로 상품 및 콘텐츠 관련 프로세스입니다. 

 

예를 들어 상품이라면 해당 상품의 판매와 관련한 진행 단계 및 정보와 관련한 사항의 흐름을 파악해야 합니다. 쇼핑몰에서 구매하는 일반 상품의 경우 간단할 수 있지만, 금융 상품의 경우 복잡할 수도 있습니다. 또한 일반 상품이라도 거래/재고/배송 정책에 따라 연동되는 시스템 인터페이스는 규칙 등이 있을 수 있습니다.

 

이러한 내용의 파악은 이후 진행되는 ASIS 화면 흐름 및 내용을 파악하는데 도움이 됩니다. 이 말은 정책 파악을 하지 않고 바로 화면 분석에 들어가면 앱/웹 플랫폼 규모에 따라 상당히 어려움을 겪을 수 있음을 의미합니다.

 

• 앱/웹 서비스 정책 파악 (사용자, 운영, 화면 정책 등을 포함)
• 상품 정책 파악 (상품 종류, 판매/가입 프로세스, 저장 데이터 등)
• 시스템 인터페이스 정책 파악 (연동 시스템이 있는 경우)

 

 

ASIS 화면 분석

 

ASIS 앱/웹 화면을 분석하는 단계입니다. 화면 분석은 간단합니다. 기존 운영 중인 앱/웹의 메뉴를 중심으로 제공 중인 모든 화면을 도출하여 파악하면 됩니다.

 

앱/웹은 일반적으로 노출되는 화면이 있을 수 있고, 사용자가 특정 상품을 구매하거나 하는 특수한 상황에서 노출되는 화면이 있을 수 있습니다.

 

이러한 화면을 파악하고 정리하는데 앞서 진행한 앱/웹 서비스 정책 파악이 도움이 됩니다. 반대로 앱/웹 서비스 정책 파악 없이 ASIS 앱/웹 화면 분석을 할 경우 놓치는 화면이 나올 수도 있다는 말이 됩니다.

 

실제 다양하고 복잡한 상품을 판매하는 경우, 금융 상품과 같이 상품에 따라 정보나 동의를 받아야 하는 경우 이러한 화면이 있을 수 있고, 보안이라는 이름으로 이를 파악하는데 난관이 있을 수 있습니다.

 

실무 기획에서 보면 이런 부실함은 TOBE 기획 시 어려움으로 작용합니다.

 

• 메뉴 분석 (서비스 중인 앱/웹의 메뉴) 
• 메뉴에 따른 앱/웹 화면 파악 (서비스 중인 앱/웹의 모든 화면)
• 화면 구성과 내용 파악 (개발 화면 기능과 UI)

 

종종 기획자들이 ASIS 화면 분석을 기존 화면을 캡처하고 일반적인 UI 설명을 붙이는 것으로 이해하는 경우가 있습니다., 이렇게 하면 TOBE 기획 시 상당한 어려움을 겪게 될 것입니다. 시스템이 복잡할수록 더 어려움을 겪을 것입니다. 그냥 ASIS 화면 분석을 하지 않은 상태와 같은 상황을 맞이할 것입니다.

 

TOBE 기획을 위한 ASIS 화면 분석은 해당 앱/웹의 UI 작동 및 인터페이스 등 컴포넌트 정의, 화면 노출/구성 정책 등 아주 세부적으로 이루어져야 합니다.

 

심지어 신입 기획 사원 고육 시 진행되는 역기획에서도 단순 화면 캡처는 하지 않습니다. 단순 화면 캡처 및 누구나 직관적으로 아는 UI 설명은 역기획 후 개발이 불가능하기 때문입니다. 

 

ASIS 화면 분석은 이를 기획서 삼아 ASIS 앱/웹을 똑같이 개발 가능할 수준으로 작성되어야 합니다.

 

 

 

TOBE 기획

 

TOBE는 기존 서비스 중인 앱/웹의 수정, 보완, 추가, 삭제하려는 내용이 반영된 앞으로 서비스될 앱/웹을 의미합니다. 이런 TOBE에서 중요한 것은 ASIS의 사용자 연속성을 유지하면서 더 나은 사용자 경험/UX를 제공할 수 있어야 한다는 점입니다.

 

이러한 부분은 서비스 기획자 또는 고객의 요구 사항에 들어 있습니다.

 

그러므로 TOBE 기획의 시작은 ASIS 파악과 함께 서비즈 기획자 의도 또는 고객의 요구 사항을 정확히 파악하는 것이 됩니다. ASIS 파악은 시작과 연속성의 기준이 되며, 서비스 기획자 의도 또는 고객 요구 사항은 TOBE 지향점이 됩니다.   

  

ASIS 파악과 요구 사항 분석이 잘 되어 있다면 TOBE 기획은 간단합니다.

 

그렇다고 TOBE 기획을 위해 투입된 모든 기획자가 ASIS 파악과 요구 사항 분석을 할 필요는 없습니다. 이는 상당히 비효율적이며, 해당 분석에 역량이 부족한 기획자가 작업한 부분은 TOBE 기획에 활용하기 어려운 수준의 결과물이 나올 것입니다.

 

프로젝트 규모에 따라 ASIS 파악과 요구 사항 분석은 생각보다 어려운 작업이 될 수 있습니다. 그러므로 분석/설계 전문 기획자를 투입하는 것이 좋습니다.

 

여기서 말하는 분석./설계와 화면 설계를 혼동하는 기획자도 있는데 이는 완전히 다른 기획 영역이라는 점을 인식하고 ASIS 파악과 요구 사항 분석에 적절한 기획자를 투입하여 설계서를 작성하는 것이 TOBE 기획을 쉽게 하는 것이라는 점을 명심해야 합니다.

 

이는 마치 기초가 잘못된 고층 건물은 저층을 공사할 때는 문제없어 보이지만 고층을 작업할 때 건물이 흔들리고 심하면 무너질 수 있는 것과 같습니다. 

 

ASIS 파악과 요구 사항 분석이 잘 되어있지 않아도 TOBE 기획 초기에는 문제가 나타나지 않습니다. 그러나 기획이 진행될수록 막히는 부분도 생기고, 다시 작업하는 부분도 많아질 것입니다.  TOBE 기획이 거의 끝나갈 때쯤이면 개발자, 디자이너가 이 기획서로 작업한 내용은 서비스 기획자나 고객의 의도와 다르다는 것을 파악하게 될 수도 있습니다. 아니면 그전에 개발자가 무엇을 개발하라는 것인지 기획서로 파악하지 못할 수도 있습니다.

 

ASIS 파악과 요구 사항 분석을 잘해 놓아야 한다는 것은 기획적으로 의미가 큽니다. TOBE IA는 ASIS IA와 비교하여 작성하면 쉽습니다. TOBE 화면 목록 또한 ASIS 화면 목록을 바탕으로 빼고, 넣고, 이동하고, 수정/보완하고 등을 정리하면 쉽습니다.

 

ASIS에서 TOBE로 기획을 진행하면 쉬운 이유는 앱/웹 서비스의 연속성 때문입니다. 단 필수 조건은 ASIS 파악과 요구 사항 분석이 잘되어 있다는 것입니다.

 

• TOBE IA 작성 ( 서비스 기획자 또는 고객 요구에 따라 작성)
• TOBE 화면 목록 (개발될 앱/웹의 전체 화면 목록)
• 스토리보드/화면 설계서 (IA와 화면 목록의 내용 반영)

  

 

ASIS에서 TOBE로의 기획에 문제가 생기는 이유

 

지금까지 정리한 내용들을 자세히 보면 기획 프로세스를 말하고 있다는 것을 알 수 있습니다. 이렇게 단계별 작업 흐름에 따라 기획을 하는 이유가 있습니다. 

 

어떤 제품이나 프로그램도 하나의 공정만으로 완성되는 것은 없습니다. 기획 또한 한 공정만으로 완성될 수 없습니다.

 

그러나 경험이 없거나 기획 자체 해보지 않은 경우 최종 결과물을 주로 보기에 한 공정만으로 앱/웹 기획이 완성된다고 생각하고 그렇게 행동합니다.

 

거의 모든 사람들 손에 들여 있는 스마트폰을 개발하기 위해서는 여러 공정이 필요합니다. 그러나 대부분을 차지하는 스마트폰 사용자 관점에서는 그냥 스마트폰을 조립하면 될 것처럼 보일 수 있습니다. 

 

그래서 스마트폰 부품을 구매해서 조립하기만 한다고 스마트폰이 되지는 않습니다.

 

기획도 마찬가지입니다. 앱/웹 기획은 스토리보드/화면설계서를 작성하는 것으로 보일 수 있습니다. 그래서 그동안 보아 왔던 스토리보드/화면설계서를 참고해서 비슷하게 작성하면 기획을 완료했다고 생각합니다.

 

그러나 요즘 발생하는 대부분 앱/웹 개발 프로젝트 문제는 바로 여기에서 나타납니다. 마치 스마트폰을 자주 사용해서 인터넷 보고 부품 모아 만들어도 스마트폰이 되지 않는 것과 같습니다.

 

요즘 기획자 유형이 기획 프로세스를 경험하거나 학습한 것이 아닌, 앱/웹 개발 프로젝트에서 스토리보드/화면설계서를 접한 경험을 토대로 기획 작업을 하는 경우가 많이 보입니다.

 

심지어 ASIS 파악과 요구 사항 분석 없이 인터넷에 있는 자료와 다른 기획자 화면 설계를 모아 기획 공통과 기준을 잡는 기획 PL(리더)도 나타나고 있습니다. 

 

이 경우 앱/웹 개발 프로젝트 초기에는 문제가 없어 보일 수 있지만, 프로젝트가 진행될수록 문제가 점점 많아질 것입니다.

 

이런 기획자의 특징은 입으로 기획을 하거나, 스스로 기획서를 만드는 것이 아닌 다른 기획자 문서에 첨삭 기획을 한다는 것입니다. 또한 이런 기획자가 기획 리더(PL)인 경우 이들이 작성한 PA들이 기준 삼아야 하는 문서는 정리가 안된, 누가 보아도 짜깁기 한 띠가 많이 난다는 것입니다.

 

이 경우  TOBE 기획은 문제가 생길 것입니다. 특히 규모가 큰 프로젝트일 경우 심각해질 것이 분명합니다.

 

앱/웹을 자주 접한 것은 제외하고 실질적인 기획 경험이 부실할 뿐 아니라, 기획의 본질인 목표와 여기에 도달하고자 하는 프로세스가 없기 때문입니다.