Sala IT #1 (piętro -1)

Zmigrowaliście się na mikroserwisy… i nagle zaczyna się jazda: sieć się wysypuje, zegary się rozjeżdżają, wiadomości docierają w innej kolejności niż powinny, dane przestają być spójne, a Ty próbujesz po prostu dowozić.

Prezentacja dotyczy fundamentalnych, nieusuwalnych problemów systemów rozproszonych – takich, które nie wynikają z „błędnej implementacji”, tylko z samej natury zawodnych sieci i wielu niezależnych węzłów.

Prezentacja skierowana jest do wszystkich, którzy chcą lepiej zrozumieć wyzwania systemów rozproszonych, w tym do osób nietechnicznych.

Jeszcze jako student zaczynający swoją zawodową karierę IT w ubiegłym tysiącleciu, razem z kolegami snuliśmy plany, że trzeba się dorobić do czterdziestki, gdyż potem będziemy niewiele już warci na szybko zmieniającym się rynku IT. A najlepiej było dorobić się oczywiście na zbudowaniu własnej firmy. Nie sprzedałem firmy przed 40-stką, natomiast zrobiłem to dwukrotnie przed 45-tką. I w sumie dobrze, że później.
Opowiem Ci swoją historię zbudowania i sprzedaży firm, czego się z tego nauczyłem i jak diametralnie zmieniło się moje pierwotne postrzeganie wymarzonej wczesnej emerytury software developera. Myślę, że pomoże to ukształtować Wasz punkt widzenia na sprzedaż biznesu czy wczesne przejście na emeryturę.

Biznes „znowu zmienił zdanie”. Naciska. Dopytuje o szczegóły. Wchodzi w rozwiązania. Przerywa sprint. Zawraca głowę. Organizuje bezsensowne spotkania. Każe wypełniać raporty. Rozlicza godziny. Dorzuca managerów.

Znacie to?

Dla IT – chaos.
Dla biznesu – próba odzyskania kontroli.

Podzielę się historiami, w których biznes „przeszkadzał” zespołom IT.

Lecz zamiast narzekać na „zły biznes”, porozmawiamy o tym, jak takim sytuacjom zapobiegać, oraz jak sobie poradzić, gdy już się w nich znajdziemy.

Jeśli jesteś z IT – zabierz osobę, która Cię rozlicza z efektów. To będzie bardzo pouczające doświadczenie.
Jeśli jesteś z biznesu – przyprowadź kogoś, kto dowozi Twój produkt. Zobaczycie, że nie wszystko jest takie czarno-białe.

Prezentacja jest oparta na ponad dekadzie doświadczeń z ratowania, wspierania i przejmowania projektów IT tam, gdzie inni zawiedli. Podzielę się z Wami naszymi sprawdzonymi metodami na zapobieganie i wychodzenie z kryzysowych konfliktów na linii biznes vs IT.

Pamiętacie czasy, gdy wytwarzanie softu przypominało wielką linię montażową? Analitycy biznesowi, systemowi, projektanci, architekci, a na końcu programiści – każdy w swojej silosowej wieży. Agile spłaszczył tę strukturę do trio architekt + developer + qa, a dalsza ewolucja dzieje się na naszych oczach właśnie teraz. W dobie LLM-ów rola inżyniera ewoluuje w stronę „Architect of Intents”. Dziś wąskim gardłem nie jest już szybkość pisania kodu, ale szybkość i trafność podejmowanych decyzji.

Podczas sesji przeanalizujemy trzy krytyczne filary tej zmiany:
– Spójność strukturalna kontra „Kod Frankensteina”: Kiedyś opór materii przy ręcznym pisaniu kodu wymuszał porządek. Dziś AI potrafi wygenerować tysiące linii w sekundy. Jak uniknąć stworzenia niekoherentnej hybrydy sprzecznych wzorców i utrzymać integralność architektury, gdy system rozrasta się w niespotykanym tempie?
– Szybka walidacja (High-Velocity Validation): LLM-y bywają „pewne swych błędów”, proponując nieistniejące biblioteki lub przestarzałe wzorce. Nowoczesny inżynier musi posiadać umiejętność błyskawicznej oceny kompromisów (trade-offs), aby zatrzymać dług techniczny, zanim trafi on do repozytorium.
– Mentalność Redaktora Naczelnego (Review over Writing): Przechodzimy od roli autora do roli krytycznego recenzenta. To ogromna zmiana poznawcza: znacznie trudniej jest znaleźć błąd w kodzie, którego się nie napisało. Zamiast pytać „Jak to zbudować?”, musimy zacząć pytać „Czy to, co zbudowało AI, jest poprawne i bezpieczne?”.

To wystąpienie dla tych, którzy chcą zrozumieć, dlaczego w świecie zdominowanym przez AI, rola architekta i jego zdolność do definiowania intencji staje się ważniejsza (i trudniejsza) niż kiedykolwiek wcześniej.