Wszystko zaczęło się od efektownej premiery. Google właśnie zaprezentowało multimodalne funkcje Gemini – technologię, która wyglądała wystarczająco obiecująco, by potencjalnie rozwiązać problemy związane z interakcją człowieka z przeglądarką. Zespół inżynieryjny uznał, że będzie to szybki eksperyment o niskim ryzyku.
Spróbował jeden zespół. Potem kolejny. A następnie trzeci.
Jednak choć sama koncepcja była ekscytująca, rzeczywiste narzędzie nie było jeszcze wystarczająco dopracowane. Znajdowało się na wczesnym etapie rozwoju, nie nadawało się do zastosowań produkcyjnych i zdecydowanie nie było dostosowane do przypadku użycia zespołu.
„Było to rozpraszające i mogło z łatwością wykoleić postępy w realizacji naszych dotychczasowych priorytetów, gdybyśmy nie zahamowali” – wspomina Anand Sainath, szef działu inżynieryjnego i współzałożyciel 100x, który podjął decyzję o przerwaniu integracji.
Inni nie mieli jednak tyle szczęścia. W przypadku wielu zespołów pogoń za „kolejną wielką rzeczą” stopniowo przejęła mapę drogową produktu. Pozostała po niej zbieranina niedopracowanych narzędzi i pominiętych priorytetów – coś, co Sainath określa mianem cichego kosztu syndromu błyszczącego obiektu.
Czym właściwie jest syndrom błyszczącego obiektu?
Syndrom błyszczącego obiektu (SOS) pojawia się, gdy zespoły dają się odciągnąć od realizacji priorytetów przez nowe narzędzia, struktury programistyczne lub technologie, często kosztem dotychczasowych celów.
„Gdy pojawia się nowa technologia, tak jak ma to dziś miejsce w przypadku AI, rynek ekscytuje się jej zastosowaniami. Może pojawić się presja, by zwrócić się w stronę tego trendu i wyprzedzić konkurencję” – mówi Raju Malhotra, CPTO w Certinia.
Wtedy „błyszczące” narzędzie lub struktura programistyczna zaczyna wkradać się do planów i „odciąga zespół inżynieryjny od pracy, która ma dziś rzeczywiste znaczenie dla klientów”.
Historia Evernote spełnia wszystkie kryteria z karty bingo syndromu błyszczącego obiektu. Firma miała wszystkie właściwe składniki: lojalnych użytkowników, solidny produkt i jasno określoną niszę. Zamiast skupić się jeszcze bardziej na swoich kluczowych funkcjach, firma rozszerzyła działalność o produkty fizyczne i wprowadziła niedopracowane funkcje produktu, takie jak Work Chat.
Produkt stał się przeładowany, wydajność spadła, a użytkownicy przeszli do prostszych narzędzi, takich jak Notion i Google Keep. W 2022 roku Evernote zostało przejęte, a na początku 2023 roku zwolniono większość jego pracowników.
SOS nie zawsze kończy się bankructwem lub zwolnieniami, ale niemal zawsze wykoleja postępy poprzez:
- Opóźnianie realizacji projektów: Częste zmiany kierunku na rzecz nowych technologii w trakcie projektu mogą zakłócić planowanie, zaburzyć cykle realizacji i wprowadzić rozbudowany, nieplanowany zakres prac. Dokładnie to wydarzyło się w przypadku projektu Virtual Case File FBI. Po pięciu latach i wydaniu 170 milionów dolarów projekt porzucono, częściowo dlatego, że zmieniające się uzgodnienia między biurokracją a biznesem nieustannie zakłócały rytm realizacji.
- Zwiększanie kosztów inżynieryjnych: Bez struktury programistycznej do oceny nowych technologii decyzje motywowane syndromem błyszczącego obiektu często prowadzą do nadmiaru narzędzi, długu technicznego i wysokich kosztów tworzenia oprogramowania. Zespoły poświęcają nawet czas na prototypy, które nigdy nie trafiają do wdrożenia albo, co gorsza, zostają wdrożone, a następnie przepisane.
- Obniżanie produktywności programistów: Każde nowe narzędzie oznacza kolejną krzywą uczenia się, więcej błędów i więcej „szybkich testów”, które rzadko pozostają szybkie. Rozprasza to uwagę inżynierów, obniża produktywność nawet o 40% i prowadzi do zmęczenia oraz ciągłego gaszenia pożarów – energii, którą można by przeznaczyć na tworzenie kluczowych funkcji produktu.
- Podważanie zaufania interesariuszy: SOS wysyła również niewłaściwy sygnał liderom biznesowym. Gdy priorytety zmieniają się zbyt często, a terminy się przesuwają, kadra kierownicza może zacząć kwestionować zdolność działu inżynieryjnego do realizacji zadań. Gdy zaufanie zostanie utracone, trudno je odzyskać.
Jak uniknąć żalu z powodu błyszczących obiektów: 3 pytania kontrolne dla zespołu
Wiesz, jakie spustoszenie syndrom błyszczącego obiektu może wywołać w Twoim zespole. Jak więc ocenić, czy nowa biblioteka, SDK lub usługa jest tego warta – zanim pochłonie czas i uwagę? Nasi eksperci mają kilka sprawdzonych pytań kontrolnych:
- Czy to „nakładka”, czy „plaster”?
Filtr Sainatha stosowany przy ocenie nowych, efektownych narzędzi i technologii jest prosty: Czy rozwiązuje to problem, który ma długoterminowe znaczenie, czy jest tylko plastrem?
„Plaster jedynie zakrywa drobne przypadki brzegowe lub krótkoterminowe ograniczenia. Istnieje jednak duże prawdopodobieństwo, że następna wersja modelu i tak rozwiąże ten problem. Co się wtedy stanie z tym, co zbudowałeś? Natychmiast się zdezaktualizuje.”
Bardziej interesuje go tworzenie nakładek – czystych warstw umieszczonych na modelach bazowych, które zapewniają rzeczywistą użyteczność dzięki projektowi, przepływom pracy lub kontekstowi.
„Określenie LLM jako „nakładki” było początkowo używane niemal pejoratywnie, ale zasadniczo wiele wartościowych produktów opiera się na bazowej technologii” — komentuje Sainath. „Spójrzmy na Cursor. Można argumentować, że to tylko nakładka, ale zapewnia znaczącą, ukierunkowaną wartość.”
Jego zdaniem prowizoryczne rozwiązania odwracają uwagę i łatwo mogą przerodzić się w lśniące obiekty. Dobrze zaprojektowane nakładki mogą natomiast stać się podstawowymi produktami.
- Czego nie zdecydujemy się zbudować?
Zdaniem Malhotry śledzenie tego, czego zespół decyduje się nie budować, jest równie ważne jak monitorowanie tego, co trafia do planu rozwoju. „Dzięki temu nie gonimy za funkcjami, które mogą dobrze wyglądać podczas demonstracji, ale w rzeczywistości nie usprawniają codziennej pracy” — mówi.
Nawet gdy zespół nie ma pewności, że coś jest gotowe do szerszego wdrożenia, nadal testuje to z pierwszymi użytkownikami. „Dzięki temu otrzymujemy informacje zwrotne bez zakłócania planu rozwoju.”
- Jaka jest wartość biznesowa?
Dla wiceprezesa ds. inżynierii w Customer.io, Paul Senechko, zrozumienie wartości biznesowej działań inżynieryjnych jest pierwszym i najważniejszym filtrem. Jeśli nowe narzędzie lub system nie służy któremukolwiek z tych celów, mówi, prawdopodobnie nie jest na niego właściwy moment.
„Naczelną zasadą przywództwa w naszej firmie jest to, że jesteśmy ekspertami w obszarze klientów” — wyjaśnia Senechko. „Wykorzystujemy tę zasadę, aby kierować naszymi inwestycjami w technologie i mieć pewność, że tworzymy z myślą o kliencie i biznesie.”
Aby utrzymać zespół na właściwym torze, Senechko opiera się na kilku prostych, ale skutecznych pytaniach: Ile kosztuje nas to pod względem czasu i zasobów? Czy usprawnia nasz produkt? Czy pomoże naszym klientom osiągać większe sukcesy?
Sainath dodaje własną perspektywę, przedstawiając pytania typu „co, jeśli”: „Co się stanie, jeśli bazowa technologia stanie się 10 razy lepsza? Czy nasz produkt z natury stanie się lepszy, czy nagle straci znaczenie?”
Bada również wysiłek potrzebny do osiągnięcia tych usprawnień: „Czy automatycznie skorzystamy z tych ulepszeń, czy też konieczna będzie gruntowna zmiana architektury, aby nadążyć?”
Przeanalizowanie tych scenariuszy wraz z zespołem może pomóc w podjęciu decyzji, czy nadać priorytet nowemu stosu technologicznego, czy pozostać przy rozwiązaniu, które już działa.
Uodpornianie planu rozwoju na syndrom lśniących obiektów (bez zabijania innowacji)
Gdy ekscytująca nowa technologia zawodzi, trzeba podchodzić do niej z rezerwą i równoważyć innowacje z rzeczywistym postępem.
Oto jak dyrektorzy ds. technologii radzą sobie z FOMO i utrzymują zespoły na właściwym torze oraz skupione na pracy:
- Zdefiniuj kryteria zakończenia projektów, zanim je rozpoczniesz
Wiele „eksperymentalnych” prób technologicznych przeradza się w długotrwałe projekty poboczne z rozszerzającym się zakresem i narastającym długiem technologicznym, głównie dlatego, że nikt nie definiuje, jak ani kiedy powinny się zakończyć. Jeśli nie ma właściciela, harmonogramu ani kryteriów sukcesu, syndrom lśniących obiektów prędzej czy później doprowadzi cały projekt do upadku. Aby tego uniknąć, traktuj każdą próbę technologiczną jak funkcję produktu: o określonym zakresie, ograniczoną czasowo, z przypisanym właścicielem i opartą na rzeczywistym przypadku użycia.
Jak ujmuje to Senechko: „Stosujcie je w małych, ale rzeczywistych przypadkach użycia, a następnie rozwijajcie rozwiązanie. Gdy decydujemy się eksperymentować z nowymi trendami, upewniamy się, że identyfikujemy mały lub dobrze odizolowany obszar, w którym możemy przetestować i zweryfikować, czy dane rozwiązanie działa. W ten sposób możemy eksperymentować i zdobywać rzeczywiste doświadczenie z technologią, zanim postawimy na nią na dużą skalę.”
Zaangażuj osobę oceniającą z różnych obszarów organizacji (EM + PM + inżynier techniczny), aby zapewnić obiektywną ocenę, i utwórz uporządkowany harmonogram obejmujący:
- Maksymalny czas trwania: ogranicz do 2 sprintów (+1 sprint rezerwowy), aby zachować zwięzłość i możliwość testowania
- Punkty kontrolne Kontynuować/Nie kontynuować z warunkami zakończenia: zdefiniuj wyraźny moment przeglądu, w którym zespół zdecyduje, czy kontynuować, iterować czy zakończyć projekt (ponad 10% kompilacji zakończyło się niepowodzeniem lub brak integracji z narzędziem CI/CD).
Senechko sugeruje nawet, aby zespoły eksperymentowały z inicjatywami o stałym czasie i zmiennym zakresie, w ramach których jego zespół ustala początkowy „apetyt” na to, ile czasu jest gotów poświęcić, i dąży do dostarczenia najbardziej wartościowego rezultatu w tym przedziale. „Pozwoliło nam to wprowadzać innowacje i szybko ponosić porażki, gdy nowe kierunki nie wydawały się prowadzić we właściwą stronę.”
- Wykorzystuj wskaźniki do mierzenia sukcesu
Gdy znana jest już wykonalność techniczna i nakład pracy inżynieryjnej, określ, jak wygląda sukces. To właśnie odróżnia zdyscyplinowane wdrożenie od projektu SOS, którego zakres wymknął się spod kontroli. Zbuduj ramy, które mierzą sukces w wielu wymiarach:
- Ludzie: wzrost produktywności programistów, zwiększenie liczby godzin pracy wymagającej głębokiego skupienia
- Procesy i przepływy pracy: krótszy czas wykonywania zestawu testów, mniej regresji, sprawniejsze przepływy wdrażania, krótszy czas wprowadzenia produktu na rynek
- Doświadczenie klienta: lepsza wydajność stron, mniej skarg dotyczących UX, krótszy czas odpowiedzi
- Wydajność systemu: szybsze obliczenia, niższe koszty infrastruktury, mniej incydentów lub wycofań zmian
- Poznaj swoich klientów
„Utrzymanie właściwego kierunku sprowadza się do szczerości w kwestii tego, gdzie powstaje wartość dla klienta” — twierdzi Malhotra. „Trendy mogą brzmieć ekscytująco, ale szybko mogą stać się rozpraszaczami, jeśli nie pomagają klientom bezpośrednio wykonywać ich pracy lepiej lub szybciej.”
Ta zasada znajduje odzwierciedlenie w tym, jak wiele zespołów łączy obecnie działy produktu i inżynierii z działem sukcesu klienta podczas bezpośredniej obserwacji pracy. Kilku inżynierów dołącza do rozmów z zespołem wsparcia, sesji wdrożeniowych lub spotkań kontrolnych z klientami, aby otrzymywać rzeczywiste, nieprzefiltrowane informacje zwrotne. Bezpośrednie usłyszenie, co dezorientuje użytkowników, co się psuje i co jest chwalone, buduje empatię, a nawet może usprawnić ustalanie priorytetów w zespołach inżynieryjnych.
Samo słuchanie jednak nie wystarczy. Aby zidentyfikować obszary, w których klienci rzeczywiście napotykają trudności, uzupełnij jakościowe informacje zwrotne o telemetrię produktu. Istnieje duża szansa, że Twoje narzędzie analityczne (PostHog, Amplitude, Heap) jest w tym celu niewykorzystywane w pełni. Zacznij śledzić, jak użytkownicy naprawdę korzystają z produktu: aż do poziomu kliknięć, przełączników, pętli nawigacyjnych i ścieżek błędów.
Połącz te dane dotyczące zachowań z zgłoszeniami do działu wsparcia, aby dostrzec wzorce. Czy funkcja jest ignorowana, ponieważ trudno ją znaleźć? Czy użytkownicy nie mogą ukończyć kluczowych przepływów pracy? Wykorzystaj te sygnały o wysokiej wartości informacyjnej jako impulsy do realizacji pilotażowych projektów skoncentrowanych na kliencie.
Z czasem w naturalny sposób zbudujesz formularz „głosu klienta” zawierający problemy klientów, informacje zwrotne, wyrazy zadowolenia i powtarzające się przeszkody, które przepływają od zespołów ds. sukcesu klienta do decyzji dotyczących produktu i inżynierii.
To ten sam system, którego zespół Senechko użył do ustalania priorytetów prac na podstawie mierzalnej wartości dla klienta: „Duża liczba klientów i wymagania dotyczące niskich opóźnień skłoniły nasz zespół do opracowania rozwiązań, których nie można było zrealizować przy użyciu gotowych technik. Inwestowanie w naszą platformę techniczną jest częścią DNA naszej firmy, ponieważ widzieliśmy korzyści, jakie przynosi to klientom i firmie.”
Ostatecznie rzeczywisty postęp w inżynierii będzie wynikał z projektowania nowych możliwości, które rozszerzają to, co już działa, a nie z budowania systemów obok istniejących rozwiązań ani z dokładania czegoś całkowicie nowego. W ten sposób zespoły mogą się rozwijać bez naruszania sprawdzonych systemów.
„Innowacja nie musi oznaczać zakłócenia. Powinna wzmacniać to, co już działa, i pomagać klientom działać szybciej przy mniejszym wysiłku” — ujmuje to prosto Malhotra.
Chcesz otrzymywać więcej takich spostrzeżeń? Zapisz się do newslettera The CTO Club.
