https://www.youtube.com/watch?v=qI4zF0GfEW0 정리
문제 1: FE ↔︎BE
현상
- API는 많은 과정을 거쳐 완성됨. 문제는 완성 후 수정되는 경우가 적지 않게 발생함.
원인
해결
- FE, BE 개발자가 설계를 같이한다.
문제 2: 개발자 ↔︎ 디자이너
현상
- 디자이너의 의도와 다르게 산출물이 개발되는 경우가 있음.
원인
- 개발자들도 참여해야한다.
해결
- 빠르게 와이어프레임 만들어서 공유하고 피드백을 주고 받음
- 문서에 빠진 맥락을 서로 공유할 수 있게됨
문제 3: 서비스 제공자 ↔︎ 고객
현상
원인
해결
- 나와 고객은 다르다는 걸 인정하라
- 제품을 만들지 않고 고객의 반응을 확인해보는 것
- 나무 모형을 꾸며 실제 흉내 내보는 것
- 사전 신청
- 이미 존재하는 도구를 이용해서 시도
- 설문
잘 모르는 것부터 검증하자
- 고칠 때 많이 드는 것부터 약속하기 → 인터페이스
- 화살표 방향을 항상 지켜야하는 것은 아니다.
- 불확실성이 높아 미루고 싶은 것부터 약속해야한다 (예시: 개발 가능한지 먼저 파악 가능해야 하는 경우)
오너십을 가지고 일을하자
- 믿고 맡길 수 있는 동료가 되자.
'Planning' 카테고리의 다른 글
[기획] Data 중심 서비스 개선 (0) | 2024.04.14 |
---|
댓글