심플하게 VOC(Voice Of Customer) 프로세스 글로만 풀어보기
VOC(Voice Of Customer)를 관리하는 이유는 CS(Custormer Service)의 만족도를 높이기 위함입니다.
VOC를 관리하기 위해서는 그에 맞는 프로세스가 필요한데요.
간단하게 설명하면 VOC 영역은 회사와 고객 간의 커뮤니케이션을 이야기합니다.
JIRA에서는 젠데스크를 통해 ITSM(IT Service Management) 구축이 가능하며, ITSM을 구축하게 되면 SLA(Service Level Agreement)를 관리할 수 있게 됩니다.
서비스 수준 협약서 - 위키백과, 우리 모두의 백과사전
위키백과, 우리 모두의 백과사전. 서비스 수준 협약서(Service Level Agreement)는 서비스를 제공함에 있어서 공급자와 사용자간에 서비스에 대하여 측정지표와 목표 등에 대한 협약서이다. 일반적으
ko.wikipedia.org
회사마다 SLA를 관리하는 방법은 다를 수 있으니 참고만 해주시면 되고, 아래 내용은 보편적인 시스템의 방식으로 ITSM과 JIRA가 구분된 시스템 내에서의 VOC 관리 프로세스를 글로 작성해 보았습니다.
JIRA는 보통 BTS로만 사용하고 있기 때문에 젠데스크라는 도구를 사용하지 않고 있어서 ITSM의 역할을 하지 못하는 경우가 많습니다.
[STEEG - 실무적용편] JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까? #1
목차 JIRA를 BTS(Bug Tracking System)로만 사용하고 있습니까? #1 IT에서 일하고 있다면 Jira에 대해서 한 번쯤 들어 보셨을 겁니다. Jira | Issue & Project Tracking Software | Atlassian Plan, track, and m..
qa-testing.tistory.com
위에 글(IRA를 BTS(Bug Tracking System)로만 사용하고 있습니까?)을 연재 중이니 나중에 참고해 보시면 좋을 것 같습니다.
결과적으로 VOC를 관리해야 하는 이유는 브랜드의 이미지를 만들어 갈 수 있는 부분이기 때문에 꼭 챙겨야 하는 부분입니다. 예를 들어 장애로 인해 카페 등에서 "OO 앱 장애 나서 사용을 못하네요." 이런 글들이 보이기 시작하면 브랜드의 이미지가 낮아질 수 있게 됩니다.
이런 상황을 미연에 방지하고, 예방하고자 VOC를 관리하기 위한 프로세스는 선택 아닌 필수입니다.
모기업에서는 KPI(Key Performance Indicator)를 VOC를 줄이는 것을 통해 품질을 측정하기도 하였습니다.
핵심성과지표 KPI - 제타위키
다음 문자열 포함...
zetawiki.com
VOC 현황 분석
📌 관리 시스템의 이슈 생성 시 VOC 항목을 필수 선택 및 링크
- VOC 수정 개발이 필요한 경우 업데이트 프로세스와 동일
- VOC 긴급 수정이 필요한 경우 구두 협의 필요
- 운영 환경에 영향받지 않도록 배포 일자 및 시간 확인 필요
테스트 요청 계획서 작성(상시 작성)
- 테스트 요청 계획서 작성(상시 작성)
- 담당 부서 : 개발 담당 부서
- 개발 담당자 : 담당 개발자
- 요청일 : 테스트 요청 예정일
- 배포 예정일 : 배포 날짜 및 시간
- 상품명 : 배포 상품명
- 수정 내용 : 수정된 Jira 이슈 링크
테스트 요청
1. Confluence(00. [x.x.x] 테스트 요청서)을 작성하여 테스트 요청
- 프로젝트 사이트맵
- 해당 상품 및 서비스 선택
- 만들기(•••)
- [업데이트] 테스트 양식 선택
2. 00. [x.x.x] 테스트 요청서 작성
- 상품 및 서비스명 : 상품 및 서비스명 작성
- 담당 개발 부서 : 개발 담당 부서
- 담당 개발 파트(장) : 개발 담당 파트
- 테스트 버전 : 테스트 요청 버전(1.0.0.b1 ~)
- 배포 버전 : 출시 버전(1.0.0)
- 테스트 가이드 정보 : 테스트 시 도움이 될만한 정보 입력(영향 범위 등)
- 테스트 요청일 : 테스트 요청 일자
- 심사 등록 희망일 : 오픈마켓의 경우 심사 등록 희망일자 작성
- 배포 예정일 : 배포 예정일자 작성
- 배포 시간 : 예정된 배포 시간 작성(배포 담당자 조율 필요)
- 개발 담당자 : 담당 개발자 이름
- 배포 마켓 : 배포되는 마켓 모두 선택
- 검수 파일 : 빌드 파일 차수별 링크 생성(직접 첨부 X)
- 테스트 정보 : 테스트에 필요한 계정 및 환경 정보
- 테스트 대상 목록 : Jira 이슈 링크
테스트 수행
- Zephyr 테스트 케이스를 통해 테스트 수행 여부 확인
- Jira 이슈 등록(결함, 개선 항목 등)
- 빌드 버전 별 테스트 사이클을 구성하여 테스트 반복 수행
테스트 결과
- Confluence(00. [x.x.x] 테스트 요청서) 하단 테스트 결과 테이블을 통해 결과 공유
- 테스트 완료 시 배포 Task 생성 후 배포 여부를 Jira 이슈를 통해 공유
- 메일로도 배포 여부 공유(인바운드센터)
- [대시보드] 품질관리 메인 홈에서 배포 현황 확인
요약 : 애자일 프로세스, 프로세스, 프로세스 마이닝, 소프트웨어 qa, 웹 qa, 앱 qa, QA 프로세스, 테스트 프로세스, 업무 프로세스 관리
'PROCESS > STEEG TEAM' 카테고리의 다른 글
| [QA : 업무 프로세스 관리] 심플하게 테스트 프로세스 글로만 풀어보기 (0) | 2021.05.15 |
|---|---|
| [QA : 업무 프로세스 관리] 소스 코드에 대한 버전 관리만 하고 있습니까? (0) | 2021.05.13 |
| [QA : 업무 프로세스 관리] "결함 우선 순위"와 "심각도" 활용 : 품질 지표 정량화 하기 (2) | 2020.12.17 |
| [QA : 업무 프로세스 관리] “개발 초기에 테스팅을 시작하라.” (0) | 2020.11.06 |