Z boku może się wydawać, że świat Salesforce kręci się dziś wyłącznie wokół Agentforce i autonomicznych agentów. Prezentacje, keynote’y i roadmapy rysują obraz systemów, które same rozumieją kontekst, podejmują decyzje i realizują cele biznesowe bez naszego ciągłego udziału. Tymczasem codzienność wielu zespołów wygląda znacznie bardziej przyziemnie: naprawianie starych Flowów, porządkowanie danych i spłacanie długu technologicznego, który ktoś zostawił kilka lat temu.
Ten rozdźwięk między wizją a rzeczywistością jest dziś bardzo wyraźny. A jednak, nawet pracując w tym przyziemnym trybie, trudno nie zauważyć, że coś fundamentalnego w sposobie projektowania systemów zaczyna się zmieniać. I jednym z pierwszych miejsc, gdzie ta zmiana staje się widoczna, jest warsztat analityczny. Konkretnie: klasyczne User Story.
Od projektowania ścieżek do projektowania intencji
Przez lata User Story było solidnym fundamentem pracy zespołów wdrożeniowych. Pomagało opisać potrzebę użytkownika, zdefiniować zakres i zaprojektować przewidywalną ścieżkę od punktu A do punktu B. Diagramy procesów, walidacje, reguły biznesowe i kryteria akceptacji domykały całość w szczelne, deterministyczne ramy.
Ten model świetnie sprawdzał się w świecie systemów, które reagowały dokładnie tak, jak zostały zaprogramowane. Kliknięcie wyzwalało akcję. Warunek prowadził do konkretnego rezultatu. Każdy krok był zaplanowany z góry.
Dziś coraz częściej okazuje się to niewystarczające.
W systemach wykorzystujących AI nie projektujemy już wyłącznie ścieżek. Projektujemy zachowanie. A to zasadniczo zmienia sposób, w jaki opisujemy wymagania.
Dla kontrastu:
- kiedyś: „Jako użytkownik chcę, aby po zaznaczeniu checkboxa ‘Refund’ system wysłał maila do klienta z szablonem numer 5”;
- dziś: „Działaj jako koordynator zwrotów. Jeśli klient wykazuje frustrację, zaproponuj mu rabat na kolejny zakup. Jeśli komunikacja jest neutralna, poinformuj o standardowej procedurze, bazując na aktualnych stanach magazynowych”.
W tym drugim przypadku nie interesuje nas już pojedynczy przycisk ani konkretny szablon. Opisujemy intencję, kontekst i oczekiwany sposób reakcji systemu. To nie jest detal semantyczny. To zmiana paradygmatu.
Specyfikacja behawioralna zamiast listy kroków
Wraz z tą zmianą inaczej zaczyna wyglądać sama dokumentacja. Coraz większą rolę odgrywają elementy, które wcześniej były drugorzędne albo w ogóle nie występowały w klasycznych User Story.
Pojawiają się guardrails, czyli jasno opisane granice zachowania systemu. Nie w formie wyjątków w logice, ale zasad typu: „system nigdy nie powinien obiecywać dostawy w 24 godziny dla produktów wielkogabarytowych” albo „nie eskaluj sprawy, jeśli klient już otrzymał rekompensatę w ciągu ostatnich 30 dni”.
Równolegle rośnie znaczenie kontekstu. System nie podejmuje decyzji na podstawie jednego pola czy statusu, ale na podstawie historii interakcji, tonu komunikacji, wcześniejszych decyzji i danych pochodzących z różnych kanałów. Opisanie tego w klasycznej strukturze „As a user I want…” staje się trudne i coraz mniej precyzyjne.
W praktyce coraz częściej próbujemy opisywać reguły biznesowe językiem naturalnym w taki sposób, by były zrozumiałe nie tylko dla dewelopera, ale również dla technologii, która ma je interpretować. To wymaga innej dokładności i innego sposobu myślenia o wymaganiach.
User Story nie znika, ale przestaje wystarczać
To nie jest manifest o końcu User Story. Wciąż pozostaje ono bardzo dobrym narzędziem tam, gdzie projektujemy deterministyczne procesy, formularze, walidacje czy klasyczne automatyzacje. Problem pojawia się wtedy, gdy próbujemy tym samym narzędziem opisać system, który ma interpretować sytuację i podejmować decyzje w warunkach niepełnej informacji.
W takich przypadkach klasyczne User Story opisuje zbyt mały fragment rzeczywistości. Skupia się na interakcji, a pomija zachowanie. Na akcji, a nie na intencji. Na jednym scenariuszu, zamiast na spektrum możliwych reakcji.
Dlatego coraz częściej potrzebujemy czegoś więcej: specyfikacji, które definiują rolę systemu, jego granice decyzyjne, sposób reagowania na kontekst i priorytety biznesowe. Nie zamiast User Story, ale obok niego.
Zmiana warsztatu, nie rewolucja
Nawet jeśli dziś pracujemy głównie nad utrzymaniem istniejących procesów i daleko nam do autonomicznych agentów, ten sposób myślenia powoli przenika do codziennej pracy. Widać go w rozmowach z biznesem, w oczekiwaniach wobec „inteligentnych” funkcji i w coraz częstszych próbach opisywania systemów w kategoriach zachowań, a nie tylko funkcji.
To jeszcze nie jest nowy standard analizy wymagań. Ale wszystko wskazuje na to, że bez takiej zmiany warsztatu projekty z komponentem AI będą albo nadmiernie skrępowane sztywną logiką, albo zbyt nieprzewidywalne, by realnie wspierać biznes.
A to oznacza, że prędzej czy później ten temat trafi z prezentacji i wizji wprost do naszych backlogów. I wtedy klasyczne User Story może okazać się dobrym punktem wyjścia, ale już nie wystarczającym narzędziem do opisania tego, czego naprawdę oczekujemy od nowoczesnych systemów.
