[패캠] 서비스 기획 Case Study

서비스 기획

[패캠] 서비스 기획 Case Study - 인하우스/외주

winter17 2024. 3. 15. 18:57

◆ Case study - 인하우스

요구사항 접수(생산)
- (업무가 적을 경우) 자체적으로 개선과제를 찾아본다
- 아이디어를 구체화한다 → 외부서비스 활용? 자체 구축?
사전 검토
- 설득하기
- 현업 인터뷰
기획서 작성
- 문제와 원인을 구체적으로 파악한다. (조사, 회의, 인터뷰)
- 개선 방향을 찾는다. (기술적, 외부의 조력 등)
- 회사 내 다양한 사람들과 협의하며 요구사항을 구체화한다.
- 정책, 플로우를 설계한다. (필요한 경우 화면기획 등이 들어간다.)
- 리소스 협조를 받고, 플래닝을 한다. WBS가 나온다.
- 구현과 QA 단계에서 상황 변화에 따라 스펙을 추가, 변경, 제외한다.
- 배포 전 현업 부서에 공지하고, 배포되면 오픈 공지한다.
- 일정 기간 경과하면 회고를 진행하고 결과 보고서를 작성한다.
일정 수립
- Jira를 사용하여 일정을 플래닝한다.
구현
- 구현 단계로 들어가면, 작업자들로부터 들어오는 문의에 답변하고, 이의제기에 대응한다.
  - 작업자: 디자인, 퍼블리싱, FE, Android, iOS, BE
- 필요한 경우 정기 미팅이나, 스크럼(한 일, 할 일 등)을 만든다.
- 작업 중 이슈가 발생하면 문의하거나 회의를 만들기도 한다.
- 작업이 순차적일수도, 함께 진행될 수도 있는데 요구사항에 따라 엔지니어들이 판단한다.
- 오픈을 앞두면 오픈 시나리오를 작성하기도 한다. 오픈 시간, 작업 순서, 오픈 테스트 항목, 롤백 순서 등
- 배포의 영향도에 따라 전체 서비스를 내리고 배포를 하는 경우도 있고, 무중단으로 배포하는 경우도 있다. 일반적으로 사용자가 최소인 시간대를 활용하는 것이 보통이다. 03~09시 사이
오픈 모니터링 및 결과 보고
- 테스트, QA를 해도 이후에 어떠한 문제가 발생할지 모르는 것이 배포이다.
- 수정한 부분이거나 예상했던 부분이 아닌 곳에 장애가 나면 사이드(side effect)라고 부른다.
- 특히 이커머스에서는 결제가 안되는 것이 가장 큰 문제이다.
  - 메인/전시/검색 > 상품 > 장바구니/주문으로 이어지는 주요 흐름에 문제가 생기면 빠르게 전파하고 대응해야 한다.
- 오류나 장애가 발생했을 시, 개발자들은 원인을 파악하고 대처하느라 바쁘다. 침착하게 기다린다. 수정 재배포, 롤백 같은 대응 이후에 물어봐도 늦지 않다.
- 배포 후 모니터링이 어느정도 마무리되면, 필요한 곳이 전파한다. 보통은 매뉴얼이 존재한다.
- 결과 보고서를 작성하고, 팀원들끼리 회고를 진행한다. 프로젝트 과정에서의 좋았던 점, 아쉬운 점, 구성원들에게 하고 싶은 말 등을 각자 작성하고 이야기 나눈다.
- 결과 보고서와 회고 내용을 토대로 정기 회의에 발표를 진행한다.

◆ Case study - 외주 과제

요구사항 정의(내부)
- 다른 팀, 고객, 판매자 등 외부에서 어떠한 요구사항 접수
- 다양한 채널에서 정보 찾기 → 공식 사이트, 블로그, 파트너사 홈페이지, 현업 인터뷰, 경쟁사 도입 여부 체크 등
- 보고서 작성에 필요한 컨텐츠 백업하기
보고 및 비용 품의
- 회사 내부에서 진행 의사결정을 받는 단계이다.
- 회사마다 방법과 문화가 달라서 일반화하기 어렵지만 시도해본다면?
  - 보고서를 작성한다. (보고서에 포함될 내용 예시 : 배경 및 문제점 > 개선 방안 > 예상 일정 및 비용)
    - 배경 및 문제점 : 미리 정해져 있다. 왜 이것을 제안하는지, 어떤 문제들이 있는지를 명확하게 제시한다.
    - 개선 방안 : 가장 어려운 부분이다. 지인, 다양한 업체와의 미팅, 제안 내용을 참고한다. 문제점을 어떻게, 어느 수준으로 해결할 수 있을지 제시한다
    - 예상 일정 및 비용 : 비용은 돈만 의미하지 않는다. 인하우스 구축이라면 리소스 투입기간도 비용이다. 개발팀이나 업체와 상의해서 합리적인 수준으로 지정해야 한다.
  - 실무자들과 검토하며 수정한다. (직속 선배 및 팀장님, 개발부서, 요청부서 등)
  - 필요한 경우, 팀장 이상 레벨에 보고하고 피드백 받는다.
  - 의사결정 프로세스를 진행한다.
- 프로덕트 커뮤니케이션의 중심은 기획서이다. 마찬가지로 회사 내 의사결정 커뮤니케이션의 중심은 보고서이다.
- 보고서는 내가 작성하고 수정하지만, 내 것은 아니다! 같이 만들어가는 것, 수정을 기분나빠할 필요없다.
- 보고서를 만드는 과정에서의 협의가 중요하다. 일을 하려면 여러 부서의 협조가 필요하기 떄문
- 변경된 내용을 잘 공유하는 것도 중요하다.
외주 용역 또는 솔루션 구매 발주
- 프로젝트 진행에 필요한 외부 자원을 구매하는 단계이다.
- GA 도입 방식은 다양하다. 이 사례에서는 GA360(유로버전) + 컨설팅 서비스를 가정한다. 솔루션 비용과 용역비가 함께 투입된다.
- 돈 쓰는 방법도 회사마다 다르다. 구매팀이나 개발팀이 진행하기도 하고, 직접 진행하기도 한다. 가장 보수적인 케이슨ㄴ 다음과 같다.
  - 제안요청서(RFP, request for proposal)를 작성한다.
    - 회사마다 양식이 다르지만, 보고서와 비슷하다. 요구사항이 무엇인지를 명시하여 도와주실 분을 찾는 문서이다.
    - 제안서 접수, 경쟁PT, 발표 등 일정을 명시하기도 한다.
  - 업체 제안서를 받고 검토한다.
  - 경쟁PT를 보고 질의응답한다.
  - 평가서를 작성한다.
  - 평가 결과에 따라 우선 협상 대상자를 정하고 세부 협의를 진행한다.
- RFP 예시

4. 요구사항 상세 정의(w/외주사)

RFP의 큰 요구사항들을 토대로 세부 요구사항을 정의하는 단계이다.
협력사와 여러 차례 미팅을 하며 구체화한다. 이 과정에서 협력사의 요청사항에 최대한 협조하고, 일정을 준수해야 한다.
- 현업 부서와 함께 꼭 분석해야 하는 항목들 정하기
- 개발 부서에서 어느 수준까지 어떤 일정으로 협조가 가능한지 확인하기
- 전자상거래 이벤트, 클릭 이벤트, 페이지명 정의 등
요구사항 정의서와 WBS가 산출물로 나온다.

5. 구현

요즘 솔루션들은 거의 SaaS 형태이다. 예전에는 프로젝트 인력이 상주했다.
GA360 파트너의 경우, 고객사 요구사항을 구체화하고 적절한 개발가이드를 만들어 고객사에 제공한다.
이후 개발은 고객사에서 진행하고, 잘 구현되고 있는지 검증을 도와준다.
사실 구현 단계에서 기획자가 할 수 있는 것은 거의 없다. 지원 업무를 수행한다.
- 정기 회의를 만들고, 회의록을 작성한다.
- 개발 과정에서 발생하는 이슈를 함께 고민한다. (스펙 변경, 스펙 아웃 등)
- 스펙 변경, 누락 정도가 크다면 상위 직책자에게 보고하고 의사결정을 받기도 한다.
- 오픈 이후 운영과 활용 계획이나 사용자 교육 방안을 세울 수도 있다.
QA 조직이나 담당자가 없는 경우, 기획자가 직접 테스트를 한다. 이 단계가 매우 중요하다.
- 개발 변경 지점은 당연하고, 영향이 없을 것 같아도 서비스의 중요한 흐름은 모두 확인하는 것이 좋다.
배포 일정이 정해지면 고객 부서에 변경 내용을 공지하고, 필요한 경우 리뷰한다.

6. 안정화 및 결과 보고

열심히 준비했지만, 배포 이후에 어떤 이슈가 생길지 모른다. 최악의 경우는 롤백 + 오픈일정 연기이다.
- 예민한 상태의 개발자들과 동고동락해야한다. 이때 태도가 동료간 신뢰, 유대감에 큰 영향을 끼친다.
- 내가 컨트롤할 수 없는 이슈라도 적극적으로 도울 방법을 고민한다.
- 장애가 터져서 상급자들이 안달해도, 최대한 개발자들을 괴롭히지 말자. 열심히 대응하는 중에 원인 알려달라고 짹짹거리면 더 늦어진다.
안정화가 마무리되면 오픈 공지한다. 오픈 공지는 길지만 구조는 아래와 같이 간단하다. 필요한 경우 결과 보고서를 만들고 보고한다.
- 배포일시
- 배포내용
- 작업자
서비스사 시작되면, 마케팅팀 등 현업 부서의 질문에 응대하거나 일정때문에 포기했던 개발 항목들을 추려서 AS를 요청하기도 한다.