주니어 IT 기획자를 위한 성과 지표를 높이는 서비스 기획

기획안의 메인 독자, 고객은 바로 '개발자'

개발자가 이해하기 쉽고 만족하는 기획안이 좋은 기획안

 

 

1. 명확할 것

모호한 표현 없애기

어떤 액션을 했을 때, 어떤 결과가 나오는지 명시

 

2. 경우의 수를 최대한 많이 고려하기

정상적인 시나리오 외 발생 가능한 다양한 케이스, 예외 사항 고려하기

 

3. 정해진 것, 변경 가능한 것 기획안에 명시하기

변경 가능성 이는 것은 기획안에도 미리 명시

특히 데이터 구조와 연관된 것 - 미리 고려하여 설계 필요

 

기획안 작성 예시

이용자별 상품 추천 기능은 1차 오픈 시에는 제외, 2차 오픈시에 반영 예정

데이터는 1차부터 미리 저장 필요(이용자별 조회한 상품 코드, 조회 날짜 저장 요망)

 

4. 고민 흔적을 기획안에 남기기

개발자가 의문을 가질 만한 것들을 미리 생각해서 기획안에도 '왜' 그렇게 했는지 명시

기획자의 의도를 알면 개발자가 더 나은 솔루션을 제안해줄 수 있음

 

5. 논리적인 구성 

케이스별로 결과가 달라지는 기능이라면 글 보다는 플로우차트나 표로 도식화

 

6. 서비스 공통 규칙

날짜 표시 규칙

이름순 정렬 규칙 

리스트 페이징 방식

 

 

________________________________________

 

예외 케이스들

이용자들은 기획자가 설계한 프로세스 대로 순차적이고, 이상적인 방식으로 서비스를 사용하지 않음

이용 순서, 방식은 언제나 제각각이다

상상 가능한 예외 케이스를 최대한 다양하게 고려하여 기획안에 반영 -> 개발자의 고민을 덜어 줌, 오류 최소화

효율적인 기획안 작성법

- 정상 시나리오 대로 상세 기획안 쭉 작성한 후, 예외 케이스들을 빠드린 것이 있는지 체크하며 기획안 보안

 

1. 초기값

입력이나 편집 가능한 항목의 초기 값을 어떻게 보여줄 지

컨텐츠가 없을 때 어떤 방식으로 보여줄 것인가

  

 

2. 컨텐츠가 많은 경우 노출방식

컨텐츠가 너무 많이 쌓일 경우 (스크롤)

우리 같은 경우 매칭 후기?

무한 스크롤 or 페이징 방식

 

무한 스크롤은 위치 저장에 대한, 재방문에 대해서는 적절하지 못함 

-> 해당 위치 좌표를 저장하는 페이징 방식이 더 적절함

 

3. 글자 수 제한

이용자가 직접 텍스트를 입력하는 부분이 있다면 '글자 수 제한' 정책 필요

노출 영역의 목적, 크기 고려, 잘리는 경우 말줄임표 & 툴팁

 

4. 데이터를 불러올 수 없을 때, 로딩 중 일때

장애 발생으로 인해 서버에서 데이터를 불러올 수 없는 경우

데이터 로딩 중, 업로드나 다운로드 등 대기가 필요한 경우 상태 표시 필요

- 프로그래스 서클(스피너), 프로그래스 바

 

 5. 기존에 있었으나 삭제된 컨텐츠 처리

기존에 있던 컨텐츠가 삭제되어 현재는 존재하지 않는 경우(이전에 존재했던 링크로 접속하는 경우)

기존 URL로 접속 시, 에러 발생 대신 적절한 문구 마련

 

6. 이용자별 권한에 따른 화면 구성

이용자의 권한 별로 화면 및 기능이 달라지는 경우 고려

사용 중에 권한이 변경되는 경우도 고려할 것

 

7. 키보드 액션

마우스를 이용한 클릭 기능 외에 키보드 액션에 따른 결과도 고려 

esc, 화살표, delete 입력 시의 진행 / 탈출 액션

 

8. 웹브라우저 기능

크롬, 사파리 등 웹브라우저의 이전, 새로 고침 버튼 클릭 시 이동

새로 고침, 뒤로 가기 액션 진행 시의 대응 (컨펌 모달 발생 등)

 

 ________________________________________

백오피스 어드민 기획

1. 벤치마킹할 서비스를 찾는 것이 어렵다

 

 

각 회사, 서비스마다 필요한 항목이 다름

회원 관리 : 회원 정보 (이름, 이메일,주소 구매 기록 등)

상품 관리 : 판매 상품 상세 내용 등록 및 수정

매출 관리 : 상품별 판매 내역, 일간 판매 내역

통계 : 일간 조회수 통계, 판매자별 통계 등

 

백오피스 기획 방법

기본적으로 이용자용 서비스 기획과 프로세스 동일

문제 발견 -> 요구사항 분석 -> 상위 기획 -> 상세 기획 -> 개발중 커뮤니케이션 -> QA 검증 -> 서비스 오픈

 

요구 사항 분석 시 유의할 점

해당 페이지를 실제 사용할 직원의 요구 사항을 확인하여 정리

특정 1명만을 위한 기능이 되지 않도록 유의, 해당 운영자가 퇴사 후 다른 사람이 동일한 페이지를 운영하더라도 쉽게 이해하고 사용할 수 있도록 구성

일회성 사용인지 주기적으로 사용할 기능인지 판단하여 개발여부 결정. 1년에 1번 정도 사용하는 기능이라면 back office에 굳이 기능할 추가할 필요 없음

개발자에게 자주 요청하게 되는 데이터, 반복 작업의 경우 -> 백오피스 구성 시 업무 효율 높아  

 

 

상품평 비공개 기능 기획

 

1. 개요 백오피스, 상품평 비공개 기능

2. 목적 / 배경

- 상품평에 관련 없는 사진 등을 운영진이 신속 비공개 할 수 있기 위함

- 이전에는 개발팀에 직접 요청하는 식으로 대응했으나, 상호 효율 증진을 위함

3. 작업 범위

- 상품평 관리 페이지 신설

  - 상품평 리스트 노출, 최신순 업데이트 정렬

  - 상품평 리스트 검색 (상품 콛, 이용자 아이디)

  - 상품평 사태 값 변경 (상품코드, 이용자 아이디)

  - 비공개 사유 입력

  - 비공개 사유는 해당 이용자에게도 메일로 발송

 

4. 정책 및 고려 사항

  - (현재) 상품평 등록 시 자동으로 공개처리 됨

  - 사후 모니터링 후, 문제 있는 것을 비공개 처 

 

 

 

백오피스 기획 실제 예시에 대한 소고

 

1. 비공개 -> 공개로 되돌리는 기능은 왜 기획안에 포함하지 않은 것인지?

공개 여부 컬럼에 따라 노출되지 않는 시나리오이고

비공개 처리 시 회원에게 메일을 발송해서, 상품평 노출을 원한다면 수정해라 라는 메일까지 발송하고 있는 점

을 고려 시 

공개 -> 비공개 / 비공개 -> 공개 두 가지 상황 모두 대응 가능한 형태로 기획하는 것이 MVP라고 생각됨

비공개 -> 공개 기능 역시 추후 반드시 필요할 것으로 생각됨