Zespół przyspieszył dzięki AI. 5 zmian, które pomogą nadążyć z decyzjami produktowymi
AI przyspieszyło pracę programistów. Czy Twoja firma potrafi równie szybko decydować, co powinni zbudować? Gdy przygotowanie wymagań i zbieranie informacji od klientów nie nadążają za implementacją, zespół zaczyna czekać. Uzyskane przyspieszenie ujawnia kolejne wąskie gardło. Jak zmienić współpracę między Product Ownerem, programistami i biznesem, żeby decyzje produktowe nadążały za możliwościami zespołu?
Więcej o tym, jak dostosować procesy i współpracę w zespole do szybszej pracy z AI, dowiesz się z naszego webinaru „Dlaczego AI nie zwiększyło efektywności IT w Twojej firmie?”.
1. Przygotowuj kolejne zadania z wyprzedzeniem
Kiedy ustalacie cel kolejnego sprintu? Jeśli dopiero pod koniec poprzedniego, pozostaje niewiele czasu na rozmowy z klientami, wyjaśnienie wątpliwości i doprecyzowanie wymagań. Szybsza implementacja sprawia, że takie opóźnienia stają się bardziej odczuwalne.
Z tym problemem zmierzył się zespół rozwijający Pragmatic Meet, darmową platformę Pragmatic Coders do organizacji eventów. Po przepisaniu aplikacji, zmianie architektury i wprowadzeniu pracy z AI opartej na specyfikacji czteroosobowy zespół pracował około czterech do pięciu razy szybciej. Przygotowanie kolejnych zadań nie nadążało jednak za jego możliwościami.
Podczas jednego ze spotkań podsumowujących sprint padła propozycja wydłużenia tygodniowych iteracji. W dyskusji zwrócono uwagę, że cel kolejnego sprintu ustalano dopiero podczas podsumowania poprzedniego lub tuż przed nim. Zespół potrzebował wcześniej rozpoczynać refinement, czyli wspólne doprecyzowywanie nadchodzących zadań.
W praktyce: jeszcze w trakcie bieżącego sprintu przejrzyj z zespołem zadania, które najprawdopodobniej będą następne. Ustalcie, czego o nich nie wiecie, kto może udzielić odpowiedzi i kiedy będzie ona potrzebna. Szczególną uwagę poświęćcie decyzjom wymagającym udziału klientów lub innych osób spoza zespołu.
2. Podziel odpowiedzialność za wymagania z programistami
Osoba odpowiedzialna za produkt potrzebuje czasu na poznawanie klientów i wybieranie kierunku rozwoju. Jednocześnie szybszy zespół częściej dociera do kolejnych pytań o wymagania. Gdy wszystkie przechodzą przez Product Ownera, te dwa obowiązki zaczynają ze sobą konkurować.
W Pragmatic Meet Bartek Czarnecki, prowadzący zespół, zauważył, że sam stał się wąskim gardłem. Konieczne było przemyślenie, kto zbiera wymagania i jak je opracowuje. Częścią opisanego sposobu współpracy jest bezpośredni kontakt programistów z klientami. Gdy jeden z inżynierów potrzebuje informacji, może zapytać klienta bez przekazywania pytania przez Bartka.
Taki podział pracy wymaga przygotowania. Programiści potrzebują rozumieć cel produktu, kontekst biznesowy i powód prowadzenia rozmowy. Wsparcie ich w rozwijaniu tych kompetencji staje się ważnym zadaniem Product Ownera. Dzięki temu więcej osób może uczestniczyć w wyjaśnianiu wymagań.
W praktyce: ustalcie, które pytania programiści mogą wyjaśniać bezpośrednio z klientami, jakie decyzje mogą podejmować samodzielnie i kiedy potrzebują udziału Product Ownera. Na początek możecie prowadzić wybrane rozmowy wspólnie, żeby zespół poznał sposób zadawania pytań i oceniania odpowiedzi.
3. Sprawdzaj wspólne zrozumienie, zanim ruszy implementacja
Zanim zespół zacznie budować funkcję, warto sprawdzić, czy osoba odpowiedzialna za produkt i programista wyobrażają sobie ten sam rezultat. Makieta lub scenariusz działania pozwalają rozmawiać o konkretnych zachowaniach systemu i wcześniej ujawnić rozbieżności.
W Pragmatic Meet historyjka trafia do Jiry wraz z odnośnikami do bazy wiedzy. Programista przygotowuje z pomocą AI specyfikację i makiety, a następnie omawia rozwiązanie podczas refinementu. Własnymi słowami wyjaśnia, co zamierza zbudować, i pokazuje, jak będzie to wyglądało. Osoba odpowiedzialna za produkt może wtedy potwierdzić kierunek lub wskazać potrzebne zmiany.
Warto zwrócić uwagę na rolę tej rozmowy. Przygotowane przez AI materiały dają punkt odniesienia. Wyjaśnienie rozwiązania przez programistę pozwala dodatkowo sprawdzić, czy rozumie on wymagania i potrafi wziąć odpowiedzialność za rezultat. W opisanym zespole właśnie dlatego wspólne spotkania zaczęły zyskiwać na znaczeniu.
W praktyce: przy najbliższej funkcji poproś osobę odpowiedzialną za implementację o przedstawienie rozwiązania na makiecie lub konkretnym scenariuszu. Sprawdźcie wspólnie, jaki problem użytkownika rozwiązujecie, jak ma działać funkcja i które kwestie pozostają otwarte. Zakończcie rozmowę jasnym ustaleniem, co jest gotowe do realizacji.
4. Planuj kontakt z klientem razem z pracą nad funkcją
Przygotowując zadanie, warto od razu ustalić, od kogo potrzebujecie informacji zwrotnej i kiedy będzie ona potrzebna do podjęcia kolejnej decyzji. Oczekiwanie na odpowiedź może trwać dłużej niż sama implementacja.
Znaczenie tego problemu stało się szczególnie widoczne, gdy Pragmatic Meet przeszedł od przepisywania istniejącego systemu do rozwijania nowych obszarów produktu. Podczas przepisywania programiści znali wymagania i mieli działającą platformę jako punkt odniesienia. Nowe funkcje wymagały poznania potrzeb użytkowników. Zespół zaczął odczuwać trudności związane z pozyskiwaniem tych informacji i przygotowywaniem kolejnych decyzji.
W takim przypadku przyspieszenie wymaga również częstszych rozmów z klientami. Pomocne są makiety, dzięki którym można wcześniej pokazać pomysł i rozmawiać o konkretnym rozwiązaniu. Umiejętność szybkiego przygotowywania takich materiałów została wskazana jako ważna część pracy produktowej przy Pragmatic Meet.
W praktyce: dla planowanej funkcji określ, czego musicie dowiedzieć się od użytkownika przed implementacją, a co sprawdzicie po jej udostępnieniu. Umów kontakt z odpowiednim wyprzedzeniem. Zastanów się też, czy część pytań można rozstrzygnąć na podstawie makiety, bez czekania na gotową funkcję.
5. Zadbaj, żeby wiedza o produkcie była dostępna dla całego zespołu
Większa samodzielność programistów wymaga dostępu do informacji, na których mogą oprzeć swoje decyzje. Warto więc przyjrzeć się temu, gdzie trafiają ustalenia z klientami i kto odpowiada za ich aktualność.
W Pragmatic Meet wiedza o produkcie jest gromadzona w rozwijanym przez zespół grafie wiedzy. Obejmuje informacje o istniejącym systemie, planowanych zmianach i rozmowach z użytkownikami. Początkowo opiekowała się nim jedna osoba. Gdy zasób się rozrósł, jego utrzymywanie stało się zbyt dużym obciążeniem, dlatego odpowiedzialność zaczęła przechodzić na cały zespół.
To ważne uzupełnienie bezpośrednich rozmów programistów z klientami. Pozyskana odpowiedź powinna pomagać również pozostałym osobom przygotowującym produkt. W przeciwnym razie część wiedzy pozostaje dostępna wyłącznie dla uczestników konkretnej rozmowy.
W praktyce: uzgodnijcie jedno miejsce zapisywania wymagań i ustaleń produktowych. Określcie, kto uzupełnia je po rozmowie z klientem i jak oznaczacie decyzje, które się zmieniły. Sprawdźcie na konkretnym zadaniu, czy programista może samodzielnie znaleźć potrzebny kontekst.
Co dziś spowalnia decyzje w Twoim zespole?
Przyjrzyjcie się wspólnie, czy kolejne zadania są przygotowane z wyprzedzeniem, programiści uczestniczą w sprawdzaniu proponowanych rozwiązań, a rozmowy z klientami rzeczywiście wpływają na to, co budujecie.
Te pytania znajdziecie w naszej Product Health Checklist. Wypełnijcie ją razem, omówcie rozbieżności w odpowiedziach i wybierzcie jeden obszar do poprawy w kolejnym sprincie.
Sprawdź kondycję swojego produktu z Product Health Checklist.
