Trzy wdrożenia AI, które przestałem rozwijać - i czego mnie nauczyła ich śmierć

Mam w repozytorium folder, do którego rzadko zaglądam. Leżą w nim narzędzia, które kiedyś działały - niektóre nawet ładnie - a których dziś już nie uruchamiam. Nie zepsuły się. Ja je wyłączyłem. Świadomie, ręcznie, czasem z ulgą, czasem z lekkim wstydem, że w ogóle je zbudowałem.

O sukcesach we wdrażaniu AI piszę często, bo to one sprzedają. Ale prawda o prowadzeniu agencji AI dla małych i średnich firm jest taka, że na każde wdrożenie, które weszło na produkcję i tam zostało, przypada przynajmniej jedno, które umarło po cichu. I dziś chcę opowiedzieć o trzech takich - własnych, wewnętrznych, więc bez chowania się za klientem. Bo wcale nie żałuję, że je zbudowałem. Żałuję tylko, że za późno przyznałem przed sobą, kiedy trzeba je było pochować.

Spis treści

• Dlaczego w ogóle przyznaję się do porzuconych projektów?
• Narzędzie pierwsze: agregator, którego nikt nie otwierał
• Narzędzie drugie: automat na problem, którego nie miałem
• Narzędzie trzecie: model, który kosztował więcej, niż był wart
• Skąd wiadomo, że pora coś wyłączyć?
• Czy porzucenie to porażka?
• Co bym zrobił inaczej, gdybym zaczynał od zera?
• Co z tego zostaje
• Słownik pojęć

Dlaczego w ogóle przyznaję się do porzuconych projektów?

Bo to jest najuczciwsza część tej roboty, a jednocześnie ta, o której nikt nie chce mówić głośno. Branża AI sprzedaje obraz, w którym każde wdrożenie zwraca się w trzy miesiące, każdy automat oszczędza etat, a każdy model robi dokładnie to, co obiecał handlowiec. Ja w tej branży siedzę na tyle długo, że wiem, jak to wygląda od podszewki - również u mnie, w idea4me, gdzie testuję wszystko na sobie, zanim dotknę firmy klienta.

Zbudowałem przez te lata kilkanaście wewnętrznych narzędzi AI. Część z nich używam codziennie i opisywałem je nawet w tekście o pięciu narzędziach AI, których używam każdego dnia. Ale obok tych pięciu jest cała ławka rezerwowych, którzy nigdy nie weszli do gry, albo weszli i szybko zeszli. I właśnie z nich nauczyłem się najwięcej - bo działające narzędzie potwierdza, że miałeś rację, a martwe pokazuje dokładnie, w którym miejscu się pomyliłeś.

Jeden warunek przyjmuję od razu: porzucenie projektu to nie wpadka, którą trzeba ukryć. To decyzja - taka sama jak uruchomienie. Tyle że trudniejsza, bo trzeba przyznać, że poprzednia decyzja była błędna. A to boli bardziej niż napisanie kodu od nowa.

Narzędzie pierwsze: agregator, którego nikt nie otwierał

Pierwszy nieboszczyk to wewnętrzny pulpit, który miał zbierać w jednym miejscu wszystko, co dzieje się wokół moich klientów. Wzmianki o ich firmach w sieci, zmiany w rejestrach, nowe ogłoszenia, ruchy konkurencji. AI zbierała to z wielu źródeł, streszczała i układała w schludne karty. Technicznie - ładna robota. Otwierałem to rano i czułem się jak ktoś, kto ma palec na pulsie.

Co poszło nie tak

Po dwóch tygodniach przestałem tam zaglądać. Po miesiącu nie pamiętałem, że to w ogóle działa. Narzędzie chodziło dalej, ciągnęło dane, paliło moc obliczeniową i moje pieniądze - tylko nikt go nie czytał. Łącznie ze mną, czyli jedynym użytkownikiem, dla którego powstało.

Diagnoza okazała się brutalnie prosta. Zbudowałem rozwiązanie, które dostarczało informacji, ale nie domagało się żadnej akcji. To był strumień ciekawostek, nie narzędzie pracy. Codziennie dostawałem dziesięć rzeczy, o których fajnie było wiedzieć, i ani jednej, którą musiałbym z czymś zrobić. A ludzki mózg - również mój - bardzo szybko przestaje otwierać coś, co tylko informuje, a nigdy o nic nie prosi.

Co ciekawe, ten sam pomysł w innej formie żyje u mnie do dziś. Różnica jest jedna, ale zasadnicza: to, co przetrwało, codziennie ląduje mi w skrzynce o świcie jako krótka lista konkretów, które wymagają mojej reakcji - nie jako pulpit, do którego muszę z własnej woli wejść i się rozejrzeć. Narzędzie, które przychodzi do mnie z gotowym „zrób z tym to", wygrywa z najpiękniejszym ekranem, na który trzeba samemu kliknąć. Różnicę między tymi dwoma podejściami widać u mnie najlepiej na przykładzie porannego pulpitu, który składa mi dzień, zanim usiądę do biurka - on żyje właśnie dlatego, że nie czeka, aż go otworzę.

Czego mnie to nauczyło

Mylenie „dostępu do informacji" z „wartością" to jeden z najczęstszych błędów we wdrożeniach AI, jakie widzę u klientów. Firma chce pulpit, który „pokazuje wszystko". A potem nikt na ten pulpit nie patrzy, bo patrzenie samo w sobie nie jest niczyją robotą. Dane, które nie kończą się decyzją albo działaniem, to nie jest wartość. To dekoracja, za którą płacisz rachunek za prąd.

Dziś, gdy klient prosi mnie o „dashboard, który zbiera wszystko", zadaję jedno pytanie, którego kiedyś nie zadałem sobie samemu: co konkretnie zrobisz z tym, co tam zobaczysz? Jeśli odpowiedź brzmi „będę wiedział" - to za mało. Narzędzie ma popychać do ruchu, nie tylko karmić poczucie kontroli.

Narzędzie drugie: automat na problem, którego nie miałem

Drugi projekt boli mnie najbardziej, bo był najbardziej elegancki. Zbudowałem automat, który miał klasyfikować i porządkować przychodzącą korespondencję - rozpoznawać, co jest zapytaniem ofertowym, co fakturą, co spamem, co sprawą do pilnej obsługi, i każde wrzucać tam, gdzie trzeba. Brzmi sensownie. Większość poradników o AI w firmie zaczyna się dokładnie od takiego przykładu.

Gdzie była pułapka

Usiadłem kiedyś i policzyłem szczerze, ile maili dziennie naprawdę wymaga takiego sortowania. Wyszło, że garść. Kilkanaście, czasem mniej. Sortowanie kilkunastu wiadomości to dwie minuty mojego dnia - jeśli w ogóle, bo i tak większość rozpoznaję po nadawcy, zanim otworzę. Zbudowałem maszynę do rozwiązywania problemu, którego praktycznie nie miałem.

To jest podstępne, bo na etapie budowy wszystko wygląda racjonalnie. „Przecież automatyzacja powtarzalnych zadań to oczywista wygrana." Tak, jest - pod warunkiem, że to zadanie naprawdę cię kosztuje. A ja nie sprawdziłem kosztu wejściowego. Zakochałem się w eleganckim rozwiązaniu, zanim upewniłem się, że istnieje pasujący do niego problem. Szczerze? Zbudowałem to, bo było ciekawe technicznie, a wmówiłem sobie, że jest potrzebne.

Lekcja, która zmieniła moje pierwsze pytanie

Od tego automatu zmieniłem sposób, w jaki w ogóle zaczynam rozmowę o wdrożeniu - i u siebie, i u klienta. Pierwsze pytanie nigdy nie brzmi „co możemy zautomatyzować". Brzmi: ile cię ten proces realnie kosztuje dzisiaj - w godzinach, w pieniądzu, w błędach? Bo jeśli odpowiedź jest mała, to najlepsze wdrożenie AI na świecie i tak będzie droższe od problemu.

Rozmawiałem o tym z kilkudziesięcioma właścicielami firm i zebrałem to w tekście o barierach, które naprawdę powstrzymują firmy przed AI. Najczęstsza nie jest technologiczna. Najczęstsza to brak twardej odpowiedzi, co właściwie ma się poprawić - i o ile. Automat na nieistniejący problem to nie awaria techniczna. To pomyłka w pytaniu, które zadano na samym początku.

Narzędzie trzecie: model, który kosztował więcej, niż był wart

Trzeci przypadek jest najmniej dramatyczny i najbardziej pouczający, bo to narzędzie działało dobrze. Naprawdę dobrze. I właśnie dlatego najtrudniej było je wyłączyć.

Zbudowałem rozwiązanie oparte na cięższym modelu AI, które robiło coś użytecznego - na tyle, że używałem go regularnie i miało sens. Problem nie leżał w jakości. Problem leżał w arytmetyce, której długo nie chciałem zrobić.

Rachunek, który odkładałem

Utrzymanie tego narzędzia kosztowało mnie czas i pieniądze co miesiąc - zależności, które trzeba było aktualizować, model, który trzeba było karmić mocą obliczeniową, drobne awarie, które trzeba było łatać. Każda z tych rzeczy osobno była mała. Razem składały się na stały, cichy wyciek - taki, którego nie czujesz w danym tygodniu, ale który po roku robi się policzalny.

Kiedy wreszcie usiadłem i zestawiłem koszt utrzymania z realną korzyścią, którą to narzędzie dawało, wyszło na zero. A może i pod kreskę. Robiło coś przyjemnego i sprawnego, za co płaciłem mniej więcej tyle, ile to było warte - czyli interes, który nie ma sensu, gdy doliczysz swój czas na pilnowanie tego wszystkiego. Najgorsze wydatki to nie te duże i widoczne. To te małe i powtarzalne, których nikt nigdy nie sumuje.

Dlaczego prostsze bywa mądrzejsze

Zastąpiłem to narzędzie czymś znacznie prostszym, które robi siedemdziesiąt procent tego co poprzednie, za ułamek kosztu i bez niańczenia. I wiesz co? Tych brakujących trzydziestu procent w ogóle nie odczułem. Bo to były funkcje, które fajnie wyglądały w opisie, a w codziennej pracy nie robiły różnicy.

To prowadzi do prawdy, którą branża AI niechętnie powtarza, bo trudno na niej zarobić: najlepsze rozwiązanie to nie najmocniejsze. To najtańsze w utrzymaniu spośród tych, które dają wystarczający wynik. Cięższy model, większy automat, sprytniejsza architektura - to wszystko ma cenę, która tyka co miesiąc, długo po tym, jak handlowiec dostał prowizję. Pisałem o tej arytmetyce szerzej przy okazji tego, ile naprawdę kosztuje AI w firmie, i ta lekcja wraca do mnie za każdym razem, gdy korci mnie, żeby coś przekombinować.

Skąd wiadomo, że pora coś wyłączyć?

Najtrudniejsze w tych trzech historiach nie było zbudowanie narzędzi. Najtrudniejsze było przyznanie, kiedy każde z nich należało zgasić. Dorobiłem się z czasem kilku prostych sygnałów, które dziś traktuję jak czujnik dymu.

• Nikt go nie otwiera. Jeśli narzędzie działa, a Ty albo Twój zespół nie zaglądacie do niego z własnej woli przez dwa tygodnie - to narzędzie już umarło, tylko jeszcze o tym nie wie. Brak adopcji to nie kwestia przyzwyczajenia. To werdykt.
• Nie umiesz wskazać decyzji, którą zmienia. Zapytaj wprost: jaką decyzję podejmuję inaczej dzięki temu? Jeśli odpowiedź jest mglista, narzędzie produkuje informację dla samej informacji.
• Koszt utrzymania rośnie, a korzyść stoi. Gdy łatanie, aktualizowanie i pilnowanie zajmuje więcej, niż narzędzie oszczędza - rachunek już się nie spina, choćby działało bez zarzutu.
• Bronisz go dlatego, że go zbudowałeś. To najbardziej zdradliwy sygnał. Jeśli jedynym argumentem za dalszym życiem projektu jest „przecież włożyłem w to tyle pracy" - to mówi pycha, nie rachunek.

Ten ostatni punkt ma nawet swoją nazwę: koszt utopiony. Pieniądze i godziny, które już wydałeś, nie wrócą bez względu na to, co zrobisz dalej - więc nie powinny w ogóle wchodzić do decyzji o tym, co robić jutro. Wiem o tym od lat. I za każdym razem, gdy mam coś własnego wyłączyć, ta wiedza i tak musi przekrzyczeć dumę.

Czy porzucenie to porażka?

Tu chcę się postawić okoniem wobec tego, co słyszę w branży. Bo pokutuje przekonanie, że wyłączone wdrożenie to dowód, że ktoś się pomylił - że projekt „się nie udał". Otóż nie. Porzucenie udanego technicznie narzędzia, które przestało się opłacać, to nie porażka. To dojrzałość.

Pomyśl o tym jak o portfelu - nie programistycznym, tylko inwestycyjnym. Nikt nie nazywa inwestora przegranym dlatego, że sprzedał akcję, która przestała rosnąć. Nazywa się go rozsądnym. Każde narzędzie w firmie pożera zasób - Twoją uwagę, czas zespołu, pieniądze na utrzymanie. Trzymanie przy życiu projektu, który już nie zarabia na swój koszt, to nie wierność. To przepalanie zasobu, który mógłby pracować gdzie indziej.

Prawdziwa porażka wygląda inaczej. To nie wyłączenie narzędzia. To trzymanie go włączonym przez rok po tym, jak przestało mieć sens - bo nie chciało się przyznać, że było pomyłką. Najdroższe wdrożenia AI, jakie widziałem u klientów, to nie te, które padły szybko. To te, które ciągnięto latami na siłę, bo ktoś kiedyś podpisał za nie fakturę i wstyd było odpuścić.

Dlatego dziś mam w ofercie rzecz, która brzmi nieintuicyjnie dla firmy AI: czasem najlepszą rekomendacją, jaką mogę dać, jest „tego nie róbcie" albo „to wyłączcie". I tracę na tym pieniądze w danym momencie. Ale zyskuję klienta, który wie, że nie sprzedaję mu technologii dla samej technologii.

Co bym zrobił inaczej, gdybym zaczynał od zera?

Gdybym mógł szepnąć słowo sobie sprzed kilku lat - temu, który z zapałem budował te trzy narzędzia - powiedziałbym trzy rzeczy. Nie o kodzie. O myśleniu, które poprzedza kod.

Po pierwsze: zaczynaj od kosztu, nie od pomysłu. Zanim cokolwiek zbudujesz, zmierz, ile dzisiaj naprawdę kosztuje Cię problem, który chcesz rozwiązać. W godzinach, w złotówkach, w błędach. Jeśli nie umiesz tego policzyć, nie buduj - bo nie będziesz miał z czym porównać efektu. Połowy moich pomyłek nie popełniłbym, gdybym ten jeden rachunek zrobił na początku, a nie po roku.

Po drugie: buduj najmniejszą wersję, jaka w ogóle ma sens, i wypuść ją zanim się w niej zakochasz. Im więcej pracy włożysz, zanim sprawdzisz, czy to komuś służy, tym trudniej będzie Ci potem przyznać, że nie służy. Mała wersja, która szybko pokaże brak adopcji, jest tańsza niż piękny system, który odkrywasz jako zbędny dopiero po pół roku.

Po trzecie: wpisz datę przeglądu w kalendarz już w dniu uruchomienia. Za kwartał usiądź i zadaj zimne pytanie - czy to jeszcze pracuje na swój koszt? Bez tej daty narzędzia nie umierają. One zombieją - działają dalej, palą zasoby i nikt nigdy świadomie nie decyduje, że mają zostać. A najgorszy stan w firmie to nie rzecz wyłączona. To rzecz włączona, o której wszyscy zapomnieli.

Co z tego zostaje

Trzy narzędzia. Jedno, którego nikt nie otwierał, bo informowało, zamiast popychać do działania. Drugie, które rozwiązywało problem zbyt mały, żeby był wart maszyny. Trzecie, które działało świetnie, ale kosztowało więcej, niż dawało. Każde nauczyło mnie czegoś, czego nie nauczyłoby działające - bo sukces tylko klepie po plecach, a porażka wskazuje palcem dokładne miejsce, w którym pomyliłeś się w głowie.

Nie wstydzę się tych trzech grobów w repozytorium. Wstydziłbym się, gdybym je trzymał włączone do dziś, udając przed sobą i przed Tobą, że każde moje wdrożenie żyje i kwitnie. Bo umiejętność zbudowania narzędzia AI jest dziś tania i powszechna. Umiejętność przyznania, że pora je wyłączyć - wciąż rzadka. A to ta druga oszczędza firmie najwięcej pieniędzy.

Słownik pojęć

• Adopcja - to, czy ludzie faktycznie używają narzędzia, które dostali. Narzędzie może działać bez zarzutu technicznie i mieć zerową adopcję, czyli nie być otwierane przez nikogo. W praktyce zerowa adopcja oznacza, że projekt jest martwy, niezależnie od tego, jak dobrze działa.
• Koszt utopiony - pieniądze i czas już wydane, których nie odzyskasz bez względu na dalsze decyzje. Zasada brzmi: nie powinny wpływać na to, co robisz dalej. W praktyce to one najczęściej każą trzymać przy życiu projekty, które dawno powinny zostać wyłączone.
• Koszt utrzymania - powtarzalny, comiesięczny wydatek na to, żeby narzędzie dalej działało - moc obliczeniowa, aktualizacje, łatanie awarii, czas na nadzór. Bywa niewidoczny tydzień po tygodniu, ale po roku potrafi przekroczyć wartość, którą narzędzie daje.
• Model AI - tu w znaczeniu silnika, który wykonuje zadanie, na przykład czyta tekst i go klasyfikuje. Mocniejszy model zwykle daje lepszy wynik, ale kosztuje więcej w utrzymaniu - dlatego nie zawsze najmocniejszy jest najmądrzejszym wyborem.

Zanim zbudujesz - a tym bardziej zanim wyłączysz

Jeśli masz w firmie narzędzie AI, do którego nikt już nie zagląda, albo kusi Cię, żeby coś zbudować, bo „wszyscy mają" - napisz do mnie na j.cybulski@idea4me.pl. Najwięcej powiem Ci nie o tym, co warto uruchomić - tylko o tym, co warto zostawić w spokoju albo zgasić. Bo ta druga lista, ta trudniejsza do przyznania, oszczędza firmie więcej niż jakiekolwiek wdrożenie.

Więcej o tym, jak wygląda współpraca ze mną - od pierwszej rozmowy po wdrożenie.