Porównania i wybór: najważniejsze fakty i kolejny krok

W projektach łączących sztukę i technologię równie istotne jak kod są sposób opowiedzenia o dziele, doświadczenie odbiorcy, kontekst instytucji kultury oraz realna możliwość dalszego rozwijania prototypu. Zespół może stworzyć efektowną aplikację w 24–48 godzin, ale bez dostępu do danych, mentora i jasno opisanych praw autorskich nawet najlepszy pomysł często pozostaje tylko prezentacją finałową.

To dlatego wybór hackathonu, konkursu albo gotowego projektu warto zacząć nie od wysokości nagrody czy atrakcyjnej nazwy organizatora. Najpierw trzeba sprawdzić, czy wydarzenie daje uczestnikom warunki do pracy nad rzeczywistym problemem kultury. Dopiero później ma sens porównywanie programu, składu jury, zaplecza technicznego i ścieżki rozwoju zwycięskich rozwiązań.

Hackathon kreatywny zaczyna się od zespołu, nie od technologii

W klasycznym wyobrażeniu hackathonu przy jednym stole siedzą programiści, którzy w ciągu weekendu budują aplikację. W projektach dla muzeów, galerii, teatrów czy festiwali taki skład jest zbyt wąski. Kod może uruchomić prototyp, ale nie odpowie samodzielnie na pytania o interpretację dzieła, dostępność dla publiczności, język komunikacji czy sposób prezentacji treści w przestrzeni wystawienniczej.

Najlepiej działają zespoły interdyscyplinarne. Programista odpowiada za architekturę rozwiązania, artysta wnosi język wizualny i sposób myślenia o doświadczeniu, humanista pomaga osadzić projekt w kontekście kultury, a projektant doświadczeń użytkownika pilnuje, by odbiorca nie zgubił się po pierwszym ekranie. Nie oznacza to, że każda grupa musi mieć dokładnie taki sam skład. Chodzi raczej o to, by kluczowe kompetencje nie zostały pominięte.

Przy wyborze wydarzenia warto sprawdzić:

• czy organizator sam dobiera uczestników, czy oczekuje gotowych zespołów;
• czy można dołączyć do grupy bez znajomości programowania;
• czy regulamin przewiduje role artystyczne, kuratorskie, badawcze i projektowe;
• czy problem konkursowy został opisany językiem zrozumiałym również dla osób spoza branży technologicznej;
• czy instytucje kultury są obecne w procesie, czy występują wyłącznie jako dostarczyciele tematów.

To ostatnie rozróżnienie jest szczególnie ważne. Muzeum, które tylko publikuje zadanie, oferuje uczestnikom zupełnie inne warunki niż instytucja obecna na miejscu, udostępniająca materiały, konsultująca pomysły i uczestnicząca w ocenie prototypów.

Dobrym przykładem różnorodności takich inicjatyw był muzealny hackathon HackArt zorganizowany przez Muzeum Narodowe w Warszawie. Skupiał się na wykorzystaniu sztucznej inteligencji, botów i sztuki generatywnej w pracy instytucji kultury. Sam temat wymagał połączenia kompetencji technicznych z rozumieniem praktyki muzealnej. Podobnie w ramach sojuszu KreativEU uczestnicy KreativHack OUTech pracowali nad rozwiązaniami wykorzystującymi sztuczną inteligencję do ochrony dziedzictwa kulturowego. W tym przypadku w wydarzeniu uczestniczyli studenci ośmiu uczelni partnerskich, co dodatkowo zwiększało różnorodność perspektyw.

Jak ocenić zespół przed startem

Nie każdy uczestnik musi mieć doświadczenie w pracy przy projektach artystycznych. Znacznie ważniejsze jest to, czy grupa potrafi podzielić odpowiedzialność i podejmować decyzje bez wielogodzinnych sporów o każdy szczegół. W krótkim maratonie projektowym nie ma czasu na budowanie zespołu od podstaw.

Przed rozpoczęciem pracy warto ustalić trzy rzeczy:

1. Kto rozumie problem instytucji? Sama znajomość narzędzia nie wystarczy, jeśli zespół nie wie, dla kogo powstaje rozwiązanie.

2. Kto odpowiada za doświadczenie odbiorcy? Prototyp powinien mieć określonego użytkownika: zwiedzającego, kuratora, edukatora, artystę albo pracownika archiwum.

3. Kto będzie w stanie pokazać działanie projektu? W hackathonie liczy się nie tylko pomysł, ale też czytelna demonstracja jego potencjału.

Najczęstszy błąd polega na rozpoczęciu od podziału zadań technicznych. Najpierw trzeba podzielić odpowiedzialność za wartość projektu, a dopiero później za poszczególne elementy implementacji.

W kreatywnym hackathonie technologia nie jest głównym bohaterem. Jest narzędziem, które ma rozwiązać konkretny problem instytucji albo zmienić doświadczenie odbiorcy.

Dostęp do danych i interfejsów programistycznych decyduje o realności pomysłu

W opisie wydarzenia często pojawiają się hasła dotyczące sztucznej inteligencji, rzeczywistości rozszerzonej, analizy obrazu czy cyfrowych archiwów. Same hasła niewiele jednak mówią. Kluczowe pytanie brzmi: z jakich zasobów uczestnicy będą mogli faktycznie skorzystać?

Jeżeli projekt ma bazować na zbiorach muzealnych, trzeba wiedzieć, czy organizator udostępni fotografie, opisy obiektów, metadane, nagrania, modele trójwymiarowe albo inne materiały. Jeżeli rozwiązanie ma komunikować się z systemem instytucji, potrzebny będzie interfejs programistyczny, czyli API, wraz z dokumentacją i ograniczeniami dostępu. Bez tego zespół może stworzyć jedynie makietę opartą na przykładowych danych.

Przy ocenie zaplecza technicznego warto rozdzielić trzy poziomy:

Nie trzeba oczekiwać, że organizator udostępni pełne systemy produkcyjne. Wystarczy jasno opisane środowisko testowe i reprezentatywny zestaw danych. Problem zaczyna się wtedy, gdy uczestnicy dowiadują się o ograniczeniach dopiero po rozpoczęciu pracy.

Co sprawdzić w regulaminie technicznym

Dobrze przygotowany regulamin albo przewodnik dla uczestników powinien odpowiadać na praktyczne pytania:

• Czy dane są dostępne przed wydarzeniem, czy dopiero w chwili startu?
• Czy można korzystać z własnych narzędzi i usług zewnętrznych?
• Czy organizator zapewnia konta, klucze dostępowe albo środowisko obliczeniowe?
• Czy dane można pobierać, przetwarzać i przechowywać po zakończeniu hackathonu?
• Czy projekt ma działać na urządzeniach uczestników, w przeglądarce czy w infrastrukturze instytucji?
• Czy rozwiązanie musi być działającym prototypem, czy wystarczy makieta doświadczenia?

Te pytania nie są przesadną ostrożnością. W projektach wykorzystujących sztuczną inteligencję szczególne znaczenie ma jakość i legalność danych treningowych. W rozwiązaniach opartych na rzeczywistości rozszerzonej liczy się natomiast nie tylko efekt wizualny, lecz także dostępność urządzeń, sposób oznaczenia przestrzeni i warunki, w których odbiorca będzie korzystał z aplikacji.

Jeżeli organizator mówi o otwartych danych, ale nie pokazuje ich struktury ani przykładowego rekordu, należy traktować to jako zapowiedź, a nie gotowe zaplecze. Przy krótkim wydarzeniu różnica między jednym a drugim może przesądzić o powodzeniu projektu.

Mentorzy są częścią infrastruktury wydarzenia

Mentor nie powinien być wyłącznie osobą, która pojawia się na kilka minut przy każdym zespole i pyta, czy wszystko idzie zgodnie z planem. W dobrym hackathonie pełni funkcję szybkiego filtra: pomaga odróżnić problem istotny od efektownego, ale mało użytecznego dodatku.

Potrzebni są mentorzy z różnych obszarów. Ekspert technologiczny pomoże ograniczyć zakres funkcji i dobrać rozwiązanie możliwe do wykonania w 24 albo 48 godzin. Praktyk instytucji kultury oceni, czy projekt odpowiada na rzeczywisty sposób pracy muzeum, teatru lub galerii. Projektant doświadczeń użytkownika sprawdzi, czy odbiorca rozumie, co ma zrobić. Z kolei osoba zajmująca się prawem autorskim może uchronić zespół przed wykorzystaniem treści, których nie wolno publikować.

Sam tytuł mentora nie wystarczy. Warto sprawdzić:

• czy mentorzy są związani z tematyką wydarzenia;
• czy ich role są opisane przed rozpoczęciem rejestracji;
• czy zespoły mają zaplanowane konsultacje, czy tylko możliwość zadawania pytań;
• czy przewidziano osobne wsparcie dla prototypu technicznego i warstwy artystycznej;
• czy mentorzy mogą pomóc także w przygotowaniu prezentacji finałowej.

W krótkim wydarzeniu konsultacja w odpowiednim momencie może być więcej warta niż dodatkowe godziny kodowania. Zespół, który zbyt długo rozwija funkcję poboczną, traci czas na dopracowanie podstawowej ścieżki użytkownika. Dobry mentor potrafi zatrzymać ten proces, zanim projekt stanie się zbiorem atrakcyjnych, lecz niespójnych elementów.

Mentor a jury — to nie są te same role

Jury ocenia wynik. Mentor pomaga go zbudować. Organizatorzy czasem mieszają te funkcje, zapraszając te same osoby do obu zadań. Nie musi to być problemem, ale uczestnicy powinni wiedzieć, kiedy otrzymują poradę, a kiedy projekt jest już oceniany.

Przejrzysty system oceny powinien uwzględniać nie tylko sprawność techniczną. W projektach kultury równie ważne mogą być:

• trafność odpowiedzi na problem instytucji;
• jakość doświadczenia odbiorcy;
• wartość artystyczna albo edukacyjna;
• możliwość dalszego rozwijania prototypu;
• odpowiedzialne wykorzystanie danych i technologii;
• jasność prezentacji oraz uczciwe określenie ograniczeń.

Nagroda nie powinna przesłaniać tych kryteriów. W ogólnopolskiej edycji konkursu HackArt realizowanej z platformą ChallengeRocket.com główna nagroda wynosiła 10 000 zł, a do konkursu nadesłano 26 projektów. To pokazuje skalę zainteresowania, ale sama kwota nie mówi jeszcze, czy zwycięskie rozwiązanie otrzymało środki, opiekę i dostęp do instytucji potrzebne do dalszego rozwoju.

Prawa autorskie trzeba ustalić przed napisaniem pierwszej linijki kodu

To jeden z najbardziej pomijanych tematów kreatywnych hackathonów. Uczestnicy skupiają się na pomyśle, prototypie i prezentacji, a regulamin dotyczący praw autorskich czytają dopiero wtedy, gdy projekt zostanie wyróżniony. Wtedy może się okazać, że organizator oczekuje szerokiego przeniesienia praw majątkowych albo że wykorzystane materiały nie mogą być publikowane poza wydarzeniem.

Nie istnieje jeden ogólnokrajowy standard umów dotyczących projektów powstających podczas hackathonów organizowanych przez instytucje kultury. Dlatego każdy regulamin trzeba analizować osobno. Szczególnej uwagi wymagają cztery obszary.

1. Autorstwo projektu

Regulamin powinien wskazywać, kto jest uznawany za autora prototypu i jak traktowane są projekty zespołowe. Warto też sprawdzić, czy organizator może modyfikować projekt bez zgody wszystkich twórców oraz czy uczestnicy zachowują prawo do prezentowania go w portfolio.

2. Zakres praw przekazywanych organizatorowi

Trzeba rozróżnić licencję od przeniesienia autorskich praw majątkowych. Licencja może pozwalać instytucji na określone wykorzystanie projektu, na przykład prezentację podczas wydarzenia. Przeniesienie praw może mieć znacznie szerszy zakres. Nie należy zakładać, że zapis o prawach jest wyłącznie formalnością.

3. Materiały dostarczone przez instytucję

Zdjęcia dzieł, nagrania, teksty kuratorskie, znaki graficzne i archiwalne dokumenty mogą być objęte różnymi prawami. To, że organizator udostępnia materiał uczestnikom, nie zawsze oznacza zgodę na jego nieograniczoną publikację. W regulaminie powinno być wyjaśnione, w jakim celu można używać tych treści i co dzieje się z nimi po zakończeniu wydarzenia.

4. Elementy zewnętrzne i narzędzia sztucznej inteligencji

Zespół może korzystać z bibliotek, gotowych modeli, muzyki, krojów pisma, obrazów albo usług internetowych. Każdy z tych elementów może mieć własne warunki licencyjne. W przypadku narzędzi generatywnych dodatkową kwestią stają się zasady dotyczące danych wejściowych i wygenerowanych rezultatów.

Najbezpieczniejsza praktyka jest prosta: przed startem należy stworzyć listę elementów, które zespół chce wykorzystać, i przypisać do nich źródło oraz status prawny. Nie trzeba przygotowywać rozbudowanej opinii prawnej, ale nie wolno zostawiać tej kwestii domysłom.

Prototyp bez ustalonego statusu prawnego może wygrać finał, a mimo to nie nadawać się do publicznego wdrożenia.

Co naprawdę powstaje w 24 albo 48 godzin

Typowy hackathon trwa 24–48 godzin, często w formule weekendowego maratonu. To wystarczająco długo, by przygotować działający prototyp, ale zdecydowanie za krótko, by stworzyć kompletny produkt gotowy do obsługi dużej publiczności.

Warto rozróżnić trzy rezultaty, które często wrzuca się do jednego worka:

1. Makieta — pokazuje układ ekranów, sposób poruszania się po rozwiązaniu albo przebieg doświadczenia, ale nie musi mieć działającego zaplecza.

2. Prototyp funkcjonalny — realizuje najważniejszą ścieżkę i pozwala sprawdzić, czy pomysł działa w praktyce.

3. Wersja pilotażowa — może zostać przetestowana z ograniczoną grupą odbiorców w warunkach zbliżonych do rzeczywistych.

Wynikiem większości hackathonów jest drugi z tych poziomów, czasem połączony z dobrze przygotowaną makietą. To wystarczy, by zweryfikować kierunek, ale nie zastępuje badań z użytkownikami, testów bezpieczeństwa, dopracowania dostępności ani integracji z systemami instytucji.

Przy ocenie projektu po finale warto zadać kilka konkretnych pytań:

• Czy prototyp działa bez udziału autora?
• Czy można przeprowadzić z nim test z osobą, która nie zna założeń projektu?
• Czy rozwiązanie wykorzystuje prawdziwe dane, czy wyłącznie przykładową zawartość?
• Które elementy są gotowe, a które zostały tylko zasymulowane?
• Jakiego rodzaju prace są konieczne, aby przejść do pilotażu?
• Kto ma prowadzić projekt po zakończeniu konkursu?

Odpowiedzi pozwalają odróżnić obiecującą koncepcję od prezentacji, która dobrze wygląda wyłącznie na scenie finałowej.

Od nagrody do wdrożenia prowadzi osobna ścieżka

Największym nieporozumieniem związanym z hackathonami jest przekonanie, że zwycięstwo automatycznie uruchamia wdrożenie. W rzeczywistości nagroda potwierdza wartość pomysłu w ramach określonych kryteriów i czasu. Nie gwarantuje budżetu, zespołu deweloperskiego, zgód prawnych ani gotowości instytucji do zmiany codziennego sposobu pracy.

Dalszy rozwój może przebiegać kilkoma drogami:

Nie każdy projekt powinien przechodzić wszystkie etapy. Czasem najlepszym rezultatem będzie decyzja, że dana technologia nie rozwiązuje badanego problemu. Taki wniosek również ma wartość, zwłaszcza jeśli został oparty na realnym prototypie i rozmowie z odbiorcami.

Wydarzenia poświęcone kulturze cyfrowej mogą być dobrym miejscem do obserwowania, jak prototypy funkcjonują w szerszym obiegu. Festiwale takie jak Digital Cultures Festival w Warszawie łączą wystawy nowych mediów z prezentacjami projektów wykorzystujących rzeczywistość wirtualną i rozszerzoną oraz dyskusjami o sztucznej inteligencji. Dla uczestnika hackathonu to szansa, by zobaczyć nie tylko samą technologię, ale też sposób jej osadzenia w programie artystycznym i relacji z publicznością.

Jak wybrać wydarzenie odpowiednie dla konkretnego celu

Nie ma jednego najlepszego hackathonu kreatywnego. Innego wydarzenia potrzebuje osoba, która chce zbudować portfolio, innego instytucja szukająca rozwiązania dla archiwum, a jeszcze innego zespół artystyczny zainteresowany eksperymentem z generatywnym obrazem.

Przed zgłoszeniem warto określić własny cel:

• Nauka i networking — najważniejsze będą mentorzy, różnorodność uczestników i możliwość pracy w zespole.
• Prototyp dla instytucji — kluczowe okażą się dane, dostęp do pracowników oraz jasno opisany problem.
• Projekt artystyczny — większe znaczenie będą miały swoboda twórcza, sposób prezentacji i prawa do rezultatu.
• Rozwój produktu — trzeba sprawdzić, czy organizator oferuje pilotaż, finansowanie albo kontakt z potencjalnym użytkownikiem.
• Badanie technologii — istotne będą narzędzia, środowisko testowe i obecność mentorów technicznych.

Pomocne może być proste porównanie wydarzeń według kilku cech:

Taka tabela nie zastąpi lektury regulaminu, ale pozwala szybko odsiać wydarzenia, które dobrze wyglądają promocyjnie, a nie oferują warunków do sensownej pracy.

Kolejny krok: nie zapisuj się, zanim nie sprawdzisz sześciu odpowiedzi

Decyzję można podjąć sprawnie, jeśli zamiast analizować cały opis wydarzenia bez hierarchii, poszuka się odpowiedzi na sześć podstawowych pytań:

1. Jaki konkretny problem kultury mam pomóc rozwiązać?

2. Jakie dane, materiały i narzędzia będą rzeczywiście dostępne?

3. Czy w wydarzeniu uczestniczą osoby rozumiejące pracę instytucji kultury?

4. Kto pomoże zespołowi ocenić pomysł przed finałem?

5. Co regulamin mówi o autorstwie, licencjach i wykorzystanych materiałach?

6. Jaka jest realna ścieżka po zakończeniu hackathonu?

Jeśli na dwa lub trzy z tych pytań nie ma odpowiedzi, nie trzeba od razu skreślać wydarzenia. Warto jednak napisać do organizatora przed rejestracją. Sposób odpowiedzi jest dodatkową informacją: konkretny, rzeczowy komunikat świadczy o przygotowaniu, a unikanie pytań dotyczących danych, praw i dalszego rozwoju powinno skłonić do ostrożności.

Hackathon łączący sztukę i technologię może być intensywnym laboratorium pomysłów, miejscem spotkania różnych zawodów i szybkim testem dla rozwiązania, którego instytucja nie miałaby czasu opracować tradycyjną drogą. Nie jest jednak skrótem omijającym analizę potrzeb, kwestie prawne i późniejsze prace wdrożeniowe.

Najrozsądniejszy wybór to nie zawsze wydarzenie z największą nagrodą ani najbardziej efektownym hasłem. Lepsze będzie to, które zapewnia dostęp do realnego problemu, odpowiednich danych, kompetentnych mentorów i uczciwie opisuje, co stanie się z projektem po weekendzie. Dopiero wtedy 24–48 godzin pracy ma szansę stać się początkiem rozwiązania, a nie tylko dobrze zaprezentowanym finałem.