문제 보고 및 해결을 위한 간편한 워크플로

(협찬 포스팅입니다.) 웹 개발 과정에서 오류, 버그, 기타 문제가 발생하기 마련입니다. 완전한 오류가 아니더라도 클라이언트는 종종 무언가가 디자인된 방식, 배치된 위치 또는 특정 요소의 작동 방식에 대한 피드백을 받습니다. 공연의 일부일 뿐입니다.

공연에서 매우 고통스러운 부분이기도 합니다.

이 시나리오를 예로 들어 보겠습니다.

고객의 이메일 #1: “버튼이 더 이상 보이지 않습니다. 홈페이지에 다시 올려주시겠습니까?”

이메일 #2: “어떤 버튼을 말씀하시는 건가요? 스크린샷을 보내주시겠습니까?”

고객에게 전화를 걸지만 대신 음성 메일을 받습니다.

고객으로부터 이메일 #3: "데모 예약 버튼."

첨부된 스크린샷을 보고 데모 예약 섹션이 손상되지 않았지만 버튼이 표시되지 않는 것을 볼 수 있습니다. Chrome과 Safari에서 웹사이트를 불러와 두 브라우저 모두에서 볼 수 있습니다. "데모 예약"이라고 표시된 큰 파란색 버튼입니다. 당신은 당신의 아이폰에 그것을 당겨 거기에서도 볼 수 있습니다.

이메일 #4: "어떤 기기와 브라우저에서 문제가 발생하는지 알려주실 수 있나요?"

고객의 이메일 #5: "내 전화."

이 일련의 메시지가 어떻게 진행될지 알고 있으며 양쪽 끝에서 좌절만 초래할 뿐입니다. 버그 보고서를 해석한 다음 작업을 수행하기 위해 작업을 일시 중지해야 할 때마다 비즈니스에 드는 비용은 말할 것도 없습니다.

그런 다음 생각해야 하는 클라이언트에 대한 버그 비용이 있습니다. 출시 후 문제가 발생하고 클라이언트가 웹사이트에 트래픽을 적극적으로 전송하려고 하면 버그로 인해 매출이 저하될 수 있습니다.

그런 일이 생기면 누가 뒤를 쫓을 것 같습니까?

문제 보고 및 수리를 위한 간편한 워크플로

버그나 문제의 크기는 중요하지 않습니다. 탐지 및 보고되면 처리해야 합니다. 여러 가지 이유가 있습니다.

우선, 클라이언트가 프로젝트를 완료된 것으로 승인하도록 하는 유일한 방법입니다. 또한 신속하고 즉각적인 버그 해결을 통해 고객의 비즈니스를 위해 인상적이고 오류가 없는 웹사이트를 만드는 데 얼마나 투자했는지 알 수 있는 고객과의 더 나은 관계를 유지할 수 있습니다. 물론 오류를 더 효율적으로 해결할수록 이 작업을 더 빨리 끝내고 다른 작업으로 넘어갈 수 있습니다!

따라서 이러한 문제를 보다 효과적이고 고통 없이 해결하기 위해 해야 할 일은 다음과 같습니다.

1. 누군가를 심사에 할당
2. 문제 해결 워크플로 사용
3. 사용자에게 버그 보고 도구 제공
4. 분류 관리자에게 추적 플랫폼 제공
5. 로컬 테스트 플랫폼에서 작업
6. 항상 루프를 닫으십시오

1. 누군가를 분류하도록 지정

가장 먼저 할 일은 문제를 분류할 사람을 결정하는 것입니다.

당신이 스스로 일한다면 그 책임은 당신에게 있습니다. 팀에서 작업하는 경우 팀의 작업 부하를 관리하는 것만큼 효과적으로 보고된 문제를 관리할 수 있는 프로젝트 관리자 또는 개발 책임자에게 문의해야 합니다.

이 사람은 다음을 담당하게 됩니다.

• 보고된 문제에 대한 모니터링.
• 대기열에 버그를 추가합니다.
• 해결 워크플로를 통해 안내합니다.
• 버그 보고서를 해결하고 닫습니다.
• 추세를 분석하고 프로세스를 수정하여 반복되는 버그가 다시 나타날 가능성을 줄입니다.

누가 프로세스를 관리할지 알게 되면 워크플로를 설계하고 이를 중심으로 일련의 도구를 구축해야 합니다.

2. 문제 해결 워크플로 사용

분류 관리자는 혼자서 이 작업을 수행할 수 없습니다. 그들은 각 문제를 A 지점(탐지)에서 B 지점(해결)으로 가져오기 위해 밀접하게 따를 수 있는 프로세스가 필요합니다.

모든 단계를 다뤘는지 확인하려면 Lucidchart와 같은 시각화 도구를 사용하여 워크플로의 단계 또는 단계를 배치하세요.

다음은 순서도가 어떻게 보이는지 보여주는 예입니다.

분해해 보겠습니다.

문제가 감지된 위치와 보고된 채널을 식별하는 것부터 시작합니다. 이 예는 너무 구체적이지 않지만 감지된 새로운 문제가 앞에서 언급한 문제라고 가정해 보겠습니다 . 홈 페이지에 데모 예약 버튼이 없습니다.

다음으로 해야 할 일은 "누가 그것을 찾았습니까?"라는 질문에 답하는 것입니다. 대부분의 경우 이것은 고객이 버그 추적 소프트웨어에서 제출한 피드백입니다(자세한 내용은 곧 설명).

다음으로 문제가 진행되는 다양한 단계로 이동합니다.

이것은 분류 관리자가 Book Demo 버튼 누락 문제가 얼마나 심각한지 결정하는 프로세스의 일부입니다(클라이언트 전환 비용이 발생하므로 "심각함"). 그런 다음 개발자에게 전달하여 확인합니다.

문제를 해결하는 데 사용할 수 있는 개발자 또는 주제 전문가의 수에 따라 버그 유형(예: 기능 손상과 디자인 업데이트)에 따라 이 단계를 나눌 수도 있습니다.

그럼에도 불구하고 버그가 확인되고 어떤 상황에서(예: iPhone 7 또는 이전 버전에만 있는 경우) 티켓은 "진행 중"으로 이동됩니다.

마지막으로 순서도는 해결할 수 있는 문제에 대한 후속 단계를 구분해야 합니다.

이 단계의 이름은 원하는 대로 지정할 수 있습니다. 위의 예에서 각 단계는 발생해야 할 일을 매우 구체적으로 설명합니다.

• 새로운 문제
• 진행 중
• 테스트
• 고치다
• 검증
• 해결하다
• 루프를 닫습니다.

일을 단순화하기 위해 대신 다음과 같은 해결 흐름을 사용할 수 있습니다.

• 새로운 문제
• 할 것
• 행위
• 완료
• 보관소.

그러나 패치 워크플로를 설정하기로 선택했지만 티켓을 닫기 전에 버그 패치가 테스트 및 확인되었는지 확인하십시오.

3. 사용자에게 버그 보고 도구 제공

웹사이트를 위한 버그 보고 도구를 선택할 때 팀과 고객이 피드백을 쉽게 남길 수 있고 더 쉽게 처리할 수 있는 도구가 필요합니다.

이를 잘 수행하는 도구 중 하나를 BugHerd라고 합니다.

기본적으로 BugHerd는 비기술적인 사람들이 시각적으로나 상황에 따라 문제를 보고할 수 있는 간단한 방법입니다. 버그 보고 도구를 사용하는 방법이나 사용 방법에 대해 사용자를 교육할 필요가 없으므로 이 프로세스에서 시간을 할애해야 하는 일이 한 가지 줄어듭니다.

게다가, BugHerd는 피드백이 문맥에 맞지 않고 구두로 전달될 때 발생하는 끊임없는 주고받기를 처리해야 하는 수고를 덜어줍니다.

그러나 BugHerd를 사용하면 사용자가 책상에 스티커 메모를 남기는 것처럼 쉽게 웹사이트에 피드백을 게시할 수 있습니다. 또한 피드백은 버그가 있는 정확한 위치에 고정됩니다.

작동 방식을 보여 드리겠습니다.

고객의 웹사이트를 BugHerd에 처음 추가할 때(첫 번째 단계), BugHerd 브라우저 확장을 설치하라는 메시지가 표시됩니다. 이것이 BugHerd가 웹사이트에 피드백 바를 고정할 수 있게 해주는 것입니다.

다음과 같이 보입니다.

이 고정된 피드백 표시줄을 사용하면 고객이 실제 웹사이트를 실제로 변경하지 않고도 매우 쉽게 피드백을 남길 수 있습니다.

버그 추적기 팝업은 다음과 같습니다.

보시다시피 매우 단순한 형태입니다. 그리고 실제로 클라이언트가 해야 할 일은 페이지에서 버그가 포함된 요소를 선택한 다음 세부 정보를 입력하는 것입니다. 나머지는 심사 관리자가 채울 수 있습니다.

새 피드백이 추가되면 댓글은 댓글을 남긴 페이지에 고정됩니다. 예를 들어:

또한 위의 스크린샷에서 심각도 수준이 할당된 작업이 그렇게 표시되어 있음을 알 수 있습니다. 또한 얼마나 중요한지 위에서 아래로 나열됩니다.

귀하의 의견을 볼 위치에 대한 선택권은 귀하에게 있습니다. 사이트를 열고 각 페이지에 고정된 메모를 검토할 수 있습니다. 또는 BugHerd 앱으로 이동하여 Kanban 보드의 댓글을 검토할 수 있습니다.

기본적으로 모든 버그는 백로그를 입력하여 시작합니다. 각 버그를 누락된 세부 정보로 채우고 개발자에게 할당하고 해결 단계를 통해 이동하는 것은 분류 관리자의 작업입니다.

즉, BugHerd는 버그 보고서를 캡처하는 더 지루한 작업을 많이 수행합니다. 예를 들어, 간판 보드에서 보고된 버그를 클릭하면 다음 "작업 세부 정보" 사이드바가 나타납니다.

이 패널은 문제에 대한 추가 세부 정보를 제공하고 사이트에서 문제가 있는 위치에 대한 스크린샷을 보여주며 누가 댓글을 남겼는지 알려줍니다.

또한 BugHerd는 "추가 정보"를 캡처합니다.

이렇게 하면 클라이언트가 문제의 전체 컨텍스트를 제공하지 않는 것에 대해 걱정할 필요가 없습니다. 이러한 세부 정보는 사용 중인 장치 및 브라우저, 화면 크기 및 보고 있는 색상 해상도를 알려줍니다.

또한 buggy 요소의 코드를 살펴봅니다. 실제로 깨지거나 부적절하게 코딩된 것이 있는 경우 여기에서 발견할 수 있습니다.

대체로 BugHerd는 모든 사람이 모든 면에서 해야 하는 일을 단순화하고 각 요청이 적시에 처리되도록 하는 훌륭한 도구입니다.

4. 분류 관리자에게 추적 플랫폼 제공

이 워크플로를 최대한 단순하게 유지하려면 BugHerd 대시보드를 사용하여 요청을 추적하고 관리할 수 있습니다.

분류 관리자와 개발 팀은 아마도 BugHerd의 버그 보고 기능을 보완하기 위해 무언가를 사용하기를 원할 것입니다. 그러나 클라이언트에게 버그 관리를 돕기 위해 Jira와 같은 플랫폼을 사용하도록 요청하는 것은 행운입니다.

이 경우 이 워크플로에 다른 도구를 추가하는 것이 좋습니다.

다행히 BugHerd는 Jira, Zendesk 및 Basecamp와 같은 문제 추적 및 헬프데스크 소프트웨어와 원활하게 통합되므로 동일한 프로세스의 여러 부분을 관리하기 위해 여러 도구를 사용하는 것에 대해 걱정할 필요가 없습니다. 두 플랫폼이 연결되면 BugHerd에서 생성된 모든 작업이 자동으로 문제 해결 센터로 복사됩니다.

이제 팀에서 이미 사용하고 있는 도구가 있지만 해당 BugHerd가 직접 통합되지 않아도 괜찮습니다. Zapier를 사용하여 더 많은 플랫폼과 연결할 수 있습니다.

예를 들어, 새로운 BugHerd 작업을 Trello 카드에 복사하는 "zap"을 즉시 생성하는 것이 얼마나 쉬운지 알 수 있습니다. 그리고 이 모든 것이 BugHerd 내에서 이루어집니다!

연결이 설정되면 분류 관리자는 선택한 작업 관리 또는 문제 추적 플랫폼에서 작업을 시작할 수 있습니다. 이 경우 Zapier가 BugHerd와 Trello를 연결하면 다음과 같은 일이 발생합니다.

이것은 내가 BugHerd에서 방금 만든 새로운 작업입니다. 몇 초 안에 카드는 내가 zap을 구성한 정확한 Trello 프로젝트 및 목록에 배치되었습니다.

이렇게 하면 BugHerd에서 사용할 수 있는 단계에 의해 제한되지 않으면서도 여전히 동일한 정보를 손쉽게 사용할 수 있으므로 분류 관리자의 작업이 훨씬 쉬워집니다.

5. 로컬 테스트 플랫폼에서 작업

버그가 보고되면 실제 웹 사이트에서 가정된 수정 사항을 테스트하고 구현하고 싶지 않습니다. 그건 너무 위험해요.

대신 로컬 테스트 플랫폼에서 문제를 해결하는 작업을 하십시오. 이 기사에는 이를 위해 사용할 수 있는 WordPress용 로컬 개발 도구에 대한 몇 가지 훌륭한 제안이 있습니다.

이 도구를 사용하면 다음을 수행할 수 있습니다.

• 웹사이트를 빠르게 복사하세요.
• 동일한 서버 조건으로 버그를 재현합니다.
• 작동하는 수정 사항을 찾을 때까지 가능한 수정 사항을 테스트합니다.

그런 다음에야 웹사이트에서 버그 패치 작업을 해야 합니다.

6. 항상 루프를 닫으십시오

마지막으로, 각 문제를 공식적으로 종료하는 것은 분류 관리자에게 달려 있습니다.

먼저 문제를 처음 보고한 클라이언트(또는 방문자)에게 문제가 해결되었음을 알려야 합니다. 이러한 종류의 투명성과 책임성은 에이전시를 보다 세련되게 보이게 하는 동시에 처음에 버그를 발견하여 불안해할 수 있는 고객과의 신뢰를 구축하는 데 도움이 됩니다.

클라이언트 측에서 작업을 종료하면 분류 관리자가 버그 보고서를 보관할 수 있습니다.

그렇다고 여기서 끝나지 않아야 합니다.

기존 프로젝트 관리자와 마찬가지로 분류 관리자는 웹 사이트에서 발견된 버그의 전반적인 심각성과 추세를 정기적으로 추적해야 합니다. 데이터는 더 깊은 문제가 있음을 드러낼 수 있습니다. 그렇게 하면 팀은 근본적인 문제를 해결하는 데 집중하고 같은 종류의 버그와 문제를 수정하는 데 너무 많은 시간을 소비하지 않을 수 있습니다.

마무리

문제와 버그가 보고될 수 있는 모든 방법에 대해 생각해 보십시오. 문의 양식, 이메일, 전화, 채팅 또는 더 나쁜 것은 소셜 미디어와 같은 공개 포럼입니다.

이제 팀, 클라이언트, 클라이언트의 고객, 웹사이트를 보다가 우연히 발견한 사람 등 이러한 문제를 보고할 수 있는 모든 다른 사람들에 대해 생각해 보십시오.

이 방정식에는 너무 많은 변수가 있어 미해결 문제를 놓치기 쉽습니다. 설상가상으로 피드백이 모호하거나 주관적이거나 맥락 없이 설명할 수 없는 경우 문제를 완전히 또는 적시에 해결하기가 너무 어려워집니다.

그러나 적절한 보고, 추적 및 피드백 구성 시스템을 사용하면 이러한 혼란에 질서를 부여하고 웹사이트에서 발견된 버그를 보다 효과적으로 제거할 수 있습니다.