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

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.)

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.

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.

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.

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?

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.

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.

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.

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.

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!

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).