사용자 최종 테스트를 원하지 않는 사용자의 기대를 처리
회사 웹 사이트에서 많은 변경을 요청하거나 버그를 지적하는 내부 부서의 사용자가 있습니다. 우리는 매우 밀접하고 강한 유대 관계를 가지고 있지만 최근에는 이러한 변경 사항을 테스트해야하는 것에 화가 나고 있습니다. 그들은 그들을 시간 낭비라고 생각합니다. 최근에받은 이메일에는 다음과 같은 작은 줄이 있습니다.
서비스를 받기 위해 차를 차고로 가져갈 때 차가 작동하는지 테스트하라는 메시지가 표시되지 않습니다.
문제는 변경 / 버그 수정이 긴급하거나 표준 서면 절차 (예 : 표준화 된 매개 변수 변경)를 사용하지 않는 한 변경 또는 버그 수정을 릴리스하기 전에 사용자 테스트 / 확인이 필요한 모델을 따른다는 것입니다.
이 사용자의 기대치를 관리하고 테스트를 완료하거나 확인하는 가장 좋은 방법은 무엇입니까?
답변
보편적 인 대답은 없습니다. 사용자가 웹 페이지에서 맞춤법 오류를보고한다고 가정 해 보겠습니다. "그것은 말한다 TEH 는 말을 할 위치 을 ". 사용자가 오타를 수정했다는 데 동의 할 때까지이 단일 수정의 배포를 보류하지 않습니다.
이제 사용자가 버튼을 "파란색의 두 음영이 더 밝아 지도록"요청했다고 가정 해 보겠습니다. 그것이 도대체 무슨 의미인지 정확하게 추측했는지 확인하도록 요청하는 것이 합리적입니다. 하지만 여기서는 문구가 핵심입니다. "수정 사항을 테스트하고 승인하십시오"는 올바르게 수행했는지 확신하지 못함을 의미하며 "나중에 문제가 발생하면 문제가 발생합니다"라고 약간 들릴 수 있습니다. 더 친근한 "새로운 색상이 마음에 드는지 알려주 시겠어요?", "원하는 것이 맞는지 확인하세요"또는 "내 개발자가 당신을 올바르게 이해했는지 확인하세요"는 더 정확할뿐만 아니라 개발자가 묻는 이유에 대한 설명이 포함되어 있습니다. 클라이언트의 작업을 위해.
또한 클라이언트가 작업을 테스트하는 것을 이해하고 코딩하려는 것을 코딩했는지 확인해야합니다. 클라이언트가 테스트하는 것은 귀하가 요청을 이해했다는 것입니다. 따라서 보고서에 열을 추가하라고 요청하고 원하는 위치를 묻는 것을 잊었습니다. 배달 할 때 "마지막에 추가했습니다"또는 "주문 날짜 옆에 추가했습니다"라고 말한 다음 확인을 요청합니다. 괜찮습니다.
물론,이 모든 것이 "테스트"입니다. 그것을보고 당신이 그것을 좋아하는지 확인하십시오. 그들의 비유를 사용하기 위해 차를 파란색으로 칠하면 아무 말도하지 않고 밝은 빨간색 차에서 운전할 수 없습니다. 따라서 절대적인 긴급 상황을 제외한 모든 경우를 수정하거나 새로운 항목을 추가 한 다음 준비 작업에 올려 놓고 확인한 다음 게시합니다. " confirm it 's good " 이라는 문구를 사용하면 원하는 작업을 많이 수행 할 수 있습니다.
- 그것은 당신이 옳은 일을했다는 가정을 포함합니다. "실수 찾기"에는 실수가 있다는 가정이 포함됩니다.
- 클라이언트가 "테스트"와 같이 지불하는 동사를 사용하지 않습니다.
- 고객이 책임을지는 것에 대해 긴장하게 만드는 동사를 사용하지 않습니다.
우리는 종종 테스트 요청에 특정 세부 정보를 추가합니다. 새 열의 형식이 원하는 것인지 확인하십시오. 개발자가 글꼴 크기에 대해 올바른 선택을했는지 확인합니다. 기본적으로 명시되지 않았기 때문에 스스로 결정해야했고 어떤 이유로 든 전에 묻지 않았기 때문에 결정을 내리고 확인을 요청하십시오. 모호하고 코딩하기 전에 명확하지 않은 부분은 지금 지적하십시오.
이 사용자의 기대치를 관리하는 가장 좋은 방법은 무엇입니까?
문제를 해결하기 전에 문제를 철저히 이해 한 다음 전문적으로 테스트하십시오.
테스트를 위해 최종 사용자를 신뢰해서는 안되며, 출시 전에 오류가 없는지 확인하는 데 관심이있는 전문가가 수행해야합니다.
사용자 수락 단계를 귀하가 아닌 고객에게 이익이되는 것으로 제시해야합니다.
회사에 대한 이점에 대해 이야기하고 있습니다 ( "사용자가 예상 한대로 변경 / 버그가 작동하는지 확인하기 위해 사용자 테스트가 필요합니다.", "사용자 검증 없이는 라이브로 릴리스 할 수 없습니다"). 고객이 당신을 위해 일하는 것처럼 느끼는 것은 놀라운 일이 아닙니다. 이것은 (그들의 마음 속에서) 그들이 원했던 것이 아닌 것을 공개함으로써 처음에 그들의 필요를 해결하지 못한 후에!
이것이 그들에게 도움이되는 프로세스의 핵심 부분임을 설명하는 것으로 시작할 수 있습니다 . "수정"을 발표 했는데도 여전히 수정되지 않았거나 원하는 방식으로 작동한다면 얼마나 더 나빠질 지 상상해보십시오! 실수로 상황을 악화 시켰다고 상상해보십시오 !
애초에 버그를 일으킨 통신의 단절이 분명했습니다. 그들이 원하는 것을 완벽하게 이해했다면, 그 기대에 대해 완벽하게 테스트하고 완벽한 것을 출시했을 것입니다. 그들은 버그를 발견했습니다. 즉, 기능을 요청하고 제공하는 프로세스가 무엇이든 놓친 것입니다. 버그를보고하고 수정하는 프로세스가 무언가를 놓칠 수 없다고 가정하는 것은 합리적이지 않습니다. 현명한 방법은 "이제 우리가 원하는대로 해냈다 고 생각합니다. 맞습니까?"라고 다시 확인하는 것입니다.
이러한 변경 또는 수정에 대해 비용을 지불하는 경우 특히 그렇습니다. 이것은 그들이 돈의 가치를 얻고 있는지 확인할 수있는 기회입니다. 만약 당신이 무언가를 놓아도 여전히 그들이 원하는 것이 아니라면, 당신은 전체 과정을 다시 거쳐서 다시 충전해야 할 것입니다. 출시하기 전에 수정 사항을 확인하는 것이 더 낫지 않을까요?
어쨌든, 그것은 그들에게 이익이없는 시간을 낭비하고 요구하는 것이 아니라 그들의 의견을 가질 수있는 긍정적 인 기회로 설명되어야합니다.
FWIW, 다른 답변과 마찬가지로 비유로 논쟁하는 것은 나쁜 생각이라고 생각합니다. 왜냐하면 실제로 이야기해야 할 문제가 아닌 것에 대해 이야기하기 때문입니다. 그럼에도 불구하고 펑크 난 타이어를 고치기 위해 차를 가져 갔다면 운전하기 전에 타이어를 살펴보고 실제로 고쳐진 것 같았는지 확인했습니다. 그렇지 않으면, 내가 방금 운전을 시작했는데 길 아래에서 평평하다는 것을 알게된다면 차고는 그들이 일을 제대로했다고 말할 수 있고 내가 떠난 후에 새 타이어가 펑크 난 것 같습니다.
서비스를 받기 위해 차를 차고로 가져갈 때 차가 작동하는지 테스트하라는 메시지가 표시되지 않습니다.
아, 재밌 네요. 자동차를 수리점으로 가져갈 때 (웹 사이트 변경 사항이 서비스되지 않음), 여기에는 타이어의 볼 베어링이 완전히 둥글 지 않은 것과 같이 서비스 중에 발견되는 것들이 포함될 수 있습니다.
... 내가 차를 집어 들었을 때마다 실제로 정비사 대표와 함께 시험 주행을 요청 받았습니다 (대표 : 일선 작업자, 매우 작은 샷이 정비공과 고객을 분리하지 않음).
귀하의 고객은 웹 사이트 변경이 서비스를 제공한다고 생각하는 것 같습니다. 그렇지 않다. 서비스는 라이브러리를 패치하는 것입니다. 변경 사항은 자동차 수리 또는 업그레이드와 유사합니다. 그리고 그러한 경우에 시운전을하지 않는다는 구색은 완전히 잘못되었거나 내 경험상 저가형 기계 상점의 사용을 나타냅니다.
그것에 대해 클라이언트와 이야기해야합니다. 또한 웹 사이트 UI 흐름으로의 업그레이드가 실제로 클라이언트가 예상 한대로 작동하지 않을 수 있다는 사실에 대해서도 설명합니다. 당신이 오류를 범하는 것은 아닙니다. 그러나 변경이 정확히 주문 된 것이지만 변경 요청이 "아, 예상대로 작동하지 않습니다"가 뒤따른 횟수를 다시 계산할 수는 없습니다. 이를 조기에 포착하는 것은 워크 플로의 일부입니다.
나는 당신이 그들과 이야기하고 그들의 비교가 저가형 기계 상점의 사용을 더 지적하는 오류라고 설명하는 것이 좋습니다.)
사용자가 지적한 버그 또는 버그를 재현 할 수없는 경우를 제외하고 사용자가 구현하도록 요청한 기능을 테스트하도록 사용자에게 말해서는 안된다고 생각합니다 . 어떤 이유로 든 당신의 끝.
그들이 당신에게 버그를보고 할 때, 당신은 가서 수정을 구현하기 전에 먼저 버그를 다시 만들어야합니다. 그래서 당신은 실제로 버그를 수정했음을 알 수 있습니다. 그런 다음 버그 수정이 배포되면 사용자에게 다음과 같이 알릴 수 있습니다. 수정 사항이 배치되었습니다.
새로운 기능을 요청하는 경우 실제로 기능을 구현하기위한 작업이 진행되기 전에 귀하 / 귀하의 회사는 모든 요구 사항 / 기대를 미리 파악해야합니다. 그들이 원하는 것을 맹목적으로 추측하고 구현 한 다음 테스트하도록 요청하지 않습니다.
당신은 말했다 :
문제는 변경 / 버그 수정이 긴급하거나 표준 서면 절차 (예 : 표준화 된 매개 변수 변경)를 사용하지 않는 한 변경 또는 버그 수정을 릴리스하기 전에 사용자 테스트 / 확인이 필요한 모델 을 따른다는 것 입니다.
그 모델을 따르는 이유는 무엇입니까? 이 모델이 달성하려는 요구 사항 / 목표는 무엇입니까? 누가 제정 했습니까?
이해 관계자가 솔루션을 확인할 수있는 기회 를 제공하는 것이 아이디어라면 이해 관계자 확인 단계에 타이머를 설정하고 이해 관계자가 2 주 동안 솔루션 (테스트 한)을 확인하지 않은 경우 문제 / 작업 항목을 다음과 같이 종료합니다. "완전한".
이 아이디어가 이해 관계자 에게 테스트 를 위임 하는 것이라면 이 특정 이해 관계자가 자신의 직무에 원하는 테스트를 수행하는 것이 포함되어 있다고 믿지 않는 것 같기 때문에 조직도에서이를 확대해야한다고 생각합니다.
일반적으로 문제보고자가보고하는 문제에 대해 문제보고자와 같은 페이지에 있다고 생각하는 경우 시간 제한 전략이 갈 길처럼 보입니다.