Dlaczego AI nie zwiększa efektywności IT? Siedem obszarów, które warto sprawdzić
Kupiliście licencje, zespół korzysta z AI, a kolejne funkcje nadal trafiają do użytkowników równie wolno? Sprawdź, na czym zatrzymuje się praca między pomysłem a wdrożeniem. Oto siedem obszarów, które warto przeanalizować z zespołem.
Interesuje Cię to i podobne zagadnienia? Obejrzyj nasz webinar “Dlaczego AI nie zwiększyło efektywności IT w twojej firmie?”.
1. Proces pracy: czy usprawnienia powstają razem z zespołem?
Można zaprojektować sposób pracy z AI, przygotować instrukcje i udostępnić narzędzia, a później odkryć, że ludzie korzystają z nich zupełnie inaczej, niż zakładaliśmy.
W Pragmatic Coders przekonaliśmy się, że próby projektowania takiego rozwiązania obok codziennej pracy zespołu zderzały się z jego potrzebami i przyzwyczajeniami. Zespoły pracujące w podobnym procesie miały własne nawyki, które trzeba było uwzględnić. Jedną z pierwszych lekcji podsumowaliśmy podczas webinaru „Dlaczego AI nie zwiększyło efektywności IT w Twojej firmie?”:
„Nie da się wymyślać systemu z boku, obok procesu, w którym uczestniczą ludzie”.
Dlatego zaczynaliśmy od prostego sposobu pracy, sprawdzaliśmy go na rzeczywistych zadaniach i poprawialiśmy na podstawie doświadczeń zespołu. W naszych projektach punktem wyjścia był Scrum. Zachowaliśmy ten sposób organizacji pracy, rozwijając praktyki związane z przygotowaniem wymagań i wykorzystaniem AI.
Sprawdź u siebie: czy ustalony sposób korzystania z AI odpowiada temu, jak zespół rzeczywiście pracuje?
Prześledźcie jedno zakończone zadanie: od otrzymania wymagań po wdrożenie. Ustalcie, gdzie pojawiły się odstępstwa od procesu i dlaczego. Następnie wybierzcie jedno usprawnienie do przetestowania przy kolejnych zadaniach. Może to być np. wspólny sposób sprawdzania specyfikacji przed rozpoczęciem implementacji.
2. Decyzje i feedback: czy zespół ma na czym pracować?
Jeżeli programiści szybciej realizują zadania, wcześniej potrzebują kolejnych ustaleń. Osoba odpowiedzialna za produkt musi nadążać z wyjaśnianiem wymagań, wyborem priorytetów i pozyskiwaniem informacji od klientów.
Takie ograniczenie pojawiło się w Pragmatic Meet, naszej darmowej platformie do organizacji eventów. Po przepisaniu aplikacji z wykorzystaniem AI czteroosobowy zespół programistów przyspieszył kodowanie. Okazało się jednak, że niespodziewaną przeszkodą na drodze programistów stał się… Product Owner. Przygotowanie decyzji produktowych zaczęło bowiem spowalniać dalszą pracę. Bartek Czarnecki, prowadzący zespół, opisał to wprost: „Ja stałem się zupełnie wąskim gardłem”.
Problemem był czas w obrębie sprintu przeznaczony na podejmowanie decyzji. W dyskusji wyszło na jaw, że cel następnego sprintu ustalano dopiero podczas podsumowania poprzedniego lub chwilę wcześniej – za późno. Zespół potrzebował więcej refinementu, czyli wspólnego doprecyzowywania nadchodzącej pracy wcześniej.
Konieczne było również przemyślenie podziału odpowiedzialności. W opisanym sposobie współpracy programista, który potrzebuje informacji od klienta, może zapytać go bezpośrednio. Product Owner pomaga zespołowi rozumieć kontekst biznesowy i przygotować się do takich rozmów.
Sprawdź u siebie: na jakie decyzje czekaliście w ostatnim sprincie i które pytania mogły zostać wyjaśnione wcześniej?
3. Wymagania: czy ludzie rozumieją to samo?
Gotowa specyfikacja może sprawiać wrażenie, że zadanie jest przygotowane do realizacji. Warto jednak sprawdzić, czy programista i osoba odpowiedzialna za produkt wyobrażają sobie ten sam rezultat.
W Pragmatic Meet dobrze pokazało to zadanie dotyczące identyfikacji nadawcy powiadomień mailowych. Użytkownik miał łatwiej rozpoznawać, która grupa wysyła mu wiadomość. Podczas przygotowania zadania powstało 12 makiet mobilnych i desktopowych, wykorzystujących istniejące komponenty aplikacji.
Programista pokazał je podczas refinementu i własnymi słowami wyjaśnił, co zamierza zbudować. Bartek opisał korzyść z takiej rozmowy następująco:
„Ja dokładnie wiem, czy to jest to, co chciałem zbudować”.
Pod spodem znajdowała się specyfikacja przechowywana w repozytorium. W podejściu Spec Driven Development to ona stanowi podstawę implementacji. Makiety i rozmowa pozwalały natomiast sprawdzić wspólne rozumienie zmiany przed rozpoczęciem budowania funkcji.
Takie przygotowanie zaczęło zajmować większą część pracy zespołu. Bartek szacował, że w ostatnim omawianym sprincie refinement pochłaniał około 30% czasu. Co więcej, programiści zaczęli zgłaszać potrzebę większej liczby spotkań, choć wcześniej sygnalizowali, że jest ich za dużo.
Sprawdź u siebie: czy osoba realizująca zadanie potrafi wyjaśnić jego cel i oczekiwane działanie bez odczytywania wygenerowanej specyfikacji?
Przy najbliższej funkcji omówcie makietę lub konkretny scenariusz użycia. Poproście programistę o przedstawienie rozwiązania własnymi słowami. Sprawdźcie, które zachowania są uzgodnione, a które wymagają jeszcze decyzji.
4. Fundamenty techniczne: czy szybsze zmiany można bezpiecznie wdrażać?
Kod powstaje szybciej, ale jego sprawdzenie nadal zajmuje dużo czasu? Kolejne zmiany wprowadzają niespójności, a wdrożenia wymagają ręcznych czynności? Warto przyjrzeć się architekturze, standardom, testom i automatyzacji dostarczania oprogramowania.
Z wcześniejszych projektów znamy problem mnożenia rozwiązań, które robią niemal to samo. Obrazowym przykładem przywołanym w rozmowie była aplikacja, w której przycisk można zaimplementować na 30 różnych sposobów. AI również może tworzyć kolejne warianty, dopóki nie otrzyma jasnych ograniczeń. Jedno z nich można ująć prosto:
„Tu masz jeden standard i tylko z niego korzystaj”.
Takie zasady trzeba odkrywać podczas pracy i uwzględniać w instrukcjach dla AI. Potrzebny jest sposób wychwytywania powtarzających się problemów oraz aktualizowania wytycznych.
Równie ważne są testy automatyczne i CI/CD, czyli automatyzacja integrowania oraz dostarczania zmian. W starszych systemach AI można wykorzystać już podczas porządkowania tych fundamentów: do analizy kodu, wskazywania miejsc wymagających testów i pomocy w ich przygotowaniu. Odtworzenie logiki biznesowej nadal wymaga przy tym udziału ludzi.
Sprawdź u siebie: co dziś utrudnia bezpieczne wdrażanie większej liczby zmian?
Wybierzcie obszar, w którym często pojawiają się poprawki lub ręczna weryfikacja. Sprawdźcie pokrycie testami, sposób wdrażania i obowiązujące standardy. Upewnijcie się również, że instrukcje dla AI wskazują istniejące komponenty i zasady, których należy przestrzegać.
5. Wiedza i kontekst: ile informacji trafia do AI na wejściu?
Programiści wyczerpują limity w narzędziach AI i proszą o droższe subskrypcje? Warto wtedy sprawdzić, jakie informacje model przetwarza podczas pracy. Jeśli do każdego zadania otrzymuje obszerną dokumentację projektu, zużywa tokeny również na materiały, które mogą być zbędne do jego wykonania. Sposób przekazywania wiedzy o projekcie wpływa więc na wykorzystanie dostępnych zasobów.
W Pragmatic Meet developerzy zaczęli sygnalizować: „Kończą się tokeny”. W tym samym czasie PO zauważył, że samo wczytanie informacji z grafu wiedzy o projekcie zajmowało około jednej czwartej do jednej trzeciej dostępnego kontekstu sesji AI. Znaczna część przestrzeni na dalszą rozmowę i pracę była zajęta już na starcie. To skłoniło zespół do przyjrzenia się temu, jak organizuje wiedzę i udostępnia ją modelowi.
Zespół rozwijał więc podejście oparte na małych, powiązanych ze sobą stronach. Zmieniła się też odpowiedzialność za zasób. Początkowo opiekowała się nim jedna osoba, ale z czasem utrzymywanie wiedzy stało się zadaniem całego zespołu.
Ten przykład pokazuje, dlaczego wraz ze wzrostem projektu warto kontrolować zarówno aktualność dokumentacji, jak i zakres informacji przekazywanych do konkretnego zadania.
Sprawdź u siebie: czy wiesz, jakie materiały AI otrzymuje podczas pracy i które z nich są rzeczywiście potrzebne?
Przejrzyjcie kontekst jednej niedawnej sesji. Poszukajcie informacji nieaktualnych, sprzecznych lub niezwiązanych z zadaniem. Ustalcie też, kto aktualizuje dokumentację po rozmowie z klientem albo zmianie decyzji produktowej.
6. Pomiar efektów: z czym porównujecie wyniki?
Rozważmy przykład z webinaru: jedna osoba wydaje na tokeny 7000 zł, druga 70 zł. „No i kto robi lepiej?” Bez informacji o rezultatach pracy trudno odpowiedzieć. Sam rachunek nie wyjaśnia, ile udało się dostarczyć i czy poniesiony koszt był uzasadniony.
Dlatego w Pragmatic Coders obserwujemy Monthly Delivery Rate, metrykę opartą na liczbie dostarczonych elementów biznesowych z backlogu, takich jak user stories. Dane zbieraliśmy jeszcze przed intensywnym wykorzystaniem AI, więc mamy punkt odniesienia do śledzenia zmian w czasie.
W przypadku Pragmatic Meet odnotowaliśmy około cztero- do pięciokrotnego przyspieszenia. Przy interpretacji tego wyniku ważny jest jednak szczegół: zespół korzystał z AI również przed przepisaniem platformy. Większe przyspieszenie pojawiło się po zmianie architektury i sposobu pracy, w tym wprowadzeniu podejścia opartego na specyfikacji. Wynik dotyczy więc konkretnego projektu i całego zestawu zmian.
Podobną ostrożność warto zachować we własnych pomiarach. Informacja, że programiści czują się bardziej produktywni, jest użyteczna, ale nadal pozostawia pytanie o wpływ tej zmiany na dostarczanie oprogramowania.
Sprawdź u siebie: na podstawie jakich danych uznajecie wdrożenie AI za udane?
Wybierzcie miarę dostarczania, którą będziecie regularnie obserwować. Ustalcie również, jak sprawdzicie jakość i koszty. Przy porównywaniu okresów zapisujcie inne zmiany, np. nową architekturę, skład zespołu czy sposób przygotowywania wymagań. Jeżeli brakuje danych historycznych, obecny wynik może być punktem odniesienia dla następnego eksperymentu.
7. Uczenie się organizacji: czy dobre rozwiązania trafiają do innych zespołów?
Jedna osoba wypracowała skuteczny sposób korzystania z AI. Inny zespół rozwiązuje podobny problem od początku. Warto wtedy sprawdzić, jak wiedza przepływa między projektami i co pomaga ją ponownie wykorzystać.
W Pragmatic Meet powstał mechanizm sprawdzania historyjek przed wysłaniem ich do Jiry. Opis jest oceniany z czterech perspektyw: programisty, agenta pomagającego w refinemencie, interesariusza biznesowego i osoby przygotowującej wymagania. Czasem potrzeba dwóch lub trzech iteracji, zanim historyjka przejdzie wszystkie oceny.
Jedna z perspektyw została oparta na konkretnym interesariuszu, Wiktorze, który zagląda do backlogu. Bartek opowiedział o tym słowami: „Dosłownie mam tam takiego Wiktora”. Chodziło o sprawdzenie, czy opis będzie zrozumiały również dla osoby patrzącej na niego od strony biznesowej.
Takie doświadczenia zaczęliśmy przekładać na wspólne wskazówki, ograniczenia i zasady dla kolejnych zespołów pracujących z AI. Pojedyncze rozwiązanie staje się wtedy punktem wyjścia do eksperymentów w innych projektach.
Wymaga to również aktualizacji. Zapisana praktyka powinna wracać do oceny wraz z kolejnymi doświadczeniami zespołów. W naszych wdrożeniach ten sposób pracy stale się rozwijał.
Sprawdź u siebie: co dzieje się z użytecznym rozwiązaniem, gdy jego autor skończy nad nim pracować?
Wybierzcie jeden sprawdzony eksperyment. Opiszcie problem, zastosowane podejście, warunki użycia i rezultat. Następnie przetestujcie go w innym zespole. Wyznaczcie osobę, która zbierze uwagi i zaktualizuje wspólne wskazówki.
Zacznij od problemu, który już widzisz
Przejdźcie przez te siedem obszarów, odwołując się do ostatnich sprintów. Poszukajcie konkretnych sytuacji: zadania zatrzymanego przez brak decyzji, specyfikacji wymagającej ponownego omówienia, wdrożenia opóźnionego przez ręczne testy.
Wybierzcie jeden problem, ustalcie zmianę do przetestowania i określcie, po czym poznacie jej rezultat. Dzięki temu kolejny krok we wdrażaniu AI będzie wynikał z doświadczeń Waszego zespołu.
Pomocna będzie nasza checklista gotowości do wdrożenia AI, przygotowana na podstawie problemów, które napotkaliśmy w naszej pracy i projektach klientów. Pobierz ją i wykorzystaj do wspólnego przeglądu sytuacji w zespole.
Więcej przykładów znajdziesz w webinarze „Dlaczego AI nie zwiększyło efektywności IT w Twojej firmie?”. Obejrzyj nagranie i poznaj doświadczenia, na podstawie których rozwijamy nasz sposób pracy z AI.
