#management #marketing Ten przewodnik opisuje kompletny system operacyjny działu marketingu: od filozofii zarządzania po konkretne tablice, formuły i dashboardy. System powstał z praktyki wdrożeń w agencjach i zespołach inhouse i działa bojowo na dziesiątkach workflow. Zasady są uniwersalne i możliwe do wdrożenia w dowolnym task trackerze ([monday.com](https://try.monday.com/work-management-pl), Asana, ClickUp, Jira). Przykłady implementacji pokazano na [monday.com](https://try.monday.com/work-management-pl) — jako referencję, nie wymóg. **Dla kogo:** dla szefa marketingu, który tonie w chaosie zadań; dla menedżera, który nie umie odpowiedzieć „na co poszedł tydzień zespołu"; dla właściciela agencji, któremu potrzebna jest rentowność, a nie heroizm; dla konsultanta wdrażającego porządek w cudzych działach. **Co dostaniesz na wyjściu:** taśmę produkcyjną, w której każda godzina pracy jest sklasyfikowana, każde zadanie żyje we wspólnym rytmie, a raportowanie odpowiada wykonawcy, menedżerowi i właścicielowi — w godzinach, wynikach i pieniądzach. ## 1. Filozofia: trzy systemy zarządzania ### 1.1. Dwa konfliktujące obwody W zarządzaniu produkcją marketingu (jak i każdego produktu intelektualnego) istnieją dwa bazowe zestawy procesów: > **Zarządzanie projektowe** — zarządzanie produkcją z punktu widzenia jakości produktu końcowego i terminów jego realizacji. To procesy, które popychają zespół, by zrobił to, co trzeba, dobrze i na czas. > **Zarządzanie zasobowe** — zarządzanie produkcją z punktu widzenia obciążenia pracą. To procesy, które analizują nakłady czasu, odciążają zespół i przesuwają zadania na późniejsze terminy, wychodząc z istniejących ograniczeń. Problem w tym, że te obwody są w konflikcie. Projektowy ciągnie „szybciej i więcej", zasobowy — „wolniej i mniej". Żeby utrzymać jakość, rentowność i przyzwoitość wobec ludzi, trzeba być skutecznym w obu jednocześnie. Do tego potrzebny jest trzeci system, który je splata i równoważy: > **Sprint management** — system warunków definiujących współdziałanie zarządzania projektowego i zasobowego. Najważniejszy z warunków — wspólny **rytm stawiania zadań**. </br> ![[sprint-management-auto.svg]] ### 1.2. Rytm, odcięcia, sprinty Bez rytmu zadania chaotycznie rozlewają się po czasie. Każde zadanie wymaga coraz większego kontekstu do oceny, analityka staje się nieludzką robotą, a menedżer musi trzymać w głowie całą produkcję naraz. Pracować się da, ale trudno. Rytm tnie czas na równe komórki i tym samym sztucznie ogranicza objętość kontekstu potrzebnego do pracy z zadaniem: > **Odcięcie** — moment, w którym nie istnieje ani jedno bieżące zadanie: wszystkie są albo zamknięte, albo jeszcze nierozpoczęte. > **Sprint** — komórka czasu między dwoma odcięciami, w którą wkładane są zadania. > **Rytm** — interwał między odcięciami, określający długość sprintów. Bez rytmu | Z rytmem -- | -- ![[Pasted image 20240314201038 1.png]] | ![[Pasted image 20240314201159.png]] Sprint pozwala „zapominać" o wszystkich innych tygodniach poza bieżącym. Koszt każdego zadania upraszcza się do pytania: „Jaki procent 35-godzinnego sprintu pracownika ono zajęło?" Każde niewykonane zadanie sygnalizuje: albo je niedoszacowano, albo godziny zjadło inne zadanie. Tak powstaje proces ciągłego leczenia zarządzania — każdy sprint odsłania bugi, które można naprawiać już w następnym tygodniu, a nie za miesiąc, gdy zrobi się katastrofalnie źle. ### 1.3. Tydzień — idealny rytm dla marketingu Jednotygodniowe sprinty są nietypowe dla klasycznego Scruma i IT, ale w marketingu i kreacji dynamika projektów jest wyższa, więc krótki rytm działa lepiej. Rekomendowane parametry: rytm — **1 tydzień**; odcięcie — **poniedziałek, początek dnia pracy** (np. pon. 08:00). Bardziej ekologiczny wariant — zamykać sprint w piątek, zostawiając weekend jako „długie odcięcie", ale nie zadziała, jeśli część zespołu ma zadania weekendowe (sesje zdjęciowe, eventy, publikacje). ### 1.4. Mantry systemu Te zasady będą wracać przez cały przewodnik — to ściany nośne: 1. **Rentowność sprintów jest ważniejsza niż rentowność projektów.** Projekt może „poczekać", przepełniony sprint — nie: łamie ludzi i statystykę. 2. **Zadanie nigdy nie przecina odcięcia.** Wszystko, co nie mieści się w sprincie, jest dzielone na części. ^mantra-odciecie 3. **Zadań się nie przenosi — tworzy się nowe.** Niezamknięte zadanie zostaje w swoim sprincie jako fakt historyczny, na resztę zakłada się nowe. 4. **Nie zgadniesz pracochłonności, ale masz obowiązek próbować.** Każda estymacja, nawet słaba, jest lepsza niż jej brak. 5. **Każda godzina pracy musi mieć klasyfikację.** Czego nie da się rozłożyć po wymiarach analityki — tego nie da się ani ocenić, ani naprawić. --- ## 2. Architektura: budowa taśmy produkcyjnej System operacyjny marketingu to nie „jedna tablica z zadaniami", lecz warstwowa taśma produkcyjna. Każda warstwa odpowiada na swoje pytanie: po co praca jest wykonywana, jak jest produkowana, na czym się opiera i jak jest kontrolowana. > **Wszystkie tablice, pola i formuły w tym rozdziale to tylko jeden z możliwych sposobów realizacji.** Ważniejszy od konkretnego boardu jest **model**: jakie są warstwy, jak encje łączą się ze sobą i jakiego pytania pilnuje każda relacja. Konkretne boardy — także cały workspace referencyjny z załącznika — traktuj jak przykład, przenoszalny na dowolne narzędzie ([monday.com](https://try.monday.com/work-management-pl), Asana, ClickUp, Jira, Notion). Kopiuj model, relacje i podejście, nie kształt tabelki. ![[taśma-produkcyjna-pionowa_1.svg]] ### 2.1. Warstwa kontekstów: projekt, ticket albo proces Kontekst odpowiada na pytanie „**po co** wykonywana jest praca". Kontekst jest zawsze jednego z trzech typów — i są one **na jednym poziomie**: > **Projekt** — strategicznie planowana inicjatywa z określonymi celami i harmonogramem. Urodził się, przeżył swoje, został zamknięty. > **Ticket** — zgłoszenie z innego działu lub od podmiotu zewnętrznego, pojawiające się nieprzewidywalnie co do czasu i liczby. Kontekst dla prac-reakcji na konkretne zapytanie. > **Proces** — stała funkcja bez daty zakończenia: „prowadzić social media", „obsługiwać tickety", „publikować newsy w panelu". Proces ma link do instrukcji, odpowiedzialnego, status aktywności i flagę automatyzacji. Trzy typy wyczerpują pytanie „po co" zgodnie z MECE: praca jest wykonywana albo dla zaplanowanego rozwoju (projekt), albo w odpowiedzi na czyjeś zapytanie (ticket), albo dla utrzymania funkcji (proces). Czwartej opcji nie ma — i da się to zweryfikować. **Zasada jednego kontekstu:** każdy element workflow jest powiązany z dokładnie **jednym** kontekstem — jednym projektem ALBO jednym ticketem, ALBO jednym procesem. Jeśli zadanie pochodzi z ticketa, zamknięcie ostatniego zadania zamyka też ticket (gdy wszystkie powiązane prace są wykonane). Każdy kontekst ma **Charakter** — wymiar, który później pozwoli zobaczyć balans wysiłków: | Charakter | Co to jest | Przykład | |---|---|---| | Strategiczny | Pcha biznes do przodu | Uruchomienie nowego kanału pozyskania | | Operacyjny | Produkuje regularną wartość | Prowadzenie social mediów, wysyłki | | Administracyjny | Obsługuje samą pracę | Spotkania zespołowe, raportowanie, rekrutacja | | Infrastrukturalny | Buduje system | Konfiguracja CRM, automatyzacji, szablonów | Konteksty nie zawierają pracy — one ją **agregują**. Przez połączenia z tablicami workflow kontekst lustruje statusy, wykonawców, ramy czasowe i sumaryczne roboczogodziny wszystkich swoich zadań. Otwierając projekt lub ticket, menedżer widzi jego pełny koszt w godzinach, nie wchodząc w żadne zadanie. ### 2.2. Wejście do systemu: formularz, tickety, pomysły Praca nie ma prawa trafiać do produkcji „przez ramię wykonawcy" — system ma bramkę. **Formularz → Ticket.** Zgłoszenie składane jest przez formularz i niesie klasyfikację od urodzenia: kategoria (materiały drukowane, szablony SMS/Email, kampanie, masowe wysyłki, nieaktualne treści…), marka, aplikacja/oddział, target, kanał, pilność (od „ASAP 🔥" do „w najbliższe 8 tygodni"), deadline. Ticket przechodzi statusy od „Nowy" do „Gotowe"; duży ticket dostaje status „Przeniesiony do Projektów" — wyrasta na pełnoprawny projekt. **Zlecenia ustne — też tickety.** O każdym zleceniu z zewnątrz informowany jest właściciel systemu i zlecenie musi pojawić się w ticketach, nawet jeśli nie przyszło przez formularz. Prośba „zrób szybko banerek" albo staje się ticketem z kolejką i priorytetem, albo nie istnieje. **Prywatne notatki szefa — też wejście.** [[#Collect: obwód pamięci|Zasada śluzy]] działa i tutaj: zadanie z Memory Trackingu, wymagające rąk innego człowieka, wchodzi na taśmę przez tę samą bramkę — jako ticket lub zadanie z pełną klasyfikacją, a nie zostaje ustaleniem w notesie. **Pomysły** — backlog inicjatyw samego działu z typem (projekt/mini-projekt), kategorią (finanse, infrastruktura, acquisition, LTV) i priorytetem. Pomysły dojrzewają osobno od produkcji i po osiągnięciu gotowości zamieniają się w projekty. Bramka to zespołowa projekcja obwodu Collect: wszystko, co przychodzi, najpierw jest rejestrowane, a dopiero potem strukturyzowane, priorytetyzowane i kierowane do pracy. Pełny [[#3.1. Planowanie: cykl CORD|cykl CORD]], według którego żyje planujący, rozebrany jest w rozdziale o rytmie. ### 2.3. Warstwa workflow: taśmy uniwersalne i wyspecjalizowane Główna idea architektoniczna: **nie jedna tablica zadań, lecz rodzina wyspecjalizowanych taśm ze wspólnym rdzeniem** (o rdzeniu — [[#2.4. Anatomia elementu: wspólny rdzeń workflow|następna sekcja]]). Taśmy dzielą się na dwie grupy — uniwersalne, które ma praktycznie każdy dział, oraz wyspecjalizowane, które każdy zespół dobiera pod własne procesy. **Taśmy uniwersalne — cztery.** Niezależne od branży, stanowią szkielet każdej taśmy produkcyjnej: | Workflow | Co produkuje | Pola specjalne | |---|---|---| | 🗂️ Zadania | Uniwersalne zadania jednorazowe | Priorytet, pliki | | 📅 Spotkania | Koordynacja i dyskusje | Pliki, powiązanie z kontekstem; jedyny workflow z wieloma wykonawcami | | 🔄 Zadania cykliczne | Powtarzalna rutyna | Powiązanie z procesem, lustro instrukcji, flaga automatyzacji | | 🔕 Day OFF | Urlopy i nieobecności | Godziny nieobecności (ręcznie lub z ram), odejmowane od pojemności sprintu | Ten zestaw wystarcza, by wystartować: dopóki jakiś typ pracy nie ma własnego cyklu życia, żyje w uniwersalnych „Zadaniach". **Wyspecjalizowane taśmy — przykłady, nie kanon.** Wszystko poza rdzeniem jest specyficzne dla działu. To już procesy, które każdy definiuje sam, wychodząc od własnych potrzeb — poniższa lista to paleta inspiracji, a nie obowiązkowy zestaw. Typowe taśmy marketingowe: | Workflow | Co produkuje | Pola specjalne | |---|---|---| | 🎞️ Publikacje w SM | Content social mediów | Format i media, marka, status per kanał (IG/FB/TG/WA/TikTok/YT), teksty PL/RU/EN, akceptacja | | 📲 Kampanie SMS | Masowe wysyłki SMS | Treść, segment GEO, typ klienta, baza, stawka, automatyczne liczenie kosztu, link UTM, akceptacja | | 📧 Kampanie Email | Wysyłki i newslettery | Typ klienta, wielkość bazy, data wysyłki, UTM, open/click, akceptacja | | 🎯 Kampanie reklamowe | Paid: Meta / Google / TikTok Ads | Platforma, budżet, grupa docelowa, kreacje, link UTM, koszt, ROAS, status per platforma | | 🛬 Landing page / lejki | Strony docelowe i lejki | URL, wersje, testy A/B, integracje (piksel, formularze), status publikacji | | ✍️ Blog / SEO | Artykuły i treści organiczne | Słowo kluczowe, brief, status redakcji, meta, data publikacji | | 👑 Współprace z influencerami | Integracje z twórcami | Karta influencera, warunki, brief, deadline publikacji, kod promo / UTM, zasięgi, rozliczenie | | 🎬 Produkcja wideo | Materiały wideo | Scenariusz → nagranie → montaż → akceptacja; lokacja, sprzęt, podwykonawca | | 🖨️ Poligrafia | Materiały drukowane | Makieta → korekta → druk → dostawa; nakład, koszt, podwykonawca, data płatności | | 🎪 Eventy / webinary | Wydarzenia offline i online | Data, miejsce/platforma, budżet, rejestracje, follow-up | Plus **sub-workflow** — taśmy, których elementy rodzą się z elementów innych workflow, a nie bezpośrednio z kontekstów. W systemie referencyjnym to ✒️ Tłumaczenia. Po co to dzielić? Każdy typ pracy ma **własny cykl życia**. Publikacja przechodzi „Planowanie → Produkcja → Akceptacja → Publikowanie → Opublikowano", kampania SMS — „Planowanie → Przygotowanie → Akceptacja → Wysyłanie → Poszła/Odwołana". Wciskanie tego w uniwersalne statusy „To Do / In Progress / Done" oznacza utratę i sterowności, i analityki. Zasada wydzielania nowego workflow: typ pracy dostaje własną tablicę, gdy pojawia się u niego **własny cykl życia (statusy), własne pola obowiązkowe lub własna ekonomia**. Do tego momentu żyje w uniwersalnych „Zadaniach". I odwrotnie — nie mnóż taśm na zapas: każda nowa tablica to koszt utrzymania, więc wydzielaj dopiero wtedy, gdy typ pracy realnie usztywnił się we własny proces. ### 2.4. Anatomia elementu: wspólny rdzeń workflow Specjalizacja działa tylko dzięki części wspólnej. Każdy element każdego workflow — publikacja, kampania, spotkanie, tłumaczenie — niesie ten sam obowiązkowy zestaw pól: > **Wspólny rdzeń workflow** — część wspólna wszystkich taśm: zestaw pól, który ma każdy element niezależnie od tablicy, na której żyje. To po rdzeniu różne workflow łączą się w jeden pulpit, jeden raport, jeden interfejs — jeden system operacyjny działu. Wyspecjalizowane pola różnią taśmy między sobą; rdzeń pozwala je składać. Po polach rdzenia ekran „Moje zadania" zbiera elementy człowieka ze wszystkich tablic, dashboard obciążenia sumuje roboczogodziny niezależnie od typu pracy, a „Podziały" kroją wysiłek działu po markach, charakterze i sprintach ([[#4. Analityka: wysiłek, wynik, pieniądze|rozdział 4]]). Bez rdzenia rodzina taśm to archipelag osobnych tabelek; z rdzeniem — jeden system. Pola rdzenia: | Pole | Typ | Przeznaczenie | |---|---|---| | Nazwa | text | Konkretne, jednoznaczne sformułowanie | | 🎈 Kontekst | połączenie | Dokładnie jeden: projekt, ticket lub proces, dla którego praca jest wykonywana | | Marka | dropdown | Wiele | | Wykonawca | people | Jeden właściciel rezultatu | | Status | status | Wspólny cykl: Zaplanowane → W realizacji → Gotowe / Problem / Oczekuje; przy odcięciu dochodzą stany zamknięcia — „Odcięcie" („Almost") i „Nie rozpoczęto" ([[#3.4. Sprint: naprawa resztek\|naprawa resztek]]) | | Ramy czasowe | timeline | Początek i koniec **wewnątrz jednego sprintu** | | Estymacja | number | Planowana pracochłonność w godzinach | Oraz pola liczone, które wypełniają się same: | Pole | Formuła (istota) | Po co | |---|---|---| | Roboczogodziny | `Estymacja × liczba wykonawców + dod. godziny sub-workflow` | Pełny koszt elementu w godzinach | | Roboczogodziny [Marka] | `(Estymacja × liczba wykonawców + dod. godziny sub-workflow) / liczba marek w klasyfikacji` | Pełny koszt udziału marki w godzinach | | Sprint | Kod tygodnia ISO z daty końca, np. `26W28` | Grupowanie całej analityki po sprintach | | Miesiąc | Kod miesiąca, np. `26M07` | Grupowanie po miesiącach | Dwa detale, które czynią system samoobronnym: **Walidacja odcięcia formułą.** Formuła „Sprint" porównuje tygodnie ISO początku i końca zadania. Jeśli są różne — zamiast kodu sprintu element dostaje wartość **„Błędne ramy"**. Zadanie przecinające odcięcie jest natychmiast widoczne w każdym grupowaniu — [[#^mantra-odciecie|mantry nr 2]] pilnuje nie dyscyplina, lecz formuła. Bieżący sprint i miesiąc są podświetlane markerem 🟣. ``` IF(ISOWEEKNUM({Ramy#End})>0, IF(ISOWEEKNUM({Ramy#End})=ISOWEEKNUM({Ramy#Start}), CONCATENATE(RIGHT(YEAR({Ramy#End}),2),"W", format tygodnia z zerem wiodącym, IF(bieżący tydzień," 🟣"," ⚪")), "Błędne ramy"), "Brak daty") ``` **Mnożenie godzin przez ludzi.** Jeśli element ma dwóch wykonawców, roboczogodziny się podwajają: każdy dostaje pełną estymację do swojego obciążenia. Godzinne spotkanie grupowe pięciu osób kosztuje biznes pięć godzin — i system to pokazuje. ### 2.5. Wewnątrz elementu: jeden interfejs na cały proces Wyspecjalizowane pola nie służą „ładniejszej tabelce". Robi się je po to, by taśma realizowała trzy cele naraz: **centralizowała pracę i kontekst, centralizowała raportowanie i przyspieszała realizację przez automatyzacje.** **Centralizacja kontekstu — jeden interfejs zamiast dziesięciu okien.** Wyspecjalizowane kolumny zapewniają pełne gromadzenie kontekstu w jednym miejscu: wykonawca nie skacze między Excelem ze stawkami, panelem providera, dyskiem z kreacjami i czatem z akceptacją. Element kampanii SMS trzyma treść, segment GEO, typ klienta, bazę, stawkę i akceptację obok siebie — całość procesu produkcyjnego mieści się w jednej karcie. To skraca wdrożenie (widać, jakie pola wypełnić), zabija „a gdzie to było" i czyni pracę odtwarzalną niezależnie od tego, kto ją przejmie. **Centralizacja raportowania — dane liczą się same.** Skoro kontekst siedzi w polach, raport nie jest osobną czynnością — powstaje z tych samych pól przez formuły i połączenia (rozdział [[#4. Analityka: wysiłek, wynik, pieniądze|Analityka]]). Element w momencie wypełnienia zna swój koszt, swój sprint, swoją markę i swoje roboczogodziny. Nikt nie przepisuje niczego do „raportu na koniec miesiąca". Przykład pola liczącego się samo — koszt kampanii SMS w chwili wklejenia treści: ``` Liczba znaków = LEN(treść) SMS per kontakt = ROUNDUP(znaki ÷ (znaki specjalne ? 70 : 160)) Liczba SMS = wielkość bazy × SMS per kontakt Koszt wysyłki = −(stawka za SMS × liczba SMS) ``` ![[Pasted image 20260722191832.png]] Marketer, który dopisał zbędne zdanie, natychmiast widzi, że kampania podrożała o jedną trzecią — decyzja „skrócić czy zaakceptować koszt" zapada przed akceptacją, a nie po fakturze od providera. **Przyspieszanie realizacji — automatyzacje wpięte w taśmę.** Tu najlepiej wpinają się automatyzacje. Skoro wszystkie dane są w polach, na ich podstawie można generować gotowe materiały i odpalać akcje bez pracy ręcznej: - **Generowanie linków UTM** pod kampanię wprost z pól elementu (marka + kanał + nazwa kampanii + medium → gotowy link z tagami) — atrybucja ruchu jest spójna i bezbłędna, a nie sklejana ręcznie w notatniku. - **Skracanie i zapis linków**, generowanie kodów promo i QR, składanie kreacji z szablonu. - **Statusy-triggery**: wejście w „Akceptacja" powiadamia akceptującego; „Zlecić tłumaczenie" tworzy element w sub-workflow tłumaczeń (2.3); „Wysłać" woła webhook do providera SMS/Email. - **Zaciąganie wyników** z powrotem do elementu (open/click, koszt, zasięgi) po zakończeniu wysyłki. Efekt złożenia trzech celów: wyspecjalizowana taśma to nie „ładniejsze zadania", lecz **skompresowany proces** — jeden interfejs, w którym praca się dzieje, sama się raportuje i sama przyspiesza. Im więcej kontekstu w polach, tym więcej można zautomatyzować — i tym łatwiej bezpiecznie wpiąć AI (rozdział [[#6. Jak wdrażać AI do taśmy produkcyjnej|Jak wdrażać AI]]). ### 2.6. Warstwa baz informacyjnych Zasoby, na których opiera się produkcja, żyją osobno od zadań — nie mają sprintów ani deadline'ów, akumulują się i są utrzymywane: - **Baza wiedzy** — instrukcje do procesów (odwołują się do nich procesy i zadania cykliczne). - **Podwykonawcy** — zewnętrzni wykonawcy z warunkami; **Influencerzy** — karty z platformą, zasięgiem, engagement rate, reputacją, statusem negocjacji i połączeniem z kampaniami. - **Baza konkurentów** — karty konkurentów do monitoringu. - **Baza szablonów** — szablony SMS/Email/czatów ze statusem aktualności, treścią i opisem automatyzacji, które z nich korzystają. - **Lokalizacje, Aplikacje, Strony internetowe, Eventy, Baza grup, Posty do crowd-marketingu** — słowniki encji, do których odwołują się zadania i kampanie. - **Faktury, Bonusy, Dokumenty i umowy** — księgowość finansowa i prawna obok produkcji, a nie w osobnym wszechświecie (koszty — zawsze z minusem). Cecha bazy informacyjnej: elementu się nie „wykonuje", lecz „utrzymuje w aktualności". --- ## 3. Rytm: cykl życia sprintu Architektura z poprzedniego rozdziału to przestrzeń systemu — tablice, pola, połączenia. Rytm to jego czas. Cały rozdział opisuje jedną pętlę, która kręci się co tydzień: **planowanie CORD** zamienia przychodzący chaos w sprinty wypełnione do 100% pojemności, **spotkanie koordynacyjne** otwiera sprint, w trakcie tygodnia czas jest **rejestrowany**, a po odcięciu **bilansowany**, niedokończenia przechodzą **naprawę resztek** i wracają do sprintu jako nowe zadania, a **retrospektywa** zamienia odchylenia w poprawki norm dla następnego planowania — i pętla rusza od nowa. ![[cykl-produkcyjny-pionowo.svg]] W kalendarzu tygodnia pętla wygląda tak: | Kiedy | Co się dzieje | Gdzie opisane | |---|---|---| | Codziennie, w tle | Collect: rejestracja wszystkiego, co przychodzi | [[#Collect: obwód pamięci\|3.1]] | | Czwartek | Organize: budowa ustrukturyzowanego backlogu | [[#Organize: obwód strukturyzacji\|3.1]] | | Piątek | Review: konfrontacja, estymacje, wybór kandydatów | [[#Review: priorytetyzacja backlogu\|3.1]] | | Piątek | Raportowanie tygodnia: każdy zamyka tydzień raportem changelog | [[#5.4. Raportowanie tygodnia\|5.4]] | | Piątek → poniedziałek rano | Do: rozlewanie zadań po sprintach | [[#Do: rozlewanie po sprintach\|3.1]] | | **Poniedziałek, 08:00** | **Odcięcie** — stary sprint staje się historią, startuje nowy | [[#1.2. Rytm, odcięcia, sprinty\|1.2]] | | Poniedziałek | Spotkanie koordynacyjne: wyniki, resztki, styki | [[#3.2. Sprint: spotkanie koordynacyjne\|3.2]] | | Poniedziałek–wtorek | Naprawa resztek: na niedokończenia powstają nowe zadania | [[#3.4. Sprint: naprawa resztek\|3.4]] | | Cały sprint | Praca pod timerem; Czas [Fakt] przy każdym zamknięciu | [[#3.3. Sprint: rejestracja i bilansowanie czasu\|3.3]] | | Poniedziałek–środa | Bilansowanie czasu zamkniętego sprintu | [[#3.3. Sprint: rejestracja i bilansowanie czasu\|3.3]] | | Środa | Retrospektywa menedżerów: plan kontra fakt, korekta norm | [[#3.5. Sprint: retrospektywa\|3.5]] | I jedno spostrzeżenie, zanim wejdziemy w szczegóły: to potok, nie sekwencja. W każdym tygodniu wszystkie stacje pracują jednocześnie — tylko dla różnych sprintów: planuje się **następny**, produkuje **bieżący**, a bilansuje i naprawia **poprzedni**. ### 3.1. Planowanie: cykl CORD Zanim zadania trafią do sprintów, przeżywają cztery stadia — cykl **[[CORD]]**. Każde stadium to osobny obwód z własnym trybem myślenia i własnym narzędziem: ![[cord-pionowo.svg]] **1. [[#Collect: obwód pamięci|Collect — obwód pamięci]].** Zarejestrować wszystko, co przychodzi — natychmiast, bez struktury i bez oceny. **2. [[#Organize: obwód strukturyzacji|Organize — obwód strukturyzacji]].** Zamienić zebrane w ustrukturyzowany backlog: sformułować, oprzeć na źródłach, zdekomponować. **3. [[#Review: priorytetyzacja backlogu|Review — priorytetyzacja backlogu]].** Skonfrontować i wycenić kandydatów; wybrać, co idzie do pracy, co czeka, co umiera. **4. [[#Do: rozlewanie po sprintach|Do — rozlewanie po sprintach]].** Zamienić wybranych kandydatów w zadania i rozlać je po sprintach do pełnej pojemności. > [!warning] Zasada osobnych slotów. > Czterech obwodów nie wykonuje się za jednym podejściem. To różne tryby myślenia: zbieranie — rozproszenie, strukturyzacja — analiza, priorytetyzacja — strategia, rozlewanie — tetris pojemności. Zmieszasz — dostaniesz „zobaczyłem notatkę → od razu wrzuciłem zadanie do sprintu", czyli chaos, który przeciekł na taśmę obok wszystkich filtrów. Każdemu obwodowi — osobny slot czasowy, a najlepiej osobny dzień, jak w kalendarzu tygodnia na początku rozdziału. #### Collect: obwód pamięci Obwód pamięci żyje poza taśmą — w prywatnym **Memory Trackingu**. Grafik szefa to calle, zmiany kontekstu i gaszenie pożarów; task trackery są zbyt ociężałe do błyskawicznej rejestracji. Rejestracja odbywa się w obwodzie prywatnym: notatki dzienne (jedna notatka = jeden dzień, chronologia zamiast hierarchii — mózg świetnie przypomina sobie kontekst po zaczepieniu w czasie), agenci AI sami zaciągają transkrypcje i podsumowania calli, a niewykonane checkboxy ze wszystkich dni plugin zbiera w jedną dynamiczną listę — bez ręcznych przenosin. Wychodzi „dobrze udokumentowany syf" i do rejestracji to format idealny: celem obwodu jest niczego nie zgubić, niczego przy tym nie strukturyzując. **Granica obwodów i zasada śluzy.** Memory Tracking kończy się tam, gdzie zaczyna się praca zespołu: gdy tylko w prywatnych notatkach pojawia się zadanie, które ma wykonać **inny człowiek**, natychmiast opuszcza notatki i trafia na taśmę jako zadanie SMART — nie czekając na planowy Review. Pełne porównanie obu obwodów — narzędzia, zawisłe zadania, pułapka all-in-one i to, co mówi rynek — w artykule [[Publish/Artykuły/Task Tracking vs Memory Tracking|Task Tracking vs Memory Tracking]]. #### Organize: obwód strukturyzacji Zebrane jest rozbierane: notatki łączą się w graf, myśli grupują się w pomysły, pomysły — w szkice projektów i ticketów. Wyjście obwodu — **ustrukturyzowany backlog**: encje z celami, granicami i połączeniami, ale jeszcze bez zobowiązań. Obwód pracuje trzema warsztatami: formułowaniem, źródłami informacji i dekompozycją. ##### Formułowanie projektów Przed produkcją projekt przechodzi cztery kroki: **Postawienie celów.** Określa się metryki i jakości, przy których projekt uznaje się za udany. Cele projektu wynikają z celów biznesowych klienta (lub własnego biznesu). **Kaskadowanie i produktyzacja.** Cele rozbija się na podcele i ubiera w opakowanie konkretnych produktów. Przykład: „Przyprowadzić 300 leadów" → określić grupę docelową i wartości → zaprojektować lejek → przygotować landing w Instagramie → wydać 12 000 zł na targetowanie. Produktyzacja: „landing w Instagramie" → „pakowanie profilu (9 postów, 5 highlightów, opis) za 4000 zł". **Zarządzanie oczekiwaniami: [[Definition of Done|DoD]].** Zbiór kryteriów, po których spełnieniu rezultat uznaje się za „zakończony". Najważniejsze w DoD jest nie to, co zostanie zrobione, lecz to, czego **nie będzie** — ta granica zabija 80% przyszłych konfliktów i darmowych dorabiań. Definicja, różnica wobec planu i przykład dialogu granicznego — w nocie [[Definition of Done]]. **Karta projektu: [[Terms Of Reference|TOR]].** Wynik formułowania spisuje się w lekki TOR (Terms of Reference) — jedną stronę z czterema blokami: co ma zostać osiągnięte (cele, zakres, produkty), kto bierze udział (role i odpowiedzialności), jak (zasoby, budżet, jakość) i kiedy (dekompozycja, harmonogram) — plus ryzyka i ograniczenia. Dokument podpina się do karty projektu w [[#2.1. Warstwa kontekstów: projekt, ticket albo proces|warstwie kontekstów]]: od tej chwili każdy spór o zakres ma arbitra, a estymacje i dekompozycja mają na czym stać. ##### Dekompozycja zadań Projekt jest dzielony na zadania, zadania są wprowadzane do systemu i dostają sformułowanie [[Publish/Kompendium/S.M.A.R.T.|S.M.A.R.T.]] Dekompozycja jest gotowa, gdy: - [ ] podział przestrzega zasady [[MECE]] — bez nakładek i bez dziur (to najważniejszy punkt tej listy) - [ ] każde zadanie jest powiązane z dokładnie jednym kontekstem - [ ] każde zadanie ma dokładnie **jednego wykonawcę** (etatowego lub outsourcing) - [ ] terminy produkcji nie przekraczają jednego sprintu - [ ] wskazane są liczby produktów [Plan] oraz ceny i koszty (jeśli dotyczy) - [ ] akceptacje wydzielono w osobne zadania - [ ] wśród zadań są zadania dla klienta i zadania dla menedżera - [ ] sformułowania przechodzą filtr [[Publish/Kompendium/S.M.A.R.T.|S.M.A.R.T.]] Drobne ToDo żyją jako podzadania: bez pieniędzy, estymacji i analityki — tylko wykonawca, status, termin. Dwa narzędzia z checklisty zasługują na rozszyfrowanie: > **[[MECE]]** — podział bez nakładek (ME) i bez dziur (CE): każdy element trafia dokładnie do jednego koszyka i żaden nie zostaje bez koszyka; dzielić najlepiej na 2–5 części, optymalnie na 3. > **[[Publish/Kompendium/S.M.A.R.T.|S.M.A.R.T.]]** — filtr sformułowania: konkretny rezultat, obiektywna miara sukcesu, osiągalny i realistyczny bez nadgodzin, ograniczony w czasie; zdrowa norma osiągania ambitnych „celów-wyzwań" to ~70%. #### Review: priorytetyzacja backlogu Backlog jest przeglądany: każdy kandydat przechodzi konfrontację z żywym systemem i dostaje wycenę, a na końcu zapada wybór — co idzie do pracy w najbliższych sprintach, co czeka, co umiera. Wyjście obwodu — krótka lista kandydatów. ##### Konfrontacja na pięciu poziomach Kandydat — nowy element albo pozycja backlogu — konfrontuje się z istniejącym kontekstem na pięciu poziomach: | Poziom konfrontacji | Kontekst istniejący | Nowe zadanie | Narzędzie | |---|---|---|---| | Priorytety | Priorytety pozostałych zadań | Priorytet nowego | — | | Zasoby | Zaplanowane obciążenie projektowe + zarezerwowany czas procesowy | Ocena, skład i estymacje nowego | Dekompozycja [[MECE]]; dane do delegowania (kompetencje i obowiązki współpracowników, ich dostępność, możliwości finansowe i budżety); porównanie z podobnymi zadaniami z doświadczenia | | Sformułowanie | Cele nadrzędne | Cele i kryteria sukcesu nowego | [[Publish/Kompendium/S.M.A.R.T.\|S.M.A.R.T.]] | | Połączenia | Istniejące zadania powiązane | Zależności nowego od innych | — | | Oczekiwania | Oczekiwania wobec projektów w toku | Oczekiwania wobec nowego zadania | Sformułowanie [[Definition of Done\|DoD]] | Poziomy karmią się nawzajem od dołu do góry: sformułowane oczekiwania precyzują cele i kryteria sukcesu, cele określają skład i estymacje, skład pozwala uczciwie zważyć priorytet. Pominięty poziom to zadanie, które niepostrzeżenie łamie cudzy plan. ##### Estymacja czasu Każde zadanie etatowego wykonawcy dostaje estymację w godzinach. > Dwie myśli do zapamiętania: > **1) Nie zgadniesz pracochłonności, ale masz obowiązek próbować.** > **2) Każda postawiona estymacja, nawet słaba, jest lepsza niż całkowity brak estymacji.** Techniki estymacji: dane historyczne; głęboka myślowa dekompozycja zadania do drobiazgów; zaczepienie w dniu („ile takich zadań realnie da się zrobić w jeden dzień?"); zapytać wykonawcę (można osobnym callem 1-na-1 po wszystkich estymacjach następnego sprintu). Estymacja pełni dwie funkcje. Po pierwsze, to autotest zarządzania: [Plan], który później spotka się z [Faktem]. Po drugie, to **rekomendacja dla wykonawcy** — ograniczenie, ile wolno siedzieć nad zadaniem. Mała estymacja znaczy: oczekujemy szybkości, poświęcamy perfekcjonizm. Bez ograniczenia wykonawca spędza tyle czasu, ile chce — czasem kosztem innych zadań i rentowności. #### Do: rozlewanie po sprintach Kandydaci stają się zadaniami z wykonawcami, ramami i estymacjami — opuszczają obwód prywatny i wchodzą na zespołową taśmę przez [[#2.2. Wejście do systemu: formularz, tickety, pomysły|bramkę]]. Zadania rozlewa się po sprintach tak, żeby wypełnić pojemność ludzi i dotrzymać zobowiązań terminowych. Pojemność liczy się od góry w dół: ``` 40 h — tydzień pracy − 5 h — przerwy obiadowe → 35 h realnej pojemności − 4 h — synchronizacja i komunikacja → 31 h czasu produkcyjnego (calle, spotkania, sprawy wewnętrzne — obowiązki niezbędne, ale nieproduktywne) ``` W czas produkcyjny nalewa się zadania projektowe według estymacji, aż pojemność się wypełni. Reszta idzie do innych ludzi, do następnego sprintu albo na outsourcing. Zadania prawie zawsze da się dzielić: „8 scenariuszy w 6 h" → dwa zadania „4 scenariusze w 3 h"; „Strategia" → „Bloki 1–3" i „Bloki 4–6". Głównym narzędziem rozlewania jest [[#4.2. Ekrany kontrolne|dashboard obciążenia]]. Zasady wypełniania: - Bieżący i następny sprint — na **100%** pojemności (ani mniej, ani więcej). - Sprinty za 2+ tygodnie — z buforem **15–20%** na nieuniknione wrzutki. - Jeśli wewnętrznych zasobów nie starcza na deadline — outsourcing albo renegocjacja terminów, ale nie przepełnianie sprintu. Rozlewanie jest gotowe, gdy: - [ ] żadne zadanie nie przecina odcięcia (zero „Błędnych ram" w grupowaniach) - [ ] bieżący i następny sprint każdego etatowego pracownika wypełnione równo na 100% - [ ] sprinty za 2+ tygodnie mają bufor 15–20% - [ ] terminy kontekstów (projektów, ticketów) nienaruszone - [ ] harmonogram uzgodniony z klientem > **Rentowność sprintów jest ważniejsza niż rentowność projektów.** ### 3.2. Sprint: spotkanie koordynacyjne Sprint otwiera jedno spotkanie całego zespołu — w poniedziałek, zaraz po odcięciu. To jedyny moment tygodnia, w którym cała taśma patrzy na siebie naraz; wszystko pozostałe dzieje się asynchronicznie, w systemie i w update'ach. Agenda ma trzy stałe punkty, zawsze w tej samej kolejności: **1. Wyniki poprzedniego sprintu.** Publicznie, po osobach: procent zamkniętych zadań — jakość pracy omawia się osobno, w akceptacjach i na 1-na-1. Ta wąska, obiektywna miara to cała presja społeczna systemu: nikt nikogo nie goni w środku tygodnia, ale każdy wie, że w poniedziałek jego liczba będzie na ekranie. Uczciwość tej liczby gwarantuje [[#3.4. Sprint: naprawa resztek|nietykalność historii]] — właśnie dlatego zadań nie wolno przenosić między sprintami. **2. Resztki.** Ile pracy z poprzedniego sprintu zostało niezamknięte i co z nią robimy: dokończenia wchodzą w bufor bieżącego sprintu, idą na outsourcing albo — jeśli bufora nie ma — skład bieżącego sprintu jest przebudowywany, a decyzja komunikowana od razu, przy wszystkich, nie cichcem w środku tygodnia. Mechanika rozdwajania zadań — w [[#3.4. Sprint: naprawa resztek|naprawie resztek]]. **3. Koordynacja styków.** Kto, co, kiedy i komu przekazuje wewnątrz sprintu: tekst do designera, kreacje do kampanii, tłumaczenie do publikacji. Zależności są w systemie już od rozlewania — spotkanie służy temu, żeby każdy styk miał świadomych obu uczestników, zanim zamieni się w czwartkowe „czekam na ciebie". Po spotkaniu sprint po prostu jedzie. Wykonawca żyje na ekranie „[[#4.2. Ekrany kontrolne|Moje zadania]]", pracuje pod timerem według [[#5. Regulamin: zasady gry dla zespołu|regulaminu]], a sytuacje nadzwyczajne obsługują [[#5.5. Procedury wyjątków|procedury wyjątków]] — nie dodatkowe spotkania statusowe, których w tym systemie nie ma wcale. ### 3.3. Sprint: rejestracja i bilansowanie czasu Warstwa faktu powstaje w dwóch taktach: **rejestracja** w trakcie sprintu, **bilansowanie** — po odcięciu. Trzymają ją dwie idee: > **Fakt wpisuje się na koniec każdego zadania.** Zamykając zadanie, wykonawca od razu wpisuje faktyczne nakłady czasowe — Czas [Fakt] — póki kontekst jest świeży. W tle pomaga timer ([[#5.1. Regulamin całościowy: zasady i zakazy|regulamin]]), ale rejestracją jest świadomy wpis człowieka przy zamknięciu, nie surowy log. Zbiorcze wpisywanie faktów w piątek z pamięci to fikcja: po trzech dniach nikt już nie wie, ile naprawdę kosztował wtorkowy baner. > **Suma nakładów musi równać się pojemności.** Sprint dzieli się na zadania według zasady [[MECE]] — bez dziur i bez nakładek — więc suma [Faktów] zamkniętego sprintu powinna wynosić dokładnie 35 godzin (o ile nie było nadgodzin ani nieobecności). Liczy się wszystko, co pochłania pojemność: zadania projektowe, spotkania, cykliczne, synchronizacja — nie tylko czas produkcyjny. Bilans, który się nie zgadza, to nie „taka specyfika tygodnia" — gdzieś jest błąd: niezarejestrowana praca, przeszacowany plan albo zlecenie, które w ogóle ominęło system. **Bilansowanie** — domknięcie tej równości po zamkniętym sprincie — odbywa się w pierwszych dniach nowego sprintu, tak by na środową [[#3.5. Sprint: retrospektywa|retrospektywę]] bilans był gotowy. Buduje się je wywiadem, a napędza iteracyjna logika [[MECE]]: pojemność sprintu jest stała, więc każda korekta faktu w jednym zadaniu natychmiast otwiera pytanie o pozostałe. Godzina „nadmiaru" musi mieć swoje źródło, godzina „oszczędności" — swoje ujście, a praca spoza systemu — własne zadanie. Pętla kręci się, aż suma faktów zejdzie się z pojemnością: > — Baner do kampanii: plan 2 h. Ile realnie? > — Ze trzy — były dwie rundy poprawek. > — Zapisuję fakt 3. Ale tydzień się od tego nie rozciągnął: skoro tu jest godzina więcej, gdzieś musi być godzina mniej. Co poszło szybciej? > — Newsletter. Szablon z poprzedniej wysyłki pasował prawie w całości. > — Czyli newsletter: plan 4, fakt 3 — suma znów się zgadza. Reszta po planie? > — Publikacje tak… Tylko doszła jeszcze godzina na hotfix landinga, tego nigdzie nie ma. > — Zakładam zadanie na hotfix, fakt 1 h — i teraz mamy o godzinę za dużo. Co przez ten hotfix nie dostało swojej godziny? > — Czwartkowa publikacja, poszła z gotowego szablonu. Pół godziny zamiast półtorej. > — Zapisuję fakt 0,5. Suma: 35 na 35 — bilans domknięty. Cztery ruchy tego wywiadu to całe bilansowanie: korekta faktu → pytanie o przeciwwagę → ujawnienie pracy spoza systemu → nowe zadanie na nią. Każda odpowiedź zmienia bilans, a każda zmiana bilansu rodzi następne pytanie — aż rachunek domknie się bez dziur i bez nakładek, po wszystkich zadaniach sprintu. Time trackery monitorujące zakładki i aplikacje pomagają, ale nie są konieczne — zbieżność bilansu jest ważniejsza niż laboratoryjna precyzja. Po co ta pedanteria: bilans to jedyny moment, w którym plan spotyka się z rzeczywistością w skali całego tygodnia. Bez niego estymacje nie mają się od czego uczyć, obciążenie na dashboardach jest deklaracją, a analityka z [[#4. Analityka: wysiłek, wynik, pieniądze|rozdziału 4]] kłamie w każdej kolumnie. ### 3.4. Sprint: naprawa resztek > **Resztka** — zadanie z poprzedniego sprintu, niezamknięte na 100%. Zasada nadrzędna: **historia jest nietykalna**. Rozbiór na przykładzie: zadanie „10 scenariuszy, 10 h", zrobiono 8, sprint się zamknął. W zadaniu źródłowym: status **„Odcięcie"** (albo „Almost" — nazwa dowolna, sens jeden: praca ruszyła, ale przerwało ją odcięcie sprintu); Liczba [Fakt] = 8 — i to prawidłowe, że nie zgadza się z planem; Czas [Fakt] = realnie zużyty (może i całe 10 h — pracownik szedł według planu, ale nie zdążył z 2 scenariuszami); **terminów nie ruszamy pod żadnym pozorem** — zadanie zostaje faktem archiwalnym. Na resztę tworzy się **nowe zadanie** w nowym sprincie: Liczba [Plan] = 2, Czas [Plan] = 2 h. Inaczej wygląda zadanie, którego nikt nie tknął: Czas [Fakt] = 0. Ono nie dostaje „Odcięcia" — dostaje status **„Nie rozpoczęto"**, również zostaje w swoim sprincie, a na nowy sprint zakłada się nowe zadanie na całość pracy. Jest przy tym jeden warunek [[MECE]]: zero na zadaniu nie oznacza, że godziny wyparowały. Sprint i tak trwał swoje 35 godzin — skoro nie zjadło ich to zadanie, zjadło je coś innego, i [[#3.3. Sprint: rejestracja i bilansowanie czasu|bilans]] musi jawnie pokazać co: podniesione fakty innych zadań albo nowe zadania na pracę, która ominęła system. „Nie rozpoczęto" bez tak rozpisanych godzin to nie status, lecz dziura w bilansie. I tu domyka się pętla ze schematu: dokończenia **wracają do sprintu** jak każda inna praca — w bufor bieżącego, na outsourcing albo do następnego, zgodnie z decyzją ze [[#3.2. Sprint: spotkanie koordynacyjne|spotkania koordynacyjnego]] i zawsze w granicach limitu pojemności. Resztka to nie kara i nie wyjątek, lecz normalny obieg: historia zostaje nietknięta, a praca i tak zostaje dokończona. Checklista: - [ ] żadne zadanie nie zmieniło swoich terminów produkcji - [ ] zadania rozpoczęte, lecz niedokończone zostały w swoim sprincie ze statusem „Odcięcie" / „Almost" - [ ] zadania nietknięte dostały status „Nie rozpoczęto", a ich godziny są jawnie rozpisane w bilansie po innych zadaniach - [ ] na każdą resztę utworzono nowe zadanie w nowym sprincie Przeniesienie zadania niszczy statystykę: sprint wstecznie „staje się wykonany" i system nie ma już czego leczyć. Rozdwojenie zadania zachowuje i fakt porażki, i drogę do dokończenia. ### 3.5. Sprint: retrospektywa Środa, spotkanie menedżerów — jedyny punkt cyklu, który patrzy wstecz nie po to, żeby rozliczać ludzi, lecz żeby kalibrować system. Na stole domknięty [[#3.3. Sprint: rejestracja i bilansowanie czasu|bilans]] poprzedniego sprintu: dla każdego zadania para Czas [Plan] i Czas [Fakt]. Trzy pytania, w stałej kolejności: 1. **Gdzie plan rozjechał się z faktem najmocniej — i dlaczego?** Krytyczne resztki dostają diagnozę: zła norma, zły brief, wrzutka, przeciążony człowiek. Wnioski od razu stają się korektami estymacji kolejnych sprintów („szablon email to nie 2 h, tylko 4"). 2. **Jaka jest celność estymacji ogółem?** Procent zgodności planu z faktem — po ludziach i po typach pracy — oraz jego trend. Pojedynczy rozjazd to szum; ten sam rozjazd trzeci sprint z rzędu to norma do poprawy. 3. **Co pokazuje [[#4.5. Panel zdrowia systemu|panel zdrowia systemu]]?** Meta-metryki samej taśmy — obowiązkowy punkt każdej retrospektywy. Retrospektywa domyka cykl: jej wnioski wchodzą do piątkowego Review i do rozlewania następnego sprintu. To dokładnie tu system „leczy się sam": każdy sprint odsłania bugi zarządzania, a retrospektywa zamienia je w poprawki norm — co tydzień, a nie raz na kwartał, gdy zrobi się katastrofalnie źle. Bramka na wyjściu — sprint jest zamknięty prawidłowo, gdy: - [ ] każde zamknięte zadanie ma wpisany Czas [Fakt] - [ ] bilans czasu domknięty do pojemności (35 h) - [ ] resztki naprawione według [[#3.4. Sprint: naprawa resztek|zasad naprawy]]: historia nietknięta, statusy nadane, na każdą resztę nowe zadanie - [ ] retrospektywa przeprowadzona, a wnioski ujęte w następnym rozlewaniu Na tych samych liczbach — ale osobno od retrospektywy — opiera się **ocena pracy**: procent zamkniętych zadań ze spotkania koordynacyjnego, celność estymacji po ludziach, dyscyplina bilansu i timerów, jakość z akceptacji. Retrospektywa kalibruje system i nie rozlicza ludzi; ocena rozlicza — ale wyłącznie na danych, które system i tak zbiera, bez ani jednego dodatkowego raportu. Dlatego w kolejności wdrożenia ocena jest ostatnia: włączona, zanim bilans okrzepnie, karze ludzi za szczerość faktów. --- ## 4. Analityka: wysiłek, wynik, pieniądze ### 4.1. Wymiary klasyfikacji [[#2.4. Anatomia elementu: wspólny rdzeń workflow|Wspólny rdzeń workflow]] istnieje po jedno: **każda roboczogodzina automatycznie rozkłada się po wymiarach**: | Wymiar | Pytanie, na które odpowiada | |---|---| | Workflow | Jakim typem pracy jesteśmy zajęci? (publikacje, wysyłki, spotkania…) | | Marka | Na którą markę idzie zasób? | | Charakter | Jaki jest balans strategicznego, operacyjnego, administracyjnego i infrastrukturalnego? | | Pochodzenie | Pracujemy na projekty (rozwój), tickety (reakcja) czy procesy (utrzymanie)? | | Kontekst | Który konkretny projekt/ticket/proces nas zjada? | | Sprint / Miesiąc | Jak to się zmienia w czasie? | | Wykonawca | Kto jest obciążony i czym? | Nikt nie wypełnia raportów ręcznie: klasyfikacja rodzi się w momencie utworzenia elementu, agregaty liczą formuły. ### 4.2. Ekrany kontrolne Dashboardy dzielą się na dwie rodziny o lustrzanej strukturze: - **Overview** — co dzieje się teraz i przed nami: moje zadania, moje „lamy" (zwisające i problemowe elementy), obciążenie, timeline'y po workflow i po ludziach, Gantt projektów. - **Historia** — co już się wydarzyło: rozkłady („Podziały"), Workflow Stats, obciążenie, te same timeline'y i Gantt, ale po zamkniętych sprintach. Lustrzaność nie jest przypadkowa: to samo pytanie („kto czym jest zajęty?") w Overview służy planowaniu, w Historii — retrospektywie. Cztery główne ekrany poniżej; każdy odpowiada na pytania jednej roli, nie więcej. **Ekran 1. „Obciążenie [Plan]" — do rozlewania (menedżer).** Macierz: ludzie × dni, pogrupowane po sprintach. W każdej komórce kółko wypełnienia pojemności z procentem: niebieskie — norma, niebieskie z fajką — dzień skompletowany na 100%, czerwone — przeciążenie (estymacje przekraczają pojemność), kreskowanie — dzień wolny. Menedżer przesuwa i dzieli zadania, aż u każdego człowieka najbliższe dwa sprinty wypełnią się na 100% bez czerwonego. To pulpit roboczy procesu [[#Do: rozlewanie po sprintach|„rozlewania"]]: „Mikita, 214% w poniedziałek" — sygnał, żeby dzielić i przekładać przed startem sprintu, a nie po porażce. ![[Pasted image 20260718194618.png]] **Ekran 2. „Moje zadania" — dla wykonawcy.** Osobisty timeline: wszystkie elementy człowieka ze wszystkich workflow, pogrupowane po taśmach (zadania, publikacje, kampanie SMS, tłumaczenia, spotkania, cykliczne…). Wykonawca widzi swój tydzień w całości i nie musi chodzić po ośmiu tablicach. Jeden ekran = odpowiedź na pytanie „co mam robić dziś i co mnie czeka". ![[Pasted image 20260718195109.png]] **Ekran 3. „Workflow Stats" — statystyka produkcji (menedżer/szef).** Trzy bloki: - *Obciążenie miesięcznie* — słupki roboczogodzin po ludziach z liniami progowymi miesięcznej pojemności (np. 140/160 h): widać przeciążenie i niedociążenie w horyzoncie miesięcy. - *Karty workflow* — dla każdej taśmy: liczba elementów kontra roboczogodziny po miesiącach. Miesiąc, w którym setka uniwersalnych zadań kosztuje ~330 roboczogodzin, a dwie dziesiątki publikacji — ~20, natychmiast pokazuje, gdzie robota sztukowa, a gdzie pożeracz zasobów. - *Obciążenie tygodniowo + rozszerzony timeline* — te same dane w przekroju sprintów i wstęga „człowiek × workflow" kolorami. ![[Pasted image 20260718193834.png]] **Ekran 4. „Podziały" — dla właściciela.** 100-procentowe wykresy skumulowane rozkładu roboczogodzin po każdym wymiarze (marka, charakter, pochodzenie, workflow, kontekst, projekty, procesy) w dwóch przekrojach czasowych: po sprintach i po miesiącach. Odpowiada na pytania poziomu właściciela: która marka zjada zespół i czy uzasadnia to jej przychód; czy dział nie zmienił się w „maszynę administracyjną"; ile procent zasobu idzie na rozwój (projekty) kontra utrzymanie (procesy); jak to się zmienia z miesiąca na miesiąc. ![[Pasted image 20260718193910.png]] ![[Pasted image 20260718193927.png]] ![[Pasted image 20260718194037.png]] Hierarchia czytania ekranów: wykonawca żyje w 2., menedżer — w 1. i 3., właściciel — w 4. Wokół czterech głównych — pomocnicze: **Gantt projektów** (terminy kontekstów), **timeline'y „workflow × czas" i „ludzie × czas"**, **„Moje lamy"** (osobiste zaległości i problemy — samokontrola bez nadzorcy). Wszystkie ekrany karmią się tymi samymi polami wspólnego rdzenia — żaden nie wymaga ręcznego raportowania. ### 4.3. Warstwa wyniku: wysiłek spotyka efekt Wszystko opisane wyżej mierzy **wysiłek**. Ale analityka wysiłku bez analityki wyniku tworzy efektywną fabrykę niepotrzebnego: zespół idealnie mieści się w sprintach, produkując to, co nie rusza biznesu. Domyka się to prosto. Każdy kontekst przy formułowaniu dostał już mierzalne kryterium sukcesu (SMART z [[#Formułowanie projektów|formułowania projektów]]) — leady, zgłoszenia, konwersje, zasięgi, retencję. Zostaje zderzyć je z nakładami: raz w miesiącu — spotkanie „wysiłek × wynik", na stole tabela kontekstów z trzech kolumn: **roboczogodziny | metryka docelowa | fakt**. Dla każdego wiersza jedna z trzech decyzji: skalować (działa — dołożyć zasób), naprawiać (nie działa — zmienić podejście) albo zabijać (nie działa i się nie naprawi — uwolnić godziny). Reguła symetryczna: analityka wyniku bez analityki wysiłku też jest ślepa — pokazuje sukces, ale nie jego cenę. Wartość daje dopiero przecięcie. ### 4.4. Warstwa pieniędzy: od godzin do P&L działu Wszystkie dane do obrazu finansowego już są w systemie — brakuje jednego mnożenia: ``` Koszt własny elementu = Roboczogodziny × Stawka godzinowa + koszty bezpośrednie elementu ``` Stawka godzinowa to **stawka wejściowa** pracownika (godzinowy koszt dla firmy, ze wszystkimi podatkami i daninami) powiększona o **kompensatory czasu niesprzedawalnego** (nieproduktywnego): przerw, spotkań, urlopów i przestojów — mechanika i wzory w [[Kanon pricingu i podziału przychodów dla sektora usług intelektualnych#VI. Kompensatory: jak czas niesprzedawalny trafia do ceny|sekcji o kompensatorach kanonu pricingu]]. Goła stawka wejściowa zaniża koszt własny: godzina produkcyjna musi opłacić także godziny, których sprzedać się nie da. Koszty bezpośrednie już żyją w elementach z minusem: koszt wysyłki SMS, druk, outsourcing. Sumowanie po połączeniach daje koszt własny kontekstu, workflow, marki — „Podziały" w walucie zamieniają się w P&L działu. Jakie decyzje to otwiera: co oddawać na outsourcing (wewnętrzna godzina droższa od zewnętrznej — liczy się, a nie czuje), które procesy automatyzować w pierwszej kolejności (roczny koszt własny procesu kontra cena automatyzacji), jak uzasadniać budżet działu przed właścicielem (nie „dużo pracowaliśmy", lecz „marka X kosztowała was tyle i przyniosła tyle"). ### 4.5. Panel zdrowia systemu System leczy się sam tylko wtedy, gdy ktoś pilnuje metryk samego systemu. Panel meta-metryk to obowiązkowy punkt retrospektywy: | Metryka | O czym sygnalizuje wzrost | |---|---| | % elementów „Błędne ramy" | Zasada odcięcia jest łamana | | % elementów bez kontekstu lub marki | Dziury w klasyfikacji — analityka kłamie | | Udział zadań pozaplanowych | Bramkę obchodzi się bokiem | | Mediana odchylenia fakt/plan | Spada jakość estymacji | | Współczynnik wyprzedzania estymacji po ludziach | Trwały wzrost = inflacja estymacji | | SLA ticketów: mediana „Nowy → W planowaniu" i „→ Gotowe" | Kolejka zgłoszeń degraduje | | Udział ręcznych korekt timerów | Tracking staje się fikcją | Progi każdy zespół ma swoje; ważny jest nie poziom, lecz trend. Dwie-trzy metryki pełznące w górę dwa sprinty z rzędu to powód na osobny punkt retro, a nie na nadzieję, że samo się rozejdzie. --- ## 5. Regulamin: zasady gry dla zespołu Architektura i rytm to strefa zarządzania. Regulamin — publiczny dokument zespołu: jak stawia się zadania, jak z nimi pracować, czego nie robić nigdy i co robić, gdy coś idzie nie tak. Poniżej wersja referencyjna; liczby i role dopasuj do swojego działu. ### 5.1. Regulamin całościowy: zasady i zakazy Regulamin wyrasta z praktyki stopniowo, ale rdzeń mieści się na jednej stronie: siedemnaście zasad, jak pracujemy, i dziesięć zakazów, czego nie robimy nigdy. Zakazy to nie teoria — każdy z nich to realny błąd, który gdzieś już położył wdrożenie. **Zasady — jak pracujemy:** 1. O każdym zleceniu z zewnątrz informowany jest właściciel systemu; zlecenie musi pojawić się w ticketach, nawet jeśli przyszło ustnie, poza formularzem. 2. Niezaplanowanych elementów („nice to have") w systemie nie trzyma się wcale: na tablicach workflow żyje wyłącznie praca zaplanowana, z ramami wewnątrz sprintu. Pomysły „na kiedyś" czekają w backlogu Pomysłów i ramy dostają dopiero przy rozlewaniu. 3. Wielu wykonawców dopuszcza się wyłącznie na spotkaniach; każdy inny element workflow — maksymalnie jeden wykonawca. 4. Zadanie nie może istnieć w dwóch sprintach: zaczyna się i kończy wewnątrz jednego. 5. Plan i fakt żyją osobno, w dwóch kolumnach: Czas [Plan] i Czas [Fakt]. Estymacji nie nadpisuje się realnym czasem — rozjazd między kolumnami to materiał na retrospektywę, nie błąd do zatarcia. 6. Zadanie ma dokładnie jeden kontekst: jeden projekt, jeden ticket albo jeden proces. Jeśli zamknięte zadanie było ostatnią pracą ticketa — zamyka się i ticket. 7. Estymacja to (a) szacowanie czasu i (b) rekomendacja, ile warto nad zadaniem siedzieć. 8. Na własnym zadaniu można przesuwać ramy czasowe wewnątrz sprintu — pilnując deadline'ów z kontekstu. 9. Zadania ad hoc można zakładać sobie samodzielnie, wypełniając: wykonawcę, kontekst (opcjonalnie), ramy, estymację, markę. 10. O urlopach informujemy jak najwcześniej: każdy wczesny anons wydłuża horyzont planowania. 11. Nad zadaniem pracują wyłącznie wskazani wykonawcy. 12. Na czas pracy włącza się timer i status „W realizacji". Jednocześnie może chodzić tylko jeden timer; zmieniłeś zadanie — przełącz timer. 13. Obiad i koniec dnia pracy — wszystkie timery wyłączone. Własne aktywne timery widać na osobnym dashboardzie. 14. Ręczne korekty timera są dopuszczalne, ale widoczne w historii i nie powinny stać się nawykiem. Operacje na timerach cudzych zadań są zabronione. 15. Rezultaty dopina się do zadania: pliki — do kolumny plików, teksty — do update'ów lub tablic dokumentacji; wszystko cyfrowe duplikuje się w magazynie plików działu. 16. Dokumentacja i raportowanie też idą pod timerem. 17. Po zakończeniu: rezultaty i dokumentacja dopięte → Czas [Fakt] wpisany → timer wyłączony → status „Gotowe". **Zakazy — czego nie robimy:** 1. **Nie wdrażamy wszystkiego naraz.** Sprinty bez bilansu czasu to tylko kalendarz, a ocena bez okrzepłego bilansu — toksyczność. Kolejność: rytm → estymacja → bilans czasu → analityka → ocena. 2. **Nie przenosimy zadań między sprintami.** Jedno „małe ustępstwo" — i statystyka martwa; niedokończenia obsługuje [[#3.4. Sprint: naprawa resztek|naprawa resztek]]. 3. **Nie wypełniamy na 100% odległych sprintów.** Bez bufora 15–20% każda wrzutka łamie cały łańcuch. 4. **Nie trzymamy konsultacji, presale'u i rutyny w zadaniach projektowych.** Obciążenie się wykrzywia, analityka kłamie. 5. **Nie liczymy zadań grupowych po jednej godzinie.** Godzina spotkania pięciu osób to 5 roboczogodzin — inaczej spotkania są darmowe i się mnożą. 6. **Nie otwieramy bramki bokiem.** Każda praca obok ticketów i spotkania koordynacyjnego przywraca chaos — najpierw ticket, potem praca. 7. **Nie traktujemy estymacji jak obietnicy.** To hipoteza i rekomendacja; karanie za uczciwy [Fakt] zabija bilans czasu. 8. **Nie szukamy „srebrnej kuli" all-in-one.** Prywatny obwód szefa i zespołowa taśma w jednym narzędziu zamieniają się w ociężałego potwora: notatkom brakuje lekkości, sprintom — rygoru (patrz [[Publish/Artykuły/Task Tracking vs Memory Tracking|Task Tracking vs Memory Tracking]]). 9. **Nie rozmazujemy taśmy po kilku systemach.** Pół pracy w task trackerze, ćwierć w arkuszach, reszta w czatach i „na gębę" — to nie wdrożenie częściowe, lecz brak wdrożenia: bilans nigdy się nie domknie, analityka kłamie dokładnie o niewidzialną część, a bramka przestaje być bramką, skoro obok jest furtka. Obowiązuje „albo całość, albo nic": jeden system, w nim wszystkie workflow i procesy zespołu. (Osobność prywatnego obwodu z zakazu 8 to nie wyjątek, lecz granica dwóch obwodów — każdy jest u siebie kompletny.) 10. **Nie trzymamy systemu na jednym człowieku.** Menedżer samodzielnie prowadzący estymacje, bilans czasu i ocenę to bus factor równy jeden. Role dublujemy, odpowiedzialności rozdzielamy (RACI: osobny A na każdy kontekst), a procesy samego systemu dokumentujemy w bazie wiedzy jak zwykłe procesy: taśma też musi mieć swój SSoT. Zwróć uwagę na proporcję: zasady 1–6 chronią system, 7–10 nie ograniczają, lecz **pozwalają** — dają wykonawcy autonomię wewnątrz sprintu, a 11–17 sprowadzają samą pracę z zadaniem do jednego wzorca: timer, rezultat, fakt. Zakazy pilnują tych samych granic od drugiej strony: niemal każdy opisuje skrót, który wygląda niewinnie, a zabija bilans, statystykę albo bramkę. Dobry regulamin rozdaje wolność równie jawnie jak zakazy. ### 5.2. Odpowiedzialność: macierz RACI i cztery strefy W systemie odpowiedzialność opisują dwie uzupełniające się soczewki: **macierz [[Macierz RACI|RACI]]** (kto pełni jaką rolę w konkretnym zadaniu lub decyzji) oraz **cztery strefy odpowiedzialności** (od pojedynczego zadania po jakość danych w SSoT). **Macierz RACI.** Cztery role przypisywane do każdej aktywności: - **R — Responsible** — wykonawca w workflow: kto realizuje pracę rękami. R może być kilku, jeśli praca jest podzielona między osoby. - **A — Accountable** — odpowiedzialny na poziomie kontekstu (ticket, projekt, proces): dokładnie **jeden** na kontekst. Rozplanowuje i dzieli pracę, podejmuje decyzje i odpowiada za rezultat. Bez jawnego A kontekst „podwisa". - **C — Consulted** — konsultowani przed decyzją: menedżer i eksperci merytoryczni, których zdanie realnie wpływa na kształt pracy. - **I — Informed** — informowani o postępie i rezultacie: zespół, powiązani wykonawcy, właściciel — bez rozdmuchiwania listy. Kto stawia zadania — zależy od typu pracy i kontekstu ([[#5.3. Stawianie zadań|stawianie zadań]]); na pewno jednak **planowanie pracy z ticketów jest delegowane na osoby odpowiedzialne za poszczególne kategorie**: to one są **A** dla swoich zgłoszeń — kwalifikują, priorytetyzują i dzielą pracę w swoim obszarze, zamiast wąskiego gardła u jednego planującego. Przykładowa macierz — aktywności taśmy produkcyjnej w przekroju RACI (nazwy ról dopasuj do swojego działu): | Aktywność | R (wykonuje) | A (odpowiada) | C (konsultowani) | I (informowani) | |---|---|---|---|---| | Realizacja zadania w workflow | Wykonawca zadania | Odpowiedzialny za kontekst | Menedżer / ekspert merytoryczny | Zespół, powiązani wykonawcy | | Rozplanowanie i podział pracy w projekcie/tickecie | Odpowiedzialny za kontekst | Odpowiedzialny za kontekst | Menedżer | Zespół | | Kwalifikacja i priorytetyzacja ticketów | Odpowiedzialny za kategorię | Odpowiedzialny za kategorię | Menedżer | Zgłaszający | | Estymacja i jej korekty | Wykonawca lub menedżer | Menedżer | Wykonawca | — | | Rozlewanie po sprintach | Menedżer / planujący | Menedżer | Wykonawcy | Zespół | | Akceptacja treści | Akceptujący | Odpowiedzialny za kontekst | Ekspert / recenzent | Wykonawca | | Rozwój i utrzymanie workflow | Właściciel workflow | Właściciel systemu | Zespół | Zespół | | Aktualność SSoT | Każdy wykonawca w swoim zakresie | Właściciel workflow / systemu | — | Zespół | Reguła zdrowej macierzy: dokładnie **jeden A** na kontekst, **R** może być wielu przy podziale pracy, a listy **C** i **I** trzyma się szczupłe — inaczej komunikacja puchnie, a odpowiedzialność się rozmywa. Ogólne zasady, algorytm wdrożenia i częste błędy macierzy — w nocie [[Macierz RACI]]. **Cztery strefy odpowiedzialności.** Role RACI rozkładają się nie po jednej drabinie, lecz po czterech równoległych strefach — i każda strefa może należeć do innej osoby: 1. **Odpowiedzialność za zadanie** — realizacja w terminie i z należytą starannością. To rola **R** w workflow. 2. **Odpowiedzialność za projekt/ticket** — rozplanowanie i podział zadań, decyzje oraz informowanie zespołu o postępach i pracach powiązanych. To rola **A** na projekcie lub tickecie. 3. **Odpowiedzialność za workflow** — samodzielny, niezależny proces: optymalizacja i automatyzacja taśm produkcyjnych — statusy, pola, formuły, automatyzacje. To rola **A** na tym procesie. 4. **Odpowiedzialność za SSoT** (Single Source of Truth) — również niezależny proces: utrzymanie i wzbogacanie informacji w [[#2.6. Warstwa baz informacyjnych|bazach informacyjnych]], tak by „jedyne źródło prawdy" naprawdę było i jedyne, i prawdziwe. To także rola **A** na procesie. Strefy 3 i 4 to nie „dodatkowe obowiązki przy okazji", lecz pełnoprawne konteksty typu proces na taśmie: mają swojego odpowiedzialnego, swoje zadania cykliczne i swoje godziny w analityce — system utrzymuje sam siebie tymi samymi mechanizmami, którymi produkuje. ### 5.3. Stawianie zadań Zadania czasami stawia menedżer, czasami sam wykonawca — zależnie od typu pracy i kontekstu. Planowanie pracy z ticketów jest delegowane na **osoby odpowiedzialne za poszczególne kategorie** (A): to one wprowadzają i kwalifikują zgłoszenia w swoim obszarze. Zadania pozaplanowe wprowadza osoba odpowiedzialna za daną kategorię: - **Pozaplanowe pilne** (termin — do końca dnia): wchodzą na tablicę workflow od razu — bez estymacji, ale z ramami wewnątrz sprintu i roboczym briefem. - **Pozaplanowe niepilne**: wchodzą jako ticket do kolejki kwalifikacji — bez estymacji i terminu, z dosłownym opisem kontekstu: od kogo i po co przyszło. Kwalifikuje odpowiedzialny za kategorię (w sprawach spornych — menedżer) na najbliższym spotkaniu koordynacyjnym; zadaniem na tablicy workflow praca staje się dopiero przy rozlewaniu, z ramami i estymacją — zgodnie z zasadą 2 [[#5.1. Regulamin całościowy: zasady i zakazy|regulaminu]]. Wymagania wobec każdego zadania: konkretne, jednoznaczne sformułowanie; właściwa tablica (workflow) i kontekst; terminy wewnątrz jednego sprintu; jeden wykonawca dobrany po kompetencjach. Zadanie bez twardych zewnętrznych deadline'ów i zależności może stać na cały tydzień — wykonawca sam decyduje, w które dni je robi. ### 5.4. Raportowanie tygodnia Raportowanie nie jest doklejone do pojedynczych zadań — to zwykły proces na taśmie, złożony z klocków, które system już ma: **Proces „Raportowanie tygodnia".** W [[#2.1. Warstwa kontekstów: projekt, ticket albo proces|warstwie kontekstów]] żyje proces z odpowiedzialnym (A) i instrukcją w bazie wiedzy — jak każda inna stała funkcja działu. **Zadania cykliczne na piątek.** Do procesu podpięte są zadania cykliczne: każdy członek zespołu zamyka tydzień własnym raportem. Zadanie ma estymację i godziny w analityce, liczone do rezerwy „synchronizacja i komunikacja" — raportowanie to praca, a nie dopisek po godzinach. **Dokument w stylu changelog.** Rezultatem zadania jest raport opisowy — dokument podpięty do zadania (np. doc w [monday.com](https://try.monday.com/work-management-pl)). Pisze się go jak changelog, nie jak wypracowanie — co zmienił ten tydzień: co zostało zrobione i gdzie leży rezultat; odchylenia od planu i briefu; trudności i sposób ich rozwiązania; wpływ na pracę innych (ze wzmianką tych osób); konta założone po drodze i sposób uzyskania dostępu. Zabronione na otwartych tablicach: dostępy i hasła (na nie jest osobne, zabezpieczone miejsce) oraz personalne wycieczki w jakimkolwiek tonie. Po co ten proces: raporty poprawiają estymację, umożliwiają pracę zdalną, pozwalają bezboleśnie zamrażać i odmrażać projekty, wyładowują kontekst z głowy („8 projektów i 400 zadań") i upraszczają ocenę pracy. A że raportowanie jest procesem z zadaniami cyklicznymi, ma odpowiedzialnego, godziny i stałe miejsce w rytmie — zamiast wisieć na dobrej woli piątkowego popołudnia. ### 5.5. Procedury wyjątków Siła regulaminu tkwi nie w opisie idealnego dnia, lecz w gotowych scenariuszach na sytuacje nadzwyczajne. Są cztery: **Procedura „Overtime" — nie mieszczę się w estymacji.** Gdy tylko stało się to jasne — update do zadania z przyczyną i wzmianką osoby odpowiedzialnej za kontekst (A). Odpowiedzialny za kontekst (A) analizuje sprint i wybiera: (a) dociskać zadanie za wszelką cenę kosztem innych albo (b) zamrozić je (status „Problem") do kolejnych sprintów i nie ruszać pozostałych. **Procedura „Proactive" — zamknąłem sprint przed czasem.** Kolejność działań: poinformować osobę odpowiedzialną za kontekst (A) → uporządkować raporty, pliki i dokumentację (zakładając na to zadanie) → przeanalizować wyniki tygodnia i poprawić, co się da → domknąć swoje braki edukacyjne → zrobić pracę przygotowawczą pod zadania następnego sprintu. **Procedura „Trouble" — zadanie niewykonalne.** Milczenie to najgorszy wariant. Działania: update z przyczyną; jeśli blokują zadania kolegów — wspomnieć ich z konkretnym wymaganym działaniem; załączyć ścieżkę rozwiązania; jeśli potrzebna restrukturyzacja — własną wizję procesu. Potem wybrać, jak pracować dalej: według „Overtime" (zużyć przydzielony czas, zamrozić) albo według „Proactive" (zapisać czas faktyczny, zamrozić, uwolnionym czasem rozporządzić według procedury). **Procedura „Timesheet" — nie zbiera się tygodniowa norma godzin.** Albo czas nie został przepracowany (odnotowuje się i odbija w ocenie), albo praca jest niezaewidencjonowana: wtedy analiza timerów tygodnia, sesje ręczne i natychmiastowe dodanie zadań, których nie było w systemie (zlecenia ustne to też naruszenie: powinien był je wprowadzić odpowiedzialny za kategorię). Eskalacja idzie najpierw do osoby odpowiedzialnej za kontekst/kategorię (A); sprawy ogólne i sporne rozstrzyga menedżer. Gdy potrzebny jest menedżer, a jest niedostępny — procedura „Trouble" i najbliższe spotkanie koordynacyjne. ### 5.6. Priorytetyzacja Hierarchia reguł przy konflikcie zadań: 1. Zadania zależne są ważniejsze od niezależnych (tekst, na który w przyszłym tygodniu czeka designer, jest ważniejszy niż tekst samodzielny). 2. Działa jawny ranking projektów (które marki ważniejsze — ustalone zawczasu, a nie w momencie sporu). 3. Zadania z kosztami pieniężnymi i ryzykiem przepalenia budżetu — ważniejsze od zwykłych. 4. Zadania przeciwdziałające stratom reputacyjnym — ważniejsze od zwykłych. 5. Zadania z zewnętrznymi deadline'ami (drukarnia zamyka się na urlop) — ważniejsze od zwykłych. --- ## 6. Jak wdrażać AI do taśmy produkcyjnej AI kusi na taśmie produkcyjnej: szkicowanie contentu, wypełnianie pól, tłumaczenia, podpowiadanie estymacji, składanie raportów z timerów, klasyfikacja przychodzących ticketów. Problem w tym, że o wszystkim decyduje **sposób podłączenia** — czy AI wzmacnia architekturę, czy ją rozsadza. ### 6.1. Dlaczego nie wolno podłączać AI bezpośrednio Cała wartość tego systemu leży w architekturze i jej regułach: jeden kontekst na element, zadanie nigdy nie przecina odcięcia, każda godzina ma klasyfikację, statusy odzwierciedlają cykl życia. Surowy model językowy podłączony wprost do narzędzia (natywne AI task trackera albo bezpośredni konektor/MCP do tablicy) **tych reguł nie zna i nie ma jak ich znać**. Zoptymalizuje się pod „usłużnie coś zrobić", a nie pod „nie złamać niezmienników": założy zadanie bez kontekstu, z ramami na dwa sprinty, w wymyślonym statusie, zduplikuje ticket, wpisze koszt bez minusa. Architektura zostanie zignorowana, a na taśmie zrobi się dokładnie ten chaos, który system miał likwidować. Im większa autonomia takiego prostego połączenia, tym większy bałagan. ### 6.2. Wzorzec: proxy MCP na warstwie automatyzacji Rozwiązanie: **nie dawać AI bezpośredniego dostępu do tablicy.** Między AI a narzędziem stawia się warstwę pośrednią — proxy MCP zbudowane na platformie automatyzacji ([n8n](https://n8n.partnerlinks.io/uijjbums0q6y) albo [make.com](https://www.make.com/en/register?pc=mikitakarney)). AI rozmawia wyłącznie z proxy; proxy rozmawia z narzędziem. ![[ai-mcp-pionowo.svg]] Proxy jest miejscem, w którym **żyje architektura**: to ono zna reguły, waliduje wejście, dopełnia braki i decyduje, które akcje w ogóle są dozwolone. AI dostaje nie „klucze do tablicy", lecz wąski, dobrze opisany zestaw operacji. ### 6.3. Architektura ma być opisana w toolach Sedno wzorca: każde narzędzie (tool) wystawione AI musi **nieść reguły w swoim opisie i schemacie**. Nie „utwórz cokolwiek", lecz operacje z wbudowanymi niezmiennikami: - **Pola obowiązkowe** wymuszone schematem: kontekst (dokładnie jeden), marka, wykonawca, ramy, estymacja. - **Statusy jako enum** — AI wybiera tylko z dozwolonego cyklu danego workflow, nie wymyśla własnych. - **Walidacja odcięcia** po stronie proxy: ramy przecinające odcięcie są odrzucane („Błędne ramy") z komunikatem, zanim cokolwiek trafi na tablicę. - **Zasada jednego kontekstu** i „na akceptacje osobne zadania" — zaszyte w logice, nie w dobrej woli modelu. - **Guardraile uprawnień**: AI może zaproponować element do „Pomysłów", zaszkicować content albo przygotować draft w statusie „Planowanie", ale nie wpycha nic wprost do bieżącego sprintu ani nie zatwierdza akceptacji. Opisy toolów to w praktyce **regulamin (rozdział 5) przetłumaczony na język maszyny**. Im dokładniej opisana jest architektura w toolach, tym mniej miejsca na improwizację — AI funkcjonuje według zdefiniowanych reguł, a nie „jak zrozumie". Dobre opisy zawierają też przykłady poprawnych i błędnych wywołań, żeby model widział granice. ### 6.4. Co oddać AI, a co zostawić człowiekowi Podział prowadzi ta sama logika, co w całym systemie: AI produkuje i klasyfikuje, człowiek zatwierdza i decyduje o zasobach oraz pieniądzach. | Dobre zadania dla AI | Zostaje przy człowieku | |---|---| | Szkic postów SM / SMS / email z briefu | Finalna akceptacja treści | | Generowanie linków UTM, kodów promo, meta-danych | Decyzje o [[#Do: rozlewanie po sprintach\|rozlewaniu]] i pojemności | | Draft tłumaczenia w [[#2.3. Warstwa workflow: taśmy uniwersalne i wyspecjalizowane\|sub-workflow]] | Korekty estymacji wg zasady sprawiedliwości | | Podpowiedź estymacji z danych historycznych | Zobowiązania pieniężne i budżetowe | | Wstępna klasyfikacja ticketa z formularza | [[#5.6. Priorytetyzacja\|Priorytetyzacja]] i [[#5.3. Stawianie zadań\|kwalifikacja]] | | Draft raportu z timerów i update'ów | Rozstrzyganie [[#5.5. Procedury wyjątków\|procedur wyjątków]] | | Podsumowania calli do [[#Collect: obwód pamięci\|Memory Trackingu]] | — | Reguła kciuka: AI wolno **przygotować** i **zaproponować**; **zatwierdza** i **zobowiązuje zasób** człowiek. ### 6.5. Rekomendacja narzędziowa Do budowy takich proxy osobiście polecam **[make.com](https://www.make.com/en/register?pc=mikitakarney) MCP-toolbox**: pozwala szybko wystawić AI wąski zestaw narzędzi z ciasnymi schematami i opisami, ma gotowe konektory do task trackerów i baz, a człowieka trzyma w pętli decyzyjnej. **[n8n](https://n8n.partnerlinks.io/uijjbums0q6y)** to dobra alternatywa dla zespołów, które chcą self-hostingu i pełnej kontroli nad danymi. W obu przypadkach zasada jest ta sama: platforma automatyzacji jest warstwą, na której spisana jest architektura — a AI dostaje do ręki tylko to, na co ta warstwa mu pozwoli. --- ## 7. Załącznik: słownik pojęć | Pojęcie | Definicja | |---|---| | Rytm | Interwał między odcięciami, określający długość sprintu | | Odcięcie | Moment, w którym nie istnieje ani jedno bieżące zadanie | | Sprint | Komórka czasu między odcięciami, w którą wkłada się zadania | | Resztka | Zadanie z poprzedniego sprintu niezamknięte na 100%; rozpoczęte dostaje status „Odcięcie"/„Almost", nietknięte — „Nie rozpoczęto", a na brakującą pracę powstaje nowe zadanie w nowym sprincie | | Estymacja | Planowana pracochłonność; jednocześnie prognoza i rekomendacja | | Rozlewanie | Rozkładanie zadań po sprintach aż do wypełnienia pojemności | | Rejestracja i bilansowanie czasu | Dwutakt warstwy faktu: przy zamykaniu zadania wykonawca wpisuje Czas [Fakt] (rejestracja), a po odcięciu suma faktów jest domykana iteracyjnie do pojemności 35 h wywiadem i logiką MECE (bilansowanie) | | Pojemność | Godziny człowieka w sprincie po odjęciu przerw obiadowych (typowo 35 h); część rezerwuje synchronizacja i komunikacja, reszta to czas produkcyjny | | Synchronizacja i komunikacja | Obowiązki niezbędne, ale nieproduktywne (calle, spotkania, sprawy wewnętrzne); rezerwują ~4 h pojemności każdego sprintu | | Zadanie | Konkretny element pracy do wykonania, zawsze znajdujący się na jednej z tablic odpowiadających konkretnemu Workflow; powiązany z dokładnie jednym Kontekstem (Projekt, Ticket lub Proces) | | Workflow | Przestrzeń przeznaczona do realizacji określonego typu zadań, definiująca ich model danych i proces realizacji; w naszym systemie każda tablica na platformie [monday.com](https://try.monday.com/work-management-pl) odpowiada jednemu Workflow, a zadanie utworzone na tej tablicy biegnie według zasad i etapów właściwych dla danego Workflow | | Wspólny rdzeń workflow | Obowiązkowy zestaw pól, który niesie każdy element niezależnie od workflow; część wspólna, po której różne taśmy łączą się w jeden pulpit, jeden raport i jedną analitykę | | Sub-workflow | Taśma rodząca się z elementów innych workflow, a nie z kontekstów (przykład: tłumaczenia) | | Kontekst | Konkretna jednostka w systemie, np. „Migracja infrastruktury" (Projekt); każdy Kontekst przypisany jest do jednej z trzech kategorii: Projekt, Ticket lub Proces; grupuje i pomaga śledzić pracę wokół danej inicjatywy, zgłoszenia lub stałej funkcji | | Projekt | Strategicznie planowana inicjatywa o zdefiniowanych celach i harmonogramie; stanowi Kontekst dla zadań realizowanych w ramach danego projektu | | Ticket | Zgłoszenie pochodzące z innego działu lub zewnętrznego podmiotu, pojawiające się nieprzewidywalnie co do czasu i liczby; pełni rolę Kontekstu dla zadań wymagających reakcji na konkretne zapytanie lub prośbę | | Event | Wydarzenie (najczęściej offline), organizowane z partnerami; w systemie referencyjnym encja bazy informacyjnej i wyspecjalizowany workflow (Eventy / webinary), a nie osobny typ kontekstu — prace eventowe żyją w projekcie albo procesie | | Pochodzenie | Cecha: praca projektowa (rozwój), ticketowa (reakcja) czy procesowa (utrzymanie) | | Charakter | Strategiczny / operacyjny / administracyjny / infrastrukturalny | | Roboczogodziny | Estymacja × liczba wykonawców + dod. godziny sub-workflow | | [[Definition of Done\|DoD]] | Kryteria stanu „gotowe" — co będzie i, co najważniejsze, czego nie będzie zrobione | | SSoT | Single Source of Truth (jedyne źródło prawdy): miejsce, w którym trzymamy najbardziej aktualne informacje na temat elementów | | [[CORD]] | Cztery obwody planowania: Collect (pamięć) → Organize (strukturyzacja, backlog) → Review (priorytetyzacja) → Do (rozlewanie); każdemu — osobny dzień | | [[Publish/Artykuły/Task Tracking vs Memory Tracking\|Memory Tracking]] | Prywatny obwód szefa: notatki dzienne + AI, cel — odciążenie mózgu i zachowanie kontekstu | | [[Publish/Artykuły/Task Tracking vs Memory Tracking\|Task Tracking]] | Obwód zespołowy: taśma ze sprintami, odcięciami i pojemnością — przedmiot tego przewodnika | | Zasada śluzy | Zadanie dla innego człowieka natychmiast opuszcza prywatne notatki i staje się zadaniem SMART na taśmie | | Inflacja estymacji | Stopniowe zawyżanie planów dla „wyprzedzenia"; śledzona [[#4.5. Panel zdrowia systemu\|panelem zdrowia]] | | Panel zdrowia | Meta-metryki samego systemu: „Błędne ramy", klasyfikacja, celność estymacji, SLA ticketów | | Stawka godzinowa | Stawka wejściowa pracownika + kompensatory czasu niesprzedawalnego ([[Kanon pricingu i podziału przychodów dla sektora usług intelektualnych#VI. Kompensatory: jak czas niesprzedawalny trafia do ceny\|kanon pricingu]]); zamienia roboczogodziny w koszt własny | | Overtime / Proactive / Trouble / Timesheet | [[#5.5. Procedury wyjątków\|Procedury wyjątków]] | ## Myśl końcowa Marketing operations to nie task tracker i nie zestaw dashboardów. To trzy umowy, których pilnuje struktura danych: praca wchodzi do systemu wyłącznie przez bramkę i z klasyfikacją; praca żyje we wspólnym rytmie i nie przecina odcięć; fakt zawsze spotyka się z planem i zmienia plan następny. Cała reszta — tablice, formuły, kółka na dashboardach — to tylko mechanizacja tych umów. Zacznij od rytmu, dodaj bilans czasu, a za miesiąc będziesz mieć system, który leczy się sam w każdym tygodniu.