114. 상품출시 전 점검사항
성공적인 소프트웨어 신상품 개발가이드
서비스 또는 유지보수 중인 상품의 신규기능을 정기적으로 릴리즈하는 것과 신상품을 처음 릴리즈 하는 것은 다르다. 신상품을 처음 릴리즈 하는 상품관리자는 마음의 준비를 단단히 해야 한다. 대부분 상상 이상의 고난이 기다리고 있다.
1) 상품출시 전 점검사항
상품을 출시할 준비가 되었는지 점검할 사항은 다음과 같다.
- 실제 사용환경에서 품질검증을 철저히 한다.
소프트웨어 상품의 품질은 디바이스(스마트 폰, 테블릿, 노트북, 와이파이 공유기)와 운영 소프트웨어의 종류뿐만 아니라 네트워크 속도에 따라서도 영향을 받을 수 있다. 특히 글로벌을 타켓으로 출시하는 상품은 다양한 사용환경에서 품질검증을 해야 한다. 별도의 테스트 환경을 구축하여 테스트 할 수도 있지만 반드시 고객의 사용환경에서 필드테스트를 하는 것이 좋다. 병원시스템과 같이 중요한 솔루션 출시전에 사전 리허설을 해야 예상하지 못한 이슈를 발견할 수 있다. 예를 들어 실제 환자가 병원에 오는 다양한 케이스 (응급, 초진, 재진, 수납 등)를 테스트 요원들이 수행하여 문제점을 발견한다.
- 롤백(roll back)에 대한 기준을 정의한다.
기존 상품이 있고 개선상품을 출시한다면 품질이나 성능에 큰 문제가 발생한다면 기존 시스템으로 신속하게 전환하여 고객불편을 최소화해야 한다. 롤백은 중요한 결정이기 때문에 사전에 그 기준을 명확하게 정의해야 한다.
- 출시 전 수정 할 결함과 안정화 기간에 수정 할 결함을 결정한다.
출시를 앞두고 재현이 잘 되지 않아 해결이 힘든 결함이 있을 수 있다. 이때 상품관리자는 출시를 미룰 정도의 결함인지 아닌지를 판단해야 한다. 출시 전에 발견한 결함은 모두 수정하는 것이 좋지만, 특수한 경우에 발생하고 그로 인한 영향력이 크지 않은 결함인데 수정하기 힘들다면 출시 이후에 결함을 수정할 수 있다.
- 고객센터에 고객응대 자료를 배포하고 교육한다.
출시 직후 가장 바쁜 조직은 고객센터일 것이다. 고객센터 응대원들에게는 출시하는 상품의 내용이 낮설기 때문에 충분한 교육을 하지 않으면 고객문의에 정확한 가이드를 하기 힘들다. 문의 유형별로 답변 스크립트를 작성하여 사전에 교육을 해야 한다. 출시후 일주일 정도 지난 후 사전에 고려하지 못한 질문이 있는지 답변에 대해 수정할 내용이 없는지 파악하여 스크립트를 업데이트 해야 한다.
- 마케팅 전략을 검증한다.
• 시장 및 고객에 대한 변경내용 검토
상품기획 시 반영했던 여러 가정들이 유효한지 출시 전에 확인해야 한다. 시장의 경쟁구도, 고객가치에 대한 큰 변화가 있다면 출시를 연기하거나 중단해야 한다.
• 상품가격 확정
경쟁상품의 가격구조, 라이선스 판매유형(기기, 수량, 사용자, 사용량 등)의 적정성, 채널 파트너의 가격, 사업전략과의 적합성 등을 검토하여 가격정책을 최종 확정한다.
• 출시시기
경쟁사 동향, 계절적 요인은 출시시기 결정시 고려할 기본 요소이다. 자사의 기존 상품에 영향을 미치는 자기잠식 상품은 기존 상품의 매출을 고려하여 출시시기를 결정한다. 품질검증을 완료한 상태에서 출시시기를 공개적으로 발표 한다.
• 출시지역
글로벌 동시 출시를 진행할 수도 있고, 특정지역에서 선 출시 후 판매를 확대할 수 있다. 특정지역에서 먼저 출시하는 것은 품질 또는 상품성능에 대한 확인 또는 보완 후 타 지역으로 판매를 확대하기 위함이다.
• 광고
타켓에 적합한 메시지 선정, 광고매체 유형별 광고횟수, 광고시점을 결정한다.
• 판매촉진
채널지원을 위한 활동과 소비자 판촉활동을 위한 예산을 결정한다.
• 기술지원 체계 및 마케팅 문서
AS를 위한 서비스 조직, 상품소개를 위한 마케팅 문서, 온라인 사이트의 상품 내용 업데이트를 확인한다.
2) 상품출시 후 안정화
상품관리자와 프로젝트관리자가 헌신하여 키운 자식과 같은 상품이 시장에 나가는 순간은 설레임과 불안이 교차한다. 많은 사람들의 관심과 사랑을 받아 무럭무럭 자라기를 원하지만 그렇지 못한 경우도 많다. 특히 외부고객의 VOC 보다 내부직원들의 VOC는 더 무섭다. 사내 게시판에 출시상품에 관해 좋지 못한 글과 댓글들이 올라오기 시작하면 상품관리자와 상품개발팀은 기운이 빠진다. 상품출시 직후 상품관리자의 멘탈은 강해야 한다.
상품출시 후 안정화를 위해 유의할 사항은 다음과 같다.
- 일정기간 동안 VOC를 모니터링한다.
상품관리자는 출시후 안정화까지 일일 VOC를 모두 읽어보는 것이 좋다. 로봇이 고객센터에 등록된 VOC를 엑셀로 추출하여 사전에 정해진 사람들에게 자동으로 배포하기 때문에 VOC 공유는 쉬워졌다. 문제를 VOC를 대하는 사람들의 마인드다. 상품관리자가 일주일에 한번 오전 또는 오후를 고객센터에 근무하면서 고객의 육성을 직접 들어보는 것이 좋다. 문자로 정리된 VOC와 전화기 너머로 들리는 고객의 육성은 느낌이 다르다.
시간이 없다고 고객센터에서 조치하지 못하는 VOC만 분석해서는 안된다. 시간이 남아 고객센터에 전화를 하거나 웹에 불편을 등록하는 고객은 없다. 대부분의 고객들은 웬만한 불편은 참고만다. 직접 전화를 하거나 온라인으로 불편사항을 접수해준 고객은 소중하다. 고객들이 상품관리자의 의도를 어떻게 느끼는지 파악해야 한다. 고객들의 목소리에서 고객가치에 대한 통찰을 얻어야 한다. 아니 통찰까지는 얻지 못하더라도 고객과 고객센터 응대원간의 간극을 줄여주려고 노력해야 한다.
- VOC 진행상황은 투명하게 공유한다.
조직의 규모가 크면 1선대응, 2선대응, 3선대응의 상세 역할을 정의하고 각 역할자들이 시스템을 통해 업무를 수행한다. 1선대응은 고객센터가 고객의 문의에 대응하고, 2선 대응은 상품 운영조직이 대응하고 마지막 3선 대응은 상품개발팀이 대응한다. 3선까지 가는 VOC 는 결함이나 개선을 위해 프로그램을 수정해야 한다.
조직의 상황에 따라 VOC를 관리하는 체계나 시스템화 수준은 다르겠지만 VOC 접수부터 해결까지의 전 단계를 모든 이해관계자들이 투명하게 파악 하는 것이 바람직하다. Jira는 큰 투자 없이 VOC를 관리 할 수 있는 좋은 도구다.
- 재현하기 힘든 VOC에 유의한다.
앱스토어에 등록된 고객의 불만은 거칠지만 구체적이지 않다. 어떤 환경, 어떤 기기에서, 어떤 화면에서, 어떤 불편을 경험하였는지 파악하기 힘들고 화가 잔뜩 난 고객의 마음만 느껴진다. 최악은 유사한 불편을 등록하는 고객 하나 둘 늘어나는 것이다. 소프트웨어 기기와 환경이 다양하여 원인을 찾기 힘든 복합적인 결함은 증가하고 있다. 정보가 부족하니 상품개발팀 내부에서는 재현이 힘들어 고객의 사용미숙인지, 프로그램 오류인지 판단하기 힘들다. 상품관리자는 이런 VOC일수록 끈기를 가지고 원인을 파악하고 고쳐야 한다. 사내 사용자 커뮤니티를 만들어 근본원인을 찾아낼 수도 있다.
https://brunch.co.kr/@kbhpmp/160
