개인적으로 어떤 방향을 정해주는 방식의 피드백도 있겠지만, 저는 고려해봤으면 하는 내용을 제시하려합니다.
팀원들과 활발히 제 피드백에 대한 내용들을 논의하여 여러분들의 방향을 만들어주세요.
노션으로 피드백을 드렸으므로, 노션 내 코멘트를 활용하여 질문주세요.
MVP 은 구체적이어야 합니다.
이 포맷은 항해99 에서 공통적으로 제공되는 템플릿인가요? 타팀들도 다 동일해서요. 제가 파악한 바로는 대다수의 팀 모두 MVP 가 너무 간결합니다. 구체적이지 못합니다. 항해99 에서 제공하는 포맷은 레이아웃이라고 생각하시면 됩니다. 그대로 복붙하여 진행하지말고, 정말 MVP 를 설계해주시는것이 좋습니다.
MVP 는 추후 프로젝트 진행 방식과 개발 의지에 직결
구체화되지 못한 MVP 는 각 피쳐별 개발에 필요한 공수(스코프) 계산이 되지 않으니, 추후에 생각한것과 너무 다른 수준의 개발량으로 기획했던것들 중 몇 피쳐를 개발하지 못하게 되는 상황이 발생합니다. 이가 하나둘 빠지다보면 생각했던 서비스를 아예 못만들게되거나, 개발 의지가 꺽이기도 합니다. 그 과정중에서 많은 조율이 발생하며 개발자인지 기획자인지 모를 상황이 무조건 발생합니다. 예를 들면 개발에 집중하기도 부족한 마당에 만나서 어떤 부분들을 쳐낼지가 주가 되는 상황이 발생합니다. 사이드 프로젝트의 경우에 2달 프로젝트가 1년을 질질끌게되는 상황도 봐왔습니다.
MVP 는 유즈케이스에서 Bottom-up 으로 기획/설계합니다.
예를 들어 사원 관리 서비스의 MVP 를 설계한다고 가정하면, 가장 첫 MVP 는 사원 관리 정보를 단순 텍스트를 입력하도록 만들고, 그 다음 여러 폼들로 기입할 정보들을 구체화하며 실제 사용자들의 피드백을 받아, DB 스키마를 더 구체화해나갑니다. 그 다음 기입한 정보들을 필터를 통해 원하는 정보만 조회하여 관리할 수 있는 피쳐를 붙이는 격입니다. 이렇게 총 3단계의 MVP 가 구성되었습니다. MVP 설계는 유즈케이스 기반으로 설계됩니다. Top-down 이 아니라 유저가 어떤 행동을 할지에 대한 정의 후에 Bottom-up 으로 MVP 요소들이 정리되어야합니다. Top-down 의 단점은 너무 많은것들이 누락된다는 점입니다.
개발 속도와 시간적인 여유가 충분하다면 3단계까지 모두 마칠 수 있을테고, 시간이 부족하더라도 2단계 상에서 실제 유저들에게 Product 로 제공할 수 있게 됩니다. 한번에 모든것을 만들 생각을 내려놓고 정말 기본적인것들이 기능할만한 것들을 순차적으로 구체화해 나간다고 생각해주시면 좋겠습니다.
MVP 는 Minimum Viable Features 가 아닙니다 “Product” 단수 명사입니다. 물론 개발자들에게 기획자의 역량을 갖추라고 하는건 욕심이겠지만, 기획 이해능력이야 말로 개발자 본인이 야근하지 않을 수 있는 최소한의 방패라는 점을 유념해주세요.
MVP 에 따른 DB 유형 선택 및 테이블 스키마가 가능해집니다.
명확한 MVP 는 그 자체로 DB 테이블 스키마 설계를 가능하게합니다. 테이블 스키마에 따라 나열된 MVP 와 각각에 해당하는 구체 페이지와 연결하게 되면 그것이 API 설계가 되는것입니다. 다시 한번 구체적인 MVP 야 말로 앞으로 프로젝트의 모든 개발의 베이스라인이라는 점을 유념해주세요.