Dlaczego tak trudno jest zmusić pracowników do zaktualizowania narzędzia do śledzenia problemów?

31

Zawsze miałem tę trudność, aby ludzie zaktualizowali swoje problemy, zarówno w mojej firmie, jak iw pracy. Miałem kilka przypadków, w których ludzie robią to z dobroci serca, ale ~ 70% czasu muszę ścigać ludzi.

Będąc tym, który generalnie zarządza jakąś inną formą zarządzania (jestem przede wszystkim programistą), głównym powodem, dla którego próbuję podać, jest to, że nie chcę ścigać ludzi i przeszkadzać w pytaniu o postęp, ale nie „ w końcu ludzie myślą, że tyle pytań. W niektórych rzadkich i skrajnych przypadkach aktualizuję bilety (kiedy muszę tworzyć raporty).

Czy napotkałeś już ten problem? Jak zachęciłeś programistów do częstego aktualizowania narzędzia do śledzenia problemów? Jaki masz sukces?

dukeofgaming
źródło
21
Z własnego doświadczenia wynika, że ​​problem polega na tym, że aktualizacja narzędzia do śledzenia problemów i ogólnie prowadzenie odpowiedniej dokumentacji nie jest tak ważne jak kodowanie. I chociaż jest to nieco naturalna mentalność dla programisty, nie powinna być dla zarządu i firmy w ogóle. Czy Twoja firma traktuje tę część pracy jako równie ważną jak kodowanie? Jeśli nie, powinieneś zacząć od tego, programiści są inteligentni i adaptacyjni, jeśli wyczują, że firma naprawdę uważa to za poważną rzecz (z pochwałą, gdy zrobione dobrze i konsekwencjami, gdy nie), wkrótce zaczną robić to dobrze.
yannis
@YannisRizos Ten komentarz jest wystarczająco dobry, aby być odpowiedzią
dukeofgaming
14
Ach! Nie mogę nawet zmusić mojego szefa do korzystania z narzędzia do śledzenia problemów. Przechodzi, mówi szybko o „rzeczach” i wychodzi. Nazywam to „zgłoszonymi błędami”. W rzeczywistości wyśmiewam się z używania narzędzia do śledzenia problemów ... Czuję frustrację w Mocy.
MetalMikester
3
imo, większość „trackerów problemów”, które widziałem, są do kitu bardzo źle - interfejs użytkownika jest zbyt nieporęczny (aby mogli obsługiwać specjalne przypadki). Jeśli więc spytasz mnie, dlaczego ich nie używam, właśnie dlatego.
GrandmasterB
1
Skutecznie upewnij się, że masz aplikację, która działa dobrze, jest łatwa w użyciu, szybka i nie wymaga wprowadzania zbyt wielu informacji. Ponadto wady należy sklasyfikować tak, jak postępować w następnej wersji i należy użyć wprowadzonych informacji. Na przykład, jeśli programista wyjaśni wszystko poprawnie, ale jesteś zbyt leniwy, aby go przeczytać i zamiast tego zapytać go, to oczywiście straciłbyś motywację do korzystania z systemu, ponieważ bardzo frustrujące jest dwukrotne wyjaśnienie tego samego.
Phil1970,

Odpowiedzi:

30

Powodem jest to, że nie zastanawiają się, dlaczego powinni aktualizować narzędzie do śledzenia problemów, poza tym, że tak mówisz.

Dlaczego? Domyślam się, że aktualizacja modułu śledzenia nie wpływa w żaden znaczący sposób na ich pracę, więc rozwiązaniem jest prawdopodobnie wdrożenie systemu śledzenia, który faktycznie pomaga im lepiej wykonywać swoją pracę.

Martin Wickman
źródło
„wdrożyć system śledzenia, który faktycznie pomaga im lepiej wykonywać swoją pracę”. Czy możesz podać przykład? Coś, co im to pomaga, a nie konkretny system śledzenia.
Burhan Ali
2
@BurhanAli Nie Nie jestem w stanie powiedzieć im, co dla nich działa. Muszą to sami wymyślić. Sugestia: zacznij od czegoś prostego i skorzystaj z cotygodniowych informacji zwrotnych, aby to poprawić.
Martin Wickman,
Twój zespół może się różnić, ale jako przykład zacząłem znacznie lepiej aktualizować narzędzie do śledzenia problemów, kiedy zacząłem używać go jako centrum komunikacyjnego, aby nie przerywać tak często, gdy jestem głęboko w kodzie.
Morgen
13

Jest to trudne, ponieważ pracownicy wyraźnie uważają, że aktualizacja narzędzia do śledzenia problemów nie jest ważna. Musisz to zmienić, ale jest pewien haczyk. Komunikacja jest trudna. Skuteczna komunikacja jest naprawdę trudna - o wiele trudniejsza niż mogłoby się wydawać. Tak ciężko, że komunikacja zwykle kończy się niepowodzeniem, chyba że przez przypadek .

Pokaż, nie mów. Na przykład. nie mów, że ty (lub twój szef) potrzebujesz danych do raportu. Pokaż z punktu widzenia pracowników, w jaki sposób aktualny moduł do śledzenia problemów wpływa i pomaga im.

Dawaj dobry przykład.

Maglob
źródło
10

Jestem programistą i mam trudności z używaniem narzędzia do śledzenia problemów, które mamy w pracy. Jest to niefortunne, ponieważ jestem za nimi, aby wszystko zorganizować. Obecnie moim rozwiązaniem jest skorzystanie z osobistego narzędzia śledzenia i odniesienie go do rozmowy o postępach na naszych codziennych scrumach.

Oto, co skłoniłoby mnie do korzystania z trackera przez cały czas:

  • Bezproblemowa integracja z IDE i kontrolą źródła. Używamy nieporęcznej aplikacji internetowej, ponieważ licencje zostały już na nią zakupione. Tworzenie / aktualizacja zadań trwa wieczność i ma mylące funkcje interfejsu użytkownika. Niestety korzystanie z tego jest poza kontrolą naszego zespołu.

  • Prostota. Rozumiem przez to, że nie biorę 10 ręcznie wypełnionych pól tylko po to, aby dodać zadanie. Szacunki godzinowe a czas zakończenia, ręczne wprowadzenie projektu / komponentu / itp. w kilku polach itp. po prostu zwiększ ilość czasu.

  • Tylko jeden. Nie jestem pewien, jak często to się dzieje, ale zarządzanie projektami korzysta z jednego narzędzia, wsparcie używa innego, a programista używa trzeciego. Jeśli ktoś nie zostanie zaktualizowany, trzy z pewnością tego nie zrobią, a synchronizacja między nimi raczej nie zostanie zautomatyzowana.

Kryptic
źródło
8

Po pierwsze: co rozumiesz przez „osoby aktualizujące swoje postępy”?

Czy masz na myśli „programistów aktualizujących bieżące oszacowanie”, „programistów nie ustawiających problemu do rozwiązania”, czy raczej „klientów / testerów nie zamykających rozwiązanego problemu”, czy wszystkie razem?

Z perspektywy dewelopera jest to połączenie myślenia i kultury.

  • sposób myślenia: gdy ustawisz problem do rozwiązania, oznacza to, że skończyłeś i odpowiadasz, jeśli jest wadliwy
  • kultura: jeśli cała firma nie bardzo chce korzystać z takich narzędzi, ale preferuje inne strategie organizacyjne

Moje doświadczenie jest takie: potrzebujesz kultury, która przynajmniej wskazuje właściwy kierunek. Następnie pomaga zdefiniowanie DoD (definicja „zrobione”) - jeśli programista (pracuje również dla innych ról) może powiedzieć, że wypełnił całą listę, to ulga, aby oznaczyć problem jako rozwiązany i przejść dalej bez potrzeby spojrzeć wstecz.

Andy
źródło
5

Przestań pytać o postęp w kodowaniu (zazwyczaj jest to arbitralny procent wyskakujący z powietrza), dopóki bilet nie zostanie zamknięty. Jeśli mierzysz przede wszystkim liczbę zamkniętych biletów, poprawi się.

Pamiętaj jednak, że wszystkie dane mogą być rozgrywane, a wskaźniki lepiej działają w połączeniu z danymi uzupełniającymi, np. Prawdopodobnie również chcesz przyjrzeć się problemom, które zostaną ponownie otwarte, ponieważ oznacza to, że są przedwcześnie zamknięte

jk.
źródło
5

Jak wskazano w kilku innych odpowiedziach, właściwe pytanie tutaj jest prawdopodobnie: dlaczego masz narzędzie do śledzenia problemów. Dobra odpowiedź na to pytanie (nie tylko z perspektywy zarządzania, ale także z perspektywy programisty) jest niezbędna, jeśli chcesz, aby system śledzenia problemów naprawdę działał i był regularnie aktualizowany.

W wielu firmach system śledzenia problemów jest wykorzystywany głównie jako narzędzie do raportowania zarządzania. Nakłanianie programistów do aktualizowania problemów tylko po to, aby kierownictwo mogło uruchomić raport, nie działa dobrze. Zmuszanie programistów do aktualizowania problemów również nie działa - możesz mieć zaktualizowane problemy, ale powinieneś przesłuchać dane.

Z mojego doświadczenia wynika, że ​​jedynym sposobem, aby naprawdę programiści (i testerzy, zarząd itp.) Skutecznie używali systemu śledzenia problemów, jest zintegrowanie go z procesem programistycznym. Oznacza to, że wynik jednej części procesu staje się wejściem do następnej części procesu.

Aby nadać autorytet systemowi śledzenia błędów, sugeruję:

  • Programiści pracują tylko nad błędami / funkcjami zalogowanymi w narzędziu do śledzenia problemów i poza nim nie są wykonywane żadne prace. Wszystkie pomysły, projekty refaktoryzacji, nowe funkcje, niestandardowe narzędzia, które należy opracować itp. Również powinny zostać zarejestrowane.
  • Zagadnienia są opracowywane według priorytetu. Priorytet powinien być częściowo ustalany przez kierownictwo, ale programiści powinni zdecydowanie mieć wpływ na określanie priorytetów. Jest to szczególnie prawdziwe, jeśli chodzi o kwestie konserwacji i refaktoryzacji.

Jeśli chodzi o przetwarzanie, możesz użyć czegoś takiego:

  • status „nowy” wskazuje, że problem nie został jeszcze wykryty przez programistę i nadal znajduje się w kolejce problemów o priorytetach
  • status „przypisany” oznacza, że ​​został przypisany do programisty. Może to zrobić programista lub ktoś inny, na przykład kierownik zespołu. Uważam, że dobrze jest mieć kilka problemów przypisanych do każdego programisty, i zwykle połączenie „ciężkich operacji podnoszenia”, takich jak nowe funkcje i łatwe wybieranie, takie jak proste błędy lub niektóre proste prace konserwacyjne. Umożliwia to programistom wybór pracy w zależności od ich nastroju.
  • status „w toku” oznacza, że ​​programista pracuje nad problemem. Tylko jeden lub dwa problemy na programistę powinny być „w toku” w dowolnym momencie.
  • po rozwiązaniu problemu programista może zmienić status problemu na „wymaga testowania” i zmienić właściciela na testera. To ważny krok, ponieważ jest to również kolejka robocza testerów.
  • testerzy mogą zmienić status na „testowanie zakończone niepowodzeniem” i zmienić własność z powrotem na programistę, co oznacza, że ​​przechodzi on na szczyt kolejki dla programisty, lub mogą zmienić status na „gotowy do wdrożenia”.
  • problemy ze statusem „gotowy do wdrożenia” można następnie scalić i zwolnić zgodnie z cyklem wydania przez osobę odpowiedzialną za wydania.

W skrócie: uczyń system śledzenia problemów istotną częścią procesu programistycznego i nie będziesz musiał się martwić, że problemy nie będą aktualizowane.

Mauritz Hansen
źródło
3

Może uważają, że to zbyt dużo pracy, aby otworzyć przeglądarkę, zalogować się, znaleźć bilet i wypełnić go. Może możesz spróbować zachęcić ich za pomocą haczyków . Obecnie powszechną cechą jest to, że w komunikacie git / hg [zakładam, że używasz jednego z nich] możesz wpisać coś takiego jak polubiony NAPRAWIONO # 123, a bilet zmieni się automatycznie po wciśnięciu zatwierdzenia. W ten sposób programiści prawie nie pracują [jeśli pracuje nad każdą kwestią w osobnym oddziale - ma już identyfikator biletu] i najprawdopodobniej doda te kilka znaków w komunikacie zatwierdzenia. Jeśli to rozwiązanie nie wystarczy, może oznacza to, że zakres biletów jest zbyt duży i należy go podzielić na wiele mniejszych biletów?

mkk
źródło
3

To brzmi jak kwestia kultury firmowej bardziej niż cokolwiek innego. Kto ustanowił potrzebę korzystania z modułu śledzącego? Jeśli jest to coś, co rzuciła tam jedna osoba lub grupa i oczekuje, że wszyscy inni po prostu zaakceptują i użyją, powodzenia. Dopóki ludzie nie zrozumieją, co to jest, nie będą wiedzieć, jak z niego korzystać i nie zaakceptują, że to naprawdę ułatwia ich życie (ich życie, a NIE twoje), nie będą go używać, chyba że będzie to wymuszone przez kierownictwo. To powiedziawszy, jeśli korzystanie z modułu śledzącego jest decyzją firmy, to na zarządzaniu powinno go wyegzekwować. O ile twoja rola nie obejmuje odpowiedzialności i uprawnień do pozyskiwania / zmuszania ludzi do korzystania z modułu śledzącego (brzmi jak nie, jak powiedziałeś, że jesteś programistą), nie zajdziesz daleko, niezależnie od tego, co robisz (realistycznie, IMHO ).

huntmaster
źródło
2

Prawdopodobnie jest to podobne do tego, dlaczego tak trudno jest zmusić ludzi do regularnego wkraczania w swój czas. To żmudna praca ...

Wiele programów do śledzenia problemów integruje się z IDE. Na przykład narzędzie śledzenia elementu pracy TFS pozwala oznaczyć zadanie jako rozwiązane podczas odprawy. Istnieje nawet opcja wymagająca powiązania odprawy z zadaniem. Włączenie aktualizacji elementu pracy do procesu meldowania upraszcza rzeczy. Alternatywą jest otwarcie modułu do śledzenia problemów w osobnym interfejsie w celu wykonania zmiany.

Inną opcją jest spotkanie statusowe (lub podczas codziennego standupu), podczas którego ktoś otwiera moduł śledzący i aktualizuje zadania, gdy ludzie podają status.

Michael Brown
źródło
0

Jedną z rzeczy, które należy wziąć pod uwagę, jest to, że sam GUI jest przeszkodą. Na przykład niektóre przeszkody mogą obejmować:

  • Za dużo kliknięć
  • Nieoptymalizowany lub niedostatecznie działający serwer aplikacji do śledzenia problemów
  • Słaba użyteczność lub dostępność

Udostępnienie interfejsu API pozwoli zaktualizować narzędzie do śledzenia problemów za pomocą skryptów takich samych jak artefakty techniczne (pokrycie kodu, raporty z testów jednostkowych, status kompilacji itp.).

Referencje

Paul Sweatte
źródło
W jednym z moich miejsc pracy korzystaliśmy z Jiry i pierwsze półtora roku było powodem, dla którego nauczyłem się go nienawidzić - było powolne, było wzdęte, proces był słabo zdefiniowany, musiałem oznaczyć spędzony czas w Jira, we własnym osobiste oprogramowanie do śledzenia czasu oraz zastrzeżone oprogramowanie, które nie pomogło. Jeśli aktualizacja błędu między sekundami zajmuje więcej niż sekundę, jest to zbyt długie. Ostatecznie nauczyłem się lubić Jirę, kiedy rzuciłem na nią lepszy sprzęt i proces został zakończony.
Maurycy,