Co się dzieje, gdy odchodzi konsultant

Pułapka zależności

Zatrudniłeś konsultanta, by zbudował AI. Zbudował. Działa. Odchodzi.

Trzy miesiące później model dryfuje. Dokładność spada. Nikt nie wie dlaczego. Nikt nie wie, jak go retrenować. Nikt nie wie, gdzie żyją dane treningowe.

Dzwonisz do konsultanta. Jest „dostępny za retainer”. 8 tys. €/miesiąc. By utrzymać system, za który zapłaciłeś 150 tys. € budowy.

To nie błąd w zaangażowaniu. To model biznesowy. Zbuduj coś, czego nie posiadasz, a potem każ za utrzymanie na zawsze.

Widziałem ten wzorzec wielokrotnie. To najczęstszy wynik konsultingu AI - i najmniej omawiany. Nikt nie pisze case studies o systemie, który stał się zakładnikiem.

Jak rozpoznać dostawcę budującego zależność

Sygnały są widoczne od pierwszego dnia, jeśli wiesz, na co patrzeć:

Nie dokumentują. Albo dokumentują w sposób, który tylko oni rozumieją - żargon wewnętrzny, nieudokumentowane założenia, odwołania do rozmów, które odbyły się w Slacku.

Nie szkolą twojego zespołu. „Twój zespół nie jest jeszcze gotowy na to” to gra na zwłokę, nie plan. Jeśli nie potrafią powiedzieć, kiedy twój zespół będzie gotowy i jakie szkolenie go tam doprowadzi, nie planują odejścia.

Używają własnych narzędzi lub frameworków, które tylko oni potrafią obsługiwać. Własne obudowy, prywatne biblioteki, wewnętrzne platformy. Jeśli narzędzie ma nazwę ich firmy, nie użyjesz go bez nich.

Trzymają klucze wdrożeniowe. Nie możesz wdrożyć bez nich. Nie możesz zmienić promptu bez nich. Nie możesz zaktualizować modelu bez nich.

Nie mają planu przekazania. Albo „plan przekazania” to 2-godzinne połączenie i PDF, którego nikt nie przeczyta po połączeniu.

Jeśli widzisz którykolwiek z tych sygnałów, nie budujesz możliwości. Budujesz zależność.

Jak wygląda „prawdziwe przekazanie”

Prawdziwe przekazanie to nie spotkanie. To zestaw artefaktów i proces zaczynający się w pierwszym dniu zaangażowania:

Dokumentacja: Diagramy architektury, mapy przepływu danych, karty modeli, logi decyzji. Napisane dla twojego zespołu, nie dla konsultanta. Jeśli twój główny inżynier nie rozumie dokumentacji, to nie dokumentacja - to rekwizyt.

Kod: W twoim repozytorium, z twoim pipeline’em CI/CD, z twoimi kontrolami dostępu. Nie w prywatnym repo konsultanta. Nie we współdzielonej przestrzeni, którą kontrolują. Twoje repo. Twoje zasady.

Runbooki: Co robić, gdy model dryfuje. Co robić, gdy dokładność spada. Co robić, gdy API się zmienia. Co robić, gdy opóźnienie skacze. Krok po kroku. Nie „zadzwońcie do nas” - actual kroki, które twój zespół może wykonać.

Szkolenie: Twój zespół cieniuje konsultanta podczas budowy. Uczestniczą w standupach, przeglądają kod, zadają pytania. Nie tylko patrzą - uczą się. Gdy konsultant odchodzi, twój zespół od tygodni już to prowadzi.

Własność: Posiadasz kod, dane, modele, dokumentację. Wszystko. Bez wyjątków. Żadnego „damy ci kod po finalnej płatności”. Żadnego „model jest nasz, ale możesz go używać”. Twój.

Zespół, którego naprawdę potrzebujesz

Nie potrzebujesz zespołu badaczy AI. Potrzebujesz trzech osób, które prawdopodobnie już masz:

Właściciel AI - istniejący inżynier, awansowany lub przeszkolony. Rozumie system, potrafi debugować, może koordynować z dostawcami w razie potrzeby. Nie musi być ekspertem AI. Musi być osobą, która wie, jak działa system i do kogo zadzwonić, gdy nie działa.

Osoba od danych - istniejący analityk lub inżynier danych. Zarządza potokami danych, monitoruje jakość, zajmuje się retrenowaniem. Już pracuje z twoimi danymi. Teraz pracuje z danymi karmiącymi AI.

Właściciel produktu - istniejący PM lub lider biznesowy. Jest właścicielem rezultatu biznesowego, śledzi miary, priorytetyzuje ulepszenia. To osoba, która mówi „AI oszczędza nam 30 godzin/tydzień” albo „nikt tego nie używa, musimy naprawić przepływ”.

To trzy osoby. Nie potrzebują doktoratów. Potrzebują szkolenia, dokumentacji i własności.

Jeśli konsultant mówi „musisz zatrudnić zespół AI”, zapytaj go, co konkretnie każda osoba by robiła. Jeśli nie potrafi jasno wyjaśnić, zawyża sprzedaż.

Model fazowego przekazania

Właściwe przekazanie dzieje się w fazach, nie w jednym spotkaniu na końcu:

Faza 1 (w trakcie budowy): Twój zespół cieniuje. Uczestniczą w standupach, przeglądają kod, zadają pytania. Nie budują - uczą się. Ale są w pokoju.

Faza 2 (przed wdrożeniem): Twój zespół uruchamia system z obecnym konsultantem. Wprowadzają zmiany, wdrażają aktualizacje, obsługują problemy. Konsultant przegląda, ale nie robi. Twój zespół prowadzi z instruktorem jazdy na fotelu pasażera.

Faza 3 (po wdrożeniu): Twój zespół prowadzi sam. Konsultant dostępny na pytania, ale nie na operacje. Check-in po 30 dniach. Ostateczny przegląd po 90 dniach. Konsultant to sieć bezpieczeństwa, nie kierowca.

Faza 4 (niezależność): Twój zespół posiada wszystko. Konsultant odszedł. System działa. Jeśli coś się psuje, twój zespół to naprawia. Mają dokumentację, runbooki i wiedzę.

Jeśli konsultant nie zobowiąże się do tego modelu fazowego, nie planuje odejścia. Planuje zostać - na twojej liście płac.

Koszt zależności vs koszt możliwości

Zależność: Retainer 8 tys. €/miesiąc × 36 miesięcy = 288 tys. €. Plus oryginalny koszt budowy. Plus koszt niemożności wprowadzania zmian bez dostawcy. Plus koszt niemożności zmiany dostawcy, bo nikt inny nie rozumie systemu.

Możliwość: Przeszkolenie 3 istniejących członków zespołu = 15-30 tys. € jednorazowo. Plus dokumentacja (wliczona w budowę). Plus bieżąca pensja (i tak ich już płacisz).

Matematyka nie jest bliska. Zależność kosztuje 10x więcej niż możliwość. A możliwość oznacza, że możesz zwolnić konsultanta.

Pytania przed podpisaniem

1. „Kto jest właścicielem kodu i modeli po projekcie?” Ty. Na piśmie. Nie „masz licencję” - ty posiadasz.

2. „Jaką dokumentację otrzymujemy?” Architektura, przepływ danych, karty modeli, runbooki. Napisane dla twojego zespołu.

3. „Jak nasz zespół jest szkolony w trakcie projektu?” Cieniowanie, praktyczne, fazowa własność. Z harmonogramem.

4. „Co się stanie, jeśli będziemy chcieli zmienić dostawcę w trakcie projektu?” Możesz. Wszystko jest w twoich repo. Brak lock-in.

5. „Jaki jest proces przekazania?” Fazowy. Z harmonogramem. Z kryteriami sukcesu. Nie 2-godzinne połączenie.

Jeśli odpowiedzi są mgliste, przekazanie też będzie mgliste.

Co ja robię

Moje zaangażowania obejmują przekazanie od pierwszego dnia. Twój zespół jest w pokoju podczas audytu. Cieniują podczas budowy. Prowadzą system przed moim odejściem.

Dostarczam dokumentację, runbooki i szkolenie. Zobowiązuję się do fazowego przekazania z ustaloną datą końcową.

Pobieram opłatę za projekt, nie za zależność. Gdy skończę, skończyłem. Jeśli chcesz mnie z powrotem, to nowe zaangażowanie - nie retainer. Dzwonisz do mnie, bo chcesz, nie bo musisz.

FAQ

Co jeśli nasz zespół jest za mały? Trzy osoby wystarczą. Jeśli macie mniej, omawiamy modele cząstkowej własności - dzielone odpowiedzialności między rolami. Kluczem jest, by ktoś posiadał wiedzę, nie że potrzebujesz dedykowanego zespołu AI.

Co jeśli chcemy wsparcia bieżącego? Dostępne. Ale jako zaangażowania projektowe, nie retainer. Dzwonisz do mnie, gdy cię potrzebujesz, nie gdy jesteś zmuszony. Jest różnica.

Co jeśli system się psuje po twoim odejściu? Twój zespół ma runbooki. Jeśli nie potrafią naprawić, zadzwoń do mnie. To nowe zaangażowanie - o określonym zakresie, wycenione i tymczasowe. Nie negocjacja zakładników.