# Карта залежностей для блokerів: знайдіть приховані зупинки роботи між командами

> Карта залежностей показує, де фактично зупиняється робота між командами — перетворюючи абстрактні скарги на блokerи на конкретні точки передачі, на які власник може вплинути.

- Автор: Ярослав Максимович (Founder & CEO, AI Advisory Board)
- Опубліковано: 2026-10-20
- Оновлено: 2026-10-20
- Джерело: https://aiadvisoryboard.me/uk/blog/dependency-map-for-blockers-that-sit-between-departments

Коли засновник 40-осібної операційної команди сказав мені, що проєкти постійно застрягають на передачах, але ніхто не міг пояснити чому, я зрозумів: ми вирішували неправильну проблему.

## TL;DR
- Карта залежностей показує, де фактично зупиняється робота між командами, а не просто хто зайнятий.
- Вона перетворює абстрактні скарги на «блokerи» на конкретні точки передачі, які можна вирішити.
- Власники використовують її, щоб виявляти системні затримки до того, як вони стануть ненавантом на квартал.

**Definition:** Blocker — це все, що зупиняє прогрес завдання через відсутність вхідних даних, затвердження або ресурсів.
**Definition:** Карта залежностей — це простий візуальний або табличний інструмент, який показує, якої команди або особи треба завершити крок, перш ніж інший може початися.
**Definition:** Передача — це момент, коли робота переходить від одного власника до іншого, часто втрачаючи контекст.

### Як побудувати карту залежностей для блokerів
Почніть зі структурної схеми вашої компанії. Для кожного ключового процесу (наприклад, запуск продукту, адаптація клієнта, виставлення рахунків) перелічте кроки у послідовності. Потім для кожного кроку зазначте:
- Хто відповідальний
- Що їм потрібно з попереднього кроку, щоб почати
- Що вони передають на наступний крок

Це виявляє, де робота застрягає. Маркетингова команда, що чекає на затвердження від юридичного відділу — це не «блoker маркетингу», а пробіл у передачі між маркетингом та правом. Команда розробки, що стоїть через очікування на технічні специфікації — це не «блoker розробки», а відсутність виходу з дизайну.

### Що включати у карту
Зберігайте її легкою. Достатньо однієї сторінки для кожного головного процесу. Включіть:
- Назву процесу (наприклад, «Налаштування нового клієнта»)
- Кроки у послідовності (напр., Продажі → Адаптація → Технічне налаштування → Виставлення рахунків)
- Власника на кожному кроці
- Вхідні дані, потрібні для початку
- Вихідні результати, що передаються
- Типова затримка (напр., «2–3 дні на юридичну перевірку»)

Використовуйте стикери в спільному документі або просту таблицю. Мета — не ідеальність, а видимість.

## Менеджерський скан (приклад 2-хвилинного digest)
- Продажі передають підписаний контракт Адаптації — але Адаптація часто чекає 2+ дні на підписаний SOW від Юридичного відділу.
- Адаптація завершує налаштування, але чекає, поки Dev надасть доступ — Dev говорить, що їм потрібні чіткі специфікації серверів від Інфраструктури.
- Інфраструктура чекає, поки Без затверди правила брандмауэру — Без каже, що отримує запити спорадично, без шаблону.
- Виставлення рахунків чекає, поки Технічне налаштування підтвердить дату запуску — Технічне налаштування каже, що не отримує сповіщення про завершення роботи.
- Підтримка отримує ескалації від клієнтів через відсутні функції — але продуктова команда каже, що ніколи не отримувала передачу нотаток від Продажів.

Кожен bullet показує точку передачі, де робота застрягає. Проблема не в зусиллях — а в відсутності вхідних даних, незрозумілих термінах або відсутності сповіщень.

## Tool tip (AiAdvisoryBoard.me):
> Карта залежностей робить видимим план → факт → розбіжність на рівні передачі. Замість гадувань, чому проєкт запізнюється, ви бачите саме, де факт відхиляється від плану — і якому команди належить наступний крок.

## Мікро-case (що змінюється через 7–14 днів)
Фірма професійних послуг з 60 осіб промапувала процес адаптації клієнта. Вони виявили три передачі, де робота постійно застрягала: Продажі → Юридичний відділ (перегляд контракту), Юридичний відділ → Адаптація (доставка SOW), Адаптація → Технічне налаштування (забезпечення доступу). Кожна пробілка в середньому тривала 1,5–2 дні. Після того, як залежності стали явними та додано прості чек-листи передачі, середній термін адаптації скоротився з 10 днів до 6,5 протягом двох тижнів. Власник припинив гнатися за статусними оновленнями та почав саме виправляти передачі.

> **Примітка до цього кейсу:** Цей приклад illustrative — bazується на типових патернах, які ми спостерігаємо в компаніях з 30–500 працівників. Конкретні числа — округлені наближення поширених діапазонів, а не гарантії.

## FAQ
**Як бути, якщо команди не хочуть ділитися тим, що їм потрібно?**
Формулюйте це як зменшення тріння, а не призначення винності. Питайте: «Що вам потрібно, щоб почати свою роботу без постійного пошуку людей?»

**Як часто треба оновлювати карту?**
Переглядайте її квартально або при великих змінах у процесі. Карта — це живий інструмент, а не разовий артефакт.

**Чи може вона замінити статус-зустрічі?**
Вона зменшує потребу в них. Коли передачі зрозумілі, потрібно менше синхронізацій, щоб розблокувати роботу.

**Якщо блoker знаходиться всередині однієї команди?**
Тоді це не проблема залежностей — це внутрішній workflow або проблема пропускної здатності. Використайте інший інструмент (наприклад, персональний канбан).

**Чи це працює лише для лінійних процесів?**
Ні. Для паралельної роботи мапуйте точки збігу — де кілька потоків мають зійтися, перш ніж перейти до наступного кроку.

## Висновок
Карта залежностей не виправляє блokerи — вона робить їх видимими. Коли ви бачите, де фактично зупиняється робота, ви можете спрямувати зусилля на саму передачу, а не на команду.

Якщо хочете виявити приховані зупинки роботи між вашими командами — подивіться, як працює 7-денна діагностика.

---

Цитуючи, посилайтесь на https://aiadvisoryboard.me/uk/blog/dependency-map-for-blockers-that-sit-between-departments. Більше статей: https://aiadvisoryboard.me/uk/blog