기획 가이드 · SaaS 및 웹 애플리케이션

SaaS MVP 범위 설계

MVP는 모든 기능을 작게 만든 것이 아닙니다. 실제 사용자가 끝까지 완료할 수 있는 하나의 여정과, 그 여정에 필요한 역할·데이터·인수인계입니다.

중국 장먼. 전 세계적으로 일합니다.

하나의 여정을 처음부터 끝까지

사용자의 언어로 여정을 설명합니다. 무엇을 가지고 들어와서, 무엇을 하고, 무엇을 가지고 나가는지. 특정 단계에 다른 사람이나 다른 시스템이 필요하다면 그것도 범위입니다.

요청을 접수하고, 담당자에게 배정하고, 진행 상황을 보여주는 고객 포털은 완결된 여정입니다. 미완성 모듈 여섯 개를 모은 대시보드는 아닙니다.

누가 생성, 편집, 승인, 삭제할 수 있나요? 각 역할은 어떤 데이터를 볼 수 있나요? 화면을 만든 뒤 권한을 정하면 보통 화면을 다시 만들어야 합니다.

각 역할을 한 문장으로 적고, 모든 역할의 입장에서 주 여정을 따라가 봅니다. 여기서 발견한 빈틈은 테스트 단계에서 발견하는 것보다 훨씬 저렴합니다.

제품이 읽거나 써야 하는 시스템과, 그 시스템을 쓸 수 없을 때의 동작을 나열합니다. 호출 한도, 페이지 처리, 인증, 동기화 실패 시 사용자에게 알릴 내용도 포함합니다.

기존 스프레드시트나 오래된 데이터베이스가 있다면 익명화한 샘플로 구조를 설명합니다. 현재 데이터가 문서화된 적이 없어 이전 작업은 대개 과소평가됩니다.

결제, 리포트 모음, 네이티브 앱, 싱글 사인온, 고급 검색은 2단계의 단골 항목입니다. 범위 밖이라고 명시하는 것은 약점이 아니라 첫 출시를 검증 가능하게 만드는 일입니다.

첫 출시가 하지 않을 일을 서면으로 합의하면, 인수 단계에서 경계를 처음 알게 되는 상황을 피할 수 있습니다.

여정의 각 단계마다 기대 동작과 실패 시 동작을 적습니다. 이어서 누가 승인하고 무엇을 증거로 삼을지(화면 녹화, 테스트 계정, 체크리스트) 정합니다.

이렇게 쓴 인수 기준은 "다 된 것 같다"를 양측이 한 시간 안에 내릴 수 있는 결정으로 바꿉니다.

MVP에는 기능이 몇 개 필요하나요?

관련된 모든 역할이 하나의 여정을 완료할 수 있을 만큼만, 그 이상은 아닙니다. 그 여정에도 법적 요구에도 해당하지 않는 기능은 이후 릴리스로 미룹니다.

디자인 시스템이 먼저 필요한가요?

완전한 시스템은 필요하지 않습니다. 첫 여정에 필요한 핵심 레이아웃, 폼 패턴, 컴포넌트 상태를 정하고 제품이 자라면서 확장합니다.

MVP 출시 후에는 어떻게 하나요?

범위를 정할 때 인수인계도 함께 계획합니다. 누가 운영하고, 누가 결함을 고치고, 데이터는 어떻게 백업하며, 다음 단계 우선순위는 어떻게 정할지입니다. 지원 조건은 출시 후보다 전에 합의하는 편이 쉽습니다.