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

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?

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

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.

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.

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.

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

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.

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?

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

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.

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

• Scrumwise - API

• JIRA Cloud REST API Reference

• Interfejs API REST Alfresco Content Services