Funkcje tworzone przez AI: jak zachować spójność produktu

Ocena funkcji tworzonej przez AI polega na sprawdzeniu, czy zmiana rozwiązuje rzeczywisty problem klienta, mieści się w jasno określonym zakresie, działa na całej ścieżce użytkownika i ma osobę odpowiedzialną za sprawdzenie efektu. Weryfikacja techniczna nadal jest potrzebna. Te pytania pomagają zdecydować przed wdrożeniem, czy zmiana pasuje do produktu.

Agent potrafi przygotować przekonujące demo, zanim ta decyzja zapadnie. Możesz kliknąć nowy przycisk, przejrzeć kod i zaakceptować testy. A mimo to dodać drugi sposób wykonania istniejącego zadania, niezrozumiałe ustawienie albo krok, który dokłada pracy komuś innemu.

Karri Saarinen, współzałożyciel Linear, w opublikowanym 15 października eseju Ktoś za tym oprogramowaniem opisuje obawę, że zmiany rozsądne z osobna mogą osłabiać wspólną wizję produktu. Tekst wywołał ożywioną dyskusję na Hacker News. To argument praktyka, a nie dowód, że agenci na ogół pogarszają produkty.

Co więc sprawdzać, gdy implementacja powstaje szybciej niż decyzja produktowa? Proponujemy ocenę opartą na czterech pytaniach. Łączy porady YC dotyczące poznawania problemów klientów z praktykami projektowymi opisanymi w Shape Up autorstwa Basecamp. To połączenie jest naszą propozycją: nie zmierzono jego skuteczności i nie przedstawiamy go jako metody potwierdzonej naukowo.

Dlaczego działająca funkcja może osłabić produkt?

Funkcja może spełniać specyfikację, a jednocześnie utrudniać zadanie, którego jest częścią. Spójny produkt pozwala w zrozumiały sposób doprowadzić sprawę do końca, z uwzględnieniem tego, co dzieje się przed nową interakcją i po niej.

Wyobraź sobie skrót do zmiany terminu rozmowy rekrutacyjnej. Skrót działa. Kandydat dostaje jednak inną wiadomość niż ta, którą widzi rekruter, a stary link nadal prowadzi do poprzedniego terminu. Każdy ekran może wyglądać sensownie, choć w całym procesie pozostaje niejasne, które ustalenia są aktualne.

Saarinen wiąże osąd produktowy z doświadczeniem, rozmowami z klientami i uwagą poświęcaną powiązaniom między poszczególnymi elementami. Dzięki temu można omówić coś konkretniejszego niż wrażenie, że funkcja pasuje. Zapytaj, jakie dotychczasowe oczekiwania zmienia i czy osoby, których dotyczy, nadal mogą ukończyć zadanie.

To samo pytanie można zadać przy pracy człowieka, agenta lub obu. Powodem do oceny jest proponowana zmiana produktu. Autorstwo kodu nie przesądza o tym, czy warto ją przyjąć.

Dostosuj ocenę do skali zmiany. Przy poprawce etykiety może wystarczyć krótkie wyjaśnienie i zrzut ekranu. Nowa ścieżka umawiania spotkań wymaga sprawdzenia interakcji, na które wpływa. Poniższe pytania mają pomóc w decyzji, a nie tworzyć komisję zatwierdzającą każdą poprawkę.

Jaki problem klienta rozwiązuje ta zmiana?

Zacznij od rzeczywistej sytuacji, w której użytkownik napotkał trudność. Zapisz, co próbował zrobić, gdzie utknął i jak poradził sobie z tym w obecnej wersji produktu.

W podsumowaniu Startup School i transkrypcji opublikowanych przez YC Eric Migicovsky radzi pytać o wcześniejszą sytuację związaną z problemem oraz o rozwiązania, których dana osoba już próbowała. Takie pytania dają więcej materiału do analizy niż reakcja na prezentowany pomysł.

Do opisu zmiany dołącz rozmowę z pomocą techniczną, obserwację pracy użytkownika albo jasno opisany przykład od klienta. Oddziel obserwację od interpretacji: „Rekruter przepisał nowy termin do dwóch wiadomości” opisuje zachowanie. „Potrzebujemy asystenta AI do umawiania spotkań” proponuje rozwiązanie o znacznie szerszym zakresie.

Wskaż osobę, której dotyczy problem, z dokładnością potrzebną do zrozumienia zadania. Kandydat zmieniający własną rezerwację ma inne potrzeby niż rekruter koordynujący rozmowę z kilkoma osobami. Nazwanie obu „użytkownikiem” może ukryć moment przekazania sprawy, który trzeba zrozumieć.

Zebrane informacje mogą uzasadniać drobną poprawę, nie rozstrzygając, czy warto rozwijać cały obszar. Jeden przykład może ujawnić mylącą interakcję; nie dowodzi, jak częsty jest problem na rynku. Wskaż, co wiadomo, co z tego wnioskujesz i jakie pytania pozostają otwarte.

Nawet jeśli funkcja zaczęła się od dema, nadal możesz zbadać problem. Zanim pokażesz zmianę, zobacz, jak ktoś wykonuje zadanie w obecnym produkcie. Być może wystarczy jaśniejszy tekst albo istniejący link. Możesz też odkryć głębszą potrzebę, której demo nie uwzględniało.

Pytanie przed decyzją: czy potrafisz opisać trudność klienta bez wspominania o funkcji? Jeśli odpowiedź sprowadza się do opisu tego, co zbudował agent, zbadaj problem przed rozszerzeniem implementacji.

Jaki kompromis pozwala utrzymać zakres zmiany?

Określ użyteczny rezultat i złożoność, którą jesteś gotów zaakceptować. Zapisz również, czego zmiana nie obejmuje, aby ocena miała wyraźne granice.

Rozdział Shape Up o wyznaczaniu granic opisuje ustalanie, ile pracy warto poświęcić projektowi, oraz zawężanie problemu w tych ramach. Przykład kalendarza pokazuje różnicę między potrzebą zobaczenia wolnych terminów a znacznie szerszym pomysłem zbudowania wszystkiego, co może oferować kalendarz.

Podobnie podejdź do oceny funkcji. „Pomóc kandydatowi znaleźć istniejącą ścieżkę zmiany terminu” określa ograniczony rezultat. „Umawianie spotkań bez wysiłku” zostawia miejsce na nowe kalendarze, uprawnienia, przypomnienia, preferencje i wyjątki, nie wskazując, co jest teraz ważne.

Zapisz rozważaną alternatywę. Czy można poprawić obecną ścieżkę, usunąć mylący krok lub zmienić wiadomość, która do niej prowadzi? Nowa funkcja łatwo wypada dobrze na tle niezmienionego produktu. Dopiero porównanie z mniejszą, ale użyteczną poprawką pokazuje rzeczywisty kompromis.

Następnie określ, z czego rezygnujesz. W przykładzie z terminami można wykluczyć zmiany przydzielania prowadzących rozmowy lub zasad wysyłania powiadomień. Taka granica przydaje się, gdy podczas implementacji pojawi się atrakcyjny pomysł z sąsiedniego obszaru: można wtedy zdecydować, czy nowe informacje uzasadniają ponowne ustalenie zakresu.

Uwzględnij też koszt późniejszego utrzymania. Ktoś musi wyjaśnić funkcję, obsługiwać jej stany, tłumaczyć komunikaty i reagować na błędy. Nie każdy przycisk wymaga spekulacyjnego modelu finansowego. Trzeba jednak zauważyć, kiedy skrót tworzy kolejną interakcję, której spójności zespół będzie musiał pilnować.

Pytanie przed decyzją: czy potrafisz wyjaśnić, dlaczego warto utrzymywać tę wersję zamiast mniejszego rozwiązania? Jeśli nie, ogranicz lub przepracuj propozycję. Działająca implementacja może nadal dostarczyć wiedzy, nawet jeśli nie trafi do użytkowników.

Czy cały proces nadal ma sens?

Wypróbuj zmianę w rzeczywistym zadaniu, uwzględniając zapisane dane i doświadczenie kolejnej osoby. Dopracowany ekran lub pojedynczy komponent nie pokazuje całej interakcji.

Rozdział Shape Up o ukończeniu pierwszego użytecznego fragmentu zaleca połączenie elementów w działającą całość, którą można wypróbować. W ocenie zmiany oznacza to przejście zadania od momentu rozpoczęcia aż do przekazania sprawy dalej.

Przy zmianie terminu zacznij tam, gdzie kandydat rzeczywiście otrzymuje zaproszenie. Otwórz link, wybierz godzinę, zapisz ją i wróć do rezerwacji. Następnie sprawdź widok rekrutera oraz wiadomości otrzymywane przez każdego uczestnika. Upewnij się, że wynik pozostaje zapisany po opuszczeniu strony.

Dobierz trudniejsze przypadki do zmiany. Termin może przestać być dostępny przed potwierdzeniem. Kandydat może ponownie otworzyć stary link. Prowadzący rozmowę może ją odwołać, gdy inna osoba nadal ma otwartą stronę. Podczas jednego przejścia nie sprawdzisz wszystkich możliwości, ale możesz ujawnić założenia wymagające weryfikacji technicznej.

Spójrz również na otoczenie nowej interakcji. Czy ścieżka używa znanych etykiet? Czy po błędzie można wrócić do zadania? Czy właściwa osoba może wykonać działanie na małym ekranie? Czy dostęp nadal zależy od odpowiedniego konta lub uprawnienia do rezerwacji?

Precyzyjnie określaj, czego dowodzą materiały. Nagranie pokazuje zdarzenia na nagranej ścieżce. Testy automatyczne potwierdzają zachowanie w granicach swoich asercji i konfiguracji. Żadne z nich nie uzasadnia ogólnego stwierdzenia, że cały produkt jest poprawny.

Podobną zasadę opisujemy w artykule o sprawdzaniu instrukcji zadania programistycznego przez osobę, która widzi je po raz pierwszy. Obserwacja rzeczywistego przejścia może ujawnić luki, których autor już nie dostrzega. Tutaj ocena obejmuje dodatkowo pytanie, czy funkcja w ogóle pasuje do reszty produktu.

Pytanie przed decyzją: czy właściwa osoba może wykonać obiecane zadanie, a kolejna zrozumieć wynik? Jeśli przekazanie sprawy dalej nie działa, napraw ten etap albo ogranicz obietnicę przed wdrożeniem.

Kto odpowiada za wynik po wdrożeniu?

Przypisz zmianie osobę odpowiedzialną i ustal, co konkretnie sprawdzi po wdrożeniu. Odpowiedzialność powinna obejmować również ocenę, czy zmiana pomogła.

W rozdziale o przekazywaniu odpowiedzialności Shape Up opisuje powierzanie całego projektu o ustalonym zakresie zespołowi, który sam określa swoje zadania. To wspiera samodzielność w jasnych granicach. Założyciel nie musi zatwierdzać każdego wyboru podczas implementacji, aby zachować spójność produktu.

Wskaż osobę, która wyjaśni decyzję, zbierze właściwych uczestników i zareaguje na dalszy rozwój sytuacji. Może to być osoba odpowiedzialna za produkt, projektant, inżynier lub założyciel. Zespół może dzielić się pracą, o ile wiadomo, do kogo zwracać się z pytaniami.

Zaplanuj obserwację związaną z pierwotnym problemem. Jeśli kandydaci nie znajdowali sposobu na zmianę rezerwacji, sprawdź, czy teraz potrafią to zrobić i czy zmieniają się rozmowy z pomocą techniczną dotyczące tej trudności. Same kliknięcia nowego przycisku nie odpowiadają na początkowe pytanie.

W produkcie używanym rzadko bezpośredni kontakt z klientami może powiedzieć więcej niż panel statystyk. W częściej używanych procesach można też analizować zdarzenia pomyślnego ukończenia zadania i błędów. W obu przypadkach nie traktuj różnicy zaobserwowanej po wdrożeniu jako dowodu związku przyczynowego, jeśli zmieniły się również inne warunki.

Ustal, co uzasadniałoby kolejną zmianę lub usunięcie funkcji. Skrót może powodować nieporozumienia, powielać istniejącą ścieżkę albo przenosić koordynację na rekruterów. To powody, by ponownie ocenić decyzję produktową, nawet jeśli implementacja nadal działa poprawnie technicznie.

Jeśli oceniasz opłacalność agentów, potraktuj ją jako osobne, jasno określone zagadnienie. Koszt zaakceptowanego rezultatu dotyczy rachunku kosztów pilotażu. Opisana tu ocena służy ustaleniu, czy ten konkretny rezultat zasługuje na akceptację.

Pytanie przed decyzją: kto wróci do pierwotnego problemu klienta i co sprawdzi? Przydziel tę odpowiedzialność przed wdrożeniem, aby pytanie nie zniknęło po premierze.

Zastosuj cztery pytania do zmiany terminu

Rozważmy hipotetyczną propozycję: agent dodaje dobrze widoczny przycisk zmiany terminu na stronie potwierdzenia rozmowy rekrutacyjnej. To przykład do analizy, a nie opis incydentu w Kit ani zapowiedź funkcji.

Punktem wyjścia jest rozmowa z klientem, który miał trudność ze znalezieniem istniejącej ścieżki. Propozycja może rozwiązać ten problem. Nie dowodzi jednak jeszcze potrzeby budowy nowego mechanizmu umawiania spotkań.

Przy ocenie zakresu porównaj widoczny przycisk z lepiej opisanym istniejącym linkiem. Załóżmy, że oba prowadzą do tego samego obecnego procesu zmiany terminu. Możesz wtedy ocenić łatwość znalezienia tej możliwości bez równoczesnego przebudowywania wyboru godzin lub uczestników. Zapisz ten wybór w opisie oceny.

Przy sprawdzaniu całego procesu przejdź przez udaną zmianę i nieudaną próbę. Sprawdź zapisaną rezerwację, widok kandydata po powrocie na stronę, widok rekrutera i powiadomienia. Zobacz, co pokazuje stare zaproszenie po zmianie godziny. Przycisk prowadzący do właściwej strony to dopiero pierwsza część tej oceny.

Te zależności mają konkretne odzwierciedlenie w obecnym kodzie planowania spotkań w Kit. Przy zmianie terminu system sprawdza warunki czasowe, stan rezerwacji oraz dostępność gospodarza i uczestników, aktualizuje zapisaną rezerwację i numer sekwencji kalendarza, a następnie dodaje powiadomienia do kolejki. To opis zadań wykonywanych przez kod; nie gwarantuje dostarczenia każdej zewnętrznej wiadomości. Wyjaśnia natomiast, dlaczego pozornie mała zmiana wymaga spojrzenia na całe zadanie.

Przy ustalaniu odpowiedzialności wskaż, kto przejrzy kolejne próby i związane z nimi uwagi. Ta osoba powinna sprawdzić, czy początkowa trudność kandydata została rozwiązana i czy większa widoczność przycisku nie tworzy nowego problemu. Użytkownicy mogą na przykład oczekiwać możliwości zmiany rezerwacji, której nie wolno już zmieniać.

Opis oceny może pozostać krótki:

Możliwe decyzje to akceptacja, ograniczenie zakresu, dalsze badanie lub odrzucenie. Ocena liczbowa sugerowałaby precyzję, której te pytania nie zapewniają. Gdy wstrzymujesz zmianę, wskaż brakujące informacje i kolejne działanie, aby zespół mógł rozstrzygnąć sprawę.

Zastosuj te same zasady w procesie rekrutacji

W rekrutacji łatwo zobaczyć, czym jest spójność produktu: działanie kandydata zmienia to, co zespół powinien zrobić dalej. Terminy rozmów, postęp między etapami, oczekiwania uczestników i wiadomości muszą do siebie pasować, aby proces był zrozumiały.

Kit oferuje procesy rekrutacji i planowania spotkań, w których te powiązania mają znaczenie. Nie udostępnia opisanych tu zasad oceny zmian produktowych, nie zatwierdza badań potrzeb klientów ani nie certyfikuje funkcji tworzonych przez agentów. Zespół nadal odpowiada za decyzję, które zmiany pasują do produktu, i za sprawdzenie ich efektów.

Przed akceptacją kolejnej funkcji zapisz problem klienta, kompromis dotyczący zakresu, całą ścieżkę i osobę odpowiedzialną. Zbierz materiały odpowiednie do skali zmiany, a potem podejmij decyzję. Jeśli szukasz procesu rekrutacji dla swojego startupu, możesz wypróbować Kit i sprawdzić, jak działania kandydatów oraz zespołu pasują do twojego sposobu pracy.