Skłanianie użytkowników do pisania przyzwoitych i przydatnych raportów o błędach

Czy ktoś zna dobry sposób na nakłonienie użytkowników do napisania pół przyzwoitego (czytaj: przydatnego ) raportu o błędzie ?

Chcieliśmy stworzyć coś, co miałoby sens dla większości użytkowników (aby było łatwe do odczytania i zrozumienia), a jednocześnie dawało przydatne informacje również programistom.

To nie działa, kiedy kliknę niebieski przycisk! Ahhh, właśnie straciłem tydzień pracy ... spraw, żeby działała.

nie jest bardzo przydatne, ponieważ jest.

Zacząłem naprawiać listę, ale zastanawiałem się, czy podobna metoda już istnieje.

Najbardziej skutecznym sposobem na zachęcenie użytkowników do pisania przyzwoitych i przydatnych raportów o błędach jest

1. aby mogli zobaczyć swoje raporty online ...
   ^{[System] Dziękujemy za zgłoszenie, możesz znaleźć status swojego żądania tutaj: ...}
2. ... wraz z oceną i komentarzami przypisanego inżyniera ...
   ^{[Inżynier] Żądanie odrzucone, ponieważ brakuje następujących szczegółów: ...}
3. ... z opcją edycji / ulepszenia raportu.
   ^{[Użytkownik] Żądane szczegóły zostały dodane, proszę ponownie ocenić: ...}

Posunąłbym się nawet do stwierdzenia, że ​​jest to jedyny skuteczny sposób.

Spójrzmy prawdzie w oczy, umiejętność skutecznego pisania raportów o błędach pochodzi tylko z doświadczeniem. Trzeba nauczyć się zdobywać doświadczenie. Uczenie się polega na ćwiczeniu, uzyskiwaniu informacji zwrotnych i doskonaleniu.

Raporty o błędach online, które można edytować przez użytkownika, są najbardziej wydajnym sposobem na nauczenie użytkowników, jak poprawić .

• ^{Alternatywnymi opcjami powyżej są 1), aby zorganizować sesje uczenia się twarzą w twarz z użytkownikami (tak, szczególnie, gdy na całym świecie są ich tysiące). Lub 2) wyjaśnij im rzeczy przez telefon („spójrz, jeśli zobaczysz tylko bzdury, które napisałeś na linii 225 ...”). Co jeszcze? Och 3) przez e-mail, pewnie "w mailu, który przesłałeś nam dwa miesiące temu, wspomniałeś ... nie, nie ten e-mail, wysłałeś nam pięć e-maili tego dnia, trzy z nich dotyczyły tematu Re: kliknij niebieski przycisk , spójrz na drugi, ten z dołączonym zrzutem ekranu 10 Mb ... czego? nie możesz go znaleźć? "}

Moim zdaniem, ważniejsze jest użycie błędu w celu ustalenia sensownego kontaktu z użytkownikiem. Pisanie i rozumienie zgłoszeń błędów to umiejętność, a moją radą powinno być ułatwienie użytkownikowi pierwszego kontaktu, a następnie stopniowe przekazywanie opinii o większej wartości w razie potrzeby.

Na przykład, po prostu pobierz adres e-mail użytkownika i podaj mu zwykły tekst z następującym tekstem do wypełnienia:

"I did _____ , and expected ______ to happen, but ______ happened instead."

Po otrzymaniu wiadomości e-mail wykonaj automatyczną odpowiedź, aby uzyskać podwójne potwierdzenie, że przesłali błąd, otrzymałeś go, a dalsze działania w sprawie błędu są w porządku.

Możesz rozważyć skorzystanie z pomysłów Mozilli i Sun na ten temat:

• Wskazówki dotyczące pisania błędów - artykuł Mozilla MDN
• Jak napisać odpowiedni błąd - artykuł Mozilla QMO
• Jak napisać pomocny raport o błędzie - artykuł Sun SDN

W szczególności (ze strony Mozilli „Jak napisać poprawny błąd”):

Ogólny zarys raportu o błędzie

Podsumowanie : Jak opisałbyś błąd w mniej niż 60 znakach? Powinien szybko i jednoznacznie zidentyfikować raport o błędzie, a także wyjaśnić problem, a nie sugerowane rozwiązanie.

Dobrze : „Anulowanie okna dialogowego kopiowania pliku powoduje awarię Menedżera plików”

Źle : „Awarie oprogramowania”

Źle : „Przeglądarka powinna działać z moją witryną”

Składnik : w której części oprogramowania istnieje? To pole jest wymagane do przesłania raportu o błędzie. Kliknij słowo „Komponent”, aby zobaczyć opis każdego komponentu. Jeśli żadne nie wydaje się odpowiednie, zaznacz element „Ogólne”.

System operacyjny : w którym systemie operacyjnym (OS) go znalazłeś? (np. Linux, Windows XP, Mac OS X.) Przykład: „Jeśli wiesz, że błąd występuje w więcej niż jednym typie systemu operacyjnego, wybierz„ Wszystkie ”. Jeśli twojego systemu operacyjnego nie ma na liście, wybierz Inne ”.

Opis : szczegóły raportu o problemie, w tym:

- Przegląd : Jest to bardziej szczegółowe przekształcenie podsumowania. Przykładem może być: „Przeciągnięcie zaznaczenia dowolnej strony powoduje awarię kompilacji Maca w funkcji NSGetFactory”.

- Identyfikator kompilacji : Aby to znaleźć, przejdź do strony „about:” za pomocą paska lokalizacji lub, jeśli masz rozszerzenie Nightly Tester Tools MozQA, przejdź do Narzędzia | Nightly Tester Tools i wybierz opcję zawierającą dane wyjściowe identyfikatora kompilacji. Powinno to wyglądać mniej więcej tak: „Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20090305 Firefox / 3.1b3 ″.

- Dodatkowe kompilacje i platformy : czy błąd występuje na innych platformach (lub przeglądarkach, jeśli dotyczy). Powinno to wyglądać mniej więcej tak: „Nie występuje w Mozilli / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20081107 Firefox / 3.1b2 ″.

Kroki do odtworzenia : zminimalizowane, łatwe do wykonania kroki, które spowodują błąd. Jeśli są konieczne, koniecznie dołącz specjalne kroki konfiguracji. Dobry przykład może wyglądać następująco: 1) Wyświetl dowolną stronę internetową. (Użyłem domyślnej przykładowej strony, http://www.google.com/ ). 2) Przeciągnij i wybierz stronę. W szczególności, przytrzymując przycisk myszy, przeciągnij wskaźnik myszy w dół z dowolnego punktu w obszarze zawartości przeglądarki na dół obszaru zawartości przeglądarki.

Rzeczywiste wyniki : Co zrobiła aplikacja po wykonaniu powyższych kroków. Przykładem może być: aplikacja uległa awarii.

Oczekiwane wyniki : To, co aplikacja powinna była zrobić, gdyby błąd nie był obecny. Przykładem może być: okno powinno przewijać się w dół. Należy przewijać zawartość. A przynajmniej aplikacja nie powinna ulec awarii.

Jest Jak zgłaszać błędy Skutecznie Simon Tatham. To ładnie wyjaśnia rzeczy, aby ułatwić zrozumienie dla mniej doświadczonych użytkowników. Minusem jest jednak to, że jest to całkiem sporo tekstu. Gdy użytkownik próbuje zgłosić problem, ale go nie wyjaśnia, zazwyczaj nie będzie w stanie go przekonać do przeczytania tego wszystkiego.

Możesz zadać użytkownikom łatwe do zrozumienia i odpowiedzi na pytania, oczekując użytecznych raportów.

Na przykład: „Jakie było Twoje ostatnie działanie przed tym błędem?”, „Czy próbowałeś ... tuż przed tym błędem?”.

Żaden użytkownik nie napisałby Ci raportu o błędzie, takiego jak: „Mój sterownik wideo nie jest zaktualizowany. Twoja biblioteka grafiki może nie być kompatybilna ze starymi sterownikami graficznymi”.

Zakładając, że bazą użytkowników są użytkownicy końcowi, którzy mieli problem z oprogramowaniem, które napisaliście ....

Nie jest zadaniem twoich użytkowników stanie się biegłym inżynierem oprogramowania lub specjalistą ds. Testowania i nie powinieneś ich oczekiwać. Twoimi użytkownikami są przeciętni ludzie, którzy słusznie oczekują, że oprogramowanie „po prostu działa”. Kiedy tak się nie stanie, będą zgłaszać wszystko, co według nich będzie miało na celu zwrócić uwagę. Nie możesz tego zmienić i nie powinieneś tego robić. Każda próba nalegania na zgłoszenie, jakiego oczekuje się od specjalisty, spowoduje utratę raportu o błędzie, a klient - „Miałem problem z tym oprogramowaniem, ale zamiast mi pomóc, wypełniłem wszystko rodzaj bezużytecznych form, które nic nie znaczą i nie mają dla mnie żadnej wartości. Poszukam oprogramowania, które faktycznie działa. "

tzn. to nie jest ich praca .....

Jeśli chcesz mieć dobre raporty o błędach, zatrudnij specjalistów, aby znaleźć swoje błędy. Jeśli jako twórca oprogramowania nie przejmujesz się kontaktami z klientami, zatrudnij kogoś, kto może.