온라인 헬프데스크로 JIRA Service Desk for JIRA 애드온을 사용해 보십시요

JIRA Service Desk를 사용하여 개발자와 협업하세요


저희는 개발자들이 JIRA를 사랑하는 것을 압니다. 이미 25,000이  넘는 팀들이 업무 추적을 위해 JIRA를 사용하고 있으니까요.  이제 여러분의 서비스 데스크를 더욱 활용해 보세요.

JIRA 는 이미 개발자들이 뛰어난 소프트웨어를 만들 수 있도록 돕고 있습니다. 마찬가지로, JIRA Service Desk 역시 훌륭한 고객 서비스를 제공하도록 합니다. 무엇보다도, 하나의 소프트웨어를 사용해 이 모두를 이끌어 낸다면 더할 나위 없겠죠! 서비스 데스크 팀을 개발 팀과 같은 위치에 두어 개발자에 대한 서비스 데스크의 요청이 원활하게 진행 될 수 있도록 JIRA와 JIRA Service Desk를 활용하세요. 꽤 쓸만한 아이디어 아닌가요?
Icon
  • Service Desk 를 처음 들어보시는 분들을 위해 간단히 설명하면 Service Desk 는 JIRA (프로젝트 관리도구) 의 확장 상용 플러그인 제품으로 온라인 헬프데스크 (고객의 요청 처리)를 처리하는 기능을 담당합니다.

JIRA Service Desk는 여러분의 개발자들이 실제로 사용하길 바라는 서비스 관리 소프트웨어입니다.  그 이유를 아래에서 확인하세요.

JIRA Service Desk 내의 역할(Role)에 대한 빠르고 쉬운 가이드

JIRA Service Desk에는 다음의 세 가지 역할(Role)이 있습니다:
(1) 에이젼트(Agents): 에이젼트는 인바운드 요청을 다루고 고객과 소통하는 역할을 합니다. 에이전트는:
  • Service Desk 프로젝트에 접속할 수 있고
  • 서비스 데스크 요청을 워크 플로우에서 전환할 수 있으며
  • 고객이 볼 수 있는 코멘트를 남길 수 있습니다
(2) 협업자(Collaborators): 협업자는 고객 요청에 대해 여러분의 팀을 지원합니다. 협업자는:
  • Service Desk 프로젝트에 이슈를 살펴볼 수 있고
  • 내부 코멘트를 남길 수 있습니다
(3) 고객(Customers): 고객은 에이젼트가 처리해야 할 요청을 합니다. 고객은:
  • 고객 포털에 접속할 수 있고
  • 자신이 작성한 요청을 볼 수 있으며
  • 코멘트를 남길 수 있습니다

Icon
  • 일반적으로 에이전트는 실제 업무환경에서는 상담원 혹은 고객을 직접 대하는 직원이 될 것입니다.
  • 협업자는 고객의 요청을 처리하는 실무 부서의 내부 개발자 혹은 담당자가 될 것입니다.

단계 1: 개발자를 협업자로 등록하기

개발자인 Emma를 협업자로 등록해 봅시다. Service Desk에서 People 탭을 누르면 나오는 Collaborators 페이지로 갑니다.
맨위 오른쪽 끝에 있는  “Add collaborator"를 선택합니다.
개 발자의 이름이나 email을 입력하기 시작하면 JIRA가 자동으로 사용자를 표시합니다. 여러분이 협업자로 추가하고 싶은 개발자를 찾았다면, 그 이름을 선택하세요. 그리고  “Make user a collaborator” (사용자를 협업자로)를 선택합니다.
다 됐습니다!
Emma는 이제 여러분의 JIRA Service Desk 프로젝트의 협업자가 되었습니다. 그녀는 서비스 데스크 요청을 볼 수 있고, 에이젼트를 돕기 위해 내부 코멘트를 남길 수 있습니다.

단계 2:  JIRA Service Desk를 개발자와 함께 사용하기

우선 모범 사례를 보겠습니다. 아래의 시나리오를 참고하세요:
대 학생인 Mitch는 자신의 브라우져에서 대학 내의 인트라넷을 접속할 수 없는 것에 대한 불만을 제기하고자 자신의 대학 IT팀에 헬프 데스크 티켓을 접수했습니다.  분석가인 Jennifer가 보니 이는 개발자의 도움이 필요한 것이었습니다.
개발자인 Emma가 개입하도록 해봅시다.

스텝 1: 헬프 데스크 이슈를 협업자와 공유하라.
에이젼트는 @를 사용해 개발자를 언급하고 내부 코멘트를 남길 수 있습니다. 그냥 @ 다음에 협업자의 이름을 입력하기만 하면 되죠. JIRA가 자동으로 사용자를 표시합니다.  (tick) JIRA 의 Mention 기능
개발자를 선택하고 메시지를 쓰세요. Emma는 자신의 관심을 요하는 티켓이 있다는 이메일 알림을 받을 것입니다. 에이젼트의 코멘트는 티켓 기록에 저장됩니다. 

스텝 2: 소프트웨어 프로젝트에서 관련된 버그 항목을 만들어라.
JIRA의 헬프 데스크 티켓을 보고 난 후, Emma는 그 오류를 복제하여 인트라넷의 한 버그임을 밝힙니다. 그녀는 자신의 JIRA 개발 프로젝트에 버그 항목을 만듭니다.
저희는 개발자가 서비스 데스크 요청과 별도로 자신의 JIRA 이슈를 생성할 것을 권장합니다. 왜냐하면 JIRA는 제품 팀이 업무를 계획하고 추적하는 것을 돕도록 최적화 되어 있는 반면, JIRA Service Desk는 고객에게 훌륭한 서비스를 제공하고 최적화 하도록 되어 있기 때문입니다. 티켓을 별도로 생성해 놓으면 좋은 다른 이유들로는:
  1. 개발자들이 버그 관리에 대해 자신의 워크플로우를 가질 수 있다는 점.
  2. 여러 서비스 데스크 티켓이 하나의 버그, 서로 다른 문제 관리 그리고 사건 관리와 연결할 수 있다는 점.
  3. 서비스 데스크 분석가는 여전히 고객과 1:1 관계를 유지할 수 있다는 점입니다. 
다음으로, 분석가는 소프트웨어 이슈를 헬프 데스크 티켓과 연결합니다. 한 번 연결되면, 헬프 데스크 에이젼트는 헬프 데스크 티켓을 여는 것만으로 소프트웨어 이슈의 상태를 확인할 수 있습니다. 
Jennifer는 Emma에게 최신 정보를 물어보지 않아도 버그의 상태를 지켜볼 수 있습니다. 그동안 Emma는 자신의 일반적인 JIRA 개발 워크플로우를 사용해 버그를 다룰 수 있죠.

스텝 3: 개발자는 티켓이 종료됐음을 분석가가 알 수 있도록 한다. 
빨리 진행시켜보죠...버그가 해결됐습니다! Emma가 일을 끝냈을 때, 티켓 에이젼트인 Jennifer에게 @맨션을 보냅니다.
Jennifer 역시 헬프 데스크 티켓에서 이슈 상태를 볼 수 있습니다:
근본적인 관련된 문제 이슈가 해결되었을 때, JIRA Service Desk가 자동으로 사건 이슈들을 해결한다면 멋지지 않을까요? 저희는 이를 검토 중입니다. JIRA.Atlassian.com JSD-1199 의 저희 공용 이슈 트래커에서 그 기능에 투표하세요. 
서비스 데스크와 근본적인 버그 간의 또다른 훌륭한 통합 아이디어가 있으신가요? 그렇다면, 꼭 알려주세요!

스텝 4: 에이젼트가 고객에게 버그가 해결되었음을 알린다. 
이제 버그가 없어졌으므로 Jennifer는 고객에게 문제가 해결되었음을 말할 수 있습니다. 그녀는 Mitch에게 회신해 인트라넷이 다시 작동할 것임을 알려줍니다.
Emma 는 문제를 확인하기 위해 JIRA를 벗어나지 않아도 돼 기쁩니다. Jennifer는 Emma에게 듣지 않아도 상태를 볼 수 있습니다. 그리고 Mitch는 당연히 누려야 할 훌륭한 서비스를 받았습니다.  win-win-win이네요.

시작할 준비가 되셨나요?

좋습니다! JIRA Service Desk는 현재 클라우드에서, 혹은 여러분의 네트워크에서 서버로서 무료 평가판을 사용해 보실 수 있습니다.

Icon
  • Service Deks 는 JIRA 의 확장 플러그인이기 때문에 JIRA 라이센스를 필요로 합니다.
  • 기존의 JIRA 사용자는 관리자 메뉴의 Atlassian Marketplace 에서 Service Desk 애드온을 검색하여 평가판을 설치해 사용해 보실 수 있습니다.
  • Service Desk 의 라이센스는 Agent 의 수에 따라 나뉘어 지며 모든 라이센스가 Customer 의 수는 제한이 없습니다. 라이센스의 종류는 ServiceDesk 제품 가격 및 라이센스 를 참조하십시요.


댓글

댓글 쓰기

이 블로그의 인기 게시물

Confluence 내의 스프레드 시트 기능이 필요하시다면 애드온을 활용해 보십시요

이미지
게스트 블로그 - Confluence 안에서의 스프래드 시트 협업과 엑셀의 난제 극복 Luke Kilpatrick  글, 개발자 프로그램 매니져  News ,  Products ,  Confluence 2015년 1월 8일   Spreadsheets for Confluence 의 제조사인  Valiantys  에 게재된 게스트 블로그 포스트입니다. Confluence 는 가히 협업을 위한 모든 것이라 할 수 있습니다. 의견과 데이터, 가치 있는 정보를 팀 전체가 수월하고 어려움 없이 공유하도록 해줍니다. 거의 모든 종류의 정보가 여러분의 페이지 내에 넘쳐나고 또 쉽게 구할 수 있습니다. 그러나 여전히 한 가지는 여러분을 힘들게 합니다. 바로 스프레드 시트입니다.  스프레드 시트는 숫자와 데이터를 고속으로 처리하는데 주로 사용됩니다. 연락처 목록에서 부터 프로젝트 세부까지 어떤 것이든 만들 수 있습니다. 하지만 이를 공유하려고 하면 어떻게 되나요?  끝없는 이메일 스레드. 오래된 버젼의 증식. 조각난 정보. 차선책으로 Confluence에 내장되어 있는 표를 사용할 수도 있는데, 여러분이 원하는 방식으로 데이터를 처리하고 서식을 만들기 어렵습니다. 기쁜 소식은 이제 힘들었던 시절은 끝났다는 겁니다. 고급 표와 스프레드 시트 관리를 위해 갓 출시된 애드온, Spreadsheets for Confluence는 여러분의 문제를 해결해 줍니다. 어떤 제품인지 간단히 소개해 드립니다. Icon Spreadsheets for Confluence 제품은 Valiantys 라는 곳에서 개발한 Confluence 확장 애드온 제품입니다. 저희 골드피처에서 테스트해 본 바로는 1.0 버전이어서인지 아직은 단일 쉬트만을 지원합니다. 이 제품을 포함한 모든 Confluence 확장 애드온 제품은 저희 골드피처를 통해 구매...
자세한 내용 보기

Confluence 페이지의 분류와 관련된 잘 몰랐던 기능 3가지를 확인해 보십시요

이미지
Confluence 정보 보고 관련 크게 개선된 기능 3가지    Confluence 의 사용목적은 간단합니다. 사용자가 업무를 정리하고 문서를 생성하며 팀과 업무 관련 의견을 나눌 수 있는 장소가 되는 것입니다. 팀 전체 또는 회사가 접근할 수 있는 한 장소에 모든 업무를 집중화(하고 정리)할 수 있도록 하는 것입니다. 이번 블로그 소식에서는 최근 배포된  Confluence 5.8 에서 제공되는 기존  매크로 의 크게 개선된 3가지 기능에 초점을 맞추겠습니다. Confluence에서 업무 및 정보를 정리하는 데 도움이 될 것입니다. 1. 레이블 등을 통한 관련 페이지의 정보 표시 레이블  콘텐츠 매크로  ( Content by Label macro ) 는 동일한 페이지 레이블을 사용해 관련 페이지 목록을 동적으로 표시하는 데 탁월합니다. 표시 페이지 관리 기능이 더 좋아졌기 때문입니다. 예를 들어, Confluence 내 고객 면담 내용을 기록한 모든 페이지를 레이블 콘텐츠 매크로를 사용해 목록으로 표시할 수 있습니다. 다음과 같이 페이지 표시 기준 옵션이 추가되었습니다. 특정 페이지 트리의 모든 페이지 또는 일부 페이지 표시 제목이나 페이지 내용에 특정 텍스트가 포함된 페이지 표시 여러 레이블이 조합된 페이지 표시 매크로 설정 대화창에서 표시하려는 정확한 페이지를 검색하고, 표시 내용을 미리보기 해서 필요에 따라 수정할 수 있습니다. 단순히 같은 페이지 레이블에서 페이지 목록을 만드는 것과는 차원이 다릅니다. 어떤 공간에서나 우리 팀 동료를 언급하는 '회의-메모' 라벨이 있는 페이지를 반환하는 간단한 예를 들어 보겠습니다. 2. 강력하면서 자세한 색인 페이지 구축 페이지 속성 및  페이지 속성 리포트 매크로 ( Page Properties Report macro ) 가 연동하면서 한 페이지의 요...
자세한 내용 보기

시스템에 숨어있는 "윤초" 버그에 대해 준비하십시요

  시스템에 숨어있는 "윤초" 버그에 대해 Atlassian 어플리케이션 관리자가 알아야 할 것들 Peter Koczan  글, 수석 지원 엔지니어 JIRA , Confluence , FishEye , Bamboo , Crucible , HipChat , Support , News , Stash 2015년 6월 3일 개요 윤초란 평균 태양시에 맞추기 위해 가끔씩 UTC (세계 협정시)의 1초를 수정하는 것입니다. 가장 최근의 윤초는 2012년 6월 30일 23시 59분 60초에 있었는데 전세계적인 컴퓨터 시스템 고장의 원인이 되었습니다. 윤초에 대해 와이어드 (잡지)에 실린 기사  ‘Leap Second’ Bug Wreaks Havoc Across the Web 를 읽어보세요. 다음번 윤초 수정은 2015년 6월 30일 23시 59분 60초에 있습니다.  Atlassian 어플리케이션에 관한 한, 여러분은 목전에서 그 위험을 벗어나실 수 있습니다. 영향 Atlassian 어플리케이션들은 몇 가지 지원 플랫폼을 통해 간접적으로 이 버그에 영향을 받습니다. 기본적으로, 컴퓨터 시스템들이 항상 윤초를 대비하고 있는 것은 아닙니다. 이 버그는 다양한 소프트웨어- 특히, 특정 버전의 자바, 리눅스 커널, 그리고  MySQL 데이터베이스 서버에 영향을 줍니다.  Atlassian 어플리케이션이 이들에 의존하는 한, 여러분은 시스템에서 몇가지에 대해 주의를 기울여야 합니다.  이 버그의 영향으로 알 수 없는 CPU 사용 및 증가, 어플리케이션 속도 저하, 어플리케이션 충돌, 시동 실패가 일어날 수 있습니다. 비록 최근에는 이 버그가 일으키는 데이터 손실이나 변형에 관련된 어떤 이슈도 접수되지 않았지만, 이로 인해 다음의 어플리케이션/서버가 충돌한다면 그러한 결과를 불러올 수도 있습니다. 영향받는 환경과 제품들 고 객의 자체 네트워크내에서 운영되는...
자세한 내용 보기