MVP(최소기능제품) 외주개발:기능 범위 이렇게 하세요
7년차 PM이 직접 알려주는 MVP 실전 스펙 기준 체크리스트
MVP 외주개발, 기능 범위 어디까지 해야할까?
안녕하세요~ 7년차 PM 리뷰온리예요! :)
새로 무언가를 시작하려고 할 때
여러가지 부담을 제거하기 위해서 MVP 개발을 생각하시는 분들이 많을거예요!
특히 MVP 같은 경우에는 빠르게 만들고 검증을 하는 게 중요하다보니,
외주개발로 진행하시는 케이스가 보통인데요~
그런데 기능 리스트를 쭉 뽑다 보면
MVP가 아니라 거의 정식 1.0 스펙이 되어버리는 경우... 정말 많이 보여요!
결과는 예산 초과, 일정 지연, 팀원 피로감으로 돌아오곤 하죠. ㅠㅠ
그래서 오늘은 MVP가 정확히 무엇인지 다시 짚고,
MVP 외주개발에서 기능 범위를 어떻게 잡아야 하는지,
그리고 왜 이 과정이 자주 실패하는지까지 전부 다 알아볼게요~
MVP(최소기능제품)란? 개념 정리
MVP 외주개발을 제대로 하려면
MVP가 비즈니스 가설을 검증하기 위한 최소 제품으로 보는 게 중요해요.
특정 가격대에서 결제 의향이 있는지
지금 설계한 가입 플로우로 가입 완료율이 나오는지
사용자가 리스트와 상세 화면을 보고 실제로 신청이나 문의까지 도달하는지
이런 가설을 정해서 검증하는 것을 목표로 해야해요!
이 가설 없이 기능부터 나열하면
결제, 쿠폰, 고급 필터, 자동 알림, 정산, 관리자 권한 같은 것들이
불필요하게 MVP 기능 범위에 들어오면서
저렴하게 빠른 제작과 검증이라는 목표를 달성하지 못할 수 있어요...ㅜㅠ
의미있는 MVP외주 개발을 위해서는
반드시 검증해야하는 가설을 최소한으로 정해두고
기능 범위를 추려가는 것이 좋아요!
MVP(최소기능제품) 외주개발 기능 범위 잡는 방법
이제 실제로 기능 범위를 줄이는 방법을 단계별로 정리해볼게요~
기능 범위를 그냥 정하는 게 아니라,
이런 방법에 따라서 정리해두면
꼭 필요한 기능들만을 위주로 제대로 된 MVP를 만들 수 있어요!
1. 가설별 코어 플로우 한 줄로 쓰기
먼저 가설마다 핵심 사용자 플로우를 정리해둬야해요!
랜딩 → 회원가입 → 리스트 보기 → 상세 보기 → 신청 남기기
이때 목표는 화면 숫자를 세는 게 아니라
가설을 검증하기 위한 최소 행동이 무엇인지 보는 거예요.
이 플로우 바깥에 있는 기능은
기본적으로 V2 후보라고 생각하면 되겠죠?
2. 화면이 아니라 플로우 단위로 스펙 분류하기
그다음에는 플로우 단위로 MVP의 개발 범위를 묶어보는 게 효율적이에요.
가입 플로우 세트
콘텐츠 탐색 플로우 세트
신청이나 결제 플로우 세트
이렇게 보면 이번 MVP에서
진짜로 필요한 플로우는 한두 개뿐인 경우가 많아요!
나머지는 다음 단계로 미뤄도 되는 플로우로 남겨둬요.
3. 운영 가능한 최소 어드민 정하기
MVP라고 해도 운영이 안 되면 의미가 없어요.
그래서 저는 항상 사용자 화면과 함께
최소한의 어드민을 꼭 묶어서 보는데요!
신청이나 문의 리스트를 보는 화면
검색과 필터 기능
상태 변경과 간단 메모 기능
이 정도만 있어도
운영자는 엑셀과 병행하면서 충분히 서비스를 운영할 수 있어요!
어드민을 완전히 빼버리면
MVP 외주개발은 끝났는데 운영차원에서 어려움이 많이 생겨요 ㅠㅠ
4. 자동화와 고급 기능을 V2로 분리하기
MVP 외주개발에서 가장 먼저 빼야 하는 건
대부분 자동화와 고급 기능이에요.
복잡한 추천 알고리즘
정교한 정산과 통계
세밀한 권한 관리
여러 채널에 뿌려지는 알림 센터
복잡한 조합 필터 검색
처음에는 운영자가 수동으로 매칭해도 되는가?
정산은 엑셀로 처리해도 되는가?
알림은 꼭 필요한 몇 가지만 먼저 넣어도 되는가?
이런 질문들을 통해 생각해보면,
생각보다 많은 기능이 V2로 내려가도 괜찮은 경우가 많아요.
스펙 관련된 회의에서 소통이 원활하도록 해당 내용을 꼭 기록까지 해둬야해요!
MVP 외주개발이 실패하는 공통적 이유 4가지
MVP 외주개발이 실패하는 이유는
공통적으로 4가지 정도로 정리할 수 있을 것 같아요!
첫째, 가설 없이 기능부터 나열하는 경우
"있으면 좋을 것 같은 기능"은 계속 떠오르기 때문에
MVP라는 이름만 붙었지 실제로는 풀스펙에 가까워져요.
둘째, 예산과 일정에서 역산하지 않는 경우
원하는 기능을 다 적고 견적을 받은 뒤에야
그때부터 스펙을 줄이기 시작하면
내부 기대치와 현실 사이에서 PM이 가장 힘들어져요.
셋째, 운영 관점이 빠져 있는 경우
사용자 화면은 그럴듯한데
어드민과 로그, 데이터 구조가 없어
런칭 이후에 운영상 수동 작업이 너무 많아지게돼요.
넷째, 외주개발사와 검증 가설을 제대로 합의하지 않는 경우
이때는 프로젝트 중간마다 스펙 논의가 계속 열리면서
추가비용과 일정 변경이 반복되기 쉬워요.
결국 MVP 외주개발이 실패하는 이유는
기능이 많아서라기보다
처음에 기준이 제대로 정리되지 않아서인 경우가 많아요!
MVP(최소기능제품) 외주개발로 완벽하게 검증하기
MVP를 외주개발할 때 좋은 외주개발사들은
기능 범위를 선정할 때 훨씬 더 현실적으로 논의해줘요.
정말 좋은 외주개발사들은
처음 미팅에서 기능보다 서비스 목표와 가설부터 접근해서,
이 목표를 기준으로 기능 범위를 제대로 설계해줄 수 있어야해요!
IT 비즈니스 프로덕트 파트너인 똑똑한개발자는 이런 부분에 있어서
큰 강점을 가진 외주개발사라고 생각되는데요!
처음 가져간 기능 리스트 그대로 개발만 맡아주는 게 아니라,
가설, 플로우, 예산, 일정을 기준으로
MVP에 꼭 필요한 기능과 다음 버전에 추가해야할 기능까지 따로 말씀해주시더라고요 ㅎㅎ
출처: 똑똑한개발자 사업소개서덕분에 PM 입장에서는
이번 MVP 외주개발이 단순히 기능이 적은 버전이 아니라
다음 단계를 준비하는 발판이라는 느낌을 받을 수 있었어요.
지원사업 예산이 걸려 있는 프로젝트에서도
과제 구조에 맞게 기능과 마일스톤을 조정해준 덕분에
심사와 실제 개발을 동시에 관리하기가 훨씬 수월했어요.
MVP 외주개발을 고려중이신 분들께 외주개발사 똑똑한개발자 추천드릴게요!
(아래 홈페이지 링크에요~)
똑똑한개발자처럼 MVP를 개발하는 과정에서도
다양한 부분을 세심하게 살펴줄 수 있는 외주개발사를 선택해야
진짜 제대로 된 기능 범위가 있는 최소기능제품으로 개발을 마무리할 수 있어요~ㅎㅎ
MVP (최소기능제품) 성공 공식
지금 MVP 외주개발을 준비 중이라면
아래 네 가지를 꼭 다시 체크해보세요!
이번 라운드에서 검증할 가설을 두세 개로 줄였는지
그 가설을 위한 코어 플로우를 한 줄로 설명할 수 있는지
그 플로우를 운영할 최소 어드민 구성이 정의되어 있는지
자동화와 고급 기능을 V2 후보로 따로 분리해두었는지
외주개발사는 MVP 기능을 많이 넣어주는 팀보다
가설과 플로우, 운영 구조까지 함께 설계해주는 팀을 고르는 것이
좋은 선택이기도 해요!
MVP 개발할 때 기능 범위를 잘 설정하셔서
성공적인 검증을 마치실 수 있길 바라면서
다음에 다시 찾아올게요~~~~
감사합니다 :)
