# Список очікування для передач між відділами: простий інструмент для розблокування роботи

> Список очікування для передач між відділами робить видимими приховані залежності, так що засновники можуть бачити реальні затримки та діяти — без додаткових зустрічей або потреби дохтувати команди.

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

## TL;DR
- Список очікування відстежує, що кожна команда чекає від іншої, щоб рухати роботу вперед.
- Він виявляє приховані залежності до того, як вони стануть затримками.
- Використовуйте його щодня, щоб бачити План проти Факт vs Розбіжність у крос-функціональній роботі.

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

**Визначення:** План проти Факт vs Розбіжність — це операційна таксономія, де План — це те, що планувалося, Факт — те, що насправді сталося, а Розбіжність — різниця, що виявляє блокуючі фактори або затримки.

### Як створити список очікування для передач між відділами
Почніть зі створення мапи регулярних передач у вашій компанії. Для кожної передачі запитайте: Що команда А потребує від команди Б, щоб позначити цей крок завершеним? Зафіксуйте ці елементи як записи списку очікування.

1. Перелічте регулярні крос-функціональні передачі (наприклад, продажі до постачання, маркетинг до продажів, продукт до підтримки).
2. Для кожної передачі визначте конкретний вихід або сигнал, який отримуюча команда очікує (наприклад, підписаний контракт, затверджена специфікація, тестове середовище).
3. Призначте власників: команда, яка очікує, оновлює список щодня, вказуючи, чекає на що й від кого.
4. Переглядайте список у вашому щоденному огляді операцій — елементи, що очікують понад 24 години, стають видимими розбіжностями.

> **Порада щодо інструменту (AiAdvisoryBoard.me):** Список очікування безпосередньо впливає на вашу операційну систему План → Факт → Розбіжність. Коли елемент списку очікування довго залишається, це Розбіжність — факт, який власник бачить без потреби дохтувати оновлення.

### Що включати у список очікування
Зберігайте його простим: один рядок на кожен елемент очікування, оновлюється кожного ранку.

- Елемент: Що очікується (наприклад, "підпис клієнта на Фазу 2")
- Команда, яка очікує: Хто потребує це (наприклад, "Команда постачання")
- Команда-власник: Хто контролює вихід (наприклад, "Продажі")
- Дата запиту: Коли почалося очікування
- Статус: Очікується, отримано, або заблоковано

### Добрі та погані приклади
**Добре:** "Очікуємо підписаний SOW від Acme Corp — команда продажів, запитано 1 червня, очікується."
**Погано:** "Очікуємо клієнта" (занадто загально — немає команди, елементу, дати).

**Добре:** "Очікуємо облікові дані API для тесту — команда інтеграції, запитано 30 травня, очікується."
**Погано:** "Очікуємо ІТ" (недостатньо конкретики — створює плутанину, а не ясність).

## Огляд менеджером (приклад digest за 2 хвилини)
- Продажі очікують на затвердження юридичного відділу трьох договорів — розбіжність: 2+ дні
- Постачання очікує на зміни специфікації від продуктового відділу — розбіжність: вирішено вчора
- Підтримка очікує на виправлення інженером проблеми з входом — розбіжність: нова, 18 годин
- Маркетинг очікує на відгуки від продажів для креативів кампанії — розбіжність: немає
- HR очікує на фінансові затвердження численності персоналу — розбіжність: 3 дні, наближається до ескалації

## Мікро-кейс (що змінюється через 7–14 днів)
Компанія SaaS з 45 людьми додала список очікування до своєї щоденної операційної рутини. За тиждень засновник побачив, що дві третини затримок виникають через передачі між продажами та постачанням — а не через напругу команд. Зробивши очікування видимими, лідери продажів та постачання почали синхронізуватися прямо по pending пунктам, скорочуючи середній час передачі з 36 годин до 8. Засновник přestáv гадати, де застрягає робота, і почав виправляти саме розбіжності.

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

## FAQ
**Як це відрізняється від списку блокерів?**
Список блокерів фіксує те, що зупинило роботу сьогодні. Список очікування показує, що робота чекає, щоб початися — це проактивно, а не реактивно.

**Хто має оновлювати список очікування?**
Команда, яка очікує, власне оновлює список. Це зберігає чіткість відповідальності та уникає потреби дохтувати оновлення.

**Чи може це жити у Slack або електронній пошті?**
Так — як спільне повідомлення, гілка або документ. Ключовий момент — щоденна видимість, а не інструмент.

**Як часто слід його переглядати?**
Щодня, як частину вашого операційного огляду. Елементи, що очікують понад 24 години, сигналізують про потребу уваги.

**Що робити, якщо команда ігнорує список?**
Почніть з видимості — покажіть список у вашому щоденному оновленні. Свідомість колег часто сприяє дотриманню краще, ніж накази.

Якщо ви хочете системи, яка автоматично виявляє План → Факт → Розбіжність — кожного дня, по всій компанії — дивіться, як працює 7-денна діагностика.
https://aiadvisoryboard.me/?lang=uk

---

Цитуючи, посилайтесь на https://aiadvisoryboard.me/uk/blog/waiting-on-list-for-handoffs-between-departments. Більше статей: https://aiadvisoryboard.me/uk/blog