Historia, którą za chwilę przedstawię, przeszła w Polsce właściwie bez echa, choć ponoć nas też dotyczyła. Dowiedziałem się o niej przypadkiem. W październiku tego roku hakerzy rozmrozili lodówki i zamrażarki w części francuskich supermarketów, zdalnie zmieniając ustawienia instalacji chłodniczych w setkach sklepów i podnosząc temperaturę nawet do 50°C. Żywność trzeba było wyrzucić, a straty liczono w milionach euro. Danfoss, który dostarczał sterowniki do tych chłodziarek, powiedział Reutersowi, że zaatakowane urządzenia działały na przestarzałym firmware, a firma wcześniej zalecała supermarketom jego aktualizację. Atakujący przejęli sterowniki instalacji chłodniczych, których interfejsy zarządzania były dostępne przez internet.
To, co umożliwiło atak, zostało pierwotnie zaprojektowane z myślą o oszczędnościach i było sensownym założeniem projektowym. Podłączone do sieci sterowniki chłodziarek i zamrażarek miały umożliwiać zdalny nadzór, wykrywanie awarii i ograniczanie kosztów wizyt serwisantów. Technik mógł sprawdzić parametry urządzenia bez wyjazdu do sklepu, a przy kilkuset placówkach dawało to konkretne korzyści. Zdalne sterowanie nie było dodatkiem wymyślonym po zakończeniu prac. Stanowiło część założeń całego rozwiązania. Zabrakło jednak kogoś, kto wziąłby na siebie odpowiedzialność za regularne aktualizacje, tak aby systemy dostępne z sieci przez cały okres pracy miały wielowarstwowe zabezpieczenia przed nieuprawnionym dostępem.
Zainteresowało mnie to, że lodówka jako produkt jest na rynku od ponad stu lat. Producenci przez ten czas nauczyli się projektować urządzenia chłodnicze i doskonalili technologię, natomiast zdalne oprogramowanie sterujące pojawiło się w tej historii znacznie później. Połączyliśmy więc produkt rozwijany od pokoleń ze stosunkowo nową technologią cyfrową, która starzeje się w zupełnie inny sposób.
Tradycyjna lodówka może prawidłowo pracować przez kilkanaście lat bez żadnej ingerencji i bez aktualizacji komponentów. Tymczasem oprogramowanie sterownika urządzenia podłączonego do sieci wymaga aktualizacji i stałego wsparcia producenta. Sama lokalna instalacja chłodnicza jest bezpieczna, ale połączenie z internetem może już stwarzać zagrożenie. Jako klienci przy zakupie pytamy o wydajność, gwarancję i zużycie energii, lecz znacznie rzadziej o to, jak długo oprogramowanie będzie aktualizowane i co powinniśmy zrobić, gdy producent zakończy wsparcie dla konkretnego rozwiązania. Czy nadal będziemy mogli bezpiecznie korzystać ze wszystkich funkcji?
Kto naprawdę zna cały produkt?
Niewielu producentów wyrobów fizycznych ma pełne doświadczenie w projektowaniu lub nadzorowaniu rozwiązań cyfrowych, które stosują w swoich produktach. Producent piekarnika może korzystać z gotowego modułu sterowania. W innym urządzeniu jedna firma dostarczy czujnik, a kolejna oprogramowanie lub system łączności. Na koniec z całością idziemy do klienta pod własną marką. Dla niego nie ma większego znaczenia, który kooperant napisał kod, a który dostarczył elektronikę. Kupuje gotowy produkt, wierzy w naszą markę i oczekuje, że produkt będzie działał.
Im więcej dostawców, tym trudniej ustalić, kto faktycznie nadzoruje bezpieczeństwo rozwiązania. Ktoś odpowiada za sterownik, ktoś inny za jego konfigurację i serwis. Kto jednak ocenia, czy wszystkie elementy nadal mogą bezpiecznie ze sobą współpracować?
Nie twierdzę, że tak właśnie wyglądał podział odpowiedzialności we francuskich supermarketach, bo pełne wyjaśnienie sprawy jeszcze się nie pojawiło. Wiem jednak, że pytanie, jak do tego doszło, staje się istotne dla każdej firmy, która oddaje kolejne elementy produktu w ręce zewnętrznych kooperantów.
Oczywiście są branże, które mają w tym ogromne doświadczenie, choćby motoryzacja czy lotnictwo. Ale czujnik mikrofalowy w mikserze raczej nie był dotąd powszechnie testowany.
Nowe technologie coraz częściej trafiają do produktów, które przez dziesięciolecia obywały się bez nich. Dodajemy czujniki, komunikację bezprzewodową, oprogramowanie, czasem AI. Czasem dlatego, że możemy, a czasem dlatego, że marzymy o stworzeniu czegoś, co wyprzedzi dostępne rozwiązania.
Wiedza o konstrukcji i technologii głównego wyrobu pozostaje po stronie doświadczonego producenta, natomiast wiedza o technologii cyfrowej przychodzi od dostawcy. Obie firmy mogą doskonale znać swoje rozwiązania, a mimo to nie wiedzieć wszystkiego o tym, jak oddziałują na siebie nawzajem.
Producent ciśnieniomierza może znakomicie rozumieć metody i ograniczenia pomiaru ciśnienia w swoim tradycyjnym produkcie. Dostawca modułu bezprzewodowego potrafi przesyłać dane z czujników do aplikacji. Czy to jednak wystarcza, żeby mieć pewność, że sprawdzono wszystkie warunki pracy gotowego produktu? Między poszczególnymi etapami pomiaru i rejestracji danych powstają zależności, których żadna ze stron nie musiała wcześniej badać w takim zestawieniu (nawet jeśli weźmiemy pod uwagę, że ciśnieniomierz jako wyrób medyczny podlega bardziej wymagającej certyfikacji niż inne urządzenia domowe).
Przypomina mi to oliwę i wodę: dwie doskonale znane substancje, obie płynne. Kiedy wlejemy je do jednego naczynia i wymieszamy, przez chwilę otrzymamy coś, co wygląda jak jednolita mieszanina. Po pewnym czasie znów zobaczymy dwie warstwy. Dziś potrafimy przygotować trwałą emulsję, bo wiemy, czego do tego potrzeba, ale ta wiedza nie wynika ze znajomości oliwy i wody osobno. Ich połączenie ma nowe właściwości.
Sam miałem kiedyś do czynienia z próbą połączenia dwóch bardzo różnych technologii. Każda była dobrze znana swojemu producentowi, a razem miały stworzyć dużą innowację produktową. Pierwsze testy dawały bardzo obiecujące wyniki i zapadła decyzja o kontynuacji projektu. Ostatecznie jednak wyrób nigdy nie trafił do sprzedaży, ponieważ właściwości fizyczne jednego z elementów sprawiały, że drugi w dłuższym okresie nie działał prawidłowo. Zewnętrzna firma dostarczająca elektronikę doskonale znała swoją pracę, lecz nie dysponowała wiedzą, która pozwoliłaby przewidzieć takie oddziaływanie w naszym zastosowaniu.
Nie nazwałbym tego automatycznie wadą jednej z technologii. Problem wynikał z ich połączenia w warunkach, których wcześniej nie sprawdzono. A pierwsze wyniki naprawdę dawały powody do optymizmu. Najbardziej dotkliwe w podobnych projektach jest właśnie to, że wcale nie musi brakować kompetentnych ludzi. Możemy mieć ich po obu stronach stołu i nadal nie mieć wiedzy, której wymaga zupełnie nowy układ.
Działało podczas testów. I co z tego wynika?
Obiecujący prototyp nie dowodzi jeszcze, że produkt nadaje się do wieloletniej, bezawaryjnej eksploatacji. NASA od lat posługuje się dziewięciostopniowym modelem Technology Readiness Levels, który rozróżnia między innymi próby laboratoryjne, testy w warunkach zbliżonych do rzeczywistych i demonstrację technologii w środowisku docelowym. Technologia kosmiczna wymaga oczywiście innych nakładów na badania niż zwykły piekarnik, jednak zasada pozostaje ta sama: wynik uzyskany na stanowisku testowym mówi nam przede wszystkim, jak urządzenie zachowało się na tym stanowisku.
Niepowodzenie odkryte podczas pierwszych badań może kosztować stosunkowo niewiele. Znacznie gorzej, gdy problem pojawi się już po zamówieniu narzędzi i zakupie komponentów. Do kosztów technicznych dochodzą wtedy wydatki marketingowe oraz napompowany balon oczekiwań dystrybutorów i klientów. Decyzja o jeszcze jednym teście lub zmianie konstrukcji przestaje być wyłącznie inżynierska i staje się decyzją biznesową, często bardzo trudną.
Nie oznacza to, że powinniśmy rezygnować z technologii zewnętrznych. Nikt nie jest specjalistą we wszystkich dziedzinach. Nawet największe koncerny korzystają z dostawców, a samodzielne rozwijanie każdej technologii byłoby kosztowne i nierzadko nieefektywne. Wyspecjalizowana firma może mieć dużo większe doświadczenie niż producent, który potrzebuje danego rozwiązania po raz pierwszy. Chciałbym tylko wiedzieć, gdzie to doświadczenie się kończy.
O powodzeniu outsourcingu decydują kompetencje obu stron i to, jak się wzajemnie uzupełniają, a nie jakość pojedynczego rozwiązania. Jeśli klient nic nie rozumie z technologii, którą zamawia, jak ma ocenić jakość pracy dostawcy i wychwycić błędne założenia?
Na rynku działa wiele wyspecjalizowanych firm. Jak wybrać właściwą? Możemy sprawdzić referencje, liczbę wdrożeń i doświadczenie branżowe, choć mnie szczególnie interesowałyby wcześniejsze niepowodzenia dostawcy. Czy spotkał się już z warunkami podobnymi do naszych, co wtedy poszło źle i jak rozwiązał problem? Jakie ograniczenia własnej technologii potrafi dziś wskazać? Prezentacja samych udanych wdrożeń nie zawsze mówi wystarczająco dużo.
AI dokłada kolejną niewiadomą
Sztuczna inteligencja jeszcze bardziej obniża barierę dostępu do technologii, których działania nie rozumiemy. Firma może na przykład kupić gotowe oprogramowanie do prognozowania popytu i dość szybko zacząć planować na podstawie jego rekomendacji. Trudniej ustalić, kiedy model przestanie być wiarygodny i czy w ogóle da się to przewidzieć. Jeśli przez kilka miesięcy prognozował dobrze, łatwo przyzwyczaić się do jego wyników. Co jednak, gdy zmieni się rynek, pojawi się nowy konkurent albo ważny klient nagle ograniczy zamówienia? System nadal może generować prognozy, które wyglądają na precyzyjne.
Badacze Microsoft Research przeanalizowali w 2025 roku 936 przykładów wykorzystania generatywnej AI. Zauważyli związek między większym zaufaniem do AI a mniejszym deklarowanym wysiłkiem krytycznego myślenia w podejściu do identyfikacji zagrożeń. Nie znaczy to, że AI odbiera ludziom zdolność myślenia, ale daje dobry powód, żeby wcześniej ustalić sposób nadzoru nad rekomendacjami, zwłaszcza gdy na ich podstawie wydajemy pieniądze.
W projektach opartych na nieznanych technologiach trzeba planować nie tylko kolejne zadania w harmonogramie, lecz także zdobywanie brakującej wiedzy. Eksperymentowanie i sprawdzanie alternatyw mogą być rozsądniejsze niż sztywne trzymanie się planu, którego założeń jeszcze nie potwierdzono. Czasem lepiej wydać więcej na dłuższy proces badawczy bez presji czasu. Presja najczęściej prowadzi do skracania i upraszczania harmonogramu, zwłaszcza gdy ryzyko próby, która może zakończyć się niepowodzeniem, wydaje się większe niż ryzyko wprowadzenia na rynek produktu, którego ograniczeń nadal nie znamy.
Product manager nie musi być ekspertem od każdej technologii. Sam uważam, że byłoby to nierealne. Musi jednak potrafić ocenić granice kompetencji swojej organizacji, rozumieć przynajmniej podstawowe ograniczenia kupowanych rozwiązań i zadawać dostawcom pytania, na które nie zawsze mają gotowe odpowiedzi. Jeśli tego nie robimy, o kosztach i przyszłości produktu decydujemy na podstawie założeń, których nikt nie potrafił sprawdzić.