Agent przechodzi proces tak jak człowiek i mówi, gdzie się zaciął
Autor czyta to, co chciał napisać, a nie to, co napisał — i to samo dotyczy każdego procesu, który sam zbudowałeś. Zobacz, jak wygląda automatyzacja testów, w której agent przechodzi materiał albo ścieżkę w serwisie, wykonuje polecenia zamiast je streszczać i zgłasza w skali ważności.
Szacunek własny, nie pomiar z logów — czas sprzed wdrożenia nikt u nas nie mierzył stoperem.
Kurs napisany to nie jest kurs sprawdzony. Autor zna materiał na pamięć, więc czyta to, co chciał napisać, a nie to, co napisał. Nie zauważy, że rozdział czwarty zakłada ustawienie, o którym nie było mowy, ani że zrzut ekranu pokazuje inną wersję panelu.
Klasyczne rozwiązanie to dać kurs komuś do przejścia. Działa raz. Przy każdej poprawce trzeba prosić o to samo ponownie, a nikt nie przejdzie tego samego kursu po raz piąty z tą samą uwagą.
Zamiast tego posadziliśmy do kursu agenta, który przechodzi go tak jak kursant: lekcja po lekcji, wykonując polecenia, a nie streszczając je.
Robione ręcznie, przez osobę, która ten kurs napisała — czyli przez kogoś, kto podświadomie uzupełnia luki w instrukcji własną wiedzą. Dokładnie te luki, na które trafia początkujący.
CO KONKRETNIE BOLAŁO
Autor ma w głowie kontekst, którego nie zapisał. Dla niego lekcja jest kompletna — dla kogoś z zewnątrz urywa się w połowie.
Instrukcja mówi „wróć do ustawień”, których nikt jeszcze nie otwierał. Widać to dopiero, gdy ktoś naprawdę próbuje to zrobić.
Interfejs się zmienił, nazwa przycisku też. Kursant utyka na czymś, czego autor nie sprawdzał od pół roku.
Jednorazowy przegląd przez znajomego nie skaluje się na dwadzieścia poprawek rozłożonych na kwartał.
JAK TO DZIAŁA
Agent wchodzi na konto testowe z normalnym dostępem — nie czyta plików źródłowych. Widzi dokładnie to, co zobaczy człowiek po zakupie.
Różnica jest zasadnicza. Streszczenie lekcji zawsze wygląda sensownie. Dopiero próba wykonania kroku pokazuje, że brakuje w nim jednej informacji.
Nie każda uwaga jest błędem. Czerwone blokuje przejście dalej, pomarańczowe utrudnia, niebieskie to propozycja. Bez tej skali raport jest listą życzeń.
Konto testowe nie liczy się do analityki ani nie wywołuje powiadomień sprzedażowych. Inaczej każdy przebieg fałszowałby dane.
Mechanizm jest jeden: przejdź proces jak człowiek, wykonuj polecenia, zgłaszaj w skali ważności.
Agent wchodzi na konto testowe z normalnym dostępem i przechodzi lekcje po kolei, wykonując ćwiczenia. Wyłapuje to, czego autor nie zobaczy: krok zakładający wiedzę, o której nie było mowy, i zrzut ekranu sprzed dwóch wersji interfejsu.
Co ten serwis wymusił: Konto testowe trzeba było wyciąć z analityki i powiadomień, bo pierwszy przebieg wygenerował „zakup”, którego nie było.
Ten sam pomysł zastosowany do formularzy i ścieżek zakupowych: agent klika, wypełnia i sprawdza wynik w przeglądarce, a nie w kodzie. Wyłapuje rzeczy, których test jednostkowy nie zobaczy — pole ukryte pod paskiem, przycisk poza ekranem, komunikat, który nie wraca.
Co ten serwis wymusił: Testy muszą pracować na izolowanej sesji, żeby nie ruszać danych ani ustawień żywego użytkownika.
Skoro agent i tak przechodzi proces krok po kroku, po drodze robi zrzuty ekranu w kolejności kroków. Wracają do lekcji jako ilustracje, więc kontrola jakości i produkcja materiałów dzieją się w jednym przebiegu.
Co ten serwis wymusił: Przy zmianie interfejsu wymieniamy zrzut, a nie przepisujemy lekcję.
Agent dostaje konkretną postać: imię, firmę, poziom wiedzy i powód, dla którego kupił kurs. Dzięki temu ocenia materiał z jednej perspektywy, a nie z wszystkich naraz.
Ćwiczenia są realnie robione — agent otwiera narzędzia, klika i zapisuje, co wyszło. Streszczenie lekcji nie wykryłoby, że opisany przycisk zmienił nazwę.
Każde potknięcie dostaje wagę: blokada, poważny problem, drobiazg, uwaga stylistyczna. Bez tego raport byłby listą, a nie kolejnością prac.
Zapis tego, co agent zrozumiał, wraca do autora jako materiał — bo pokazuje, które fragmenty tłumaczą, a które tylko opisują.
Pierwsza wersja prosiła o podsumowanie lekcji. Wszystko wychodziło świetnie i nic nie znajdowało. Dopiero polecenie „wykonaj” zaczęło wyłapywać luki.
Lista czterdziestu uwag bez hierarchii ląduje w szufladzie. Trzy czerwone flagi poprawia się tego samego dnia.
Zapomnieliśmy o tym przy pierwszym przebiegu i sprzedaż dostała powiadomienie o „zakupie”, którego nie było.
Mechanizm nie zależy od tego, co testujemy — tylko od tego, czy da się powiedzieć, kiedy przejście się udało.
Najdroższy proces do zepsucia i najrzadziej testowany ręcznie, bo wymaga przejścia płatności.
Każda edycja bloków może zepsuć pole, którego nikt nie sprawdza. Przebieg po publikacji wyłapałby to zanim zrobi to klient.
Porównanie zrzutów przed i po wdrożeniu, żeby zmiana w jednym theme nie psuła układu w drugim.
Wszędzie tam, gdzie ktoś musi przeklikać proces od początku, żeby sprawdzić, czy nadal działa.
Ten sam wzorzec działa wszędzie tam, gdzie ktoś musi przeklikać proces od początku do końca, żeby sprawdzić, czy nadal działa — onboarding nowego pracownika, ścieżka zamówienia w sklepie, formularz zgłoszeniowy, konfigurator.
