Pamiętam spotkanie w salce z widokiem na parking. Po jednej stronie founder z oczami na zapałkach, po drugiej dyrektor z korpo, który miał kalendarz zapchany jak autostrada przed długim weekendem. Ja w środku z notesem i pytaniem: co zrobimy w 6 tygodni, co da się uruchomić na żywych danych, a nie w pdf. Od tamtej pory zbieram sprawdzone układy współpracy, które kończą się działającym artefaktem i decyzją, a nie pięknym slajdem.

Oto moja ósemka.

1. Fellowship w firmie

Na 3–6 miesięcy wchodzisz do zespołu jako „gość specjalny” od konkretnego problemu, z własnym czasem i swobodą myślenia, ale z dostępem do danych i ludzi.

Plusy: szybka wymiana wiedzy, dostęp do realnych ograniczeń. Minusy: łatwo utonąć w bieżączce zespołu.

Kontrakt: umowa o dzieło albo B2B z klauzulą o IP typu background zostaje u badacza, rezultat na licencji niewyłącznej dla firmy; 30 dni na review publikacji, bez możliwości wetowania na wieczność.

Wskaźniki: czas do pierwszego prototypu w środowisku testowym, liczba decyzji productowych zmienionych dzięki insightom, adopcja narzędzia poza zespołem macierzystym.

2. Wspólny lab

Tworzycie małą jednostkę z nazwą i roadmapą. Połowa ludzi z firmy, połowa z uczelni lub niezależnego zespołu. Cel: tematy średniego horyzontu, które potrzebują tygodni i miesięcy, nie lat.

Plusy: stabilność finansowania i zaplecze. Minusy: ryzyko muzeum projektów, jeśli nie ma jasnych bramek decyzyjnych.

Kontrakt: list intencyjny plus master services agreement, do tego data processing agreement i jasny podział IP: wynalazki wspólne licencjonowane firmie na warunkach royalty-free w jej domenie, publikacja po 60 dniach z anonimizacją.

Wskaźniki: liczba artefaktów gotowych do wpięcia w produkt, odsetek hipotez odrzuconych wcześnie, cykl od pomysłu do demo u interesariusza.

3. Grant rozwojowy

Pieniądze publiczne lub fundacyjne na rozwiązanie konkretnego problemu biznesowo-społecznego z partnerem wdrożeniowym. Tak, wiem, słowo grant wielu odstrasza, ale da się to zrobić bez papierologii jako sportu ekstremalnego.

Plusy: finansowanie ryzyka technologicznego, możliwość pracy nad trudnym problemem. Minusy: terminy i biurokracja, trzeba pilnować zakresu.

Kontrakt: konsorcjum z liderem, opis kamieni milowych, IP zwykle u lidera z prawem do korzystania przez partnerów; klauzula o otwartym kodzie dla komponentów badawczych na licencji MIT lub Apache 2.0.

Wskaźniki: zgodność z kamieniami, liczba komponentów otwartych, realny transfer do partnera wdrożeniowego w ciągu 90 dni od zakończenia finansowania.

4. Research-as-a-service

Stała opłata miesięczna za dostęp do zespołu badawczego i gotowych narzędzi. Jak abonament na analitykę, tylko z ludźmi, którzy wchodzą w kontekst.

Plusy: przewidywalność kosztów, szybkie kolejki zadań. Minusy: pokusa „zróbcie nam raport” zamiast pracy na artefaktach.

Kontrakt: retainer z limitem godzin i prawem pierwszeństwa, service level dla odpowiedzi i prototypów, IP na rezultaty u klienta, ale prawo do ponownego użycia ogólnych komponentów po depersonizacji.

Wskaźniki: czas odpowiedzi na zapytanie, liczba wdrożonych zmian na miesiąc, rating „czy decyzja byłaby inna bez tego serwisu”.

5. Konsorcjum problemowe

Kilka firm, jeden trudny temat, wspólna pula danych i neutralny operator. Przykład z Polski: bezpieczeństwo płatności albo logistyka chłodnicza. W pojedynkę nikt nie ma pełnego obrazu.

Plusy: lepsze dane, dzielenie kosztów. Minusy: spory o prywatność, kto co wnosi i co wynosci.

Kontrakt: umowa konsorcyjna z zasadami wnoszenia danych, czarną listą użyć, escrow na kod, IP dzielone jako wspólna licencja w obrębie konsorcjum, publikacje tylko z akceptacją wszystkich.

Wskaźniki: liczba partnerów aktywnie dostarczających dane, pokrycie rynku, liczba wspólnych modeli lub pipeline’ów, decyzje regulacyjne wsparte wynikami.

6. Embedded sabbatical

Badacz idzie „na gościnne” do firmy na 1–2 dni w tygodniu przez pół roku. Ma kartę dostępu, ale nie siedzi w korpo full time. Idealne, gdy trzeba zrozumieć proces od kuchni.

Plusy: bliskość codziennej pracy bez utraty niezależności. Minusy: rozciągnięty czas, łatwo wpaść w tryb konsultacyjny zamiast budowania.

Kontrakt: B2B z harmonogramem obecności, NDA, prawo do publikacji metod po anonimizacji, przeniesienie majątkowych praw do konkretnych komponentów, ale nie do wzorców i bibliotek ogólnych.

Wskaźniki: liczba wspólnych pull requestów, zgłoszeń do backlogu, ile razy zespół productowy sam użył powstałych narzędzi.

7. Otwarte artefakty plus płatne wsparcie

Kod i notatniki są publiczne, biznes płaci za wdrożenie w swojej infrastrukturze, szkolenie i wsparcie. Dobra ścieżka dla niszowych narzędzi.

Plusy: widoczność, łatwiejsza rekrutacja kontrybutorów, brak zamknięcia na jednego klienta. Minusy: trzeba dbać o jakość repo i dokumentację.

Kontrakt: umowa wdrożeniowa na konfigurację i utrzymanie, licencja Apache 2.0 lub podobna, do tego umowa serwisowa z gwarantowanym czasem reakcji.

Wskaźniki: liczba zewnętrznych użytkowników, tempo wydawania wersji, zgłoszenia błędów zamknięte w czasie T, wpływ na koszt i czas wdrożenia u klienta.

8. Sprint badawczo-produktowy

Trzy–cztery tygodnie intensywnej pracy z jedną tezą do sprawdzenia. Na końcu musi powstać demo na danych klienta i krótka karta decyzji: wchodzimy czy nie.

Plusy: tempo, jasna definicja sukcesu. Minusy: nie wszystko da się zamknąć w sprint, kusi upiększanie wyników.

Kontrakt: krótkie SOW z celem i metrykami, rozliczenie za rezultat, nie za godziny; IP u klienta z niewyłącznym prawem badacza do pokazywania demo w portfolio po maskowaniu danych.

Wskaźniki: czy demo działa na danych klienta, czas do pierwszego wyniku „na zielono”, różnica w metryce biznesowej po 2–4 tygodniach pilotażu.

---

Jak wybierać wzorzec i nie zwariować

Zadaję sobie trzy proste pytania:

1. Czy mamy jednego sponsora, który powie „tak” w ciągu tygodnia. Jeśli nie, biorę konsorcjum albo grant i zakładam dłuższy marsz.
2. Czy dane i decyzja są w zasięgu jednego zespołu. Jeśli tak, sprint albo fellowship. Jeśli nie, embedded sabbatical, żeby zobaczyć proces od środka.
3. Czy cel da się zmierzyć w metrykach, które nie są marketingowe. Jeśli nie, na start biorę RaaS z jasnym katalogiem zadań i przeglądami co dwa tygodnie.

Czerwone flagi, które ignorujemy na własne ryzyko

• wieczne NDA bez terminu wygaśnięcia i bez trybu publikacji po anonimizacji
• brak właściciela po stronie firmy albo zmieniający się co tydzień „komitet”
• brak dostępu do środowiska testowego i danych reprezentatywnych
• kontrakt na godziny zamiast na rezultat, gdy zakres jest jasno opisany
• raport zamiast artefaktów jako definicja zakończenia prac

Mini checklista kontraktowa

• IP: rozróżnij background i rezultat, określ licencję i pola eksploatacji
• dane: DPA, zakres i retencja, prawo do tworzenia sztucznych próbek do demo
• publikacje: okno review 30–60 dni, maskowanie wrażliwych elementów
• mierniki: ustal „czas do pierwszego uruchomienia”, „czas powrotu po błędzie”, jedną metrykę biznesową
• przeglądy: rytm tygodniowy, decyzja go lub no-go na koniec etapu

Nie mam złudzeń, że każdy układ będzie działał zawsze. Zdarzają się projekty, które mimo idealnego kontraktu rozbijają się o brak odwagi po stronie decydentów. Ale gdy wzorzec jest dobrany pod problem, a finałem jest działający artefakt, szanse rosną. I o to chodzi.