문제

그래서 저는 상당히 작은 IT 섹션에서 일합니다. 최종 사용자의 약 절반이 사용하는 티켓팅 시스템에 문제가 있습니다. 내 동료 중 일부는 실제로 최종 사용자가 우리가 가지고있는 시스템을 사용하도록 격려하기 위해 많은 노력을 기울이지 않습니다. 최종 결과? 최종 사용자가 IM에 의해 우리를 데려 오거나 사무실에 직접 사무실에 오기 때문에 지속적인 중단. 이것은 분명히 코드를 작성하는 것이 어려울 수 있습니다.

자, 나는 단지 "이봐, 다음에 문제 티켓을 채우고 싶습니까?"라고 말할 수 있다고 생각합니다. 그러나 다른 사람들이 그렇게하지 않기 때문에 나쁜 사람으로 나올 것입니다. 나는 또한 최종 사용자가 내가 접근 할 수 없다고 느끼기를 원하지 않습니다. 나는 그들이 도움을 요청하는 적절한 방법이 있다는 것을 이해하기를 원합니다.

그렇다면 이런 상황에서 가장 좋은 일은 무엇입니까?

도움이 되었습니까?

해결책

그렇게하기 위해 매력적으로 만드십시오.

사용자에게 문제 티켓 문제가 전체 개발 팀에서 볼 수 있으며 상당히 빠르게 고정 된 것으로 밝혀졌습니다. 티켓이없는 것은 셔플에서 길을 잃을 가능성이 있다고 말합니다. 외부 직면 링크를 제공하여 티켓에서 진행 상황과 개발자/지원 의견을 볼 수 있습니다. 이메일 알림을 제공하여 프로세스의 일부인 것처럼 느껴지고 문제에 대한 즉각적인 정보를 가지고 있습니다.

가능한 한 마찰이 없습니다.

시스템의 사용자 입력 부분을 사용하기 쉽고 최대한 직관적으로 만듭니다. 아무도 티켓을 채우는 것을 좋아하지 않습니다 틀림없이 그렇게하기 위해 어떤 후프를 뛰어 넘지 않을 것입니다. 로그인이없고 사인이없고 문제와 연락처 정보를 입력하고 이동하십시오.

팀과 대화하십시오.

궁극적으로, 팀과 동일한 페이지에 있지 않으면 위의 시스템에 대한 많은 노력이 중요하지 않습니다. 팀 회의를 요청하고 문제에 대해 이야기하십시오. 당신의 상사가 참석하면, 그가 이해할 수있는 용어로 그것을 시도하십시오. 소중한 시간 손실, 시스템에없는 고객 문제를 추적하는 문제 등을 언급합니다.

다른 팁

관리자가 도움을 받기 전에 사용자가 티켓을 제출하도록 강요하지 않음으로써 관리자가 실망시키는 것처럼 들립니다. 문제는 거기서 시작되며 동료들에게만 그러한 행동을 허용합니다. 우리는 응용 프로그램 지원을 위해 직장에서 Redmine을 사용하고 사용자에게 "티켓을 제출하면 우리는 그것을 살펴볼 것입니다"라고 말하면서 좋은 진전을 이루었지만 모든 사람들의 일관된 목소리가되어야합니다.

그들에게 약간의 심리학을 사용하십시오. 문제 티켓을 보내지 않는 사람들의 경우 부서에있는 사람들의 80%가 티켓팅 시스템을 사용한다는 것을 상기시켜줍니다. 그것이 거짓말이더라도, 그것은 악 대차 효과 때문에 좋은 행동을 장려 할 것입니다. 사람이 인구 통계 통계에 비해 비슷할수록 행동에 영향을 줄 가능성이 높습니다. 따라서 "직계 동료"는 "이 회사 전체의 사람들"보다 더 잘 작동합니다.

발권 시스템을 사용하는 사람들은 금색 별을 받아야합니다.

2 월 하버드 비즈니스 리뷰에서 사회적 압력을 사용하여 행동에 영향을 미치는 매우 간단한 기사가있었습니다. 새로운 연구에 대해 논의했지만 기사에는 참조가 포함되지 않았습니다.

동료가 시스템을 먼저 사용하도록 설득하지 않으면 많은 진전을 이룰 것입니다. 원하는 프로세스에 동의 한 후에는 사용자와 대화 할 수 있습니다. 팀의 모든 사람이 동일한 규칙에 따라 플레이하는 경우 시스템에 입력되지 않은 문제에 대해 느리게 회전 시간을 가짐으로써 사용자가 시스템을 사용하도록 강요하거나 심지어는 잊어 버릴 수도 있습니다.

그러나 동료와 사용자 모두가 티켓을 입력하도록 설득 할 수 있다고해도 티켓이 불완전하거나 유익하지 않다는 것을 알게 될 것입니다. 우리는 "Feature X가 깨지고 PLZ를 수정"하고 다른 정보를 제공하지 않는 많은 티켓을 보았습니다. 하루에 얻는 티켓의 수에 따라 총알을 물고 사용자를 걸어 가서 문제가 무엇인지 확인할 것입니다.

당신은 그렇지 않습니다. 사용자는 나도 그 일을 싫어합니다. 대신 귀하의 정책은 "나를 생각하지 마십시오"여야합니다. 필요한 모든 것을 수집하고 사용자에게 보이지 않는 방식으로 자동 처리해야합니다. 그들이 설치 한 후에.

우리는 종종 이런 종류의 경우 사용자를 대신하여 티켓을 기록합니다.

나의 오래된 직장에서, 나는 문제 티켓 없이는 아무것도 할 수 없다고 들었다. 이유를 물었을 때, 나는 문제 티켓을 사용하여 지원 팀의 생산성을 측정했다고 들었습니다. 이것은 문제 티켓을 사용하도록 강요하고 (필요했기 때문에) 그렇게 할 동기를 부여하는 효과가있었습니다 (동료들이 나쁘게 보이기를 원하지 않았습니다).

내 새로운 직장에서는 모든 기술 지원이 하청 계약이 저장됩니다. 나는 말 그대로 기술 지원에 전화해야하며, 그들은 저를 대신하여 티켓을 만듭니다.

또한 - 행동을 장려하지 마십시오. IM 필터링 옵션을 사용하여 Dev 팀에 온라인으로 만 나타납니다. 우선 순위가 높은 우선 순위 (보스, 개발자 팀)를받은 편지함에 필터링하는 이메일 또는 하루에 한 번 또는 다른 날에 한 번 확인하는 폴더로 필터링하는 필터를 확인하지 마십시오.

Simucal의 조언은 좋습니다. 당신은 어느 시점에서 대신 "티켓을 제출하라고 말해야합니다. 당신이 사실 후에 그들에게 묻는다면, 그들은 필요한 것을 얻었 기 때문에 신경 쓰지 않을 것입니다.

이것을 처리하는 가장 좋은 방법은 지원을 위해 헌신적 인 사람을 갖는 것입니다. 우리 팀은이 작업을 수행했으며 생산성을 엄청나게 돕고 중단의 90% 이상을 제거했습니다.

그 (또는 대령)를 제외하고, 당신은 각각 사용자 요청을 처리 할 사람에 대해 매일 회전 할 수 있습니다. 이것은 문제 티켓을 더욱 필요로하지 않는 것의 결과를 가지고 있습니다. 다른 사람이 작업을 시작할 때 요청에서 일어난 일을 추적해야합니다. 시간이 지남에 따라 이것은 또한 프로세스에 더 많은 응집력을 제공합니다. 사람들은 일반적인 작업을 수행하기 위해 작은 스크립트를 만들고, 수행되는 작업은 개정 제어 등으로 이동합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top