Dokładny stos dostarczania AI, którego dyrektor ds. produktu używa do ograniczenia liczby poprawek o 25%
AI może generować kod w ciągu kilku sekund. Jednak bez architektury pomaga jedynie szybciej dostarczać niewłaściwe rozwiązania. W tym wywiadzie dyrektor ds. produktu i dyrektor ds. inżynierii przedstawia system AI oparty przede wszystkim na architekturze, którego używa do skrócenia czasu tworzenia prototypów o połowę, ograniczenia liczby poprawek o 25% oraz projektowania mechanizmów kontrolnych dla cyklu życia oprogramowania wspomaganego przez AI.
Yurii Lozinskyi
Dyrektor ds. produktu i dyrektor ds. inżynierii w Verysell
Przywództwo w obszarze AI: AI przekształca zarządzanie projektami z koordynacji w projektowanie systemów, ograniczając liczbę zadań ręcznych dzięki wbudowaniu AI.
Rola architektury: Solidna architektura zapobiega chaosowi w dostarczaniu rozwiązań AI, dostosowując pracę generowaną przez AI do standardów jakości i celów.
Wydajność prototypowania: AI kierowane przez architekturę obniża koszty i przyspiesza tworzenie prototypów od pomysłu do działającego modelu w ciągu kilku dni.
Wartość inżynierów: AI zwiększa wartość starszych stażem inżynierów, usprawniając projektowanie architektury i ograniczając przypadkowe programowanie.
Zmiana w zarządzaniu projektami: Przyszłe role kierowników projektów będą wykorzystywać AI do koordynacji, kładąc większy nacisk na projektowanie, strategię i nadzór.
Yurii Lozinskyi jest dyrektorem ds. produktu i dyrektorem ds. inżynierii w Verysell AI, gdzie kieruje realizacją projektów AI. Ma 25 lat doświadczenia, a przekształcanie inicjatyw związanych z oprogramowaniem i AI w wymierne rezultaty biznesowe to jego codzienność.
Usiedliśmy więc z nim, aby dowiedzieć się, jak to robi. Oto, co nam powiedział.
Dbanie o to, by AI nie było tylko efektowną zabawką
Jestem liderem ds. produktu i inżynierii, który działa na styku systemów AI, dostarczania oprogramowania i realiów biznesowych. Od ponad 15 lat tworzę i wdrażam rozwiązania w bankowości, ubezpieczeniach, na platformach ITSM/MSP, w handlu detalicznym i ochronie zdrowia. I jakoś wciąż wracam do ubezpieczeń, ponieważ właśnie tam zarówno złożoność, jak i wpływ są bardzo duże.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Obecnie nie prowadzę projektów w tradycyjnym sensie. Projektuję sposób, w jaki powinny być prowadzone, i staram się aktywnie uczestniczyć w ich realizacji. Oznacza to modele operacyjne, wzorce realizacji oparte na AI oraz plany działania oparte na weryfikacji hipotez, stosowane w wielu zespołach i u wielu klientów.
W skrócie, moja codzienna praca polega na dbaniu o to, aby AI nie było efektowną zabawką na marginesie, lecz częścią sposobu definiowania, realizacji i zarządzania pracą od początku do końca.
Jak AI zmienia zarządzanie projektami — od koordynacji do projektowania systemów
Przywództwo w obszarze realizacji projektów przechodzi od zarządzania kalendarzem do projektowania systemów. Spędzam znacznie mniej czasu na spotkaniach statusowych lub ręcznym tworzeniu artefaktów, które maszyny generują teraz w kilka sekund. Jeśli AI może pomóc mi napisać pierwszą wersję planu lub podsumowania, chętnie mu na to pozwalam.
Wielu kierowników projektów nadal poświęca dziś 40–60% czasu na monitowanie statusów, ręczne raportowanie, identyfikowanie podstawowych zagrożeń oraz przenoszenie informacji między narzędziami i osobami. W środowisku wspomaganym przez AI odsetek ten spada poniżej 10–15%, ponieważ wbudowani agenci obsługują aktualizacje, podsumowania, przypomnienia i proste eskalacje w Jira/Linear, Slack/Teams oraz dokumentach.
Ceną za to jest przesunięcie mojej pracy o poziom wyżej: koncentruję się na ograniczeniach, kryteriach akceptacji, mechanizmach ochronnych i pętlach informacji zwrotnej. Innymi słowy, projektuję „tory”, po których poruszają się ludzie i agenci AI.
Jestem zwolennikiem podejścia opartego na architekturze: używam modelu C4 i normy ISO/IEC 25010 jako podstawy dokumentów wizji architektury, a następnie wykorzystuję je jako prompty. To właśnie jest interesująca część — traktowanie architektury jako interfejsu API dla AI. Dokumentacja architektury nie jest materiałem odkładanym na półkę, lecz paliwem dla cyklu życia wytwarzania oprogramowania opartym na AI (SDLC). Więcej na ten temat za chwilę.
AI sprawia, że niezwykle łatwo jest działać szybko, dlatego moją rolą jest dopilnowanie, abyśmy działali szybko we właściwym kierunku. Zamiast więc pytać: „Kto co robi w tym tygodniu?”, pytam: „Czy nasz system utrudnia szybkie dostarczenie niewłaściwego rozwiązania?”
AI sprawia, że niezwykle łatwo jest działać szybko, dlatego moją rolą jest dopilnowanie, abyśmy działali szybko we właściwym kierunku.
Dlaczego architektura zapobiega chaosowi w realizacji projektów wywołanemu przez AI
Lubię C4, ISO 25010 i dokumenty wizji architektury, ponieważ tworzą one podstawę integracji AI z realizacją projektów. Bez tej podstawy AI może szybko stać się kolejnym źródłem chaosu w procesie dostarczania.
W szczególności:
- C4 daje AI mapę systemu. Zamiast mówić: „Po prostu napisz jakiś kod”, możemy powiedzieć: „W tym kontekście i kontenerze, z wykorzystaniem tych interfejsów, zaimplementuj tę zmianę”. Dzięki temu praca wygenerowana przez AI pozostaje w jasno określonych granicach architektury.
- ISO 25010 definiuje „dobrze” szerzej niż „kompiluje się”. Przekładamy jego atrybuty jakości na konkretne scenariusze — wydajność, bezpieczeństwo, łatwość utrzymania i niezawodność — a następnie uwzględniamy je w promptach i kryteriach akceptacji. AI generuje wtedy weryfikacje koncepcji i testy zgodne z jasno określonymi oczekiwaniami dotyczącymi jakości, a nie tylko z funkcjonalnością.
- Dokumenty wizji architektury integrują wszystko. Łączą cele biznesowe, widoki C4 i scenariusze jakości w stylu ISO w jedną narrację przeznaczoną zarówno dla ludzi, jak i AI. Dla ludzi stanowią artefakt zapewniający zgodność. Dla AI są głównym źródłem kontekstu do generowania kodu, testów i dokumentacji.
Razem przekształcają AI z przypadkowej supermocy w kontrolowany element cyklu życia wytwarzania oprogramowania opartego na AI, z jasno określonymi granicami, identyfikowalnością i wspólnym rozumieniem tego, co chcemy zbudować.
Jak ograniczyć koszt popełniania błędów dzięki prototypom AI kierowanym przez architekturę
Oto przykład. Mieliśmy funkcję dopasowywania opartą na AI, której w „starym świecie” przejście od pomysłu do klikalnego prototypu zajęłoby około dwóch tygodni.
Zamiast zaczynać od zadań w Jira i doraźnych promptów, najpierw napisaliśmy krótki dokument wizji architektury. Narysowaliśmy diagramy w stylu C4: kontekst systemu, zaangażowane kontenery, kluczowe komponenty oraz kilka scenariuszy jakości inspirowanych normą ISO 25010 (np. dotyczących opóźnień, audytowalności i obsługi błędów).
Następnie potraktowaliśmy tę architekturę jak interfejs API dla AI:
- Przekazaliśmy dokument wizji i fragmenty C4 naszemu asystentowi programistycznemu jako jedyne źródło prawdy dla promptów.
- Poprosiliśmy go o wygenerowanie szkieletu, logiki głównego przepływu i testów pierwszej wersji w ramach określonych kontenerów i interfejsów.
Nie prosisz AI: „Napisz mi jakiś kod”, lecz: „Zaimplementuj tę konkretną interakcję z uwzględnieniem tych ograniczeń i tych atrybutów jakości”. To zupełnie inna gra. Dzięki temu w ciągu kilku dni powstał spójny PoC, zamiast ręcznego kodowania wszystkiego od zera.
Inżynierowie nadal sprawdzali i poprawiali poszczególne elementy, ale:
- Czas od „powinniśmy tego spróbować” do „interesariusze mogą przeklikać działający prototyp” skrócił się z około dziesięciu dni roboczych do trzech lub czterech. To niemal niesprawiedliwe, jak szybko można stworzyć wiarygodny prototyp, gdy architektura nadaje kierunek promptom zamiast opierać je na niejasnych życzeniach.
- Zaobserwowaliśmy o 20–25% mniej cykli poprawek, ponieważ kod wygenerowany przez AI już respektował granice i wzorce zapisane w architekturze.
- Inżynierowie zgłaszali, że poświęcają około 20% mniej czasu na kod szablonowy i kod integracyjny, co w praktyce wyeliminowało odrębną rolę „inżyniera integracji”.
- Pokrycie testami dla tego fragmentu było wyższe już za pierwszym podejściem, ponieważ asystent wykorzystał udokumentowane scenariusze jakości do zasugerowania testów przypadków brzegowych, których prawdopodobnie nie napisalibyśmy tak wcześnie.
Innymi słowy, gdy tylko uczyniliśmy architekturę jawną i ustrukturyzowaną, AI przestało zachowywać się jak sprytne autouzupełnianie, a zaczęło działać bardziej jak młodszy inżynier, który naprawdę rozumie mapę systemu, tworzy świetną dokumentację i nigdy nie śpi.
Co najważniejsze, ograniczyło to koszt popełniania błędów, czyli dokładnie to, czego potrzebujesz w złożonych domenach.
Dlaczego AI zwiększa wartość starszych inżynierów, zamiast ją zmniejszać
Wbrew temu, co możesz sądzić, AI zwiększa wartość starszych inżynierów, zamiast ją zmniejszać.
Jeśli podłączysz AI do słabej architektury i oprzesz je na słabym osądzie, otrzymasz szybszy bałagan. Powierz je dobremu architektowi, a nagle jeden starszy inżynier może przeanalizować pięć projektów przed lunchem i nadal mieć czas na rozmowę z interesariuszami.
AI niweluje niektóre luki w umiejętnościach, ale pogłębia różnicę między przypadkowym kodowaniem a celowym projektowaniem.
Jeśli podłączysz AI do słabej architektury i oprzesz je na słabym osądzie, otrzymasz szybszy bałagan. Powierz je dobremu architektowi, a nagle jeden starszy inżynier może przeanalizować pięć projektów przed lunchem i nadal mieć czas na rozmowę z interesariuszami.
Żegnaj, analityku biznesowy — witaj, ekspercie dziedzinowym.
Które zadania związane z realizacją należy najpierw zautomatyzować za pomocą AI
Obecnie najbardziej gotowe do automatyzacji są te elementy pracy związanej z realizacją, które są „bogate w kontekst, oparte na wzorcach i pozbawione ego”:
- Jak wspomniano, generowanie kodu PoC i testów na podstawie dokumentów wizji architektury oraz specyfikacji C4/ISO 25010
- Tworzenie dzienników decyzji, opcji projektowych i list ryzyk
- Przekształcanie chaotycznych wątków na Slacku w coś, co Twoje przyszłe ja może przeczytać bez płaczu
AI świetnie radzi sobie z sugestiami, ale fatalnie z braniem odpowiedzialności. To obszary, za które ludzie nadal całkowicie odpowiadają:
- Zdefiniowanie problemu
- Wybór między ryzykiem a szybkością
- Uwzględnianie ograniczeń regulacyjnych i etycznych
- Decydowanie, kiedy coś „technicznie poprawnego” nadal jest niewłaściwą rzeczą do wdrożenia
Obecnie najlepsze efekty daje skracanie wczesnych pętli odkrywania i projektowania. Agenci dobrze radzą sobie z przekształcaniem spójnej specyfikacji w prawdopodobne ścieżki. Nadal jednak nie rozumieją, kiedy dana ścieżka jest politycznie, etycznie lub strategicznie niewłaściwa, dlatego ludzie wciąż zdecydowanie sprawują kontrolę.
Dlaczego kierownicy projektów powinni przedkładać pętle informacji zwrotnej nad formalności
Tradycyjne zarządzanie projektami często obejmuje wiele rytuałów bez jasno określonego celu. Odchodzę od tego na rzecz systemów, które przedkładają informacje zwrotne nad formalności.
W praktyce oznacza to:
- Mniej monolitycznych planów, więcej małych, możliwych do przetestowania hipotez
- Mniej długich spotkań statusowych, więcej asynchronicznych aktualizacji automatycznie podsumowywanych przez AI
- Mniej rozdętych dokumentów wymagań, więcej żywych dokumentów wizji architektury, na podstawie których mogą działać zarówno ludzie, jak i AI
Nadal dbamy o terminy, budżety i ryzyka. Pozwalamy jednak AI zajmować się prowadzeniem ewidencji, aby ludzie mogli skupić się na projektowaniu, podejmowaniu decyzji i rzeczywistości interesariuszy.
Ironia polega na tym, że gdy usuniesz połowę rytuałów, ludzie bardziej szanują pozostałą strukturę.
Ironia polega na tym, że gdy usuniesz połowę rytuałów, ludzie bardziej szanują pozostałą strukturę.
Jak integracje AI usprawniają dostarczanie projektów w GitHubie i CI/CD
Z technicznego punktu widzenia „odchudzenie” oznaczało bezpośrednie podłączenie AI do repozytorium i środowisk, a nie tylko dodanie kolejnego pulpitu nawigacyjnego.
Konkretnie zintegrowaliśmy asystenta programistycznego AI o nazwie Codex z naszymi repozytoriami GitHub i potokiem CI/CD. Inżynierowie pracują w swoim zwykłym środowisku IDE, ale asystent widzi strukturę repozytorium i może zrobić wszystko, o czym wspomniałem powyżej, na podstawie diagramów architektury w stylu C4 oraz dokumentu wizji architektury. Przy koszcie wynoszącym około $20 USD na inżyniera miesięcznie jest to tańsze niż niemal jakakolwiek inna dźwignia produktywności, którą można wykorzystać.
Dodatkowo korzystamy z prostej automatyzacji wdrażania (potoków opartych na GitHubie), dzięki czemu możemy jednym kliknięciem wdrażać zmiany wspomagane przez AI do dedykowanego środowiska prototypowego.
Nawet generowanie poleceń jest częściowo zautomatyzowane: nowoczesny model klasy GPT (GPT-5.2) może generować uporządkowane polecenia dla narzędzi takich jak Eraser na podstawie naszych dokumentów wizji architektury.
Kluczowe jest to, że wszystko to działa w ramach standardowych zabezpieczeń: inżynierowie nadal sprawdzają każdy wniosek o scalenie zmian, CI/CD nadal jest uruchamiane, a do produkcji nie trafia nic bez zgody człowieka. AI przyspiesza nudne elementy pracy, ale ludzie pozostają odpowiedzialni za projekt, ryzyko i ostateczną decyzję.
Dlaczego prototypy AI na nowo definiują rytuały dostarczania
Wszystko to miało duży wpływ na nasze rytuały związane z dostarczaniem.
Definiowanie zakresu wyglądało kiedyś tak: „Porozmawiajmy przez kilka godzin, a potem napiszmy dokument, który wszyscy zignorujemy”. Teraz brzmi to: „Szybko przygotujmy prototyp i spierajmy się, korzystając z czegoś interaktywnego”.
Zaczynamy od rezultatu na wysokim poziomie, zapisujemy go w dokumencie wizji architektury, szkicujemy widoki C4, a następnie używamy AI do wygenerowania PoC lub przynajmniej realistycznej makiety. Nagle każdy ma opinię — ponieważ istnieje coś namacalnego, na co można zareagować.
Innymi słowy, osiągamy zgodność co do zachowania, a nie punktów na liście.
Przeprowadzamy walidację, łącząc testy wygenerowane przez AI (świetne pod kątem pokrycia i regresji) ze scenariuszami zaprojektowanymi przez ludzi (świetne pod kątem osądu i nietypowych przypadków brzegowych).
Przenosimy zarządzanie realizacją z „przydzielania zadań” na „projektowanie przepływów”: kto lub co powinno zobaczyć ten element pracy jako następne i w jakim kontekście?
Jak wygląda prosty zestaw narzędzi do realizacji projektów AI
Mój zestaw narzędzi jest oparty na konkretnych założeniach, ale prosty.
Do architektury i uzgadniania wykorzystuję diagramy w stylu C4 oraz dokumenty wizji architektury, tworzone w narzędziach takich jak Eraser. Dzięki temu można je łatwo iterować z udziałem ludzi, a następnie przekazywać do AI.
W przypadku specyfikacji preferuję dokumenty oparte przede wszystkim na tekście, które opisują intencje, ograniczenia i atrybuty jakości w sposób zrozumiały dla LLM.
Po stronie inżynieryjnej korzystam z nowoczesnych IDE z rozbudowanym wsparciem AI oraz z narzędzi takich jak Claude Code i Codex do generowania implementacji PoC i testów bezpośrednio na podstawie tych artefaktów architektury. Celowo nie powierzyłem AI tworzenia kompletnych funkcji produkcyjnych. AI przygotowuje szkice, tworzy podstawową strukturę i przedstawia propozycje. Inżynierowie — prawdziwi — nadal decydują o tym, co trafia na produkcję.
Co ważne, każde z tych narzędzi przestało być odizolowaną wyspą. Są teraz połączone w ramach SDLC wspieranego przez AI: wymagania, architektura, programowanie, testowanie, a nawet zarządzanie mają warstwę wspomagającą.
W praktyce oczekuję, że ta zmiana odblokuje wzrost produktywności na poziomie około 18-25% w całym procesie realizacji. Trzeba jednak jasno powiedzieć, że liczba ta w dużym stopniu zależy od punktu wyjścia organizacji — jej dojrzałości, istniejących procesów i dyscypliny architektonicznej.
Jak selektywne wdrażanie narzędzi usprawnia realizację projektów AI
W ciągu ostatniego roku zaczęliśmy celowo wymieniać narzędzia i prowadzić projekty pilotażowe, zamiast próbować „włączyć AI” wszędzie naraz.
Po stronie realizacji wdrożyliśmy Miro do tworzenia prostych map drogowych i prowadzenia warsztatów architektonicznych, ale tylko pilotażowo w kilku małych projektach. Chcieliśmy ocenić, na ile tablice Miro w połączeniu z podsumowaniami generowanymi przez AI mogą zastąpić długie prezentacje i ręcznie tworzone dokumenty uzgodnieniowe. Pierwsze sygnały są dobre, ale zanim podejście stanie się standardem, musimy jeszcze je sfinalizować i wdrożyć na większą skalę.
W przypadku dokumentacji i specyfikacji zachowaliśmy narzędzie do dokumentacji oparte przede wszystkim na tekście, służące do tworzenia dokumentów wizji architektury. Dodaliśmy do niego wsparcie AI w postaci bardzo lekkich, niestandardowych GPT — po cichu wycofując duże, statyczne dokumenty specyfikacji, których nie utrzymywaliśmy i które nie przekładały się dobrze na prompty.
Wspominałem o tym powyżej, ale po stronie inżynieryjnej dodaliśmy Codex jako asystenta programowania AI zintegrowanego z naszym repozytorium Git i potokiem CI, aby tworzyć podstawową strukturę PoC i generować testy, zachowując jednocześnie dotychczasowe IDE oraz narzędzia wdrożeniowe. Innymi słowy, nie usuwamy jeszcze obecnego zestawu narzędzi. Nakładamy na niego AI tam, gdzie wyraźnie oszczędza czas, najpierw robiąc to w ramach kontrolowanych projektów pilotażowych, zanim wdrożymy cokolwiek w całej firmie.
Nie usuwamy jeszcze obecnego zestawu narzędzi. Nakładamy na niego AI tam, gdzie wyraźnie oszczędza czas, najpierw robiąc to w ramach kontrolowanych projektów pilotażowych, zanim wdrożymy cokolwiek w całej firmie.
Dokąd zmierza zarządzanie projektami w ciągu najbliższych pięciu lat
Za pięć lat „kierownik projektu” jako rola polegająca wyłącznie na koordynacji w dużej mierze zniknie z branży technologicznej. Praca nadal będzie istniała, ale wbudowani agenci AI przejmą większość koordynacji, monitorowania i raportowania w używanych narzędziach.
Ludzie wcześniej znani jako PM-owie albo awansują do roli projektujących SDLC wspierane przez AI i modele zarządzania, albo przejdą do ról związanych z produktem i strategią.
Panele wyników PM-ów odejdą od kryteriów „na czas / w ramach budżetu” w kierunku niewielkiego zestawu wskaźników systemowych, na które aktywnie wpływają: czasu realizacji zmian, odsetka defektów wykrytych po wdrożeniu, opóźnienia decyzyjnego, przepustowości eksperymentów i poziomu zaufania interesariuszy. AI zajmie się większością obliczeń. PM-owie będą odpowiadać za to, czy te liczby zmieniają się we właściwym kierunku — nie dlatego, że obsłużyli więcej zgłoszeń, ale dlatego, że zaprojektowali lepsze sposoby pracy.
PM-owie, którzy pozostaną przy „pilnowaniu statusów”, zostaną po cichu zastąpieni przez boty, które robią to przez całą dobę i nie mają problemu z aktualizowaniem sześciu paneli jednocześnie.
Dlaczego kierownicy projektów powinni traktować AI jak członka zespołu, a nie temat do nauki
Moja rada: przestań próbować „uczyć się AI”, jakby było nową platformą, i zacznij traktować je jak nowy rodzaj członka zespołu o konkretnych mocnych stronach i ograniczeniach. Żartobliwie nazywamy naszego „gptBuddy”.
Wybierz jeden przepływ pracy, jeden zespół i jeden istotny miernik, a następnie przeprowadź bezkompromisowy eksperyment. Jeśli nie zauważysz znaczącej poprawy, zmień konfigurację albo przerwij.
Prawdziwa wartość AI z zewnątrz wygląda nudno. Nie chodzi o rzeczy rodem z fantastyki naukowej, których ludzie się spodziewają. Chodzi o mało efektowne, kumulujące się korzyści: generowanie testów, porządkowanie dokumentacji, tworzenie szkieletu, badanie wariantów i tak dalej.
Jednocześnie oderwij wzrok od narzędzi i nakreśl, jak wyglądałby cykl życia oprogramowania wspierany przez AI w twojej organizacji. Jeśli tego nie zrobisz, ktoś inny zrobi to za ciebie — a jego zespoły będą działać szybciej, z mniejszą liczbą spotkań i mniejszą liczbą niepotrzebnych problemów.
Przestań próbować „uczyć się AI”, jakby było nową platformą, i zacznij traktować je jak nowy rodzaj członka zespołu o konkretnych mocnych stronach i ograniczeniach.
Śledź dalsze informacje
Możesz obserwować Yuriego Lozinskyiego na LinkedIn i Dev.to, gdzie dzieli się swoją wiedzą techniczną na temat AI, inżynierii, produktu i realizacji projektów. Zajrzyj również do Verysell AI.
Na The Digital Project Manager pojawią się kolejne wywiady z ekspertami!
