[도그냥이 알려주는 서비스 기획 스쿨] Ch3. 실무에 돌입하기

프로세스 설계에서 자주하는 실수 : 있으면 좋을 것 같은 기능을 추가

우리가 세운 전략이 효과적이었는지 측정할 수 없게 됨

가설이 옳았는지 보려면, 전략적으로 바꾸려고 하는 부분 외에 나머지 부분은 모든 조건이 동일해야 함

 

 

개발자와 소통하기

요구사항 정의서를 미리 리뷰하기

- 인력 배치에 용이

- 오류없이 유지하기 위해 필요한 불확실성을 줄일 수 있음. '일부 수정'이 발생하면 어디를 수정해도 불확실성이 높은 프로그래밍 상태인 '스파게티 코드'가 발생

=> 기존 시스템에 있는 기능으로 구현이 불가능한지 / 기존 시스템에 영향도를 최소화할 수 있는지 고민

 

 

 

사용자 스토리 작성법

제목 : 너무 길지 않게

실제 내용 (사용자, 사용자의 목적, 서비스 목표)

완성 기준

 

 

요구사항 정의서와 다른 점 : 페르소나 개념과 서비스 목표, 사용자 과업, 비즈니스 목표와 중요성이 포함됨 

UI 부분은 디자이너가 자유롭게 할 수 있도록 작성하지 않기

 

에픽 : 사용자 스토리에서 최상단에 놓인 것

백로그 : 하위의 가장 작은 기능 단위로 정의된 항목

 

 

* 서비스 UX를 개선하려는 눈빛으로만 본다면 우리는 절대 사용자의 눈을 가질 수 없다. 사용자는 서비스를 경험할 때는 서비스 화면 구성과 같은 디테일에 무심하다. 그저 서비스를 목적 달성을 위한 도구로 이용한다. 그리고 이는 오직 사용자일때만 느낄 수 있다. p252