Nasz proces: od odkrycia do przekazania
Nie prowadzimy rozmów odkrywczych, które kończą się 40-slajdową prezentacją. Prowadzimy ustrukturyzowane zaangażowanie, które kończy się działającym systemem.
Każdy projekt przechodzi przez te same cztery fazy. Pomijanie ich to sposób, w jaki projekty upadają. Nie niektóre projekty — wszystkie. Widzieliśmy wystarczająco dużo nieudanych wdrożeń AI, żeby wiedzieć, że proces istnieje z konkretnego powodu, a skracanie go nie oszczędza czasu. Kosztuje czas.
Faza 1 — Odkrycie
Czas trwania: 1-2 sesje, 60 minut każda. Format: Wideorozmowa lub spotkanie osobiste. Nagrywane za Twoją zgodą (wyłącznie do naszego użytku, nigdy udostępniane). Koszt: Bezpłatnie. Bez zobowiązań.
Zaczynamy od zmapowania Twojej rzeczywistej sytuacji, nie wersji, którą Twoim zdaniem chcemy usłyszeć. Nie szukamy wypolerowanych prezentacji Twojego workflow. Szukamy prawdy.
Czego tak naprawdę szukamy
Podczas Odkrycia polujemy na cztery rzeczy:
Wycieki czasu. Gdzie ten sam rodzaj pracy powtarza się raz za razem, pochłaniając godziny, które mogłyby być wykorzystane na coś bardziej wartościowego? 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. Musimy to wiedzieć, zanim cokolwiek oszacujemy.
Czym Odkrycie NIE jest
Odkrycie nie jest prezentacją sprzedażową. Nie pokażemy Ci demo AI i nie będziemy czekać, aż zrobisz wrażenie. Nie jesteś tu, żeby nas podziwiać.
Odkrycie nie jest "analizą potrzeb," gdzie potakujemy na wszystko, co mówisz, a potem proponujemy najdroższe rozwiązanie. Jeśli Twoje potrzeby nie pasują do tego, co budujemy, powiemy 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. Musimy 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, powiemy 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.
Piszemy specyfikację funkcjonalną, zanim napiszemy choćby jedną linijkę kodu. To nie jest opcjonalne. To nie jest formalność. To najważniejszy dokument w całym projekcie.
Jak wygląda dokument specyfikacji
Typowa specyfikacja liczy 5-15 stron w zależności od poziomu projektu. 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ę pomyliliśmy.
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, precyzujemy 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. Zidentyfikowaliśmy 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 uznamy 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 jest biurokracja — to jasność.
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 poziomu. Tier 2: 2-4 tygodnie. Tier 3: 4-8 tygodni. Tier 4: 8-16 tygodni. Twoja rola: Testowanie na prawdziwych danych, dawanie feedbacku, zgłaszanie problemów.
Jak budowa wygląda w praktyce
Typowy cykl iteracji wygląda tak:
Tydzień 1 (przykład Tier 2):
- ›Dni 1-3: Rdzeń systemu zbudowany i skonfigurowany. Model AI zintegrowany, baza wiedzy załadowana, podstawowa logika przetwarzania zaimplementowana.
- ›Dni 4-5: Testy wewnętrzne na Twoich przykładowych danych z Odkrycia. Łapiemy oczywiste problemy, zanim cokolwiek zobaczysz.
Tydzień 2:
- ›Dzień 1: Dostajesz dostęp do pierwszej działającej wersji. Nie demo — prawdziwy system podłączony do Twoich danych.
- ›Dni 2-4: Testujesz na prawdziwej pracy. Nie hipotetyczne scenariusze — Twoje rzeczywiste dokumenty, Twoje rzeczywiste e-maile, Twoje rzeczywiste procesy.
- ›Dzień 5: Zgłaszasz, co zadziałało, co się zepsuło i co czuło się nie tak. Zbieramy ten feedback na piśmie.
Tydzień 3:
- ›Dni 1-3: Naprawiamy to, co się zepsuło, korygujemy to, co czuło się nie tak, poprawiamy obsługę przypadków brzegowych, które odkryłeś.
- ›Dni 4-5: Testujesz ponownie. Powtarzamy, aż kryteria akceptacji ze specyfikacji zostaną spełnione.
Ten cykl trwa tyle iteracji, ile potrzeba. Nie mamy ustalonej liczby rund poprawek. Mamy kryteria akceptacji i iterujemy, aż zostaną spełnione.
Testowanie na prawdziwych danych
"Testowanie na prawdziwych danych" oznacza dokładnie to, co mówi. Nie budujemy demo z wyselekcjonowanymi przykładami i nie uznajemy go za gotowe. Podłączamy system do Twoich rzeczywistych źródeł danych i pozwalamy 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 angielsku, ale Twoi klienci czasem piszą po niemiecku.
Te niespodzianki są normalne. Dlatego iterujemy. I dlatego testujemy 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óżniamy 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. Naprawiamy 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 aktywnie się przed nim bronimy.
Nasz workflow weryfikacji jakości
Każdy wynik produkowany przez nasze 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 ludzki. Ręcznie sprawdzamy próbki z każdej kategorii wyników, skupiając się na przypadkach brzegowych i decyzjach o wysokiej stawce.
- ›Testowanie klienta. 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 naszej implementacji. Pytanie nigdy nie brzmi "czy AI popełnia błędy?" — brzmi "czy błędy są wyłapywane, zanim dotrą do użytkownika końcowego?" Nasz workflow weryfikacji to sposób, w jaki je wyłapujemy.
Faza 4 — Przekazanie
Każda budowa kończy się pakietem przekazania dostarczonym Twojemu zespołowi.
Co zawiera pakiet przekazania
Przekazanie to zbiór wszystkiego, czego Twój zespół potrzebuje do obsługi systemu bez nas:
- ›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 piszemy 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. Dokumentujemy je, zamiast udawać, że nie istnieją.
- ›Przewodnik rozwiązywania problemów. Typowe problemy i jak je rozwiązać. "AI zaczyna dawać krótkie 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ę z nami skontaktować w okresie wsparcia, oczekiwane czasy odpowiedzi, co kwalifikuje się jako bug.
Co oznacza "możecie to obsługiwać bez nas"
To jest nasz standard. Jeśli Twój zespół nie potrafi obsługiwać systemu na co dzień bez dzwonienia do nas, 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 budujemy systemów, które tworzą trwałą zależność. Zatrudniłeś nas, żebyśmy coś zbudowali. Kiedy jest zbudowane, jest Twoje. W pełni.
Sesja szkoleniowa
Dla projektów Tier 3 i Tier 4 przekazanie obejmuje sesję szkoleniową na żywo z Twoim zespołem:
- ›Tier 3: Do 2 godzin. Obejmuje codzienną obsługę, typowe utrzymanie i rozwiązywanie problemów.
- ›Tier 4: Do 4 godzin. Obejmuje wszystko powyżej plus przegląd architektury, interakcje komponentów i zaawansowaną konfigurację.
Szkolenie jest nagrywane i dołączane do Twojego pakietu przekazania. Nowi członkowie zespołu mogą je 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 → Specyfikacja: 1-3 dni robocze. Przetwarzamy nasze notatki, szkicujemy wstępną strukturę specyfikacji i zaczynamy pisać.
Specyfikacja → Budowa: 1-5 dni roboczych. Przeglądasz specyfikację, zadajesz pytania, my poprawiamy, Ty zatwierdzasz. Proste specyfikacje trwają dzień. Złożone mogą wymagać tygodnia wymiany uwag.
Budowa → Przekazanie: Natychmiast po spełnieniu kryteriów akceptacji. Nie przedłużamy projektów sztucznie.
Typowy całkowity harmonogram od pierwszej sesji Odkrycia do działającego systemu:
- ›Tier 2: 4-6 tygodni
- ›Tier 3: 8-12 tygodni
- ›Tier 4: 12-22 tygodnie
To są realne przedziały, nie estymaty marketingowe. Uwzględniają cykle przeglądów i okna feedbacku, które zawsze się zdarzają.
Czerwone flagi, na które zwracamy uwagę
Czasem musimy wstrzymać lub zatrzymać projekt. Oto sygnały ostrzegawcze:
Brak feedbacku przez 5+ dni roboczych. Wysłaliśmy 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 nam o tym nie powiedziałeś (co oznacza, że nie możemy tego naprawić). Tak czy inaczej, wstrzymujemy i planujemy 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. Zmapowaliśmy 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. Wstrzymujemy 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. Radzimy sobie z tym, traktując każdy dodatek jako aneks do specyfikacji — spisany, oszacowany, zatwierdzony — zamiast pozwalać mu przejść bez uwagi.
Kiedy widzimy te czerwone flagi, nie pchamy się dalej na ślepo. Zatrzymujemy się, zgłaszamy problem na piśmie i proponujemy 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ądzamy 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. Odpowiadamy na wiadomości projektowe w ciągu 24 godzin w dni robocze. Oczekujemy 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łamy pisemne podsumowanie. Jeśli wyślesz wiadomość WhatsApp ze zmianą, potwierdzimy jej otrzymanie i poprosimy o wysłanie jej e-mailem. To nie jest sztywność — chodzi 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 naszej stronie, powiadamiamy Cię w ciągu 24 godzin i korygujemy harmonogram na piśmie.