기획자가 요구사항 정의서를 리뷰하면 개발 리더는 다음과 같은 두 가지 질문을 꼭 던진다. 1. 기존 시스템에 있는 기능으로는 구현이 불가능한가? 2. 기존 시스템에 영향도를 최소화할 수 있는가? 기획자의 의도에 개발부서가 공감한다면, 분명 서비스 기획에 도움이 되는 조언을 들을 수 있다. 개발자가 기존 시스템의 숨겨진 기능을 이용해 개발 기간을 단축할 방법을 찾아줄 수도 있고 추가 개발 없이 목표를 달성하는 방법을 제안할 수도 있다. 하다못해 우리가 알 수 없었던 타사 서비스의 시스템 구조와 힌트를 들을지도 모른다. 서비스 기획자가 생각할 수 있는 범주와 개발자가 생각하는 범주가 다르기에 협업은 필수적이다. *마이크로 UX : 사용자가 움직이는 동선이라고 하면 대개는 페이지 단위 이동만을 생각하는데 페이..
개발자와 커뮤니케이션을 하려면 요구사항 정의서를 작성해야 한다. 소프트웨어에 포함되어야 할 기능과 데이터 등 완성될 서비스의 완성 조건을 정의하는 것을 의미한다. 요구사항 정의서를 리뷰하고 나면, 개발 담당자는 가능한 것과 가능하지 않은 것, 추가적으로 검토해봐야 할 것 등을 파악하게 된다. 어느 정도의 개발 인력과 시간이 투자되어야 하는지도 가늠한다. 그러므로 요구사항 정의서를 리뷰할 때는 원하는 기능뿐만이 아니라 프로젝트의 방향과 목표, 히스토리 등을 폭 넓게 설명해서 공감대와 관계를 형성하도록 하자. 요구사항 정의서 주요 작성 항목 1. 시스템 구분 : Front / Adminstrator / 기타(API, BATCH 등) 2. 기능 신규 여부 : 신규/기존 수정 3. 요구사항 번호 : 모듈명 + ..
STEP 1. 필요한 기능과 데이터를 정의한다. 1. 서비스의 재료가 되는 기능과 데이터를 생각해보자 2. 데이터를 활용하는 정책을 같은 마인드맵에 써보자 서비스 목표와 이에 필요한 기능과 데이터를 차례로 정리했으면, 이제 '정책'을 정리할 차례다. 정책은 '데이터 활용 기준'이라고 생각하면 된다. 개발을 하는 사람이 알고리즘을 짤 때 핵심적으로 고려할 기준을 정리해주는 것이다. STEP 2. 내부와 외부 사용자별 플로우를 정리한다. 보통 자료에서 보는 플로우 차트는 고객이 보는 프론트 화면의 순서를 나타낸다. 하지만 그런 화면만으로는 디자인도 개발도 진행하기 어렵다. 다양한 정책이 가져오는 여러 가지 케이스에 대해 모두 확인해볼 수 있는 플로우 차트가 필요하다. 현업 실무자에게는 '비즈니스에 맞는 플로..
역기획 : 독학으로 서비스 기획을 공부하는 방법 STEP 1. 비즈니스 모델 파악 : 서비스를 선택하고 서비스 구조와 수익 구조를 파악한다. 어떤 서비스를 선택하느냐에 대한 기준은 '데이터 가설'을 세울 수 있느냐는 점이다. 온라인 서비스란 아무리 인터페이스가 화려해 보여도 결국은 데이터를 입력하고 특정한 과정을 통해서 원하는 형태의 데이터를 출력하는 서비스다. STEP 2. 핵심 로직 분석 : 데이터 가설을 설정하고 서비스를 사용해보면서 검증한다. 어느 정도 서비스의 비즈니스 모델을 이해했다면 각 화면에서 수집하고 사용하는 데이터의 활용에 대해 가설을 세운다. 비즈니스 모델에서 핵심적으로 보이는 부분에 집중해보는 것. 가설을 세우려면 서비스를 이용해보아야 한다. 그리고 서비스가 어떤 데이터를 수집하고 ..
서비스 기획의 3요소 UX, 비즈니스, IT 서비스 기획에서 말하는 '서비스'란 무언가 목적을 가지고 있는 이용자에게 목적을 이룰 수 있도록 도와주는 프로덕트 전체 서비스 기획자의 역할 서비스 기획자는 비즈니스, UX, 기술 영역을 망라하여 프로덕트(서비스)를 구현하기 위해 기획하고 관리하는 사람을 말한다. 쉽게 말하면 비즈니스 모델상의 수익 구조, 고객과의 접점, 지향점 등을 종합하여 서비스를 만들고 성장하도록 관리한다는 의미다. 또한 서비스 기획자는 현업부서가 원하는 진짜 목표를 기반으로 전체 프로덕트의 방향성에 맞는 대안을 새로 고민할 수 있어야 한다. 그러자면 핵심 질문을 던지는 것이 중요하다 * 프로덕트 vs 프로젝트 : 프로덕트는 서비스로 나타나는 '산출물' 자체를 의미하며, 프로젝트는 그 목..
