Jak radzisz sobie ze śledzeniem błędów w sposób przyjazny dla programistów i personelu nietechnicznego? [Zamknięte]

Używamy Mantis do naszych projektów. A może powinienem powiedzieć „próbujemy użyć”. Problem ze wszystkimi modułami do śledzenia błędów, które znam, polega na tym, że są one tworzone przez programistów dla programistów. Więc projekt nie istnieje lub jest całkowicie absurdalny.

Oczywiście jako programista mogę bez problemu używać modliszki, ale jak przydatne jest śledzenie błędów, gdy wszystkie osoby zaangażowane w projekt ** uważają je za tak źle zaprojektowane i tak trudne w użyciu, że wolą tworzyć dokumenty Google z listą wypunktowaną znalezionych błędów lub sugestii, które mogą mieć.

Mam zamiar zainstalować forum, wydaje mi się, że jest to „w środku” rozwiązanie między modułem śledzenia błędów a zwykłą listą wypunktowań. Przynajmniej forum pozwala monitorować i scentralizować dyskusję na temat sugestii.

Jeśli moje obawy nie są jasne, moje pytanie można streścić w następujący sposób:

Jak radzisz sobie z raportem o błędach i sugestiach skierowanych do użytkowników nietechnicznych?

** Zaangażowany, NIE mam na myśli faktycznego klienta ani użytkownika końcowego. Mam na myśli naszego integratora, kierowników projektów i osoby zaangażowane w kontrolę jakości.

Na początku tego roku zmieniliśmy z Mantis na FogBugz (i Kiln), ale jedyne, czego nie zmieniliśmy, to to, że nie pozwalamy „użytkownikom” w ogóle mieć dostępu do narzędzia do śledzenia błędów. Niektórzy inni szefowie działów mają dostęp tylko do odczytu, ale szczerze mówiąc, są menedżerami i zwykle zapominają o tym w ciągu kilku tygodni. Użytkownicy naszego oprogramowania mają do czynienia z jednym facetem od rozwiązywania problemów, który określa, czy jest to problem z konfiguracją, błąd użytkownika czy błąd oprogramowania. Osoba ta następnie pełni rolę strażnika przy wprowadzaniu prawdziwych problemów do FogBugz. Zapobiega to zapełnieniu naszego systemu problemami, które nie są tak naprawdę istotne.

Tak więc, aby odpowiedzieć na twoje prawdziwe pytanie ... nie jest dla nas problemem, że oprogramowanie do śledzenia błędów jest „przez programistów”, „dla programistów”, ponieważ tylko „programiści” z niego korzystają. Wszyscy inni mają bezpośredni kontakt z człowiekiem.

(Uwaga: nasz produkt nie jest termokurczliwy, a wszyscy nasi użytkownicy są bezpośrednimi pracownikami lub pracują z pracownikiem w dziale usług).

Używamy Redmine do tego rodzaju rzeczy. Kluczową sztuczką jest to, że większość użytkowników nigdy nie widzi redmine - po prostu wysyłają e-mail na adres support@example.com. Korzystając z kilku bardziej zaawansowanych sztuczek - głównie BCC poprzez nasze konto Redmine i włączając problem # - możemy kontynuować aktualizację do redmine. Bardziej zaawansowanym ludziom pozwalamy po prostu korzystać z redmine bezpośrednio, ponieważ jest on nieco bardziej nowoczesny i przyjazny dla użytkownika niż kiedykolwiek wcześniej MANTIS.

Obecnie używamy MKS. Dla nie-programistów przygotowałem kilka raportów i pulpit nawigacyjny z podsumowaniami, którymi są zainteresowani. Oznacza to, że muszę wykonać wstępną konfigurację, ale są oni w stanie monitorować postęp wad i ogólne podsumowanie same dane, gdy pokażę im, jak uzyskać dostęp do raportów i pulpitów nawigacyjnych. Potrzebowali także szkolenia, aby zmodyfikować swoje bilety, ale zawsze będzie trochę szkolenia. Na szczęście był on proporcjonalny do zaangażowanych funkcji.

Drugiego używam Redmine i osobiście używam The Bug Genie (tak, tandetna nazwa, ale dobrze zaprojektowana; jeśli jesteś w środowisku PHP i / lub nie możesz uruchomić Ruby z jakiegokolwiek powodu) do śledzenia problemów, które są przyjazne dla innych niż użytkownicy technologii.

Poza tym jednym z kluczy jest to, że użytkownicy końcowi nigdy nie muszą widzieć więcej problemów niż te, które domyślnie wprowadzili (opcjonalnie możesz mieć możliwość wyszukiwania, aby uniknąć duplikatów biletów, ale to zależy od twoich potrzeb i konfiguracji). Widzenie wszystkich problemów po prostu zaśmieci interfejs i dezorientuje użytkownika końcowego. Użytkownicy w ogóle powinni widzieć tylko to, co powinni zobaczyć, więc kierownicy projektów dostrzegają problemy tylko na przykład nad projektami, które kontrolują. Jak już wspomniano, dla użytkowników końcowych im łatwiej jest złożyć zgłoszenie, tym lepiej. Punkty bonusowe, jeśli możesz przesłać zgłoszenie, które nawet nie wymaga interfejsu użytkownika modułu śledzącego (za pośrednictwem poczty elektronicznej lub prostego formularza, który zawiera tylko pola wymagane do przesłania zgłoszenia).

Używamy „funkcji zarządzania cyklem życia aplikacji programu Visual Studio”, wcześniej znanego jako Team Systems. Dużą zaletą dla nas jest to, że możesz wyeksportować wynik zapytania (np. „Wszystkie wymagania” lub „wszystkie błędy z pri 2 lub niższą, które nie będą w następnej wersji”) do arkusza kalkulacyjnego lub dokumentu projektu. Menedżerowie projektów, przedstawiciele użytkowników końcowych, interesariusze itp. Mogą edytować te pliki - zmieniając priorytet, aktualizując opisy, przypisując komuś innemu, cokolwiek - a następnie, gdy plik powróci do komputera podłączonego do TFS, możesz nacisnąć Publikuj i zmiany wracają do repozytorium. Programiści pracują z elementami pracy bezpośrednio z Visual Studio, ale nie-programiści nigdy nie zbliżają się do VS. Dla każdego projektu TFS istnieje także witryna SharePoint, więc nie „

Może nie jest to opcja, jeśli nie jesteś sklepem VS, ale warto o tym pomyśleć.

Jeśli rozmawiasz z personelem QA / PM, musisz ocenić różne narzędzia do śledzenia źródeł otwartych i zamkniętych. Osoby, które mają możliwość ustawiania kompilacji itp., Są dobre, więc pracownicy QA / PM mogą wystawiać bilety na konkretną kompilację, a gdy naprawisz problem, będą wiedzieć, w której kompilacji go przetestować.

Większość używanych przeze mnie narzędzi poprawności jest w rzeczywistości bardziej dostrojona dla nie-programistów niż dla programistów. StarTeam był dla mnie całkiem niezły, ale nie wiem, czy nadal jest w pobliżu. Możesz dostosować pola i takie, jeśli chcesz. Tylko upewnij się, że nie przesadzą z tym.

Jeśli mówisz o użytkownikach końcowych, musisz spojrzeć na oprogramowanie pomocy technicznej, a następnie poprosić personel działu pomocy technicznej o eskalację narzędzia do błędów w razie potrzeby.