Podręcznik mikrokonsultingu

Na tyle małe, by powiedzieć „tak”

To jest książka o małej pracy. Nie małej ambicją, lecz kształtem: o zleceniu ze stałym zakresem, krótkim kalendarzem i jednym rezultatem, na który klient może wskazać palcem, kiedy wszystko się skończy. Płatny audyt tego, jak zespół korzysta z AI. Naprawa jednego bolesnego procesu. Zestaw przetestowanych promptów. Dwutygodniowy pilotaż agenta. Półdniowe szkolenie. Sprint dokumentacyjny, który zamienia wiedzę plemienną w coś, co przeczyta zarówno model, jak i nowy pracownik. Każde z nich łatwo kupić, szybko dostarczyć z pomocą Claude’a, a do tego każde zaprojektowano tak, by prowadziło do następnego.

Dlaczego małe? Bo najtrudniejszą częścią doradztwa nigdy nie była sama praca. Najtrudniejsze jest „tak”. Duże zlecenie wymaga od kupującego zobowiązania budżetu, którego nie ma, wobec osoby, której jeszcze nie sprawdził, w zamian za wynik, którego nie potrafi sobie wyobrazić. Małe prosi tylko o zaryzykowanie niewielkiej kwoty na konkretny rezultat w konkretnym terminie. Pierwsza rozmowa trafia do komisji. Druga kończy się płatnością kartą, a w najgorszym razie podpisem kierownika, który nie musi w tym celu zwoływać zebrania.

Jest i drugi powód, i to on sprawia, że właśnie teraz jest na to dobry moment. Narzędzia agentowe drastycznie zmniejszyły wysiłek stojący za ogromną klasą pożytecznej pracy. To, co kiedyś zajmowało konsultantowi trzy tygodnie czytania, pisania i budowania, dziś zajmuje kilka skupionych dni, podczas których czytaniem, pisaniem i sporą częścią budowania zajmuje się Claude. Jeśli sprzedajesz tę pracę na godziny, narzędzia cię zubożą. Jeśli sprzedajesz ją jako stały rezultat, narzędzia zrobią z ciebie firmę. Mikrozlecenie to po prostu handlowy kształt, który pasuje do nowej ekonomii.

Małe „tak” to wciąż „tak”. I jedyne, jakie może ci dać ktoś obcy.

Książka opiera się na stu ruchach, zebranych w dziesięciu częściach. Wczesne części dotyczą samej oferty i warsztatu, którym będziesz ją realizować: jak briefować model, jak karmić go kontekstem, jak pracować w repozytorium z Claude Code, jak zamykać powtarzalną pracę w skillach. Środek dotyczy dostarczania, realizacji i kształtu ceny, przy czym ani razu nie pada tu żadna liczba, bo twoje stawki zależą od twojego rynku, a nie od czyjegokolwiek innego. Ostatnie części mówią o dowodach, lejku sprzedażowym i o tym, dokąd to wszystko zmierza. Każdy rozdział to albo ruch, który możesz wykonać w tym tygodniu, albo mikrozlecenie, które możesz poprowadzić, a większość kończy się zachętą, żeby spróbować.

Jedno ostrzeżenie na początek. Małe zlecenia nie są gorszą odmianą doradztwa. Trudniej je zrobić dobrze, bo nie ma się za czym schować. Dwunastomiesięczny program przełknie dwa kiepskie tygodnie. Dwutygodniowy sprint – nie. Będziesz musiał ciasno określać zakres, dostarczać tak, żeby było to widać, i uczciwie mierzyć. W zamian dostaniesz szybszą informację zwrotną, zadowolonych klientów i lejek, który sam się napełnia. Cała sztuka, jak się okazuje, nie polega na tym, by sprzedawać więcej. Polega na tym, by sprzedawać mniej, wcześniej, a potem zrobić to jeszcze raz.

Sprzedawaj rezultaty, nie godziny

Rozliczanie godzinowe ma jedną cichą wadę, która staje się bardzo głośna w chwili, gdy zaczynasz pracować z Claude’em: karze cię za to, że robisz się szybszy. Każda godzina zaoszczędzona dzięki narzędziom to godzina, której nie możesz zafakturować. Stań się dwa razy szybszy, a przy stawce dziennej właśnie zmniejszyłeś swoje dochody o połowę za ten sam wynik. Nikt celowo nie projektuje tak firmy. Mnóstwo konsultantów po prostu w to dryfuje.

Alternatywą jest wycena rezultatu. Klient nie kupuje twojej obecności; kupuje przeaudytowany proces, działający pilotaż, przeszkolony zespół, zestaw promptów, które za pierwszym podejściem dają zgodne z wymogami teksty. Opisz tę rzecz precyzyjnie, przypisz jej jedną cenę i ustal termin. Ile czasu ci to zajmie, jest odtąd twoją sprawą, a nie ich. Kiedy Claude w jedno popołudnie zrobi to, co kiedyś zajmowało tydzień, ta wydajność zostaje u ciebie i finansuje kolejne udoskonalenie twojej metody.

Zmienia to także rozmowę z kupującym, przeważnie na lepsze. Stawka dzienna zaprasza do targowania się o nakłady: dlaczego to wymaga pięciu dni, czy nie dałoby się w cztery, kto jest w zespole. Stały rezultat zaprasza do rozmowy o wartości: ile to jest dla was warte, co się stanie, jeśli zadziała, jak wygląda „gotowe”. Ta druga rozmowa jest bardziej użyteczna dla obu stron i znacznie mniej wyczerpująca. Zmusza cię też do zdefiniowania, co znaczy „gotowe”, a to, jak przekonują dalsze rozdziały, najcenniejszy pojedynczy nawyk w tym rodzaju pracy.

Warto też powiedzieć wprost, z czego rezygnujesz. Wynajmowanie się na dniówki, żeby siedzieć w cudzym zespole, to zupełnie przyzwoita praca. Po prostu nie jest to mikrokonsulting. Robi z ciebie podwykonawcę z dodatkowymi krokami, opłacanego za obecność, a nie za wyniki, i skaluje się dokładnie tak daleko, jak sięga twój kalendarz. Rezultatem mikrokonsultanta jest system, dokument, kompetencja albo decyzja. Twoja obecność jest sprawą uboczną.

Fakturuj za dziurę w ścianie, nie za wiertarkę. Zwłaszcza teraz, gdy wiertarka robi większość roboty.

Ryzyka są realne. Stały rezultat oznacza, że to ty pokrywasz przekroczenia, jeśli źle określiłeś zakres, a niektórej pracy naprawdę nie da się z góry ograniczyć. Odpowiedzią nie jest ucieczka do stawek godzinowych. Odpowiedzią jest mniejszy zakres. Jeśli nie potrafisz z pewnością opisać rezultatu, sprzedaj płatne rozpoznanie, którego produktem jest ten opis, a rezultat wyceń dopiero wtedy, gdy go zobaczysz. Niepewność to powód, by zmniejszyć pierwsze zlecenie, nigdy powód, by odpuścić jego stałość.

Wypróbuj to na swojej obecnej ofercie. Przepisz każdą pozycję, która wspomina dni albo godziny, na rzeczownik – coś, co klient będzie miał na własność na końcu. Pięć dni doradztwa AI staje się uszeregowaną listą sześciu procesów wartych automatyzacji, wraz z działającym prototypem pierwszego. Lepiej się to czyta, lepiej się sprzedaje i po cichu zobowiązuje cię do czegoś, z czego naprawdę możesz być dumny. Twoje godziny nigdy nie były produktem. Były po prostu jedyną rzeczą, którą umiałeś policzyć.

Rozmowa diagnostyczna

Pierwsza rozmowa z potencjalnym klientem to nie prezentacja oferty. To diagnoza. Większość konsultantów ją marnuje, opowiadając, czym się zajmuje – co kupujący mógłby przeczytać na stronie internetowej – zamiast ustalić, co jest nie tak, czego kupujący sam może do końca nie wiedzieć. Kosztowny problem rzadko pojawia się w pierwszym zdaniu. Pojawia się mniej więcej przy dwunastym pytaniu, kiedy już przestałeś mówić.

Przyjdź z listą. Dwadzieścia pytań to dobra liczba, choć nie zadasz wszystkich. Zacznij od pracy, nie od technologii: opowiedz mi o ostatnim razie, kiedy coś poszło nie tak, kto tego dotykał, ile to trwało, ile kosztowało, co zrobiliście zamiast tego. Potem przejdź do krawędzi: co już próbowaliście, kto musiałby zatwierdzić zmianę, co się stanie, jeśli w tym kwartale nic się nie zmieni. Dopiero na końcu pytaj o narzędzia, a nawet wtedy pytaj, czego używają, a nie czego chcą. Ludzie opisują swoje aspiracje w kategoriach oprogramowania. Swoje problemy opisują w kategoriach wtorków.

Claude przydaje się po obu stronach rozmowy. Przed nią wklej to, co wiesz o firmie, jej publiczne materiały i informacje o branży, i poproś o dopasowaną listę pytań, uszeregowaną według tego, jak prawdopodobne jest, że każde z nich wydobędzie na wierzch kosztowny problem. Po rozmowie wklej notatki albo transkrypcję, za zgodą rozmówcy, i poproś o uporządkowane podsumowanie: problem zgłoszony, problem rzeczywisty, kto jest jego właścicielem, ile kosztuje i które mikrozlecenie by go rozwiązało. To podsumowanie staje się pierwszą stroną twojej propozycji, a co ważniejsze – czymś, co odsyłasz jeszcze tego samego popołudnia, żeby kupujący mógł to poprawić.

Ta poprawka ma znaczenie. Kupujący, który redaguje twoje podsumowanie swojego problemu, właśnie zaczął współtworzyć ofertę. Jest teraz współautorem diagnozy, a ludzie rzadko odrzucają diagnozy, które pomagali pisać. Niech podsumowanie będzie krótkie, na jedną stronę, w ich języku, a nie twoim. Jeśli przyłapiesz się na pisaniu o lewarowaniu albo synergii, poproś Claude’a, żeby przepisał tekst słownictwem, którego kupujący używał podczas rozmowy.

Prezentowanie oferty na pierwszej rozmowie to jak wypisywanie recepty, zanim pacjent zdąży usiąść.

Zakończenie rozmowy też jest sztuką. Nie zamykaj jej propozycją przesłania oferty. Zamknij ją, nazywając problem z powrotem, w jednym zdaniu, i pytając, czy dobrze go rozumiesz. Jeśli powiedzą „tak”, opowiedz, jak wyglądałby mały pierwszy krok i kiedy możesz go przesłać. Jeśli powiedzą „nie”, właśnie dowiedziałeś się czegoś znacznie cenniejszego niż sprzedaż, a rozmowa wcale się nie skończyła.

Spróbuj tego w tym tygodniu. Spisz swoje dwadzieścia pytań w kolejności: praca, krawędzie, narzędzia, i trzymaj je w notatce, którą otworzysz podczas każdej rozmowy. Następną rozmowę poprowadź tak, by nie opisywać swoich usług aż do ostatnich pięciu minut. Będziesz mówić mniej, dowiesz się więcej i wycenisz właściwy problem. Kupujący zapamięta cię jako osobę, która słuchała, a na tym rynku to zaskakująco rzadkie wyróżnienie.

Płatny audyt

Audyt AI o stałym zakresie to najlepsze drzwi wejściowe, jakie mikrokonsultant może zbudować. Dla kupującego jest mało ryzykowny, tobie płaci się za niego w całości, jest na tyle krótki, że kończy się, zanim ktokolwiek straci zainteresowanie, i kończy się mapą drogową, którą akurat ty najlepiej możesz zrealizować. To sprzedaż, która produkuje kolejną sprzedaż, pod warunkiem że przeprowadzisz ją porządnie.

Kształt jest prosty. W ciągu tygodnia lub dwóch rozmawiasz z kilkoma osobami, obserwujesz, jak naprawdę płynie praca, przeglądasz używane narzędzia i dane, a na koniec przygotowujesz uszeregowaną listę szans. Każda szansa dostaje krótki opis, uczciwe oszacowanie wartości, oszacowanie nakładu, uwagę o ryzyku i rekomendowane mikrozlecenie, które ją wykorzysta. Dwie lub trzy pierwsze mają zakres określony na tyle ciasno, że można je kupić prosto ze strony. Pozostałe zostają odłożone na bok – w widoczny sposób, żeby klient zobaczył, że nie sprzedajesz mu po prostu wszystkiego, co znalazłeś.

Claude przyspiesza audyt, nie spłycając go. Transkrypcje wywiadów, za zgodą rozmówców, wchodzą na wejściu, a wychodzą jako tematy, cytaty i powtarzające się skargi. Opisy procesów zamieniają się w proste schematy przepływu, które możesz sprawdzić z osobami, które je opisały. Arkusz zadań można ocenić według kryteriów, które piszesz razem z klientem. Synteza, która kiedyś wymagała dni ponownego czytania notatek, staje się godziną przeglądania i poprawiania tego, co naszkicował model. Twój czas idzie tam, gdzie powinien: w osąd, które szanse są prawdziwe.

Bądź surowy w kwestii tego, czym audyt nie jest. Nie jest darmowy, bo darmowe audyty traktuje się jak próbki, a ich rekomendacje jak opinie. Nie jest prezentacją strategii, bo w małej firmie nikt nie działa na podstawie prezentacji strategicznych. I nie jest otwarty. Ustal liczbę wywiadów, liczbę szans, które uszeregujesz, i datę prezentacji wyników. Kiedy klient poprosi, żebyś przyjrzał się jeszcze jednemu działowi, uśmiechnij się i dopisz to do listy rzeczy, którymi może zająć się następne zlecenie.

Audyt, który nie kończy się decyzją, to po prostu drogi sposób, żeby poczuć się nowocześnie.

To prezentacja wyników sprawia, że audyt na siebie zarabia. Przedstaw uszeregowaną listę na żywo, objaśnij pierwszą trójkę i, jeśli możesz, pokaż wstępny prototyp pierwszej pozycji, choćby jeden artefakt zbudowany poprzedniego wieczoru. Potem zapytaj, od której chcą zacząć. Nie czy. Od której. Audyt spełnił swoje zadanie, jeśli kupujący wychodzi ze spotkania, wybierając między twoimi kolejnymi zleceniami, a nie zastanawiając się, czy w ogóle jakieś zlecić.

Żeby zbudować własny, zacznij od rezultatu. Naszkicuj przykładowy raport z audytu dla wymyślonego klienta z twojej branży: tabelę z rankingiem, trzy rekomendacje z określonym zakresem, listę rzeczy odłożonych. Potem cofnij się do wywiadów i przeglądów, które byłyby potrzebne, by uczciwie go wypełnić. Masz teraz produkt, szablon i całkiem niezłe pojęcie o tym, co sprzedajesz. Większość konsultantów opisuje swój audyt. Bardzo niewielu ma taki, który mogłoby pokazać.

Dwutygodniowy sprint

Jeśli audyt jest drzwiami wejściowymi, sprint jest pierwszym pokojem. Dwa tygodnie, jeden problem, jeden działający rezultat. To dość długo, by dostarczyć coś prawdziwego, i dość krótko, by nikt nie potrzebował zgody zarządu, procesu zakupowego ani komitetu sterującego. A przede wszystkim na tyle krótko, że przetrwa impet. Długie zlecenia zwykle nie upadają przez złą pracę. Upadają przez gasnącą uwagę.

Dwa tygodnie mają naturalny rytm. Dzień pierwszy to dostępy i start: dane logowania, wskazana z imienia i nazwiska osoba decyzyjna, spisana definicja ukończenia. Pierwszy tydzień to budowanie, małymi przyrostami, z demonstracją na koniec. Drugi tydzień to dopracowywanie, testowanie na prawdziwych przypadkach i przygotowanie przekazania: instrukcja obsługi, prompty, krótkie nagranie z omówieniem, sesja z osobą, która przejmie całość. Ostatniego dnia demonstrujesz gotową rzecz, pokazujesz zmierzoną zmianę i proponujesz, co dalej.

Z Claude’em jako partnerem w realizacji w dwóch tygodniach mieści się zaskakująco dużo. Automatyzacja procesu, która czyta przychodzące dokumenty, wyciąga to, co istotne, i szkicuje odpowiedź do zatwierdzenia przez człowieka. Małe narzędzie wewnętrzne, zbudowane jako prototyp w jednym pliku, a potem utwardzone. Biblioteka skilli do powtarzalnych zadań pisarskich zespołu. Pilotaż agenta uruchomiony na próbce prawdziwej pracy z zeszłego miesiąca. Żadna z tych rzeczy nie jest banalna, ale wszystkie się mieszczą, pod warunkiem że zakres to jeden problem, a nie trzy.

Ten warunek to cała dyscyplina. Sprint żyje albo umiera razem z definicją ukończenia, którą piszesz pierwszego dnia. Niech będzie konkretna, sprawdzalna i sformułowana słowami klienta: zespół potrafi przetworzyć tydzień faktur od dostawców z pomocą asystenta, a dziewięć na dziesięć szkiców wymaga najwyżej drobnych poprawek. Unikaj przymiotników takich jak solidny czy bezproblemowy, które opisują twoje samopoczucie, a nie to, co da się przetestować. Jeśli nie potrafisz zapisać definicji ukończenia w dwóch zdaniach, sprint jest za duży. Podziel go.

Dwa tygodnie to nie termin. To pojemnik, a pojemniki są po to, żeby rzeczy się nie rozlewały.

Pojawi się presja, żeby to rozciągnąć. Klient widzi wczesne postępy i pyta, czy nie zająłbyś się przy okazji powiązanym procesem. Odpowiedź brzmi: tak, w następnym sprincie. Zapisz to, umieść na liście na końcową demonstrację i pracuj dalej. Sprint, który kończy się na czas z mniejszym zakresem, buduje więcej zaufania niż taki, który kończy się z opóźnieniem, ale ze wszystkim w środku.

Spróbuj naszkicować trzy sprinty, które mógłbyś sprzedać jutro. Dla każdego zapisz problem w jednym zdaniu, definicję ukończenia w dwóch, a pakiet przekazania w trzech. Jeśli któryś potrzebuje więcej, to program udający sprint. Zmniejszaj go, aż zmieści się na fiszce. Małe, skończone i zademonstrowane wygrywa z dużym, prawie gotowym i objaśnionym – za każdym razem, bez wyjątku.

Nazwij to

Usługa bez nazwy to przysługa. Usługa z nazwą to produkt z ceną. Brzmi to jak marketingowy kaprys i po części nim jest, ale opiera się na praktycznej prawdzie o tym, jak myślą kupujący. Ludzie układają sobie rzeczy według nazw. Trochę pomocy z tymi naszymi sprawami od AI ląduje w szufladzie z napisem „różne”, gdzie zresztą budżety idą umierać. Sprint porządkowania skrzynki odbiorczej trafia do osobnej szuflady, obok innych rzeczy, które kosztują pieniądze i przynoszą wyniki.

Nazwa wykonuje trzy zadania jednocześnie. Mówi kupującemu, co dostaje, zanim to objaśnisz. Pozwala mu powtórzyć ją komuś innemu, a właśnie tak wędrują polecenia. I ogranicza ciebie, bo kiedy zlecenie ma nazwę, ma też kształt, a kształty opierają się powolnemu rozrastaniu, które zamienia pracę o stałym zakresie w otwartą. Zestaw promptów dla obsługi klienta nie może po cichu stać się migracją CRM. Nazwa by zaprotestowała.

Dobre nazwy są proste. Mówią, co dana rzecz robi, dla kogo, a czasem także ile trwa. Audyt gotowości na AI. Dwutygodniowy pilotaż agenta. Sprint dokumentacji procedur. Warsztat z Claude’a dla zespołu. Sprytne nazwy, które trzeba objaśniać, mijają się z celem. Jeśli musisz opisać nazwę, zanim opiszesz usługę, zbudowałeś sobie drugi problem. Gry słowne zostaw na wpisy blogowe.

Claude całkiem nieźle sobie z tym radzi, jeśli dobrze go zbriefujesz. Podaj mu problem, który rozwiązuje zlecenie, kupującego, dla którego jest przeznaczone, rezultat, czas trwania i trzy nazwy, których już nie lubisz, a potem poproś o dwadzieścia prostych propozycji uszeregowanych według jasności. Następnie wypowiedz najlepszą piątkę na głos do kogoś, kto nie pracuje w twojej branży. Wygrywa ta, którą ta osoba potrafi ci powtórzyć godzinę później. Zapamiętywalność to test, a nie wrażenie.

Jeśli nie potrafią tego powiedzieć swojemu szefowi, nie potrafią tego od ciebie kupić.

Kiedy rzecz ma już nazwę, daj jej stronę. Jedną stronę, z problemem, rezultatem, harmonogramem, tym, co zapewnia klient, tym, co zapewniasz ty, i tym, co zwykle dzieje się dalej. Nie umieszczaj na niej ceny, jeśli twój rynek woli rozmowę, ale daj jasno do zrozumienia, że cena istnieje i jest stała. Ta strona staje się linkiem, który wysyłasz po rozmowie diagnostycznej, załącznikiem do oferty i rzeczą, którą kupujący przekazuje osobie, która podpisuje. Sprzedaje więcej niż ty.

Przyjrzyj się w tym tygodniu swoim trzem ostatnim zleceniom. Nadaj każdemu nazwę, tak jakbyś sprzedał je jako produkt. Potem zauważ, które chętnie sprzedałbyś ponownie dokładnie w takiej postaci, a które chciałbyś zmienić. Te, które sprzedałbyś ponownie, to twój katalog. Reszta była przysługami, co jest w porządku, ale czas przestać udawać, że była strategią.

Jedna branża, za to głęboko

Generaliści konkurują ze wszystkimi. Specjaliści – prawie z nikim. To stara rada, starsza niż którekolwiek z narzędzi opisanych w tej książce, ale w mikrokonsultingu ma większe znaczenie niż w większości innych rodzajów pracy, bo małe zlecenia żyją albo umierają w zależności od tego, jak szybko potrafisz określić ich zakres. Konsultant, który już zna branżę, przychodzi z zakresem w połowie gotowym.

Przyjrzyj się różnicy podczas rozmowy diagnostycznej. Generalista pyta gabinet stomatologiczny, jak umawia się wizyty, i spędza dwadzieścia minut na uczeniu się słownictwa. Specjalista już zna oprogramowanie do rezerwacji, którego najpewniej używają, przepisy regulujące dokumentację pacjentów, trzy zadania, które zjadają popołudnie recepcjonistki, i powody, dla których wcześniejsze próby automatyzacji zwykle zawodziły. Pierwsze pytanie specjalisty jest piętnastym pytaniem generalisty. Ta przewaga na starcie przekłada się na ostrzejszą ofertę, szybszy sprint i klienta, który czuje się zrozumiany, a nie przesłuchany.

Specjalizacja wyostrza też twój warsztat pracy z Claude’em. Każde zlecenie w tej samej branży uczy cię czegoś, co da się wykorzystać ponownie: promptu, który radzi sobie z żargonem, skilla, który zna przepisy, zbioru danych startowych, który wygląda jak prawdziwe rekordy, listy kontrolnej pytań, które mają znaczenie. Po pięciu zleceniach masz bibliotekę dostrojoną do jednego rodzaju klienta, a szóste zlecenie zaczyna się od tej biblioteki zamiast od pustej strony. Rosną twoje marże, rośnie jakość, a twoje oferty zaczynają brzmieć tak, jakby napisał je ktoś, kto już to robił. Bo napisał.

Wybór branży jest mniej mistyczny, niż się ludziom wydaje. Szukaj sektora, w którym już rozumiesz pracę, w którym firmy są na tyle małe, by kupować bez komisji, i w którym dokumenty, wiadomości i powtarzalne decyzje stanowią dużą część dnia. Ten ostatni test jest ważny, bo właśnie tam modele językowe zarabiają na siebie. Kancelarie prawne, biura nieruchomości, biura rachunkowe, organizacje charytatywne, przychodnie, firmy usługowo-rzemieślnicze i małe wydawnictwa – wszystkie pasują. Wybierz taką, o której zniesiesz rozmawianie przez lata.

Bogactwo kryje się w niszach, jak mówi przysłowie. Pewniej jednak kryją się tam powtarzalne zlecenia.

Obawa jest taka, że specjalizacja zawęża rynek. W praktyce dzieje się odwrotnie, bo specjalista staje się oczywistym wyborem, a oczywiste wybory dostają polecenia z wnętrza branży, gdzie ludzie nieustannie ze sobą rozmawiają. Zawsze możesz przyjąć od czasu do czasu ciekawe zlecenie spoza swojego pasa. Po prostu przestajesz tego potrzebować.

Potraktuj to jako ćwiczenie, a nie zobowiązanie. Wybierz jedną branżę i spędź godzinę z Claude’em, budując jej opis: typowa firma, jej oprogramowanie, przepisy, powracające bolączki, słownictwo. Potem zapisz trzy nazwane mikrozlecenia wyłącznie dla tej branży. Jeśli przychodzą łatwo, być może znalazłeś swój pas. Jeśli wydają się wymuszone, spróbuj innej. Nie chodzi o znalezienie idealnej niszy. Chodzi o to, by przestać być trochę przydatnym dla wszystkich.

Zamień powtarzalne w produkt

Kiedy budujesz to samo po raz trzeci, przestaje to być projektem i staje się produktem. Za pierwszym razem się uczyłeś. Za drugim – przypominałeś sobie. Za trzecim, jeśli wciąż zaczynasz od pustej strony, po prostu odmawiasz dostrzeżenia wzorca. Mikrokonsulting nagradza tych, którzy dostrzegają.

Zamiana usługi w produkt nie oznacza budowania oprogramowania. Oznacza przekształcenie powtarzanego zlecenia w powtarzalne: stały opis, standardowy zestaw danych wejściowych, szablon rezultatu, bibliotekę promptów i skilli, które wykonują większość ciężkiej pracy, oraz listę kontrolną mówiącą, co robić w każdym dniu sprintu. Klient kupuje ten sam nazwany rezultat. Ty dostarczasz go ułamkiem pierwotnego wysiłku, za tę samą cenę i w lepszej jakości, bo każde wcześniejsze zlecenie wygładziło jakąś szorstką krawędź.

To dzięki Claude’owi jest to dziś realne dla kogoś, kto pracuje w pojedynkę. W dawnym świecie zamiana usługi doradczej w produkt oznaczała zatrudnienie juniorów i napisanie podręczników procedur, które ci juniorzy by ignorowali. Teraz podręcznik procedur może być skillem, który ładuje się sam, kiedy jest potrzebny, szablony mogą powstawać z uporządkowanych danych wejściowych, a powtarzalną analizę może prowadzić agent wykonujący instrukcje, które napisałeś raz i dopracowałeś w wielu przebiegach. Innymi słowy, juniorami są narzędzia, a narzędzia naprawdę czytają podręcznik.

Sztuka polega na tym, by tworzyć produkt na podstawie dowodów, a nie nadziei. Nie wymyślaj produktu, żeby potem szukać klientów, którzy go chcą. Spójrz wstecz na to, za co klienci już zapłacili, znajdź zlecenie, które realizowałeś najczęściej, i zapisz krok po kroku, co zrobiłeś, póki masz to świeżo w pamięci. Ten zapis to pierwsza wersja produktu. Każda kolejna realizacja go dopracowuje. Po kilku przebiegach masz coś, co w zasadzie mógłbyś przekazać kompetentnemu koledze.

Proces, który potrafisz opisać, to proces, który możesz ulepszyć. Proces, który potrafisz tylko wykonać, to po prostu nawyk z fakturą.

Uważaj na jedną pułapkę. Usługi zamienione w produkt mogą zesztywnieć, a sztywne usługi zaczynają źle leżeć na klientach. Zostaw w każdym zleceniu niewielką, jawną przestrzeń na dopasowanie, na przykład dzień pracy szytej na miarę w stałych ramach, i bądź uczciwy, kiedy problem klienta nie pasuje do produktu. Zarekomendowanie czegoś innego albo zupełnie niczego buduje więcej zaufania niż wciskanie kwadratowego zlecenia w okrągłą firmę.

W tym tygodniu znajdź swoje najczęściej powtarzane zlecenie i napisz jego scenariusz: dane wejściowe, kroki, prompty, rezultaty, kontrole, przekazanie. Przechowuj prompty i szablony tam, gdzie następnym razem znajdziesz je w dziesięć sekund. Potem sprzedaj je ponownie. Czwarta realizacja będzie szybsza niż trzecia, a piąta jeszcze szybsza. Ta krzywa to cały biznesowy argument za małą pracą, po cichu wyginający się na twoją korzyść.

Od pilotażu do abonamentu

Pilotaż, który kończy się czysto i nie zostawia niczego do utrzymania, to pilotaż źle zaprojektowany. To nie cynizm wobec klientów. To uznanie faktu, że użyteczne systemy AI wymagają opieki: prompty dryfują, gdy zmienia się firma, modele się poprawiają i otwierają nowe możliwości, pojawiają się nowe przypadki brzegowe, a ktoś musi zauważyć, kiedy jakość spada. Jeśli pilotaż dowiedzie wartości, naturalnym następnym krokiem jest stała opieka. Projektuj z myślą o tym od samego początku.

Ta praca projektowa odbywa się, zanim napiszesz choćby linijkę kodu. Kiedy określasz zakres pilotażu, zapytaj, co będzie musiało się dziać, gdy się powiedzie. Kto będzie monitorował wyniki? Kto zaktualizuje prompty, kiedy zmieni się asortyment? Kto co miesiąc przejrzy zestaw ewaluacyjny i doda nowe przypadki? Kto wypróbuje ulepszony model, kiedy się pojawi? W większości małych firm uczciwa odpowiedź brzmi: nikt, a ta odpowiedź to właśnie abonament, zaproponowany otwarcie, a nie wyciągnięty jak królik z kapelusza na koniec.

Napisz o tym wprost w ofercie. Opisz pilotaż, jego definicję ukończenia i zmierzony rezultat. Potem w krótkim akapicie opisz, czego wymagałoby utrzymanie go w dobrej kondycji i co obejmowałaby comiesięczna współpraca. Nie sprzedajesz jeszcze abonamentu. Upewniasz się, że kiedy pilotaż się powiedzie, nikogo nie zaskoczy, że sukces wymaga utrzymania. Kupujący doceniają, kiedy wcześnie poznają pełny kształt zobowiązania.

Sam abonament powinien być mały i konkretny, jak wszystko inne w tej książce. Comiesięczny przegląd próbki wyników względem zestawu ewaluacyjnego. Aktualizacje promptów i skilli w razie potrzeby. Krótki pisemny raport pokazujący, co system zrobił, co się zmieniło i co rekomendujesz. Stała liczba drobnych usprawnień miesięcznie. Określony czas reakcji na problemy. Unikaj mglistego abonamentu, który obiecuje bieżące wsparcie, bo mgliste abonamenty są anulowane przy pierwszym przeglądzie budżetu, kiedy nikt już nie pamięta, po co były.

Pilotaż dowodzi, że coś działa raz. Abonament dowodzi, że działa dalej, a to właśnie tej części kupujący naprawdę potrzebował.

Nie każdy pilotaż powinien zamienić się w abonament. Niektóre systemy są na tyle proste, że dobra instrukcja obsługi i przeszkolona osoba odpowiedzialna to wszystko, czego klient potrzebuje, a zarekomendowanie tego jest uczciwe i bywa znakomite dla poleceń. Ale powinieneś zdecydować o tym świadomie, na końcu, na podstawie tego, czego potrzebuje system, a nie dryfować w to, bo nigdy nie pomyślałeś, co będzie potem.

Wypróbuj to przy następnej ofercie. Dodaj sekcję zatytułowaną po pilotażu z trzema zdaniami: czego system będzie potrzebował, kto mógłby to zapewnić i co obejmowałaby mała comiesięczna współpraca. Zauważ, jak zmienia to rozmowę. Kupujący zaczyna myśleć o pilotażu jako o początku czegoś, a nie o eksperymencie, który być może po cichu porzuci. Co w przypadku większości pilotaży AI w większości firm dzieje się w przeciwnym razie.

Drabina oferty

Złóż poprzednie rozdziały w całość, a dostaniesz drabinę. Na samym dole coś darmowego i małego: krytyczna analiza, narzędzie, przydatny artykuł, krótka rozmowa diagnostyczna. Wyżej płatny audyt, który znajduje problem. Jeszcze wyżej sprint wdrożeniowy, który go naprawia. Na szczycie miesięczny abonament, który dba, by problem pozostał naprawiony, i ulepsza rozwiązanie. Każdy klient wchodzi nisko i się wspina, a ty już nigdy nie musisz wymyślać oferty od zera.

Drabina rozwiązuje problem, o którym większość konsultantów nawet nie wie, że go ma: każda sprzedaż jest indywidualną negocjacją. Bez drabiny każdy potencjalny klient dostaje ofertę szytą na miarę, każda oferta zajmuje dzień pisania, a każda jest świeżym strzałem w ciemno, co kupujący mógłby zaakceptować. Z drabiną pytanie brzmi po prostu: od którego szczebla powinien zacząć. Kupujący, który już zna swój problem, może pominąć audyt. Ostrożny może zacząć od darmowej analizy. Struktura jest stała; punkt wejścia jest elastyczny.

Każdy szczebel powinien sprawiać, że następny wydaje się nieunikniony. Darmowa analiza kończy się pokazaniem, co znalazłby porządny audyt. Audyt kończy się uszeregowaną listą, na której szczycie stoi sprint z określonym zakresem. Sprint kończy się działającym systemem i jasnym opisem tego, czego wymaga utrzymanie go w dobrej kondycji. Nie ma w tym nic manipulacyjnego, pod warunkiem że każdy szczebel jest naprawdę wartościowy sam w sobie. Klient, który zatrzyma się na audycie, powinien wciąż czuć, że dostał to, za co zapłacił. Większość się nie zatrzyma, bo zobaczyła, jak wygląda następny krok.

Twój katalog mikrozleceń zgrabnie wpasowuje się w drabinę. Szkolenia i zestawy promptów często stoją obok audytu jako małe, mało ryzykowne pierwsze zakupy. Naprawy procesów, sprinty dokumentacyjne i pilotaże agentów to sprinty wdrożeniowe. Monitoring, przeglądy ewaluacyjne i ciągłe doskonalenie to praca abonamentowa. Przypisz każdą nazwaną ofertę do szczebla, a jednym rzutem oka zobaczysz, gdzie masz luki. Wielu konsultantów odkrywa, że ma pięć sposobów na rozpoczęcie współpracy i ani jednego na jej kontynuowanie.

Drabina to po prostu ciąg małych „tak”, ułożonych tak, by każde ułatwiało następne.

Narysuj swoją w tym tygodniu. Cztery szczeble, na każdym nazwane oferty, i jedno zdanie wyjaśniające, jak każdy szczebel prowadzi do następnego. Potem spójrz na swoich dziesięciu ostatnich klientów i zaznacz, gdzie każdy wszedł i gdzie się zatrzymał. Miejsca, w których klienci przestają się wspinać, to miejsca, gdzie twoje oferty są najsłabsze albo gdzie nie zbudowano mostu z jednego szczebla na następny. Napraw most, zanim dodasz kolejne szczeble.

To jest kształt, który wypełnia reszta książki. Części o warsztacie uczą, jak szybko dostarczać każdy szczebel z pomocą Claude’a. Części o realizacji i wycenie uczą, jak prowadzić każdy szczebel bez zgrzytów. Części o dowodach uczą, jak z każdego ukończonego szczebla zrobić powód do następnego. Drabina nie jest strategią. Jest ramą, która pozwala, by mała praca złożyła się w coś dużego.

Briefuj jak klient

Każdy konsultant wie, jak wygląda zły brief od klienta. Potrzebujemy czegoś nowoczesnego na stronę. Poznacie, jak zobaczycie. A potem większość konsultantów odwraca się i pisze dokładnie taki sam brief do modelu. Napisz mi ofertę dla tego klienta. Model, podobnie jak młodszy grafik przed nim, nie jest jasnowidzem. Wypełnia luki średnimi, a średnie to właśnie to, co dostajesz z powrotem.

Rozwiązaniem jest briefowanie Claude’a tak, jak chciałbyś, żeby klienci briefowali ciebie. Wystarczą cztery części. Kontekst: dla kogo jest ta praca, w jakiej sytuacji jest ta osoba, czego już próbowano. Zadanie: jedna rzecz, którą chcesz zrobić, wyrażona czasownikiem. Format: w jakim kształcie ma przyjść odpowiedź, od długości przez strukturę po ton. Kontrola: skąd ty i model będziecie wiedzieć, że wynik jest dobry. Tę ostatnią część pomija niemal każdy, a to właśnie ona najbardziej zmienia rezultat.

Oto różnica w praktyce. Napisz maila z podsumowaniem po rozmowie diagnostycznej to życzenie. A teraz spróbuj tak: Kontekst: prowadzę zlecenia AI o stałym zakresie dla małych biur rachunkowych. Wczoraj rozmawiałem z biurem dwóch wspólników, któremu zamknięcie miesiąca spowalniają ręczne notatki uzgodnieniowe. Zadanie: napisz maila, który podsumowuje ich problem ich własnymi słowami i proponuje płatny audyt jako pierwszy krok. Format: poniżej dwustu słów, prosta polszczyzna, bez wypunktowań, jedno jasne pytanie na końcu. Kontrola: wspólnik powinien przeczytać go w niecałą minutę i odpowiedzieć „tak” albo poprawką. Druga wersja zajmuje półtorej minuty dłużej, a daje coś, co naprawdę możesz wysłać.

Głębszym nawykiem jest biegłość: nauka zastępowania dziesięciu rund doprecyzowań jednym gęstym, jednoznacznym briefem. Na początku będziesz briefować skąpo i często poprawiać, i to jest w porządku. Z czasem zauważ, które poprawki powtarzasz, i przenieś je do briefu. Krócej, mniej formalnie, przestań używać słowa „lewarować”, dodaj następny krok. To nie są poprawki redakcyjne. To brakujące części briefu, które przychodzą spóźnione.

Brief na jeden strzał pisze się wolniej, a kończy dramatycznie szybciej.

Dla konsultantów ma to większe znaczenie niż dla większości użytkowników, bo twoje briefy często same są rezultatem. Prompt, który przekazujesz zespołowi obsługi klienta, instrukcje w skillu, prompt systemowy dla pilotażu agenta: każdy z nich to brief, na którym ktoś inny będzie polegał bez ciebie w pokoju. Jeśli nie umiesz dobrze briefować modelu we własnej pracy, nie nauczysz tego zespołu klienta, a już na pewno nie sprzedasz mu zestawu promptów.

Wypróbuj to dziś na zadaniu, które powtarzasz. Napisz czteroczęściowy brief, uruchom go i zanotuj każdą poprawkę, którą wciąż musisz wprowadzić. Wpleć każdą poprawkę z powrotem w brief i uruchom go ponownie. Kiedy pierwsza wersja wróci od razu dobra, zapisz brief tam, gdzie go znajdziesz. Właśnie stworzyłeś swoje pierwsze aktywo i zajęło ci to mniej czasu niż poprawki, które i tak miałeś zamiar nanosić.

Rola, zadanie, format

Jeśli czteroczęściowy brief wydaje się przesadą przy szybkim pytaniu, istnieje mniejszy szkielet, który sam naprawia większość złych promptów. Trzy linijki. Kto odpowiada, co ma zrobić i w jakim kształcie ma przyjść odpowiedź. Nic więcej w większości promptów nie jest nośne, a zaskakująco wiele z tego, co ludzie dodają, wręcz przeszkadza.

Rola ustala fachowość i rejestr. Jesteś konsultantem operacyjnym, który pracuje z małymi firmami logistycznymi daje ci inne słownictwo, inne założenia i inne priorytety niż jesteś pomocnym asystentem. Rola nie jest magią i nie sprawi, że model będzie wiedział rzeczy, których nie wie. Mówi mu natomiast, który z wielu możliwych sposobów odpowiedzi jest tym, którego chcesz, a to większość sukcesu.

Zadanie to czasownik. Streść, uszereguj, naszkicuj, skrytykuj, wyodrębnij, porównaj, przepisz. Najlepiej jeden czasownik na prompt, z jasno nazwanym dopełnieniem. Uszereguj te dwanaście pomysłów na usprawnienie procesów według prawdopodobnej oszczędności czasu dla pięcioosobowego biura to zadanie. Rzuć na to okiem i daj znać, co myślisz to nastrój. Kiedy prompt zawiera trzy czasowniki, model zwykle wykona pierwszy dobrze, drugi poprawnie, a trzeci pobieżnie, dokładnie w kolejności, której najmniej byś sobie życzył.

Format to kształt. Tabela z nazwanymi kolumnami. Trzy akapity. Jedno zdanie. Obiekt JSON z określonymi kluczami. Zwykły tekst bez markdownu. Nazwij go, a model przestanie improwizować. Pomiń, a dostaniesz to, co model uważa za typową odpowiedź na pytania takie jak twoje, czyli zwykle nagłówek, kilka punktorów i radosną linijkę na koniec z propozycją dalszej pomocy.

Kto, co, w jakim kształcie. Jeśli nie zapamiętasz niczego innego o promptowaniu, zapamiętaj tę kolejność.

W mikrokonsultingu ten szkielet jest też narzędziem dydaktycznym. Kiedy prowadzisz szkolenie dla zespołu klienta, to pierwsza rzecz, którą im dajesz, bo jest na tyle krótka, by ją zapamiętać, i na tyle mocna, by od razu zmienić wyniki. Ludzie, którzy miesiącami wpisywali luźne pytania do okienka czatu, są wyraźnie zaskoczeni, kiedy trzy linijki dają coś, czego naprawdę by użyli. To zaskoczenie jest na warsztacie bezcenne. To moment, w którym sceptyczny zespół dochodzi do wniosku, że może warto cię posłuchać.

Daje ci to również szybką diagnostykę cudzych promptów. Kiedy klient pokazuje ci prompt, który nie działa, sprawdź te trzy linijki. Zwykle jednej brakuje: najczęściej formatu, czasem roli, sporadycznie samego zadania, zakopanego pod akapitami tła. Przywróć brakującą linijkę, a prompt często naprawia się sam. Wyjdziesz na mądrzejszego, niż jesteś, co dla konsultanta jest wynikiem całkowicie do przyjęcia.

W tym tygodniu weź pięć promptów, których regularnie używasz, i przepisz każdy na trzy linijki. Uruchom obie wersje obok siebie. Zostaw zwycięzcę. W codziennej pracy rzadko będziesz potrzebować czegoś więcej niż ten szkielet, a kiedy będziesz, będziesz dokładnie wiedzieć, którą linijkę rozbudować.

Pokaż trzy przykłady

Styl łatwiej zademonstrować, niż opisać. Możesz spędzić cały akapit na wyjaśnianiu, że chcesz tekstu ciepłego, ale profesjonalnego, pewnego siebie, ale nie aroganckiego, zwięzłego, ale nie oschłego, i dostać coś, co nie jest żadną z tych rzeczy albo jest wszystkimi naraz w złych proporcjach. Możesz też wkleić trzy przykłady tekstów, które ci się podobają, i napisać dopasuj się do nich. Drugie podejście zwykle wygrywa i skraca pięciorundowe negocjacje do jednej.

Powód jest prosty. Przymiotniki są wieloznaczne; przykłady nie. Ciepły znaczy co innego dla ciebie, a co innego dla modelu uśredniającego wszystko, co kiedykolwiek przeczytał. Przykład niesie swój ton, długość, strukturę, słownictwo i rytm naraz, i nikt nie musi ich nazywać. Model jest bardzo dobry w dostrzeganiu wzorców w przykładach. W zamienianiu przymiotników na wzorce jest zaledwie poprawny.

Trzy to przydatna liczba. Jeden przykład zachęca do niewolniczego kopiowania: model odtwarza jego strukturę, a nawet konkretne sformułowania. Dwa pokazują wzorzec, ale mogą zostać odczytane jako para przeciwieństw. Trzy pozwalają modelowi namierzyć, co mają wspólnego, i to uogólnić. Wybieraj przykłady, które różnią się treścią, ale dzielą cechy, na których ci zależy. Trzy maile do klientów na różne tematy, wszystkie we właściwym tonie. Trzy streszczenia różnych dokumentów, wszystkie o właściwej długości i strukturze.

W tym miejscu mikrokonsulting robi się ciekawy, bo samo zbieranie przykładów jest usługą. Większość firm ma swój styl, który żyje wyłącznie w głowach ich najlepszych ludzi. Kiedy prowadzisz zlecenie na zestaw promptów albo sprint dokumentacyjny, częścią pracy jest znalezienie przykładów: oferty, która wygrała, odpowiedzi na reklamację, która odwróciła nastawienie klienta, raportu, który zarząd naprawdę przeczytał. Zebranie ich, opisanie, dlaczego każdy z nich działa, i wbudowanie ich w prompty i skille jest naprawdę cenne, a klient nie zrobiłby tego łatwo sam, bo jest zbyt blisko.

Dobry przykład to przewodnik stylu, którego nie da się źle odczytać.

Są dwa zastrzeżenia. Po pierwsze, przykłady przenoszą swoje wady równie wiernie jak zalety. Jeśli wszystkie trzy próbki zaczynają się od tego samego wyświechtanego zwrotu, tak samo zacznie się wszystko, co napisze model. Przeczytaj przykłady krytycznie, zanim ich użyjesz, i w razie potrzeby je zredaguj. Po drugie, uważaj z materiałami poufnymi. Przykłady klienta użyte w promptach tego samego klienta są w porządku, za jego zgodą. Przykłady klienta przeniesione do pracy dla innego klienta – już nie. Trzymaj biblioteki osobno.

Wypróbuj to na tekście, który często piszesz. Znajdź trzy dobre przykłady z przeszłości, wklej je z krótką instrukcją, żeby dopasować się do ich tonu, struktury i długości, i daj modelowi nowy temat. Porównaj wynik z tym, co dostajesz na podstawie samego opisu. Potem trzymaj te trzy przykłady obok promptu, w tym samym pliku, żeby następnym razem, gdy będziesz potrzebować takiego tekstu, zacząć od demonstracji, a nie od przymiotników.

Przykłady negatywne

Pokazanie modelowi, czego chcesz, ma dużą moc. Pokazanie mu, czego nie chcesz, tuż obok tego, czego chcesz, często ma jeszcze większą. Jeden zły przykład obok jednego dobrego uczy granicy za jednym podejściem, czego strona instrukcji o tonie rzadko potrafi dokonać. Kontrast robi całe tłumaczenie.

Pomyśl, jak sam nauczyłeś się dobrze pisać, jeśli się nauczyłeś. Ktoś pewnie pokazał ci niezgrabny akapit, a potem lepszą wersję tego samego akapitu, i od razu zobaczyłeś różnicę. To właśnie robi dla modelu przykład negatywny. Nie mówi jedynie unikaj żargonu; pokazuje zdanie pełne żargonu i proste zdanie mówiące to samo, a linia między nimi staje się oczywista.

Technika działa najlepiej, gdy zły przykład jest wiarygodny. Celowo okropny przykład niczego nie uczy, bo model i tak nigdy by go nie wyprodukował. Użyteczny przykład negatywny to ten, który model prawdopodobnie wyprodukuje domyślnie: przesadnie entuzjastyczny początek, asekuracyjne zakończenie, streszczenie powtarzające pytanie, mail, który trzy razy przeprasza. Zapisz wynik, który ciągle dostajesz, a którego nie chcesz, wyraźnie oznacz go jako rzecz do uniknięcia i postaw obok wersję, której chcesz.

Dla konsultantów przykłady negatywne są szczególnie przydatne w pracy regulowanej albo drażliwej. Prompt dla firmy z sektora finansowego może pokazać przykład odpowiedzi, która zapuszcza się w doradztwo indywidualne, i przykład, który bezpiecznie pozostaje po właściwej stronie granicy. Prompt do komunikacji organizacji charytatywnej z darczyńcami może pokazać przykład, który wzbudza poczucie winy, i taki, który brzmi wdzięcznie. Te pary niosą jednocześnie zgodność z przepisami i ton, a klientom znacznie łatwiej je przejrzeć i zatwierdzić niż abstrakcyjne reguły.

Jeden zły przykład, uczciwie podpisany, jest wart strony instrukcji pisanych z nadzieją.

Jest pewna subtelność. Nie pozwól, żeby przykłady negatywne zdominowały prompt. Przy zbyt wielu model zaczyna orientować się na to, czego unikać, a nie na to, co wytworzyć, przez co wyniki potrafią być sztywne i lękliwe. Jeden czy dwa wyraźne kontrasty zwykle wystarczą. Jeśli przyłapiesz się na wypisywaniu dziesięciu rzeczy, których nie należy robić, pozytywny brief jest pewnie zbyt cienki. Wzmocnij raczej jego.

To także świetne ćwiczenie na szkolenie. Poproś zespół klienta, żeby przyniósł wynik, który mu się nie spodobał. Wspólnie napiszcie obok krótką dobrą wersję, potem dodajcie obie do promptu jako podpisaną parę i uruchomcie ponownie. Poprawa jest zwykle natychmiastowa, a zespół uczy się z tych dziesięciu minut więcej niż z godziny slajdów o inżynierii promptów.

Wypróbuj to w tym tygodniu na swoim najbardziej upartym prompcie, tym, który ciągle daje coś odrobinę nie tak. Wklej ten nietrafiony wynik, podpisz go nie tak, napisz wersję, której chciałeś, podpisz ją tak i uruchom ponownie. Granice łatwiej szanować, kiedy ktoś je narysował. Modele nie są tu wyjątkiem.

Ogranicz wynik

Model bez ograniczeń pisze wypracowanie. Model z ograniczeniami pisze coś, czego można użyć. W pracy konsultanta ta różnica ma ogromne znaczenie, bo tak wiele z tego, co budujesz, polega na tym, że wynik modelu trafia gdzieś indziej niż przed ludzkie oczy: do arkusza kalkulacyjnego, systemu zgłoszeń, bazy danych, następnego kroku zautomatyzowanego procesu. Wypracowania nie mieszczą się w komórkach arkusza. Wyniki ustrukturyzowane – tak.

Ograniczanie zaczyna się od precyzyjnego nazwania formatu. Nie daj mi listę, tylko zwróć tabelę z kolumnami: zadanie, właściciel, częstotliwość i szacowana liczba minut tygodniowo. Nie streść jako JSON, tylko zwróć obiekt JSON z kluczami category, urgency i suggested_reply, gdzie urgency przyjmuje jedną z wartości low, medium lub high. Im precyzyjniej nazwiesz kształt, tym mniej model musi zgadywać, a im mniej zgaduje, tym pewniej działają kolejne kroki.

Ograniczanie oznacza też zawężenie tego, co dozwolone wewnątrz kształtu. Określ dopuszczalne wartości kategorii. Ustal maksymalne długości. Powiedz, co robić, gdy brakuje informacji: zwrócić null, zwrócić słowo unknown albo pominąć pole. Modele bardzo chcą się przypodobać, a przymilny model poproszony o wypełnienie pola, o którym nie ma żadnych informacji, czasem wymyśli coś wiarygodnie brzmiącego. Wyraźne powiedzenie mu, jak ma zasygnalizować nie wiem, to jedna z najcenniejszych linijek, jakie możesz dodać do produkcyjnego promptu.

Przy wszystkim, co zasila oprogramowanie, idź dalej. Tam, gdzie platforma, na której budujesz, obsługuje ustrukturyzowane wyniki albo definicje narzędzi ze schematem, korzystaj z nich, bo schemat wymuszany przez system jest silniejszy niż opisany prozą. A potem i tak waliduj to, co wraca. Mały skrypt, który sprawdza, czy wynik ma oczekiwany kształt, i ponawia próbę albo zgłasza problem, kiedy go nie ma, uchroni cię przed tą jedną na sto zniekształconą odpowiedzią, która w przeciwnym razie zepsułaby klientowi proces w najmniej dogodnym momencie.

Proza jest dla ludzi. Struktura jest dla potoków danych. Wiedz, dla kogo piszesz.

To zawias między promptem, który robi wrażenie na demonstracji, a systemem, który przetrwa na produkcji. Wiele pierwszych pilotaży AI upada nie dlatego, że osąd modelu był słaby, lecz dlatego, że jego wyniki miały niespójny kształt. Pewnego dnia pole przyszło pod inną nazwą. Kategoria była inaczej zapisana. Streszczenie rozrosło się do trzech akapitów, choć interfejs miał miejsce na jedną linijkę. Żaden z tych problemów nie dotyczy inteligencji. To problemy z ograniczeniami i da się im całkowicie zapobiec.

W tym tygodniu przyjrzyj się jednemu procesowi, który budujesz albo planujesz, i zapytaj, dokąd płynie dalej wynik modelu. Dla każdego kroku zapisz dokładny kształt, jakiego potrzebuje następny krok, a potem wpisz ten kształt, z dopuszczalnymi wartościami i zasadami dotyczącymi brakujących danych, do promptu. Dodaj walidację. To mało efektowna praca. Ale to dzięki niej twoje systemy działają dalej, kiedy już przestaniesz ich pilnować, a tylko za takie klient powinien płacić.

Niech najpierw pomyśli

Przy trudnych problemach jakość bierze się z pętli, nie z pierwszej próby. Poproś model o odpowiedź od razu, a dostaniesz jego pierwszą myśl, podaną z pewnością siebie. Poproś, by najpierw przemyślał problem, potem naszkicował odpowiedź, a następnie skrytykował szkic w świetle pierwotnego celu i go poprawił, a zwykle dostaniesz coś wyraźnie lepszego. Pętla kosztuje cię linijkę czy dwie w prompcie. Często oszczędza godzinę poprawek.

Nowoczesne modele Claude potrafią rozumować przed odpowiedzią same z siebie, a kiedy dostępne jest rozszerzone myślenie, warto z niego korzystać przy naprawdę trudnych zadaniach. Ale pętlę możesz też ukształtować jawnie, a w pracy konsultanta często powinieneś, bo chcesz, żeby rozumowanie było widoczne. Zanim zarekomendujesz, który proces zautomatyzować najpierw, wypisz czynniki istotne dla tego klienta, oceń względem nich każdego kandydata, a potem podaj rekomendację i największe pojedyncze ryzyko z nią związane. Taki prompt daje rekomendację i stojące za nią rozumowanie, czyli dokładnie to, czego klient potrzebuje, by podjąć decyzję.

Krok krytyki to ten, który ludzie pomijają. Po szkicu poproś model, żeby przejrzał go pod kątem briefu: czy odpowiada na zadane pytanie, czy pasuje do formatu, czy zawiera twierdzenia, których nie da się poprzeć, co zarzuciłby mu sceptyczny czytelnik. Potem poproś o poprawioną wersję. Zdziwisz się, jak często krytyka wyłapuje coś prawdziwego: pominięte ograniczenie, założenie podane jako fakt, rekomendację sprzeczną z czymś w materiale źródłowym.

Ten wzorzec jest szczególnie przydatny, gdy stawka jest wyższa niż przy szybkim szkicu. Rekomendacja z audytu, na podstawie której klient będzie działał. Streszczenie klauzuli umowy. Uszeregowana lista opcji, przy której wybór wiąże się z pieniędzmi. W każdym z tych przypadków dodatkowa pętla to tanie ubezpieczenie. Nie zastępuje twojej weryfikacji, ale oznacza, że wersja, którą weryfikujesz, przetrwała już jedną rundę krytyki, więc twoja uwaga idzie na subtelne problemy, a nie na oczywiste.

Pierwsza odpowiedź to szkic. Modele o tym wiedzą. Dobrze, jeśli ty też wiesz.

Nie nadużywaj tego. Prośba o przeformatowanie tabeli nie potrzebuje fazy rozumowania, a domaganie się jej sprawia jedynie, że odpowiedź jest wolniejsza i dłuższa. Pełną pętlę zachowaj na zadania, przy których błędna odpowiedź by coś kosztowała albo w których właściwa odpowiedź zależy od wyważenia kilku czynników. Przy prostych przekształceniach wystarczy jasna instrukcja i ograniczony format.

W systemie klienta tę pętlę można wbudować jako osobne kroki zamiast jednego długiego promptu: jedno wywołanie rozumuje i szkicuje, drugie krytykuje według kryteriów oceny, trzecie poprawia. Dzięki temu każdy krok łatwiej przetestować i ulepszać niezależnie, a ty masz gdzie umieścić ludzki punkt kontrolny, jeśli praca go wymaga. W tym tygodniu wybierz jedno zadanie o charakterze decyzji, które przekazujesz Claude’owi, i dodaj pętlę jawnie. Porównaj przed i po. Myślenie najpierw nie jest wolniejsze. Po prostu przenosi powolność tam, gdzie jej miejsce.

Poproś o kryteria oceny

Oto ruch, który wydaje się nieco odwrócony, a działa zadziwiająco dobrze. Zanim model odpowie, poproś go, żeby napisał klucz oceniania. Co zawierałaby znakomita odpowiedź na to zadanie? W czym pomyliłaby się słaba? Potem pozwól mu odpowiedzieć, ocenić własną odpowiedź według tych kryteriów i przepisywać ją, aż zdobyłaby komplet punktów. Model staje się własnym egzaminatorem, z kryteriami spisanymi przed egzaminem, a nie po nim.

Dlaczego to pomaga? Bo spisanie kryteriów zmusza model do ujawnienia ukrytych wymagań zadania. Prośba o napisanie raportu postępów dla klienta ma niewypowiedziane kryteria: powinien zaczynać się od tego, co się zmieniło, liczbowo określać postęp, uczciwie sygnalizować ryzyka, prosić o wszelkie potrzebne decyzje i pozostać krótki. Model w pewnym sensie to wszystko wie, ale niekoniecznie stosuje wszystko za jednym podejściem. Spisanie kryteriów wydobywa je na powierzchnię; ocena według nich – stosuje je.

Kryteria możesz też napisać sam albo, jeszcze lepiej, razem z klientem. W tym miejscu technika staje się narzędziem konsultingowym. Przy pilotażu agenta albo zleceniu na zestaw promptów usiądź z osobą, która będzie oceniać wyniki, i zapytaj, co sprawia, że wynik jest dobry. Zapisz jej odpowiedzi jako kryteria oceny, jej słowami. Potem wbuduj te kryteria w prompt i w proces ewaluacji. Nagle milczące standardy klienta stają się jawne, model jest z nich rozliczany, a testy odbiorcze mają podstawę, na którą wszyscy zgodzili się z góry.

Kryteria sprawiają też, że postęp da się zmierzyć. Jeśli uruchomisz dwadzieścia przypadków testowych i każdy ocenisz według tych samych pięciu kryteriów, zobaczysz dokładnie, gdzie system jest słaby. Może zawsze określa postęp liczbowo, ale rzadko sygnalizuje ryzyka. To mówi ci, którą część promptu wzmocnić. Bez kryteriów zostaje ci ogólne wrażenie, że wyniki są w większości w porządku, a to odczucie, nie ustalenie.

Jeśli nie potrafisz zapisać, jak wygląda dobrze, ani ty, ani model nie będziecie tego niezawodnie wytwarzać.

Ostrzeżenie: modele oceniające własną pracę bywają hojne. Samoocena to przydatny krok, a nie ostateczny werdykt. Przy wszystkim, co ważne, niech pracę oceni osobny przebieg, najlepiej w świeżym kontekście, bez przywiązania do szkicu, a człowiek niech zagląda do próbki. Kryteria sprawiają, że obie te weryfikacje są szybsze i uczciwsze, ale ich nie zastępują.

Wypróbuj to w tym tygodniu na powtarzalnym tekście. Poproś Claude’a o napisanie pięciopunktowych kryteriów znakomitej wersji, redaguj je, aż się z nimi zgodzisz, a potem niech model naszkicuje tekst, oceni go i poprawi według nich. Zapisz kryteria obok promptu. Przekonasz się, że używasz ich częściej niż samego promptu, bo dobra definicja jakości przeżywa każdy konkretny sposób proszenia o nią.

Zacznij odpowiedź za model

Rozpoczęcie odpowiedzi za model steruje jej formatem mocniej niż niemal każda instrukcja. Napisz sam początek odpowiedzi – pierwszy nawias obiektu JSON, pierwszy nagłówek raportu, pierwszą komórkę tabeli – a model będzie kontynuował w tym kształcie. To mały ruch o dużym efekcie i jedna z najstarszych sztuczek w pracy z modelami językowymi.

Zasada jest taka, że modele kontynuują wzorce. Instrukcja jest prośbą; rozpoczęta odpowiedź to wzorzec, który już jest w ruchu. Jeśli odpowiedź zaczyna się od otwierającego nawiasu klamrowego, model jest mocno skłonny dokończyć JSON, zamiast poprzedzać go uprzejmym zdaniem o tym, co zaraz zrobi. Jeśli odpowiedź zaczyna się od konkretnego nagłówka, model kontynuuje treścią pod tym nagłówkiem, zamiast wymyślać własną strukturę.

Sposób użycia zależy od tego, gdzie pracujesz. Kiedy budujesz na API, w wielu konfiguracjach możesz bezpośrednio podać początek wypowiedzi asystenta, co czyni wstępne wypełnienie precyzyjnym. W interfejsie czatu przybliżasz to, pokazując pożądany początek: zacznij odpowiedź od linijki Podsumowanie dla wspólników: i kontynuuj od tego miejsca. W szablonie albo skillu możesz zawrzeć szkielet wyniku z częściowo wypełnioną pierwszą sekcją i poprosić model o dokończenie. Wszystkie trzy podejścia popychają tę samą skłonność.

Wstępne wypełnienie jest szczególnie przydatne do usuwania wstępów, które wkradają się do wyników modelu. Znasz ten rodzaj: Oczywiście! Oto streszczenie dokumentu, który przesłałeś. Nieszkodliwe na czacie, irytujące w materiale dla klienta i po prostu psujące wszystko, gdy wynik zasila system oczekujący danych. Rozpoczęcie odpowiedzi usuwa miejsce, w którym znalazłby się wstęp. W połączeniu z jasnym ograniczeniem formatu zwykle wystarcza, by za każdym razem dostać czysty wynik.

Jeśli chcesz, żeby odpowiedź zaczynała się w konkretnym miejscu, zacznij ją tam sam.

Jest w tym pewna delikatna sztuka. Wypełnij za dużo, a ograniczysz nie tylko formę, ale i treść, czasem w niezamierzony sposób. Wypełniaj tylko strukturalny początek – nawias, nagłówek albo pierwszą etykietę – a treść zostaw modelowi. Zauważ też, że niektóre funkcje i konfiguracje ograniczają lub zmieniają działanie wstępnego wypełniania, więc jeśli technika, która działała w jednym miejscu, w innym zachowuje się inaczej, sprawdź aktualną dokumentację, zamiast zakładać, że model zrobił się uparty.

Dla konsultantów szablony z rozpoczętą odpowiedzią są świetnym rezultatem samym w sobie. Zespół klienta może otworzyć zapisany prompt, który zawiera już szkielet potrzebnego raportu, uzupełnić szczegóły i za każdym razem dostać spójny dokument. Tę spójność klient często ceni bardziej niż jakąkolwiek błyskotliwość samego promptu.

W tym tygodniu weź jeden wynik, którego format ciągle się rozjeżdża, i sam zacznij odpowiedź. Zauważ, jak duża część twojej wcześniejszej instrukcji staje się zbędna. Czasem najkrótszym sposobem, by powiedzieć, czego chcesz, jest po prostu to zacząć.

Prompty to aktywa

Prompt, którego używasz dwadzieścia razy, to nie wiadomość. To infrastruktura. Zasługuje na nazwę, wersję, miejsce i notkę wyjaśniającą, do czego służy i skąd wiesz, że działa. Większość ludzi traktuje swoje najlepsze prompty tak, jak błyskotliwe uwagi rzucone na przyjęciu: wypowiedziane raz, mgliście zapamiętane, niemożliwe do odtworzenia. Dla konsultanta to pieniądze zostawione na stole, raz za razem.

Zacznij od nadawania nazw. Podsumowanie rozmowy diagnostycznej, ocena szans z audytu, autor instrukcji obsługi, pierwsza wersja studium przypadku. Nazwa pozwala znaleźć prompt, odwołać się do niego i zauważyć, że masz dwa robiące to samo. Potem daj każdemu miejsce: folder w repozytorium, sekcję w aplikacji do notatek, projekt w Claude, gdzie leży jako materiał referencyjny. Test polega na tym, czy potrafisz znaleźć właściwy prompt w mniej niż dziesięć sekund, kiedy go potrzebujesz. Jeśli nie, to tak naprawdę on nie istnieje.

Wersjonowanie ma większe znaczenie, niż się wydaje. Prompty doskonalą się przez używanie. Poprawiasz linijkę po złym wyniku, dodajesz przykład po skardze klienta, zaostrzasz ograniczenie po awarii w dalszym kroku. Bez wersji nie wiesz, która zmiana pomogła, i nie możesz wycofać tej, która pogorszyła sprawę. Zwykłe pliki tekstowe w gicie są w zupełności wystarczające. Podobnie prosty dziennik zmian na dole każdego promptu, z datą i powodem każdej zmiany.

Testowanie zamienia dobry prompt w niezawodny. Trzymaj obok każdego ważnego promptu garść danych testowych, w tym przynajmniej jeden kłopotliwy przypadek, i uruchamiaj je ponownie przy każdej zmianie promptu albo gdy pojawi się nowy model. Na początek nie potrzebujesz rozbudowanych narzędzi. Krótki skrypt albo nawet staranne ręczne sprawdzenie na tych samych pięciu danych wejściowych wyłapie większość regresji, zanim zrobi to klient.

Sprytny prompt to chwila. Przetestowany prompt z wersją to narzędzie. Tylko jedno z nich procentuje.

Kiedy twoje prompty stają się aktywami, zaczynasz inaczej widzieć swoją praktykę. Twoja biblioteka to różnica między twoim pierwszym zleceniem w branży a dziesiątym. To dzięki niej dwutygodniowy sprint dostarcza to, co kiedyś zajmowało miesiąc. To także, coraz częściej, coś, co możesz przekazać: własna biblioteka klienta, zbudowana podczas twojego zlecenia, udokumentowana i przetestowana, staje się częścią tego, co kupił. Następna część tej książki idzie dalej i zamienia najlepsze z tych aktywów w skille, które ładują się same.

W tym tygodniu zbierz prompty, których użyłeś więcej niż trzy razy. Nadaj każdemu nazwę, miejsce, numer wersji i kilka danych testowych. Zajmie to popołudnie. To popołudnie zwróci się w ciągu miesiąca i po cichu zmieni twoje myślenie o wszystkim, co piszesz dla modelu. Każdy dobry prompt, który od teraz napiszesz, jest albo aktywem, albo zmarnowanym dobrym promptem.

Sprzedaj zestaw promptów

Wszystko z tej części można zapakować i sprzedać. Zestaw promptów to jedno z najprostszych mikrozleceń, jakie istnieją: projekt o stałym zakresie, którego celem jest dać zespołowi przetestowany zestaw promptów do zadań wykonywanych codziennie. Łatwo go wyjaśnić, szybko dostarczyć, jest mało ryzykowny dla kupującego i widocznie przydatny od pierwszego poranka. To także świetny pierwszy szczebel dla klientów, którzy są ciekawi AI, ale nie są jeszcze gotowi na audyt ani pilotaż.

Kształt jest prosty. Zacznij od krótkiego warsztatu albo kilku rozmów, by spisać powtarzalne zadania zespołu, które wymagają czytania, pisania albo decydowania. Wybierz dziesięć najczęstszych i najbardziej uciążliwych. Dla każdego zbierz prawdziwe przykłady, dobre i złe, i napisz prompt, wykorzystując wszystko z tej części: porządny brief, jasną rolę, ograniczony format, gotowe przykłady, przykład negatywny tam, gdzie pomaga, kryteria jakości. Przetestuj każdy prompt na prawdziwych danych z ludźmi, którzy będą go używać. Potem przekaż zestaw z krótkim przewodnikiem i sesją, na której pokażesz zespołowi, jak z niego korzystać.

O wartości nie decydują same prompty. Decyduje to, że są dostrojone do pracy tego zespołu, w głosie tego zespołu, z przykładami tego zespołu i przetestowane na prawdziwych danych tego zespołu. Ogólna lista promptów jest w internecie za darmo i mniej więcej tyle jest warta. Zestaw, który za pierwszym podejściem tworzy ich format oferty, ich odpowiedzi na reklamacje i ich cotygodniowy raport, jest wart bardzo dużo, bo oszczędza czas każdego dnia od chwili, gdy trafi do zespołu.

Gdzie zestaw będzie mieszkał, zależy od klienta. W zespole korzystającym z Claude’a prompty mogą leżeć we wspólnym projekcie jako materiał referencyjny, obok przykładów i krótkiego przewodnika. W zespołach bardziej zaawansowanych najlepsze prompty mogą stać się skillami, które ładują się, gdy są potrzebne, zamiast być kopiowane i wklejane. Tak czy inaczej, udokumentuj każdy prompt: jego cel, przykładowe dane wejściowe i wynik oraz nazwisko osoby, która odpowiada za niego w firmie.

Zestaw promptów to najmniejsza rzecz, jaką możesz sprzedać, a której zespół będzie używał codziennie.

Jasno określ zakres. Dziesięć promptów, nie pięćdziesiąt. Jeden zespół, nie cała firma. Testy na prawdziwych danych, nie na hipotetycznych. Stała data przekazania. Kiedy klient poprosi o prompty dla kolejnego działu, a poprosi, jeśli pierwszy zestaw będzie dobry, to jest następne zlecenie. Zapisz to i zaproponuj przy przekazaniu.

Zestaw wykonuje też cichą pracę na rzecz twojego lejka. Dostarcza mierzalnych przykładów „przed” i „po”, tworzy wewnętrznego orędownika, który używa go codziennie, i wydobywa na wierzch większe problemy z procesami, których sam prompt nie naprawi – a to dokładnie te problemy, którymi zajmuje się twój następny szczebel. W tym tygodniu naszkicuj zestaw promptów dla znanego ci zespołu: dziesięć zadań i jeden przetestowany prompt do pierwszego z nich. Jeśli ten pierwszy prompt oszczędza jednej osobie dwadzieścia minut dziennie, masz już studium przypadku.

Kontekst jest produktem

Jakość modelu, przy dowolnym zadaniu, jest mniej więcej stała. To, czym go karmisz – już nie. Większość różnicy między przeciętną odpowiedzią a znakomitą powstaje, zanim prompt zostanie wysłany: które dokumenty model widzi, jakie ma przykłady, co wie o kliencie, jakie decyzje już zapadły, do jakiego celu zmierza. Uwagę przyciąga warsztat promptowania. Większość roboty wykonuje kontekst.

To dobra wiadomość dla konsultantów, bo to w kontekście mieszka twoja wartość. Każdy może otworzyć Claude’a i zadać pytanie. Bardzo niewielu potrafi zebrać właściwy kontekst dla konkretnego problemu biznesowego: odpowiednie strony regulaminu, trzy maile, które pokazują prawdziwy problem, arkusz z rzeczywistymi liczbami, notatkę wyjaśniającą, dlaczego poprzednia próba się nie udała. Wiedza o tym, co zebrać, a co pominąć, to fachowość. To za tę fachowość płacą klienci, kiedy zatrudniają ciebie, zamiast po prostu kupić subskrypcję.

Myśl o kontekście warstwami. Na dole trwała wiedza, która rzadko się zmienia: kim jest klient, jego branża, styl, ograniczenia. Nad nią wiedza projektowa: cel tego zlecenia, dotychczasowe decyzje, definicja ukończenia. Wyżej kontekst zadania: konkretne dokumenty i przykłady związane z pytaniem, przed którym stoisz. A na samej górze – sama instrukcja. Każdą warstwę trzeba dobierać osobno, bo każda zmienia się w innym tempie i w inny sposób się starzeje.

Narzędzia wyrosły wokół tej idei. Projekty w Claude pozwalają przypiąć materiały referencyjne widoczne w każdej rozmowie. Claude Code na początku każdej sesji czyta pliki pamięci z repozytorium. Skille ładują szczegółowe instrukcje dopiero wtedy, gdy są potrzebne. Konektory pozwalają modelowi pobierać aktualne informacje z systemów klienta, zamiast polegać na tym, co wkleiłeś w zeszłym tygodniu. Każde z tych rozwiązań to w gruncie rzeczy sposób na podsunięcie modelowi właściwego kontekstu we właściwym momencie bez twojej ręcznej pracy.

Śmieci na wejściu, śmieci na wyjściu – to zawsze była prawda. Nowa reguła brzmi: starannie dobrane na wejściu, zaskakująco dobre na wyjściu.

Praktyczna zmiana polega na tym, by traktować składanie kontekstu jako osobny krok, a nie dodatek na doczepkę. Zanim zadasz trudne pytanie, zapytaj siebie, co znakomity ludzki ekspert chciałby najpierw przeczytać. Potem zbierz dokładnie to, ani mniej, ani więcej, i umieść tam, gdzie model to zobaczy. Kolejne rozdziały opisują, jak to robić: wklejać oryginał, dobrze go układać, utrzymywać kontekst szczupłym, usuwać to, co nieaktualne, i porządkować to, co zostaje.

W tym tygodniu wybierz zadanie, przy którym odpowiedzi Claude’a cię rozczarowywały. Zanim przepiszesz prompt, przepisz kontekst. Dodaj dokument, który dotąd streszczałeś z pamięci. Usuń trzy, które nie mają związku. Dodaj krótką notkę o decyzji, która już zapadła. Potem zadaj to samo pytanie jeszcze raz. Często okaże się, że prompt był w porządku od samego początku. Po prostu kazano mu odpowiadać na pytanie o pokój, którego nie widział.

Wklej oryginał

Streszczenia gubią dokładnie te szczegóły, które miały znaczenie. Kiedy opisujesz komunikat o błędzie z pamięci, pomijasz numer linii. Kiedy parafrazujesz klauzulę umowy, gubisz zastrzeżenie, które zmienia jej sens. Kiedy streszczasz skargę klienta, wygładzasz ton, który mówi ci, jak bardzo jest zły. Potem prosisz model o pomoc, a on pomaga z twoim streszczeniem, czyli z problemem nieco innym niż prawdziwy.

Rozwiązanie jest niemal wstydliwie proste: wklej oryginał. Prawdziwy błąd, w całości. Prawdziwą klauzulę, z numeracją. Prawdziwego maila, z literówkami. Prawdziwy eksport arkusza, a nie twój opis tego, co w nim jest. Modele bardzo dobrze czytają surowy materiał, często lepiej niż ludzie, bo nie nudzą się w połowie i nie czytają po łebkach. Daj im źródło, a zwykle znajdą to, co ty byś przeoczył.

W konsultingu ma to podwójne znaczenie, bo często pracujesz o krok od samego problemu. Klient mówi ci, że jego proces fakturowania jest powolny. Jeśli zapytasz Claude’a, jak przyspieszyć fakturowanie, dostaniesz ogólne rady. Jeśli wkleisz zanonimizowany eksport faktur z zeszłego miesiąca, wątek mailowy, w którym klient zakwestionował jedną z nich, i wewnętrzną listę kontrolną, której trzyma się dział księgowości, dostaniesz konkretne obserwacje: te same trzy pola są wpisywane ręcznie po kilka razy, spory skupiają się wokół jednej linii produktów, a lista kontrolna ma krok, którego nikt nie wykonuje. To jest różnica między konsultantem a wyszukiwarką.

Są granice i są one ważne. Prawdziwe materiały często zawierają dane osobowe i poufne. Zanim wkleisz cokolwiek od klienta, sprawdź, na co pozwala twoja umowa, czego wymagają jego zasady i co mówią przepisy o ochronie danych w twojej jurysdykcji. Anonimizuj, gdzie się da, usuwaj to, czego nie potrzebujesz, i korzystaj z narzędzi oraz planów, których sposób przetwarzania danych klient zatwierdził. Wklejanie oryginału to dobra praktyka. Wklejanie czyjejś listy klientów do narzędzia, którego nie zaakceptował, już nie.

Parafraza to kopia stratna. Model zasługuje na oryginał, i twój klient też.

Jest też sztuka wyboru, który oryginał wkleić. Wklejanie wszystkiego to osobny rodzaj porażki, o czym przekonuje rozdział o budżecie kontekstu. Umiejętność polega na znalezieniu konkretnego materiału źródłowego, w którym siedzi problem: przypadku, który zawodzi, a nie wszystkich przypadków; spornej faktury, a nie całej księgi; akapitu regulaminu, który ma zastosowanie, a nie całego podręcznika. Prawdziwe i istotne, w tej kolejności.

Spróbuj tego następnym razem, gdy utkniesz. Zauważ moment, w którym zaczynasz pisać opis czegoś, co mógłbyś po prostu wkleić. Zatrzymaj się, znajdź oryginał, wyczyść go ze wszystkiego, co nie powinno opuścić klienta, i wklej. Potem zadaj pytanie. Oszczędzisz sobie rundy, w której model prosi o więcej szczegółów, i unikniesz subtelniejszej porażki, w której w ogóle nie pyta, tylko z pewnością siebie rozwiązuje niewłaściwy problem.

Kolejność ma znaczenie

To, gdzie umieszczasz rzeczy w prompcie, wpływa na to, jak dobrze model z nich korzysta. Ogólna zasada, która w praktyce dobrze się sprawdza, jest prosta: długie dokumenty na początku, pytanie na końcu. Materiał na górze, instrukcje i właściwe pytanie na dole, żeby instrukcja była świeża, gdy model zaczyna odpowiadać, a nie zakopana pod dziesięcioma tysiącami słów tekstu źródłowego.

Intuicja jest łatwa do uchwycenia. Wyobraź sobie, że wręczasz koledze gruby raport z karteczką na okładce: sprawdź, proszę, warunki płatności, a potem wyobraź sobie, że wręczasz mu ten sam raport z karteczką na ostatniej stronie. W pierwszym przypadku, zanim dotrze do strony czterdziestej, może już nie pamiętać, czego dokładnie szukał. W drugim pytanie pojawia się w chwili, gdy jest gotów na nie odpowiedzieć. Modele to nie ludzie, ale długie prompty zachowują się podobnie na tyle często, że warto to uwzględnić w planach.

Dobra domyślna struktura dla obszernego promptu wygląda tak. Najpierw dokumenty referencyjne, każdy wyraźnie podpisany. Potem przykłady pożądanego wyniku. Potem krótka informacja, dla kogo jest ta praca i po co. Potem konkretne zadanie, format i kryterium sukcesu. Na koniec, jeśli to pomaga, jednozdaniowe powtórzenie najważniejszego ograniczenia. Taka struktura czyta się naturalnie i trzyma instrukcję blisko odpowiedzi.

W obrębie dokumentów kolejność też ma znaczenie. Umieść najistotniejszy materiał tam, gdzie model najprawdopodobniej nada mu największą wagę, i podpisz każdy fragment: czym jest i dlaczego się tu znalazł. Poniżej obecny regulamin zwrotów klienta, z którym nowy proces musi być zgodny jest znacznie bardziej użyteczne niż niepodpisany blok tekstu. Podpisy mówią modelowi, jak użyć każdego dokumentu, a nie tylko, że on istnieje.

Najpierw materiał, pytanie na końcu. Model z największą starannością odpowiada na to, co przeczytał najświeżej.

Dla konsultantów, którzy budują systemy, a nie jednorazowe prompty, kolejność staje się decyzją projektową. Kiedy składasz prompt programowo, wciągając rekord klienta, odpowiedni regulamin, kilka dawnych przykładów i przychodzącą wiadomość, ustal kolejność świadomie i trzymaj się jej. Niespójna kolejność to cichy powód niespójnych wyników i jedna z pierwszych rzeczy do sprawdzenia, gdy system, który działał w testach, zaczyna dziwnie się zachowywać na produkcji. Spójna struktura pomaga też w buforowaniu promptów tam, gdzie platforma to obsługuje, bo stały materiał na początku można ponownie wykorzystywać między wywołaniami.

To także przydatna uwaga na szkolenia, bo tak łatwo ją zastosować. Większość ludzi wkleja najpierw pytanie, a potem materiał, bo tak właśnie myślą o problemie. Pokazanie zespołowi tego samego promptu w obu kolejnościach, z wyraźnie różnymi wynikami na długim dokumencie, zamienia zasadę w nawyk szybciej niż jakiekolwiek wyjaśnienia.

W tym tygodniu weź swój najdłuższy regularnie używany prompt i przestaw go: podpisane dokumenty na górze, przykłady dalej, instrukcja i pytanie na dole. Uruchom go na tych samych danych co wcześniej. Jeśli odpowiedź się poprawi, zostaw tę kolejność. Jeśli nie, straciłeś tylko minutę, a dowiedziałeś się czegoś o tym konkretnym zadaniu.

Budżet kontekstu

Okna kontekstu są dziś duże, na tyle duże, że mieszczą całe książki i spore bazy kodu. Ten rozmiar zachęca do złego nawyku: wrzucania wszystkiego, bo można. Każdy nieistotny dokument w kontekście to rozproszenie, które model musi omijać. Może nie zawieść całkowicie, ale odpowiedź staje się bardziej mglista, uwaga się rozmywa, a szczegóły, na których ci zależało, dostają jej mniej. Trzy właściwe pliki wygrywają z trzydziestoma, a odpowiedź zwykle się wyostrza, gdy stos maleje.

Myśl o kontekście jak o budżecie, a nie pojemniku. Pojemnik pomieści bardzo dużo. Budżet to ilość uwagi, jaką chcesz, by model poświęcił każdej rzeczy. Wydawaj go na materiał, który bezpośrednio dotyczy pytania. Pomiń materiał jedynie powiązany, tło dorzucone na wszelki wypadek, stare wersje, notatki ze spotkań w innym projekcie. Jeśli nie dałbyś tego bystremu ludzkiemu ekspertowi przy tym pytaniu, nie dawaj tego modelowi.

Dobór to umiejętność i jedna z najcenniejszych rzeczy, które wnosi konsultant. Klient, który dał ci dostęp do wspólnego dysku, dał ci tysiące dokumentów. Wartość, którą dodajesz, to wiedza, które sześć z nich ma znaczenie przy tym problemie. Z Claude’em możesz zrobić to w dwóch krokach: najpierw poproś model, żeby przeczytał szerszy zbiór i wskazał dokumenty istotne dla pytania, z jednym zdaniem uzasadnienia; potem zacznij świeżą rozmowę tylko z tymi dokumentami i zadaj właściwe pytanie. Pierwszy krok to selekcja. Drugi to praca.

Idea budżetu dotyczy też długotrwałej pracy. W Claude Code kontekst zapełnia się w miarę trwania sesji: przeczytanymi plikami, uruchomionymi poleceniami, wygenerowanym wyjściem. Pomagają tu subagenty, bo mogą wykonać pracę eksploracyjną we własnym kontekście i zwrócić tylko podsumowanie. Pomaga też kompaktowanie albo zaczynanie świeżych sesji. Zasada jest wszędzie ta sama: główny wątek powinien nieść to, czego potrzebuje bieżące zadanie, a szum powinien być gdzie indziej.

Model może przeczytać wszystko. To nie znaczy, że powinien.

Czynnikiem jest też koszt, choć rzadko najważniejszym. Większe konteksty dłużej się przetwarza i drożej uruchamia, a w systemie produkcyjnym wywoływanym wiele razy dziennie te różnice się sumują. Szczupły, starannie dobrany kontekst jest szybszy, tańszy i zwykle lepszy. To rzadka zbieżność interesów i warto ją wykorzystać, projektując system dla klienta.

Wypróbuj to przy następnym zadaniu o charakterze badawczym. Zanim zadasz pytanie, wypisz wszystkie dokumenty, które zamierzałeś dołączyć, i oznacz każdy jako niezbędny, przydatny albo na wszelki wypadek. Dołącz tylko niezbędne, a przydatne – jeśli masz konkretny powód. Uruchom i porównaj z wersją „wszystko”. Większość ludzi odkrywa, że wersja szczupła odpowiada precyzyjniej. Uczy też czegoś niewygodnego: jak duża część twojego zwykłego kontekstu była tam dla twojego spokoju, a nie dla pożytku modelu.

Gnicie długiego czatu

Po czterdziestu wymianach rozmowa dźwiga sporo bagażu. Martwe założenia, które poprawiłeś dwadzieścia wiadomości temu. Podejścia, które wypróbowałeś i porzuciłeś. Stare wersje dokumentu. Wczesne nieporozumienie, które naprawiłeś, ale które model może wciąż na wpół pamiętać. Wszystko to siedzi w kontekście i wszystko to może wpływać na odpowiedź. Skutkiem jest stopniowy spadek jakości, który łatwo przeoczyć, bo każda kolejna odpowiedź jest tylko odrobinę gorsza od poprzedniej.

Objawy są rozpoznawalne, kiedy już się je zna. Model przywraca zwrot, który kazałeś mu usunąć. Wraca do wcześniejszej struktury. Miesza szczegóły z dwóch wersji planu. Wydaje się polemizować ze stanowiskiem, którego już nie zajmujesz. Łapiesz się na powtarzaniu instrukcji wydanych godzinę temu. Nic z tego nie znaczy, że model się pogorszył. Znaczy, że rozmowa zamieniła się w bałagan, a model robi, co może, z bałaganem, który mu dałeś.

Rozwiązaniem jest świeży start z czystym briefem. Zanim opuścisz długą rozmowę, poproś model o podsumowanie stanu rzeczy: cel, podjęte decyzje, aktualną wersję pracy, otwarte pytania i następny krok. Przeczytaj je uważnie, bo od czasu do czasu zachowa coś, co chciałeś wyrzucić, i popraw. Potem otwórz nową rozmowę, wklej poprawione podsumowanie i aktualną wersję pracy, i kontynuuj. Nowa rozmowa ma wszystko, co ważne, i nic, co nieważne.

To nie jest oznaka porażki. Doświadczeni użytkownicy rutynowo zaczynają świeże rozmowy, często w naturalnych punktach przełomowych: gdy kończy się etap pracy, gdy zmienia się kierunek, gdy zmienia się temat. W Claude Code czyszczenie kontekstu między niepowiązanymi zadaniami to normalna część dobrej sesji, a narzędzie potrafi samo skompaktować długie sesje. Nawyk jest ten sam w obu miejscach: nie próbuj sprawić, by jedna rozmowa udźwignęła cały projekt.

Kłótnia z własną historią to marny sposób na spędzenie popołudnia. Napisz notkę przekazania i zacznij od nowa.

Dla konsultantów gnicie długiego czatu ma też stronę zwróconą ku klientowi. Jeśli dasz zespołowi klienta proces oparty na jednej, wciąż rosnącej rozmowie, jakość spadnie także u nich, a oni dojdą do wniosku, że narzędzie jest zawodne. Wbuduj świeże starty w sam proces: nowa rozmowa na każdą sprawę, każdy dokument, każdy dzień, z trwałym kontekstem przypiętym w projekcie, żeby zawsze był dostępny. Ta drobna decyzja projektowa zapobiega dużej części skarg w rodzaju kiedyś działało lepiej, które przychodzą miesiąc po przekazaniu.

W tym tygodniu zwróć uwagę na moment, w którym rozmowa zaczyna wydawać się ociężała albo zagubiona. Zamiast znowu ją poprawiać, poproś o podsumowanie, popraw je i zacznij z nim nową rozmowę. Porównaj następną odpowiedź z tym, co dostawałeś wcześniej. Świeże starty wydają się utratą postępu. W praktyce zwykle są najszybszą drogą do postępu, którego naprawdę chciałeś.

Wiedza projektowa

Część kontekstu zmienia się przy każdym zadaniu. Część prawie wcale: zasady marki klienta, słowniczek żargonu jego branży, schemat danych, którego używają jego systemy, decyzje podjęte na starcie, definicja ukończenia zlecenia. Wklejanie tego od nowa do każdej rozmowy jest żmudne i podatne na błędy. Przypnij to raz, tam, gdzie każda rozmowa to zobaczy, a przestanie być udręką.

Projekty w Claude są do tego stworzone. Wgrywasz albo wpisujesz materiały referencyjne do projektu, a każda rozmowa w jego obrębie zaczyna się z tymi materiałami na podorędziu. Dodaj własne instrukcje, a one również obowiązują wszędzie. Przy zleceniu naturalnym kształtem jest jeden projekt na klienta: brief, zakres, słowniczek, styl firmy, kilka opatrzonych komentarzem przykładów, bieżący rejestr decyzji. Każda rozmowa o tym kliencie zaczyna się od właściwych fundamentów, a ty już nigdy nie tłumaczysz jego modelu biznesowego na początku czatu.

Ta sama idea pojawia się w innych miejscach. Repozytorium może zawierać plik pamięci, który Claude Code czyta na początku każdej sesji. Skill może nieść trwałe instrukcje do powtarzającego się rodzaju zadania. Zespołowa przestrzeń robocza może udostępniać wiedzę projektową współpracownikom, żeby wszyscy pracowali na tych samych fundamentach. Różne powierzchnie, ta sama zasada: trwała wiedza należy do trwałego miejsca, a nie do czyjejś historii schowka.

Dobieraj wiedzę projektową równie starannie jak kontekst zadania, a może staranniej, bo wpływa na wszystko. Niech będzie krótka i konkretna. Dziesięciostronicowa księga marki może zawierać jedną stronę istotną dla pisania; wyodrębnij tę stronę. Długi słowniczek może zawierać tuzin terminów, które wprowadzają zamieszanie; zacznij od nich. Datuj rejestr decyzji, żeby było jasne, które decyzje są aktualne. I przeglądaj wiedzę projektu, gdy zlecenie wchodzi w nowy etap, bo to, co miało znaczenie podczas audytu, podczas budowy może być szumem.

Jeśli wyjaśniłeś coś dwa razy, to należy do projektu. Jeśli wyjaśniłeś to pięć razy, to ty jesteś projektem.

Wiedza projektowa to także świetny materiał do przekazania. Na koniec zlecenia dobrze zorganizowany projekt, zawierający kontekst klienta, przetestowane prompty, przykłady i instrukcje, to coś, z czego jego zespół może korzystać już następnego ranka. Wielu klientów uważa to za przydatniejsze niż jakikolwiek raport, bo nie jest to opis tego, jak pracować z AI w ich firmie. To gotowe, już skonfigurowane środowisko pracy.

Jest też kwestia bezpieczeństwa. Wiedza projektowa jest widoczna dla każdego, kto ma dostęp do projektu, więc zastanów się, co do niej trafia i kto może to zobaczyć. Trzymaj materiały klienta w projektach dedykowanych temu klientowi, nigdy wymieszane z materiałami innych klientów, i przy przekazaniu uzgodnij z klientem, kto po jego stronie ma mieć dostęp.

W tym tygodniu utwórz projekt dla swojego najbardziej absorbującego klienta albo dla własnej praktyki. Dodaj pięć rzeczy, które najczęściej tłumaczysz od nowa, zapisanych jako krótkie, jasne notatki. Potem popracuj w nim przez tydzień i zauważ, o ile krótsze stają się twoje prompty. To skrócenie to czas, który dotąd szedł na przypominanie, a teraz idzie na myślenie.

Powtórz cel

Długie zadania dryfują. Zaczynasz od prośby o przeprojektowanie procesu, które skróci czas realizacji, a trzy godziny później tkwisz w dyskusji o nazewnictwie pól statusu. Każdy krok miał sens w świetle poprzedniego, ale ścieżka odbiegła od celu. Modele dryfują dokładnie tak samo i z bardzo podobnego powodu: reagują na to, co mają przed sobą, a przed sobą mają ostatni krok, a nie pierwotny cel.

Lekarstwo kosztuje bardzo niewiele. Powtórz cel w trakcie lotu. Krótka linijka w miejscu, w którym zauważasz, że praca się rozgałęzia, załatwia sprawę: Przypomnienie: celem jest skrócenie czasu przygotowania wyceny dla działu sprzedaży z dni do godzin. Czy ta decyzja o nazewnictwie temu służy? Dwadzieścia słów. Ściągają rozmowę z powrotem do pytania, które ma znaczenie, i często ujawniają, że bieżące zadanie poboczne to objazd, który można porzucić.

Jest to szczególnie przydatne w pracy agentowej, w której Claude może wykonać wiele kroków, a ty nie sterujesz każdym z nich. Brief zadania zaczynający się od jasnego celu jest dobry. Brief, który dodatkowo prosi agenta, by co jakiś czas sprawdzał postęp względem celu, jest lepszy. W Claude Code krótki plan z celem na górze, trzymany w pliku aktualizowanym przez agenta w miarę pracy, działa jak bieżące przypomnienie. Agent czyta własny plan, widzi cel i mniej prawdopodobne jest, że spędzi godzinę na szlifowaniu czegoś, czego cel nie wymaga.

Ta sama dyscyplina dotyczy ludzi uczestniczących w zleceniu. Spotkania z klientem dryfują równie chętnie jak modele. Sprint, który zaczął się jako pilotaż przetwarzania faktur, po kilku sympatycznych rozmowach może zmienić się w dyskusję o całym zapleczu finansowym klienta. Powtarzanie celu na początku każdego spotkania kontrolnego, najlepiej słowami klienta z dnia startu, utrzymuje wszystkich w uczciwości. Daje ci też uprzejmy sposób na odłożenie rozrastania się zakresu: brzmi to cennie; czy pomaga osiągnąć cel dotyczący czasu realizacji, czy dopiszemy to do listy na następny raz?

Dwadzieścia słów przypomnienia może oszczędzić godzinę rozwiązywania problemu, którego nikt już nie ma.

Jest też subtelniejsza korzyść. Regularne powtarzanie celu zmusza cię do sprawdzenia, czy cel jest wciąż właściwy. Czasem dryf coś ci mówi: pierwotny cel był niewłaściwy, a praca powędrowała w stronę prawdziwego problemu. Warto to zauważyć i otwarcie omówić, zamiast ignorować dryf albo ślepo za nim podążać. Tak czy inaczej to właśnie powtórzenie celu sprawia, że wybór staje się świadomy.

Wypróbuj to podczas następnej długiej sesji roboczej. Ustaw sobie łagodne przypomnienie, może co godzinę albo przy każdej naturalnej przerwie, by powtórzyć cel w jednym zdaniu i zapytać, czy bieżący krok mu służy. Zrób to samo na początku następnego spotkania z klientem. Wytniesz trochę pracy, której nie musiałeś wykonywać, a od czasu do czasu odkryjesz, że sam cel wymaga uprzejmej poprawki, a to najcenniejszy rodzaj dryfu, jaki istnieje.

Zabij przeterminowany kontekst

Kiedy coś się zmienia, stara wersja nie jest po prostu nieaktualna. Jest aktywnie szkodliwa. Jeśli model wciąż widzi cennik z zeszłego tygodnia, poprzednią wersję regulaminu albo starą strukturę plików, często połączy jedno z drugim i wytworzy wiarygodną hybrydę: w większości nową wersję, z jednym starym szczegółem po cichu przeniesionym dalej. Wiarygodne hybrydy to najgorszy rodzaj błędu, bo wyglądają dobrze, dopóki ktoś się na nich nie oprze.

Pierwszą obroną jest powiedzenie tego głośno i wprost. Regulamin zwrotów zmienił się dzisiaj. Poniższa wersja zastępuje wszystkie wcześniejsze. Zignoruj wszelkie warunki zwrotów wspomniane wcześniej w tej rozmowie. To nie jest przesadny nacisk. To minimum. Modele nie wiedzą automatycznie, że nowszy dokument zastępuje starszy, zwłaszcza gdy oba są w kontekście. Powiedzenie im, który jest aktualny i że drugi należy pominąć, usuwa dwuznaczność.

Druga obrona, silniejsza, to całkowite usunięcie przeterminowanego materiału. Zaktualizuj dokument w wiedzy projektowej, zamiast dodawać nową wersję obok starej. Zacznij świeżą rozmowę, zamiast poprawiać długą. W repozytorium zaktualizuj plik pamięci i usuń nieaktualną instrukcję, zamiast dopisywać sprzeczność. Każda kopia starej informacji, którą zostawisz gdzieś na wierzchu, to szansa, że wypłynie w najgorszym możliwym momencie.

To częste źródło kłopotów w systemach klientów po przekazaniu. Firma zmienia regulamin, aktualizuje dokument w intranecie, ale zapomina, że zbudowany przez ciebie proces AI ma gdzieś przypiętą własną kopię starego regulaminu. Miesiąc później klient firmy dostaje odpowiedź opartą na zasadach, które już nie obowiązują. Rozwiązaniem jest projekt, a nie czujność: tam, gdzie to możliwe, niech systemy czytają z jednego źródła prawdy, zamiast trzymać własne kopie, a przegląd materiałów referencyjnych AI niech będzie częścią procesu zmian u klienta. Wpisz to do instrukcji obsługi.

Stary kontekst nie blaknie grzecznie. Czeka na okazję, by z pełnym przekonaniem się pomylić.

Jest też wersja osobista. Twoja własna biblioteka promptów i wiedza projektowa gromadzą przeterminowany materiał: instrukcje napisane dla starszego modelu, przykłady od klienta, którego styl się zmienił, obejścia problemów, które już nie istnieją. Przycinaj je okresowo. Krótka, aktualna instrukcja wygrywa z długą, w połowie przestarzałą, a ta przestarzała połowa może przeczyć tej, która przestarzała nie jest.

W tym tygodniu przyjrzyj się jednemu projektowi albo długotrwałemu procesowi i znajdź przeterminowany materiał. Stare wersje dokumentów, zastąpione decyzje, instrukcje, które już nie mają zastosowania. Usuń, co się da, to, co musisz zachować, oznacz jako historyczne, a aktualną wersję uczyń nie do pomylenia. Potem dodaj do swojej listy kontrolnej przekazania linijkę przypominającą klientom, by robili to samo przy każdej zmianie zasad. Najtańszy do naprawienia błąd to ten, który nie miał skąd się wziąć, bo nie było przeterminowanego dokumentu.

Ustrukturyzowane wejście

Kiedy prompt zawiera kilka rodzajów materiału, model musi ustalić, gdzie jeden się kończy, a drugi zaczyna. Gdzie kończy się transkrypcja, a zaczyna twoja instrukcja? Czy ten akapit to przykład dobrego wyniku, czy część dokumentu źródłowego? Zwykle zgaduje dobrze. Czasem nie, a błędy doprowadzają do szału: instrukcja potraktowana jako treść, przykład streszczony, jakby był dokumentem, wiadomość klienta wykonana, jakby była twoim poleceniem.

Rozwiązaniem jest ustrukturyzowanie wejścia. Owiń każdy odrębny blok wyraźnie nazwanymi znacznikami: dokument źródłowy w jednym, przykłady w drugim, tło klienta w trzecim, instrukcję w czwartym. Claude szczególnie dobrze reaguje na znaczniki w stylu XML, a ich nazwy nie muszą trzymać się żadnego standardu. Najlepiej sprawdzają się proste, opisowe etykiety: contract, previous_emails, style_examples, task. Potem odwołuj się do znaczników w instrukcji: korzystając z regulaminu w znacznikach policy, napisz odpowiedź na wiadomość w znacznikach customer_message.

Struktura na wejściu zwykle daje strukturę na wyjściu. Kiedy wejście jest wyraźnie podzielone na sekcje, model lepiej pamięta, do czego służy każda z nich, dokładniej cytuje z właściwej i trzyma się instrukcji, zamiast rozpraszać się materiałem. Możesz też, według tej samej idei, prosić o ustrukturyzowany wynik, z rozumowaniem w jednym znaczniku, a ostateczną odpowiedzią w drugim, dzięki czemu oprogramowanie albo zabiegany czytelnik łatwo wyłowi część, która ma znaczenie.

Jest tu wymiar bezpieczeństwa, który warto traktować poważnie. W systemach klientów duża część wejścia pochodzi z zewnątrz: maile od klientów, wgrane dokumenty, strony internetowe. Część tej treści może zawierać tekst wyglądający jak instrukcje, przypadkiem albo celowo. Wyraźne oddzielenie niezaufanej treści od twoich instrukcji, oznaczenie jej jako danych do przetworzenia, a nie poleceń do wykonania, i wyraźne poinformowanie modelu, by nie wykonywał instrukcji znalezionych w jej wnętrzu, to podstawowa obrona. Nie jest kompletna, dlatego dalsze rozdziały omawiają zabezpieczenia i ludzkie punkty kontrolne, ale stanowi fundament.

Powiedz modelowi, która część jest listem, a która twoją notatką o liście. Nie zawsze rozpozna to na oko.

Ustrukturyzowane wejście sprawia też, że prompty łatwiej utrzymywać. Kiedy system klienta składa prompt z kilku źródeł – rekordu klienta, wyciągu z regulaminu, kilku przykładów i przychodzącej wiadomości – znaczniki sprawiają, że każdy składnik jest widoczny i wymienny. Kolega czytający szablon promptu rok później od razu widzi, co gdzie trafia. Ta czytelność to część tego, co czyni system obsługiwalnym przez kogoś, kto nigdy cię nie spotkał.

W tym tygodniu weź jeden ze swoich bardziej złożonych promptów i przebuduj go za pomocą znaczników. Nazwij każdy blok zgodnie z tym, czym jest, trzymaj instrukcję we własnej oznaczonej sekcji na końcu i odwołuj się w niej do bloków po nazwie. Uruchom go na kłopotliwych danych. Jeśli nic się nie zmieni, i tak sprawiłeś, że prompt łatwiej czytać i utrzymywać. Zwykle jednak coś się zmienia.

Sprint dokumentacyjny

Każda mała firma działa po części na wiedzy, która istnieje wyłącznie w głowach ludzi. Jak naprawdę wygląda zamknięcie miesiąca. Do którego dostawcy trzeba zadzwonić zamiast pisać maila. Po co istnieje ten drugi arkusz. Kiedy ta wiedza wychodzi za drzwi, na urlop albo na dobre, wszystko zaczyna się sypać. A kiedy firma próbuje korzystać z AI, odkrywa, że model też nie czyta w myślach. Sprint dokumentacyjny rozwiązuje oba problemy naraz i jest jednym z najbardziej po cichu wartościowych mikrozleceń, jakie możesz sprzedać.

Kształt to sprint o stałej długości, zwykle tydzień lub dwa, skupiony na jednym obszarze firmy. Rozmawiasz z ludźmi, którzy wykonują pracę, za ich zgodą nagrywasz omówienia, zbierasz istniejące, rozproszone dokumenty i z pomocą Claude’a zamieniasz to wszystko w jasną, uporządkowaną dokumentację: opisy procesów, reguły decyzyjne, słowniczki, listy kontrolne i najczęściej zadawane pytania. Każdy szkic wraca do osoby, która wykonuje daną pracę, do poprawienia. Rezultatem jest zestaw dokumentów, według którego mógłby działać nowy pracownik i z którego model mógłby korzystać jako z kontekstu.

Ta podwójna publiczność to główny argument sprzedażowy. Tradycyjne projekty dokumentacyjne trudno było uzasadnić, bo dokumentów rzadko ktoś czytał. Dokumentacja pisana jednocześnie dla ludzi i dla AI jest używana nieustannie: staje się wiedzą projektową stojącą za asystentem zespołu, materiałem referencyjnym dla pilotażu agenta, kontekstem, dzięki któremu prompty działają. Klient, który kupuje sprint dokumentacyjny, kupuje fundament, na którym oprze się każde przyszłe zlecenie AI, i widzi, jak ten fundament jest używany, już po kilku dniach.

Lekcje warsztatowe z tej części mają tu bezpośrednie zastosowanie. Wklejaj oryginał: transkrypcje i prawdziwe dokumenty, a nie twoje ich streszczenie. Zabijaj przeterminowany kontekst: wyszukuj i wycofuj nieaktualne wersje na bieżąco. Strukturyzuj wejście: spójne nagłówki i podpisane sekcje sprawiają, że modelom łatwiej korzystać z dokumentów. A zasada przekazania – spisywanie stanu, decyzji, otwartych pytań i następnego działania przy każdej zmianie warty – staje się nawykiem, który zostawiasz klientowi, żeby dokumentacja żyła także po twoim odejściu.

Kiedyś dokumentację pisało się dla audytora. Teraz pisze się ją dla nowego pracownika i dla modelu, a oni obaj naprawdę ją czytają.

Bądź precyzyjny w kwestii zakresu. Jeden obszar procesów, nie cała firma. Stała liczba wywiadów. Wskazany z nazwiska właściciel po stronie klienta, który będzie utrzymywał dokumenty w aktualności. Jasne określenie, gdzie dokumenty będą przechowywane i jak będą utrzymywane. Bez właściciela dokumentacja w ciągu kilku miesięcy niszczeje, a zniszczona dokumentacja podana modelowi daje pewne siebie, nieaktualne odpowiedzi, co jest gorsze niż jej brak.

To zlecenie w naturalny sposób prowadzi do kolejnych. Kiedy proces jest jasno udokumentowany, szanse na automatyzację stają się oczywiste, a ty jesteś osobą, która właśnie przeczytała każdy jego krok. W tym tygodniu wybierz proces z własnej praktyki, który istnieje tylko w twojej głowie. Spędź godzinę z Claude’em, zamieniając go w spisany przewodnik. Potem przeczytaj go i zauważ, jak wiele założyłeś, że nikomu nie trzeba mówić. Za zamknięcie właśnie tej luki zapłacą ci klienci.

Najpierw przeczytaj repozytorium

Spora część mikrozleceń odbywa się w cudzym repozytorium. Skrypt, który uzgadnia dwa eksporty. Wewnętrzne narzędzie, na którym polega dział operacyjny. Strona internetowa z formularzem, który powinien mądrzej kierować zapytania. Przychodzisz jako obcy, zwykle z krótkim kalendarzem, a pokusa, by zacząć coś zmieniać już pierwszego popołudnia, jest silna. Oprzyj się jej. Dziesięć minut rozpoznania kupuje godziny poprawnego kodu, a z Claude Code te dziesięć minut jest tanie.

Claude Code to agentowe narzędzie do programowania od Anthropic. Czyta bazę kodu, edytuje pliki, uruchamia polecenia i sprawdza własną pracę, a ty kierujesz nim w rozmowie. Zanim poprosisz go o jakąkolwiek zmianę, poproś, żeby się rozejrzał. Przeczytaj to repozytorium i wyjaśnij jego architekturę: główne komponenty, jak płyną między nimi dane, jakich konwencji się trzyma, jak jest budowane i testowane, i wszystko, co wygląda na kruche. Będzie przeszukiwał, otwierał pliki, czytał konfigurację i wróci z mapą. Twoim zadaniem jest krytycznie przeczytać tę mapę i zadawać pytania uzupełniające, dopóki nie zrozumiesz terenu.

To w fazie rozpoznania wychodzi na wierzch wiele ukrytych problemów klienta. Zestaw testów, który nie był uruchamiany od roku. Plik konfiguracyjny z danymi logowania w środku. Dwa moduły, które robią to samo na dwa różne sposoby. Zależność opóźniona o kilka wersji. Żadna z tych rzeczy może nie wchodzić w zakres twojego zlecenia, ale musisz o nich wiedzieć, częściowo dlatego, że wpływają na twoją pracę, a częściowo dlatego, że często są materiałem na następne zlecenie. Zanotuj je, powiedz klientowi i pracuj dalej.

Pomaga tu tryb planowania, bo w nim Claude może czytać i analizować, niczego nie edytując. Przy pierwszym spojrzeniu na nieznaną bazę kodu to dokładnie właściwe ustawienie. Dostajesz pełną zdolność czytania agenta bez ryzyka, że gorliwa pierwsza sugestia zamieni się w niesprawdzoną zmianę. Kiedy zrozumiesz kształt rzeczy, możesz przejść do trybu, w którym edycje są dozwolone, w wybranych przez ciebie granicach.

Agent, który przeczytał bazę kodu, pisze kod, który do niej pasuje. Ten, który jej nie przeczytał, pisze kod, który się jedynie kompiluje.

Jest też korzyść dla klienta. Podsumowanie architektury jest przydatne samo w sobie. Wiele małych firm ma kod, którego nikt w pełni nie rozumie, napisany przez wykonawcę, który dawno poszedł dalej. Jasna, spisana mapa ich własnego systemu, przygotowana w pierwszej godzinie zlecenia i sprawdzona przez ciebie, często spotyka się z prawdziwą wdzięcznością. Niektórzy konsultanci oferują to jako samodzielne mikrozlecenie: przegląd bazy kodu zakończony spisaną mapą, listą ryzyk i uszeregowanym zestawem usprawnień.

Uczyń rozpoznanie rytuałem przy każdym repozytorium, którego dotykasz. Przed pierwszą edycją poproś o mapę, przeczytaj ją, popraw tam, gdzie wiesz lepiej, i zapisz poprawioną wersję tam, gdzie agent zobaczy ją następnym razem. Następny rozdział mówi dokładnie gdzie. Popełnisz mniej błędów, będą one mniejsze, a ty będziesz wyglądać na kogoś, kto traktuje system klienta poważnie, a właśnie takie wrażenie chcesz zostawić pierwszego popołudnia.

Najpierw CLAUDE.md

Pierwszym plikiem, który piszesz w repozytorium klienta, powinien zwykle być ten, który wyjaśnia repozytorium Claude’owi. Plik o nazwie CLAUDE.md w katalogu głównym projektu jest automatycznie czytany na początku każdej sesji Claude Code. Cokolwiek tam umieścisz, agent wie to, zanim zrobi cokolwiek innego: jak budować i testować, jakich konwencji przestrzegać, których katalogów nie ruszać, które polecenia są bezpieczne, a które nie. To tekst o największej dźwigni, jaki napiszesz w całym tygodniu.

Zacznij od poleceń. Jak zainstalować zależności, uruchomić testy, wystartować aplikację, sprawdzić kod linterem. To rzeczy, których agent najczęściej potrzebuje i które najczęściej zgaduje, a złe zgadnięcie marnuje czas albo, co gorsza, uruchamia coś niepożądanego. Potem konwencje: nazewnictwo, struktura folderów, preferowane biblioteki, sposób obsługi błędów, sposób pisania testów. Potem pułapki: moduł, który wygląda na nieużywany, ale jest używany, zmienna środowiskowa, którą trzeba ustawić, krok wdrożenia, którego nigdy nie wolno uruchamiać z laptopa. Niech to będzie krótkie. Długi plik pamięci czyta się mniej uważnie, zarówno agenci, jak i ludzie.

Możesz go szybko zainicjować. Claude Code potrafi wygenerować startowy CLAUDE.md na podstawie bazy kodu poleceniem init, a mapa architektury z fazy rozpoznania to dobry surowiec. Ale nie przyjmuj wygenerowanej wersji bez redakcji. Najcenniejsze linijki to te, które zna tylko człowiek: dział finansów uruchamia skrypt eksportu pierwszego dnia roboczego każdego miesiąca; nie zmieniaj jego formatu wyjściowego bez uprzedzenia ich. Żadne czytanie kodu by tego nie ujawniło. Dowiedziałeś się tego podczas rozmowy diagnostycznej.

Dla konsultantów plik pamięci pełni podwójną funkcję. Podczas zlecenia sprawia, że twoje własne sesje są szybsze i bardziej niezawodne. A przy tym jest materiałem do przekazania: kiedy odchodzisz, następny programista klienta albo własne sesje Claude’a klienta dziedziczą wszystko, czego dowiedziałeś się o jego bazie kodu. Dobry CLAUDE.md to instrukcja obsługi, którą narzędzia czytają za ciebie. Klienci, którzy sami korzystają z Claude Code, od razu zauważają różnicę; ich sesje nagle zachowują się tak, jakby ktoś porządnie zbriefował agenta, bo ktoś to zrobił.

Każde wyjaśnienie, które umieścisz w pliku pamięci, to wyjaśnienie, którego już nigdy nie będziesz musiał powtarzać.

Dbaj o jego aktualność. Kiedy odkryjesz nową pułapkę, dopisz ją. Kiedy zmieni się konwencja, zaktualizuj ją. Usuwaj instrukcje, które już nie obowiązują, bo przeterminowane instrukcje są gorsze niż żadne. Claude Code obsługuje też pliki pamięci w podkatalogach oraz osobisty plik na preferencje, których nie należy udostępniać zespołowi, więc zasady projektu umieść we wspólnym pliku, a własne nawyki w swoim.

Przy następnym zleceniu w repozytorium niech plik pamięci będzie twoim pierwszym commitem. Polecenia, konwencje, pułapki, poniżej strony. Potem popracuj dzień i dopisz każdą poprawkę, którą musiałeś wprowadzić w działaniu agenta. Pod koniec zlecenia będziesz mieć dokument, o którego potrzebie klient nie wiedział i którego nie będzie chciał stracić. To najmniejszy rezultat, jaki kiedykolwiek przekażesz, i całkiem możliwe, że ten używany najczęściej.

Plan przed edycją

Każ agentowi napisać plan, zanim dotknie jakiegokolwiek pliku. Przeczytanie błędnego planu zajmuje trzydzieści sekund. Odkręcenie błędnego refaktoringu w dziewięciu plikach zajmuje popołudnie, a przy dwutygodniowym zleceniu nie masz wielu wolnych popołudni. Najpierw plan – to najtańszy pojedynczy nawyk, który chroni przed kosztownymi błędami w programowaniu agentowym, i szczególnie dobrze pasuje do pracy konsultanta.

Claude Code ma do tego tryb planowania. W nim agent może czytać pliki, przeszukiwać bazę kodu i rozważać zmianę, ale nie może niczego edytować ani uruchamiać poleceń, które zmieniają stan. Opisujesz zadanie; on bada sprawę i proponuje plan: które pliki się zmienią, na czym będzie polegała każda zmiana, w jakiej kolejności je wprowadzić, jak sprawdzi wynik. Czytasz plan, kwestionujesz części, z którymi się nie zgadzasz, zadajesz pytania i dopiero wtedy pozwalasz mu działać.

Wartość tkwi w rozmowie o planie. To tutaj łapiesz agenta na tym, że proponuje przepisanie modułu, o którym wiesz, że jest kruchy, albo wybiera bibliotekę, której klient nie używa, albo przeocza dalszego odbiorcę formatu danych, który chce zmienić. To także tu stosujesz wiedzę z rozmowy diagnostycznej i rozpoznania: zespół raportowy czyta tę tabelę bezpośrednio; nie zmieniaj jej kolumn. Trzydzieści sekund czytania i jedno zdanie poprawki mogą oszczędzić dzień naprawiania.

Plany to też dobre materiały dla klienta. Przy zmianie, która ma znaczenie, spisany i sprawdzony przez ciebie plan może trafić do lidera technicznego klienta, zanim zmieni się choćby linijka kodu. To zamienia potencjalnie nerwowy moment – zewnętrzny konsultant z agentem AI w ich bazie kodu – w uspokajający: oto dokładnie, co się zmieni, oto dlaczego, oto jak to sprawdzimy. Ludzie czują się znacznie pewniej przy zmianach, które widzieli opisane z wyprzedzeniem. Mali klienci rzadko doświadczają takiej uprzejmości ze strony wykonawców i zauważają, kiedy jej doświadczają.

Plan to miejsce, w którym wolno ci się mylić tanio. Tam wydawaj swoje błędy.

Nie każda zmiana potrzebuje formalnego planu. Zmiana nazwy zmiennej albo poprawka literówki – nie. Dobra reguła kciuka: planuj zawsze, gdy zmiana dotyka więcej niż jednego pliku, zmienia format danych albo interfejs, albo robi cokolwiek, co trudno byłoby cofnąć. W razie wątpliwości planuj. Koszt jest niewielki, a nawyk planowania każdej istotnej pracy uchroni cię przed większością kłopotów, przed którymi ostrzega ta książka.

Jest też cichsza korzyść. Czytanie planów sprawia, że lepiej specyfikujesz pracę. Zaczynasz zauważać, co pominąłeś w prośbie, bo plan ujawnia lukę: agent założył format, którego nie określiłeś, albo wybrał podejście, którego ty byś nie wybrał. Z czasem twoje prośby stają się ostrzejsze, a plany wymagają mniej poprawek. W tym tygodniu używaj trybu planowania przy każdej zmianie obejmującej kilka plików. Czytaj każdy plan tak, jakby napisał go junior, a ty odpowiadał za wynik. Bo odpowiadasz.

Małe diffy, szybkie pętle

Jedna sprawa na turę, sprawdzona przed następną. To rytm pracy, dzięki któremu dostarczanie z agentem jest niezawodne. Sesje w stylu wielkiego wybuchu, w których prosisz o pięć zmian naraz i oceniasz wynik jako całość, zawodzą w sposób, który kosztownie się rozplątuje. Małe diffy zawodzą w sposób, który można po prostu cofnąć. Przy krótkim zleceniu różnica między tymi dwoma rodzajami porażki to często różnica między zmieszczeniem się w terminie a niezmieszczeniem się.

Wzorzec łatwo opisać, a jego przestrzeganie wymaga dyscypliny. Poproś o jedną zmianę. Pozwól agentowi ją wprowadzić i uruchomić odpowiednie kontrole. Przejrzyj diff. Jeśli jest dobry, zrób commit. Jeśli nie, cofnij go i poproś ponownie, z lepszą instrukcją. Potem przejdź do następnej zmiany. Każdy cykl może trwać kilka minut. Dzień takich cykli daje czystą, łatwą do przejrzenia historię małych, działających kroków, a dokładnie to chcesz przekazać klientowi.

Pokusa grupowania jest silna, bo agent jest szybki, a duże prośby wydają się wydajne. Ale duży diff trudno porządnie przejrzeć. Twoja uwaga słabnie w połowie, a subtelny problem w siódmym pliku się prześlizguje. Kiedy coś później się zepsuje, nie da się łatwo ustalić, która z pięciu zmian była przyczyną. Małe diffy sprawiają, że każdy przegląd jest na tyle krótki, by zrobić go dobrze, i utrzymują jasny łańcuch przyczynowy. Jeśli zmiana numer cztery coś zepsuła, wiesz dokładnie, gdzie szukać.

Pasuje to też do tego, jak klienci lubią oglądać postępy. Sprint, którego historia czyta się jak ciąg małych, sensownych, opisanych commitów, łatwo wyjaśnić na piątkowej demonstracji i łatwo zrozumieć własnym programistom klienta po twoim odejściu. Poproś Claude Code o pisanie jasnych komunikatów commitów, które wyjaśniają, dlaczego wprowadzono każdą zmianę, a nie tylko co się zmieniło. Ta historia staje się dokumentacją samą w sobie: czytelnym zapisem tego, co zrobiłeś i dlaczego.

Małe kroki nie są powolne. To najszybszy sposób, by dotrzeć tam, skąd wciąż znajdziesz drogę powrotną.

Szybkie pętle zależą od szybkiej weryfikacji, której poświęcony jest następny rozdział. Jeśli uruchomienie kontroli trwa dziesięć minut, rytm się rwie i znowu kusi cię grupowanie. Częścią przygotowania zlecenia jest zadbanie o szybki sposób sprawdzenia każdej zmiany: ukierunkowane polecenie testowe, skrypt sprawdzający odpowiednią ścieżkę, prosta kontrola, którą agent uruchomi w kilka sekund. Czas zainwestowany pierwszego dnia w szybką pętlę informacji zwrotnej zwraca się przy każdym kolejnym cyklu.

Wypróbuj ten rytm przez cały dzień przy następnym zadaniu programistycznym. Przed każdą prośbą zapytaj siebie, czy zawiera więcej niż jedną sprawę. Jeśli tak, podziel ją. Po każdej zmianie nalegaj na krok weryfikacji i commit, zanim pójdziesz dalej. Na koniec dnia przeczytaj historię commitów. Jeśli opowiada jasną historię, za którą nadążyłby obcy, rytm zadziałał. Jeśli czyta się jak seria panicznych zapisów, grupowałeś. Większość ludzi odkrywa, że pierwsza wersja jest też mniej męcząca.

Niech sam uruchamia testy

Agent, który może sam uruchamiać weryfikację, przestaje zgadywać. Daj Claude Code polecenie uruchamiające testy, a wprowadzi zmianę, uruchomi je, przeczyta błędy, poprawi i uruchomi ponownie, aż przejdą, bez twojego pośredniczenia w przekazywaniu wiadomości między agentem a terminalem. Ta jedna zdolność zamienia asystenta, który podsuwa kod, w agenta, który dostarcza działający kod, i jest fundamentem szybkiego, niezawodnego dostarczania.

Pierwszym zadaniem przy każdym zleceniu w repozytorium jest więc ustalenie, jak działa weryfikacja. Czy jest zestaw testów? Czy się uruchamia? Jak długo trwa? Czy da się szybciej uruchomić tylko odpowiednie testy? Wpisz odpowiedzi do pliku pamięci, żeby agent znał je od początku każdej sesji. Jeśli testy są zepsute, ich naprawa może być pierwszym małym zadaniem zlecenia i warto ją wykonać, bo od tego zależy każde kolejne zadanie.

Wiele baz kodu małych firm nie ma żadnych testów. To nie powód, by porzucić weryfikację; to powód, by jakąś stworzyć. Zanim zmienisz istniejące zachowanie, poproś Claude Code o napisanie testów, które utrwalają to, co kod robi obecnie, uruchom je, by potwierdzić, że przechodzą, a dopiero potem wprowadź zmianę. Testy stają się siatką bezpieczeństwa dla twojej pracy i aktywem dla klienta. Tam, gdzie testy automatyczne są niepraktyczne, mały skrypt, który uruchamia daną funkcję i wypisuje wynik, jest znacznie lepszy niż nic. Zasada jest taka, że agent powinien mieć sposób sprawdzenia swojej pracy, który nie zależy od jego własnej opinii.

Proś o dowody, nie o zapewnienia. Kiedy agent zgłasza, że coś działa, poproś o pokazanie wyniku testów. Agent, który mówi wszystkie testy przechodzą, i agent, który pokazuje wynik, w którym wszystkie testy przechodzą, składają różne twierdzenia, a tylko jedno z nich jest dowodem. W pracy dla klienta ma to ogromne znaczenie: będziesz raportować wyniki ludziom, którzy ci ufają, i chcesz, żeby każde twoje twierdzenie opierało się na czymś, co widziałeś.

Test, który agent może uruchomić, jest lustrem. Bez niego agent tylko podziwia własne odbicie w twoim zaufaniu.

Weryfikacja definiuje też, co znaczy „gotowe” dla każdego zadania. Napraw błąd z datami jest mgliste. Napraw błąd z datami tak, by test w module raportów przechodził, a żaden inny test się nie zepsuł da się sprawdzić. Formułowanie zadań w ten sposób czyni agenta skuteczniejszym, a twój przegląd szybszym, bo wiesz dokładnie, czego szukać. Daje ci to także czysty materiał do raportu dla klienta: błąd, poprawka i dowód.

Przy następnym zadaniu programistycznym zacznij od potwierdzenia, że polecenie testowe działa, i wpisania go do pliku pamięci. Potem formułuj każdą prośbę z dołączonym krokiem weryfikacji i proś o pokazanie wyniku, zanim przyjmiesz jakiekolwiek zapewnienie o sukcesie. Jeśli testów nie ma, niech ich napisanie będzie pierwszym zadaniem. Przez dzień będzie się to wydawać wolniejsze. Potem wszystko przyspieszy, a ty już nigdy nie będziesz musiał się zastanawiać, czy coś działa.

Git to przycisk „cofnij”

Zrób commit, zanim spuścisz agenta ze smyczy. Czyste drzewo robocze zamienia każdą nieudaną sesję w dwusekundowy reset zamiast w kryminalistyczną rekonstrukcję. Kontrola wersji zawsze była dobrą praktyką; gdy agent szybko wprowadza zmiany w wielu plikach, staje się najważniejszą siatką bezpieczeństwa, jaką masz. W bazie kodu klienta, gdzie twoje błędy stają się jego problemem, nie jest opcjonalna.

Rutyna jest prosta. Przed rozpoczęciem zadania upewnij się, że wszystko jest zacommitowane. Pozwól agentowi pracować. Przejrzyj zmiany w diffie. Jeśli są dobre, zrób commit z jasnym komunikatem. Jeśli nie, odrzuć je i zacznij od nowa z lepszą instrukcją. Ponieważ każde zadanie zaczyna się od czystego stanu, zły wynik kosztuje cię tylko czas tego zadania, nigdy pracę, która była wcześniej. Claude Code przechowuje też własne punkty kontrolne w obrębie sesji, więc możesz cofnąć się do wcześniejszego momentu rozmowy, ale to git jest zapisem, który przetrwa sesję, i to jego zobaczy zespół klienta.

Gałęzie czynią to jeszcze bezpieczniejszym. Pracuj na gałęzi, a nie na głównej linii klienta, i scalaj dopiero wtedy, gdy zmiana jest przejrzana i zweryfikowana. Wielu klientów będzie chciało przeglądać zmiany, zanim trafią na produkcję, a gałąź z pull requestem to do tego naturalny kształt. Nawet jeśli klient nie prosi, pracuj w ten sposób. Nic to nie kosztuje, a chroni wszystkich.

Kiedy prowadzisz kilka prac naraz, pomagają worktree. Git worktree to osobny katalog roboczy podłączony do tego samego repozytorium, na własnej gałęzi. Dwie sesje Claude Code w dwóch worktree mogą równolegle pracować nad dwiema funkcjami, nie wchodząc sobie w pliki. Dla mikrokonsultanta, który żongluje poprawką błędu i małą nową funkcją dla tego samego klienta albo testuje eksperymentalne podejście obok bezpiecznego, to schludny sposób na uniknięcie zamieszania. Każdy worktree to osobna czysta sala.

Najtańsze ubezpieczenie w pracy z agentami to commit zrobiony trzydzieści sekund przed tym, zanim był potrzebny.

Uzgodnij zasady z klientem na starcie. Na której gałęzi pracować, kto przegląda i scala, czy możesz wypychać zmiany bezpośrednio, czy tylko przez pull request, i czego nigdy nie wolno commitować: danych logowania, danych osobowych, dużych plików binarnych. Wpisz to, co najważniejsze, do pliku pamięci, żeby agent też tego przestrzegał. Klientów, którzy mieli złe doświadczenia z wykonawcami, uspokoi widok tych zasad spisanych i przestrzeganych. Ci, którzy nie mieli, po prostu nigdy nie będą mieli złego doświadczenia z tobą.

Niech w tym tygodniu stanie się to odruchem. Przed każdym zadaniem agenta sprawdź, czy drzewo robocze jest czyste. Po każdym zadaniu przejrzyj i zrób commit albo reset. Jeśli prowadzisz prace równoległe, wypróbuj worktree dla drugiego wątku. Przez dzień czy dwa będzie się to wydawać przesadną pedanterią. Potem będzie jak zapinanie pasów – niczym niezwykłym i po cichu niezbędnym – a ludzie, którzy pracują bez nich, zaczną cię lekko niepokoić.

Własne polecenia z ukośnikiem

Każdy proces, który uruchamiasz w Claude Code dwa razy, powinien stać się poleceniem. Claude Code pozwala zapisać prompt jako polecenie wielokrotnego użytku, które ty albo ktokolwiek z zespołu może wywołać ukośnikiem i nazwą. W ciągu zlecenia repozytorium klienta może dorobić się małego prywatnego zestawu narzędzi, ukształtowanego dokładnie tak, jak naprawdę pracuje jego zespół. Ten zestaw jest przydatny w trakcie twojego zlecenia i cenny długo po nim.

Pomyśl o zadaniach, które powtarzają się w typowej małej bazie kodu. Przegląd zmiany przed scaleniem. Przygotowanie wydania z dziennikiem zmian. Generowanie cotygodniowego raportu z eksportu danych. Wdrożenie nowego programisty przez objaśnienie architektury. Każde z nich wymaga za każdym razem dość standardowego zestawu instrukcji, tych samych kontroli i tego samego formatu wyniku. Napisanie tych instrukcji raz, przetestowanie ich i zapisanie jako polecenia oznacza, że nikt już nie musi ich pamiętać.

Polecenia mogą przyjmować argumenty, więc jedno polecenie może obsłużyć wiele przypadków: przejrzyj tę gałąź, zrób raport za ten miesiąc, objaśnij ten moduł. Można je też udostępniać przez repozytorium, dzięki czemu każdy, kto pracuje nad projektem, ma ten sam zestaw. Ten wspólny zestaw po cichu standaryzuje sposób, w jaki zespół pracuje z agentem. Zamiast pięciu osób piszących pięć wersji promptu do przeglądu kodu, o różnej jakości, wszyscy używają jednej, przetestowanej i dopracowanej.

W nowszych wersjach Claude Code polecenia i skille zbliżyły się do siebie, a wiele z tego, co kiedyś było prostym poleceniem, można teraz spakować jako skill, który dodatkowo ładuje się sam, gdy jest potrzebny. Następna część omawia skille dogłębnie. Praktyczna lekcja jest tak czy inaczej ta sama: powtarzalna praca zasługuje na nazwaną, wielokrotnego użytku, wspólną formę, a nie na świeży prompt za każdym razem wpisywany z pamięci.

Lista poleceń zespołu to jego portret przy pracy. Zadbaj, żeby portret był pochlebny i wierny.

Dla mikrokonsultantów polecenia to znakomity element przekazania i naturalne mikrozlecenie samo w sobie. Krótkie zlecenie polegające na zidentyfikowaniu powtarzalnych zadań zespołu programistów, napisaniu i przetestowaniu polecenia dla każdego z nich i przeszkoleniu zespołu w ich używaniu łatwo zakresować, szybko dostarczyć i od razu przynosi pożytek. Wprowadza też zespół w ideę zapisywania własnych procesów, a to brama do większych zleceń obejmujących skille, automatyzację i agentów.

Przyjrzyj się w tym tygodniu własnej pracy i znajdź dwie rzeczy, o które prosiłeś Claude Code więcej niż raz mniej więcej tymi samymi słowami. Zamień każdą w polecenie z jasną nazwą i krótkim opisem, kiedy go używać. Potem korzystaj z nich przez tydzień i dopracuj je. Kiedy następnym razem zaczniesz zlecenie u klienta, prowadź bieżącą listę wszystkiego, o co zespół prosi dwa razy. Pod koniec sprintu ta lista będzie zestawem narzędzi, a zestaw narzędzi rezultatem, o który klient nie wiedział, że może poprosić.

Konektory jako ręce

Przez długi czas wąskim gardłem nie było rozumowanie. Model potrafił ustalić, co trzeba zrobić; po prostu nie sięgał do systemów, w których to robienie się odbywało. Konektory to zmieniają. Dzięki Model Context Protocol, otwartemu standardowi łączenia aplikacji AI z narzędziami i danymi, Claude może czytać zgłoszenia, odpytywać bazy danych, sprawdzać kalendarze, przeszukiwać repozytoria dokumentów i aktualizować rekordy. Asystent programisty staje się czymś bliższym operatorowi, a operator może dostarczać zupełnie inną klasę mikrozleceń.

Model Context Protocol, zwykle skracany do MCP, określa wspólny sposób, w jaki narzędzia i źródła danych przedstawiają się modelowi. Wiele popularnych usług oferuje dziś konektory, a dla tych, które ich nie mają, mały własny serwer może udostępnić dokładnie te możliwości, których potrzebujesz. W Claude Code dodajesz serwery do projektu, a agent może wtedy korzystać z ich narzędzi obok wbudowanych. W aplikacjach Claude konektory dają ten sam zasięg w codziennej pracy.

W konsultingu ciekawe zlecenia często leżą właśnie na tym styku. Zespół obsługi klienta, którego asystent może sprawdzić zamówienie klienta, zanim naszkicuje odpowiedź. Kierownik operacyjny, którego agent może przeczytać tracker projektów i napisać cotygodniowe podsumowanie statusu. Programista, którego sesja może jednocześnie sprawdzić serwis śledzenia błędów i odpowiedni kod. Nic z tego nie wymaga egzotycznej inżynierii. Wymaga wiedzy, które systemy mają znaczenie, bezpiecznego ich podłączenia i napisania instrukcji mówiących agentowi, jak z nich korzystać.

Bezpieczeństwo to serce tego rzemiosła. Konektor daje prawdziwe możliwości w prawdziwych systemach, a zasada najmniejszych uprawnień obowiązuje tu z pełną mocą. Dawaj dostęp do odczytu tam, gdzie odczyt wystarcza. Dostęp do zapisu zawężaj ściśle, do konkretnych działań. Używaj kont i danych logowania utworzonych w tym celu, a nie czyjegoś osobistego loginu. Zostaw krok zatwierdzenia przez człowieka przy wszystkim, co wysyła, wydaje albo usuwa. Pamiętaj, że treść pobrana z zewnętrznych systemów to dane, nie instrukcje; dokument albo mail pobrany przez narzędzie może zawierać tekst próbujący sterować agentem, a system powinien być zaprojektowany z myślą o tym.

Zasięg bez ograniczeń to nie możliwości. To incydent czekający na swoją datę.

To także miejsce, w którym trzeba jasno powiedzieć klientom, co robisz, a czego nie. Podłączenie agenta do ich systemów to zmiana ich postawy bezpieczeństwa. Udokumentuj, które konektory skonfigurowałeś, co każdy może zrobić, jakich danych logowania używa i jak go odłączyć. Umieść to w instrukcji obsługi. Klient, który widzi dokładnie, do czego agent ma dostęp i jak go wyłączyć, to klient, który powierzy ci następne, większe połączenie.

W tym tygodniu wybierz jeden system, do którego stale zaglądasz w swojej pracy – tracker, repozytorium dokumentów, kalendarz – i podłącz go do Claude’a z najwęższymi uprawnieniami, które są jeszcze przydatne. Korzystaj z niego przez kilka dni i zauważ, które zadania się zmieniają. Potem wyobraź sobie tę samą zmianę w zespole klienta. Ten obraz, jasno opisany, to oferta na twoje następne zlecenie.

Bez interfejsu, w CI

Ten sam agent, który pomaga ci interaktywnie, może działać bez nadzoru. Claude Code potrafi pracować w trybie nieinteraktywnym: dostaje prompt i zestaw uprawnień, a zwraca wynik, choć nikt nie siedzi przy klawiaturze. Wstaw to do potoku ciągłej integracji, a każdy pull request może zostać przejrzany, każde wydanie może dostać szkic dziennika zmian, a każdy nieudany build – pierwszą diagnozę, automatycznie. Dla małego zespołu programistów to mikrozlecenie z bardzo wyraźnym „przed” i „po”.

Najczęstszym punktem wyjścia jest automatyczny przegląd kodu. Kiedy otwiera się pull request, potok uruchamia Claude Code z instrukcjami, by przejrzał diff pod kątem konwencji zespołu, sprawdził typowe problemy i zostawił komentarze. Nie zastępuje to przeglądu przez człowieka. Wyłapuje to, co ludzie przelatują wzrokiem: brakujący test, niespójne nazewnictwo, błąd po cichu połykany, zmianę interfejsu, który ma wywołania gdzie indziej. Ludzcy recenzenci mogą wtedy poświęcić uwagę pytaniom, które wymagają osądu. Istnieje oficjalna integracja Claude Code z GitHub, która czyni taką konfigurację znacznie prostszą niż budowanie jej od zera.

Inne zastosowania przychodzą naturalnie. Szkicowanie notatek do wydania na podstawie commitów od ostatniego tagu. Wstępna obsługa nowych zgłoszeń przez nadawanie im etykiet i wskazywanie, której części kodu dotyczą. Aktualizacja dokumentacji, gdy zmienia się interfejs. Zaplanowana kontrola podsumowująca aktualizacje zależności. Każde z nich to małe, dobrze ograniczone zadanie, które działa bez nadzoru i daje coś, co przegląda człowiek. Tego wzorca szukaj: powtarzalne, sprawdzalne, mało ryzykowne w razie pomyłki i przydatne, gdy się uda.

Przebiegi bez nadzoru wymagają ściślejszych zabezpieczeń niż interaktywne, bo nikt nie obserwuje każdego kroku. Ogranicz narzędzia, z których agent może korzystać, do tego, czego wymaga zadanie. Daj mu możliwie najwęższe dane uwierzytelniające. Niech komentuje albo proponuje, zamiast scalać czy wdrażać. Traktuj treść pull requestów i zgłoszeń jako niezaufane wejście, bo każdy, kto może otworzyć pull request, może podsunąć agentowi tekst. Te środki ostrożności nie są skomplikowane, ale muszą być przemyślane.

Agent, który przegląda każdy pull request, nie wyłapie wszystkiego. Za to nigdy nie będzie zbyt zajęty, czego nie da się powiedzieć o reszcie zespołu.

Jako zlecenie jest to atrakcyjne zarówno w sprzedaży, jak i w realizacji. Zakres da się określić ciasno: skonfigurować automatyczny przegląd i notatki do wydań dla jednego repozytorium, przez tydzień dostrajać instrukcje na prawdziwych pull requestach zespołu, udokumentować, jak to działa i jak to dostosowywać, i przekazać. Rezultat widać na każdym pull requeście od pierwszego dnia. Tworzy to też naturalną kontynuację, bo kiedy zespół zobaczy agenta wykonującego pożyteczną pracę bez nadzoru, zaczyna sobie wyobrażać, co jeszcze mógłby robić.

Wypróbuj to w tym tygodniu na repozytorium, które kontrolujesz. Skonfiguruj nieinteraktywny przegląd pull requestów z ostrożnymi uprawnieniami, dostrój instrukcje na kilku prawdziwych zmianach i zobacz, co wyłapuje. Dowiesz się, jak wyglądają dobre instrukcje do pracy bez nadzoru, i będziesz mieć gotową demonstrację dla następnego zespołu programistów, który zapyta, co AI mogłoby dla niego zrobić.

Naprawa procesu

Złóż tę część w całość, a dostaniesz jedno z kluczowych mikrozleceń tej książki: naprawę procesu. Jeden bolesny, powtarzający się proces, zdiagnozowany, naprawiony z pomocą Claude Code, zweryfikowany i przekazany, w stałym zakresie i krótkim kalendarzu. Nie program transformacji. Nie migracja platformy. Jeden proces, który obecnie co tydzień marnuje godziny, a od teraz będzie marnował minuty.

Dobrzy kandydaci są wszędzie, jeśli się rozejrzysz. Miesięczny raport, który ktoś składa ręcznie z trzech eksportów. Skrypt, który umie uruchomić tylko jedna osoba i który się wysypuje, jeśli plik wejściowy ma dodatkową kolumnę. Formularz zapytań, którego zgłoszenia są kopiowane do arkusza, a potem wysyłane mailem do właściwej osoby przez tego, kto akurat zauważy. Porządkowanie danych, które odbywa się w każdy poniedziałek rano. Każdy z nich jest mały, konkretny, mierzalny i na tyle dokuczliwy, że klient chętnie zapłaci, by się go pozbyć.

Zlecenie podąża za ruchami z tej części. Najpierw diagnoza, w krótkiej rozmowie i przez obserwację, jak proces jest wykonywany. Przeczytaj repozytorium albo skrypty i arkusze, z których składa się obecny proces. Napisz plik pamięci. Zaplanuj zmianę i sprawdź plan z technicznym opiekunem po stronie klienta. Buduj małymi diffami, z weryfikacją na każdym kroku. Podłączaj tylko te systemy, które są niezbędne, z najwęższymi uprawnieniami. Jeśli pasuje, dodaj polecenie albo przebieg bez nadzoru, żeby proces dało się łatwo wywołać albo uruchamiać według harmonogramu. Potem przekaż całość z instrukcją obsługi, krótkim nagranym omówieniem i sesją z osobą, która przejmie opiekę.

Pomiar ma równie duże znaczenie jak budowa. Zanim zaczniesz, zmierz czas obecnego procesu albo poproś klienta o uczciwe oszacowanie i zanotuj, jak często coś idzie nie tak. Po przekazaniu zmierz ponownie. Różnica, wyrażona w kategoriach klienta – godziny miesięcznie, błędy na kwartał, uniknięte dni opóźnień – to wynik, który raportujesz, i dowód na rzecz kolejnego zlecenia. Naprawiony proces bez zmierzonego wyniku to miła przysługa. Naprawiony proces z „przed” i „po” to studium przypadku.

Napraw porządnie jedną rzecz, a klient pokaże ci pozostałe dziewięć.

Dyscyplina zakresu to wszystko. Naprawa procesu działa, bo dotyczy jednego procesu. Kiedy klient zobaczy, jak dobrze poszło, i zapyta o proces sąsiedni, to świetna wiadomość – i następne zlecenie, a nie rozszerzenie bieżącego. Dopisz to do listy. Wspomnij o tym na końcowej demonstracji. Wyceń osobno. Szereg małych, skończonych, zmierzonych napraw buduje znacznie więcej zaufania niż jeden rozlazły projekt, który nigdy do końca się nie kończy.

W tym tygodniu napisz jednostronicowy opis własnej oferty naprawy procesu: do jakich procesów pasuje, co zapewnia klient, co dostarczasz ty, jak długo to trwa, jak mierzy się sukces i co zwykle następuje potem. Potem rozejrzyj się we własnej praktyce za procesem, który mógłbyś naprawić w ramach treningu. Pierwszy naprawiony proces nauczy cię o zakresowaniu więcej niż jakikolwiek rozdział.

Skille wygrywają z promptami

Prompt to wiadomość. Skill to umiejętność. Różnica polega na tym, że prompt trzeba za każdym razem znaleźć, skopiować i wkleić, a skill siedzi w tle i ładuje się sam, kiedy zadanie tego wymaga. W chwili, gdy po raz drugi wklejasz Claude’owi te same instrukcje, potrzebowałeś skilla. Za piątym razem od dawna wykonujesz ręcznie pracę narzędzi.

W świecie Claude’a skill to folder zawierający krótki plik z instrukcjami, z nazwą i opisem na górze, oraz wszelkie potrzebne materiały pomocnicze: dokumenty referencyjne, szablony, przykłady, skrypty. Claude widzi nazwy i opisy dostępnych skilli, a kiedy zadanie pasuje, czyta pełne instrukcje i się do nich stosuje. Skille działają w aplikacjach Claude, w Claude Code i na platformie deweloperskiej, więc ta sama umiejętność może podróżować z tobą i twoimi klientami z jednej powierzchni na drugą.

Praktyczny efekt jest taki, że fachowość przestaje zależeć od pamięci. Wyobraź sobie konsultanta, który pisze raporty z audytu w określonej strukturze: z uszeregowaną tabelą szans, notką o ryzyku przy każdej pozycji i listą rzeczy odłożonych. Jako prompt ta struktura żyje w dokumencie, o którego wklejeniu trzeba pamiętać. Jako skill ładuje się za każdym razem, gdy poprosi Claude’a o napisanie raportu z audytu, razem z szablonem, dobrym przykładem i kryteriami punktacji. Instrukcje są stosowane konsekwentnie, czy to pierwszy raport w tygodniu, czy piętnasty, i niezależnie od tego, czy autor pamięta szczegóły.

Skille zmieniają też to, co konsultant może przekazać. Biblioteka promptów jest pomocna, ale zależy od tego, czy ludzie korzystają z niej poprawnie. Biblioteka skilli jest bliższa zestawowi przeszkolonych współpracowników: zespół klienta prosi zwykłymi słowami o podsumowanie dostawcy albo kontrolę zgodności, a właściwe instrukcje pojawiają się automatycznie. Zakodowana przez ciebie fachowość jest stosowana bez potrzeby, by ktokolwiek wiedział o jej istnieniu. To skokowa zmiana w tym, jak duża część twojej wartości przetrwa po twoim odejściu.

Prompt to rada, o której zastosowaniu trzeba pamiętać. Skill to rada, która zjawia się na czas.

Nie wszystko musi być skillem. Jednorazowe pytania, rozmowy eksploracyjne i zadania, które za każdym razem są naprawdę inne, mogą pozostać zwykłymi promptami. Skille zasługują na swoje miejsce przy powtarzalnej pracy o stabilnym kształcie: raportach, przeglądach, analizach, typach dokumentów, kontrolach, przekształceniach. Dobry test: czy potrafisz zapisać, jak wygląda znakomite wykonanie tego zadania, i czy ten opis utrzyma się przez kolejnych dwadzieścia razy. Jeśli tak, to jest skill, który czeka na napisanie.

W tym tygodniu wróć do swojej biblioteki promptów z części drugiej i znajdź trzy, których używasz najczęściej. Zamień jeden z nich w skill: folder, plik instrukcji z jasną nazwą i opisem oraz przykłady i szablony, których potrzebuje. Korzystaj z niego przez tydzień. Zwróć uwagę, czy uruchamia się wtedy, kiedy się tego spodziewasz, i czy wyniki są tak spójne, jak liczyłeś. Kolejne rozdziały mówią, jak sprawić, by jedno i drugie było niezawodne. Pierwszy krok to po prostu przestać wklejać.

Opis, który uruchamia

Skill, który nigdy się nie uruchamia, jest bezwartościowy. Instrukcje w środku mogą być nieskazitelne, szablony piękne, a przykłady idealnie dobrane, ale jeśli Claude nie rozpozna, kiedy go użyć, nic z tego nie ma znaczenia. Opis na górze pliku skilla to tekst, który Claude czyta, by podjąć decyzję, a to czyni go najważniejszym tekstem w całym skillu. To nie jest dokumentacja. To wyzwalacz.

Pomyśl, jak zapada ta decyzja. Claude widzi opisy dostępnych skilli obok prośby użytkownika. Jeśli opis wyraźnie pasuje do tego, o co prosi użytkownik, skill zostaje załadowany. Jeśli jest mglisty, ogólnikowy albo sformułowany słowami, których użytkownik nigdy by nie użył, skill leży nieużywany. Opis musi przerzucić most między tym, jak ty myślisz o skillu, a tym, jak ludzie naprawdę będą prosić o to, co on robi.

Pisz więc opisy językiem próśb. Powiedz, co skill robi i kiedy go używać, a potem dodaj dokładne sformułowania, synonimy i pokrewne prośby, które powinny go obudzić. Skill do pisania raportów z audytu może wspominać raporty z audytu, przeglądy gotowości na AI, oceny szans i prośby w rodzaju spisz wnioski z wywiadów. Skill do podsumowań dostawców może wspominać notatki o dostawcach, jednostronicowe profile dostawców i co wiemy o tym dostawcy. Prawdziwi użytkownicy mówią na wiele sposobów. Opis powinien przewidzieć większość z nich.

Równie ważne jest powiedzenie, kiedy skilla nie używać. Jeśli dwa skille obejmują sąsiednie terytoria, każdy opis powinien wyraźnie zaznaczać granicę: ten jest do audytów wstępnych, tamten do raportów postępu. Niejasne nakładanie się prowadzi do uruchomienia niewłaściwego skilla, co pod pewnymi względami jest gorsze niż brak jakiegokolwiek, bo wynik będzie pewny siebie i ukształtowany pod inne zadanie.

Opis to drzwi wejściowe. Nikt nie podziwia mebli w domu, którego nie umie znaleźć.

Testuj uruchamianie celowo. Spisz listę dziesięciu lub piętnastu próśb, które powinny wywołać skill, sformułowanych tak, jak sformułowaliby je różni ludzie, oraz kilka takich, które nie powinny. Wypróbuj je. Zanotuj, które chybiają, i poprawiaj opis, aż większość trafi. Zajmuje to może pół godziny na skill, a stanowi różnicę między biblioteką, która działa, a taką, którą ludzie porzucają po tygodniu, bo jest zawodna.

W pracy dla klienta zaangażuj w te testy ludzi, którzy będą korzystać ze skilla. Zapytaj, jak naturalnie poprosiliby o to zadanie, i użyj ich słów w opisie. Dział finansów może mówić paczka na koniec miesiąca tam, gdzie ty napisałbyś raport finansowy. Jeśli opis używa twojego słownictwa zamiast ich, skill uruchomi się dla ciebie podczas demonstracji, a zawiedzie ich później, a to najgorsza możliwa kolejność zdarzeń.

Weź skill, który napisałeś po poprzednim rozdziale, i przepisz jego opis, mając to wszystko na uwadze. Wypisz sposoby, w jakie ty i inni naprawdę prosicie o to zadanie, i wpleć je. Potem przetestuj go na tuzinie zróżnicowanych próśb. Prawdopodobnie znajdziesz kilka chybień. Napraw je, a skill przestanie być ciekawym eksperymentem i stanie się narzędziem, które zjawia się, kiedy jest potrzebne, a o to przecież chodziło.

Stopniowe odsłanianie

Kontekst jest skończony, a skille powinny to szanować. Skill, który przy każdym uruchomieniu wysypuje do rozmowy czterdzieści stron instrukcji, wypycha materiał, którego zadanie naprawdę potrzebuje. Lepszym projektem jest stopniowe odsłanianie: krótki plik główny, który obejmuje to, czego wymaga niemal każde użycie, a szczegółowe materiały referencyjne trzymane w osobnych plikach, które model czyta tylko wtedy, gdy wymaga tego konkretna sytuacja. Innymi słowy, instrukcje powinny być ewaluowane leniwie.

Skille są do tego stworzone. Dopóki skill nie zostanie uruchomiony, widoczne są tylko nazwa i opis. Potem czytany jest główny plik instrukcji. W tym pliku możesz wskazywać inne pliki w folderze skilla: przy klientach z regulowanego sektora finansowego przeczytaj materiał o zgodności przed pisaniem, jeśli użytkownik prosi o wersję w slajdach, trzymaj się szablonu z przewodnika po slajdach. Te pliki są czytane tylko wtedy, gdy warunek jest spełniony. Prosta prośba korzysta z głównych instrukcji; nietypowa dociąga dokładnie te szczegóły, których potrzebuje.

Ten projekt ma kilka zalet. Utrzymuje kontekst szczupłym, więc model poświęca należytą uwagę zadaniu, które ma przed sobą. Ułatwia utrzymanie skilla, bo każdy plik referencyjny ma jeden cel i może być aktualizowany niezależnie. I pozwala skillowi rozrosnąć się na wiele przypadków, nie stając się nieporęcznym, bo przypadki mieszkają we własnych plikach, zamiast piętrzyć się w jednym długim dokumencie, którego nikt nie chce czytać.

Napisanie dobrego pliku głównego to dyscyplina. Umieść w nim to, co ma zastosowanie zawsze: cel, główne kroki, format wyniku, poprzeczkę jakości. Pomiń wszystko, co ma zastosowanie tylko czasami, i zastąp to jasnym odsyłaczem. Niech będzie na tyle krótki, by dało się go przeczytać w kilka minut. Jeśli plik główny ciągle rośnie, poszukaj sekcji, które mają zastosowanie tylko w szczególnych okolicznościach, i przenieś je do materiałów referencyjnych.

Powiedz modelowi, czego potrzebuje zawsze. Powiedz mu, gdzie szukać reszty. A potem zaufaj, że poszuka.

Ta struktura szczególnie dobrze pasuje do pracy konsultanta, bo zlecenia u klientów różnią się w przewidywalny sposób. Główny skill do pisania raportów z audytu może mieć materiały referencyjne dla różnych branż, różnych długości raportu i różnych odbiorców. Jeden skill, wiele sytuacji, a w każdej pojawiają się właściwe szczegóły. Kiedy specjalizujesz się w jednej branży, materiał branżowy staje się skondensowanym zapisem wszystkiego, czego nauczyłeś się o tym rodzaju klienta, ładowanym tylko wtedy, gdy jest istotny.

Ułatwia to także przekazanie. Klient, który otrzymuje bibliotekę skilli, może jednym rzutem oka z pliku głównego zobaczyć, co robi każdy skill, a gdy zmieni się jego firma, znaleźć i zaktualizować konkretny materiał, który wymaga zmiany, nie ruszając reszty. Tak zorganizowany skill łatwiej zrozumieć, łatwiej mu zaufać i łatwiej przejąć nad nim opiekę.

W tym tygodniu przyjrzyj się swojemu najdłuższemu skillowi albo promptowi. Oznacz każdą sekcję jako potrzebną zawsze albo potrzebną czasami. Sekcje „czasami” przenieś do osobnych plików referencyjnych, z jasnym odsyłaczem w pliku głównym. Uruchom go na prostym przypadku i na nietypowym. Prosty przypadek powinien być szybszy i czystszy; nietypowy wciąż powinien dostać potrzebne szczegóły. Tak wygląda działający projekt.

Dołącz skrypty

Deterministyczna praca należy do kodu, nie do tokenów. Jeśli jakiś krok zadania zawsze działa tak samo – konwersja formatu pliku, walidacja struktury danych, obliczenie sumy, zmiana nazw plików według wzorca – model nie powinien za każdym razem wyprowadzać go od nowa. Dołącz skrypt do skilla i pozwól modelowi go wywołać. Model dostarcza osąd; skrypt dostarcza precyzję. Każde robi to, w czym jest dobre.

Skille mogą zawierać wykonywalne skrypty obok instrukcji. Kiedy skill działa w środowisku, w którym dostępne jest wykonywanie kodu, instrukcje mogą kazać Claude’owi uruchomić konkretny skrypt na konkretnym etapie: aby sprawdzić, czy eksport jest poprawny, uruchom skrypt walidacyjny i zgłoś wszelkie błędy, aby przygotować końcowy arkusz, uruchom skrypt budujący na oczyszczonych danych. Kod skryptu nie musi znajdować się w rozmowie; trafia do niej tylko jego wynik, co również utrzymuje kontekst szczupłym.

Zalety są znaczne. Skrypty są niezawodne: te same dane wejściowe za każdym razem dają ten sam wynik, bez szans na twórczą interpretację. Są szybkie i tanie, bo uruchomienie kilku linijek kodu kosztuje znacznie mniej niż przeprowadzenie modelu przez to samo przekształcenie krok po kroku. Da się je testować w zwykły sposób. I kodują precyzyjną logikę, taką jak konkretna reguła obliczeń albo ścisły format pliku, czyli dokładnie to, co model mógłby raczej przybliżyć niż odtworzyć.

Dla konsultantów zmienia to, co skill może dostarczyć. Skill, który przygotowuje miesięczny raport klienta, może zawierać skrypt pobierający liczby z eksportu, obliczający uzgodnione wskaźniki i budujący wykres, podczas gdy model pisze komentarz i sygnalizuje wszystko, co nietypowe. Skill, który sprawdza umowy pod kątem regulaminu, może zawierać skrypt wyodrębniający klauzule do ustrukturyzowanej postaci, zanim przejrzy je model. To połączenie jest bardziej niezawodne niż każda z części osobno i znacznie bardziej niezawodne niż proszenie modelu, by zrobił wszystko prozą.

Niech model decyduje, co zrobić. Niech kod robi te części, które za każdym razem muszą być zrobione dokładnie tak samo.

Skrypty może oczywiście napisać też Claude. Rozsądny wzorzec to obserwować, jak model wykonuje zadanie kilka razy, zauważyć, które kroki są mechaniczne, i poprosić go o napisanie dla nich skryptu, z testami. Potem zaktualizować skill, żeby ten skrypt wywoływał. Z czasem twoje skille gromadzą małe, dobrze przetestowane narzędzia, które z każdym zleceniem czynią je szybszymi i pewniejszymi.

Słowo ostrzeżenia przy przekazaniu klientowi: skrypty to kod, a kod potrzebuje opiekuna. Udokumentuj, co robi każdy skrypt, czego potrzebuje do działania i jak go przetestować. Ogranicz zależności do minimum. Jeśli zespół klienta nie jest w stanie utrzymywać kodu, wybieraj prostsze skrypty i zadbaj, by skill zawodził wyraźnie, z pomocnym komunikatem, gdy skrypt się zepsuje. Skill, który po cichu daje błędne wyniki, bo zawiódł skrypt, jest gorszy od takiego, który nawet nie próbuje.

W tym tygodniu znajdź w jednym ze swoich powtarzalnych zadań krok czysto mechaniczny. Poproś Claude’a o napisanie dla niego małego skryptu z testem i dołącz go do odpowiedniego skilla. Uruchom zadanie ponownie. Zauważ, o ile spójniejszy staje się ten krok. Potem poszukaj następnego.

Rozdzielanie na subagenty

Niektóre prace w naturalny sposób dzielą się na niezależne kawałki. Przejrzeć dwanaście umów z dostawcami. Streścić wywiady z ośmioma pracownikami. Przeanalizować pięć lat zgłoszeń do działu wsparcia, rok po roku. Robienie tego w jednej długiej rozmowie wypełnia kontekst szczegółami z każdego kawałka, więc zanim dotrzesz do ostatniego, model brnie przez wszystko, co było wcześniej. Lepszym wzorcem jest rozdzielenie: przekaż każdy kawałek subagentowi z czystym kontekstem, a wyniki niech zbierze orkiestrator.

W Claude Code subagenty to wyspecjalizowani asystenci, którym główny agent może delegować zadania. Każdy działa we własnym kontekście, z własnymi instrukcjami i własnym zestawem dozwolonych narzędzi, i zwraca podsumowanie, a nie całość swojej pracy. Główna rozmowa przechowuje plan i wyniki, a nie szum. Możesz zdefiniować własne subagenty do powtarzających się ról – recenzenta umów, autora streszczeń wywiadów, autora testów – każdy z ukierunkowanym briefem.

Ten wzorzec szczególnie dobrze pasuje do pracy audytowej. Podczas płatnego audytu możesz mieć tuzin transkrypcji wywiadów i stos dokumentów opisujących procesy. Rozdziel transkrypcje między subagenty, z których każdy przygotuje uporządkowane podsumowanie w tym samym formacie: tematy, bolączki, cytaty, sugerowane szanse. Potem niech orkiestrator albo ty dokonacie syntezy wszystkich podsumowań. Każda transkrypcja dostaje pełną uwagę; synteza dostaje czysty widok na wszystkie. To, co kiedyś było dniami czytania, staje się popołudniem przeglądania.

Kluczem do dobrego rozdzielania jest spójny brief dla wykonawców i spójny kształt ich wyników. Jeśli każdy subagent zwraca podsumowanie w innej strukturze, synteza staje się trudniejsza, a nie łatwiejsza. Zdefiniuj format wyniku precyzyjnie, najlepiej z przykładem, i niech będzie taki sam dla każdego wykonawcy. Daj każdemu wykonawcy tylko kontekst potrzebny do jego kawałka, plus ewentualne wspólne tło, i nic więcej.

Jeden agent trzymający wszystko to żongler. Orkiestrator z wykonawcami to kuchnia. Kuchnie karmią więcej ludzi.

Są koszty, które trzeba wyważyć. Każdy subagent zużywa własne zasoby, więc rozdzielanie błahych zadań to marnotrawstwo. Praca równoległa daje też równoległe błędy: jeśli brief ma wadę, dziedziczy ją każdy wykonawca. Przetestuj brief na jednym kawałku, zanim wyślesz go do dwunastu. I niech etap syntezy, wykonywany przez orkiestratora czy przez ciebie, uczciwie odnotowuje rozbieżności i luki między wynikami wykonawców, zamiast wygładzać je w fałszywie schludny wniosek.

Dla klientów rozdzielanie bywa niewidoczne, ale jego efekty już nie. To dzięki niemu dwutygodniowe zlecenie radzi sobie z ilością materiału, która kiedyś wymagałaby zespołu. Pojawia się ono też w systemach, które budujesz: pilotaż agenta przetwarzający partię dokumentów może pod spodem korzystać właśnie z tego wzorca. W tym tygodniu znajdź we własnej pracy zadanie, które dzieli się na niezależne kawałki. Napisz jeden brief, przetestuj go na jednym kawałku, potem rozdziel. Porównaj wynik, i czas, jaki to zajęło, z robieniem wszystkiego w jednej rozmowie.

Subagent weryfikator

Jeden agent buduje; drugi sprawdza, świeżym okiem i bez przywiązania do pracy. Samoocena jest słaba, u modeli i u ludzi. Autor wie, co miał na myśli, i wczytuje to w to, co napisał. Recenzent z czystym kontekstem i jasnymi kryteriami widzi tylko to, co naprawdę tam jest. Przegląd z pozycji przeciwnika, prowadzony w osobnym kontekście, to jeden z najskuteczniejszych ruchów jakościowych dostępnych komuś, kto pracuje w pojedynkę.

Ten wzorzec łatwo skonfigurować. Kiedy kończy się istotna część pracy – raport, zestaw zmian w kodzie, partia przetworzonych dokumentów – przekaż ją osobnemu subagentowi, którego jedynym zadaniem jest weryfikacja. Daj mu pierwotny brief, definicję ukończenia i kryteria oceny, i poproś o znalezienie problemów: twierdzeń niepopartych źródłem, pominiętych wymagań, niespójności, nieobsłużonych przypadków brzegowych, testów, które przechodzą z niewłaściwego powodu. Poproś, by był konkretny i przytaczał dowody. Potem sam przejrzyj jego ustalenia i zdecyduj, na które zareagować.

Niezależność weryfikatora jest tu sednem. Nie powinien widzieć rozumowania wykonawcy ani rozmowy, z której powstała praca, tylko samą pracę i kryteria. Wtedy argumenty wykonawcy nie mogą go przekonać. Ocenia wynik na podstawie jego zalet. W praktyce często wyłapuje rzeczy, które przeoczyli zarówno wykonawca, jak i ty, bo żadne z was nie potrafiło przestać widzieć tego, co zamierzało.

Przy materiałach dla klienta to tanie ubezpieczenie od najbardziej wstydliwego rodzaju porażki: pewnego siebie twierdzenia w raporcie, które okazuje się błędne. Przepuść każdy ważny dokument przez weryfikatora z instrukcją, by sprawdził każde twierdzenie faktograficzne względem dostarczonego materiału źródłowego i oznaczył te, które nie mają pokrycia. Przepuść każdą istotną zmianę w kodzie przez weryfikatora z testami, wymaganiami i instrukcją, by szukał tego, czego testy nie obejmują. Weryfikator czasem podniesie fałszywy alarm. To niewielka cena.

Wykonawca chce, żeby praca była dobra. Weryfikator chce tylko wiedzieć, czy jest. Potrzebujesz obu, w osobnych pokojach.

Weryfikatory mogą też być częścią systemów, które dostarczasz. Pilotaż agenta, który szkicuje odpowiedzi dla klientów, może zawierać krok weryfikacji sprawdzający każdy szkic pod kątem regulaminu, zanim zobaczy go człowiek, i oznaczający te, które wymagają bliższej uwagi. Dzięki temu ludzki przegląd jest szybszy i bardziej skupiony, a klient dostaje mierzalną warstwę jakości, którą widzi w działaniu. Ułatwia to też testy odbiorcze, bo kryteria weryfikatora służą jednocześnie za kryteria odbioru.

Bądź uczciwy co do ograniczeń. Weryfikator zbudowany na tym samym modelu może dzielić niektóre martwe pola wykonawcy i nie sprawdzi faktów, do których nie ma dostępu. To druga linia obrony, nie gwarancja. Twój własny przegląd i przegląd klienta pozostają niezbędne przy wszystkim, co ma znaczenie. W tym tygodniu weź następną istotną rzecz, którą wytworzysz, i przekaż ją świeżemu weryfikatorowi z kryteriami i instrukcją znalezienia problemów. Przeczytaj, co wróci, z otwartym umysłem. Możesz się lekko zirytować. Niemal na pewno wyjdziesz na tym lepiej.

Jeden skill, wiele uprzęży

Skill, który da się uruchomić tylko w jednym miejscu, to sprytna sztuczka. Skill, który da się uruchomić w aplikacji desktopowej, w Claude Code, w zautomatyzowanym potoku i przez platformę deweloperską, to aktywo, które procentuje. Przenośność zamienia dobrze napisany prompt w infrastrukturę i jest coraz łatwiejsza do osiągnięcia, bo skille mają wspólny format na wszystkich powierzchniach Claude’a.

Zobacz, jak jeden skill może wędrować przez zlecenie. Piszesz skill, który z zestawu eksportów przygotowuje cotygodniowe podsumowanie operacyjne klienta. Podczas sprintu wdrożeniowego uruchamiasz go w Claude Code, rozwijając go i testując. Kierownik operacyjny klienta używa go w aplikacji Claude w poniedziałkowe poranki. Później działa w zautomatyzowanym zadaniu, które przygotowuje podsumowanie, zanim ktokolwiek przyjdzie do pracy. Te same instrukcje, te same szablony, te same skrypty; trzy zupełnie różne sposoby ich wywoływania. Każde wprowadzone przez ciebie usprawnienie dociera do wszystkich trzech.

Pisanie z myślą o przenośności wymaga odrobiny staranności. Niech instrukcje będą niezależne od konkretnego interfejsu: nie zakładaj istnienia określonego przycisku ani określonego polecenia. Niech skrypty działają w standardowym środowisku przy minimalnych zależnościach. Opisz wprost dane wejściowe i wyjściowe, żeby skill działał niezależnie od tego, czy pliki dostarcza człowiek na czacie, czy automatycznie potok. A wszelkie wymagania specyficzne dla środowiska, takie jak wykonywanie kodu czy dostęp do sieci, zanotuj na górze, żeby osoba instalująca skill wiedziała, czego on potrzebuje.

Ma to znaczenie handlowe, nie tylko techniczne. Klient kupujący bibliotekę skilli chce, by działała dalej, w miarę jak dojrzewa jego korzystanie z AI. Dziś jego zespół może używać aplikacji Claude; za rok może mieć zautomatyzowaną połowę raportowania. Skille pisane z myślą o przenośności przechodzą razem z nim. Skille przyspawane do jednej powierzchni trzeba przepisać, a to albo koszt dla klienta, albo, jeśli źle je zbudowałeś, cichy wstyd dla ciebie.

Napisz raz, uruchamiaj wszędzie tam, gdzie dzieje się praca. Wszystko inne to przepisywanie, które zaplanowałeś, nawet tego nie zauważając.

Są oczywiście ograniczenia. Niektóre możliwości są dostępne tylko w określonych środowiskach, a niektóre zadania mają sens wyłącznie interaktywnie. Nie każdy skill musi działać wszędzie. Celem jest uniknięcie przypadkowego uwiązania, w którym skill działa tylko w jednym miejscu, bo nikt nie pomyślał o innych, a nie wciskanie każdego skilla w każdą uprząż wbrew zdrowemu rozsądkowi.

Przenośność służy też twojej własnej praktyce. Twoje osobiste skille – autor raportów z audytu, autor szkiców ofert, kreator studiów przypadku – są przydatniejsze, jeśli działają wszędzie, gdzie akurat jesteś: przy biurku w aplikacji, w terminalu podczas zlecenia programistycznego albo w telefonie między spotkaniami. W tym tygodniu weź jeden ze swoich skilli i wypróbuj go na drugiej powierzchni. Zanotuj, co się psuje, napraw to tak, by działał w obu miejscach, i zapisz wymagania na górze pliku skilla. Druga powierzchnia jest najtrudniejsza. Potem pozostałe zwykle idą już same.

Wersjonuj swój kanon

Skille dryfują. Ulepszasz jeden na laptopie, zapominasz skopiować zmianę do wspólnego folderu, poprawiasz inną kopię dla klienta, a trzy tygodnie później masz trzy wersje tego samego skilla, każdą nieco inną, i żadnej wyraźnie najnowszej. Kiedy coś pójdzie nie tak, debugujesz trzy różne prawdy. Lekarstwo jest mało efektowne i całkowicie skuteczne: umieść swoje skille w systemie kontroli wersji, traktuj jedno repozytorium jako kanon i świadomie z niego synchronizuj.

Oczywistym domem jest git. Każdy skill to folder; repozytorium mieści je wszystkie. Każda zmiana to commit z komunikatem wyjaśniającym dlaczego. Wydania można oznaczać tagami, więc możesz z pewnością powiedzieć, której wersji używa klient. Kiedy zmiana coś pogorszy, widzisz dokładnie, co się zmieniło, i możesz to wycofać. To podstawowa praktyka programistyczna, a dotyczy skilli, bo skille są w każdym istotnym sensie oprogramowaniem: instrukcjami i kodem, od których zależą inni ludzie i systemy.

Kanon daje ci też jasny proces dystrybucji. Zamiast ręcznie kopiować skille do każdego miejsca, w którym są używane, synchronizujesz je z repozytorium: na własne maszyny, do wspólnych lokalizacji skilli twojego zespołu, do środowiska każdego klienta. Wtyczki mogą łączyć skille, polecenia i inne rozszerzenia w pakiet, który instaluje się spójnie. Jakiegokolwiek mechanizmu używasz, zasada jest ta sama. Zmiany płyną na zewnątrz z jednego źródła. Nikt nie edytuje wdrożonej kopii i jej tak nie zostawia.

Biblioteki skilli klientów zasługują na własne repozytoria, oddzielone od twoich. Skille klienta zawierają jego kontekst, jego przykłady, a czasem jego poufne procesy. Powinny mieszkać tam, gdzie klient je kontroluje, a twoje skille ogólnego przeznaczenia mogą być w razie potrzeby dostarczane jako osobna, wersjonowana zależność. Ten podział chroni informacje klienta, utrzymuje twój kanon w czystości i jasno pokazuje, co do kogo należy, gdy zlecenie się kończy.

Jeśli nie potrafisz powiedzieć, która wersja działa, nie masz skilla. Masz plotkę.

Dziennik zmian pomaga wszystkim. Krótka notka na górze każdego skilla albo w repozytorium, zapisująca, co i dlaczego zmieniło się w każdej wersji, ułatwia zespołowi klienta zrozumienie aktualizacji, a tobie przypomnienie sobie, po co istnieje dana linijka. Wspiera też rozmowę o abonamencie: comiesięczna lista usprawnień skilli klienta to namacalny zapis stałej wartości.

Jest też aspekt testowy. Każdy skill może nieść niewielki zestaw przypadków testowych – danych wejściowych i oczekiwanych cech wyniku – które uruchamiasz przed oznaczeniem nowej wersji. Kiedy pojawia się nowy model, uruchom testy na całym kanonie i zobacz, które skille się poprawiają, które pozostają bez zmian, a które wymagają dostosowania. Tak zamieniasz aktualizacje modeli w usprawnienia, a nie w niespodzianki.

W tym tygodniu, jeśli twoje skille nie są jeszcze w repozytorium, umieść je tam. Jeden folder na skill, krótki dziennik zmian, pierwszy tag. Potem wybierz jedno miejsce, w którym używasz skilli, i spraw, by synchronizowało się z kanonem, zamiast trzymać własną kopię. To nudne popołudnie. Oszczędzi ci wielu zagmatwanych.

Skille jako rezultat

Klienci płacą za rezultaty, ale zatrzymują aktywa. Raport opisuje, co dałoby się zrobić. Zestaw promptów pomaga ludziom to robić. Biblioteka skilli robi za nich dużą część tej pracy, za każdym razem, w ich języku, według ich standardu. Przekazanie działającej biblioteki skilli jest warte więcej niż jakikolwiek raport, a do tego to zupełnie inny rodzaj rezultatu: nie porada dotycząca pracy, lecz trwała zdolność, która ją wykonuje.

Zlecenie na bibliotekę skilli zwykle zaczyna się tam, gdzie kończy się audyt albo zestaw promptów. Audyt zidentyfikował powtarzalne zadania; zestaw promptów dał zespołowi lepsze sposoby, by o nie prosić. Biblioteka skilli koduje najlepsze z tych zadań jako skille: każdy z opisem uruchamiającym sformułowanym słowami zespołu, głównymi instrukcjami, materiałami na nietypowe przypadki, przykładami znakomitych wyników, dołączonymi skryptami do kroków mechanicznych i przypadkami testowymi do kontroli jakości. Zespół prosi potem o pracę zwykłymi słowami i dostaje wynik spełniający standard, który uzgodnił z tobą.

Realizacja podąża za wzorcami z tej części. Zacznij od pięciu lub dziesięciu najcenniejszych powtarzalnych zadań, a nie od wszystkich, jakie przyjdą ci do głowy. Dla każdego zbierz prawdziwe przykłady i klienta definicję tego, co dobre. Napisz skill, przetestuj jego uruchamianie z ludźmi, którzy będą go używać, przetestuj wyniki na prawdziwych danych i dopracuj. Umieść bibliotekę w repozytorium kontrolowanym przez klienta, z dziennikiem zmian i krótkim przewodnikiem. Przeszkol zespół i wskaż wewnętrznego opiekuna, który może wprowadzać drobne zmiany i wie, kiedy zadzwonić do ciebie w sprawie większych.

Kształt ceny ma tu znaczenie, o czym mówi część ósma. Biblioteka skilli to aktywo, które będzie oszczędzać czas w każdym dniu roboczym, i powinna być wyceniana względem tej wartości, a nie godzin, które zajęło ci jej napisanie. Niektórzy konsultanci oferują też małą stałą współpracę polegającą na utrzymywaniu i rozbudowie biblioteki, w miarę jak zmienia się firma i poprawiają się modele. To uczciwa praca, bo skille naprawdę wymagają opieki, a do tego zamienia jednorazową dostawę w relację.

Raport czyta się raz. Skilla używa się każdego ranka. Wyceniaj odpowiednio i odpowiednio dostarczaj.

Na starcie trzeba rozstrzygnąć kwestię własności. Klient powinien być właścicielem skilli zbudowanych z jego kontekstu i przykładów. Ty możesz chcieć zachować prawo do ponownego wykorzystania ogólnych technik i uniwersalnych skilli, które wniosłeś do zlecenia. Powiedz to jasno w umowie. Większość klientów jest z takim układem w pełni pogodzona, gdy wyjaśni się go z góry, a nikt nie jest z nim pogodzony, gdy pojawia się po raz pierwszy przy przekazaniu.

Biblioteka skilli to także znakomity dowód. Każdy skill można zademonstrować, pokazać jego wynik i zmierzyć zaoszczędzony czas. Studium przypadku mówiące zbudowaliśmy osiem skilli, których zespół używa teraz codziennie, skracając przygotowanie raportu z dnia do godziny jest konkretne, wiarygodne i łatwe do wyobrażenia dla następnego potencjalnego klienta we własnej firmie.

W tym tygodniu wyobraź sobie, że twoje ostatnie zlecenie zakończyło się biblioteką skilli zamiast tego, co faktycznie dostarczyłeś. Jakie pięć skilli by zawierała? Zapisz nazwy i opisy. Jeśli przychodzą łatwo, właśnie zaprojektowałeś swoją następną ofertę.

Pilotaż agenta

Pilotaż agenta to najbardziej ambitne mikrozlecenie w tej książce i to, o które klienci pytają najczęściej. Słyszeli, że agenty potrafią wykonywać pracę, a nie tylko odpowiadać na pytania, i chcą wiedzieć, czy któryś mógłby wykonać część ich pracy. Pilotaż odpowiada na to pytanie w stałym czasie, na prawdziwej pracy, ze zmierzonym wynikiem. Zrobiony dobrze, jest najbardziej przekonującym zleceniem, jakie możesz sprzedać. Zrobiony źle, jest kosztowną demonstracją tego, dlaczego ludzie nie ufają słowu agent.

Wybierz zadanie starannie. Dobre zadanie na pilotaż jest częste, ograniczone i sprawdzalne. Wstępna selekcja przychodzących zapytań i szkicowanie pierwszych odpowiedzi. Uzgodnienie dwóch źródeł danych i zgłoszenie rozbieżności. Przetworzenie partii dokumentów od dostawców i wyodrębnienie kluczowych warunków do rejestru. Każde ma jasne dane wejściowe, jasny wynik i sposób stwierdzenia, czy wynik jest poprawny. Unikaj zadań, w których błędy są kosztowne i trudne do wykrycia albo w których sukces zależy od osądu, którego klient nie potrafi wyartykułować. Na takie przyjdzie czas później, jeśli w ogóle.

Prowadź pilotaż na prawdziwej pracy z niedawnej przeszłości, a nie na hipotetycznych przypadkach. Weź próbkę zapytań, dokumentów albo rekordów z zeszłego miesiąca, za zgodą klienta i przy odpowiednim obchodzeniu się z danymi, i pozwól agentowi je przetworzyć. Porównaj jego wyniki z tym, co faktycznie zrobił zespół, według kryteriów uzgodnionych z klientem z góry. Daje ci to uczciwy, konkretny, mierzalny obraz: jak często agent miał rację, gdzie się pomylił i ile czasu by zaoszczędził. Potem, jeśli wyniki to uzasadniają, uruchom go przez tydzień równolegle z bieżącą pracą, z człowiekiem zatwierdzającym każdy wynik.

Tu zbiega się wszystko, o czym mówi ta książka. Jasny brief i ograniczony format wyniku z części drugiej. Starannie dobrany kontekst i wiedza projektowa z części trzeciej. Uważna praca w repozytorium z części czwartej. Skille, skrypty, subagenty i weryfikator z tej części. Zabezpieczenia, ludzkie punkty kontrolne i ewaluacje z części siódmej. Pilotaż to nie jeden sprytny prompt. To mały, dobrze zaprojektowany system, przez który płynie prawdziwa praca klienta.

Pilotaż to eksperyment z hipotezą, metodą i wynikiem. Wszystko inne to demo z dłuższą fakturą.

Zanim zaczniesz, określ decyzję, którą pilotaż ma wesprzeć. Pytanie nie brzmi czy agenty działają?, tylko raczej czy agent potrafi naszkicować akceptowalne pierwsze odpowiedzi na większość rutynowych zapytań, z człowiekiem zatwierdzającym każdą z nich, istotnie skracając czas odpowiedzi? Określ próg, który uzasadniałby pójście dalej. Na końcu uczciwie zaraportuj względem niego. Czasem odpowiedź brzmi „nie” albo „jeszcze nie”, a jasne powiedzenie tego, z dowodami, buduje więcej zaufania niż naciągane „tak”.

Kiedy odpowiedź brzmi „tak”, następny krok jest oczywisty, a ty zaprojektowałeś go na początku: abonament na prowadzenie, monitorowanie i ulepszanie systemu albo sprint, który go rozszerzy. W tym tygodniu naszkicuj pilotaż agenta dla znanego ci klienta: zadanie, próbkę, kryteria oceny, próg, zabezpieczenia. Jeśli zmieścisz to na jednej stronie, możesz to sprzedać. Jeśli nie, pilotaż jest za duży. Zmniejszaj zadanie, aż się zmieści.

Demo jest prezentacją

Działający prototyp zamyka transakcje, które slajdy potrafią jedynie opisać. Pokaż kupującemu prezentację o tym, jak asystent mógłby segregować jego zapytania, a on uprzejmie pokiwa głową i zapyta o bezpieczeństwo. Pokaż mu asystenta segregującego pięć jego własnych zapytań, na ekranie, gdy patrzy, a rozmowa przesunie się z pytania „czy” na pytanie „kiedy”. Ludzie znacznie chętniej wierzą w to, co widzą, niż w to, co się im mówi, a z Claude’em pokazywanie jest dziś na tyle tanie, że można to zrobić, zanim ktoś ci zapłaci.

To prawdziwa zmiana w ekonomii sprzedaży. Kilka lat temu zbudowanie przekonującego prototypu zajmowało programiście kilka dni, co oznaczało, że stać cię było na to dopiero po tym, jak klient się zobowiązał. Dziś jednostronicowy interaktywny prototyp, mały działający skrypt albo realistyczną próbkę wyników da się przygotować w godzinę czy dwie. Koszt pokazania spadł poniżej kosztu wyjaśniania. Większość konsultantów nie dostosowała jeszcze do tego swojego procesu sprzedaży.

Prototyp nie musi być kompletny. Musi odpowiedzieć na prawdziwe pytanie kupującego, które zwykle brzmi w jakiejś wersji: czy to by u nas zadziałało? To znaczy, że powinien używać ich rodzaju danych, ich słownictwa i ich procesu, nawet jeśli działa w nim tylko jedna ścieżka. Demo, które przetwarza realistyczną wersję ich faktur, jest znacznie bardziej przekonujące niż dopracowane ogólne demo przetwarzające faktury kogoś innego. To konkret czyni je wiarygodnym.

Używaj demonstracji także jako narzędzia diagnostycznego. Kupujący, patrząc, będzie reagował: to dokładnie nasz problem, albo u nas to tak nie wygląda, albo co się stanie, gdy dostawca przyśle zeskanowany obrazek. Każda reakcja to informacja o prawdziwych wymaganiach, podana dobrowolnie i z entuzjazmem, a to rzadkie połączenie. Zapisuj. Połowa twojego dokumentu z zakresem prac powstanie z komentarzy, które kupujący rzuca, oglądając prototyp.

Slajdy proszą kupującego, by sobie wyobraził. Demo pozwala mu rozpoznać. Rozpoznanie jest szybsze.

Są uczciwe granice, których trzeba pilnować. Nigdy nie pozwól, by prototyp sugerował, że wersja produkcyjna jest gotowa. Powiedz jasno, co jest prawdziwe, co symulowane i czego by potrzeba, by całość była solidna. Kupujący, który później odkryje, że imponujące demo trzymało się na przykładowych danych i dobrych chęciach, nie zaufa twojej następnej wycenie. Kupujący, któremu powiedziano dokładnie, na co patrzy, zaufa ci bardziej za to, że byłeś wobec niego szczery.

Ta część książki dotyczy warsztatu budowania i dostarczania takich rzeczy: prototypów w jednym pliku, realistycznych danych, klikalnych ścieżek, skupionych artefaktów, udostępniania ich jako linków, zamieniania ich w materiały do zostawienia, weryfikowania i, na samym końcu, budowania podczas spotkania. Wszystko to służy tej samej zasadzie. W tym tygodniu przed następną rozmową sprzedażową przygotuj małą demonstrację zamiast dodatkowych slajdów. Użyj danych w rodzaju tych, które ma kupujący. Pokaż jedną działającą rzecz. Potem przestań mówić i obserwuj jego twarz. To w tym momencie naprawdę dokonuje się sprzedaż.

Prototypy w jednym pliku

Jeden plik, bez kroku budowania, działa wszędzie, gdzie da się go otworzyć. To ograniczenie jest sekretem szybkich prototypów. To w czasie przygotowań prototypy umierają: instalowanie frameworków, konfigurowanie narzędzi, podpinanie bazy danych, wdrażanie na serwer. Wszystko to w końcu będzie potrzebne, ale nic z tego nie jest potrzebne, by odpowiedzieć na pytanie, dla którego prototyp istnieje. Jeden plik omija to wszystko.

W praktyce oznacza to pojedynczą stronę HTML z wbudowanymi stylami i skryptami, pojedynczy komponent React, który da się wyrenderować jako artefakt w Claude, albo pojedynczy skrypt uruchamiany z wiersza poleceń. Claude bardzo dobrze sobie z tym radzi. Opisz narzędzie, dane, na których pracuje, i główną interakcję, a zwykle dostaniesz działającą pierwszą wersję w jednej odpowiedzi. O zmiany proś w rozmowie. W ciągu godziny możesz mieć coś, co wygląda i zachowuje się na tyle podobnie do prawdziwej rzeczy, by pokazać to klientowi.

Artefakty w Claude czynią to szczególnie wygodnym. Prototyp zbudowany jako artefakt można oglądać, wypróbowywać i dopracowywać w tym samym miejscu, w którym powstał, i opublikować jako stronę do udostępnienia. Możesz iterować z klientem podczas rozmowy: on sugeruje zmianę, ty o nią prosisz, prototyp aktualizuje się na jego oczach. Ograniczenie do jednego pliku sprawia, że każda zmiana jest szybka, a całość łatwa do zrozumienia.

Dyscyplina polega na tym, by nie pozwolić mu się rozrastać. Kiedy prototyp działa, kusi, by dokładać funkcje, aż stanie się prawie produktem – wciąż w jednym pliku, teraz liczącym kilka tysięcy linijek i niemożliwym do utrzymania. To pułapka. Zadaniem prototypu jest odpowiedzieć na pytanie, a potem zostać wyrzuconym albo porządnie przebudowanym. Kiedy klient powie „tak” i zacznie się prawdziwa budowa, zacznij wersję produkcyjną z odpowiednią strukturą, testami i wdrożeniem. Prototyp zachowaj jako punkt odniesienia dla tego, co klient zaakceptował.

Prototyp to argument, nie fundament. Buduj go na tyle szybko, żeby wyrzucenie go nie bolało.

Dla mikrokonsultantów nawyk jednego pliku ma jeszcze jedną zaletę: sam prototyp staje się przenośnym rezultatem. Klient może go otworzyć, przesłać dalej, pokazać przełożonemu, a nikt nie musi niczego instalować. Wiele małych zleceń – kalkulator, narzędzie do podejmowania decyzji, wewnętrzny panel nad stałym zbiorem danych – można dostarczyć jako dopracowany pojedynczy plik, który nigdy nie musi się rozrosnąć. Nie lekceważ tego, ile problemów biznesowych rozwiązuje dobrze zrobiona pojedyncza strona.

Ograniczenia pomagają też Claude’owi. Prośba o zbudowanie narzędzia w jednym pliku, bez zewnętrznych zależności poza kilkoma dobrze znanymi bibliotekami, daje skupiony, czytelny kod. Prośba o zbudowanie aplikacji bez żadnych ograniczeń daje coś rozlazłego. Powiedz mu, jakiego kształtu chcesz, a zbuduje pod ten kształt.

W tym tygodniu wybierz małe narzędzie, które od dawna zamierzałeś zbudować, dla siebie albo dla klienta, i zbuduj je z Claude’em jako jeden plik, za jednym posiedzeniem. Zmierz, ile to trwa. Większość ludzi jest zaskoczona i lekko poirytowana tym, jak długo to odkładała.

Fałszywe dane, prawdziwe wrażenie

Realistyczne dane przykładowe czynią prototyp przekonującym. Tekst zastępczy robi z niego makietę. Różnica nie jest kosmetyczna. Kiedy kupujący widzi demo wypełnione nazwiskami klientów, które wyglądają jak jego klienci, produktami, które wyglądają jak jego produkty, i liczbami z zakresu, z którym ma do czynienia, jego mózg przestaje oceniać narzędzie i zaczyna wyobrażać sobie korzystanie z niego. Kiedy widzi Klient A, Produkt 1, 123,45, pozostaje w trybie oceniania. Poświęć dziesięć minut na wygenerowanie danych, które wyglądają jak jego.

Z Claude’em nie wymaga to niemal żadnego wysiłku. Opisz firmę klienta, rodzaj rekordów, z którymi będzie pracować narzędzie, i kształt danych, a potem poproś o realistyczny syntetyczny zbiór danych: pięćdziesiąt zapytań takich, jakie dostaje małe biuro rachunkowe, rok zamówień wyspecjalizowanego dostawcy żywności, listę zgłoszeń do firmy programistycznej z wiarygodną mieszanką spraw pilnych i błahych. Poproś o realistyczną różnorodność, w tym kilka kłopotliwych przypadków. Wynik wygląda na tyle prawdziwie, by demo było wiarygodne, nie zawierając przy tym niczego prawdziwego.

Ten ostatni punkt ma znaczenie. Dane syntetyczne to właściwy domyślny wybór przy prototypach, zwłaszcza zanim zawrzesz umowę. Prawdziwe dane klienta niosą ze sobą obowiązki w zakresie ochrony danych, pytania o poufność i ryzyko kompromitującego wycieku, jeśli prototyp zostanie udostępniony szerzej, niż zamierzano. Dane syntetyczne, które oddają kształt i charakter prawdziwych, dają ci korzyść perswazyjną bez żadnego z tych ryzyk. Zaznacz wyraźnie, że są syntetyczne, a klient doceni tę staranność.

To w kłopotliwych przypadkach dane syntetyczne zarabiają na siebie. Prototyp, który obsługuje tylko czyste, typowe rekordy, będzie dobrze wyglądał i nikogo niczego nie nauczy. Dodaj zapytanie napisane wersalikami, zamówienie bez kodu pocztowego, zgłoszenie, które w rzeczywistości dotyczy dwóch problemów, fakturę w obcej walucie. Pokaż, jak prototyp sobie z nimi radzi albo nie radzi. Kupujący natychmiast rozpozna te przypadki z własnej pracy, a jego zaufanie do ciebie wzrośnie, bo widać, że rozumiesz, jak wyglądają prawdziwe dane.

Lorem ipsum mówi kupującemu, że nie myślałeś o jego firmie. Dobre fałszywe dane mówią mu, że myślałeś.

Jest tu też aktywo wielokrotnego użytku. Jeśli specjalizujesz się w jednej branży, zbuduj dla niej bibliotekę syntetycznych zbiorów danych: przykładowych klientów, typowych transakcji, popularnych rodzajów dokumentów, częstych przypadków brzegowych. Każdy nowy prototyp zaczyna się od tej biblioteki, lekko dopasowanej do konkretnego klienta. Z czasem twoje przykładowe dane po cichu zyskują autorytet, stając się portretem branży, który kupujący od razu rozpoznają.

Kiedy zlecenie się zacznie i na podstawie odpowiednich umów pojawią się prawdziwe dane, szybko przetestuj na nich prototyp. Dane syntetyczne, choćby najlepsze, coś przeoczą. Prawdziwe dane będą zawierać wzorzec, którego nikt nie przewidział. Znalezienie go wcześnie jest tanie; znalezienie go przy przekazaniu – nie.

W tym tygodniu weź dowolny prototyp albo demo, jakie masz, i zastąp dane zastępcze realistycznymi danymi syntetycznymi dla konkretnego rodzaju klienta. Dodaj pięć kłopotliwych przypadków. Pokaż to komuś z tej branży i obserwuj, czy zacznie mówić o narzędziu, czy o własnej pracy. Jeśli o własnej pracy, dane spełniają swoje zadanie.

Od zrzutu ekranu do specyfikacji

Obrazek interfejsu, którego chcesz, jest wart zaskakująco wielu słów. Klientom często trudno opisać tekstem, czego potrzebują, ale zwykle potrafią na coś wskazać: zrzut ekranu narzędzia, które lubią, zdjęcie szkicu z tablicy, stronę z produktu konkurencji, układ arkusza, którego używają od lat. Wklej obrazek do Claude’a, wyjaśnij, co ma robić, i pozwól modelowi napisać implementację. Wizualne briefy likwidują całą rundę niejasności projektowych.

Claude dobrze czyta obrazy: układy, etykiety, tabele, odręczne szkice i zrzuty ekranu z adnotacjami. Daj mu zrzut ekranu obecnego arkusza klienta i poproś o proste narzędzie internetowe, które wykonuje tę samą pracę, z walidacją i widokiem podsumowania. Daj mu zdjęcie tablicy z prostokątami i strzałkami i poproś o działający prototyp tego przepływu. Daj mu zrzut ekranu panelu, który klient podziwia, i poproś o taki sam w strukturze, ale z jego danymi i w jego kolorach firmowych. Pierwsza wersja nie będzie idealna, ale będzie rozpoznawalnie tym, o co mu chodziło, a to jest najtrudniejsza część.

Sprawdza się to dobrze podczas rozmów. Poproś klienta, by udostępnił ekran i pokazał ci, jak dziś wykonuje dane zadanie. Zrób zrzut ekranu, za jego zgodą. Po rozmowie, albo w jej trakcie, jeśli czujesz się pewnie, użyj go jako briefu do prototypu. Klient widzi własny proces odbity z powrotem jako lepsze narzędzie, a rozmowa od razu staje się konkretna. Ten przycisk powinien być tutaj. Ta kolumna jest niepotrzebna. Czy da się sortować po dacie? Każdy komentarz jest precyzyjny, bo jest coś precyzyjnego do skomentowania.

Zrzuty ekranu pomagają też w drugą stronę. Kiedy omawiasz prototyp z klientem asynchronicznie, poproś go, by zrobił zrzut ekranu tego, co chce zmienić, i dodał adnotację. Zrzut z kółkiem i słowami zrób to większe jest znacznie jaśniejszy niż akapit opisu, a Claude może na jego podstawie działać bezpośrednio. Pętla informacji zwrotnej się skraca i oboje spędzacie mniej czasu na interpretowaniu się nawzajem.

Ludzie nie zawsze potrafią powiedzieć, czego chcą. Niemal zawsze potrafią to wskazać palcem.

Pamiętaj o poufności. Zrzuty ekranu systemów klienta mogą zawierać nazwiska klientów, liczby albo inne wrażliwe informacje. Zanim udostępnisz obrazy jakiemukolwiek narzędziu, przytnij albo rozmyj to, co niepotrzebne, i upewnij się, że narzędzia, z których korzystasz, zostały zaakceptowane przez klienta. Traktuj zrzuty ekranu z taką samą starannością jak wszelkie inne dane klienta.

Pamiętaj też o granicy między inspiracją a kopiowaniem. Używanie produktu konkurencji jako punktu odniesienia dla układu i przepływu to normalna praktyka. Odtwarzanie jego charakterystycznego wyglądu, oznaczeń marki czy treści – już nie. Celem jest uchwycenie tego, czego klient chce od interfejsu, a nie sklonowanie cudzej pracy.

W tym tygodniu, następnym razem gdy klient albo współpracownik opisze ci interfejs słowami, poproś go, by zamiast tego coś ci pokazał: zrzut ekranu, szkic, stronę, która mu się podoba. Użyj tego jako briefu. Porównaj wynik z tym, co zbudowałbyś na podstawie samego opisu. Przy czymkolwiek wizualnym rzadko wrócisz już do briefów wyłącznie tekstowych.

Klikalny prototyp

Półprawdziwe wygrywa z w pełni wyobrażonym. Prototyp, w którym trzy ścieżki naprawdę działają, a wszystko inne to wyraźnie oznaczone zaślepki, odpowiada na więcej pytań niż jakikolwiek dokument specyfikacji. Specyfikacje opisują zamiary, a zamiary są nieskończenie elastyczne. Działająca ścieżka jest uparta: albo robi to, czego potrzebuje klient, albo widocznie tego nie robi, a ta widoczność jest dokładnie tym, co czyni ją użyteczną.

Wybierz te trzy ścieżki starannie. Powinny to być drogi najważniejsze dla decyzji klienta: najczęstsze zadanie, najbardziej uciążliwe zadanie i zadanie, w którym nowe podejście najbardziej różni się od starego. W narzędziu do segregowania zapytań może to być skierowanie rutynowego zapytania, obsługa pilnej reklamacji i poradzenie sobie z zapytaniem, które nie pasuje do żadnej kategorii. Niech te trzy działają od początku do końca, z realistycznymi danymi i prawdziwą logiką. Wszystko inne – ustawienia, raporty, zarządzanie użytkownikami – może być zaślepką, która mówi, co by robiła.

To działające ścieżki dźwigają ciężar rozmów z klientem. Klient może sam wypróbować najczęstsze zadanie i ocenić, czy wydaje się szybsze. Może zobaczyć, jak oznaczany jest pilny przypadek, i zdecydować, czy próg jest właściwy. Może przyjrzeć się kłopotliwemu przypadkowi i powiedzieć ci, co dziś robi w takiej sytuacji jego zespół. To decyzje, które kształtują prawdziwą budowę, a podejmuje się je znacznie pewniej z czymś klikalnym niż z dokumentem pełnym założeń.

Zaślepki powinny być uczciwe. Oznacz je wyraźnie, z krótką notką o tym, co robiłaby gotowa wersja i mniej więcej ile pracy to wymaga. Zapobiega to klasycznemu nieporozumieniu, w którym klient widzi dopracowany ekran i zakłada, że działa. Daje ci też naturalny sposób, by rozmawiać o zakresie: oto trzy ścieżki, które udowodniliśmy, oto zaślepki – które z nich mają znaczenie dla pierwszego wydania, a które mogą poczekać?

Specyfikacja to obietnica dotycząca przyszłości. Działająca ścieżka to dowód dotyczący teraźniejszości. Kupujący wolą dowody.

Z Claude’em zbudowanie klikalnego prototypu jest na tyle szybkie, że mieści się w audycie albo przed rozpoczęciem sprintu. Zacznij od podejścia z jednym plikiem, dodaj realistyczne dane z poprzednich rozdziałów, starannie zaimplementuj trzy ścieżki, a resztę zaślep. Dzień pracy, często mniej, daje coś, co znacząco zmniejsza ryzyko dwutygodniowej budowy. Niektórzy konsultanci rutynowo dołączają klikalny prototyp do każdej prezentacji wyników audytu, tak że najważniejsza rekomendacja przychodzi nie jako akapit, lecz jako coś, co klient może wypróbować.

Uważaj, by prototyp nie kształtował oczekiwań co do nakładu pracy. Ścieżka, której prototyp zajął godzinę, może wymagać dni, by zbudować ją solidnie, z obsługą błędów, zabezpieczeniami, integracją i testami. Powiedz to. Prototyp pokazuje, co narzędzie będzie robić, a nie ile czasu zajmie uczynienie go niezawodnym.

W tym tygodniu weź pomysł, który dotąd opisywałeś słowami, i zbuduj trzy działające ścieżki z zaślepkami w miejsce reszty. Pokaż to komuś, kto by z tego korzystał. Policz decyzje, które podejmie w ciągu pierwszych dziesięciu minut. Potem wyobraź sobie, ile spotkań byłoby trzeba, by dojść do tych samych decyzji na podstawie dokumentu. Do tej właśnie luki służą klikalne prototypy.

Jeden artefakt na jedno pytanie

Oprzyj się mega-aplikacji. Kiedy budujesz coś dla klienta, kusi, by było wszechstronne: panel z dziewięcioma zakładkami, każdym wskaźnikiem, każdym filtrem, każdym widokiem, jakiego ktokolwiek mógłby kiedykolwiek chcieć. Przy przekazaniu wzbudza podziw, wszyscy dodają go do zakładek, a potem po cichu idzie w zapomnienie, bo nikt nie potrafi znaleźć w nim tej jednej rzeczy, której naprawdę potrzebuje. Skupiony artefakt, który odpowiada na dokładnie jedno pytanie biznesowe, jest używany co tydzień, latami.

Zacznij od pytania, nie od danych. Którzy klienci mogą nie przedłużyć umowy w tym kwartale? Które faktury od dostawców czekają na zatwierdzenie po terminie? Jak czasy odpowiedzi w tym tygodniu wypadają na tle zeszłotygodniowych? Każde pytanie ma odbiorców, częstotliwość i związaną z nim decyzję. Zbuduj narzędzie, które jasno odpowiada na to pytanie, dla tych odbiorców, z tą częstotliwością, i ułatwia tę decyzję. Wszystko inne pomiń. Jeśli ktoś potrzebuje odpowiedzi na inne pytanie, zbuduj inny artefakt.

Skupione artefakty łatwiej zbudować, przetestować, wyjaśnić i utrzymać. Z Claude’em każdy z nich to krótki, zamknięty kawałek pracy: jedno źródło danych, jeden widok, jedna czy dwie interakcje. Każdy łatwo zweryfikować, bo wiesz dokładnie, jak wygląda poprawny wynik. I każdy łatwo przekazać, bo jego cel jest oczywisty z samego tytułu. Klient z sześcioma małymi narzędziami, z których każde odpowiada na jedno pytanie, jest obsłużony znacznie lepiej niż klient z jednym narzędziem, które próbuje odpowiedzieć na wszystkie.

To także znakomite mikrozlecenia. Klient z pytaniem, na które nie może łatwo odpowiedzieć na podstawie istniejących systemów – czyli większość klientów – może kupić skupione narzędzie, które na nie odpowiada. Zakres jest jasny, dostawa szybka, a wartość oczywista od pierwszego użycia. Seria takich narzędzi, z których każde zajmuje się innym pytaniem, buduje relację po jednym małym zwycięstwie naraz, a to dokładnie ten wzorzec, który rekomenduje ta książka.

Panel, który odpowiada na wszystko, nie odpowiada na nic konkretnego. Zbuduj ten, który odpowiada na poniedziałkowe pytanie.

Nazwij każdy artefakt od jego pytania. Ryzyko nieprzedłużenia w tym kwartale to lepszy tytuł niż Panel analityki klientów, bo mówi użytkownikowi, czego się dowie, zanim jeszcze go otworzy. Dyscyplina nazewnictwa utrzymuje cię też w uczciwości: jeśli nie potrafisz nazwać artefaktu od jednego pytania, to pewnie próbuje odpowiedzieć na kilka i należy go podzielić.

Jest tu też kwestia projektowa. Kiedy artefakt odpowiada na jedno pytanie, jego układ można zbudować wokół odpowiedzi: kluczowa liczba na górze, szczegóły pod nią, wezwanie do działania na dole. Kiedy odpowiada na wiele, układ trzeba zbudować wokół nawigacji, i dlatego tak wiele paneli przypomina raczej menu niż odpowiedzi.

W tym tygodniu przyjrzyj się dowolnemu panelowi albo raportowi, którego ty lub klient regularnie używacie. Ustal jedno pytanie, na które ludzie naprawdę chcą znaleźć odpowiedź, otwierając go. Zbuduj artefakt o jednym przeznaczeniu, który odpowiada tylko na to pytanie, możliwie jak najjaśniej. Postaw go obok oryginału i zobacz, który zostanie otwarty w następny poniedziałek.

Link wygrywa z załącznikiem

Adres URL wygrywa z załącznikiem. Wyślij prototyp jako plik, a będzie leżał w skrzynce, czekając, aż ktoś go pobierze, znajdzie właściwą aplikację do otwarcia i zacznie się zastanawiać, czy jest bezpieczny. Wyślij go jako link, a klient może go otworzyć na telefonie w taksówce, przesłać koledze, pokazać szefowi na korytarzu. Przestaje być demem i zaczyna być czymś, co istnieje, a o rzeczach, które istnieją, się rozmawia.

Narzędzia do tego są dziś zwyczajne. Artefakty w Claude można publikować jako prywatne strony i udostępniać konkretnym osobom. Proste usługi hostingu statycznego pozwalają umieścić jednoplikowy prototyp w sieci w kilka minut. Przy zleceniach programistycznych wdrożenie podglądowe gałęzi daje klientowi link do pracy w toku. Jakakolwiek droga, cel jest ten sam: umieść pracę tam, gdzie klient sięgnie do niej jednym dotknięciem, na jakimkolwiek urządzeniu akurat trzyma.

Linki zmieniają pętlę informacji zwrotnej. Klient z linkiem częściej zagląda do prototypu i pokazuje go większej liczbie osób. Komentarze przychodzą szybciej i od szerszej grupy, w tym od ludzi, których nigdy nie spotkałbyś na formalnych spotkaniach. Czasem to faktyczni użytkownicy, którzy zauważają rzeczy, których nie zauważył kupujący. Czasem to osoba, która podpisuje budżet, a teraz ma konkretny powód, by zatwierdzić następny etap. Link wędruje przez organizację tak, jak załącznik nigdy nie wędruje.

Starannie przemyśl kwestię dostępu. Prototyp z danymi syntetycznymi można zwykle udostępniać dość swobodnie. Taki, który dotyka prawdziwych danych, wymaga porządnej kontroli dostępu: domyślnie prywatny, udostępniany tylko wskazanym osobom, w razie potrzeby za uwierzytelnianiem klienta. Nigdy nie umieszczaj prawdziwych danych klienta pod publicznym linkiem dla wygody. Szybkość udostępniania jest zaletą tylko wtedy, gdy otrzymują go właściwi ludzie.

Załącznik czeka, aż ktoś go otworzy. Link jest już otwarty, w czyjejś ręce, pokazywany komuś, kogo nigdy nie spotkałeś.

Jest w tym też profesjonalny szlif. Link do czystego, działającego prototypu, zatytułowanego nazwą klienta i pytaniem, na które odpowiada, sygnalizuje kompetencje skuteczniej niż jakakolwiek prezentacja możliwości. Mówi, że budujesz rzeczy i je kończysz. Dla mikrokonsultanta, którego cała oferta opiera się na szybkim, widocznym dostarczaniu, ten sygnał jest wart bardzo wiele.

Prowadź ewidencję tego, co udostępniłeś. Prosta lista aktywnych linków, z informacją, kto ma dostęp i kiedy każdy należy wycofać, oszczędza późniejszego zamieszania. Prototypy pozostawione w sieci bezterminowo mogą sprawiać kłopoty: nieaktualne wersje mylone z bieżącymi albo demo traktowane jak narzędzie produkcyjne. Kiedy zlecenie się kończy, wycofaj linki do prototypów albo wyraźnie oznacz je jako archiwalne.

W tym tygodniu weź coś, co normalnie wysłałbyś jako załącznik – prototyp, raport, małe narzędzie – i udostępnij to jako link, z odpowiednimi ustawieniami dostępu. Zauważ, jak szybko przychodzą odpowiedzi i od kogo. Może się okazać, że twoją pracą zajmują się ludzie, którzy nigdy nie otworzyliby pliku.

Materiał do zostawienia

Niektórzy wciąż chcą czegoś, co mogą wziąć do ręki, a przynajmniej czegoś, co mogą odłożyć do teczki. Członek zarządu, który drukuje materiały przed spotkaniami. Dyrektor finansowy, który trzyma segregator z każdą ofertą. Klient, który chce przesłać twoje wnioski spółce matce, a ta nie przyjmuje linków. Dla nich potrzebujesz materiału do zostawienia: schludnego dokumentu, który broni się sam, kiedy już wyjdziesz z pokoju. Dobra wiadomość jest taka, że rzadko potrzebujesz do tego osobnego narzędzia projektowego.

Arkusz stylów do druku w przeglądarce zamienia każdy artefakt internetowy w porządny dokument. Kilka reguł mówiących stronie, jak ma się ułożyć po wydrukowaniu – ukryj nawigację i przyciski, ustaw marginesy, unikaj podziałów stron w niezręcznych miejscach, użyj kolorów przyjaznych drukowi – a ten sam artefakt, który działa jako interaktywne narzędzie, drukuje się jako profesjonalny raport. Zapisz go jako PDF z przeglądarki i masz materiał do zostawienia bez dodatkowego potoku eksportu i bez dodatkowej zależności do utrzymania. Claude może napisać ci style druku w jednej prośbie.

Dla konsultantów ma to znaczenie, bo scala dwa rezultaty w jeden. Nie budujesz już prototypu, by potem osobno pisać o nim raport. Budujesz jeden artefakt, który na ekranie jest interaktywny, a na papierze jest dokumentem. W ten sposób mogą działać prezentacje wyników audytu, studia przypadku, oferty i przewodniki przekazania. Klient dostaje wersję na żywo do eksplorowania i statyczną do archiwizacji, a one zawsze się zgadzają, bo są tą samą rzeczą.

Projektuj wersję drukowaną świadomie, a nie na doczepkę. Umieść na górze wyraźny tytuł, nazwę klienta i datę. Zadbaj, by najważniejsza treść znalazła się na pierwszej stronie, dla czytelnika, który nigdy jej nie odwraca. Dodaj tyle wyjaśnień, by dokument miał sens bez ciebie w roli narratora. Jeśli wersja interaktywna wymaga najechania kursorem albo kliknięcia, by odsłonić informacje, upewnij się, że te informacje są widoczne w druku.

Spotkanie się kończy. Dokument zostaje na biurku i przedstawia twoje argumenty pod twoją nieobecność.

Materiały do zostawienia to także trwały marketing. Dobrze zrobione podsumowanie audytu albo studium przypadku, wydrukowane lub zapisane jako PDF, krąży po organizacji klienta, a czasem i poza nią. Niesie twoje nazwisko, twoją metodę i twoje wyniki do pokojów, do których nigdy nie wejdziesz. Niech to będzie coś, z czego byłbyś dumny, gdyby przeczytał to ktoś obcy.

Utrzymuj spójną markę i dyskretny profesjonalizm. Prosty, czytelny układ z twoim nazwiskiem i danymi kontaktowymi w stopce w zupełności wystarczy. Unikaj ciężkich ozdobników, które źle wyglądają w czerni i bieli. Unikaj umieszczania w materiale do zostawienia czegokolwiek, co byłoby niezręczne, gdyby trafiło do niewłaściwej osoby, bo prędzej czy później trafi.

W tym tygodniu weź artefakt, który zbudowałeś, i dodaj do niego arkusz stylów do druku. Wydrukuj go albo zapisz jako PDF i przeczytaj tak, jak przeczytałby go obcy. Popraw to, co samo się nie broni. Potem uczyń style druku częścią swojego standardowego podejścia, tak by każdy dostarczany artefakt miał materiał do zostawienia wbudowany od początku.

Sprawdź, zanim ogłosisz

Nigdy nie mów, że działa, dopóki tego nie uruchomiłeś. Dowód przed twierdzeniem to różnica między zaufanym wykonawcą a takim, do którego po cichu przestaje się dzwonić. Przy szybkim dostarczaniu z pomocą AI pokusa przedwczesnego ogłoszenia sukcesu jest silna: agent mówi, że zmiana jest gotowa, kod wygląda dobrze, demo za dziesięć minut. Oprzyj się. Uruchom to. Spójrz na wynik. Wtedy i dopiero wtedy powiedz, że działa.

Modele są elokwentne i pewne siebie, co pod wieloma względami jest przydatne, a pod tym jednym – niebezpieczne. Agent, który wprowadził zmianę, często zgłasza, że zadziałała, czasem zanim faktycznie to sprawdzi, czasem na podstawie kontroli, która nie testowała właściwej rzeczy. To nie nieuczciwość; to natura narzędzia. Twoim zadaniem jest domagać się dowodów: wyniku testów, zrzutu ekranu działającej strony, rezultatu uruchomienia skryptu na prawdziwych danych. Jeśli dowodu nie ma, twierdzenie nie jest jeszcze prawdziwe.

Dotyczy to ze szczególną siłą wypowiedzi kierowanych do klienta. Kiedy mówisz klientowi, że proces jest naprawiony, prototyp radzi sobie z jego przypadkami brzegowymi albo pilotaż agenta osiągnął określoną trafność, stawiasz na to twierdzenie swoją reputację. Jedno fałszywe twierdzenie, odkryte później, przekreśla mnóstwo dobrej pracy. Nawyk pokazywania dowodów – oto przebieg, oto wyniki, oto przypadek, w którym się pomylił – buduje reputację, którą bardzo trudno podważyć.

Uczyń weryfikację widoczną. Podczas demonstracji, gdzie to praktyczne, uruchamiaj rzecz na żywo, zamiast pokazywać nagranie. W raportach zamieszczaj dowody: przypadki testowe, wyniki punktowe, pomiary przed i po. W aktualizacjach statusu wyraźnie odróżniaj to, co zostało zweryfikowane, od tego, co wciąż jest sprawdzane. Klienci zauważają różnicę między konsultantem, który mówi powinno działać, a takim, który mówi działa; oto przebieg.

Pewność siebie jest za darmo. Dowód kosztuje kilka minut. Tylko jedno z nich przetrwa zetknięcie z prawdziwymi danymi klienta.

Weryfikacja chroni cię też przed samym sobą. Najniebezpieczniejszy moment każdej dostawy to chwila, gdy jesteś zmęczony, termin jest blisko, a agent mówi, że wszystko w porządku. Właśnie wtedy najbardziej kusi, by mu uwierzyć. Prosta osobista zasada – nic nie trafia do klienta, dopóki nie zobaczę, jak działa – zdejmuje decyzję z barków zmęczonej chwili. Nie musisz oceniać, czy sprawdzić. Po prostu sprawdzasz.

Tam, gdzie się da, wbudowuj weryfikację w same narzędzia. Prototypy z widocznym autotestem. Procesy, które zapisują w dzienniku, co zrobiły i czy się udało. Agenty, które raportują wyniki z dołączonymi dowodami. Dzięki temu weryfikacja jest łatwa dla ciebie i dla klienta po twoim odejściu. System, który pokazuje własne dowody, to system, któremu ludzie ufają.

W tym tygodniu przed każdym ogłoszeniem sukcesu, sobie czy klientowi, zatrzymaj się i zapytaj, jaki dowód widziałeś. Jeśli odpowiedź brzmi „żaden”, idź go zdobyć. Będzie to kosztować minuty. W ciągu roku oszczędzi ci przynajmniej jednej bardzo niezręcznej rozmowy, a pewnie kilku.

Dostarcz podczas spotkania

Wprowadzanie zmiany na żywo, gdy klient patrzy, to najskuteczniejszy pojedynczy ruch sprzedażowy dostępny komuś, kto działa w pojedynkę. Natychmiast przełamuje sceptycyzm. Kupujący, który wątpił, czy AI może pomóc z jego problemem, patrzy, jak bierzesz jego prawdziwy przykład, opisujesz zmianę zwykłymi słowami i w ciągu kilku minut na ekranie pojawia się działający wynik. Żadna prezentacja nie może z tym konkurować. To najczystsza demonstracja wszystkiego, czego dowodzi ta książka.

Działa, bo usuwa naraz każdą warstwę wątpliwości. Kupujący widzi, że narzędzie jest prawdziwe, a nie wyreżyserowane na nagraniu. Widzi, że działa na jego rodzaju problemu, a nie na starannie wybranym przykładzie. Widzi, jak szybko następuje zmiana, co przestawia jego wyobrażenie o tym, co mógłby osiągnąć dwutygodniowy sprint. I widzi, jak pracujesz, spokojnie i kompetentnie, a to właśnie jest to, o czego zakupie naprawdę decyduje.

Przygotowanie sprawia, że wygląda to na bezwysiłkowe. Przed spotkaniem zbuduj rusztowanie: jednoplikowy prototyp z realistycznymi danymi, skill z właściwymi instrukcjami, projekt z już załadowanym odpowiednim kontekstem. Przećwicz zmianę, której się spodziewasz, żeby wiedzieć, że działa. Potem, na spotkaniu, zaproś kupującego, by sam zaproponował zmianę, w obszarze, który przygotowałeś. On czuje, że ma kontrolę; ty stąpasz po znanym gruncie. Kiedy zaproponuje coś nieoczekiwanego, spróbuj uczciwie. Jeśli zadziała, wspaniale. Jeśli nie, powiedz to wprost i zanotuj jako coś do zbadania. Uczciwość pod presją robi większe wrażenie niż bezbłędny występ.

Ryzyka są realne i do opanowania. Demonstracje na żywo mogą zawieść: usługa działa wolno, zrywa się połączenie, model obiera nieoczekiwane podejście. Miej gotowy plan awaryjny, na przykład nagranie albo przygotowaną wersję wyniku, ale sięgaj po niego tylko wtedy, gdy próba na żywo naprawdę zawiedzie. I nigdy nie buduj na żywo na prawdziwych danych klienta, chyba że pozwala na to umowa i jego systemy. Bezpiecznym domyślnym wyborem są dane syntetyczne odzwierciedlające jego rzeczywistość.

Najbardziej przekonujące zdanie w konsultingu nie jest zdaniem. To działająca zmiana, która pojawiła się, gdy patrzyli.

Ten ruch działa też w trakcie zleceń, nie tylko w sprzedaży. Podczas piątkowej demonstracji wprowadź na żywo drobną zmianę, o którą prosi klient. Podczas szkolenia zbuduj coś pożytecznego na podstawie sugestii uczestnika. Za każdym razem pokazujesz, że zmiana jest tania i szybka, co zachęca klientów do proszenia o usprawnienia, zamiast tolerowania problemów. To dobre dla nich i bardzo dobre dla relacji.

To naturalna kulminacja tej części. Wszystko, co było wcześniej – prototypy w jednym pliku, realistyczne dane, skupione artefakty, linki, weryfikacja – to przygotowanie do tego momentu. Opanuj te nawyki, a budowanie podczas spotkania przestanie być popisem i stanie się twoim normalnym sposobem pracy.

W tym tygodniu, podczas następnej rozmowy z klientem, znajdź jedną małą zmianę, którą możesz wprowadzić na żywo. Przygotuj rusztowanie, przećwicz raz, a potem zrób to na jego oczach. Zwróć uwagę na moment, w którym zmienia się jego postawa. Zapamiętaj go. To właśnie sprzedajesz, a ty właśnie znalazłeś najszybszy sposób, by to dostarczyć.

Pierwszy tydzień to dostępy

Nic nie zostanie dostarczone, dopóki nie masz trzech rzeczy: danych logowania, dostępu do danych albo repozytorium i wskazanej z nazwiska osoby decyzyjnej. Przy dwutygodniowym zleceniu stracić trzy dni na czekanie na hasło to stracić jedną piątą kalendarza, zanim w ogóle zacząłeś. Ścigaj wszystkie trzy pierwszego dnia, bo inaczej drugi tydzień po cichu znowu zamieni się w pierwszy, a klient będzie się zastanawiał, dlaczego sprint wydaje się taki krótki.

Dostępy zawsze trwają dłużej, niż ktokolwiek się spodziewa. Osoba, która może założyć konto, jest na urlopie. Dostawca usług IT potrzebuje zgłoszenia. Repozytorium należy do wykonawcy, który nie odpowiedział na maila od wiosny. Dane siedzą w systemie, do którego nikt nie ma hasła administratora. Nic z tego nie jest niczyją winą, ściśle biorąc, ale wszystko to spada na twój harmonogram, chyba że wyprzedzisz problem. Najlepsi konsultanci traktują dostępy jako pierwszy rezultat, z taką samą powagą jak samą pracę.

Wyślij więc listę kontrolną dostępów, zanim zlecenie się zacznie, najlepiej razem z umową. Wypisz każdy system, którego będziesz potrzebować, wymagany poziom dostępu do każdego z nich, nazwisko osoby, która może go przyznać, i datę, do której go potrzebujesz. Proś o konta utworzone na potrzeby zlecenia, a nie o współdzielone osobiste loginy, które są problemem bezpieczeństwa i bólem głowy przy audycie. Proś o minimalny dostęp, który wystarczy do wykonania pracy, i mów to wprost; klientów uspokaja konsultant, który prosi o mniej, a nie o więcej.

Wskazana osoba decyzyjna to pozycja z listy dostępów, o której ludzie zapominają, a która ma największe znaczenie. Ktoś po stronie klienta musi być w stanie odpowiadać na pytania w ciągu doby, zatwierdzić plan, odebrać wynik i powiedzieć „nie” rozrastaniu się zakresu. Bez tej osoby każde pytanie zamienia się w spotkanie, a każda decyzja dryfuje. Poproś o nią z nazwiska na starcie. Uzgodnij, jak będziesz się z nią kontaktować i jak szybko może odpowiadać. Jeśli odpowiedź jest mglista, zlecenie jest zagrożone, a lepiej wiedzieć o tym pierwszego dnia.

Sprint nie zaczyna się wtedy, gdy zaczynasz pracować. Zaczyna się wtedy, gdy możesz.

Użyj Claude’a, żeby start przebiegł gładziej. Dobry pakiet startowy – z definicją ukończenia, listą kontrolną dostępów, tygodniowym rytmem, planem komunikacji i zawartością przekazania – można w kilka minut naszkicować na podstawie twojego szablonu i podsumowania diagnostycznego, a potem omówić z klientem na pierwszym spotkaniu. Wygląda na staranny, bo jest staranny, a gdy szablon już istnieje, kosztuje cię bardzo niewiele.

Jeśli dostępów naprawdę nie da się załatwić na czas, powiedz to wcześnie i dostosuj plan. Przesuń datę startu, zmniejsz zakres albo zacznij od tych części pracy, które nie wymagają brakującego dostępu. Czego nie wolno ci zrobić, to po cichu wchłonąć opóźnienie, a na końcu dostarczyć mniej, niż obiecałeś. To zamienia problem administracyjny w problem z reputacją.

W tym tygodniu napisz szablon listy kontrolnej dostępów: systemy, poziomy dostępu, kto przyznaje, do kiedy, plus wskazana osoba decyzyjna i jej czas reakcji. Dołącz go do następnej umowy. Za pierwszym razem, gdy klient będzie miał wszystko gotowe pierwszego dnia, bo poprosiłeś z wyprzedzeniem, poczujesz lekkie samozadowolenie. Zasłużysz na nie.

Zabezpieczenia zamiast zgadywania

Zdecyduj z góry, czego agentowi nigdy nie wolno. Wysyłać czegokolwiek na zewnątrz. Wydawać pieniędzy. Usuwać rekordów. Zmieniać uprawnień. Kontaktować się z klientami. Jakakolwiek jest ta lista dla danego klienta, zapisz ją na początku, a potem wpisz ją w sam system, a nie w pełne nadziei zdanie w dokumencie, którego nikt nie czyta. Zabezpieczenia zależne od tego, czy model zapamięta instrukcję, to zgadywanie. Zabezpieczenia egzekwowane przez system to zabezpieczenia.

Ta różnica jest ważna. Instrukcja w prompcie – nigdy nie wysyłaj maili bez zatwierdzenia – jest zwykle przestrzegana, ale „zwykle” nie wystarcza przy działaniach, które mają realne konsekwencje. Modele mogą coś źle zrozumieć, dać się zmylić nietypowym danym albo zostać zmanipulowane tekstem ukrytym w przetwarzanej treści. Kontroli na poziomie systemu – agenta, który po prostu nie ma możliwości wysyłania maili, albo którego narzędzie do wysyłania wymaga wyraźnego zatwierdzenia przez człowieka przed wykonaniem – nie da się namówić do przekroczenia własnych granic. Taki poziom pewności jest klientom potrzebny przy wszystkim, co ma znaczenie.

Narzędzia to wspierają. Claude Code ma ustawienia uprawnień, które określają, które narzędzia i polecenia mogą działać bez zatwierdzenia, a które są całkowicie zablokowane. Hooki mogą egzekwować reguły w określonych punktach, na przykład sprawdzając każde polecenie przed jego uruchomieniem. Konektory można skonfigurować z dostępem tylko do odczytu albo z wąskim zakresem zapisu. W systemach budowanych na API to ty decydujesz, jakie narzędzia w ogóle istnieją. W każdym przypadku zasada brzmi: przyznaj tylko tyle możliwości, ile wymaga zadanie, a możliwości niebezpieczne niech albo nie istnieją, albo będą strzeżone przez człowieka.

Pisz zabezpieczenia razem z klientem. Przejdźcie przez działania, które system mógłby podjąć, i przy każdym zapytaj: jaki jest najgorszy prawdopodobny skutek, jeśli coś pójdzie nie tak, i jak łatwo da się to odwrócić? Działania mało ryzykowne i łatwo odwracalne – odczyt danych, szkicowanie tekstu – mogą być swobodne. Działania o umiarkowanym ryzyku – edycja rekordów, zapis plików – mogą wymagać zatwierdzenia. Działania wysokiego ryzyka albo nieodwracalne – wysyłanie, wydawanie, usuwanie – powinny być zablokowane albo ściśle strzeżone. Wynikiem jest krótka, jasna tabela, którą klient rozumie, a system egzekwuje.

Zabezpieczenie w prompcie to prośba. Zabezpieczenie w systemie to fakt.

Ta rozmowa buduje też zaufanie. Klientów, którzy obawiają się AI – czyli większość klientów – uspokajają nie obietnice, że system jest mądry, lecz dowody, że jest ograniczony. Pokazanie im listy rzeczy, których agent nie może zrobić, i zademonstrowanie, że naprawdę nie może, często przekonuje bardziej niż jakakolwiek demonstracja tego, co potrafi. Zamienia abstrakcyjny lęk w konkretną granicę, którą da się obejrzeć.

Umieść zabezpieczenia w instrukcji obsługi, razem z instrukcją, jak je zmieniać. Firmy się zmieniają, a zabezpieczenie, które miało sens przy przekazaniu, rok później może wymagać korekty. Klient powinien wiedzieć, gdzie są kontrolki, co robi każda z nich i kto jest upoważniony do ich zmiany.

W tym tygodniu weź dowolnego agenta albo zautomatyzowany proces, który zbudowałeś dla siebie lub klienta, i wypisz każde działanie, jakie mógłby podjąć. Oznacz każde jako swobodne, za zgodą albo nigdy. Potem sprawdź, czy system naprawdę egzekwuje twoje oznaczenia. Te, które opierają się wyłącznie na instrukcji w prompcie, to twoje pierwsze poprawki.

Człowiek w pętli

Projektuj ludzki punkt kontrolny świadomie, zamiast doklejać go po pierwszym incydencie. Każdy system, który wykonuje prawdziwą pracę, od czasu do czasu coś pomyli. Pytanie nie brzmi, czy człowiek powinien być zaangażowany, lecz gdzie, jak i przy jakich rodzajach działań. Autonomię trzeba zdobywać dla każdego typu działania z osobna, na podstawie dowodów, a nie przyznawać całemu systemowi naraz, bo demo dobrze poszło.

Zacznij od rozrysowania procesu i zaznaczenia, gdzie błąd byłby kosztowny. Szkic odpowiedzi na rutynowe zapytanie może być bezpieczny do wysłania po szybkim rzucie oka człowieka. Odpowiedź na reklamację może wymagać uważnej lektury. Zwrot powyżej pewnej kwoty może wymagać zgody kierownika. Wiadomość do regulatora prawdopodobnie nigdy nie powinna być szkicowana przez agenta bez ścisłego nadzoru. Każdy z tych przypadków to inny punkt kontrolny, zaprojektowany pod ryzyko na danym etapie, a nie jedno ogólne zatwierdzenie, którego ludzie przestają czytać po pierwszym tygodniu.

Spraw, by punkt kontrolny dało się łatwo dobrze wykonać. Człowiek zatwierdzający wyniki musi widzieć właściwe informacje: pierwotne dane wejściowe, wynik agenta, wszelkie flagi podniesione przez system i, jeśli to istotne, uzasadnienie. Potrzebuje szybkiego sposobu, by zatwierdzić, poprawić albo odrzucić, oraz sposobu, by zapisać dlaczego. Jeśli ekran zatwierdzania jest zagracony albo powolny, ludzie zaczynają klikać „zatwierdź” bez czytania, a punkt kontrolny staje się teatrem. Dobry projekt punktu kontrolnego to przede wszystkim dobry projekt interfejsu.

Wykorzystaj punkt kontrolny do zbierania dowodów. Każde zatwierdzenie, poprawka i odrzucenie mówi ci coś o tym, jak działa system. Zapisuj je. Regularnie przeglądaj. Jeśli zespół zatwierdza dany typ wyniku bez zmian dziewięćdziesiąt kilka razy z rzędu w miarodajnym okresie, to dowód, że punkt kontrolny dla tego typu można poluzować, na przykład do kontroli wyrywkowej zamiast pełnego przeglądu. Jeśli ciągle poprawia inny typ, to dowód, że system wymaga tam ulepszeń. Autonomia rozszerza się tam, gdzie wspierają ją dowody, po jednym typie działania naraz.

Ufaj systemowi tak daleko, jak sięgają dowody, i ani kroku dalej.

To podejście dobrze pasuje do mikrozleceń. Pilotaż agenta zwykle zaczyna się od człowieka zatwierdzającego każdy wynik. To bezpieczne, daje klientowi pewność i generuje dokładnie te dowody, które są potrzebne, by zdecydować, co dalej. Kolejne zlecenie może wtedy poluzować punkty kontrolne tam, gdzie wspierają to dane, i ulepszyć system tam, gdzie nie wspierają. Każdy krok jest mały, uzasadniony i mierzalny.

Bądź wobec klientów uczciwy w kwestii tego, co człowiek w pętli może wyłapać, a czego nie. Recenzent przeglądający pięćdziesiąt szkiców na godzinę przeoczy subtelne błędy. Projektuj z myślą o tym: oznaczaj wyniki nietypowe albo o niskiej pewności do bliższej uwagi, żeby uwaga recenzenta szła tam, gdzie jest najbardziej potrzebna. Łącz ludzki przegląd z automatycznymi kontrolami, takimi jak wzorzec weryfikatora z części piątej, zamiast polegać na jednym z nich.

W tym tygodniu weź jeden proces, który zautomatyzowałeś albo planujesz zautomatyzować, i oznacz każdy krok punktem kontrolnym, jakiego wymaga: żaden, rzut oka, uważny przegląd albo zgoda przełożonego. Przyjrzyj się krokom bez punktu kontrolnego i zapytaj, czy masz dowody, że są bezpieczne, czy jedynie nadzieję. Tam, gdzie to nadzieja, dodaj punkt kontrolny i zacznij zbierać dowody.

Ewaluacje jako odbiór

Zastąp mglisty odbiór punktowanym zestawem testów. Na końcu typowego zlecenia klienta pyta się, czy jest zadowolony, a odpowiedź zależy od jego nastroju, ostatniego wyniku, jaki widział, i od tego, czy tego ranka coś poszło nie tak. To kiepska podstawa do odbioru pracy i żyzny grunt dla sporów. Kiedy odbiór to wynik punktowy na dwudziestu prawdziwych przypadkach, uzgodnionych z góry, spory zwykle kończą się, zanim się zaczną.

Zestaw ewaluacyjny, zwykle nazywany po prostu ewaluacjami, to zbiór realistycznych danych wejściowych z jasnym sposobem oceny każdego wyniku. Dla systemu szkicującego odpowiedzi na zapytania może to być dwadzieścia prawdziwych zapytań z przeszłości, w razie potrzeby zanonimizowanych, każde z notką o tym, co powinna zawierać dobra odpowiedź. Dla potoku wyodrębniającego dane z dokumentów może to być dwadzieścia dokumentów z poprawnymi wyodrębnionymi wartościami. Dla zestawu promptów może to być zbiór zadań z kryteriami jakości. Test zostaje uruchomiony, każdy wynik oceniony, a rezultatem jest liczba, którą wszyscy widzą.

Buduj zestaw ewaluacyjny razem z klientem, wcześnie. W pierwszych dniach zlecenia poproś osobę, która będzie odbierać pracę, by wybrała reprezentatywne przypadki, w tym kilka kłopotliwych, i powiedziała, jak wygląda dobry wynik dla każdego z nich. Zapisz to jako kryteria oceny. Uzgodnij próg odbioru: na przykład określona liczba przypadków musi w pełni spełniać kryteria, a żaden nie może zawierać poważnego błędu. Teraz wszyscy wiedzą, co znaczy „gotowe”, w konkretnych, sprawdzalnych kategoriach.

Zestaw ewaluacyjny staje się potem twoim narzędziem deweloperskim. Uruchamiaj go po każdej istotnej zmianie. Od razu widzisz, czy nowy prompt, nowy skill albo nowy model poprawia sytuację, czy ją pogarsza. Przestajesz spierać się o to, czy wynik jest ogólnie dobry, i zaczynasz naprawiać konkretne przypadki, które zawodzą. Claude może pomagać w uruchamianiu i punktowaniu ewaluacji według kryteriów, a ty przeglądasz wyniki. Wzorzec weryfikatora ma tu bezpośrednie zastosowanie.

Odbiór na podstawie odczuć zaprasza do kłótni. Odbiór na podstawie wyniku zaprasza do poprawki.

Ewaluacje wzmacniają też przekazanie i uwiarygodniają abonament. Przy przekazaniu klient otrzymuje zestaw ewaluacyjny razem z systemem, żeby mógł go ponownie uruchomić przy każdej zmianie: nowym modelu, nowym regulaminie, nowej linii produktów. W ramach abonamentu comiesięczny raport może pokazywać wynik w czasie, a każdy nowy przypadek porażki trafia do zestawu. To konkretna, ciągła demonstracja wartości, znacznie bardziej przekonująca niż lista przepracowanych godzin.

Dwa zastrzeżenia. Po pierwsze, zestaw ewaluacyjny jest tak dobry jak jego przypadki. Jeśli wszystkie dwadzieścia są łatwe, wysoki wynik niewiele znaczy. Dodaj trudne przypadki i dokładaj nowe za każdym razem, gdy zdarzy się prawdziwa porażka. Po drugie, nie pozwól, by wynik stał się jedyną miarą. System może dobrze wypadać na swoim zestawie testów, a mimo to frustrować użytkowników w sposób, którego zestaw nie wychwytuje. Łącz wynik z opiniami użytkowników i miarami z rzeczywistego świata.

W tym tygodniu, przy następnej rzeczy, którą dostarczasz, napisz zestaw ewaluacyjny, zanim zaczniesz budować: od dziesięciu do dwudziestu realistycznych przypadków, kryteria oceny i próg, uzgodnione z osobą, która będzie odbierać pracę. Potem buduj, aż przejdzie. Przekonasz się, że rozmowa na końcu jest znacznie krótsza i znacznie przyjaźniejsza niż zwykle.

Demo w każdy piątek

Cotygodniowe demo to najtańsze ubezpieczenie od budowania niewłaściwej rzeczy. W każdy piątek pokaż klientowi, co zbudowałeś w tym tygodniu: działające, na ekranie, z danymi w rodzaju jego danych. Zajmuje to pół godziny. Zmusza cię do wytworzenia co tydzień przyrostu, który da się dostarczyć, wyłapuje nieporozumienia, póki ich naprawa jest tania, i utrzymuje emocjonalne zaangażowanie klienta w pracę. Niewiele nawyków daje tak dużo za tak niewiele.

Ten przymus ma znaczenie. Bez demonstracji w kalendarzu praca dryfuje w stronę tego, co wygodne i niewidoczne: refaktoringu, szlifowania, eksplorowania. Z demonstracją w każdy piątek musisz mieć co pokazać, a to znaczy, że musisz mieć coś działającego. Ta presja utrzymuje pracę skupioną na tym, co klient zobaczy i czego będzie używał. W dwutygodniowym sprincie dwa piątkowe dema są kręgosłupem zlecenia: jedno do sprawdzenia kierunku, drugie do dostarczenia.

Demo to także miejsce, w którym wychodzą na wierzch nieporozumienia. Zbudowałeś narzędzie do segregowania zapytań według typu produktu; klient zakładał, że będzie segregować według pilności. W dokumencie takie nieporozumienie mogłoby przetrwać do przekazania. Na demonstracji wychodzi w trzydzieści sekund, kiedy klient widzi pilną reklamację skierowaną do niewłaściwej kolejki i mówi: chwileczkę, to powinno iść prosto do Sary. Lepiej usłyszeć to w pierwszy piątek niż w ostatni.

Trzymaj się stałego formatu. Zacznij od przypomnienia celu i definicji ukończenia. Pokaż, co zmieniło się od zeszłego tygodnia, w działaniu, najlepiej na żywo. Pokaż wynik ewaluacji, jeśli go masz. Wspomnij o wszystkim, co poszło nie tak albo się zmieniło. Poproś o konkretne uwagi do konkretnych decyzji. Zakończ tym, co zrobisz w przyszłym tygodniu. Trzydzieści minut, za każdym razem ta sama struktura, żeby klient wiedział, czego się spodziewać, i przychodził przygotowany.

Demo w każdy piątek oznacza, że złe wieści przychodzą w małych kawałkach, które da się przeżyć, a nie w jednym wielkim, którego się nie zapomina.

Strona emocjonalna jest niedoceniana. Klienci, którzy co tydzień widzą postęp, czują się współwłaścicielami pracy. Opowiadają o niej kolegom. Zaczynają wyobrażać sobie, jak będą z niej korzystać. Do przekazania są już zaangażowani w jej sukces, co znacznie zwiększa szansę na wdrożenie. Klienci, którzy przez dwa tygodnie nic nie widzą, a potem dostają gotowy system, czują się odbiorcami, a nie uczestnikami, a odbiorcy dużo chętniej szukają dziury w całym.

Zaproś właściwych ludzi. Osobę decyzyjną, oczywiście. Osobę, która przejmie opiekę nad systemem po przekazaniu, koniecznie. Jedną czy dwie osoby, które będą z niego faktycznie korzystać, jeśli się da. Użytkownicy zauważają praktyczne problemy, których nie widzą kierownicy, a wczesne zaangażowanie ich bardzo ułatwia późniejsze szkolenie.

W tym tygodniu, jeśli jesteś w trakcie zlecenia, zaplanuj piątkowe demo, nawet jeśli ma trwać tylko piętnaście minut. Jeśli nie jesteś, dodaj cotygodniowe demo do swojego standardowego szablonu zlecenia i do następnej oferty. Klienci konsekwentnie mówią, że cotygodniowe dema to jedna z rzeczy, które cenili najbardziej, a to jedna z najtańszych rzeczy, jakie kiedykolwiek zapewnisz.

Protokół rozrastania się zakresu

Powiedz „tak” pomysłowi i „nie” terminowi. Rozrastanie się zakresu to naturalny wróg pracy o stałym zakresie i rzadko przychodzi jako żądanie. Przychodzi jako entuzjastyczna, rozsądna, niewinnie brzmiąca prośba od klienta zadowolonego z postępów. A czy mogłoby to obsługiwać także zwroty? Skoro już tam jesteś, mógłbyś zerknąć na raportowanie? Każda prośba wydaje się błaha. Razem zamieniają dwutygodniowy sprint w sześciotygodniowy za tę samą cenę.

Protokół jest prosty i życzliwy. Kiedy pojawia się nowa prośba, przyjmij ją z radością, bo oznacza, że klient jest zaangażowany. Potem zapisz ją jako notkę o zmianie: o co się prosi, co by to obejmowało, jak wpłynęłoby na harmonogram i ile by kosztowało. Wyślij notkę szybko, najlepiej tego samego dnia, z jasnym wyborem: dodać to do bieżącego zlecenia z podaną zmianą albo wpisać na listę na następne. Większość klientów wybiera listę, i to pogodnie, bo widzą, że bieżąca praca idzie zgodnie z planem.

Ton ma równie duże znaczenie jak procedura. Protokół wdrażany niechętnie wydaje się biurokracją. Wdrażany ciepło wydaje się profesjonalizmem. To świetny pomysł i naturalnie pasuje po tym sprincie. Dopisałem go do listy na końcowe demo i mogę ci przesłać krótki zarys tego, co by obejmował. Klient słyszy entuzjazm i plan, a nie odmowę. Na pytanie o termin odpowiedź brzmi „nie”; na pomysł – „tak”.

Claude może sprawić, że protokół nie wymaga niemal żadnego wysiłku. Trzymaj szablon notki o zmianie, a gdy przyjdzie prośba, poproś Claude’a, by naszkicował notkę na podstawie prośby, bieżącego zakresu i twoich standardowych warunków. Przejrzyj ją, dostosuj szacunek, wyślij. Pięć minut. Trzymaj wszystkie notki w jednym miejscu. Pod koniec zlecenia ten zbiór odłożonych próśb to gotowy lejek: lista rzeczy, o których klient już powiedział, że ich chce, opisanych i z grubsza zakresowanych, czekających na końcowe demo.

Każda odłożona prośba to oferta, którą klient napisał za ciebie. Traktuj tę listę z troską.

Uzgodnij protokół na starcie, żeby nigdy nie był zaskoczeniem. Wyjaśnij, że zlecenie ma stały zakres, a nowe prośby będą mile widziane, spisywane i albo dodawane ze zmianą, albo odkładane na później. Klienci doceniają znajomość zasad. Oznacza to też, że kiedy sięgasz po protokół, postępujesz zgodnie z uzgodnioną procedurą, a nie wymyślasz powodu, by odmówić.

Jest jeden wyjątek, który warto nazwać. Jeśli prośba ujawnia, że pierwotny zakres był błędny, że to, co budujesz, nie rozwiąże problemu, zatrzymaj się i porządnie to omów. To nie jest rozrastanie się zakresu. To nowa informacja i może oznaczać zmianę kierunku. Protokół dotyczy dodatków, nie korekt.

W tym tygodniu napisz szablon notki o zmianie: prośba, wpływ, harmonogram, wybór. Uzgodnij protokół na następnym starcie zlecenia. Kiedy przyjdzie pierwsza prośba, użyj go, ciepło i tego samego dnia. Potem patrz, jak rośnie lista odłożonych spraw. To najpewniejsze źródło kolejnych zleceń, jakie kiedykolwiek będziesz mieć.

Napisz instrukcję obsługi

System, który zostawiasz, musi dać się obsługiwać komuś, kto nigdy cię nie spotkał. To test dobrego przekazania, a instrukcja obsługi to sposób, by go zdać. Bez instrukcji twoja praca jest projektem: istnieje, działa dzisiaj i zależy od wiedzy w twojej głowie. Z instrukcją staje się aktywem: czymś, co klient może uruchomić, sprawdzić, naprawić i zmienić bez dzwonienia do ciebie. Za to zapłacił, czy zdawał sobie z tego sprawę, czy nie.

Dobra instrukcja obsługi obejmuje trzy rzeczy. Po pierwsze, co system robi i dlaczego: jego cel, dane wejściowe i wyjściowe, decyzje, które go ukształtowały, i zabezpieczenia, które go ograniczają. Po drugie, jak go uruchomić i sprawdzić: gdzie się znajduje, jak go wystartować, jak poznać, czy działa, gdzie są logi, jak ponownie uruchomić zestaw ewaluacyjny. Po trzecie, co robić, gdy się psuje: typowe tryby awarii, jak rozpoznać każdy z nich, kroki naprawcze i kiedy eskalować. Dodaj kontakty, miejsca przechowywania danych logowania i procedury zmian, a masz dokument, na którym klient może polegać.

Pisz ją w trakcie zlecenia, a nie na końcu. Za każdym razem, gdy coś konfigurujesz, zapisz jak. Za każdym razem, gdy coś pójdzie nie tak, zapisz, co się stało i jak to naprawiłeś. Claude może zamienić twoje notatki, plik pamięci, historię commitów i konfigurację systemu w dobrze ustrukturyzowany szkic, który potem sprawdzasz i uzupełniasz. Instrukcja pisana w ostatnich dwóch godzinach sprintu zawsze jest cieńsza niż ta pisana na bieżąco.

Przetestuj ją. Poproś osobę, która przejmie opiekę nad systemem, by postępowała według instrukcji bez twojej pomocy: uruchomiła system, przeprowadziła kontrolę, zasymulowała typową awarię i ją naprawiła. Obserwuj, gdzie utyka. Każde miejsce, w którym utyka, to luka w instrukcji. Załataj luki. Ten test zajmuje godzinę i jest jedną z najcenniejszych godzin całego zlecenia, bo dokładnie pokazuje, jak duża część twojej wiedzy nie została jeszcze przekazana.

Jeśli system działa tylko wtedy, gdy jesteś osiągalny, nie dostarczyłeś systemu. Dostarczyłeś zależność.

Trzymaj instrukcję tam, gdzie klient ją znajdzie: w repozytorium obok kodu, w wiedzy projektowej obok promptów albo w jego zwykłym systemie dokumentacji. Spraw, by łatwo mógł ją aktualizować. Systemy się zmieniają, a instrukcja, której nikt nie aktualizuje, zaczyna wprowadzać w błąd, co jest gorsze niż jej brak. Wskaż po stronie klienta właściciela odpowiedzialnego za jej aktualność.

Instrukcja obsługi to także dyskretny marketing. Klienci, którzy dostają jasną, przetestowaną instrukcję, pamiętają o tym, bo większość wykonawców jej nie zapewnia. To sygnał, że zależy ci na tym, co dzieje się po twoim odejściu, a właśnie to sprawia, że klienci powierzają ci następne zlecenie.

W tym tygodniu napisz instrukcję obsługi do czegoś, co zbudowałeś, nawet czegoś małego dla siebie. Trzy sekcje: co i dlaczego, jak uruchomić i sprawdzić, co robić, gdy się psuje. Potem poproś kogoś innego, by z niej skorzystał. Odkryjesz, jak wiele założyłeś. O to odkrycie właśnie chodzi.

Wyszkol orędownika

Każdy klient potrzebuje jednej osoby w środku, która potrafi zademonstrować system bez ciebie. Wdrożenie umiera, gdy jedyny kompetentny operator co miesiąc wystawia fakturę. Możesz zbudować najbardziej elegancki proces, najbardziej niezawodny pilotaż agenta, najprzydatniejszą bibliotekę skilli, a jeśli nikt w firmie nie rozumie ich na tyle dobrze, by ich bronić i je promować, powoli wyjdą z użycia. Szkolenie orędownika nie jest dodatkiem do dostawy. Jest częścią dostawy.

Wybierz orędownika starannie, najlepiej razem z klientem na starcie. Najlepszym orędownikiem niekoniecznie jest osoba najwyżej w hierarchii ani najbardziej techniczna. To ktoś, kto na co dzień korzysta z systemu, kogo szanują koledzy, kogo AI ciekawi, a nie przeraża, i kto ma dość czasu, by się uczyć. Poproś o tę osobę z nazwiska, angażuj ją w piątkowe dema i dawaj jej w trakcie zlecenia prawdziwe obowiązki: testowanie wyników, dostarczanie przykładów, przegląd instrukcji obsługi.

Wyszkol ją porządnie przed przekazaniem. Orędownik powinien umieć zademonstrować system koledze, wyjaśnić, co robi, a czego nie, poradzić sobie z typowymi problemami opisanymi w instrukcji, wprowadzać drobne zmiany, takie jak dodanie przykładu do skilla albo aktualizacja promptu, ponownie uruchomić zestaw ewaluacyjny i ocenić, kiedy eskalować sprawę do ciebie albo do własnego wsparcia technicznego. To spory zestaw umiejętności i nie da się go zbudować na jednym spotkaniu. Zaplanuj kilka krótkich sesji w ciągu zlecenia, z ćwiczeniami pomiędzy nimi.

To także miejsce, w którym szkolenie staje się mikrozleceniem samym w sobie. Wiele firm chce, by ich szerszy zespół dobrze korzystał z narzędzi AI, a skupiona, praktyczna sesja – pół dnia, konkretny zespół, jego prawdziwe zadania, zestaw przetestowanych promptów na wynos – to łatwy zakup z natychmiastowymi rezultatami. Prowadź ją z orędownikiem jako współprowadzącym. Zespół uczy się od kogoś, z kim pracuje, pozycja orędownika rośnie, a szkolenie trwa dalej po twoim odejściu, bo orędownik wciąż jest na miejscu.

System będzie używany tak długo, jak ktoś w środku w niego wierzy i umie go pokazać. Zadbaj, żeby ten ktoś istniał.

Dobre szkolenie jest praktyczne, a nie teoretyczne. Korzystaj z prawdziwej pracy zespołu, a nie z wymyślonych przykładów. Niech każdy uczestnik podczas sesji wytworzy coś przydatnego. Naucz dobrze kilku technik, zamiast pobieżnie omawiać wszystko. Zostaw im krótką ściągę, zestaw promptów albo jednostronicowy przewodnik, i nazwisko orędownika jako osoby, którą można pytać. Kilka tygodni później sprawdź, co się przyjęło.

Dbaj o orędownika także po przekazaniu. Krótka rozmowa kontrolna miesiąc później, wiadomość, gdy pojawi się istotna nowa funkcja, zaproszenie do opowiedzenia o jego sukcesie w studium przypadku. Orędownicy są też twoim najlepszym źródłem poleceń i najlepszymi adwokatami, gdy rozważane jest następne zlecenie. Wiedzą, co zrobiłeś, widzieli, że działa, i mają osobisty interes w tym, by działało dalej.

W tym tygodniu pomyśl o systemach, które dostarczyłeś. Przy każdym wymień z nazwiska wewnętrznego orędownika. Jeśli nie potrafisz nikogo wymienić, ten system jest zagrożony. Odezwij się i zaproponuj krótką sesję szkoleniową. Może to być najcenniejsza godzina, jaką spędzisz w tym miesiącu.

Oddaj prompty

Zatrzymywanie promptów dla siebie, by wytworzyć zależność, to krótka gra, która źle się kończy. Niektórzy konsultanci trzymają instrukcje, skille i konfigurację swoich systemów dla siebie, wychodząc z założenia, że klient, który nie widzi, jak coś działa, musi płacić, by dalej działało. Czasem to się udaje, przez jakiś czas. Potem klient zmienia konsultanta, zatrudnia programistę albo po prostu zaczyna mieć żal o taki układ, a ty tracisz klienta, a razem z nim reputację. Daj mu wszystko, a sprzedaj mu następny system.

Co znaczy „wszystko”? Prompty i instrukcje systemowe. Skille, z ich materiałami referencyjnymi i skryptami. Pliki pamięci. Zestawy ewaluacyjne i kryteria oceny. Konfigurację konektorów i uprawnień. Instrukcję obsługi. Prototypy i ich kod źródłowy. Wszystko, co zostało zbudowane dla klienta, z kontekstu klienta, do wykonywania pracy klienta, należy do klienta. Przekaż to w formie, której może używać, którą może przechowywać i zmieniać, i udokumentuj na tyle dobrze, by ktoś inny mógł to przejąć.

To nie tylko etyka; to dobry biznes. Klienci, którzy dostają wszystko, ufają ci bardziej, a nie mniej. Widzą, że twoja wartość nie tkwi w tajnych promptach, lecz w osądzie, szybkości i umiejętności rozwiązania następnego problemu. Chętniej zadzwonią do ciebie w sprawie następnego zlecenia, bo wiedzą, że nie zastawisz na nich pułapki. Chętniej cię polecą, bo mogą uczciwie powiedzieć innym, że grałeś w otwarte karty. I rzadziej się targują, bo czują, że dostali pełną wartość.

To także realizm. Prompty nie są trwałą fosą obronną. Kompetentna osoba z dostępem do wyników systemu często potrafi odtworzyć sporą część promptu w jedno popołudnie, a modele poprawiają się tak szybko, że sprytne sformułowania tracą przewagę w ciągu miesięcy. Nie traci na wartości twoja metoda, twoja biblioteka skilli ogólnego przeznaczenia, twoje doświadczenie z wieloma klientami i twój osąd w kwestii tego, co zbudować dalej. To zostaje z tobą, cokolwiek przekażesz.

Twoje prompty zestarzeją się w ciągu roku. Twoja reputacja kogoś, kto je oddaje – nie.

Jasno określ, co jest ich, a co twoje, jak sugerował wcześniejszy rozdział o skillach jako rezultacie. Praca specyficzna dla klienta należy do klienta. Ogólne techniki, szablony i skille, które przyniosłeś ze sobą, pozostają twoje, a klient otrzymuje licencję na korzystanie z nich jako części dostarczonego systemu. Zapisz to w umowie na początku, prostym językiem. Większość klientów jest w pełni zadowolona z takiego układu, a on chroni twoją bibliotekę wielokrotnego użytku.

Uczyń z samego przekazania moment. Krótka sesja omawiająca, co teraz posiadają, gdzie to się znajduje i jak to zmieniać. Uporządkowane repozytorium albo projekt z plikiem readme na górze. Jasne stwierdzenie, że mogą to swobodnie modyfikować, rozbudowywać albo przekazać komuś innemu. Klienci pamiętają konsultanta, który w gruncie rzeczy mówi: to wszystko jest teraz wasze; zadzwońcie, kiedy będziecie chcieli następnej rzeczy.

W tym tygodniu przyjrzyj się ostatniemu dostarczonemu systemowi i sprawdź: czy klient ma wszystko? Jeśli nie, wyślij to z krótką notką. Nie kosztuje cię to niczego, co ma znaczenie, a kupuje więcej zaufania niż jakikolwiek marketing.

Zamknij pętlę głośno

Policz, co się zmieniło, i powiedz to kupującemu jego językiem. Niezmierzone sukcesy nie są odnawiane, polecane ani pamiętane, gdy przychodzi czas na budżet. Mogłeś przeobrazić proces, ale jeśli nikt nie potrafi powiedzieć, o ile, poprawa rozpływa się w ogólnym tle rzeczy, które teraz po prostu działają. Pół roku później, przy przeglądzie budżetu, pada pytanie, co ten konsultant właściwie osiągnął, a uczciwa odpowiedź brzmi, że nikt tego nie zapisał.

Zamykanie pętli zaczyna się na początku. Pierwszego dnia ustal punkt zero: ile dziś trwa zadanie, jak często coś idzie nie tak, ile przypadków obsługuje, ile kosztuje w czasie albo opóźnieniach. Zdobądź liczby od klienta, zmierz je sam albo starannie oszacujcie je razem i zapiszcie metodę. Bez punktu zero każdy pomiar „po” to twierdzenie bez porównania.

Na końcu zmierz te same rzeczy w ten sam sposób. Czas na zadanie, odsetek błędów, obsłużony wolumen, czas realizacji. Zaraportuj różnicę w kategoriach klienta. Nie system osiąga wysoką trafność, tylko zespół szkicuje teraz rutynowe odpowiedzi w ułamku dotychczasowego czasu, a zestaw ewaluacyjny pokazuje, że w większości przypadków szkice spełniają uzgodniony standard, a każdy wyjątek jest wyłapywany przy przeglądzie. Nie proces został zautomatyzowany, tylko miesięczny raport, który zajmował cały dzień, teraz zajmuje niecałą godzinę. Konkretnie, porównywalnie, jego językiem.

Potem powiedz to kupującemu głośno. Nie w przypisie do dokumentu przekazania, lecz jako nagłówek końcowej demonstracji i krótkie pisemne podsumowanie, które może przesłać dalej. Ułatw mu podzielenie się wynikiem w górę i na boki: z przełożonym, z zarządem, z kolegami z innych działów. Kupujący dobrze wypada, co zapamięta, a wynik dociera do ludzi, którzy mogą chcieć czegoś podobnego.

Praca nie jest skończona, kiedy działa. Jest skończona, kiedy wie o tym ktoś, kto podpisuje budżety.

Wróć do tematu później. Miesiąc po przekazaniu sprawdź liczby ponownie. Systemy czasem działają lepiej w użyciu niż w testach, bo ludzie uczą się z nimi pracować, a czasem gorzej, bo pojawiają się przypadki brzegowe. Tak czy inaczej, ten powrót jest cenny: dobre wyniki stają się mocniejszym studium przypadku, a problemy można naprawić, zanim podkopią cały wysiłek. To także naturalny moment, by poruszyć kwestię następnego zlecenia z listy odłożonych spraw.

Bądź uczciwy. Jeśli wynik jest mniejszy, niż się spodziewano, powiedz to i wyjaśnij dlaczego. Klienci znacznie bardziej ufają konsultantom, którzy rzetelnie raportują skromne wyniki, niż tym, którzy wszystko pompują. A rzetelnie zaraportowany skromny wynik, z jasnym wyjaśnieniem, co by go poprawiło, często otwiera drogę do następnego zlecenia.

W tym tygodniu, dla bieżącego albo ostatniego zlecenia, napisz jednoakapitowe podsumowanie wyniku: punkt zero, stan po, różnica, językiem klienta. Jeśli nie masz punktu zero, oszacuj go razem z klientem i zanotuj metodę. Wyślij to kupującemu z krótką notką. Potem wbuduj pomiar punktu zero w swój szablon startu zlecenia, żeby już nigdy nie musieć go odtwarzać.

Wyceniaj lukę wartości

Zakotwicz cenę w tym, ile problem kosztuje klienta, a nie w tym, ile praca kosztuje ciebie. W każdym zleceniu są dwie liczby: koszt problemu dla nich, w skali roku albo dłużej, i koszt pracy dla ciebie. Odkąd Claude wykonuje dużą część ciężkiej roboty, druga liczba gwałtownie spadła. Pierwsza – nie. W luce między tymi dwiema liczbami powinno mieszkać twoje honorarium, a zrozumienie tej luki to fundament dobrej wyceny małych zleceń.

Ta książka nie podaje cen, i to celowo. Twoje ceny zależą od twojego rynku, branży, reputacji i klientów, a każda wydrukowana tu kwota byłaby błędna dla większości czytelników. Może natomiast dać ci kształt rozumowania. Zacznij od problemu klienta i oszacuj, razem z nim, ile kosztuje: godziny pracy personelu w każdym tygodniu, błędy i ich konsekwencje, opóźnienia i ich wpływ na klientów, utracone szanse. To oszacowanie, uczciwie przeprowadzone, jest sufitem tego, ile warte jest dla nich rozwiązanie.

Potem rozważ swój koszt: swój czas, swoje narzędzia, swoje ryzyko. To podłoga, poniżej której zlecenie nie jest warte podjęcia. Twoje honorarium powinno wygodnie mieścić się między nimi, na tyle blisko wartości, by odzwierciedlało to, co dostarczasz, i na tyle daleko poniżej niej, by klient widział oczywisty zwrot. Kupujący, który płaci honorarium wyraźnie stanowiące skromny ułamek kosztu problemu, nie targuje się. Podejmuje łatwą decyzję.

Materiał do tego zbierasz podczas rozmowy diagnostycznej. Pytania o to, jak często pojawia się problem, ile trwa, co idzie nie tak i ile to kosztuje, to nie tylko diagnoza; to dane wejściowe do twojej ceny. Przedstawiając ofertę, krótko pokaż rozumowanie: tak oszacowaliśmy koszt problemu, to dostarczy zlecenie, takie jest honorarium. Honorarium wygląda skromnie obok kosztu, bo jeśli zrobiłeś to porządnie, to skromne jest.

Wyceniaj dziurę w ich wiadrze, a nie godziny, których potrzebujesz, by ją załatać.

Wycena oparta na wartości ma uczciwą granicę. Jeśli nie potrafisz z jakąkolwiek pewnością oszacować wartości, nie wymyślaj dużej liczby, by uzasadnić wysokie honorarium. Albo przeprowadź płatne rozpoznanie, żeby się dowiedzieć, albo wyceń zlecenie skromnie, jako pierwszy krok, który dostarczy dowodów na rzecz większego. Klienci odróżniają staranne oszacowanie od wygodnej fikcji, a ta druga szybko niszczy zaufanie.

Ma też wymiar etyczny. Wycena oparta na wartości nie oznacza wyciskania jak najwięcej. Oznacza wycenę, która nagradza cię za wyniki, a nie za wysiłek, i zostawia klienta wyraźnie w lepszej sytuacji. Konsultant, który wycenia na pełną wartość problemu, zostawia klienta bez zysku i bez powodu, by wrócił. Zostaw miejsce na wyraźną wygraną po obu stronach.

W tym tygodniu weź niedawne albo nadchodzące zlecenie i oszacuj możliwie starannie, ile problem kosztuje klienta w ciągu roku. Zapisz swój koszt realizacji. Spójrz na swoje honorarium w odniesieniu do obu tych liczb. Jeśli leży znacznie bliżej twojego kosztu niż ich wartości, prawdopodobnie wyceniałeś swoje godziny, a nie ich rezultat.

Nigdy nie podawaj ceny pierwszy

Zapytaj, ile klient przeznaczył, zanim sam podasz kwotę. Za pierwszymi kilkoma razami wydaje się to niezręczne, a to jedno z najbardziej przydatnych pytań w konsultingu. Odpowiedź często przewyższa to, co zamierzałeś zaproponować. Kiedy jest niższa, dowiadujesz się o tym wcześnie i możesz dopasować zlecenie, zamiast odkrywać rozbieżność po napisaniu długiej oferty. Tak czy inaczej, mówi ci, w jaką grę grasz.

Pytanie można sformułować łagodnie. Czy macie na to jakiś budżet albo przedział, w którym chcielibyście się zmieścić? Czy na tego rodzaju pracę w tym roku przeznaczono już jakąś kwotę? Żebym zaproponował coś sensownego: o jakim poziomie inwestycji myśleliście? Większość kupujących coś ci powie, nawet jeśli w przybliżeniu. Niektórzy powiedzą, że nie mają pojęcia, a to też przydatna informacja: sugeruje, że są na wczesnym etapie myślenia i że może trzeba im pomóc zbudować uzasadnienie.

Kiedy przyjdzie odpowiedź, użyj jej do kształtowania zakresu, a nie do ustalania ceny. Jeśli przydział jest hojny, możesz zaproponować pełniejsze zlecenie albo opcję kompleksową. Jeśli skromny, możesz zaproponować mniejszy pierwszy krok: audyt zamiast sprintu, zestaw promptów zamiast pilotażu agenta, jeden proces zamiast trzech. Celem nie jest zgarnięcie każdego grosza z budżetu. Celem jest zaproponowanie czegoś, co pasuje do możliwości klienta i w ich ramach dostarcza wyraźnej wartości.

Bywa, że kupujący nalega, żebyś to ty zaczął. W porządku. Wtedy podaj widełki zamiast jednej kwoty, zakotwiczone w wartości, i powiąż każdy koniec widełek z innym zakresem. Przy skupionym zleceniu na jeden proces byłoby to mniej więcej tyle; przy pełniejszym, obejmującym procesy sąsiednie, mniej więcej tyle. Widełki z objaśnionymi zakresami zapraszają do rozmowy o tym, czego chcą, zamiast do odpowiedzi „tak” lub „nie” na jedną liczbę.

Pierwsza wypowiedziana liczba ustawia atmosferę w pokoju. Niech, kiedy tylko się da, będzie to ich liczba.

Claude może pomóc ci się przygotować. Przed rozmową o cenie zapisz, co wiesz o kliencie, problemie i jego szacowanym koszcie, i poproś o zestaw opcji zakresu w różnych rozmiarach, każdą z jasnym rezultatem i efektem. Wtedy wchodzisz w rozmowę gotów dopasować do tego, co powie klient, kształt, który pasuje. Przygotowanie sprawia, że pytanie brzmi naturalnie, a nie wymijająco.

Przede wszystkim utrzymuj rozmowę wokół wartości, a nie kosztu. Kiedy kupujący ujawnia budżet, mówi ci, ile jego zdaniem warte jest rozwiązanie problemu. Jeśli wydaje się to niskie w porównaniu z twoim oszacowaniem, zapytaj o to. Może nie docenili kosztu problemu, a kilka pytań to ujawni. Może mają ograniczenia, o których nie wiedziałeś. Tak czy inaczej, dowiadujesz się czegoś ważnego, zanim się do czegokolwiek zobowiążesz.

W tym tygodniu przećwicz to pytanie. Zapisz dwa albo trzy sformułowania, z którymi czujesz się swobodnie, i użyj jednego z nich podczas następnej rozmowy sprzedażowej. Zauważ, jak zmienia się rozmowa, kiedy to kupujący pierwszy mówi o pieniądzach. Większość konsultantów odkrywa, że to znacznie mniej niezręczne, niż się obawiali, i znacznie bardziej przydatne, niż się spodziewali.

Zawsze trzy opcje

Jedna cena zaprasza do „tak” albo „nie”. Trzy opcje zapraszają do wyboru, którą wziąć. To dla kupującego zupełnie inna decyzja, a dla ciebie znacznie lepsza. Kiedy oferta ma jedną opcję, kupujący decyduje, czy w ogóle chce z tobą pracować. Kiedy ma trzy – oszczędną, standardową i pełną – decyduje, ile z tego, co oferujesz, chce wziąć. Pytanie po cichu przesunęło się z „czy” na „którą”.

Projektuj opcje wokół zakresu i rezultatu, a nie wokół dowolnych dodatków. Opcja oszczędna rozwiązuje główny problem w najprostszy sposób: jeden proces, jeden zespół, stałe przekazanie. Opcja standardowa, którą wybierze, jak zakładasz, większość klientów, rozwiązuje główny problem gruntownie, z dodatkowymi elementami, które czynią rozwiązanie solidnym: zestawem ewaluacyjnym, przeszkolonym orędownikiem, kontrolą po czasie. Opcja pełna rozszerza rozwiązanie na sąsiednie problemy albo dodaje stałą opiekę. Każda opcja to prawdziwe, spójne zlecenie, które chętnie byś zrealizował.

Większość pracy wykonuje opcja środkowa. Kupujący unikają skrajności, więc środkowa często wygrywa, co oznacza, że powinieneś zaprojektować ją jako tę, którą najbardziej chcesz sprzedać: właściwą równowagę wartości, nakładu i rezultatu dla tego klienta. Opcja oszczędna sprawia, że środkowa wygląda rozsądnie. Opcja pełna pokazuje, co jest możliwe, i od czasu do czasu wybierają ją klienci, którzy chcą wersji kompletnej. Żadna z nich nie jest wabikiem. Obie są uczciwymi alternatywami.

Spraw, by różnice były jasne i łatwe do porównania. Krótka tabela, z rezultatami, harmonogramem i efektami każdej opcji obok siebie, pomaga kupującemu dokładnie zobaczyć, co zyskuje na każdym kolejnym stopniu. Unikaj długich list drobnych funkcji; skup się na różnicach, które mają znaczenie dla problemu kupującego. I trzymaj opisy w języku kupującego, o jego rezultatach, a nie o twoich czynnościach.

Jedna cena to test. Trzy opcje to menu. Ludzie wolą menu.

Claude może szybko naszkicować trzy opcje na podstawie podsumowania diagnostycznego i twoich szablonów ofert. Podaj mu problem, kontekst klienta, przydzielony budżet, jeśli go znasz, i swoje standardowe kształty zleceń, i poproś o trzy spójne opcje z tabelą porównawczą. Potem starannie zredaguj. Model chętnie wymyśli dodatki, żeby wypchać opcje; twoim zadaniem jest dopilnować, by każda była prawdziwym zleceniem, które dobrze zrealizujesz.

Jest też subtelna korzyść dla zakresowania. Projektowanie trzech opcji zmusza cię do jasnego przemyślenia, co jest rdzeniem, a co rozszerzeniem. Ta jasność pomaga podczas realizacji, bo wiesz dokładnie, co klient kupił, a czego nie. Kiedy przychodzi prośba o rozszerzenie zakresu odpowiadająca czemuś z opcji pełnej, którą odrzucił, możesz łagodnie na to wskazać. Klient już wie, co by to obejmowało.

W tym tygodniu przepisz następną ofertę tak, by miała trzy opcje zamiast jednej. Niech środkowa będzie tą, którą byś zarekomendował, i dopilnuj, by dwie pozostałe były naprawdę użytecznymi alternatywami. Przedstaw je obok siebie. Zauważ, czy rozmowa przesuwa się z tego, czy w ogóle współpracować, na to, którą wersję wybrać. Zwykle się przesuwa, i to dość szybko.

Pobieraj opłatę za rozpoznanie

Darmowe zakresowanie uczy kupujących traktować twoje myślenie jak próbkę. Kiedy spędzasz dni na badaniu problemu klienta, rozmowach z jego pracownikami i projektowaniu rozwiązania, wszystko przed jakąkolwiek umową, oddajesz najcenniejszą część pracy. Niektórzy kupujący wezmą tę pracę i wykorzystają ją sami albo przekażą tańszemu dostawcy. Inni po prostu nigdy się nie zdecydują, bo nic dla nich nie jest stawką. Płatne rozpoznanie odsiewa tych, którzy tylko oglądają i kopią w opony, a wynikającą z niego ofertę czyni znacznie trudniejszą do odrzucenia.

Rozróżnienie przebiega między rozmową a dochodzeniem. Rozmowa diagnostyczna jest rozmową: godzina, za darmo, wystarczająco, by zrozumieć problem w zarysie i ocenić, czy jest dopasowanie. Wszystko ponad to – szczegółowe wywiady, mapowanie procesów, analiza danych, pisemna rekomendacja – to dochodzenie, a dochodzenie to praca. Płatne rozpoznanie jest po prostu uczciwym przyznaniem tego faktu. Jest też w gruncie rzeczy płatnym audytem z części pierwszej pod inną nazwą, dopasowanym rozmiarem do konkretnego pytania.

Przedstawiaj rozpoznanie jako rezultat, a nie opłatę za twój czas. Krótkie zlecenie o stałym zakresie, które kończy się jasnym, pisemnym dokumentem: problem, jego koszt, opcje rozwiązania, rekomendowane podejście z zakresowanym zleceniem i mierzalnym rezultatem. Ten dokument jest dla klienta cenny niezależnie od tego, czy będzie dalej pracować z tobą. Mógłby zanieść go innemu dostawcy albo wykorzystać wewnętrznie. Większość tego nie robi, bo osoba, która go napisała, jest oczywistym kandydatem do jego realizacji.

Płatne rozpoznanie także radykalnie poprawia twoje oferty. Po kilku dniach porządnego dochodzenia rozumiesz problem na tyle dobrze, by ciasno określić zakres, pewnie go wycenić i uniknąć przykrych niespodzianek, które rujnują zlecenia o stałej cenie. Klient, który zainwestował w rozpoznanie, ma interes w tym, by na jego podstawie działać. Oferty po płatnym rozpoznaniu są przyjmowane znacznie częściej niż oferty po jednej darmowej rozmowie, bo obie strony wykonały pracę.

Darmowa rada jest warta tyle, ile kosztowała. Rozdawaj ją, a będzie traktowana jak próbka.

Niektórzy kupujący zaprotestują, zwłaszcza ci przyzwyczajeni do konsultantów, którzy zakresują za darmo. Spokojnie wyjaśnij różnicę: rozmowa diagnostyczna jest bezpłatna i cieszysz się z niej; szczegółowe dochodzenie to kawał pracy z wartościowym rezultatem. Zaproponuj zaliczenie części albo całości opłaty za rozpoznanie na poczet późniejszego zlecenia, jeśli zdecydują się w określonym czasie. To czyni decyzję łatwą dla poważnych kupujących i odsiewa tych, którzy od początku tylko zbierali darmowe pomysły.

Claude czyni rozpoznanie wydajnym. Synteza wywiadów, mapy procesów, analiza opcji i szkic rekomendacji mogą powstać szybko, a twój czas zostaje na osąd, która opcja jest właściwa. To znaczy, że możesz zaoferować wartościowe rozpoznanie w krótkim, stałym czasie, a to ułatwia jego zakup.

W tym tygodniu przyjrzyj się temu, jak obecnie zakresujesz zlecenia. Gdzie kończy się darmowa rozmowa, a zaczyna nieodpłatne dochodzenie? Wyznacz tę granicę, nazwij płatne rozpoznanie jako produkt z jasnym rezultatem i zaproponuj je następnemu potencjalnemu klientowi, który potrzebuje więcej niż jednej rozmowy, by porządnie określić zakres.

Zaliczka przed dostępami

Praca zaczyna się, gdy ruszają pieniądze. Ta prosta zasada eliminuje większość problemów z płatnościami, które w przeciwnym razie byś miał. Zaliczka – zwykle znacząca część honorarium, często połowa – płacona przed rozpoczęciem zlecenia to w wielu rodzajach pracy profesjonalnej standard. Prośba o nią jest czymś zupełnie zwyczajnym. Brak takiej prośby to prezent dla mniejszości klientów, którzy w przeciwnym razie płaciliby z opóźnieniem, częściowo albo wcale.

Przy małych zleceniach zaliczka robi więcej, niż tylko zabezpiecza płatność. Potwierdza zobowiązanie. Klient, który zapłacił zaliczkę, podjął prawdziwą decyzję, zaangażował osobę zatwierdzającą wydatki i ma interes w tym, by zlecenie dobrze wystartowało. Chętniej szybko zapewni dostępy, przyjdzie na spotkanie startowe, wskaże osobę decyzyjną i zaangażuje się w piątkowe dema. Klient, który nie zapłacił nic, może dryfować, zwlekać i zmieniać zdanie bez kosztów, a niektórzy tak zrobią.

Powiąż zaliczkę z datą startu. Zlecenie zaczyna się w uzgodnionym dniu, pod warunkiem że zaliczka wpłynęła, a lista kontrolna dostępów jest kompletna. Jeśli brakuje którejś z tych rzeczy, start się przesuwa. Łączy się to zgrabnie z rozdziałem o dostępach: zaliczka i dostępy to dwa warunki wstępne, a ty ścigasz oba w dniach poprzedzających start. Klient rozumie, że to on chroni harmonogram.

Proś o nią wprost. W umowie podaj wysokość zaliczki, termin jej płatności i to, co zabezpiecza: datę startu, twój czas zarezerwowany na zlecenie, prace przygotowawcze. Wyślij fakturę razem z umową. Nie przepraszaj za nią i nie chowaj jej. Profesjonalni kupujący są przyzwyczajeni do zaliczek i nie poświęcają im ani myśli. Jedyni kupujący, którzy mocno protestują, to najczęściej ci, od których zaliczki potrzebowałeś najbardziej.

Zaliczka nie jest oznaką nieufności. Jest oznaką, że obie strony się zdecydowały.

Pozostała kwota też powinna mieć jasny wyzwalacz. Przy przekazaniu, przy odbiorze na podstawie zestawu ewaluacyjnego albo w określonym terminie po dostawie: wybierz jedno i zapisz. Powiąż odbiór z uzgodnioną definicją ukończenia i progiem ewaluacji, żeby nie było wątpliwości, kiedy praca jest skończona i kiedy należy się zapłata. Jasne warunki na początku oznaczają łatwe rozmowy na końcu.

Przy abonamentach fakturuj z góry za każdy okres. Praca w danym miesiącu zaczyna się, gdy ten miesiąc jest opłacony. To utrzymuje abonamenty w porządku i zapobiega powolnemu narastaniu nieopłaconych miesięcy, które czasem psuje skądinąd dobrą relację.

Utrzymuj administrację finansową równie schludnie jak realizację. Proste, terminowe fakturowanie, z jasnymi opisami odwołującymi się do nazwanego zlecenia i jego rezultatów. Claude może pomóc w szkicowaniu umowy, opisów na fakturach i uprzejmych przypomnień na podstawie twoich szablonów. Konsultant, który ma porządek w pieniądzach, uspokaja, bo sugeruje, że ma porządek we wszystkim innym.

W tym tygodniu sprawdź swoje standardowe warunki. Jeśli nie zawierają zaliczki, dodaj ją, z wyraźnym powiązaniem z datą startu i dostępami. Jeśli zawierają, sprawdź, czy naprawdę je egzekwujesz. Za pierwszym razem, gdy wstrzymasz datę startu z powodu brakującej zaliczki, możesz poczuć się niezręcznie. Klient niemal zawsze po prostu ją zapłaci.

Wdrożenie plus abonament

Pobierz porządną opłatę za budowę, a potem pobieraj kolejną za utrzymanie przy życiu. Większość systemów z tej książki wymaga stałej opieki: promptów i skilli, które dostosowują się do zmian w firmie, zestawów ewaluacyjnych, które rosną, gdy pojawiają się nowe przypadki, usprawnień, gdy dostępne stają się lepsze modele, monitoringu, który wyłapuje spadek jakości, osoby, do której można zadzwonić, gdy coś się zepsuje. Opłata wstępna pokrywa pracę przy budowie. Opłata miesięczna pokrywa pracę przy utrzymaniu wartości. To przychody cykliczne zamieniają dochód wolnego strzelca w firmę.

Taką strukturę łatwo wyjaśnić klientom, bo odpowiada ich doświadczeniom z innymi usługami. Płacą za zainstalowanie czegoś, a potem płacą skromną stałą kwotę za utrzymanie i wsparcie. Tak działają subskrypcje oprogramowania i wiele usług profesjonalnych. Ważne jest, by obie części dostarczały jasnej, odrębnej wartości: wdrożenie dostarcza działający system; comiesięczna współpraca dostarcza ciągłą wydajność i usprawnienia.

Zdefiniuj comiesięczną współpracę precyzyjnie, tak jak część pierwsza zalecała to przy abonamentach. Comiesięczny przegląd jakości wyników względem zestawu ewaluacyjnego. Stała ilość pracy nad usprawnieniami. Aktualizacje, gdy zmieniają się modele albo narzędzia. Określony czas reakcji na problemy. Krótki pisemny raport co miesiąc, pokazujący, co system zrobił, co się zmieniło i co rekomendujesz dalej. Klienci odnawiają współpracę, której działanie widzą. Mgliste układy anulują przy pierwszym przeglądzie budżetu.

Wyceniaj opłatę miesięczną względem wartości, jak wszystko inne. System, który oszczędza zespołowi wiele godzin tygodniowo, jest wart opieki, a opłata miesięczna powinna odzwierciedlać wartość utrzymania go w działaniu, a nie tylko godziny, które spędzasz każdego miesiąca. Jednocześnie niech będzie skromna w stosunku do opłaty wstępnej, żeby wyglądała jak utrzymanie, a nie drugi zakup. Celem jest układ, o którym klienci prawie nie myślą, bo jest oczywiście tego wart.

Budowa opłaca miesiąc, w którym budowałeś. Opieka opłaca każdy kolejny.

Jest pewna dyscyplina realizacji, dzięki której jest to do utrzymania. Jeśli każdy klient abonamentowy wymaga nieustannej, indywidualnej uwagi, comiesięczna współpraca staje się pożeraczem czasu. Standaryzuj miesięczną pracę: ten sam proces przeglądu, ten sam szablon raportu, ten sam cykl usprawnień, wspierane przez skille i skrypty wykonujące rutynowe części. Claude może uruchomić zestaw ewaluacyjny, naszkicować miesięczny raport na podstawie logów i wskazać przypadki wymagające uwagi. Twój czas idzie na osąd i usprawnienia, nie na administrację.

Nie każde zlecenie potrzebuje comiesięcznej współpracy. Niektóre systemy są na tyle proste, że wystarczy im dobra instrukcja obsługi i przeszkolony orędownik. Zarekomenduj to uczciwie, gdy tak jest. Ale tam, gdzie system potrzebuje opieki, powiedz to w ofercie i uwzględnij w cenie od początku. Klient, który od początku wie, że system ma miesięczny koszt, planuje go. Klient, który dowiaduje się o tym przy przekazaniu, czuje się wprowadzony w błąd.

W tym tygodniu przyjrzyj się systemom, które dostarczyłeś, i zapytaj, które z nich skorzystałyby na stałej opiece. Dla każdego naszkicuj comiesięczną współpracę: co obejmuje, o czym raportuje, co usprawnia. Potem ją zaproponuj, zaczynając od klienta, który miał najlepsze wyniki. Najlepszy moment na zaproponowanie abonamentu to chwila, gdy dowody wartości są świeże.

Znaj swój koszt tokenów

Realizacja z agentami ma realny koszt krańcowy i łatwo go ignorować, dopóki nie zaboli. Każde wywołanie modelu coś kosztuje, a praca agentowa wymaga wielu wywołań: czytania plików, uruchamiania narzędzi, weryfikowania wyników, rozdzielania pracy na subagenty, iterowania aż do przejścia testu. Przez większość czasu koszt jest niewielki w stosunku do honorarium. Od czasu do czasu źle zakresowane zadanie albo nieefektywny proces zużywa znacznie więcej, niż się spodziewano, a twój sprint o stałej cenie po cichu staje się stratą o stałej cenie. Śledź wydatki na każde zlecenie.

Śledzenie nie jest trudne. Większość platform udostępnia raporty zużycia, a plany różnią się sposobem mierzenia i ograniczania zużycia, więc zrozum ten, z którego korzystasz. Przy zleceniach budowanych na API używaj osobnych kluczy albo przestrzeni roboczych dla każdego klienta, żeby koszty były jasno przypisane. Przy pracy w aplikacjach Claude i w Claude Code obserwuj zużycie podczas intensywnej pracy i notuj, które zadania pochłonęły najwięcej. Po kilku zleceniach wyrobisz sobie wyczucie, ile kosztuje dostarczenie każdego rodzaju pracy, a to czyni wycenę trafniejszą.

Większym problemem są systemy, które przekazujesz. Pilotaż agenta klienta, który przetwarza setki dokumentów dziennie, ma bieżący koszt działania, a klient musi go znać, zanim się zobowiąże. Oszacuj go podczas pilotażu, na podstawie rzeczywistego zużycia na prawdziwej pracy, i uwzględnij w przekazaniu i ofercie na następny etap. Klienci są zrozumiale niezadowoleni, gdy miesiąc po uruchomieniu odkrywają, że ich nowy system ma koszt działania, o którym nikt nie wspomniał.

Jest wiele sposobów na obniżenie kosztów bez obniżenia jakości. Używaj mniejszych, szybszych modeli do prostych kroków, a najbardziej zaawansowanych tylko tam, gdzie liczy się osąd. Utrzymuj szczupłe konteksty, jak zalecała część trzecia. Korzystaj z buforowania promptów tam, gdzie platforma to obsługuje, dla stałych instrukcji i materiałów referencyjnych. Zastępuj powtarzalną pracę modelu dołączonymi skryptami. Grupuj pracę, która nie jest pilna, tam, gdzie dostępne jest przetwarzanie wsadowe. Każdy z tych sposobów to także dobra inżynieria, więc optymalizacja kosztów i jakość zwykle wskazują ten sam kierunek.

Stała cena przy nieznanym koszcie to nie stała cena. To zakład, którego nie zamierzałeś zawierać.

Tam, gdzie ma to znaczenie, wbuduj koszt działania w strukturę cenową. Przy zarządzanych systemach w ramach abonamentu zdecyduj, czy klient płaci za zużycie bezpośrednio z własnego konta, co zwykle jest najczystsze, czy też uwzględniasz pewien limit w opłacie miesięcznej. Tak czy inaczej, powiedz to wprost. Niejasność co do tego, kto płaci za zużycie, to częste źródło tarć w zleceniach AI, a da się jej całkowicie uniknąć.

Nie pozwól, by lęk przed kosztami wypaczał twoją pracę. W większości mikrozleceń koszt korzystania z modeli jest skromny w porównaniu z dostarczoną wartością i pobranym honorarium. Celem śledzenia nie jest minimalizowanie każdego wywołania, lecz unikanie niespodzianek i trafna wycena. Wydawaj tam, gdzie to poprawia rezultat; przycinaj tam, gdzie nie.

W tym tygodniu przyjrzyj się zużyciu w swoim ostatnim zleceniu i oszacuj z grubsza, ile kosztowało jego dostarczenie w zużyciu modeli. Porównaj to z honorarium. Potem oszacuj miesięczny koszt działania przekazanego systemu i sprawdź, czy klient go zna. Jeśli którakolwiek z tych liczb cię zaskoczy, znalazłeś coś, co warto naprawić.

Podnoś przy odnowieniu

Każde odnowienie to okazja do nowej wyceny, a większość konsultantów ją pomija. Abonament zbliża się do odnowienia, klient jest zadowolony, a ścieżka najmniejszego oporu to kontynuować na tych samych warunkach. Tymczasem system się poprawił, twoje umiejętności się pogłębiły, dostarczana wartość wzrosła, a twoje koszty się zmieniły. Obecni klienci przyjmują podwyżki znacznie lepiej, niż mógłbyś się spodziewać, kiedy wyniki są udokumentowane, a podwyżka wyjaśniona.

Kluczem jest dokumentacja. Rozmowa o odnowieniu, która zaczyna się od miesięcznych raportów, wyników ewaluacji w czasie, wprowadzonych usprawnień i zmierzonego wpływu na pracę klienta, jest rozmową o wartości. W tym kontekście korekta honorarium jest naturalną częścią dyskusji, a nie niemiłą niespodzianką. Rozmowa o odnowieniu, w której nie ma czego pokazać, jest rozmową o koszcie, a w takiej rozmowie każda podwyżka wydaje się narzuceniem.

Zasygnalizuj to wcześnie. Na miesiąc czy dwa przed datą odnowienia wspomnij, że będziesz przeglądać współpracę i proponować ewentualne zmiany. Kiedy nadejdzie odnowienie, przedstaw przegląd: co system osiągnął, co się zmieniło, co proponujesz na kolejny okres, w tym wszelkie korekty zakresu i honorarium. Podaj powody. Może zakres się rozrósł, może wzrosła wartość, a może zmieniły się twoje stawki dla nowych klientów i stopniowo wyrównujesz je u obecnych. Jasne powody, spokojnie przedstawione, są zwykle akceptowane.

Rozważ połączenie podwyżki z czymś nowym. Odnowienie, które dodaje przydatną możliwość – kwartalną sesję strategiczną, rozszerzony zakres, dodatkowy proces – obok korekty honorarium, odbierane jest jako ulepszenie, a nie podwyżka ceny. Klient dostaje więcej, ty dostajesz uczciwszy zwrot, a relacja się rozwija, zamiast jedynie trwać.

Milczenie przy odnowieniu to też decyzja cenowa. Po prostu taka, której nie podjąłeś celowo.

Bądź w tym rozsądny. Duże, nagłe podwyżki niszczą zaufanie, a klienci, którzy czują się wyciskani, zaczynają szukać alternatyw. Umiarkowane, regularne, dobrze wyjaśnione korekty są znacznie trwalsze. A czasem właściwa odpowiedź to w ogóle nie podnosić: jeśli klient jest pod presją albo wartość nie wzrosła, utrzymanie honorarium bez zmian jest rozsądnym wyborem. Chodzi o to, by decydować świadomie, a nie domyślnie.

Odnowienia to również moment, by sprawdzić dopasowanie. Czy system stał się tak stabilny, że klient potrzebuje mniej opieki? Powiedz to i zaproponuj ograniczenie współpracy albo przejście na lżejszą formę. Taka uczciwość zostaje zapamiętana. Czy firma klienta urosła tak, że system potrzebuje więcej? Zaproponuj rozszerzenie. Odnowienie to naturalny punkt, by przekształcić relację tak, by odpowiadała rzeczywistości.

W tym tygodniu wypisz swoje cykliczne umowy i ich daty odnowienia. Dla każdej, która przypada w najbliższym kwartale, przygotuj krótki przegląd wartości: wyniki, usprawnienia, zakres, proponowane warunki. Potem przeprowadź rozmowę, wcześnie i spokojnie. Większość konsultantów, którzy tego próbują, jest zaskoczona, jak bardzo rutynowe się to okazuje.

Gotówka wygrywa z udziałami

Prędzej czy później jakiś start-up zaproponuje ci udziały zamiast honorarium. Brakuje mu gotówki, entuzjazmuje się przyszłością i jest pewien, że udziały będą warte znacznie więcej niż twoja faktura. Czasem będą. Zazwyczaj nie. Weź pieniądze. Prowadzisz firmę, a nie portfel inwestycji venture z jedną pozycją, a praktyka mikrokonsultingowa zależy od przepływów pieniężnych znacznie bardziej niż od spekulacyjnych zysków.

Arytmetyka jest dla udziałów przy małych zleceniach nieubłagana. Większość firm na wczesnym etapie nie odnosi sukcesu w sposób, na jaki liczą ich założyciele, a nawet te, które odnoszą, mogą potrzebować wielu lat, by przynieść jakikolwiek zwrot drobnym udziałowcom, a do tego czasu twój udział może zostać znacznie rozwodniony. Skromny kawałek firmy, która za kilka lat może coś będzie warta, a może nie, nie zastąpi honorarium, które opłaca twoje rachunki w tym miesiącu. To los na loterii, a losy na loterii to kiepska podstawa dla firmy.

Są też komplikacje praktyczne. Umowy dotyczące udziałów wymagają dokumentów prawnych, czasem porady podatkowej i starannych warunków dotyczących nabywania uprawnień i tego, co się stanie, jeśli firma zmieni kierunek. Przy dwutygodniowym zleceniu ten ciężar administracyjny jest zupełnie nieproporcjonalny do pracy. A udziały mogą tworzyć niezręczne bodźce: stajesz się inwestorem zainteresowanym wyborami firmy, co może komplikować niezależne doradztwo, które masz świadczyć.

Jeśli start-up naprawdę nie może zapłacić, są lepsze opcje niż udziały. Zakresuj mniejsze pierwsze zlecenie, które zmieści się w jego budżecie. Zaproponuj opcję oszczędną ze swojej oferty z trzema opcjami. Odrocz część honorarium do określonego kamienia milowego, na przykład następnej rundy finansowania, na jasnych warunkach. Albo po prostu uprzejmie odmów i pozostań w kontakcie, bo start-upy, którym się udaje, pamiętają konsultantów, którzy byli wobec nich uczciwi, i wracają, gdy mają środki.

Udziały to obietnica dotycząca przyszłości. Gotówka to fakt dotyczący teraźniejszości. Małe praktyki działają na faktach.

Są rzadkie wyjątki. Jeśli dobrze znasz założycieli, mocno wierzysz w firmę i stać cię na potraktowanie zlecenia jako inwestycji, którą możesz w całości stracić, niewielki komponent udziałowy obok obniżonego honorarium może być rozsądny. Ale traktuj to jako świadomą decyzję inwestycyjną, oddzieloną od twoich dochodów z doradztwa, i nigdy nie pozwól, by zastąpiła gotówkę, której twoja praktyka potrzebuje, by funkcjonować.

Szersza zasada wykracza poza start-upy. Uważaj na każdy układ, który zastępuje jasne honorarium czymś niepewnym: udziałem w przychodach z niesprawdzonych produktów, zapłatą w postaci rozgłosu, premią za sukces zależną od rezultatów, których nie kontrolujesz. Każde z nich ma swoje miejsce w szczególnych okolicznościach, ale żadne nie powinno stać się normą w praktyce zbudowanej na małych, stałych, niezawodnych zleceniach.

W tym tygodniu ustal swoją politykę wobec udziałów i innych niegotówkowych ofert, zanim przyjdzie następna. Zapisz ją: honoraria w gotówce jako standard; elementy odroczone tylko na jasnych warunkach; udziały tylko jako świadoma inwestycja poboczna. Posiadanie polityki ułatwia rozmowę i chroni cię przed podejmowaniem decyzji pod wpływem zaraźliwego optymizmu założyciela.

Zwolnij złych klientów

Klient, który płaci najmniej, a wymaga najwięcej, blokuje miejsce temu, który zapłaciłby najwięcej. Każda praktyka gromadzi kilku takich klientów: abonament wyceniony za nisko przed laty, klient, który każdą interakcję traktuje jak negocjacje, ten, którego zakres rozrasta się mimo wszelkich protokołów, ten, który zawsze płaci późno i zawsze wcześnie się skarży. Pochłaniają czas, uwagę i energię nieproporcjonalnie do swojej wartości. Higiena portfela klientów to strategia wzrostu, a nie luksus.

Argument to prosta arytmetyka. Twoje możliwości są ograniczone. Każda godzina spędzona na kliencie, który cię drenuje, to godzina niespędzona na kliencie, który cię nagradza, albo na marketingu, rozwoju produktów i nauce, które przyciągnęłyby lepszych klientów. Małe praktyki odczuwają to dotkliwie, bo nie ma zespołu, który wchłonąłby koszt. Jeden zły klient może zajmować znaczną część tygodnia konsultanta działającego w pojedynkę i większość jego zmartwień.

Przeglądaj swoich klientów regularnie, na przykład co kwartał. Przy każdym rozważ przychód, czas, jaki zajmuje, to, jak przyjemnie i rozsądnie się z nim pracuje, czy płaci terminowo, czy praca jest ciekawa i czy do czegoś prowadzi: poleceń, studiów przypadku, nowych umiejętności. Rozmieść ich z grubsza na wykresie. Większość klientów będzie w porządku. Kilku będzie znakomitych. Jeden czy dwóch będzie wyraźnie kosztować cię więcej, niż daje.

W przypadku tego jednego czy dwóch spróbuj najpierw naprawić relację. Przy odnowieniu wyceń współpracę na nowo, zresetuj zakres, przywróć protokoły, które się rozluźniły. Czasem szczera rozmowa całkowicie odmienia relację z klientem. Jeśli nie, pozwól mu odejść, profesjonalnie i uprzejmie. Daj odpowiednie wypowiedzenie, dokończ bieżące zobowiązania, przekaż wszystko, jak zalecała część siódma, i może zasugeruj innego dostawcę, który lepiej do niego pasuje. Rozstań się w dobrej atmosferze; świat jest mały.

Mówienie „nie” niewłaściwemu klientowi to sposób na zrobienie miejsca, by powiedzieć „tak” właściwemu.

Obawa zawsze dotyczy utraconych przychodów. W praktyce czas uwolniony przez odejście złego klienta często szybko się zapełnia, i to lepszą pracą, bo masz teraz możliwości i energię, by o nią zabiegać. Ulga też jest spora. Konsultanci, którzy rozstali się z wyczerpującym klientem, często mówią, że żałują, iż nie zrobili tego wcześniej.

Lepiej zapobiegać, niż leczyć. Nawyki z tej książki – jasny zakres, zaliczki, notki o zmianach, odbiór na podstawie ewaluacji, udokumentowane wyniki – odsiewają wielu trudnych klientów, zanim staną się trudnymi relacjami. Płatne rozpoznanie albo audyt jako pierwsze zlecenie pokazuje ci, jak się z klientem pracuje, zanim zobowiążesz się do dłuższej relacji. Korzystaj z tej informacji. Nie każdemu klientowi, który kupuje audyt, należy proponować abonament.

W tym tygodniu wypisz obecnych klientów i uczciwie oceń każdego pod względem wartości i wysiłku. Wskaż tego, który kosztuje cię najwięcej przy najmniejszym zwrocie. Zdecyduj, czy relację da się naprawić, czy należy ją zakończyć, i zrób pierwszy krok. Potem zauważ, o ile lżejszy wydaje się następny tydzień.

Studium przypadku z każdego zlecenia

Napisz studium przypadku, póki liczby są ciepłe, a klient zachwycony. Problem, podejście, wynik, zdanie od klienta: dwadzieścia minut na koniec zlecenia i masz dowód, z którego możesz korzystać przez dwa lata. Odłóż to o miesiąc, a liczby się zamażą, klient zajmie się innymi priorytetami, a studium przypadku nigdy nie powstanie. Każde zlecenie, które kończysz bez niego, to wyrzucony dowód.

Struktura jest prosta i działa. Problem, w kategoriach klienta: co szło nie tak, jak często i jakim kosztem. Podejście: co zrobiłeś, krótko, bez żargonu, z naciskiem na kształt zlecenia, żeby czytelnik mógł sobie wyobrazić, że kupuje to samo. Wynik: zmierzone „przed” i „po” z zamknięcia zlecenia, podane wprost. I, za zgodą klienta, krótki komentarz od niego o tym, co się zmieniło. Wystarczy jedna strona. Krócej często znaczy lepiej.

Claude sprawia, że nie wymaga to niemal żadnego wysiłku, jeśli prowadziłeś dobrą dokumentację. Podsumowanie diagnostyczne, zakres, notatki z piątkowych dem, wyniki ewaluacji i podsumowanie zamknięcia zawierają wszystko, co potrzebne. Daj je Claude’owi razem ze swoim szablonem studium przypadku i poproś o szkic prostym, konkretnym językiem. Sprawdź go pod kątem zgodności z faktami, usuń wszystko, co poufne, i wyślij klientowi do zatwierdzenia. Większość klientów chętnie zatwierdza studium przypadku, w którym wypadają rozsądnie i nowocześnie, a dobre studium właśnie tak ich przedstawia.

Zgoda i poufność mają znaczenie. Na początku zlecenia, najlepiej w umowie, uzgodnij, że możesz napisać studium przypadku, pod warunkiem zatwierdzenia tekstu przez klienta. Niektórzy klienci będą chcieli być wymienieni z nazwy; inni wolą anonimowość, a wtedy opisz ich przez branżę i wielkość. Nigdy nie publikuj liczb ani szczegółów, których klient nie zatwierdził, i nigdy nie umieszczaj niczego, co mogłoby zidentyfikować jego klientów albo pracowników bez wyraźnej zgody.

Zakończone zlecenie bez studium przypadku to sprzedaż, którą zrobiłeś raz, zamiast wiele razy.

Korzystaj z nich wszędzie. Na swojej stronie internetowej, pogrupowane według rodzaju zlecenia, żeby potencjalny klient szukający audytu mógł poczytać o audytach. W ofertach, wybierając jedno czy dwa najbardziej związane z branżą i problemem klienta. W mailach z analizami i w wystąpieniach. W rozmowach, jako historie: praktyka bardzo podobna do waszej miała ten sam problem; oto, co zrobiliśmy i co się stało. Konkretne, świeże studia przypadków należą do najbardziej przekonujących rzeczy, jakie może zaoferować mały konsultant, bo zastępują obietnicę precedensem.

Z czasem twoje studia przypadków tworzą bibliotekę, która mówi ci też coś o twojej praktyce. Które zlecenia dają najsilniejsze wyniki? Które branże reagują najlepiej? Które oferty prowadzą do abonamentów? Czytanie własnych studiów przypadków razem to zaskakująco przydatne ćwiczenie strategiczne, którego większość konsultantów nigdy nie wykonuje, bo nigdy ich nie spisała.

W tym tygodniu napisz studium przypadku swojego ostatniego zakończonego zlecenia, według czteroczęściowej struktury. Jeśli brakuje ci liczb, poproś klienta o uczciwe oszacowanie i zaznacz, że to oszacowanie. Wyślij do zatwierdzenia. Potem dodaj napisać studium przypadku do ostatniego dnia swojego szablonu zlecenia, żeby działo się to za każdym razem, póki zachwyt jest świeży.

Polecenia z premedytacją

Proś o polecenia w chwili największego zachwytu i proś o coś konkretnego. Mgliste prośby, by klient o tobie pamiętał, dają dokładnie nic, na zawsze. Klienci mają dobre intencje, gdy mówią, że wspomną o tobie znajomym, a potem są zajęci i chwila mija. Konkretna prośba we właściwym momencie daje przedstawienia. Polecenia nie zdarzają się przypadkiem na tyle często, by można było na nich zbudować praktykę. Zdarzają się z premedytacją.

Chwilę największego zachwytu zwykle łatwo dostrzec. Końcowe demo, kiedy klient widzi gotowy system i zmierzony wynik. Pierwszy raz, gdy system radzi sobie z problemem, który dotąd rujnował komuś popołudnie. Wiadomość od orędownika, że zespół jest zachwycony. W tej chwili życzliwość klienta jest u szczytu, a wartość twojej pracy jest żywa. Wtedy trzeba prosić, a nie miesiąc później, gdy wszystko stało się normalne.

Niech prośba będzie konkretna. Nie jeśli znasz kogoś, kto mógłby być zainteresowany, tylko kogo jeszcze znasz, kto prowadzi praktykę taką jak twoja i ma ten sam ból głowy na koniec miesiąca? Albo czy jest ktoś w twoim stowarzyszeniu branżowym, kogo zainteresowałby ten wynik? Albo czy byłbyś gotów przedstawić mnie kierownikowi operacyjnemu w waszej siostrzanej spółce? Konkretne pytanie skłania klienta do pomyślenia o konkretnej osobie. Mgliste skłania go do powiedzenia „jasne” i niepomyślenia o nikim.

Ułatw mu działanie. Zaproponuj krótką notkę do przesłania dalej, opisującą, co zrobiłeś i dla kogo, którą może wysłać z jednym zdaniem od siebie. Zaproponuj, że napiszesz za niego maila z przedstawieniem, który on tylko poprawi. Zaproponuj swoje studium przypadku jako załącznik. Im mniej wysiłku wymaga polecenie, tym bardziej prawdopodobne, że do niego dojdzie. Claude może szybko szkicować takie notki, dopasowane do każdego klienta i osoby, o której myśli.

Klienci chcą ci pomóc. Trzeba im tylko powiedzieć jak, kiedy i komu.

Dziękuj za każde polecenie, niezależnie od tego, czy prowadzi do pracy. Krótka, osobista notka i informacja, jeśli przedstawienie zamieni się w zlecenie. Ludzie lubią wiedzieć, że ich pomoc miała znaczenie, a ci, którym podziękowano, zwykle polecają ponownie. Niektórzy konsultanci oferują drobny gest wdzięczności za polecenia, które zamieniły się w zlecenia; czy ty to robisz, to kwestia gustu i norm w twojej branży. Szczere podziękowanie nigdy nie jest błędem.

Projektuj zlecenia tak, by wytwarzały momenty do poleceń. Piątkowe dema, zmierzone zamknięcie, przeszkolony orędownik, studium przypadku: każde z nich tworzy chwilę zachwytu i naturalną okazję. Format mikrozleceń ogromnie tu pomaga, bo krótkie zlecenia często dają momenty ukończenia, a każde ukończenie to okazja, by poprosić. Praktyka zbudowana na stałym strumieniu małych, ukończonych, udanych zleceń to praktyka z wieloma takimi momentami w każdym roku.

W tym tygodniu pomyśl o swoim obecnym albo ostatnim kliencie. Wskaż moment zachwytu, przeszły lub nadchodzący. Napisz konkretną prośbę o polecenie i krótką notkę do przesłania dalej. Potem poproś, w tym właśnie momencie, o jedno konkretne przedstawienie. Śledź, ile przedstawień przyniesie to podejście w ciągu kolejnych miesięcy w porównaniu z mglistymi prośbami, które zwykłeś wysyłać.

Mail z analizą

Wykonaj pracę przed spotkaniem. Mail z analizą to konkretna, nieomylnie szyta na miarę analiza prawdziwego problemu potencjalnego klienta, wysłana przed jakąkolwiek rozmową, bez żadnej prośby poza odpowiedzią. Pokazuje, zamiast mówić: oto, co zauważyłem w twojej firmie, oto, co można by poprawić, oto mniej więcej jak. Odsetek odpowiedzi na tego rodzaju korespondencję w niczym nie przypomina zwykłych zimnych maili, bo taki mail nie czyta się jak zimny mail. Czyta się jak wiadomość od kogoś, kto już zaczął pomagać.

To w rozpoznaniu Claude zmienia ekonomię. Wybierz potencjalnego klienta w swojej branży. Zbierz to, co publiczne: jego stronę internetową, opublikowane procesy, ogłoszenia o pracę, opinie klientów, media społecznościowe, formularze zapytań. Poproś Claude’a o przeanalizowanie tego pod kątem szans, którymi umiesz się zająć: procesu obsługi zapytań, który wygląda na ręczny, skarg klientów na powolne odpowiedzi, ogłoszenia o pracę opisującego zadania, które dałoby się wspomóc, dokumentacji, którą trudno znaleźć. Potem użyj swojego osądu, by wybrać jedną czy dwie, które są prawdziwe, konkretne i mieszczą się w twojej ofercie.

Napisz analizę krótko. Kilka akapitów: co zauważyłeś, dlaczego to prawdopodobnie dla nich ważne, jak mogłaby wyglądać mała poprawka i jaki wynik mogłaby przynieść. Dołącz coś konkretnego, może szybki prototyp, próbkę lepszej odpowiedzi, jednostronicowy szkic przeprojektowanego procesu. Zakończ prostym pytaniem: czy warto byłoby o tym porozmawiać? Bez załączników pełnych referencji, bez długiego wstępu o sobie. Praca jest przedstawieniem.

Uważaj na ton. Analiza, która czyta się jak krytyka, zostanie zignorowana albo wywoła niechęć. Przedstawiaj to jako szansę, a nie porażkę: zauważyłem, że wasz formularz zapytań prosi na wstępie o wiele szczegółów; oto sposób, który mógłby zamienić więcej odwiedzających w klientów i zaoszczędzić czas waszego zespołu. Bądź dokładny: wskazuj tylko to, co faktycznie zaobserwowałeś, i przyznaj, czego nie widać z zewnątrz. Potencjalni klienci od razu poznają, czy ktoś naprawdę przyjrzał się ich firmie, czy tylko wypełnił szablon.

Zimny mail prosi o uwagę. Mail z analizą płaci za nią z góry.

Celem nie jest ilość. Kilka naprawdę szytych na miarę analiz tygodniowo, starannie przygotowanych i dobrze wycelowanych, przyniesie więcej rozmów niż setki ogólnikowych wiadomości. Claude sprawia, że rozpoznanie jest na tyle szybkie, iż dobra analiza zajmuje może godzinę, a to rozsądna inwestycja w potencjalnego klienta, który może stać się długoletnim. Trzymaj szablon struktury, ale nigdy nie pozwól, by treść stała się ogólnikowa.

Szanuj przepisy obowiązujące w twojej jurysdykcji i preferencje potencjalnych klientów. Korespondencja biznesowa w wielu miejscach podlega regulacjom, a dobra praktyka to wysyłać do właściwej osoby kontaktowej w firmie, jasno się przedstawić i ułatwić odmowę. Analiza, która szanuje czas i wybór odbiorcy, ma znacznie większą szansę na życzliwe przyjęcie.

W tym tygodniu wybierz trzech potencjalnych klientów ze swojej niszy. Przy każdym spędź godzinę z Claude’em na analizie ich publicznych materiałów, wskaż jedną konkretną szansę i napisz krótką analizę z dołączonym czymś konkretnym. Wyślij. Zanotuj odpowiedzi. Nawet te, które mówią nie teraz, są zwykle ciepłe, a nie teraz ma zwyczaj zamieniać się po kilku miesiącach w teraz.

Wypuść darmowe narzędzie

Małe, przydatne narzędzie w twojej niszy to najlepsza wizytówka, jaką kiedykolwiek wymyślono. Kwalifikuje potencjalnych klientów, pokazuje kompetencje i pracuje, gdy śpisz. Kalkulator, który szacuje, ile czasu praktyka poświęca na konkretne zadanie. Sprawdzarka, która ocenia dokument pod kątem popularnego standardu. Generator, który przygotowuje pierwszą wersję czegoś, czego twoi kupujący regularnie potrzebują. Każde z nich jest przydatne samo w sobie, pokazuje, co potrafisz zbudować, i przyprowadza do twoich drzwi właściwych ludzi.

Ekonomia zmieniła się na korzyść takiego podejścia. Zbudowanie dopracowanego narzędzia o jednym przeznaczeniu zajmowało kiedyś tygodnie programowania. Z Claude’em skupione narzędzie zbudowane jako jednoplikowy artefakt można zaprojektować, zbudować i opublikować w dzień czy dwa. Ograniczeniem nie jest już budowanie; jest nim wybór właściwego narzędzia. A ten wybór wynika wprost z twojej wiedzy branżowej: czego twoi kupujący potrzebują wielokrotnie, co uważają za żmudne i za co byliby wdzięczni, gdyby dostali to za darmo?

Wybieraj narzędzia powiązane z twoimi płatnymi ofertami. Narzędzie, które szacuje czas poświęcany przez zespół na ręczne raportowanie, w naturalny sposób łączy się ze zleceniem naprawy procesu. Narzędzie oceniające gotowość firmy na AI łączy się z płatnym audytem. Narzędzie generujące pierwszą wersję regulaminu łączy się ze sprintem dokumentacyjnym. Darmowe narzędzie rozwiązuje mały problem i ujawnia większy, który akurat ty potrafisz rozwiązać. To nie sztuczka; to po prostu przydatna kolejność.

Spraw, by narzędzie było naprawdę przydatne bez podawania danych kontaktowych. Zamykanie każdego darmowego narzędzia za formularzem rejestracji zmniejsza korzystanie i irytuje ludzi, na których najbardziej chcesz zrobić wrażenie. Pozwól korzystać z niego swobodnie i zaproponuj opcjonalny następny krok: bardziej szczegółowy raport mailem, krótką rozmowę o wyniku, link do odpowiedniego studium przypadku. Potencjalni klienci, którzy zrobią ten krok, to ci, którzy najprawdopodobniej kupią, a przychodzą już przekonani, że wiesz, co robisz.

Narzędzie, które komuś pomaga dziś, zostaje zapamiętane, kiedy jutro ten ktoś ma budżet.

Niech będzie skupione, jak przekonywał rozdział o jednym artefakcie na jedno pytanie. Narzędzie, które dobrze odpowiada na jedno pytanie, jest udostępniane dalej; narzędzie, które próbuje robić wszystko, jest porzucane. Nadaj mu jasną nazwę opisującą, co robi, umieść je tam, gdzie znajdą je twoi kupujący, i wspominaj o nim w analizach, wystąpieniach i wpisach. Obserwuj, jak ludzie z niego korzystają, i od czasu do czasu je ulepszaj. Małe narzędzie, które pozostaje aktualne i dokładne, pracuje dla ciebie bardzo długo.

Uważaj na to, co narzędzie obiecuje. Kalkulator, który podaje szacunki, powinien wyraźnie mówić, że to szacunki, i wyjaśniać założenia. Sprawdzarka powinna jasno mówić, co sprawdza, a czego nie. Przesadne obietnice w darmowym narzędziu podkopują tę samą wiarygodność, którą miało budować.

W tym tygodniu pomyśl o jednym pytaniu, które twoi kupujący zadają najczęściej, a na które proste narzędzie mogłoby pomóc odpowiedzieć. Zbuduj z Claude’em pierwszą wersję jako jednoplikowy artefakt. Przetestuj ją z kimś z twojej niszy. Jeśli uzna ją za przydatną, opublikuj ją i zacznij o niej wspominać. Jeśli nie, zapytaj, co byłoby przydatniejsze, i zbuduj to zamiast niej.

Buduj publicznie

Co tydzień dostarczaj coś widocznego i pozwól, by praca szukała klientów za ciebie. Kupujący zatrudniają osobę, której pracę obserwują już od trzech miesięcy. Budowanie publicznie oznacza dzielenie się pracą w trakcie jej wykonywania: narzędziami, które budujesz, problemami, które rozwiązujesz, lekcjami, których się uczysz, eksperymentami, które się udały, i tymi, które się nie udały. Z czasem ten stały strumień widocznej pracy buduje reputację, której nie kupi żadna reklama.

Czym się dzielić, zależy od twojej niszy i poufności twoich klientów. Nie możesz publikować pracy dla klienta bez zgody, ale możesz dzielić się mnóstwem rzeczy wokół niej. Nowym darmowym narzędziem. Techniką, którą dopracowałeś. Krótkim opisem problemu częstego w twojej branży i tego, jak do niego podchodzisz. Syntetycznym przykładem procesu, który naprawiłeś, odbudowanym na danych przykładowych. Lekcją z pilotażu, zanonimizowaną. Skillem, który udostępniłeś otwarcie. Każdy taki element pokazuje, jak myślisz i co potrafisz.

Regularność ma większe znaczenie niż błyskotliwość. Jeden przydatny wpis albo małe wydanie co tydzień, przez całe miesiące, jest znacznie skuteczniejsze niż okazjonalny wybuch aktywności. Ludzie, którzy w końcu cię zatrudnią, obserwują po cichu; muszą widzieć, jak pojawiasz się regularnie, wykonując dobrą pracę, aż staniesz się oczywistą osobą, do której się dzwoni. Claude pomaga w produkcji: zamienia twoje notatki w czytelny wpis, buduje małe demonstracje, szkicuje podsumowania. Osąd, czym warto się podzielić, pozostaje twój.

Dziel się tam, gdzie naprawdę są twoi kupujący. W niektórych niszach to sieć zawodowa. W innych forum branżowe, newsletter, grupa społecznościowa albo specjalistyczna publikacja. Budowanie publicznie w miejscu, którego twoi kupujący nigdy nie odwiedzają, to hobby, a nie lejek sprzedażowy. Dowiedz się, gdzie czytają twoi kupujący, i pojawiaj się tam z przydatną pracą, regularnie.

Widoczność nie jest próżnością, gdy to, co widać, jest przydatne. Jest po prostu bardzo powolną i bardzo skuteczną rozmową handlową.

Budowanie publicznie poprawia też samą pracę. Wyjaśnianie, co zrobiłeś, zmusza cię do jasnego zrozumienia tego. Uwagi kolegów po fachu ulepszają twoje metody. Pytania potencjalnych klientów ujawniają, na czym naprawdę zależy twojemu rynkowi. A archiwum publicznej pracy staje się zasobem, do którego możesz odsyłać potencjalnych klientów: oto jak podchodzę do tego problemu; oto narzędzie, które do tego zbudowałem; oto co się stało, kiedy to wypróbowałem.

Są uczciwe ograniczenia. Budowanie publicznie zajmuje czas i może odciągać od płatnej pracy. Ustal skromny, zrównoważony rytm, może godzinę czy dwie tygodniowo, i chroń go, nie pozwalając mu się rozrosnąć. I pamiętaj, że celem jest bycie przydatnym, a nie występowanie. Wpisy pisane po to, by zaimponować innym konsultantom, rzadko przyciągają klientów. Wpisy, które rozwiązują prawdziwy problem kupującego, często to robią.

W tym tygodniu zdecyduj, czym będziesz się dzielić co tydzień przez najbliższe trzy miesiące i gdzie. Potem podziel się pierwszą rzeczą. Prowadź prostą listę tego, czym się podzieliłeś. Za trzy miesiące spójrz wstecz na tę listę i na rozmowy, które z niej wynikły. W pierwszych tygodniach wyniki rzadko są spektakularne, a pod koniec zwykle są nie do przeoczenia.

Wystąp na spotkaniu branżowym

Dwadzieścia zaangażowanych osób w sali wygrywa z dwoma tysiącami wyświetleń w sieci. Lokalne grupy biznesowe, stowarzyszenia branżowe, wydarzenia izb gospodarczych i spotkania branżowe są pełne ludzi z budżetami i problemami, zebranych specjalnie po to, by nauczyć się czegoś przydatnego. Krótkie, praktyczne wystąpienie na takim wydarzeniu przynosi zaskakująco dobre wyniki, bo każdy tam obecny już postanowił poświęcić czas temu tematowi, a ty jesteś osobą, która właśnie pokazała mu coś, czego może użyć.

Najlepsze wystąpienia są praktyczne, konkretne i krótkie. Nie przyszłość AI w biznesie, o której każdy uczestnik słyszał już kilka razy, tylko jak praktyka taka jak wasza może skrócić zamknięcie miesiąca o dzień narzędziem, które kosztuje mniej niż lunch, z demonstracją na żywo na realistycznych danych. Pokaż jedną czy dwie działające rzeczy. Daj publiczności coś, co może wypróbować jeszcze tego wieczoru. Zostaw czas na pytania, bo to od pytań zaczynają się prawdziwe rozmowy.

Budowanie na sali, jak opisywała część szósta, jest na spotkaniu branżowym szczególnie skuteczne. Poproś publiczność o problem, z którym się mierzy, i rozwiąż jego małą wersję na żywo z Claude’em. Nie musi to być nic wyszukanego. Szkic odpowiedzi na trudny mail od klienta, streszczenie długiego regulaminu, szybkie narzędzie wykonujące obliczenie, które dziś robią ręcznie. Publiczność widzi możliwości na własnym rodzaju problemu, w czasie rzeczywistym, i wielu z nich będzie chciało potem z tobą porozmawiać.

Przygotuj dalszy kontakt przed wystąpieniem. Krótką stronę z głównymi punktami, zademonstrowanymi promptami i linkiem do twojego darmowego narzędzia albo odpowiednich studiów przypadków. Łatwy sposób na umówienie krótkiej rozmowy. Niewielką liczbę terminów na rozmowy diagnostyczne w kolejnych tygodniach. Wystąpienie budzi zainteresowanie; dalszy kontakt zamienia je w rozmowy. Bez niego zainteresowanie wyparowuje w ciągu kilku dni.

Sala z dwudziestoma osobami, które mają ten sam problem, to najlepsza publiczność, jaką specjalista kiedykolwiek będzie miał.

Organizatorzy lokalnych grup często szukają prelegentów, zwłaszcza takich, którzy mają do powiedzenia coś praktycznego. Zwróć się do nich z jasną, konkretną propozycją wystąpienia, istotną dla ich członków, z obietnicą praktycznych wniosków i bez prezentacji handlowej. Potem dotrzymaj tej obietnicy: wystąpienie, które zamienia się w reklamę, traci salę i życzliwość organizatora. Sprzedaż dzieje się potem, w rozmowach, bo byłeś przydatny.

Wystąpienia procentują. Dobre wystąpienie prowadzi do zaproszeń, by wygłosić je gdzie indziej. Nagrania albo spisane wersje stają się częścią twojej publicznej pracy. Uczestnicy stają się klientami, klienci studiami przypadków, a studia przypadków przykładami w twoim następnym wystąpieniu. Specjalista, który co miesiąc czy dwa wygłasza przydatne wystąpienie w swojej niszy, w ciągu roku będzie w niej szeroko znany, a to dokładnie ta pozycja, którą zaleca ta książka.

W tym tygodniu znajdź dwie czy trzy grupy, w których spotykają się twoi kupujący. Naszkicuj praktyczne dwudziestominutowe wystąpienie z jedną demonstracją na żywo i jedną techniką do zabrania do domu. Zwróć się do organizatora. Potem przygotuj stronę do dalszego kontaktu i link do umawiania rozmów przed terminem wydarzenia, żeby zainteresowanie, które wzbudzisz, miało dokąd pójść.

Zdobądź wyszukiwania w swojej niszy

Bądź wymieniony wszędzie tam, gdzie szuka twój konkretny kupujący. Katalogi, strony partnerów, marketplace’y, listy stowarzyszeń, ekosystemy dostawców. Nudna dystrybucja wygrywa z błyskotliwymi treściami, których nikt nie znajduje. Kupujący z twojej niszy, który postanawia poszukać pomocy z AI, nie zaczyna od czytania tekstów eksperckich. Wyszukuje, pyta swoje stowarzyszenie, sprawdza stronę partnerów oprogramowania, z którego już korzysta, albo przegląda marketplace zatwierdzonych dostawców. Jeśli cię tam nie ma, nie jesteś brany pod uwagę.

Zacznij od zmapowania, gdzie szukają twoi kupujący. Zapytaj obecnych klientów, jak szukaliby kogoś takiego jak ty, gdyby musieli zaczynać od nowa. Przyjrzyj się oprogramowaniu powszechnie używanemu w twojej niszy i sprawdź, czy jego dostawcy prowadzą listy partnerów wdrożeniowych albo konsultantów. Sprawdź, czy stowarzyszenia zawodowe w branży prowadzą listy zatwierdzonych dostawców. Znajdź marketplace’y, na których firmy z twojej niszy kupują usługi. Każde z tych miejsc to drzwi, przez które przychodzą kupujący, już zakwalifikowani i już szukający.

Potem zadbaj o porządny wpis. Jasny, konkretny profil, który mówi dokładnie, co robisz i dla kogo: nie konsultant AI, tylko naprawy procesów i audyty AI dla małych biur rachunkowych. Twoje nazwane oferty, krótko opisane. Dwa czy trzy odpowiednie studia przypadków. Jasne następne kroki. Wiele wpisów jest darmowych albo tanich; niektóre wymagają zgłoszenia albo akredytacji. Wysiłek jest skromny, a wpisy, okazjonalnie aktualizowane, pracują latami.

Liczy się też twoja własna strona internetowa i powinna być zbudowana pod wyszukiwania, które naprawdę wykonują twoi kupujący. Strona dla każdej nazwanej oferty, napisana językiem twoich kupujących, odpowiadająca na pytania, które zadają. Studia przypadków pogrupowane według branży i rodzaju zlecenia. Twoje darmowe narzędzie, łatwe do znalezienia. Claude może pomóc ci szkicować i dopracowywać te strony, ale konkret musi pochodzić z twojej znajomości niszy. Ogólnikowe strony przyciągają ogólnikowych odwiedzających; konkretne strony przyciągają kupujących.

Najlepsze treści na świecie przegrywają ze zwykłym wpisem w tym jednym miejscu, w którym twój kupujący naprawdę szukał.

Wyszukiwanie oparte na AI także zmienia sposób, w jaki kupujący znajdują dostawców. Ludzie coraz częściej proszą asystenta, by polecił kogoś do konkretnej potrzeby. Ci asystenci czerpią z tego, co o tobie opublikowano i gdzie jesteś wymieniony. Jasne, konkretne, spójne opisy tego, co robisz, dla kogo, z dowodami wyników, na twojej stronie i we wpisach, zwiększają szansę, że zostaniesz znaleziony i trafnie opisany. Zasady są te same co przy wyszukiwaniu przez ludzi: bądź konkretny, bądź spójny, bądź obecny.

Dbaj o swoje wpisy. Nieaktualne profile, zepsute linki i stare studia przypadków sugerują praktykę, która nie zwraca uwagi, a to przeciwieństwo tego, co chcesz przekazać. Ustaw sobie co kwartał przypomnienie, by przejrzeć i zaktualizować każdy wpis. Zajmuje to godzinę i utrzymuje drzwi otwarte.

W tym tygodniu wypisz każde miejsce, w którym kupujący z twojej niszy mógłby szukać pomocy takiej jak twoja. Sprawdź, czy jesteś obecny w każdym z nich. Wybierz trzy najważniejsze, w których cię nie ma albo jesteś słabo reprezentowany, i napraw to. Potem zapytaj następnego nowego klienta, jak cię znalazł. Jego odpowiedź powie ci, które drzwi działają.

Opublikuj listę oczekujących

Ograniczenia możliwości są realne i warto o nich mówić. Mikrokonsultant może prowadzić naraz tylko określoną liczbę zleceń. Kiedy masz pełny kalendarz, odruchem jest to ukryć, bo wydaje się, że odprawiasz klientów, albo bo brzmi to jak przechwałka. Zamiast tego opublikuj to. Widoczna lista oczekujących, z najbliższą dostępną datą startu, przestawia rozmowę z tego, czy cię zatrudnić, na to, kiedy możesz zacząć.

Psychologia jest prosta. Konsultant, który może zacząć jutro, budzi małe, niewypowiedziane pytanie: dlaczego jest dostępny? Konsultant, którego najbliższa data startu jest za kilka tygodni, sygnalizuje, że inni już go wybrali i że jego czas jest cenny. Pytanie kupującego przesuwa się z czy powinniśmy zatrudnić tę osobę? na czy powinniśmy zarezerwować termin, zanim zrobi to ktoś inny? To dla ciebie znacznie lepsze pytanie i całkowicie uczciwe, jeśli twój kalendarz naprawdę jest pełny.

Niech lista oczekujących będzie praktyczna. Podaj najbliższą dostępną datę startu dla każdego rodzaju zlecenia na swojej stronie albo w odpowiedziach. Zaproponuj prosty sposób rezerwacji terminu, na przykład z niewielką zaliczką zaliczaną na poczet honorarium. Utrzymuj kontakt z osobami z listy, dzieląc się przydatnymi materiałami i potwierdzając datę startu, gdy się zbliża. Niektórzy konsultanci oferują płatny audyt albo rozpoznanie jako sposób na rozpoczęcie przed otwarciem terminu na główne zlecenie, co podtrzymuje impet, gdy kupujący czeka.

Format mikrozleceń ułatwia zarządzanie tym. Ponieważ zlecenia są krótkie i stałe, możesz z rozsądną pewnością przewidzieć swoje możliwości. Wiesz, że dwutygodniowy sprint zajmuje dwa tygodnie, że możesz prowadzić ich naraz tyle a tyle i kiedy zwalnia się każdy termin. Praktyka zbudowana na otwartych zleceniach nigdy nie opublikuje wiarygodnej listy oczekujących, bo nikt nie wie, kiedy cokolwiek się kończy.

Dostępność to sygnał. Zadbaj, by mówił prawdę: że dobra praca wymaga czasu, a inni już o tym wiedzą.

Bądź uczciwy. Fałszywa lista oczekujących, sugerująca pełny kalendarz, kiedy wcale go nie masz, to manipulacja, którą kupujący szybko wykrywają i której głęboko nie znoszą. Publikuj listę tylko wtedy, gdy twoje możliwości są naprawdę ograniczone, i dbaj o dokładność dat. Jeśli niespodziewanie zwolni się termin, zaproponuj go następnej osobie z listy. Uczciwość w małych sprawach buduje zaufanie w dużych.

Lista oczekujących daje ci też informacje. Jeśli robi się długa, być może jesteś za tani, albo gotów na dalszą zamianę usług w produkty, albo na sprowadzenie pomocy. Jeśli pozostaje krótka, twój lejek wymaga uwagi. Tak czy inaczej, lista oczekujących to prosta, widoczna miara popytu, która pomaga ci podejmować decyzje dotyczące praktyki.

W tym tygodniu uczciwie przyjrzyj się swoim możliwościom na najbliższe trzy miesiące. Jeśli jesteś blisko pełnego obłożenia, opublikuj najbliższe dostępne daty startu i sposób rezerwacji terminu. Jeśli nie, zanotuj, czego by trzeba, by dojść do punktu, w którym lista oczekujących miałaby sens, i pracuj w tym kierunku. Pełny kalendarz z widoczną kolejką to jedna z najwygodniejszych pozycji, w jakich może być konsultant, i jedna z najbardziej przekonujących.

Ciepłe wygrywa z zimnym

Twoich pięciu ostatnich klientów zna wszystkich, których chcesz poznać. Systematyczny kontakt z byłymi klientami i uśpionymi znajomościami daje lepsze wyniki niż jakikolwiek zimny kanał, jaki kiedykolwiek zbudujesz. Ludzie, którzy z tobą pracowali, poznali cię albo widzieli twoją pracę, już w pewnym stopniu ci ufają. Ludzie, którzy nigdy o tobie nie słyszeli, nie ufają ci wcale. Start z pewnego poziomu zaufania to ogromna przewaga, a większość konsultantów ją marnuje, pozwalając relacjom zamilknąć po zakończeniu zlecenia.

Rozwiązaniem jest prosty, regularny system. Prowadź listę byłych klientów, orędowników, osób polecających, kontaktów ze spotkań i ludzi, którzy wyrazili zainteresowanie, ale nie kupili. Co miesiąc czy dwa odezwij się do kilku z nich, nie po to, by sprzedawać, lecz by być przydatnym: istotny artykuł, nowe narzędzie, notka o możliwości, która się poprawiła, pytanie o to, jak sprawuje się zbudowany przez ciebie system. Każdy kontakt utrzymuje relację ciepłą. Niektóre zamieniają się w rozmowy, a niektóre rozmowy w zlecenia.

Byli klienci są najcieplejsi ze wszystkich. Znają twoją pracę, widzieli wyniki i prawdopodobnie mają więcej problemów, które mógłbyś rozwiązać, wiele z nich zresztą już na liście odłożonych spraw z protokołu rozrastania się zakresu. Krótka notka kilka miesięcy po przekazaniu – jak sprawuje się system segregowania zapytań? Zauważyłem, że podczas sprintu wspominałeś o procesie zwrotów; czy warto byłoby teraz się temu przyjrzeć? – często wystarcza. Powtarzalne zlecenia od byłych klientów to zwykle najłatwiejsza, najszybsza i najbardziej dochodowa praca, jaką praktyka może zdobyć.

Claude może pomóc ci prowadzić ten system tak, by nie stał się udręką. Trzymaj kontakty i notatki w jednym miejscu. Okresowo poproś Claude’a, by zaproponował, do kogo się odezwać, i naszkicował dla każdej osoby spersonalizowaną notkę, na podstawie twoich notatek o niej, jej firmie i waszej ostatniej rozmowie. Przejrzyj i zredaguj każdą, bo musi brzmieć jak ty i być naprawdę istotna. Model szkicuje; ty dostarczasz relację.

Twoja sieć kontaktów to nie ci, których znasz. To ci, z którymi utrzymujesz kontakt.

Bądź naprawdę przydatny, a nie tylko obecny. Wiadomość chciałem tylko zapytać, co słychać łatwo zignorować. Wiadomość zauważyłem tę zmianę w przepisach waszej branży i pomyślałem o dokumentacji regulaminów, którą robiliśmy; oto krótka notka o tym, co to dla was oznacza jest wartościowa i przypomina odbiorcy, dlaczego cenił współpracę z tobą. Celem jest, by każdy kontakt był mile widziany, tak żeby ludzie czekali na wiadomość od ciebie.

Śledź, co się dzieje. Z czasem zobaczysz, które rodzaje kontaktu prowadzą do rozmów, którzy byli klienci wracają, którzy polecający przysyłają najlepsze przedstawienia. Ta wiedza pomaga ci skupić wysiłek tam, gdzie działa. Większość konsultantów, którzy to robią, odkrywa, że duża część ich pracy pochodzi od ludzi, których już znali, a to krzepiące odkrycie dla każdego, kto martwi się o znalezienie następnego klienta.

W tym tygodniu wypisz swoich byłych klientów i ciepłe kontakty. Wybierz pięć osób. Dla każdej napisz krótką, naprawdę przydatną notkę na podstawie tego, co o niej wiesz, i wyślij. Potem ustaw w kalendarzu cykliczne przypomnienie, by robić to samo co miesiąc. To najpewniejszy lejek, jaki kiedykolwiek zbudujesz.

Napisz własny podręcznik

Opublikowanie swojej metody kosztuje cię prawie nic, a czyni cię oczywistym kandydatem do zatrudnienia. Wydaje się to sprzeczne z intuicją: jeśli dokładnie wyjaśnisz, jak prowadzisz audyt, naprawę procesu albo pilotaż agenta, czy klienci po prostu nie zrobią tego sami? Niektórzy może tak. Większość nie, bo wiedza o tym, jak coś się robi, to coś zupełnie innego niż czas, umiejętności i doświadczenie, by zrobić to dobrze. Publikacja pokazuje ponad wszelką wątpliwość, że wiesz, o czym mówisz.

Podręcznik może przybrać wiele form. Serię artykułów opisujących twoje podejście do każdego rodzaju zlecenia. Przewodnik do pobrania dla twojej niszy. Zestaw otwarcie opublikowanych skilli albo szablonów. Nawet książkę, taką jak ta, którą czytasz. Każda z tych form szczegółowo pokazuje twoje myślenie, a szczegółowe myślenie przekonuje znacznie bardziej niż deklaracje fachowości. Kupujący, który przeczytał twój podręcznik, przychodzi na pierwszą rozmowę, już rozumiejąc twoje podejście i w dużej mierze przekonany, że jest słuszne.

Powód, dla którego rzadko kanibalizuje to twój biznes, jest prosty. Ludzie, którzy potrafiliby wdrożyć twoją metodę na podstawie pisemnego opisu, to w większości nie są twoi kupujący. Twoi kupujący to zajęci ludzie prowadzący firmy, którzy chcą wyniku bez spędzania miesięcy na nauce jego wytwarzania. Lektura twojego podręcznika pokazuje im, że wynik jest osiągalny i że to ty jesteś osobą, która może go osiągnąć. Mniejszość, która próbuje zrobić to sama, często odkrywa, ile osądu to wymaga, a niektórzy z nich dzwonią potem do ciebie.

Claude może pomóc ci go napisać, na podstawie materiału, który już masz: szablonów zleceń, studiów przypadków, instrukcji obsługi, notatek z wystąpień. Poproś go o naszkicowanie rozdziałów albo artykułów z tego materiału, a potem mocno redaguj, dodając historie, osądy i zastrzeżenia, które znasz tylko ty. Gotowy podręcznik powinien brzmieć jak ty, odzwierciedlać to, co naprawdę robisz, i uczciwie mówić o tym, co trudne. Podręcznik, w którym wszystko brzmi łatwo, zostanie odczytany jako marketing i odpowiednio zdyskontowany.

Oddaj przepis za darmo. Większość ludzi i tak wolałaby, żeby ugotował ktoś inny.

Publikacja wyostrza też twoją praktykę. Spisanie, jak coś robisz, zmusza cię do uporządkowania tego, a jasność poprawia realizację. Czytelnicy zadają pytania i wskazują luki, co ulepsza metodę. A opublikowana metoda staje się materiałem szkoleniowym, jeśli kiedykolwiek sprowadzisz współpracowników albo partnerów, którzy mogą uczyć się twojego podejścia z tego samego materiału, który czytają twoi klienci.

To naturalne zwieńczenie tej części. Studia przypadków dowodzą pojedynczych wyników; polecenia i ciepłe kontakty przyprowadzają do ciebie ludzi; analizy, darmowe narzędzia, budowanie publicznie, wystąpienia i wpisy w katalogach czynią cię widocznym. Opublikowany podręcznik spina to wszystko w jedno, autorytatywne oświadczenie: tak pracuję, dlatego to działa i tego możesz się spodziewać. Na zatłoczonym rynku pełnym mglistych obietnic jasna, konkretna, opublikowana metoda jest rzadka i cenna.

W tym tygodniu napisz pierwszy rozdział swojego podręcznika: jak prowadzisz swoje najczęstsze zlecenie, krok po kroku, z uzasadnieniem każdego kroku. Opublikuj go tam, gdzie zobaczą go twoi kupujący. Potem zauważ, kto o nim wspomni w kilku następnych rozmowach. Może się okazać, że sprzedaje więcej niż ty.

Sprzedawaj systemy, nie sesje

Sesja kończy się, gdy się wylogujesz. System pracuje dalej o trzeciej nad ranem. To rozróżnienie jest fundamentem tego, dokąd zmierza mikrokonsulting. Konsultant, który sprzedaje sesje – warsztaty, porady, godziny uwagi – sprzedaje coś, co ustaje w chwili, gdy on przestaje. Konsultant, który sprzedaje systemy – działające procesy, ładujące się skille, przetwarzające agenty, narzędzia odpowiadające na pytania – sprzedaje coś, co dostarcza wartość długo po zakończeniu zlecenia.

Ta książka od początku zmierzała do tej idei. Naprawa procesu zostawia działający proces. Zestaw promptów zostawia przetestowane prompty. Biblioteka skilli zostawia umiejętności. Pilotaż agenta zostawia system przetwarzający prawdziwą pracę. Sprint dokumentacyjny zostawia wiedzę, z której mogą korzystać i ludzie, i modele. Każde zlecenie jest małe, ale każde wytwarza coś, co je przeżywa. Z czasem klient gromadzi zbudowane przez ciebie systemy, z których każdy wciąż działa i każdy przypomina o twojej wartości.

Projektowanie z myślą o tym zmienia podejście do każdego zlecenia. Pytanie brzmi nie tylko co zrobimy razem?, ale co będzie działać po moim odejściu? To pytanie popycha cię w stronę nawyków, które zalecała ta książka: jasnych instrukcji obsługi, przeszkolonych orędowników, zestawów ewaluacyjnych, zabezpieczeń w systemie, a nie w dokumencie, przekazanych promptów, wszystkiego wersjonowanego i należącego do klienta. System, który do działania potrzebuje ciebie, to przebrana sesja.

Wycena idzie za projektem. Sesję wycenia się według czasu, bo to czas pochłania. System wycenia się według wartości, bo to wartość wytwarza, i to nieprzerwanie. Skromne zlecenie, które zostawia system oszczędzający wiele godzin w każdym tygodniu, jest warte znacznie więcej niż warsztat tej samej długości, a klienci to rozumieją, gdy pokaże im się to jasno, z punktem zero, pomiarem i bieżącą sumą.

Sesje się pamięta. Na systemach się polega. Poleganie to silniejsza relacja.

Pod spodem zachodzi głębsza zmiana. W miarę jak rosną możliwości AI, wartość bieżącej uwagi konsultanta w pojedynczej sesji spada, bo wiele z tego, co ta uwaga kiedyś zapewniała, mogą dziś zapewnić narzędzia. Rośnie natomiast wartość projektowania, budowania i utrzymywania systemów, które te narzędzia zaprzęgają do pracy, bo wymaga to osądu, kontekstu i troski, których narzędzia same z siebie nie dostarczają. Sprzedawanie systemów stawia cię po właściwej stronie tej zmiany.

Nic z tego nie znaczy, że sesje są bezwartościowe. Dobre szkolenie albo warsztat strategiczny mogą mieć ogromną wartość, a niektórzy klienci potrzebują dokładnie tego. Ale nawet sesję można zaprojektować tak, by zostawiła po sobie system: zestaw promptów ze szkolenia, ramę decyzyjną z warsztatu, skill kodujący metodę, której nauczył się zespół. Najlepsze sesje to te, które stają się systemami.

W tym tygodniu przejrzyj swoje oferty i przy każdej zapytaj: co będzie działać po moim odejściu? Jeśli odpowiedź brzmi „nic”, przeprojektuj ofertę tak, by coś po sobie zostawiała. Jeśli odpowiedź brzmi „system”, zadbaj, by twoja wycena, oferty i studia przypadków mówiły to jasno. Nie sprzedajesz swojego czasu. Sprzedajesz maszyny, które pracują dalej, z wbudowanym twoim osądem.

Agenty, które raportują swoją wartość

Następnym poziomem zleceń jest system, który prowadzi proces i raportuje własną wartość. Co miesiąc, bez niczyjej prośby, przygotowuje krótkie sprawozdanie z tego, co zrobił: ile spraw obsłużył, ile czasu to zaoszczędziło, jakie wyniki jakościowe osiągnął, jakie problemy zasygnalizował, co się zmieniło. Kiedy agent sam uzasadnia swoją fakturę, odnowienie przestaje być rozmową i staje się formalnością.

Klocki są już w tej książce. Agent albo proces, który obsługuje prawdziwą pracę, z rozdziału o pilotażu. Dziennik każdego działania i jego wyniku, z projektu z człowiekiem w pętli. Zestaw ewaluacyjny regularnie uruchamiany ponownie, z rozdziału o odbiorze. Punkt zero z początku zlecenia, z rozdziału o zamykaniu pętli. Złóż je razem, a możesz automatycznie generować comiesięczny raport: wolumen, czas zaoszczędzony względem punktu zero, wynik jakościowy, wyjątki, wprowadzone usprawnienia, rekomendacje.

Gdy szablon jest już gotowy, Claude może przygotowywać taki raport z logów i wyników ewaluacji przy bardzo niewielkim nadzorze. Twoja rola sprowadza się do przejrzenia go, dodania komentarza tam, gdzie potrzebny jest osąd, i wysłania klientowi. Raport robi trzy rzeczy. Co miesiąc pokazuje klientowi, w jego kategoriach, jaką wartość otrzymuje. Daje ci wczesne ostrzeżenie, gdy jakość spada albo zmienia się wolumen. I buduje stale rosnący zapis wyników, który przemawia za odnowieniem, rozszerzeniem i poleceniem.

Bądź w tych raportach skrupulatnie uczciwy. Zaoszczędzony czas powinien być liczony według podanej metody, względem punktu zero uzgodnionego z klientem. Jakość powinna być mierzona według uzgodnionych kryteriów. Problemy i porażki powinny być raportowane, a nie ukrywane. Raport, który zawsze pokazuje tylko dobre wiadomości, w końcu przestanie budzić zaufanie. Raport, który obok ogólnej wartości pokazuje sporadyczne problemy i wyjaśnia, co z nimi zrobiono, budzi wiarę, a o to właśnie chodzi.

Najlepszy argument za odnowieniem to taki, który klient czyta co miesiąc od roku.

Zmienia to ekonomię abonamentów na twoją korzyść. Abonament uzasadniany comiesięcznymi dowodami wartości jest znacznie trwalszy niż taki, za którym stoi mgliste poczucie, że wszystko działa. Wspiera to też wycenę: system, który dowodnie oszczędza co miesiąc mnóstwo czasu, może udźwignąć opłatę miesięczną odzwierciedlającą uczciwą część tej wartości, a klient może sam sprawdzić rachunek.

Dalej leży kolejna granica, za którą systemy nie tylko raportują wartość, ale też w większym stopniu same dbają o swoje usprawnianie, proponując zmiany na podstawie obsługiwanych spraw i otrzymywanych wyników, do zatwierdzenia przez człowieka. To zaczyna być praktyczne i pasuje do wzorca tej książki: autonomia rozszerzana tam, gdzie wspierają ją dowody, a osąd w rękach człowieka. Najpierw zbuduj raportowanie. Pętla usprawnień wyrośnie z niego naturalnie.

W tym tygodniu weź system, który dostarczyłeś, i zaprojektuj jego comiesięczny raport wartości: wskaźniki, punkt zero, metodę, format. Wygeneruj pierwszą wersję z tych logów i wyników, które istnieją. Wyślij ją klientowi, nawet jeśli jest surowa. Obserwuj jego reakcję. Klienci rzadko dostają takie dowody od kogokolwiek, a pierwszy raport zwykle robi trwałe wrażenie.

Przejmij warstwę ewaluacji

W miarę jak modele stają się coraz zdolniejsze i coraz powszechniej dostępne, rzadką umiejętnością staje się wiedza, czy ich wyniki są dobre. Każdy może wygenerować wiarygodnie wyglądający raport, wiarygodnie wyglądającą odpowiedź, wiarygodnie wyglądający kawałek kodu. Znacznie mniej osób potrafi niezawodnie i na dużą skalę ocenić, które z tych wiarygodnie wyglądających wyników są naprawdę właściwe dla konkretnej firmy, a które są subtelnie błędne w sposób, który później będzie kosztować. Kto posiada ten pomiar, ten posiada zaufanie, a za zaufanie się płaci.

Warstwa ewaluacji to zestaw narzędzi, przypadków, kryteriów i procesów, które odpowiadają na pytanie czy to jest dobre? w odniesieniu do pracy konkretnego klienta. Obejmuje zestawy ewaluacyjne zbudowane podczas zleceń, kryteria uzgodnione z klientem, agenty weryfikujące wyniki, dzienniki ludzkich zatwierdzeń i poprawek oraz comiesięczne raporty śledzące jakość w czasie. Dobrze zbudowana pozwala klientowi w każdej chwili wiedzieć, jak dobrze działają jego systemy AI i gdzie wymagają uwagi.

Dla mikrokonsultanta przejęcie tej warstwy to trwała pozycja. Modele się zmieniają; warstwa ewaluacji trwa i zyskuje na wartości, w miarę jak rośnie. Każdy nowy przypadek, każde dopracowane kryterium, każda uchwycona porażka sprawiają, że coraz dokładniej oddaje ona to, jak wygląda dobre dla tego klienta. Kiedy pojawia się nowy model, to warstwa ewaluacji mówi klientowi, czy przejść na niego. Kiedy system zachowuje się nie tak, to ona ujawnia problem. Kiedy klient chce rozszerzyć korzystanie z AI, to ona mówi mu, czy rozszerzenie działa.

Zmienia to też charakter twojej relacji. Konsultanta, który buduje systemy, ceni się za budowę. Konsultanta, który utrzymuje warstwę ewaluacji, ceni się nieustannie, bo jest zaufanym sędzią jakości klienta. To bardzo naturalna podstawa stałej współpracy i trudno go zastąpić, bo warstwa ewaluacji ucieleśnia lata nagromadzonego zrozumienia tego, czego klient potrzebuje.

Generowanie odpowiedzi tanieje. Wiedza, którym odpowiedziom ufać – nie.

Budowanie warstwy ewaluacji zaczyna się od małych rzeczy, w każdym zleceniu. Napisz zestaw ewaluacyjny, zanim zaczniesz budować. Uzgodnij kryteria z klientem. Każdą prawdziwą porażkę zapisz jako nowy przypadek testowy. Trzymaj przypadki, kryteria i wyniki w wersjonowanym repozytorium, którego właścicielem jest klient. Uruchamiaj je regularnie. Po kilku zleceniach u tego samego klienta staje się to pokaźnym aktywem, a ty jesteś osobą, która zna je najlepiej.

To także umiejętność warta rozwijania dla niej samej. Projektowanie dobrych ewaluacji – wybór reprezentatywnych przypadków, pisanie kryteriów, które chwytają to, co ważne, wykrywanie, kiedy wynik wprowadza w błąd – to fachowość, na którą rośnie popyt. Konsultanci, którzy będą z niej znani, przekonają się, że klienci przychodzą do nich nie tylko po to, by budować systemy, ale też po to, by je oceniać, łącznie z systemami zbudowanymi przez innych.

W tym tygodniu, dla jednego klienta albo jednego własnego systemu, zbierz w jednym miejscu każdy przypadek ewaluacyjny, kryterium i zapis jakości, jakie masz. Zanotuj luki: rodzaje pracy bez testów, porażki, których nigdy nie zapisano jako przypadków. Wypełnij jedną lukę. Budujesz aktywo, które będzie miało największe znaczenie, gdy wszystko inne stanie się łatwiejsze do wytworzenia.

Aktualizacje to darmowe R&D

Każde wydanie modelu może ulepszyć wszystko, co już dostarczyłeś, jeśli zbudowałeś to z myślą o tym. Dobrze zaprojektowany system, z jasnymi instrukcjami, czystym kontekstem, ustrukturyzowanymi wynikami, dołączonymi skryptami i mocnym zestawem ewaluacyjnym, zwykle może skorzystać z bardziej zdolnego modelu przy niewielkiej przeróbce albo bez niej. Uruchom zestaw ewaluacyjny na nowym modelu, przejrzyj wyniki, dostosuj, co trzeba, i przełącz. Przyrost możliwości ląduje w systemie klienta, a ty nie musiałeś finansować badań, które go wytworzyły.

To niezwykła pozycja. Większość firm musi inwestować, by ulepszać swoje produkty. Tutaj znaczna część ulepszeń przychodzi z zewnątrz, regularnie, w miarę jak dostawcy modeli wypuszczają lepsze modele. Twoim zadaniem jest zadbać, by twoje systemy mogły gładko przyjmować te ulepszenia, i być osobą, która mówi klientowi, co się zmieniło i dlaczego to ważne. To naturalna część abonamentu i przekonujący powód, by klient go utrzymywał.

Budowanie z myślą o aktualizacjach oznacza unikanie ścisłego przywiązania do dziwactw konkretnego modelu. Instrukcje, które opierają się na obejściu konkretnej słabości, mogą stać się zbędne, a nawet szkodliwe, gdy słabość zostanie usunięta. Prompty jasne, dobrze ustrukturyzowane i oparte na ogólnych zasadach zwykle dobrze się przenoszą. Trzymaj wybór modelu w konfiguracji, a nie rozsiany po kodzie. Dokumentuj obejścia, żebyś wiedział, do których wrócić, gdy pojawi się nowy model.

To zestaw ewaluacyjny sprawia, że aktualizacje są bezpieczne. Bez niego zmiana modelu to hazard: nowy model może być ogólnie lepszy, ale gorszy w jakimś konkretnym przypadku, który ma znaczenie dla klienta. Z nim widzisz dokładnie, jak nowy model radzi sobie z prawdziwą pracą klienta, zanim przełączysz. Czasem poprawa jest dramatyczna. Czasem skromna. Od czasu do czasu, przy konkretnym zadaniu, dotychczasowy model wciąż jest lepszym wyborem. Ewaluacja mówi ci, który.

Buduj tak, żeby postęp, za który nie zapłaciłeś, i tak trafiał pod drzwi twojego klienta.

Aktualizacje to także okazja, by na nowo przemyśleć, co jest możliwe. Zadanie, które było zbyt trudne dla poprzedniego modelu, może być teraz w zasięgu. Ludzki punkt kontrolny, który był konieczny, może teraz zostać bezpiecznie poluzowany dla niektórych typów działań, jeśli wspierają to dowody. Proces, który wymagał kilku kroków, może teraz zmieścić się w jednym. Każda z tych rzeczy to potencjalne usprawnienie do zaproponowania klientowi, a wiele z nich to naturalne mikrozlecenia same w sobie.

Uważaj, by nie obiecywać przyszłych usprawnień, których nie możesz zagwarantować. Postęp modeli był szybki, ale jego dokładny przebieg jest nieprzewidywalny i nie każde wydanie poprawia każde zadanie. Mów klientom, że ich systemy są zaprojektowane tak, by korzystać z ulepszeń, i że ocenisz każde istotne wydanie, zamiast obiecywać konkretne zyski w konkretnych terminach.

W tym tygodniu sprawdź jeden ze swoich systemów pod kątem przywiązania do modelu. Czy wybór modelu jest w konfiguracji? Czy obejścia są udokumentowane? Czy jest zestaw ewaluacyjny gotowy do uruchomienia na nowym modelu? Uzupełnij, czego brakuje. Następne istotne wydanie będzie wtedy szansą, a nie zakłóceniem, a ty będziesz pierwszy, by powiedzieć klientowi, co ono dla niego oznacza.

Projekty poboczne, które procentują

Każda budowa powinna wykorzystywać komponenty poprzedniej. Konsultant, który każde zlecenie zaczyna od pustej strony, ciężko pracuje bez końca. Konsultant, który świadomie buduje na wcześniejszej pracy, odkrywa, że każde zlecenie jest szybsze od poprzedniego, bo więcej jest już zrobione. Dwa lata takiej pracy dają bibliotekę komponentów, skilli, szablonów i narzędzi, której nikt nie dogoni w kwartał, a to cichy silnik każdej wydajnej praktyki.

Procentowanie wymaga intencji. Pracując, zauważaj, co jest ogólne, a co szczególne. Struktura raportu z audytu jest ogólna; ustalenia klienta są szczególne. Skrypt, który czyści popularny format eksportu, jest ogólny; dane klienta są szczególne. Skill do szkicowania studiów przypadków jest ogólny; samo studium przypadku jest szczególne. Wyodrębniaj ogólne części do własnej biblioteki, porządkuj je, dokumentuj i używaj następnym razem. Szczególne części zostaw u klienta.

Projekty poboczne to przyspieszają. W spokojniejszych tygodniach albo przez kilka godzin w każdym tygodniu buduj dla siebie rzeczy, które przyspieszą przyszłe zlecenia: lepszy szablon prototypu, nowe darmowe narzędzie dla twojej niszy, skill automatyzujący część realizacji, która cię nuży, zestaw syntetycznych zbiorów danych dla twojej branży. Każdy projekt poboczny powinien wykorzystywać poprzednie, żeby biblioteka rosła spójnie, a nie jako sterta niepowiązanych eksperymentów.

Claude sprawia, że projekty poboczne są na tyle tanie, by się opłacały. Komponent, który kiedyś zająłby tydzień, często da się zbudować w jedno popołudnie. Ograniczeniem nie jest budowanie, tylko dyscyplina, by budować rzeczy, które procentują, a nie takie, które są jedynie ciekawe. Przed każdym projektem pobocznym zapytaj: czy to sprawi, że moje następne zlecenie będzie szybsze albo lepsze? Czy wykorzysta coś, co już mam? Czy coś w przyszłości wykorzysta to? Jeśli odpowiedzi brzmią „tak”, buduj.

Pierwsza budowa to praca. Dziesiąta, postawiona na pierwszych dziewięciu, to dźwignia.

Zorganizuj bibliotekę tak, byś mógł w niej coś znaleźć. Wersjonuj ją, jak zalecał rozdział o kanonie. Nazywaj rzeczy jasno. Prowadź krótki indeks tego, co istnieje i do czego służy każdy element. Biblioteka, której nie da się przeszukać, to biblioteka, z której nie będziesz korzystać, a komponenty, których nie możesz znaleźć, budowane są od zera, co niweczy cały sens.

Procentowanie widzą też klienci. Konsultant, którego prototypy są dopracowane od pierwszego dnia, którego skille już rozumieją branżę, którego szablony już pasują do zlecenia, dostarcza w dwa tygodnie więcej, niż nowicjusz w dwa miesiące. Klienci mogą nie wiedzieć dlaczego, ale zauważają wynik i mówią o nim innym. Ta reputacja procentuje równolegle z biblioteką.

W tym tygodniu przyjrzyj się swoim trzem ostatnim zleceniom i wypisz komponenty, które zbudowałeś przy każdym z nich. Oznacz, które były ogólne i mogłyby zostać ponownie wykorzystane. Wyodrębnij jeden, uporządkuj go i dodaj do biblioteki z krótką notką. Potem zaplanuj na nadchodzący miesiąc jeden projekt poboczny, który zbuduje na czymś, co już masz. Małe, konsekwentne dodatki to sposób, w jaki biblioteka staje się przewagą.

Fosa z biblioteki skilli

Model może kupić każdy. Nikt inny nie ma twoich czterdziestu zakodowanych procesów, dostrojonych na prawdziwej pracy dla klientów. Ta biblioteka skilli, dopracowywana w wielu zleceniach w określonej niszy, to jedyna naprawdę obronna rzecz, jaką posiada mikrokonsultant. Modele są dostępne dla wszystkich. Techniki są publikowane za darmo. Ogólna wiedza jest na wyciągnięcie wyszukiwarki. Rzadka jest nagromadzona, przetestowana, konkretna umiejętność, która bierze się z wielokrotnego wykonywania tego samego rodzaju pracy i kodowania tego, czego się nauczyłeś.

Pomyśl, co zawiera dojrzała biblioteka skilli. Skille do każdego rodzaju zleceń, które prowadzisz: audytu, naprawy procesu, sprintu dokumentacyjnego, zestawu promptów, pilotażu. Materiały branżowe z żargonem, przepisami i typowymi pułapkami twojej niszy. Szablony ofert, instrukcji obsługi, studiów przypadków i raportów. Skille weryfikacyjne z kryteriami dostrojonymi do tego, co cenią twoi klienci. Skrypty do mechanicznej pracy, której twoja branża wielokrotnie potrzebuje. Każdy element jest przydatny sam w sobie. Razem pozwalają ci dostarczać pracę o jakości i w tempie, któremu nowicjusz, nawet z tymi samymi modelami, nie dorówna.

Fosą nie jest tajemnica. Jak przekonywały wcześniejsze rozdziały, powinieneś przekazywać klientom skille zbudowane z ich kontekstu i możesz opublikować dużą część swojej metody. Fosą jest nagromadzenie. Konkurent mógłby przeczytać twój podręcznik i skopiować twoje podejście, ale nie zdobędzie natychmiast lat dostrajania na prawdziwych przypadkach, setek drobnych usprawnień wywołanych prawdziwymi porażkami, materiałów branżowych dopracowanych u dziesiątek klientów. To wymaga czasu, a czas to jedyna rzecz, której konkurent nie może kupić.

Chroń bibliotekę, utrzymując ją. Biblioteka skilli, która nie jest aktualizowana, traci wartość, w miarę jak zmieniają się modele, narzędzia i branże. Wersjonuj ją, testuj na każdym nowym modelu, przycinaj to, co już nie działa, i dodawaj do niej po każdym zleceniu. Biblioteka to żywe aktywo, a jak każde aktywo wymaga troski. Zaniedbana biblioteka staje się obciążeniem: zestawem przestarzałych instrukcji dających subtelnie błędne wyniki.

Model to silnik, który może kupić każdy. Twoje skille to samochód, który tylko ty umiesz zbudować.

Biblioteka zmienia też ekonomię twojej praktyki. Z mocną biblioteką konsultant działający w pojedynkę może dostarczać w skali, która kiedyś wymagała zespołu, bo duża część fachowości jest zakodowana, a nie noszona w ludzkich głowach. Ułatwia to współpracę: partner albo współpracownik może dostarczać według twojego standardu, korzystając z twojej biblioteki. I otwiera nowe możliwości: licencjonowanie części biblioteki, oferowanie jej jako produktu albo wykorzystanie jej jako fundamentu systemów obsługujących wielu klientów naraz.

Zacznij budować świadomie już teraz, jeśli jeszcze tego nie robisz. Każde zlecenie powinno zostawiać twoją bibliotekę odrobinę lepszą, niż ją zastało: dopracowany skill, nowa notka branżowa, dodany przypadek testowy, ulepszony szablon. W ciągu roku te drobne dodatki stają się pokaźne. W ciągu kilku lat stają się fosą.

W tym tygodniu zrób inwentaryzację swojej biblioteki skilli. Wypisz, co masz, zanotuj, czego brakuje dla twoich kluczowych rodzajów zleceń, i wskaż jeden dodatek, który zrobiłby największą różnicę przy następnym zleceniu. Zbuduj go, przetestuj, wersjonuj. Tak kopie się fosę: łopata po łopacie, konsekwentnie, przez lata.

Flota zamiast okrętu flagowego

Dziesięć małych zleceń przynoszących stały dochód wygrywa z jednym heroicznym zakładem. Pokusą w każdej praktyce doradczej jest pogoń za okrętem flagowym: dużym programem transformacji, klientem korporacyjnym, kontraktem, który za jednym zamachem sfinansowałby cały rok. Czasem warto o nie zabiegać. Ale praktyka zbudowana na flocie małych zleceń jest odporniejsza, szybciej się uczy, wytwarza więcej dowodów i z czasem często zarabia więcej niż praktyka zbudowana na kilku dużych.

Odporność to pierwsza zaleta. Praktykę z jednym dużym klientem od kryzysu dzieli jedna decyzja budżetowa. Praktyka z tuzinem małych klientów, na różnych szczeblach drabiny oferty, może stracić jednego bez poważnej szkody. Flota rozkłada ryzyko na wiele relacji, branż i rodzajów zleceń. Daje też opcje: jeśli jeden rodzaj zlecenia przestaje się sprzedawać, pozostałe trwają, a ty masz czas, by się dostosować.

Nauka to druga zaleta. Każde małe zlecenie to pełny cykl: diagnoza, zakresowanie, realizacja, pomiar, przekazanie. Dziesięć małych zleceń rocznie daje ci dziesięć pełnych cykli do nauki. Jedno duże zlecenie daje jeden, i trwa tak długo, że lekcje przychodzą za późno, by je zastosować. Krótkie cykle oznaczają szybką informację zwrotną, a szybka informacja zwrotna poprawia twoją metodę, bibliotekę i osąd znacznie szybciej niż jakakolwiek ilość lektury.

Dowody to trzecia zaleta. Każde małe zlecenie wytwarza studium przypadku, referencję, zmierzony wynik. Flota małych zleceń wytwarza bibliotekę dowodów z wielu branż i problemów, co ułatwia następną sprzedaż. Jedno duże zlecenie wytwarza jedno studium przypadku, często poufne, często zbyt specyficzne, by przydało się większości potencjalnych klientów. Mała praca to zaskakująco dobry marketing.

Flota nie potrzebuje, by którykolwiek statek był niezwykły. Potrzebuje, by wszystkie płynęły dalej.

Idea floty dotyczy nie tylko klientów, ale i produktów. Praktyka może prowadzić zestaw małych darmowych narzędzi, z których każde służy nieco innej potrzebie w niszy i każde przyprowadza strumień potencjalnych klientów. Może utrzymywać portfel małych usług zamienionych w produkty, z których każda jest dopracowywana w wielu realizacjach. Zasada jest ta sama: wiele skromnych aktywów, z których każde coś wnosi, a żadne samo w sobie nie jest krytyczne.

Jest koszt zarządzania. Flota wymaga systemów: standardowych szablonów zleceń, biblioteki skilli, spójnych procesów realizacji, uporządkowanej dokumentacji klientów. Bez nich tuzin małych zleceń staje się tuzinem źródeł chaosu. Z nimi każde zlecenie jedzie po szynach, a flotą da się zarządzać nawet w pojedynkę. Dlatego wcześniejsze części tej książki mają tak duże znaczenie. To one są systemami, dzięki którym flota jest możliwa.

Nic z tego nie wyklucza większej pracy. Duże zlecenie, które wyrasta w naturalny sposób z serii udanych małych, u klienta, którego dobrze znasz, to zupełnie co innego niż duże zlecenie zdobywane na zimno. Niech okręty flagowe wyłaniają się z floty, zamiast stawiać całą praktykę na to, że jakiś znajdziesz.

W tym tygodniu rozrysuj swoją obecną praktykę jako flotę: ilu klientów, na którym szczeblu drabiny, w jakich branżach. Zanotuj, gdzie jesteś nadmiernie skoncentrowany. Wybierz jeden krok, który rozłoży ryzyko: nową małą ofertę, nową branżę, nowe darmowe narzędzie. Flotę buduje się po jednym skromnym statku naraz.

Praktyka dwuosobowa

Realizacja z agentami oznacza, że liczba pracowników przestaje wyznaczać możliwości. Dwie osoby z mocną biblioteką skilli, dobrymi systemami i nawykami z tej książki mogą dziś obsługiwać bazę klientów, która kiedyś wymagała znacznie większego zespołu. To nie przepowiednia odległej przyszłości. Widać to już w praktykach, które przeorganizowały się wokół tych narzędzi, i zmienia to, czym może być mała firma doradcza.

Zobacz, jak dzieli się praca. Wiele z tego, co kiedyś zajmowało młodszych pracowników – research, synteza, szkicowanie, budowanie prototypów, pisanie dokumentacji, uruchamianie testów, przygotowywanie raportów – może dziś robić Claude, kierowany przez doświadczonego praktyka. Ludziom zostaje to, co wymaga osądu i relacji: diagnozowanie problemów, projektowanie rozwiązań, przeglądanie wyników, podejmowanie decyzji, budowanie zaufania klientów. Dwie osoby dobre w tych rzeczach, z agentami robiącymi resztę, mają niezwykły zasięg.

Umiejętności takiej praktyki są inne niż w tradycyjnej agencji. Zamiast zarządzać ludźmi, wspólnicy zarządzają systemami: bibliotekami skilli, szablonami realizacji, warstwami ewaluacji, monitoringiem i raportami. Zamiast szkolić juniorów, kodują swój osąd w skillach i nieustannie go dopracowują. Zamiast zatrudniać, gdy rośnie popyt, ulepszają swoje systemy i zamieniają oferty w produkty. Wzrost bierze się z dźwigni, a nie z liczby etatów.

Dwójka to przydatna liczba, choć nie magiczna. Praktyk działający w pojedynkę może robić wiele z tego, ale nie ma nikogo, kto zastąpiłby go na urlopie, przejrzał jego pracę albo podzielił się ciężarem sprzedaży i realizacji. Para może podzielić się rolami, na przykład jedna osoba bardziej skupiona na klientach, a druga na systemach, przy czym każda może zastąpić drugą. Mogą przeglądać nawzajem swoją pracę, co ma ogromne znaczenie w biznesie zbudowanym na zaufaniu. A dwie osoby wciąż mogą podejmować decyzje przy herbacie, bez narzutu, którego potrzebują większe organizacje.

Dźwignia brała się kiedyś z ludzi. Teraz bierze się z systemów, które ludzie projektują i oceniają.

Są uczciwe ryzyka. Mała praktyka o dużym zasięgu niesie prawdziwą odpowiedzialność: wielu klientów zależy od systemów zbudowanych i utrzymywanych przez bardzo nieliczne osoby. To wymaga dyscypliny: rygorystycznej ewaluacji, dobrego monitoringu, jasnych instrukcji obsługi, przeszkolonych orędowników u każdego klienta i ustaleń na wypadek, gdyby jeden ze wspólników był niedostępny. Bycie małym nie usprawiedliwia kruchości. Jeśli już, wymaga więcej staranności, bo jest mniej luzu.

Jest też pokusa, by rozciągnąć się za bardzo, biorąc więcej klientów, niż systemy są w stanie naprawdę obsłużyć, bo narzędzia sprawiają, że wydaje się to możliwe. Uważnie obserwuj jakość. Warstwa ewaluacji i comiesięczne raporty to twoje wczesne ostrzeżenie. Jeśli jakość zaczyna spadać, zwolnij, wzmocnij systemy i dopiero wtedy bierz więcej.

W tym tygodniu wyobraź sobie swoją praktykę z dwukrotnie większą liczbą klientów i bez nowych zatrudnień. Co musiałoby być prawdą? Jakie systemy musiałyby istnieć, jakie skille musiałyby zostać zakodowane, jakie procesy ustandaryzowane? Spisz listę. Potem wybierz pierwszą pozycję i zacznij ją budować. Możliwości nie są już czymś, co się zatrudnia. Są czymś, co się projektuje.

Naucz to cię zastąpić

Koduj w skillu każdy powtarzalny osąd, który podejmujesz, świadomie i nieustannie. Celem nie jest pewność zatrudnienia. Celem są możliwości, które możesz sprzedać dwa razy. Każde zadanie wykonywane ręcznie, które dałoby się zakodować, to zadanie ograniczające to, ile możesz dostarczyć. Każde zakodowane zadanie uwalnia twoją uwagę dla pracy, którą możesz wykonać tylko ty, i pozwala zakodowanej wersji obsłużyć więcej klientów, niż kiedykolwiek mógłbyś osobiście.

Wielu konsultantom brzmi to niepokojąco. Jeśli zakoduję to, co wiem, co mi zostanie? Odpowiedź, którą ostatni rozdział podaje wprost, to osąd stojący ponad każdym konkretnym zadaniem: decydowanie, co budować, dla kogo, dlaczego i czy to działa. Ten osąd nie zostaje umniejszony przez kodowanie zadań, które leżą pod nim. Zostaje uwolniony, by działać na większą skalę. Konsultant, który zakodował swoją metodę audytu, może prowadzić więcej audytów, ale co ważniejsze, może poświęcać czas trudnym decyzjom, które metoda audytu wydobywa na wierzch.

Zacznij od zauważania swoich powtarzalnych osądów. Kiedy przeglądasz szansę z audytu i decydujesz, czy warto się nią zająć, na co patrzysz? Kiedy zakresujesz sprint i decydujesz, co do niego włączyć, jakie reguły stosujesz? Kiedy przeglądasz szkic i uznajesz, że jest wystarczająco dobry, jakimi kryteriami się kierujesz? Każdy z nich to osąd, który podejmujesz raz za razem. Zapisz, jak go podejmujesz, przetestuj spisaną wersję na prawdziwych przypadkach i zamień ją w skill albo kryteria oceny.

Zakodowana wersja na początku będzie niedoskonała. To w porządku. Używaj jej obok własnego osądu, porównuj wyniki i dopracowuj ją tam, gdzie się różnią. Z czasem będzie dobrze radzić sobie z rutynowymi przypadkami, zostawiając tobie nietypowe. Ten podział – przypadki rutynowe dla systemu, nietypowe dla ciebie – jest dokładnie właściwy. To także dokładnie ten wzorzec, który projektujesz dla klientów, zastosowany do własnej praktyki.

Jeśli tylko ty potrafisz to zrobić, jesteś sufitem. Zakoduj to, a sufit się podniesie.

Jest w tym test uczciwości. Jeśli odkryjesz, że nie potrafisz zakodować jakiegoś osądu, bo nie umiesz wyjaśnić, jak go podejmujesz, warto to wiedzieć. Czasem oznacza to, że osąd jest naprawdę milczący i wymaga doświadczenia, którego nie da się łatwo spisać. Czasem oznacza, że jesteś mniej konsekwentny, niż sądziłeś. Tak czy inaczej, sama próba zakodowania uczy cię czegoś o twojej własnej fachowości.

Uczenie systemu, by cię zastąpił, przygotowuje też twoją praktykę do wzrostu. Partner albo współpracownik może pracować według twojego standardu, korzystając z twoich zakodowanych osądów. Klienci mogą otrzymywać skille, które stosują twoją metodę do ich pracy bez twojej obecności. Twoja praktyka staje się mniej zależna od twojego osobistego czasu, a bardziej od systemów, które zbudowałeś, a to jedyny sposób, by mała praktyka rosła, nie sprowadzając się po prostu do dłuższej pracy.

W tym tygodniu wybierz jeden osąd, który wielokrotnie podejmujesz w swojej pracy. Zapisz możliwie precyzyjnie, jak go podejmujesz. Zamień go w skill albo kryteria oceny, przetestuj na pięciu prawdziwych przypadkach i porównaj wyniki z własnymi. Dopracuj. Potem wybierz następny. Każdy zakodowany osąd to odrobina więcej możliwości, które możesz sprzedać ponownie.

Osąd to ostatnia praca

Oto cała książka w jednym zdaniu: sprzedawaj małe, dostarczaj szybko, udowadniaj i pozwól, by każde „tak” zapracowało na następne, a osąd zatrzymaj dla siebie. Cała reszta – sto ruchów, oferty i sprinty, skille i zestawy ewaluacyjne – to maszyneria, która pozwala robić to dobrze. Na małe zlecenia łatwo powiedzieć „tak”. Claude sprawia, że szybko się je dostarcza. Pomiar zamienia każde z nich w dowód. Dowód zamienia się w następne zlecenie. A przez cały ten czas tym, za co klient naprawdę płaci, jest twój osąd w kwestii tego, co warto robić.

Małe, bo najtrudniejszą częścią doradztwa jest „tak”, a małe, stałe, konkretne zlecenie to najłatwiejsze „tak”, jakie może dać kupujący. Płatny audyt, dwutygodniowy sprint, zestaw promptów, sprint dokumentacyjny, pilotaż agenta, szkolenie: każde z nich jest ograniczone, nazwane i jasne co do tego, co dostarcza. Klient, który mówi „tak” jednemu z nich, podjął niewielkie ryzyko i, jeśli dobrze wykonasz swoją robotę, otrzymał wyraźny zwrot. To początek relacji, a nie koniec negocjacji.

Szybko, bo narzędzia na to pozwalają. Claude czyta, szkicuje, buduje, testuje i weryfikuje w tempie, które drastycznie zmniejsza wysiłek stojący za ogromną ilością pożytecznej pracy. Warsztat promptowania, starannie dobrany kontekst, Claude Code w repozytorium, skille i subagenty, prototypy i artefakty: tak pojedynczy praktyk dostarcza w dwa tygodnie to, co kiedyś zajmowało zespołowi dwa miesiące. Wyceniaj rezultat, nie godziny, a ta szybkość zostanie u ciebie.

Udowodnione, bo niezmierzone sukcesy idą w zapomnienie. Punkty zero, zestawy ewaluacyjne, liczby z zamknięcia zlecenia, comiesięczne raporty, studia przypadków: to one zamieniają dobrą pracę w dowody, które klient może zobaczyć, którymi może się podzielić i na podstawie których może działać. Dowody zapracowują na odnowienie, polecenie i następny szczebel drabiny. Praktyka, która nieustannie dowodzi swojej wartości, nigdy nie musi o nią walczyć.

Wszystko, co leży poniżej gustu, w końcu się zautomatyzuje. Automatyzuj własną pracę, aż zostanie tylko decyzja, co w ogóle warto budować.

I osąd, bo to ta część, której nie da się delegować. Jaki jest prawdziwy problem za tym zgłoszonym? Którą z szans wskazanych w audycie warto podjąć najpierw? Co znaczy „gotowe” dla tego klienta? Kiedy wysoki wynik ewaluacji wprowadza w błąd? Którego działania nigdy nie należy automatyzować? Czy to w ogóle powinno powstać? Claude może dostarczać informacji do każdej z tych decyzji, często znakomitych, i powinieneś go o to prosić. Nie może jednak być ich właścicielem, bo bycie ich właścicielem oznacza odpowiadanie przed klientem za konsekwencje, a pod tą odpowiedzialnością widnieje twoje nazwisko.

Automatyzuj więc własną pracę, zadanie po zadaniu, świadomie, aż zostanie tylko osąd. To nie jest umniejszona rola. To najcenniejsza rola w całym biznesie i ta, za którą klienci zawsze płacili, nawet gdy była zakopana pod godzinami researchu i pisania, których dziś nie trzeba już wykonywać ręcznie. Zacznij w tym tygodniu od najmniejszego zlecenia, jakie możesz sprzedać, dostarcz je szybko, zmierz uczciwie i poproś o następne. Potem zrób to jeszcze raz. Oto cały podręcznik. Nigdy tak naprawdę nie chodziło w nim o AI. Chodziło o to, by łatwo było powiedzieć „tak”, a potem dopilnować, żeby to „tak” było tego warte.