Najdroższe w projekcie IT są pytania, których nikt nie zadał

Powodów jest wiele, ale dla mnie najciekawsze są sytuacje, w których dotychczasowe narzędzie zaczyna ograniczać rozwój firmy. Technicznie może działać bez zarzutu, a mimo to nie pozwalać jej zrobić kolejnego kroku.

Współpracujemy z federacją sportową ze Stanów Zjednoczonych, która zrzesza setki tysięcy członków. Korzystali z dużej, gotowej platformy. Chcieli wprowadzić zmiany w tym, jak obsługują członków, jaki mają dostęp do danych i co mogą z nimi robić, ale dostawca nie planował rozbudowy dla jednego klienta. Mieli wybór: zaakceptować status quo albo zbudować własny system i mieć kontrolę nad tym, jak będzie działać.

Z kolei w przypadku dużej polskiej firmy cateringowej powodem było bezpieczeństwo operacyjne. Ich cały proces sprzedaży opierał się na zewnętrznym systemie. Początkowo to miało sens biznesowy, ale urośli na tyle, że uzależnienie kluczowego procesu od innej firmy stało się zbyt dużym ryzykiem.

Ważny bywa też wizerunek. Amerykańska firma szkoleniowa zwróciła się do nas z prośbą o przebudowanie aplikacji mobilnej, bo jej słabe oceny w sklepach odbijały się na całej marce.

Zainteresował Cię ten temat? Zobacz podcast - kliknij poniżej.

Moim zdaniem ta granica mocno się przesunęła. Budowanie własnego rozwiązania nadal jest inwestycją, która musi się zwrócić, ale dziś można zrobić to szybciej i taniej. Uważam, że najwięcej sensu ma inwestowanie we własne rozwiązania tam, gdzie mają one styczność z klientem. Tam powstaje doświadczenie, którym można realnie wygrać. Rzeczy powtarzalnych, jak system księgowy, nie ma sensu wymyślać na nowo.

Styczność z klientem to nie tylko strona i aplikacja. Mamy klienta e-commerce z Niemiec, który robi dedykowane nadruki. Jego klienci projektowali je w aplikacji, ale proces i tak wymagał zaangażowania grafika: otwierał plik, poprawiał i odsyłał - i tak w kółko. To był koszt operacyjny, ale przede wszystkim blokada: nie dało się skrócić czasu realizacji ani poszerzyć oferty bez powiększania zespołu. Zbudowaliśmy narzędzia wewnętrzne, które maksymalnie ograniczyły ręczną pracę. Dzięki temu graficy zyskali czas na przygotowywanie nowych wzorów, a firma mogła poszerzyć ofertę.

Powiem kolokwialnie: AI jest tu wisienką na torcie. Istotne są dwie zmiany, które w ostatnich latach obserwowaliśmy na rynku i w technologii.

Pierwsza to koszty zespołu. W okresie covidowym podwyżki rzędu pięćdziesięciu procent były standardem i potrafiły pochłonąć marżę projektu. Dziś rynek jest ustabilizowany.

Druga to dojrzałość technologii. Przez lata trwały wojny o frameworki i co kilka miesięcy pojawiało się coś nowego. Od dwóch, trzech lat to się uspokoiło.

Dopiero na tym fundamencie AI zaczyna dawać realne efekty, pod dwoma warunkami: że korzystają z niej ludzie, którzy wiedzą, co robią, i że pracujemy w technologiach, na których modele były uczone. Gdy sięgamy po niszową technologię, zaczynają się halucynacje, model podsuwa rozwiązania sprzed kilku wersji i wygenerowany kod po prostu nie działa.

Nie widzę problemu, żeby ktoś sam zbudował proste rozwiązanie i go używał. Mój znajomy prowadzący sieć piekarni potrzebował narzędzia do obsługi wejść. Poradziłem mu, żeby spróbował zrobić to sam. Udało się, system działa. Osoba bez zaplecza w IT też może zrobić coś, co przyniesie realną wartość.

Nie chodzi o to, czy zbudowałeś coś samodzielnie, tylko o poziom złożoności systemu i związane z nim ryzyko. Im więcej funkcji i danych, im bardziej skomplikowana sieć dostępów, im bardziej rozbudowana infrastruktura, tym łatwiej wpaść w pętlę, w której dodajesz jedną rzecz, a psujesz inną.

Do tego dochodzi kwestia bezpieczeństwa. Bardzo często dostajemy zapytanie: "zbudowałem system, trzeba tylko poprawić security". Tylko że powyżej pewnego poziomu złożoności nie wystarczy załatać dziury. Często okazuje się, że fundamentów po prostu nie ma i trzeba przebudować system od zera.

Jako prototyp takie rozwiązanie ma jednak dużą wartość. Klient może nam pokazać, co chce osiągnąć, zamiast próbować wszystko opisać. Sami tak pracujemy przy większych projektach. Kiedy ludzie mogą coś zobaczyć i przeklikać, łatwiej im powiedzieć, czego potrzebują i co powinno działać inaczej. Wychodzą też rzeczy, o których wcześniej nie pomyśleli. Dopiero potem budujemy właściwy system - na odpowiedniej architekturze.

Widzę tendencję, którą podpowiada sama AI: napisać rozbudowane zapytanie ofertowe ze szczegółowo rozpisanymi wymaganiami, czasem nawet ze strukturami danych. To tworzy gigantyczny szum informacyjny. Dostajemy gotową koncepcję rozwiązania, ale prawie nic o tym, jaki problem ma ono rozwiązać. A to jest najważniejsze.

Rozumiem, skąd to się bierze: żeby dostać porównywalne oferty, trzeba wysłać wszystkim tak samo zdefiniowany zakres prac. Problem w tym, że lista wymagań niewiele mówi o specyfice danego biznesu ani o tym, jak firma pracuje. Wyceniamy wstępnie zdefiniowaną koncepcję, nie mając pewności, czy odpowiada rzeczywistym potrzebom firmy.

Dlatego my zaczynamy od pytania o problem, który klient chce rozwiązać. Wtedy staje się jasne, które elementy specyfikacji rzeczywiście są potrzebne, a czego w niej brakuje. Jeśli pomija się ten krok, często kończy się znacznym przekroczeniem budżetu.

Mieliśmy klienta, mniejszą polską firmę, która chciała przebudować swój portal. Przyszli z problemem biznesowym i dostali trzy bardzo różne wyceny: bardzo niską, naszą mniej więcej pośrodku i bardzo wysoką. Każda firma inaczej podeszła do tego samego problemu. Najtańsza zbagatelizowała jego skalę, najdroższa pochodziła od dużej organizacji pracującej w strukturze korporacyjnej. Klient dobrze zrobił, przychodząc z problemem. Trudność polegała na tym, że takich ofert nie da się porównać jeden do jednego.

Szukałbym firmy, która się w danym obszarze specjalizuje. Wtedy przychodzisz z problemem, a druga strona wie, o co zapytać i czego potrzeba, żeby ten problem rzeczywiście rozwiązać - zamiast uczyć się twojej branży za twoje pieniądze.

Zwróciłbym też uwagę na to, z kim rozmawiam od samego początku. My zrezygnowaliśmy z modelu, w którym handlowcy prowadzili wstępne rozmowy. Dla nas istotne jest, żeby ktoś od razu zadał dobre pytania i zakwestionował rzeczy niemożliwe albo trudne, bazując na bieżącym doświadczeniu projektowym. To dynamiczna branża, więc trzeba stale być zaangażowanym w projekty i zdobywać nową wiedzę.

Największym ryzykiem jest na ogół to, czego nie wiesz, czego nie przewidziałeś i nie zaplanowałeś.

Rozmawialiśmy kiedyś z firmą, która zamówiła u innego dostawcy konfigurator produktowy z modelami 3D. Budżet się skończył, narzędzie działało, ale część back-office do przygotowywania modeli, materiałów i opcji nie była dostosowana do pracowników, którzy mieli z niej korzystać. Dopracowanie tej części mogło oznaczać drugi projekt o podobnym budżecie. Pojawiło się więc pytanie, czyja to wina: tych, którzy przygotowali specyfikację, czy tych, którzy realizowali projekt.

Takim sytuacjom staram się zapobiegać. Zaczynam od zrozumienia, jak firma pracuje i jakie ma procesy. Jak najwcześniej włączam w rozmowy wszystkie osoby, których projekt dotyczy.

Minimum ze strony klienta to jedna osoba, która jest punktem styku i ma dostęp do wiedzy wewnątrz firmy. Nie musi znać się na IT, ale musi wiedzieć, z kim i o czym porozmawiać. Bez tego ryzyko rośnie.

To nie koniec. Trzeba cyklicznie ponosić koszt utrzymania infrastruktury. Przy niewielkim, zamkniętym systemie po pierwszych miesiącach stabilizacji i drobnych poprawek dalsze utrzymanie może ograniczyć się do aktualizacji bibliotek i reagowania na ostrzeżenia dotyczące bezpieczeństwa. Przy większych lub stale rozwijanych projektach często zostaje jedna osoba na część etatu, a czasem mały zespół.

Wiedza ekspercka nadal będzie miała dużą wartość. AI dobrze radzi sobie z generowaniem powtarzalnego kodu, ale działa na podstawie wzorców i prawdopodobieństwa. Może zaproponować rozwiązanie, które sprawdza się statystycznie, ale niekoniecznie będzie najlepsze w twoim przypadku.

Wiedza ekspercka polega między innymi na przewidywaniu konsekwencji decyzji: co się stanie, jeśli zrealizujemy coś w określony sposób, jak wpłynie to na doświadczenie użytkownika i czy rzeczywiście rozwiąże problem biznesowy. Nacisk przesuwa się z pisania kodu na rozumienie kontekstu i podejmowanie właściwych decyzji. AI jeszcze nie zastępuje człowieka w odkrywaniu potrzeb, których klient sam nie nazwał, ani w ocenie konsekwencji podejmowanych decyzji w konkretnym kontekście biznesowym.

Nie należy bać się tych narzędzi. Trzeba z nich korzystać i śledzić ich rozwój, ale też weryfikować efekty ich pracy. Nie polegajmy na nich w stu procentach. Sama AI to często wciąż za mało, żeby rozwiązać problem biznesowy. Dlatego udział człowieka nadal jest tak ważny.

Dziękuję za rozmowę.