Sala IT #1 (piętro -1)

Abstrakt:

Porozmawiamy o wyzwaniach, możliwościach współpracy z sektorem IT oraz o tym, dlaczego właśnie dziś warto bliżej przyjrzeć się rynkowi AgriTech.

Opis: 
Rolnictwo i nowe technologie coraz częściej spotykają się na wspólnym polu. Cyfryzacja procesów, analiza danych, automatyzacja, sztuczna inteligencja czy nowoczesne kanały sprzedaży zmieniają sposób funkcjonowania gospodarstw rolnych i producentów żywności. AgriTech staje się jednym z najbardziej perspektywicznych sektorów dla innowacji, a jego potencjał wciąż pozostaje niedoceniony przez branżę IT. Podczas firechatu porozmawiamy z przedsiębiorcami, którzy od lat rozwijają nowoczesne gospodarstwa i marki oparte na produkcji rolnej.
To historie pokazujące, jak tradycyjne gospodarstwa mogą przekształcać się w nowoczesne, innowacyjne przedsiębiorstwa, budujące własne marki, rozwijające sprzedaż bezpośrednią i wykorzystujące technologię jako przewagę konkurencyjną.

Abstrakt:

Opis:

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.

Abstrakt:

Historia dwukrotnej sprzedaży firmy IT przed 45-tka. Co się sprawdziło, czego się nauczył i dlaczego wczesna emerytura wygląda inaczej niż w marzeniach.

Opis:

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ę.

Abstrakt:

Jak zmienić proces zarządzania danymi testowymi stosując podejście „Data as Code”.

Opis:

Zarządzanie danymi testowymi (Test Data Management) to jeden z największych, a jednocześnie najczęściej pomijanych problemów w nowoczesnych organizacjach IT. Ręczne procesy, ryzyko compliance, wysokie koszty infrastruktury i trudności z utrzymaniem spójności danych to wyzwania, z którymi na co dzień mierzą się zespoły QA i DevOps. Celem prezentacji jest pokazanie, jak skutecznie odpowiedzieć na te problemy przy pomocy podejścia Data as Code. Uczestnicy poznają nowoczesne podejście do TDM oraz możliwości implementacji od generatorów danych w repozytorium po wykorzystanie GenAI oraz rozwiązań komercyjnych. Prezentacja przybliży wymierne korzyści płynące z nowoczesnego TDM – od skrócenia czasu dostarczania danych testowych, przez obniżenie kosztów infrastruktury, aż po poprawę jakości i pokrycia testami.

Abstrakt:

Konflikty między biznesem a IT rzadko wynikają ze złej woli – znacznie częściej są efektem utraty zaufania, kontroli i wspólnego zrozumienia celu. Prelekcja dotyczy źródeł tych napięć oraz sposobów zapobiegania i wychodzenia z kryzysów na linii biznes–IT.

Opis:

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.

Abstrakt:

Rola inżyniera ewoluuje z pisania kodu na podejmowanie decyzji. O spójności architektury, szybkiej walidacji outputu AI i mentalności redaktora vs autora.

Opis:

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.