Mój zespół sabotuje wdrożenie Jiry – jak to ugryźć?

Przeszedłem przez dokładnie to samo z 12-osobowym teamem. Problem nie leży w Jirze – leży w tym, że ludzie nie widzą dla siebie wartości z jej używania, tylko dodatkową robotę papierkową. Kluczowe było u nas jedno: zaczęliśmy robić planowanie sprintu WYŁĄCZNIE na podstawie tasków w Jirze – jeśli czegoś nie ma w systemie, nie istnieje, nie ma co dyskutować. Ból administracyjny stał się mniejszy niż ból bycia pominiętym w planowaniu.

Jedno pytanie, które może zmienić perspektywę: czy deweloperzy rozumieją, że ten projekt za 150k zależy od ich dyscypliny, czy widzą Jirę jako Twoje narzędzie kontroli, a nie ich narzędzie pracy? Bo to dwie zupełnie różne sytuacje wymagające różnych podejść.

Powiem wprost: może Jira to za duże działo dla 8-osobowego software house'u i tego można było nie wiedzieć przed zakupem. Trello z odpowiednimi kolumnami i Power-Upami albo Linear dałyby Ci tę samą widoczność z 10x mniejszym oporem zespołu. Nie mówię, żeby teraz rezygnować, ale warto zadać sobie pytanie czy walczysz o narzędzie czy o efekt.

Konkretna mechanika, która działa: wprowadź zasadę że PR nie może zostać zmergowany bez podlinkowanego taska w Jirze. To wymaga 2 minut konfiguracji integracji z GitHubem/GitLabem i nagle każdy developer ma osobisty powód, żeby zakładać taski PRZED pracą, nie po.

Dwa miesiące to za mało, żeby oceniać czy wdrożenie działa, ale zdecydowanie za dużo, żeby tolerować chaos przy projekcie tej wartości. Ja bym teraz zrobił jedno spotkanie bez slajdów: pokazał timeline projektu, aktualną widoczność (zerową), i wprost zapytał zespół co musiałoby się zmienić w Jirze żeby chcieli jej używać. Czasem okazuje się, że cała struktura którą postawiłeś ma sens tylko dla Ciebie.