Ukryty koszt nieprecyzyjnych ticketów w Jira
Nieprecyzyjny ticket w Jira rzadko na pierwszy rzut oka wygląda ryzykownie. Prawdziwy problem wychodzi później, gdy różne osoby dopowiadają sobie brakujące rzeczy na różne sposoby, a kilka dni skupionej pracy okazuje się skierowane nie tam, gdzie trzeba.
Dlaczego nieprecyzyjne tickety wciąż przechodzą
Backend developerka bierze ticket w poniedziałek rano. Tytuł brzmi konkretnie: „Dodać powiadomienia użytkownika o aktualizacjach zamówienia”. Opis ma dwa zdania i link do wątku na Slacku sprzed trzech tygodni. Na pierwszy rzut oka wygląda to wystarczająco jasno. Spędza więc trzy dni na budowie mechanizmu mailowych powiadomień uruchamianych przy każdej zmianie statusu zamówienia.
W czwartek, podczas przeglądu PR-a, PM wpada i mówi: „Nie o to mi chodziło. Potrzebowaliśmy tylko powiadomień w aplikacji dla zdarzeń związanych z wysyłką, a użytkownicy mieli móc je wyłączyć”. Nikt się nie pomylił. Nikt nie był niedbały. Ticket po prostu nigdy nie wydobył na światło dzienne decyzji, które ukrywał.
Nikt nie pisze nieprecyzyjnego ticketu celowo. Powstaje on w dwie minuty między spotkaniami, z uczciwym zamiarem, żeby wrócić później i dopisać szczegóły. Tyle że to później nie nadchodzi. Autor ma cały kontekst w głowie. Wie, które zdarzenia są ważne, o jakich kanałach myśli i których użytkowników to dotyczy.
Nic z tego nie trafia do opisu, bo wydaje się oczywiste. Dla innych osób wcale takie nie jest.
Jira jeszcze to pogarsza właśnie dlatego, że wszystko bardzo ułatwia. Nie ma obowiązkowego pola, które pyta, co jest wyraźnie poza zakresem. Nie ma żadnej blokady odrzucającej opis krótszy niż dwadzieścia słów. Możesz wpisać trzy słowa w podsumowaniu, zostawić pusty opis i kliknąć Utwórz. Jira nie protestuje. To jednocześnie wygoda i pułapka. Efekt to backlog pełen ticketów, które na pierwszy rzut oka wyglądają na kompletne, a swoją nieprecyzyjność ujawniają dopiero wtedy, gdy ktoś zaczyna już coś budować.
Co naprawdę zawiera plan gotowy do wdrożenia
Większość ticketów odpowiada na jedno pytanie: czego chcemy? Plan gotowy do wdrożenia odpowiada na sześć.
| Część | Na co odpowiada |
|---|---|
| Zakres | Co wchodzi w pracę, a co jest wyraźnie poza nią |
| Ograniczenia | Czego nie wolno zmienić ani zepsuć |
| Kroki | Co ma się wydarzyć i w jakiej kolejności |
| Przypadki brzegowe | Co się dzieje, gdy oczywista ścieżka zawodzi |
| Zależności | Co musi istnieć wcześniej |
| Definicja ukończenia | Po czym wszyscy poznają, że praca jest naprawdę skończona |
To nie jest lista kontrolna do każdej drobnej poprawki z backlogu. Ale wszystko, co trafia do sprintu, wszystko, co prawdopodobnie zajmie komuś więcej niż kilka godzin, potrzebuje tych odpowiedzi przed startem. Zakres to element, który zespoły pomijają najczęściej. Określenie tego, co wypada poza zakres, wydaje się zbędne, gdy wszyscy są skupieni na tym, co ma się zmieścić w środku. Tymczasem właśnie tu zaczyna się zaskakująco dużo przeróbek.
Ograniczenia to ciche wymagania:
- Nie zepsuć istniejącego przepływu maili o zamówieniach.
- Pozostać w obecnym serwisie powiadomień.
- Bez nowej infrastruktury w tym sprincie.
Takie szczegóły rzadko się zapisuje, bo autor zakłada, że wszyscy już je znają. Nie znają. A definicja ukończenia to granica między „wydaje mi się, że to już gotowe” a „wszyscy zgadzamy się, że to gotowe”. Dobra definicja ukończenia jest obserwowalna i sprawdzalna.
Pytania są ważniejsze niż sama struktura
Każda instancja Jira prędzej czy później przechodzi przez ten sam cykl. Ktoś dodaje szablon opisu z sekcjami typu Podsumowanie, Kryteria akceptacji, Notatki techniczne i Poza zakresem. Przez kilka tygodni ludzie go wypełniają. Potem ten sam nieprecyzyjny język, który wcześniej żył w pustym opisie, po prostu rozlewa się po większej liczbie podpisanych pól. Struktura się poprawiła. Myślenie nie.
Szablony nie rozwiązują problemu, bo problem nie jest strukturalny. Jest poznawczy. Osoba pisząca nie wie, czego jej brakuje. Pusta sekcja zatytułowana Przypadki brzegowe nie pomoże komuś, kto jeszcze o nich nie pomyślał. Pytania pomagają. Konkretne pytania, które wymuszają decyzje.
Pięć pytań szczególnie dobrze wyciąga ukryte decyzje:
- Co zmienia się w zachowaniu systemu?
- Kto jest głównym użytkownikiem i co chce osiągnąć?
- Czy istnieje sytuacja, w której to nie powinno się wydarzyć?
- Co się zepsuje, jeśli tego nie dostarczymy?
- Czy dotyczy to obecnych użytkowników, nowych użytkowników czy obu grup?
Te pytania działają, bo są na tyle konkretne, by dało się na nie odpowiedzieć, a jednocześnie na tyle szerokie, by pasowały do niemal każdego ticketu funkcjonalnego. Samo odpowiadanie na nie jest już planowaniem. Szablon jest tylko miejscem, do którego trafiają odpowiedzi.
Pełny przykład
Tak to wygląda w praktyce. Oryginalny ticket jest malutki: „Dodać powiadomienia użytkownika o aktualizacjach zamówienia”. Opis mówi jedynie, że użytkownicy powinni dostawać powiadomienia przy zmianie statusu zamówienia, oraz zawiera notatkę, by ustalić z designem warstwę wizualną. To wystarczy, żeby wrzucić temat do sprintu, ale zdecydowanie za mało, by budować z pewnością.
Krótka runda doprecyzowania zmienia wszystko:
| Pytanie doprecyzowujące | Odpowiedź |
|---|---|
| Które zmiany statusu mają znaczenie? | Tylko wysłane i dostarczone |
| Jakie kanały? | Tylko w aplikacji w tym sprincie |
| Czy użytkownik może je wyłączyć? | Tak, domyślnie włączone |
| Co z użytkownikami offline? | Powiadomienie czeka do następnego logowania |
| Czy to dotyczy istniejących zamówień? | Nie, tylko nowych |
| Co jeśli dostarczenie się nie powiedzie? | Jedna ponowna próba, potem wpis do logu |
Piętnaście minut później ticket znaczy dla wszystkich dokładnie to samo. Wersja po doprecyzowaniu ma realny zakres, realne ograniczenia, uporządkowane kroki, prawdziwe przypadki brzegowe i definicję ukończenia, którą da się sprawdzić. To ten sam ticket. Klarowność jest zupełnie inna. Różnica nie wynika z lepszego szablonu. Wynika z niewielkiej, ale celowej serii pytań zadanych przed rozpoczęciem pracy.
Gdzie w tym procesie pasuje AI
AI nie pisze ticketów. Tickety piszą ludzie. Ale AI jest bardzo przydatne w jednym konkretnym miejscu procesu: wtedy, gdy intencja już istnieje, ale struktura nie jest jeszcze dopięta. Model językowy potrafi przeczytać nieprecyzyjny opis i zapytać: „Czy uwzględniliście, co dzieje się, gdy użytkownik jest offline?”. Potrafi zebrać rozrzucone odpowiedzi z wątku na Slacku i uporządkować je jako zakres, ograniczenia i kroki. Potrafi zauważyć, że plan wspomina migrację bazy danych, ale lista zależności nie uwzględnia przeglądu przez właściwe osoby.
To, w czym AI nie jest dobre, to podejmowanie decyzji produktowych za was. Może zapytać, czy to ma być e-mail, push czy powiadomienie w aplikacji. Nie może zdecydować, która z tych opcji jest właściwa dla waszych użytkowników i tego sprintu. Może wygenerować wiarygodnie brzmiącą definicję ukończenia, ale tylko człowiek rozumiejący produkt wie, czy ta definicja naprawdę jest trafna.
Schemat jest prosty: ludzie decydują, AI porządkuje. Ludzie ustawiają zakres, AI wychwytuje luki. Właśnie na tym schemacie, doprecyzuj, zaplanuj, wykonaj, zbudowane jest Just w Atlassian Marketplace wewnątrz Jira. Ten sam schemat działa też ręcznie. AI po prostu przyspiesza cały cykl.
Trzy rzeczy do zastosowania już dziś
- Przed następnym sprintem wybierz najbardziej nieprecyzyjny ticket ze swojego backlogu i zadaj pięć pytań z tego artykułu, zanim ktokolwiek zacznie pisać kod. Prawie na pewno odkryjesz co najmniej dwie decyzje, których nikt nie zauważył, że wciąż nie zostały podjęte.
- Zapisz odpowiedzi jako zakres, ograniczenia i sprawdzalną definicję ukończenia, nie w osobnym dokumencie, tylko w samym tickecie, tam gdzie osoba realizująca pracę naprawdę je zobaczy.
- Traktuj powyższy szablon jako punkt wyjścia, a nie sztywny standard. Dopasuj go do języka waszego zespołu, ale nie pomijaj pytań. Jeśli chcesz szerszego kontekstu, dlaczego ten etap doprecyzowania jest jeszcze ważniejszy, gdy nieprecyzyjne tickety trafiają bezpośrednio do AI, pierwszy tekst z tej serii omawia problem alignmentu szerzej: Dlaczego większość narzędzi AI do Jira pogarsza problem alignmentu zamiast go rozwiązywać.
