[Intum Dev](https://intum.dev.md) / [Oprogramowanie dla firm](https://intum.dev/oprogramowanie-dla-firm.md)

# [Tablica zespołu — jak ogarnąć kto co robi i dlaczego zadania stoją](https://intum.dev/oprogramowanie-dla-firm/tablica-zespolu-zadania-kto-co-robi.md)

> **Intum** ma wbudowaną Tablicę zespołu z mechanizmem "biorę" i kontrolą obciążenia. Jeśli szukasz gotowego rozwiązania — [przetestuj Intum za darmo](https://intum.pl) i sprawdź jak wygląda zarządzanie zadaniami w zespole bez zbędnych ceremonii.

## Problem: dużo zadań, nikt nie wie kto co robi

Zgłaszasz zadania. Pięć, dziesięć, dwadzieścia. Przypisujesz je do ludzi — albo zostawiasz bez przypisania, bo nie wiesz kto ma czas. Po tygodniu patrzysz i widzisz: połowa nie ruszona, dwa zaczęte ale porzucone, jedno zrobione ale nikt nie powiedział.

Pytasz na standupie: "Kto wziął to zadanie z eksportem?" Cisza. "A kto robi ten bug z fakturami?" "Ja miałem, ale wpadło coś pilnego i zostawiłem".

Brzmi znajomo? Problem nie polega na tym, że ludzie nie pracują. Problem polega na tym, że **nikt nie wie co kto faktycznie wziął na siebie** — i nie ma mechanizmu który to wymusza.

## Przypisanie to nie to samo co wzięcie

Większość systemów do zarządzania zadaniami ma jedno pole: "Assigned to". Manager przypisuje, pracownik widzi. Ale to pole kłamie — bo "przypisane do Kowalskiego" nie znaczy że Kowalski wie, że ma to robić teraz, ani że się na to zgodził.

Są trzy stany których nikt nie rozróżnia:

1. **Sugestia** — "myślę że Ty powinieneś to zrobić" (manager zgłasza)
2. **Deklaracja** — "biorę to na siebie, skończę do piątku" (osoba potwierdza)
3. **Porzucenie** — "muszę to oddać, bo wpadło coś pilniejszego" (z jawnym powodem)

Bez tego rozróżnienia masz wieczny bałagan. Zadania siedzą w statusie "assigned" tygodniami i nikt nie wie czy ktoś je robi, czy tylko ma je na liście.

## Jak to robią inne systemy?

### Jira + Kanban board

Klasyka. Kolumny "To Do", "In Progress", "Done". Człowiek przesuwa karteczkę gdy zaczyna robić. Problem: nic nie wymusza przesunięcia. Połowa zespołu zapomina. Drugie tyle przesuwa do "In Progress" pięć zadań naraz i robi jedno. Jira nie ma pojęcia o tym czy ktoś faktycznie zaczął, ani nie ostrzega że ktoś wziął za dużo.

Brak: limitu WIP per osoba, mechanizmu "oddania" z powodem, rozróżnienia sugestia vs deklaracja.

### Trello

Prostszy Kanban. Lekki, wizualny, przyjemny. Ale jeszcze mniej struktury niż Jira — nie ma SLA, nie ma powiadomień o niebranych zadaniach, nie ma logowania czasu. Sprawdza się dla małych zespołów z dobrą samodyscypliną. Dla reszty — tablica pełna karteczek których nikt nie przesuwa.

### Asana / Monday.com

Ładne interfejsy, dużo widoków (lista, board, timeline). Przypisanie do osoby + deadline. Ale to wciąż ten sam model: manager przypisuje, system zakłada że ktoś robi. Nie ma mechanizmu "biorę" — jest tylko "assigned". Nie wiadomo czy osoba wie, zgodziła się, czy zaczęła.

### Linear

Szybki, zoptymalizowany pod zespoły developerskie. Ma cykle (sprinty), stany, filtry. Lepszy od Jiry w UX, ale ten sam model mentalny: przypisujesz i czekasz. Linear nie pyta "czy na pewno bierzesz?" ani nie ostrzega że masz już za dużo.

### Co im wszystkim brakuje?

**Aktywnego potwierdzenia.** Żaden z tych systemów nie rozróżnia "przypisane" od "wzięte". Żaden nie wymusza deklaracji terminu. Żaden nie ma mechanizmu oddania z powodem. Żaden nie łączy zadań z resztą kontekstu — ticketami helpdesku, emailami, połączeniami VoIP, urlopami zespołu.

W efekcie manager musi sam chodzić i pytać: "Hej, robisz to?" — czyli system jest drogi, a człowiek robi za system.

## Jak powinno to wyglądać?

Dobra tablica zespołu ma pięć elementów:

### 1. Sugestia vs Deklaracja

Dwa osobne mechanizmy:

- **Sugestia** — manager lub zgłaszający proponuje osobę. To nie jest przypisanie — to podpowiedź. Zadanie wyświetla się u tej osoby w sekcji "Sugerowane dla Ciebie" ale nie obciąża jej listy aktywnych.
- **Deklaracja ("Biorę")** — osoba sama klika "Biorę" i opcjonalnie podaje kiedy skończy. Dopiero wtedy zadanie jest naprawdę w toku. Różnica jest wizualna — sugerowane są szare, wzięte są kolorowe.

To zmienia dynamikę. Manager nie musi pytać "robisz to?". Widzi od razu: wzięte czy nie.

### 2. Limit obciążenia (WIP)

System powinien wiedzieć ile zadań ktoś może mieć aktywnych. Jeśli Kowalski ma już 3 zadania w toku i próbuje wziąć czwarte — ostrzeżenie: "Masz już 3 aktywne zadania. Na pewno bierzesz kolejne?"

To nie blokada — to informacja. Człowiek może wziąć, ale musi świadomie potwierdzić. A manager widzi kto jest obłożony, a kto ma wolne moce.

### 3. Oddanie z powodem

Człowiek zaczął zadanie ale musi przerwać? OK — ale system wymaga powodu:

- "Zatrzymane — wpadło pilne zadanie #1234"
- "Oddaję — nie mam kompetencji"
- "Oddaję — nie zdążę przed deadline"

Zadanie wraca do puli z pełnym logiem co się stało. Nie znika w ciszy — zespół widzi że wróciło i dlaczego.

### 4. Pulpit zespołowy

Widok dla managera i całego zespołu — kto co ma, co stoi niezabrane, co oddane:

| Do wzięcia | W toku | Zrobione |
|---|---|---|
| Bug w fakturach (sugestia: Tomek) | Jan: Integracja API, ETA: środa | Logo redesign |
| Nowy eksport (sugestia: Ola) | Ola: Migracja danych, ETA: piątek | Raport Q1 |
| Aktualizacja docs (brak sugestii) | Tomek: Testy regresji, ETA: dziś | Poprawka CSS |

Na pierwszy rzut oka widać: co czeka, kto robi, kiedy będzie gotowe. Bez pytania na Slacku.

### 5. Eskalacja niebranych

Zadanie z priorytetem "pilne" leży w "Do wzięcia" dłużej niż 30 minut? Powiadomienie do zespołu. Godzina? Powiadomienie do team leada. Dwie godziny? SMS do managera.

To łączy się z mechanizmem eskalacji — te same reguły, te same kanały, ten sam łańcuch osób. Nie trzeba konfigurować osobno.

## Jak to działa w Intum?

Intum ma to czego brakuje innym — **cały kontekst w jednym miejscu**. Helpdesk, email, VoIP, CRM, urlopy, zadania. Tablica zespołu w Intum nie jest odizolowanym boardem — wie co się dzieje dookoła.

### Mechanizm "Biorę"

Przy każdym zadaniu przycisk "Biorę" — jedno kliknięcie, jak przypisywanie ticketów w helpdesku. System zapisuje kto wziął, kiedy, i opcjonalnie deklarowany termin.

Zadanie zmienia stan z "Sugerowane" na "W toku". Na pulpicie zespołu widać to natychmiast.

### Sugestia przypisania

Przy tworzeniu zadania możesz zasugerować osobę — ale to nie jest twarde przypisanie. Osoba widzi sugestię i decyduje czy bierze. Jeśli nie weźmie — zadanie jest widoczne dla całego zespołu jako wolne.

To ważna różnica od klasycznego "Assigned to". Sugestia mówi "myślę że Ty", ale nie zamyka drogi innym.

### Kontrola obciążenia

Każdy użytkownik ma widoczną liczbę aktywnych zadań. Przy próbie wzięcia kolejnego — system informuje ile już ma. Manager widzi na pulpicie kto jest obłożony:

| Osoba | Aktywne | Sugerowane | Zrobione (tydzień) |
|-------|---------|------------|--------------------|
| Jan | 2 | 1 | 5 |
| Ola | 3 ⚠️ | 0 | 3 |
| Tomek | 1 | 2 | 7 |

Ola ma ostrzeżenie — 3 aktywne to dużo. Tomek ma 2 sugerowane czekające. Jan ma wolne moce.

### Oddanie i pauza

Przycisk "Oddaję" z obowiązkowym powodem. Zadanie wraca do puli "Do wzięcia" z logiem:

- 10:00 — Jan wziął zadanie
- 14:30 — Jan oddał: "Zatrzymane, wpadł krytyczny bug #4521"
- 14:35 — Tomek wziął zadanie

Historia jest jawna — nie trzeba pytać co się stało.

### Kontekst z helpdesku i VoIP

Zadanie powiązane z ticketem helpdesku? Na tablicy widać że klient czeka. Zadanie powstało z nieodebranego połączenia VoIP? Widać kto dzwonił i ile razy. To informacja której Jira, Asana ani Linear nie mają — bo nie są podłączone do reszty firmy.

### Eskalacja niebranych zadań

Zadania oznaczone jako pilne, które leżą w "Do wzięcia" — automatyczna eskalacja:

| Czas bez wzięcia | Akcja |
|---|---|
| 30 min | Powiadomienie do sugerowanej osoby |
| 1 godz | Powiadomienie do całego zespołu |
| 2 godz | Push + email do team leada |
| 4 godz | SMS do managera |

Te same polityki eskalacji co w helpdesku — konfiguracja w jednym miejscu.

### Automatyczne pomijanie niedostępnych

Sugerowana osoba jest na urlopie? System automatycznie kieruje sugestię do zastępcy lub pokazuje zadanie jako "bez sugestii" — żeby ktoś inny mógł wziąć. Harmonogramy, urlopy, dyżury — wszystko z jednego systemu.

## Porównanie

| Cecha | Jira | Trello | Asana | Linear | Intum |
|-------|------|--------|-------|--------|-------|
| Sugestia vs Deklaracja | Nie | Nie | Nie | Nie | Tak |
| Przycisk "Biorę" | Nie (ręczne przesunięcie) | Nie | Nie | Nie | Tak |
| Limit WIP per osoba | Plugin | Nie | Nie | Nie | Wbudowany |
| Oddanie z powodem | Nie | Nie | Nie | Nie | Tak |
| Eskalacja niebranych | Nie | Nie | Nie | Nie | Tak |
| Kontekst helpdesk/VoIP/CRM | Integracje | Nie | Integracje | Nie | Wbudowany |
| Urlopy/harmonogramy | Nie | Nie | Nie | Nie | Automatyczne |
| Widok obciążenia zespołu | Plugin (Tempo) | Nie | Workload (drogi plan) | Nie | Wbudowany |

## Kiedy to ma sens?

Tabela zespołu nie jest dla każdego. Ma sens gdy:

- Zespół ma więcej niż 3 osoby i trudno ogarnąć kto co robi
- Zadania przychodzą z różnych źródeł (helpdesk, email, klienci, wewnętrzne)
- Część zadań jest pilna i nie może czekać
- Manager traci czas na pytanie "kto to robi?"
- Ludzie biorą za dużo i nie kończą

Nie ma sensu gdy masz 2-osobowy zespół z dobrą komunikacją — tam wystarczy lista zadań i rozmowa.

## Podsumowanie

Problem nie polega na braku narzędzi do zadań — jest ich za dużo. Problem polega na tym, że żadne z nich nie odpowiada na proste pytanie: **kto to faktycznie wziął na siebie i kiedy skończy?**

Przypisanie to nie deklaracja. Status "In Progress" to nie potwierdzenie. A brak informacji o porzuceniu to czarna dziura, w której giną zadania.

Dobra tablica zespołu wymusza jawność — kto wziął, kiedy skończy, a jak oddaje to dlaczego. Reszta to szczegóły implementacji.


---

## Powiązane

- [Jak wygląda dzień firmy, która opiera się na systemie Intum](https://intum.dev/oprogramowanie-dla-firm/dzien-firmy-na-dzialajacej-na-intum.md)
- [Eskalacja w systemach obsługi klienta — jak to działa i jak to zrobić dobrze](https://intum.dev/oprogramowanie-dla-firm/eskalacja-w-systemach-obslugi-klienta.md)