// docs

Nasz proces: od odkrycia do przekazania

Nie prowadzę rozmów odkrywczych, które kończą się 40-slajdową prezentacją. Prowadzę ustrukturyzowane zaangażowanie, które kończy się działającym systemem.

Każdy projekt przechodzi przez te same cztery fazy. Skracanie tego procesu nie oszczędza czasu — kosztuje go.

Faza 1 — Odkrycie

Czas trwania: 1-2 sesje, 60 minut każda. Format: Wideorozmowa lub spotkanie osobiste. Nagrywane za Twoją zgodą (wyłącznie do mojego użytku, nigdy udostępniane). Koszt: Bezpłatnie. Bez zobowiązań.

Zaczynam od zmapowania Twojej rzeczywistej sytuacji, nie wersji, którą Twoim zdaniem chcę usłyszeć. Wypolerowane prezentacje workflow mnie nie interesują — interesuje mnie, jak ta praca naprawdę wygląda.

Czego szukam

Podczas Odkrycia poluje na cztery rzeczy:

Wycieki czasu. Gdzie ten sam rodzaj pracy powtarza się raz za razem, pochłaniając godziny, które mogłyby być spędzone inaczej? Nie "jesteśmy zajęci" — konkretne, powtarzające się zadania, które mają wzorzec.

Wzorce decyzyjne. Które decyzje w Twoim workflow są złożone (wymagające doświadczenia, oceny, kontekstu, który zmienia się za każdym razem), a które są schematyczne (podążające za regułami, które da się zapisać)? AI radzi sobie dobrze z decyzjami schematycznymi. Źle radzi sobie ze złożonymi. Rozróżnienie tych dwóch to pierwszy krok.

Przepływ danych. Jak informacje przemieszczają się przez Twoją organizację? Gdzie się zacinają? Gdzie się gubią? Gdzie ludzie ręcznie kopiują dane z jednego systemu do drugiego? Te punkty styku są często najlepszymi kandydatami do automatyzacji.

Tarcie narzędziowe. Które z Twoich istniejących narzędzi dobrze ze sobą współpracują, a które nie? CRM z dobrym API ułatwia integrację. System legacy, który eksportuje pliki CSV tylko ręcznie, utrudnia. Muszę to wiedzieć, zanim cokolwiek oszacuję.

Czym Odkrycie NIE jest

Odkrycie nie jest prezentacją sprzedażową. Nie pokażę Ci demo AI i nie będę czekał aż zrobisz wrażenie.

Odkrycie nie jest "analizą potrzeb," gdzie potakuję na wszystko, co mówisz, a potem proponuję najdroższe rozwiązanie. Jeśli Twoje potrzeby nie pasują do tego, co buduję, powiem Ci o tym podczas Odkrycia, nie po tym, jak się zobowiążesz.

Odkrycie nie jest początkiem projektu. To punkt decyzyjny. Możesz wyjść z jasnym "nie" i to jest zupełnie prawidłowy wynik. Dobre Odkrycie kończące się "nie" jest cenniejsze niż złe Odkrycie kończące się projektem, który nie powinien był wystartować.

Co ze sobą przynosisz

Dostęp do prawdziwych przykładów. Rzeczywiste e-maile, rzeczywiste raporty, rzeczywiste workflow. Nie wyczyszczone wersje. AI napotka Twoje prawdziwe dane, z całym ich bałaganem i niespójnościami. Muszę to zobaczyć podczas Odkrycia, nie podczas budowy.

Odkrycie jest bezpłatne. Przejście do Specyfikacji nie wymaga żadnych zobowiązań, a jeśli projekt nie będzie dobrym dopasowaniem, powiem Ci o tym, zanim ta faza się rozpocznie.

Pełny przewodnik po procesie Odkrycia, w tym jak się przygotować i czego się spodziewać, znajdziesz w Konsultacja: dlaczego ma znaczenie.

Faza 2 — Specyfikacja

Czas trwania: 3-5 dni roboczych po Odkryciu. Rezultat: Pisemna specyfikacja funkcjonalna. Twoja rola: Przegląd, pytania, zatwierdzenie.

Piszę specyfikację funkcjonalną, zanim napiszę choćby jedną linijkę kodu. To obowiązkowy krok i najważniejszy dokument w całym projekcie.

Jak wygląda dokument specyfikacji

Typowa specyfikacja liczy 5-15 stron w zależności od zakresu. Zawiera następujące sekcje:

Opis problemu. Co rozwiązujemy, napisane prostym językiem. Jeśli Twój zespół przeczyta tę sekcję i nie rozpozna problemu, to znaczy, że się pomyliłem.

Dokładne wejścia i wyjścia. Co wchodzi do systemu (format danych, źródła, częstotliwość) i co z niego wychodzi (raporty, powiadomienia, przetworzone dokumenty, odpowiedzi API). Bez niejasności. Jeśli wejściem jest e-mail, precyzuję jaki rodzaj e-maila, z jakiego źródła, w jakim formacie.

Logika przetwarzania. Co AI robi z danymi wejściowymi. Krok po kroku, w kolejności. Włącznie z tym, co się dzieje, gdy AI napotka coś, z czym nie potrafi sobie poradzić (ścieżka awaryjna jest równie ważna jak ścieżka główna).

Przypadki brzegowe. Rzeczy, które czynią prosty proces złożonym. Zidentyfikowałem je podczas Odkrycia, a tutaj są udokumentowane z konkretnymi instrukcjami obsługi. "Klient wysyła e-mail w języku, którego nie obsługujemy" — co się dzieje? "Na fakturze brakuje wymaganego pola" — co się dzieje? Każdy przypadek brzegowy ma odpowiedź.

Granica zakresu. Czego system NIE robi, zapisane wprost. Ta sekcja zapobiega 90% rozmów typu "ale myślałem, że to też będzie..." podczas budowy. Jeśli nie ma tego w specyfikacji, nie jest w zakresie.

Punkty integracji. Z jakimi narzędziami system się łączy, jak i co się dzieje, gdy te połączenia zawiodą. Specyfikacje API, wymagania uwierzytelniania, limity zapytań — wszystko udokumentowane.

Kryteria akceptacji. Jak poznasz, że budowa jest poprawna. Konkretne, mierzalne testy, które system musi zaliczyć, zanim uznam go za ukończony. To standard, którego obie strony będą się trzymać.

Dlaczego pisemne specyfikacje zapobiegają porażkom projektów

Większość projektów AI upada, bo zakres nigdy nie został spisany. Obie strony miały inny obraz w głowie. Dostawca myślał, że "klasyfikacja e-maili" oznacza sortowanie do 5 kategorii. Klient myślał, że oznacza czytanie, streszczanie i routing do właściwej osoby z gotową odpowiedzią. Nikt się nie mylił — nikt nie spisał, co miał na myśli.

Specyfikacja to umowa między nami. Nie umowa prawna (choć może być w niej przywoływana), ale umowa operacyjna. To jedyne źródło prawdy o tym, co budujemy. Kiedy podczas budowy pojawiają się pytania — a pojawiają się zawsze — wracamy do specyfikacji.

Jeśli nie ma tego w specyfikacji, nie jest w zakresie. Jeśli chcesz, żeby było w zakresie, dodajemy to do specyfikacji (z zaktualizowanym harmonogramem i kosztem). To nie biurokracja, tylko sposób, żeby obie strony wiedziały, na czym stoją.

Przeglądasz i zatwierdzasz specyfikację. Jeśli się w czymś nie zgadzamy, rozwiązujemy to na piśmie przed rozpoczęciem budowy. Nikt nie zaczyna kodować z nierozwiązanymi pytaniami.

Faza 3 — Budowa

Czas trwania: zależy od instalacji. openclaw: do 5 dni roboczych. hermes: 7-12 dni roboczych. custom: 3-7 dni. hybrid: 2-4 tygodnie. Twoja rola: Testowanie na prawdziwych danych, dawanie feedbacku, zgłaszanie problemów.

Jak budowa wygląda w praktyce

Typowy cykl dla instalacji openclaw (do 5 dni) lub hermes (7-12 dni):

Dni 1-3: Rdzeń systemu zbudowany i skonfigurowany. Agent AI zintegrowany, podstawowa logika przetwarzania zaimplementowana. Dni 4-5: Testy wewnętrzne na Twoich przykładowych danych z Odkrycia. Łapię oczywiste problemy, zanim cokolwiek zobaczysz. Dzień 6: Dostajesz dostęp do pierwszej działającej wersji. Nie demo — prawdziwy system podłączony do Twoich danych. Dni 6-8: Testujesz na prawdziwej pracy. Nie hipotetyczne scenariusze — Twoje rzeczywiste dokumenty, Twoje rzeczywiste e-maile, Twoje rzeczywiste procesy. Dni 9-10: Naprawiam to, co się zepsuło, koryguję to, co czuło się nie tak, poprawiam obsługę przypadków brzegowych, które odkryłeś. Testujemy ponownie, aż kryteria akceptacji ze specyfikacji zostaną spełnione.

Instalacja custom (Claude Code / Codex CLI wpięte w Twój stack) działa szybciej: 3-7 dni, bo środowisko masz już gotowe. Hybrid to system złożony z kilku warstw i trwa 2-4 tygodnie.

Ten cykl trwa tyle iteracji, ile potrzeba. Nie mam ustalonej liczby rund poprawek. Mam kryteria akceptacji i iteroję, aż zostaną spełnione.

Testowanie na prawdziwych danych

"Testowanie na prawdziwych danych" oznacza dokładnie to, co mówi. Nie buduję demo z wyselekcjonowanymi przykładami i nie uznaję go za gotowe. Podłączam system do Twoich rzeczywistych źródeł danych i pozwalam mu przetwarzać prawdziwe dane wejściowe.

Tu pojawiają się niespodzianki. Format e-maila, który działał idealnie w testach, psuje się, bo jeden klient używa podpisów HTML z osadzonymi obrazami. Parser dokumentów obsługuje PDF-y z Twojego systemu bez problemu, ale dławi się na skanach od partnera. Model klasyfikacji działa świetnie po polsku, ale Twoi klienci czasem piszą po angielsku.

Te niespodzianki są normalne. Dlatego iteroję. I dlatego testuję na prawdziwych danych, a nie na demo — bo dane demo nigdy nie zawierają niespodzianek.

Bugi vs. prośby o nowe funkcje

Podczas budowy wyraźnie rozróżniam bugi i prośby o nowe funkcje.

Bug to sytuacja, gdy system nie robi tego, co specyfikacja mówi, że powinien. Klasyfikacja e-maili ma sortować do 5 kategorii, ale konsekwentnie wrzuca "zapytania o faktury" do "ogólne" zamiast "finanse." To jest bug. Naprawiam go, bez dyskusji.

Prośba o nową funkcję to sytuacja, gdy chcesz, żeby system robił coś, czego nie ma w specyfikacji. "Czy mógłby też przygotowywać odpowiedź?" — gdy specyfikacja obejmuje tylko klasyfikację. To jest prośba o nową funkcję. Trafia do backlogu. Jeśli chcesz ją dodać do bieżącej budowy, aktualizujemy specyfikację, harmonogram i koszt na piśmie.

To rozróżnienie nie wynika ze złośliwości. Chodzi o ochronę harmonogramu projektu i pewność, że obie strony wiedzą, co jest w zakresie. Pełzanie zakresu to zabójca numer jeden projektów AI, i się przed nim bronię.

Workflow weryfikacji jakości

Każdy wynik produkowany przez moje systemy przechodzi wieloetapowy proces weryfikacji:

Automatyczne sprawdzenia. Walidacja formatu, integralność danych, wykrywanie błędów.
Krzyżowa weryfikacja AI. Drugi model AI weryfikuje wynik pierwszego. Inny model, inny prompt, niezależna ocena.
Przegląd manualny. Ręcznie sprawdzam próbki z każdej kategorii wyników, skupiając się na przypadkach brzegowych i decyzjach o wysokiej stawce.
Testowanie przez Ciebie. Testujesz na prawdziwej pracy i zgłaszasz rozbieżności.

Ten workflow istnieje, bo modele AI halucynują. To znana właściwość technologii, nie wada implementacji. Liczy się nie to, czy AI popełnia błędy, ale czy są wyłapywane, zanim dotrą do użytkownika końcowego.

Faza 4 — Przekazanie

Każda budowa kończy się pakietem przekazania dostarczonym Tobie lub Twojemu zespołowi.

Co zawiera pakiet przekazania

Przekazanie to zbiór wszystkiego, czego potrzebujesz do obsługi systemu beze mnie:

Dokumentacja systemu. Co zostało zbudowane, jak działa, przegląd architektury, opisy komponentów. Napisane dla Twojego zespołu, nie dla inżynierów (chyba że Twój zespół to inżynierowie — wtedy piszę dla inżynierów).
Podręcznik operacyjny. Instrukcje krok po kroku dla typowych zadań utrzymaniowych: dodawanie nowych wpisów do bazy wiedzy, korygowanie promptów, aktualizowanie źródeł danych, restartowanie komponentów po awarii.
Pliki konfiguracyjne. Wszystkie prompty systemowe, ustawienia modelu, poświadczenia integracji (bezpiecznie przechowywane) i konfiguracje workflow. Wszystko jest wersjonowane w repozytorium GitHub, które należy do Ciebie.
Znane ograniczenia. Uczciwa lista tego, czego system nie obsługuje dobrze, z obejściami. Każdy system ma ograniczenia. Dokumentuję je, zamiast udawać, że nie istnieją.
Przewodnik rozwiązywania problemów. Typowe problemy i jak je rozwiązać. "AI zaczyna dawać krótsze odpowiedzi" — sprawdź okno kontekstowe, może być pełne. "Spada dokładność klasyfikacji" — sprawdź, czy nie zmienił się format danych wejściowych.
Protokół kontaktu supportowego. Jak się ze mną skontaktować w okresie wsparcia, oczekiwane czasy odpowiedzi, co kwalifikuje się jako bug.

Co oznacza "możesz to obsługiwać beze mnie"

To jest mój standard. Jeśli Twój zespół nie potrafi obsługiwać systemu na co dzień bez dzwonienia do mnie, przekazanie się nie powiodło.

Konkretnie, Twój zespół powinien umieć:

Dodawać nową treść do bazy wiedzy
Korygować prompty AI, gdy zmieniają się potrzeby biznesowe
Monitorować stan systemu i rozpoznawać, kiedy coś idzie nie tak
Obsługiwać typowe problemy korzystając z przewodnika rozwiązywania problemów
Wiedzieć, kiedy problem przekracza ich możliwości i wymaga profesjonalnego wsparcia

Nie buduję systemów, które tworzą trwałą zależność. Zatrudniłeś mnie, żebym coś zbudował. Kiedy jest zbudowane, jest Twoje. W pełni.

Sesja przeprowadzająca

Każda instalacja kończy się rozmową na żywo, podczas której przechodzę przez system z Twoim zespołem. Dla pakietu hybrid ta sesja jest dłuższa — obejmuje architekturę, routing między warstwami i zaawansowaną konfigurację.

Sesja jest nagrywana i dołączana do Twojego pakietu przekazania. Nowi członkowie zespołu mogą ją obejrzeć później.

Co dzieje się między fazami

Projekty nie przechodzą z jednej fazy do następnej natychmiast. Oto jak wyglądają typowe okresy przejściowe:

Odkrycie do Specyfikacji: 1-3 dni robocze. Przetwarzam notatki, szkicuję wstępną strukturę specyfikacji i zaczynam pisać.

Specyfikacja do Budowy: 1-5 dni roboczych. Przeglądasz specyfikację, zadajesz pytania, poprawiam, Ty zatwierdzasz. Proste specyfikacje trwają dzień. Złożone mogą wymagać tygodnia wymiany uwag.

Budowa do Przekazania: Bezpośrednio po spełnieniu kryteriów akceptacji. Nie przedłużam projektów sztucznie.

Typowy całkowity harmonogram od pierwszej sesji Odkrycia do działającego systemu:

openclaw / hermes: 1-3 tygodnie
custom: 1-2 tygodnie
hybrid: 3-5 tygodni

To realne przedziały — uwzględniają cykle przeglądów i okna feedbacku, nie tylko sam czas budowy.

Czerwone flagi, na które zwracam uwagę

Czasem muszę wstrzymać lub zatrzymać projekt. Oto sygnały ostrzegawcze:

Brak feedbacku przez 5+ dni roboczych. Wysłałem Ci build do testów. Mija pięć dni. Cisza. To oznacza, że albo projekt nie jest dla Ciebie priorytetem (co oznacza, że harmonogram się poślizgnie), albo coś poszło nie tak, a Ty mi o tym nie powiedziałeś (co oznacza, że nie mogę tego naprawić). Tak czy inaczej, wstrzymuję i planuję rozmowę kontrolną.

Zakres zmienia się szybciej, niż jesteśmy w stanie go specyfikować. "Właściwie, czy mógłby też obsługiwać faktury?" w poniedziałek. "A co z reklamacjami klientów?" w środę. "I czy możemy dodać dashboard raportowy?" w piątek. Każda z tych rzeczy może być rozsądna pojedynczo. Razem wskazują, że problem nie jest jeszcze dobrze zdefiniowany, a budowanie pod ruchomy cel marnuje czas wszystkich.

Interesariusze, których nie było na Odkryciu, teraz podejmują decyzje. Zmapowałem proces z Tobą. Rozumiałeś kompromisy. Teraz Twój przełożony (który nie był w pokoju) ma inne priorytety i chce inne funkcje. To nie jest problem techniczny — to problem organizacyjny. Wstrzymuję się, aż wszyscy decydenci będą zgodni.

Syndrom "jeszcze jedna drobna rzecz." Każdy dodatek ma koszt, nawet mały. Kiedy małe dodatki się kumulują, tworzą złożoność, która nie była uwzględniona w specyfikacji, harmonogramie ani cenie. Traktuję każdy dodatek jako aneks do specyfikacji — spisany, oszacowany, zatwierdzony — zamiast pozwalać mu przejść bez uwagi.

Kiedy widzę te czerwone flagi, nie pcham się dalej na ślepo. Zatrzymuję się, zgłaszam problem na piśmie i proponuję rozwiązanie. Czasem oznacza to sesję ponownego określania zakresu. Czasem oznacza to wydłużenie harmonogramu. W rzadkich przypadkach oznacza to wstrzymanie projektu, aż warunki wstępne wrócą na swoje miejsce.

Komunikacja

Wszystko na piśmie. E-mail lub współdzielony wątek projektowy. Nie zarządzam projektami przez WhatsApp, wiadomości prywatne na Slacku ani nieformalne rozmowy telefoniczne. Komunikacja pisemna tworzy zapis, zapobiega nieporozumieniom i pozwala obu stronom wyszukiwać decyzje podjęte tygodnie temu.

Cotygodniowe aktualizacje statusu w piątki. Krótkie, ustrukturyzowane: co zostało ukończone w tym tygodniu, co jest zaplanowane na przyszły tydzień, ewentualne blokery. Będziesz dokładnie wiedzieć, na jakim etapie jest projekt, bez konieczności pytania.

Oczekiwania dotyczące odpowiedzi. Odpowiadam na wiadomości projektowe w ciągu 24 godzin w dni robocze. Oczekuję tego samego od Ciebie. Kiedy obie strony odpowiadają szybko, projekty trzymają się harmonogramu. Kiedy jedna strona milknie, harmonogramy się rozjeżdżają.

Żadnych decyzji projektowych w nieformalnych kanałach. Jeśli coś jest omawiane na rozmowie, wysyłam pisemne podsumowanie. Jeśli wyślesz wiadomość WhatsApp ze zmianą, potwierdzę jej otrzymanie i poproszę o wysłanie jej e-mailem. Nie chodzi o sztywność, tylko o to, żeby nic się nie zgubiło.

Jeśli coś jest zablokowane po Twojej stronie przez ponad 5 dni roboczych, harmonogram przesuwa się odpowiednio. To samo działa w drugą stronę: jeśli blokada jest po mojej stronie, powiadamiam Cię w ciągu 24 godzin i koryguję harmonogram na piśmie.

ostatnia aktualizacja: 2026-05-11