---
title: Final sync - scenariusz rozmowy 20 minut
type: log
data: 2026-09-07
agent: Codex
ttl: 90d
---

# Final sync / nagrywane po zgodzie uczestników / 20 minut / 5 bloków

Szablon do wypełnienia po odpowiedziach i farmingu zwrotnym. Nie ma jeszcze rozstrzygnięć z formularzy.

## Ustalone pisemnie - nie omawiamy

Do uzupełnienia po otrzymaniu odpowiedzi. Nie traktować braków jako zgody.

## 1. Wynik i granice (4 min)
Propozycja: wybierzmy scenariusze CRM i moduł do komercjalizacji.
Ustalić: kryteria odbioru na wersji eksperymentalnej, minimum którego nie odpuszczamy i co ograniczymy, gdy demo w czwartek o 12:00 pokaże ryzyko.

## 2. Zależności i gotowość (4 min)
Pytanie: kto bez czyjej decyzji nie ruszy?
Ustalić: dostęp, kontrakt między modułami, osoba odblokowująca i czas. Jak przekazujemy kod i robimy review bez kolejki do jednej osoby?

## 3. Podział pracy (6 min)
Do rozstrzygnięcia: konflikty „biorę ja” i zadania bez właściciela.
Ustalić: dla każdego wyniku jedna osoba odpowiedzialna, reviewer i demo. Klemens też nazywa swój rezultat i czas na odblokowywanie innych.

## 4. Eksperymenty i komercjalizacja (3 min)
Pytanie: jak chronimy oba bloki przy ograniczonej przepustowości?
Ustalić: minimalny zakres reklam, rolek i Apollo oraz co odkładamy.
Do rozstrzygnięcia: godzina eksperymentów. Propozycja strony to czwartek 13:30; w rozmowie padło 16:00, obok przygotowania do demo o 18:00.

## 5. Kontrakt pracy (3 min)
Ustalić: gotowe, blokada, zmiana zakresu i sposób eskalacji. Przy piątkowym przekazaniu zapisujemy warunki przejścia z eksperymentalnej na produkcję i jedną miarę efektu do sprawdzenia po 30 dniach.

## Co ma wypaść z rozmowy

| Rozstrzygnięcie | Właściciel | Termin |
|---|---|---|
| Zakres CRM i odbiór | do uzupełnienia | do uzupełnienia |
| Moduł komercjalizacji | do uzupełnienia | do uzupełnienia |
| Blokady i podział pracy | do uzupełnienia | do uzupełnienia |
| Eksperymenty, reklamy, rolki, Apollo | do uzupełnienia | do uzupełnienia |

Tabelę uzupełniamy z rozmowy. Zadania w trackerze powstają po zatwierdzeniu.

## Środa 9.09 — wspólne sesje i wieczorne ustalenia

- 15:00–15:20: final sync — wizja, priorytety, zakres i odpowiedzialność.
- 15:20–15:30: sprawdzenie dostępów przez logowanie, właściciele brakujących dostępów.
- 15:30–16:00: Consultation with Fred <> receptionOS.
- 16:00–16:20: kultura pracy, enablement i narzędzia. Dostępy przez 1Password, wymiana kontekstu, jeden kanał komunikacji i miejsce zadań.
- 16:20–17:00: wspólna sesja Łukasza — model danych i przejście przez ścieżkę produktu. Zadanie, tag, klient, lead, źródło, wizyta, wartość: definicje, relacje, pola i granice modułów.
- 17:00–17:20: workflow Czarka — przygotowanie feature’u, testy, review, akceptujący, warunki publikacji i wycofania zmiany. Produkcja wymaga osobnej decyzji; pracujemy na wersji eksperymentalnej.
- 17:20–18:30: pierwsza iteracja.
- 18:30–19:15: kolacja.
- 19:15–20:00: druga iteracja.
- 20:00–20:30: demo i konkretne blokady.
- 20:30–21:00: finalizacja milestone’ów — wynik, właściciel, termin, kryterium odbioru, sprawdzający i zależności. Zapisujemy, co odkładamy.
- 21:00: wspólny wieczór.

## Wpływ perspektywy Adama

Adam preferuje samodzielną pracę z uzgodnieniem na wejściu i review na wyjściu. Zgłasza braki dostępów — stan wymaga sprawdzenia. Wybór celu (upsell czy nowe kliniki), granice warstwy reklam oraz właściciel formalności, szkoleń i onboardingu wymagają decyzji zespołu. Eksperymenty są opcjonalne, rolki następują po odbiorze modułu lub po wyjeździe. Makieta i mapa przy blokadach są etapem przygotowania, nie ukończonym produktem.

## Czwartek 10.09

- 11:30–12:00: Maria (VF) · Klemens; pozostali kontynuują pracę.
- 12:00: demo i decyzja o zakresie do 18:00.
- 13:30: eksperymenty dla chętnych; Adam kontynuuje implementację.
- 16:00: dopracowanie modułów i scenariuszy odbioru zamiast rolek.
- 18:00: demo i odbiór; decyzja o materiale do rolki po wyjeździe.
- Po kolacji: sauna, następnie Klemens + Czaro — reflection time; Adam + Łukasz — co-enablement.

Checklistę na stronie prowadzimy na jednym ekranie. Zapis jest lokalny w przeglądarce; eksport JSON służy przenoszeniu, a kopiowanie ustaleń — przekazaniu ich na wspólnym kanale. Nie ma automatycznej synchronizacji między osobami.