: 동작보다는 정책 위주로 와이어프레임을 만들었다.
MVP의 흔한 실수 50가지
읽은 이유: 이번주 금요일부터 MVP 프로젝트가 시작이라서 읽었다.
요약 이 글은 MVP를 대하는 팀원들의 자세에서 어떤 실수가 일어날 수 있는 지 꽉꽉 채워넣은 것이다.
나의 경험과 느낀점
1. 경험: 역기획 프로젝트때 MoSCoW를 자주 공유했던 것처럼, 이번 MVP 프로젝트 주차에서도 팀원들과 주기적으로 목표, 지표, MoSCoW를 공유하고 싶다.
2. 느낀 점 및 관점 전환: 최근 팀원들과 지내며 나의 생각을 전달하는 것에 생각보다 많은 공수가 들고 있다는 생각이 들었다. 그래서 MVP 프로젝트 발제문 이후 1시간 정도 시간을 두고, 각자 생각해온 목적과 지표를 이야기 나누는 시간을 가지면 좋을 것 같다고 요청드렸다. ‘무엇을 검증할 것인지 팀원 모두가 명확하게 알고 있어야한다.’라는 아티클의 말이 마음에 와닿았다.
질문: 초등학생도 이해할 수 있게 '어드민'을 설명하면?
AI 답변
1. 마땅한 답이 없다.
2. 다만 해당 내용이 들어가는 부분의 위치를 조정하여 맥락 상 이해가 가능하도록 한다.
3. 명칭은 보다 쉽게 "운영 정책 및 등록 기준"가 있을 수 있다.
핵심: 와이어프레임+기능 설명 > 운영 정책 및 등록 기준 > QA나 AB 테스트로 가야 설득력이 있다.
[Chapter.5-1] 데이터 드리븐 프로덕트 기획 주차
데이터 드리븐 기획에 필요한 역량들을 총정리하며 마무리 하는 과정
| 일시 | 작업 | 느낀 점 |
|---|---|---|
| 02/10 | 아티클 카타 | 노션의 덧글 기능이 아주 쏠쏠하다. 발표 기회가 없는 건 아쉽지만 ㅎㅎ |
| 02/10 | 유저 플로우 | 전체 유저, 초기 이탈 유저의 플로우를 작성하면서 플로우를 복습했다! |
| 02/10 | 와이어프레임 | 피그마로 반응성을 보려다가, 동작보다 기능에 중점을 둔 기획안을 만들었다. |
| 02/10 | (추가) 어드민, 테스트 | 각 화면마다 어떤 정책과 테스트를 설계할지 고민하다가 오전 시간이 훅! 갔다.. |
