IssueSticker이 문서가 필요한 경우
- 클라이언트마다 피드백 형식이 달라 QA나 PM이 다시 정리합니다.
- 코드 수정 권한이 없는 사이트와 장기 운영 중인 서비스가 섞여 있습니다.
- 클라이언트가 쓰는 Jira나 Notion으로 결과물을 넘겨야 합니다.
끝나면 확인할 것
- 클라이언트별 프로젝트 경계를 정했습니다.
- 내부 QA가 남기는 이슈와 클라이언트가 직접 남기는 피드백을 구분했습니다.
- 각 클라이언트가 이미 쓰는 처리 도구를 기준으로 연동 대상을 골랐습니다.
무엇이 번거로운가요
클라이언트마다 피드백을 보내는 방식이 다릅니다. 어떤 팀은 메일로 보내고, 어떤 팀은 스프레드시트에 적고, 어떤 팀은 메신저에 캡처를 올립니다. 결국 QA나 PM이 다시 모아서 개발팀이 볼 수 있는 형태로 바꿔야 합니다.
이슈스티커로 줄어드는 일
이슈스티커는 웹사이트 위에서 바로 피드백을 남기게 합니다. 화면 위치와 캡처가 같이 들어오니 “이 버튼이요” 같은 설명도 정확해집니다.
클라이언트가 직접 남길 필요가 있으면 SDK Widget을 프로젝트에 붙이고, 내부 QA가 대신 검수하는 구조라면 Extension으로 시작하면 됩니다.
어떤 제품이 맞나요
코드를 건드릴 수 없는 클라이언트 사이트는 Extension이 안전합니다. 장기 운영하는 자사 서비스나 유지보수 프로젝트라면 SDK Widget을 붙여 클라이언트가 직접 남기게 할 수 있습니다.
외주 프로젝트에서는 “하나의 도구로 전부 통일”보다 “클라이언트별 결과물이 같은 형식으로 도착”하는 것이 더 중요합니다. 수집 채널은 달라도 최종 리포트 형식과 전달 위치를 맞추세요.
바로 해볼 다음 단계
- 클라이언트별로 프로젝트를 나눕니다.
- 각 프로젝트에 도메인을 연결합니다.
- 내부 QA용으로 Extension을 설치합니다.
- 클라이언트가 직접 남길 프로젝트에는 SDK Widget을 붙입니다.
- 전달 방식은 Jira 또는 Notion 중 클라이언트가 이미 쓰는 도구에 맞춥니다.