Starsza kierowniczka produktu mówi, że zespoły dostarczające rozwiązania powinny koncentrować się na tarciach zamiast dążyć do automatyzacji

Jeśli chodzi o realizację projektów, skupiam się na definiowaniu tego, co i dlaczego tworzymy, uzgadnianiu priorytetów między zespołami oraz zapewnianiu, że dostarczamy rozwiązania niezawodnie i w szybkim tempie. Oznacza to ścisłą współpracę z zespołem inżynieryjnym przy realizacji zadań, przy jednoczesnym stałym monitorowaniu wpływu na klientów, jakości i ciągłego doskonalenia.

You should also read

• Wskazówki dotyczące budowania profilu na Slacku

• Jak opanować zarządzanie zasobami w zarządzaniu projektami

Dlaczego sztuczna inteligencja zmienia realizację projektów z reaktywnej na strategiczną

Sztuczna inteligencja zasadniczo zmieniła zarówno moją rolę, jak i codzienną realizację projektów. Wcześniej realizacja zależała od ręcznej koordynacji, reaktywnego debugowania i ludzkiej analizy. Dziś, gdy sztuczna inteligencja jest wbudowana w nasze przepływy pracy, praca stała się bardziej strategiczna.

Na co poświęcam teraz mniej czasu:

• Ręczne sortowanie i debugowanie: wcześniej identyfikowanie przyczyn źródłowych błędów wymagało wielokrotnej wymiany informacji między zespołami. Teraz systemy sztucznej inteligencji mogą automatycznie wykrywać problemy, klasyfikować je, a nawet sugerować poprawki. Znacznie ograniczyło to początkowy nakład pracy.
• Pisanie szczegółowych specyfikacji dla każdego przypadku brzegowego: zamiast wyczerpująco dokumentować wszystko z wyprzedzeniem, w większym stopniu polegamy na eksploracji wspomaganej przez sztuczną inteligencję, symulacjach i szybkich iteracjach w celu dopracowania rozwiązań.
• Śledzenie statusu i koordynacja: śledzenie postępów, podsumowania i raportowanie są teraz zautomatyzowane, co ogranicza potrzebę ciągłych działań następczych.

Saloni opowiada

Moja rola ewoluowała od ścisłego zarządzania realizacją do kształtowania sposobu, w jaki inteligentne systemy realizują zadania w naszym imieniu.

Na czym skupiam teraz więcej uwagi:

• Definiowanie właściwych problemów i sygnałów: ponieważ sztuczna inteligencja może działać szybko, jakość danych wejściowych ma znacznie większe znaczenie. Poświęcam więcej czasu na zastanawianie się, co monitorować, które sygnały są istotne i jak systemy powinny reagować.
• Projektowanie przepływów pracy wspomaganych przez sztuczną inteligencję: zamiast skupiać się wyłącznie na funkcjach, projektujemy kompleksowe przepływy, w których agenci sztucznej inteligencji wykrywają problemy, podejmują działania, a czasami nawet je rozwiązują. Ta zmiana — od narzędzi do systemów — stanowi obecnie istotną część mojej roli.
• Jakość i zaufanie: gdy sztuczna inteligencja podejmuje decyzje lub je sugeruje, zapewnienie niezawodności, wyjaśnialności i zaufania użytkowników ma kluczowe znaczenie. Poświęcam więcej czasu na weryfikowanie wyników i definiowanie zabezpieczeń.
• Szybkość i odpowiedzialność: dostarczamy rozwiązania szybciej niż wcześniej, ale oczekiwania również są wyższe. Nie chodzi tylko o szybkie działanie, lecz o szybkie działanie bez regresji. Zachowanie tej równowagi wymaga bardziej rygorystycznego myślenia produktowego.

Ogólnie rzecz biorąc, zmiana w realizacji projektów wygląda następująco: przeszliśmy od reaktywnego modelu napędzanego przez ludzi do bardziej proaktywnego modelu wspomaganego przez sztuczną inteligencję. Wcześniej wykrywamy problemy, cykle ich rozwiązywania ulegają skróceniu, a zespoły poświęcają mniej czasu na gaszenie pożarów i więcej na ulepszanie samego systemu.

Moja rola ewoluowała więc od ścisłego zarządzania realizacją do kształtowania sposobu, w jaki inteligentne systemy realizują zadania w naszym imieniu.

Jak sztuczna inteligencja zmienia sortowanie incydentów

Nie próbowaliśmy automatyzować wszystkiego. Zamiast tego skupiliśmy się na obszarach o wysokiej częstotliwości i powtarzalności poznawczej, które spowalniały pracę inżynierów. Sortowanie incydentów i RCA były jednymi z takich obszarów, ponieważ odbywają się codziennie, wymagają dużego nakładu czasu i opierają się w dużej mierze na rozpoznawaniu wzorców.

Nasza konfiguracja agentów obejmuje agenta sygnałów, który wykrywa anomalie na podstawie danych telemetrycznych; agenta kontekstu, który pobiera dzienniki, ślady i powiązane przebiegi; agenta RCA, który generuje przyczynę źródłową i dowody; oraz agenta działań, który tworzy zgłoszenie zawierające cały kontekst. Był to najłatwiejszy obszar do rozpoczęcia, ponieważ sukces można mierzyć za pomocą MTTR.

To skłoniło nas do zbudowania silnika RCA na bazie naszej warstwy obserwowalności.

Jak systemy oparte na sztucznej inteligencji radzą sobie ze złożonością w rzeczywistych przypadkach

Zbudowaliśmy silnik RCA, aby skrócić MTTR, ale prawdziwa zmiana polegała na przejściu od ręcznego badania do diagnozy prowadzonej przez system. Problem polegał na tym, że gdy pojawiał się błąd, logi były rozproszone między usługami, inżynierowie musieli ręcznie odtwarzać przebieg zdarzeń, a analiza przyczyn źródłowych w dużej mierze zależała od indywidualnego doświadczenia. Nawet w przypadku znanych problemów MTTR był niespójny, ponieważ proces nie był powtarzalny.

W odpowiedzi zbudowaliśmy silnik RCA, który działa na bazie naszej warstwy obserwowalności i automatycznie wykonuje trzy zadania:

Łączenie kontekstu

• Pobiera logi, metryki i ślady wykonania z różnych usług
• Odtwarza dokładną ścieżkę wystąpienia błędu (krok po kroku w ramach partii lub przepływu)

Dopasowywanie wzorców + wykrywanie podobieństw

• Porównuje problem z historycznymi incydentami
• Wykorzystuje reprezentacje wektorowe do identyfikowania podobnych incydentów, które miały miejsce wcześniej

Wspomagana przez AI sugestia przyczyny źródłowej

• Klasyfikuje problem (problem z danymi, problem z konfiguracją, regresja w kodzie, infrastruktura)
• Sugeruje najbardziej prawdopodobną przyczynę źródłową
• Przedstawia dowody potwierdzające, a nie tylko odpowiedź

Dlaczego wpływ AI zależy od jakości systemu

Początkowo zakładaliśmy, że warstwa LLM bezpośrednio poprawi rezultaty. Tak się nie stało. Pierwsze wersje były rozczarowujące. Szybko zrozumieliśmy, że AI nie naprawia nieuporządkowanych systemów. Wzmacnia ich problemy. Nauczyliśmy się również, że jakość danych ma większe znaczenie niż jakość modelu.

Poświęciliśmy dużo czasu na naprawianie niespójnych logów, brakującego kontekstu między usługami i nieprecyzyjnie zdefiniowanych sygnałów. Gdy dane bazowe stały się uporządkowane i wiarygodne, dobrze działały nawet proste konfiguracje AI.

Zaufanie jest równie ważne jak dokładność. Nawet gdy silnik RCA lub system selekcji zgłoszeń okazywał się technicznie poprawny, inżynierowie z niego nie korzystali. Dlaczego? Ponieważ nie wyjaśniał swojego działania.

Początkowo zakładaliśmy, że warstwa LLM bezpośrednio poprawi rezultaty. Tak się nie stało. AI nie naprawia nieuporządkowanych systemów. Wzmacnia ich problemy. Jakość danych ma większe znaczenie niż jakość modelu.

Share This Quote on:

• Share on Twitter
• Share on LinkedIn
• Share on Facebook

Saloni MalhotraOpens new window

Starszy menedżer produktu, zespół R&D w o9 Solutions

Ludzie nie potrzebują idealnej AI. Potrzebują zrozumiałej AI. Prawdziwa korzyść nie polega na szybkości — chodzi o koncentrację. Myśleliśmy, że AI po prostu sprawi, że będziemy szybsi. Jednak inżynierowie nie tylko szybciej zamykali zgłoszenia. Zaczęli pytać: „Dlaczego ta klasa problemów w ogóle istnieje?”. To zupełnie inny poziom myślenia. Wąskie i konkretne rozwiązania są lepsze niż ambitne i szerokie. Początkowo chcieliśmy zbudować szeroki, inteligentny system. To się nie udało. Wdrażanie AI nie było wielkim przełomem. Było serią małych, precyzyjnych sukcesów.

Zauważyliśmy zmianę dopiero wtedy, gdy dołączaliśmy dowody (logi, ślady, porównania) i pokazywaliśmy, dlaczego system doszedł do konkretnego wniosku. W rezultacie spędzaliśmy mniej czasu na powtarzalnym badaniu, a więcej na usprawnieniach na poziomie systemu. Następnie osiągnęliśmy sukces, wybierając konkretne przypadki użycia (takie jak RCA w przypadku awarii partii), rozwiązując je dogłębnie i stopniowo rozszerzając zakres.

Jak narzędzia AI zwiększają efektywność realizacji projektów

Oto nasz stos technologiczny.

Warstwa AI i inteligencji:

• LLM (modele klasy GPT) — RCA, podsumowywanie, klasyfikacja
• Reprezentacje wektorowe + wektorowa baza danych (FAISS / Pinecone) — wyszukiwanie podobieństw, pobieranie informacji o incydentach
• Potoki RAG — ugruntowywanie wyników AI za pomocą logów i danych historycznych
• Wykrywanie anomalii (reguły + ML) — wykrywanie wzorców awarii

Obserwowalność i dane:

• Rejestrowanie i monitorowanie (Elastic / Datadog / OpenTelemetry)
• Systemy śledzenia rozproszonego
• Potoki danych (Python, przetwarzanie strumieniowe/wsadowe)
• Warstwy przechowywania danych telemetrycznych i inżynierii cech

Dostarczanie i przepływ pracy:

• CI/CD (GitHub Actions / Jenkins)
• Śledzenie zgłoszeń (Jira lub podobne narzędzie)
• Struktury walidacji wydań / symulacji

Produktywność deweloperów:

• Asystenci programowania (GitHub Copilot lub podobne narzędzie)
• Wewnętrzni asystenci AI do debugowania i wysyłania zapytań do systemów

Ogólnie ewolucja w ciągu ostatnich 6–12 miesięcy wyglądała następująco:

• Od pulpitów nawigacyjnych → do wniosków wspomaganych przez AI
• Od ręcznej kategoryzacji zgłoszeń → do zautomatyzowanej analizy przyczyn źródłowych
• Od odizolowanych narzędzi → do połączonych potoków
• Od reaktywnego debugowania → do proaktywnego wykrywania

Jak Claude i Figma zwiększają produktywność zespołu

Połączenie Claude z Figmą okazało się dla nas zaskakująco skuteczne. Wcześniej korzystaliśmy z procesu, który wyglądał tak: kierownik produktu przygotowywał PRD, projektant go interpretował, a następnie odbywało się wiele rund uzgodnień.

Teraz przekazujemy do Claude’a ogólne pomysły, przepływy, a nawet nieuporządkowane notatki i prosimy go o uporządkowanie przepływów, zaproponowanie przypadków brzegowych oraz przygotowanie koncepcji na poziomie ekranów.

Następnie bezpośrednio przenosimy to do Figmy, gdzie znacznie szybciej tworzymy makiety, sprawnie analizujemy różne warianty oraz opracowujemy mikroteksty i stany.

Dlaczego lekkie systemy zastępują tradycyjne zarządzanie projektami

Tradycyjne systemy działały, ale powoli dostosowywały się do zmian, wiązały się z wysokim narzutem koordynacyjnym i często były oderwane od tego, co działo się w systemie. Tak wyglądało „tradycyjne” podejście: szczegółowe PRD przygotowywane z wyprzedzeniem (często nieaktualne już po kilku tygodniach), ustalone plany sprintów ze sztywnym zakresem, ręczne śledzenie statusu (codzienne spotkania, raporty, pulpity nawigacyjne), a także oddzielne narzędzia do planowania, realizacji i monitorowania.

Teraz odeszliśmy od rozbudowanych PRD na rzecz modułowych specyfikacji i aktualnego kontekstu. Dzięki temu nowemu podejściu możemy podzielić pracę na: definicję problemu, kluczowe przepływy i ograniczenia. Możemy również przechowywać je w lekkich formatach (dokumenty + zgłoszenia) oraz używać modeli LLM do rozwijania przypadków brzegowych i generowania scenariuszy testowych.

Obecnie poświęcamy znacznie mniej czasu na pisanie wyczerpujących dokumentów (PRD liczących 10–15 stron w Confluence). Zamiast tego mamy jednostronicowy, uporządkowany opis zawierający problem, przepływ użytkownika i ograniczenia.

Aby to osiągnąć, korzystaliśmy z następujących narzędzi:

• Confluence (ograniczone wykorzystanie)
• Jira (główne źródło prawdy)
• Warstwa LLM (modele klasy GPT za pośrednictwem API)
• Figma
• Claude (do porządkowania przepływów)

Oto nasz proces:

• Jednostronicowy, uporządkowany opis:
  • Problem
  • Przepływ użytkownika
  • Ograniczenia
• Przekazujemy go do Claude’a / LLM, aby:
  • Rozwinąć przepływy
  • Wygenerować przypadki brzegowe
  • Przygotować kryteria akceptacji
• Bezpośrednio przekształcamy go w zgłoszenia Jira i makiety w Figmie

Wpływ wygląda następująco:

• Około 40–50% mniej czasu od pomysłu → do pierwszej wersji
• Mniej rund uzgodnień między kierownikiem produktu, zespołem projektowym i zespołem inżynieryjnym
• Znacznie klarowniejsza pierwsza wersja funkcji

Jak integracja AI zmienia rytuały dostarczania

Ponadto definiowanie zakresu zmieniło się z wyczerpującego na kierunkowe. Wcześniej staraliśmy się zdefiniować wszystko z wyprzedzeniem i uwzględnić wszystkie przypadki brzegowe w PRD. Teraz definiujemy problem, kluczowe przepływy i ograniczenia. Następnie wykorzystujemy AI do rozszerzania przypadków brzegowych, symulowania scenariuszy i wskazywania luk. Zakres nie polega już na kompletności od pierwszego dnia, lecz na wyznaczeniu wyraźnego kierunku i umożliwieniu szybkiej pętli udoskonalania.

Za pięć lat plany nie będą już „pisane” — będą stale generowane. Myślę, że plany będą żywymi systemami, a nie dokumentami. AI będzie stale aktualizować priorytety, ryzyka i harmonogramy na podstawie realizacji w czasie rzeczywistym, sygnałów od klientów i stanu systemu. Planowanie będzie dynamiczne i zawsze aktualne, a nie okresowe.

Saloni dzieli się

AI działa najlepiej, gdy usuwa rzeczywisty, codzienny problem, a nie gdy jest dodawana jako kolejna warstwa.

Dlaczego wyeliminowanie tarć jest kluczowe przed wdrożeniem AI

Nie zaczynaj od AI. Zacznij od problemów.

Można ulec pokusie, by zapytać: „Gdzie możemy wykorzystać AI?”. Zwykle jest to niewłaściwy punkt wyjścia. Zamiast tego zapytaj: Gdzie zespoły wielokrotnie tracą czas? Gdzie praca jest zbyt zależna od kilku osób? Gdzie wszystko zwalnia pod presją? Wybierz jeden z tych obszarów i rozwiąż problem dogłębnie.

AI działa najlepiej, gdy usuwa rzeczywisty, codzienny problem, a nie gdy jest dodawana jako kolejna warstwa.

Bądź na bieżąco

Możesz śledzić pracę Saloni na LinkedInie.

Więcej wywiadów z ekspertami już wkrótce na stronie The Digital Project Manager!