By-Design“버그”는 나쁜 표시입니까?

사용자가 의도 한 것에 대한 버그 보고서를 제출하면 나쁜 징조입니까?

그것은 일반적으로 응용 프로그램이 혼란 스럽거나 명확하지 않다는 것을 의미합니까, 아니면 특별히 언급하지 않는 한 일회성 사용자 실수로 분필로 처리해야합니까?

(실제로 그러한 보고서는 없습니다. 이것은 의도적으로 "버그"가 존재하는지 여부에 대한 순전히 가상의 질문입니다.

나쁜 징조입니까? 나는 그것이 가치있는 경고라고 생각하지만, 그것이 일어날 것이라고 생각합니다.

사람들이 나에게 어떤 종류의 피드백을 제출하면 세 가지 버킷으로 필터링하려고합니다.

• 버그
• 기능 요청
• 잘못된 의사 소통

버그

뭔가 분명히 방법이 작동하지 않을 때 버그는 당신이 기대하는 것, 나 방법 사용자가 기대합니다. 나도 이름을 물어 보니 "Scott"에 들어가서 Enter 키를 쳤다. "Hi Joe!"

기능 요청

이것은 "우리가 이것에 대해 이야기 한 적이 없다는 것을 알고 있지만 프로그램은 내가 왼손잡이 인 마우스 제스처를 추론하고 확인 버튼을 화면 왼쪽으로 움직일 수 있습니까?" 이것은 현재 행동 이 사용자와 사용자의 기대 와 모두 일치 하지만 기대치를 변경하고자 할 때입니다.

잘못된 의사 소통

때이다 당신이 시나리오에서 하나 개의 결과를 기대하지만, 사용자는 다른 결과를 기대하고있다. 그들이 단지 그들의 기대를 전달하지 않았지만 그들이 생각한 경우에 이것은 때때로 기능 요청이된다. 때로는 당신의 기대가 틀린 것으로 판명되면 이것이 버그가됩니다.

그러나 많은 경우 사용자에게는없는 지식이 있습니다. "이 화면에서 이름과 성이 같은 기록을 두 번 추가 할 수 있습니다. 분명히 버그입니다!" 귀하의 답변은 다음과 같습니다. "전 세계에 이름과 성이 같은 사람이 많으므로 해당 조합을 고유하게 요구하지 않습니다. 밤에 실행되는 정리 작업이 있으며 가능한 중복 보고서를 이메일로 보냅니다. 고객 서비스에서 이름과 주소가 비슷한 사본을 감지하고 수동으로 확인하도록 요청하는 경우 "

따라서 모든 버그 보고서를 읽어야하지만 대부분의 복잡한 시스템에는 실제로 기능 요청이거나 요구 사항에 대한 잘못된 통신 인 버그 보고서가 있습니다. 실제 세계의 근본적인 복잡성을 이해하지 못하는 것이 아마도 이러한 문제의 가장 큰 원인 일 것입니다.

이것은 지금까지 이전 답변에서 다루지 않았으므로 무지한 사용자 기반의 표시 일 수 있다고 덧붙입니다. 필자는 "무지한"이라는 단어를 경멸 적이거나 과감한 방식으로 사용하지 않으며, 단지 도메인이나 소프트웨어 자체의 복잡성에 대한 적절한 지식이나 교육이 없음을 표현하는 방법으로 사용됩니다.

대부분의 사용자는 특정 요구 사항을 충족하기 위해 소프트웨어가 얼마나 복잡한 지 잘 모릅니다. 80 %의 노력으로 인한 효과는 기능의 20 % (프린지 및 예외 경우)에만 적용됩니다.

그들은 때때로 소프트웨어가 본질적으로 특정 방식으로 여러 번 결함이나 데이터 손상 등을 방지하기 위해 행동 해야하는 이유를 이해하지 못합니다 ...

명확하고 간결한 문서와 커뮤니케이션으로 더 나아 지므로 걱정하지 않아도됩니다.

해당 분야의 전문가 인 사용자에게는 큰 문제가있을 수 있습니다. 설계 상 소프트웨어를 찾는 회계사가 일반 회계 절차를 따르지 않거나 잘못된 공식을 발견 한 엔지니어를 상상한다고 상상해보십시오. 이것이 올바른지 조사하기가 너무 어렵지 않아야합니다. 필요한 경우 재 설계하고 수정하십시오.

적어도 더 많은 피드백을 얻을 때까지 특정 UI 기능이나 통화 기호 또는 다른 형식이 있어야한다고 생각되는 필드에 대한 의견을 고려해야합니다. 이것을 연구하는 것은 조금 더 어려울 수 있습니다.

내 경험에 의한 디자인 버그는 사용 사례가 실제 사용자에게 맞지 않음을 의미합니다. 실제 사용자를 유스 케이스에 사용하는 것에 대해 읽으십시오 (이름과 썸네일 설명만으로도 유스 케이스의 품질이 궁금합니다).

저명한 OS 벤더가 "이것은 의도적으로 설계된 동작"이라고 말하면 일반적으로 구현의 용이성 또는 상업적 이점을 염두에 두었습니다. 그렇지 않은 경우 사용자에게 실제 기술과 소프트웨어와의 관계를 찾아보십시오. 그들은 하루 종일 그것을 사용합니까? 재미를 위해? TPS 양식을 대체했기 때문에 일주일에 한 번?

UI는 최소한 놀랍게도의 원칙을 따라야합니다 . 설계된대로 작동하는 기능에 대한 반복 된 버그 보고서는이 원칙이 올바르게 준수되지 않았 음을 나타냅니다.

두 가지 종류의 버그가 있습니다. 기능이 프로그래머의 의도와 일치하지 않거나 기능이 요구 사항과 일치하지 않습니다. 프로그래머는 전자를 후자에 해를 끼치는 데 집중하는 경향이 있습니다. 간단히 말해, 사용자가 많은 "설계 상 버그"를보고하는 경우 요구 사항은 생각과 다릅니다.

반드시 그런 것은 아닙니다. 보고 된 버그가 원래 정의 된 범위를 벗어난 소프트웨어를 사용 중일 수 있습니다. A, B 및 C를 수행하도록 설계된 소프트웨어를 고려하십시오 (사소한 예에서는 선, 삼각형 및 사각형 그리기). D가 논리적 다음 단계 (예 : 오각형) 인 경우 사용자는 그렇게해야한다고 가정 할 수 있으며 그렇게하지 않는 것은 버그라고 생각할 수 있습니다. 그러나 이것이 원래 범위를 벗어나면 버그가 아닙니다. 대신 디자인의 감독 (버그), 사양의 회색 영역 또는 개발자와 사용자가 만든 다른 가정이 될 수 있습니다.

(편집-@Marjan Venema의 제안에 따라 답변에 내 의견을 추가했습니다.

나는 디자인이 일반적이지 않고 사용자 요구 사항이 완전히 이해 / 분석되지 않았기 때문에 그 나쁜 징조를 믿습니다.

우연히 디자인이라는 두 가지 범주의 디자인을 봅니다. 의도적으로 디자인.

우연히 디자인하면 이러한 문제가 자주 발생하고 지속될 수 없습니다.

사용자의 "무지"에 대한 maple_shaft의 답변에 추가하고 싶습니다. 또한 사용자의 90 %가 자신의 경험과 시스템 사용 방법 만 신경 써야한다는 점을 명심해야 합니다. 그들은 다른 사용자를 신경 쓰지 않습니다. 왜 그럴까요? 디자이너 / 개발자로서 모든 종류의 사용자로부터 의견을 수렴하고 가능한 한 모든 사람에게 적합한 것을 만드는 것이 우리의 임무입니다. 대부분의 경우 모든 사람에게 최적의 솔루션을 만들 수는 없습니다.

그러나 물론 사용자의 의견을 읽고 평가해야합니다! 그들은 결국 당신의 창조물을 사용하는 사람들입니다!

버그 요청을 제출 한 사용자는 일반적으로 디자인에 대해 문의하지 않았으므로 의도적으로 디자인 결정을 한 버그로 간주하는 것은 놀라운 일이 아닙니다. 사용자에게 예상대로 작동하지 않는 것은 버그입니다.

문제는 종종 BA 또는 PM이 실제 사용자가 아닌 관리자의 요구 사항 만 가지고 있다는 신호입니다. 관리자가 시스템에 대해 기대하는 것은 종종 데이터를 입력하는 사람들이 실제로 필요한 것과 크게 다릅니다. 나는 실제 사용자들로부터 직접 데이터를 수집하도록 배웠지 만, 최근에 만난 대부분의 학사들은 단지 관리자들 (그리고 일반적으로 상대적으로 고위 관리자들) 과만 대화합니다.