Czy „błędy” według projektu są złym znakiem?

29

Czy to zły znak, jeśli użytkownicy przesyłają raporty o błędach dotyczące rzeczy zaprojektowanych?

Czy zazwyczaj oznacza to, że aplikacja jest myląca lub niejasna, czy powinienem po prostu przypisać to jednemu błędowi użytkownika, chyba że wyraźnie zaznaczono inaczej?

(Tak naprawdę nie mam takich raportów. Jest to czysto hipotetyczne pytanie, czy istnienie „błędów” według projektu jest złe.)

Maks
źródło
19
Być może niektórzy programiści z Lotus Notes chcieliby komentować, ponieważ standardowa odpowiedź brzmi: „to nie jest błąd, to funkcja, której nie rozumiesz”.
James Anderson
5
Sugeruje mi to, że wymagania użytkowników podane programistom nie odpowiadają tym, o co użytkownicy myślą, że o to prosili.
temptar
7
@temptar „O to prosiłem, ale nie o to mi chodziło”.
StuperUser,
5
Niedawno przydzielono mi element roboczy „błąd” z powodu zachowania, które było dokładnie określone w specyfikacji (i które zostało omówione na etapie specyfikacji). Chociaż zachowanie mogło być bardzo nieoczekiwane z punktu widzenia użytkownika (szczególne ustawienie, na które zwrócono uwagę gdzie indziej, było ignorowane), jeśli specyfikacja dosłownie wszystko mówi „zignorujmy to na razie, aby zaoszczędzić czas”, dla mnie to nie błąd, ale prośba o zmianę. Z pewnością można uzasadnić chęć zmiany, ale nie nazywaj tego błędem .
CVn
7
@Dunk: Wdrożyłem system, który zakładał 24 godziny na dobę, ponieważ nie udało nam się przekonać klienta o istnieniu czasu letniego. Po prostu nie uwierzą, że są dni z 25 godzinami. Czy to błąd w programie?
MSalters

Odpowiedzi:

54

Czy to zły znak? Myślę, że jest to ostrzeżenie, na które warto się przyjrzeć, ale myślę też, że tak się stanie.

Gdy ludzie przesyłają mi jakiekolwiek informacje zwrotne, próbuję je przefiltrować do trzech segmentów:

  • Robaki
  • Żądania funkcji
  • Niezrozumienie

Robaki

Błędy występują wtedy, gdy coś oczywiście nie działa tak , jak byś się tego spodziewał, ani tego, czego oczekiwałby użytkownik . Zapytał mnie o moje imię, wpisałem „Scott”, wcisnąłem enter i powiedziałem „Cześć Joe!”

Żądania funkcji

To tak, jakby „wiem, że nigdy o tym nie rozmawialiśmy, ale czy program może wywnioskować z moich gestów myszy, że jestem leworęczny i przesunąć przycisk OK na lewą stronę ekranu?” Dzieje się tak, gdy bieżące zachowanie odpowiada oczekiwaniom użytkownika i użytkownika , ale chcą one zmienić oczekiwania.

Niezrozumienie

Wtedy można oczekiwać jednego wyniku ze scenariusza, ale użytkownik oczekuje innego wyniku. Czasami staje się to prośbą o udostępnienie funkcji, jeśli po prostu nie przekazali swoich oczekiwań, ale tak myśleli. Czasami staje się to błędem, jeśli twoje oczekiwania okażą się błędne.

Jednak wiele razy masz wiedzę, której użytkownik nie ma. Co jeśli powiedzą: „Na tym ekranie mogę dodać rekord dwa razy pod tym samym imieniem i nazwiskiem! To oczywiście błąd!” Twoja odpowiedź może brzmieć: „Na świecie jest wiele osób o tym samym nazwisku i nazwisku, więc nie wymagamy, aby ta kombinacja była unikalna. Mamy zadanie czyszczenia, które działa w nocy i przesyła e-mailem raport o możliwych duplikatach na adres obsługa klienta, gdy uzna, że ​​wykrywa duplikat o podobnej nazwie i adresie, i prosi go o sprawdzenie go ręcznie ”.

Powinieneś więc przeczytać każdy raport o błędzie, ale większość złożonych systemów będzie zawierać raporty o błędach, które są tak naprawdę tylko żądaniami funkcji lub błędną komunikacją wymagań. Niezrozumienie podstawowej złożoności realnego świata jest prawdopodobnie największym źródłem tych problemów.

Scott Whitlock
źródło
3
Błędna komunikacja obejmuje również niepamięć (lub zwykłe zapomnienie) oczekiwań, które zostały przekazane i uzgodnione.
Peter Taylor,
1
Świetne rozróżnienia, ale nadal uważam, że aplikacja powinna próbować wyjaśnić błędną komunikację, jeśli to możliwe. W przypadku wielu osób o tej samej nazwie aplikacja może powiedzieć: „Mamy już 3 John Smiths, jesteś pewien, że to nie jeden z nich” z opcją „Nie, jestem pewien, że to nowa John Smith”.
Alex Andronov
@Alex Andronov - nieporozumienie nie oznacza, że ​​nie musisz nic robić: zmień dokumentację, podpowiedzi itp., Zaktualizuj materiał szkoleniowy lub po prostu krótkie wyjaśnienie i przejdź dalej.
Scott Whitlock,
7

Nie było to dotąd poruszane w poprzednich odpowiedziach, więc dodam, że może to być również znak ignorancji bazy użytkowników. Nie używam słowa „ignorant” w sposób uwłaczający lub protekcjonalny, jedynie jako sposób wyrażenia, że ​​nie posiadają oni odpowiedniej wiedzy lub wykształcenia w swojej dziedzinie lub złożoności samego oprogramowania.

Większość użytkowników nie zdaje sobie sprawy z tego, jak skomplikowane oprogramowanie musi spełniać określone wymagania. Coś w efekcie 80% wysiłku przypada tylko na 20% funkcjonalności (przypadki skrajne i wyjątkowe).

Czasami nie rozumieją, dlaczego oprogramowanie z natury musi zachowywać się w określony sposób, wiele razy, aby zapobiec wielu wadom lub uszkodzeniom danych itp.

Nie jest to niepokojące, ponieważ staje się to lepsze dzięki przejrzystej i zwięzłej dokumentacji i komunikacji.

wałek klonowy
źródło
2
+1, ale spójrz na różnicę między złożonym a skomplikowanym ... Oprogramowanie wcale nie musi być skomplikowane, ale często jest bardzo skomplikowane.
Marjan Venema
To jest najprawdziwsza prawda. Najczęstszym przypadkiem, na jaki natknęłam się, jest to, że użytkownicy nie zdają sobie sprawy z różnicy między relacjami wiele do jednego i wiele do wielu. Często pojawia się pytanie „czy możesz sprawić, by raport pokazywał numer zamówienia w nagłówku?” i muszę wyjaśnić, że chociaż w około 95% przypadków jest tylko jeden numer zamówienia na rzeczy, nad którymi pracują, w wielu przypadkach zapytanie może zawierać dane z wielu zamówień. Następnie muszę zapytać, czy chcesz, abym wymienił wszystkie numery zamówień w nagłówku oddzielone przecinkami, czy chcesz numer zamówienia w każdym wierszu szczegółów w raporcie?
Scott Whitlock
@ScottWhitlock Tak, to jest to samo. Dobry programista lub analityk biznesowy nie powinien więc po prostu robić tego, o co prosi klient, ale starać się odkryć podstawowy problem, z jakim się borykają, i dlaczego w ogóle złożył taką prośbę. Po zidentyfikowaniu problemu możesz znaleźć właściwe rozwiązanie i napisać odpowiednie wymagania lub historie użytkowników.
wałek klonowy
5

Jeśli masz użytkownika, który jest ekspertem w swojej dziedzinie, możesz mieć poważny problem. Wyobraź sobie, że księgowy, który z założenia znajduje twoje oprogramowanie, nie przestrzega ogólnych procedur księgowych lub inżynier, który odkrywa, że ​​masz niepoprawną formułę. Nie powinno być zbyt trudne do zbadania, czy są poprawne. Przeprojektuj i napraw w razie potrzeby - szybko.

Jedna opinia na temat określonej funkcji interfejsu użytkownika lub pola, które ich zdaniem powinna zawierać symbol waluty lub inne sformatowanie, powinna być brana pod uwagę, przynajmniej do momentu uzyskania większej liczby opinii. Badanie tego może być nieco trudniejsze.

JeffO
źródło
1
Tak więc chyba nie ma jednej odpowiedzi. Należy to oceniać indywidualnie dla każdego przypadku. Tak myślałem.
Maks.
5

Błędy w projektowaniu z mojego doświadczenia oznaczają, że przypadki użycia nie pasują do prawdziwych użytkowników. Spróbuj przeczytać o korzystaniu z rzeczywistych użytkowników dla swoich przypadków użycia (po prostu nadanie im nazw i opisu miniatury robi cuda dla jakości przypadków użycia).

Kiedy wybitni dostawcy systemów operacyjnych mówią „takie zachowanie jest zgodne z projektem”, zwykle mają na myśli łatwość wdrożenia lub korzyści handlowe. Jeśli to nie ty, spróbuj dowiedzieć się, jaki jest prawdziwy zestaw umiejętności i związek z oprogramowaniem. Czy używają tego przez cały dzień? Dla zabawy ? Raz w tygodniu, ponieważ zastąpił formularze TPS?

Tim Williscroft
źródło
5

Interfejs użytkownika powinien być zgodny z zasadą najmniejszego zdziwienia - powtarzające się raporty o błędach dotyczące funkcji, która działa zgodnie z przeznaczeniem, wskazują, że zasada ta nie była przestrzegana poprawnie.

Joris Timmermans
źródło
3
Lub, że istnieje podzielona grupa użytkowników. Załóżmy na przykład, że twoja aplikacja internetowa naśladuje pulpit. Czy spodziewasz się, że zamknięcie okna zamyka program? Tak dla użytkowników systemu Windows, Nie dla użytkowników komputerów Mac.
keppla,
1
@Keppla - masz rację. Nie możesz zadowolić wszystkich, więc w przypadku „błędów”, takich jak te wymienione tutaj, konieczne jest przeprowadzenie dochodzenia, aby upewnić się, że po otrzymaniu „poprawki” nie pojawi się więcej zgłoszeń błędów.
Joris Timmermans
1
być może, ale o wiele bardziej skuteczne jest cytowanie danych „setek osób zgłosiło błędy w tym!” niż to jest mieć kilka wściekłych użytkowników informacją, że zostały naruszone ich osobistą interpretację Magical Zasada najmniejszego zdziwienia i oni są zdumieni. Jestem trochę zmęczony tym drugim, ponieważ „zdziwienie” jednego człowieka jest „proste” innego człowieka.
Jeff Atwood,
@Jeff Atwood - jak mówi przysłowie „jedna jaskółka nie czyni lata”, „jeden raport o błędzie nie oznacza błędu projektowego”. Pojedynczy raport o błędzie dotyczący czegoś, co jest funkcją, nie jest powodem do przeprojektowania, a nawet kilka raportów dotyczących wspólnej funkcji niekoniecznie oznacza, że ​​większość użytkowników nie byłaby szczęśliwsza bez „poprawki”. Zwłaszcza jeśli twoje oryginalne wydanie jest już popularne i ludzie są przyzwyczajeni do korzystania z niego „w ten sposób”.
Joris Timmermans
2

Istnieją dwa rodzaje błędów: funkcjonalność nie odpowiada intencjom programisty lub funkcjonalność nie spełnia wymagań. Programiści mają tendencję do skupiania się na tym pierwszym, ze szkodą dla drugiego. Mówiąc najprościej, jeśli użytkownicy zgłaszają wiele „błędów związanych z projektowaniem”, twoje wymagania nie są takie, jak myślisz.

Karl Bielefeldt
źródło
2

Niekoniecznie. Może się zdarzyć, że zgłoszony błąd korzysta z oprogramowania, które znajduje się poza jego pierwotnie zdefiniowanym zakresem. Zastanów się nad oprogramowaniem zaprojektowanym do wykonywania zadań A, B i C (na banalny przykład rysuj linie, trójkąty i prostokąty). Jeśli D jest logicznym następnym krokiem (np. Pięciokąty), użytkownik może założyć, że również powinien to zrobić, a to nie jest błędem. Ale jeśli jest to poza pierwotnym zakresem, nie jest to błąd. Zamiast tego może to być niedopatrzenie (błąd) w projekcie, szara strefa w specyfikacjach lub inny zestaw założeń poczynionych przez programistę i użytkownika.

(Edytuj - dodał mój komentarz do odpowiedzi zgodnie z sugestią @Marjan Venema.

James McLeod
źródło
Naprawdę nie widzę tego oznaczonego jako raport o błędzie. Bardziej jak sugestia lub prośba o funkcję. (Chociaż w przypadku niektórych systemów śledzenia błędów i tak może to być jeden.)
Maxpm
1
Zgadzam się, przez większość czasu, ale może to oznaczać niedopatrzenie (błąd) w projekcie lub szary obszar w specyfikacjach lub inny zestaw założeń poczynionych przez programistę i użytkownika.
James McLeod
1
James, jeśli dodasz ten komentarz do swojej odpowiedzi, cała odpowiedź stanie się lepsza.
Marjan Venema,
1

Uważam, że jest to zły znak, głównie dlatego, że projekt nie jest ogólny, a wymagania użytkowników nie są w pełni zrozumiane / analizowane.

Widzę dwie kategorie projektowania, - Projektowanie przez przypadek. - Projektowanie z zamiarem.

Przypadkowe projektowanie często prowadzi do takich problemów i nie może zostać utrzymane.

18 bajtów
źródło
1

Chciałbym dodać do odpowiedzi maple_shaft na temat „ignorancji” użytkowników. Należy również pamiętać, że 90% użytkowników będzie dbało tylko o własne wrażenia i sposób korzystania z systemu. Nie dbają o innych użytkowników, dlaczego powinni? Naszym zadaniem jako projektantów / programistów jest pozyskiwanie informacji od różnych użytkowników i tworzenie czegoś, co pasuje każdemu tak dobrze, jak to możliwe. W większości przypadków nie można stworzyć rozwiązania optymalnego dla wszystkich.

Ale oczywiście musisz przeczytać i ocenić opinie użytkowników! W końcu to ci, którzy używają waszego dzieła!

AndSoYouCode
źródło
0

Użytkownicy zgłaszający żądania błędów na ogół nie byli konsultowani w sprawie projektu, więc nie jest zaskakujące, że postrzegają rzeczy jako błędy, które były celowymi decyzjami projektowymi. Dla użytkownika wszystko, co nie działa zgodnie z oczekiwaniami, jest błędem.

Zauważyłem, że problem jest często oznaką, że licencjat lub kierownik otrzymali wymagania od menedżerów, a nie od rzeczywistych użytkowników. To, czego menedżerowie oczekują od systemu, często znacznie różni się od tego, czego faktycznie potrzebują ludzie wprowadzający dane. Nauczono mnie, jak zbierać dane bezpośrednio od rzeczywistych użytkowników, ale większość licencjatów, na które natknąłem się ostatnio, rozmawia tylko z menedżerami (i ogólnie relatywnie starszymi menedżerami).

HLGEM
źródło