바퀴를 재발명 하지말자.
이미 선배들이 오랜시간 노력해서 만든 성과들이있다면 거인의 어깨에 올라타 적절히 사용하는것이 좋다.
- 오픈소스
- 깃허브
- 오픈api
디자인으로치면 중요한 BI 로고 정도만 직접디자인하고, 아이콘 등 중요하지않은건 이미 만들어진것을 가져다쓰자.
개발로치면 지도 등을 직접 만들생각하지말고(어차피못만들지만) 이미 구현되어있는것을 가져다쓰자.
아이디어를 구상할땐
기존 서비스와의 어떤 측면에서 경쟁이있는지를 생각하자 (이용자의 어떤 가려운 부분을 긁어줄 수 있는지에 집중하자.)
또한, 아이디어도구를 사용하면 아이디어를 조정하는데 도움이된다 (구름에서는 아이디어개발도구로 lean canvas 를 사용한다.)
MVP 프로세스
- 완벽함보다 속도중시
- 폭넓은 관심보다는 하나의 집중
- 과정과 절차보다는 분업과협업으로 속도를 우선으로
- 기능추가보다는 실용성
발표 팁
- 발표는 무조건 잘하는사람이 해라 (ㅋㅋㅋㅋ이거진짜공감)
- 순서: 가설 -> 검증 -> 구현
- 가설 : (나-우리) 경험, 기성품의 한계, 새로운 접근/기능
- 검증 : 주요고객 페르소나, 선택과집중
- 구현 : 프로토타입, mvp
- 핵심에 집중 -> 와우포인트만들기
- 해당 행사 목표와 주최/후원사 요구사항을 확인
: 기능구현이 목적이아닌 모두가 공감할 수 있는것을 만들어야한다.
🤟 강의 후기 및 느낀점
뻔하다고도 할 수 있지만, 어쩌면 중요한것을 놓치고 지금까지 개발한느낌이였다.
가장 마음에 와닿았던건 MVP범위 설정이다.
사실 최근에 여러 사이드 프로젝트를 하면서 느낀것 중 하나가 MVP범위에 대한 사람들간의 다른점이였다.
나같은경우 조금 더 확장된 정도의 범위를 원했는데, 다른사람들은 엄청엄청 최소한의 범위만 원했다.
그로인해 조율하는점이 힘들었었는데,
이강의를 보고 느낀점은 내가 잘못생각을 했다는점이다.
MVP범위라 함은 정말정말 최소한의 핵심기능을 말하는것이였는데, 나는 지금까지 어느정도 서비스가 그려지는 범위를 생각했던것같아서 많은 반성이되었다.
앞으로는 MVP범위를 잘 생각해서 구현해야할것같다.
학생 점심 좀 차려