Як показує мій власний досвід, не варто намагатися формалізувати комунікацію заради самої комунікації. Потрібно визначити лише те, що необхідне для керованого руху проєкту: хто, кому, коли і в якому форматі передає інформацію та яка дія має відбутися після цього. Саме тоді комунікація в проєктах набирає ваги й стає багаторазово кориснішою.
У традиційному підході для цього часто складають комунікаційний план — окремий регламент або таблицю зі строками та форматами звітів. Проблема починається тоді, коли цей документ стає самоціллю, а не частиною реального бізнес-процесу.
Й, можливо. у теорії це виглядає логічно та послідовно. Але практика демонструє, що такий документ часто перестає відповідати реальному ходу роботи вже майже після перших кроків у проєкті…
Чому так відбувається? Бо комунікаційний план визначає, як люди мають взаємодіяти. Але сам по собі він не забезпечує, що ця взаємодія стовідсотково відбудеться. Як варіант управління комунікацією є фіксація завдань безпосередньо у боксах виконавця й замовника за рахунок їхньої синхронізації, яку дозволяє забезпечити додаток OneBox Network. Але, все одно залишається відкритим питання щодо використання цього інструменту сторонами й однакового сприйняття користі від таких дій.
Виконавець може хоч сторчма ставати й робити все, як домовилися, але замовник може з різних причин ігнорувати наявні сигнали з системи, яку йому ж й впроваджують.
Ми в iCOLOR зазвичай починаємо не з систем, а з процесів. Якщо бізнес-процес взаємодії не продуманий у реальному житті, жоден документ чи таблиця його не врятує.
Де ламається домовленість, комунікаційні правила
Уявіть стандартну ситуацію: згідно з регламентом, щоп’ятниці менеджер надсилає замовнику звіт про статус проєкту. Менеджер підготував документ, відправив його на пошту і поставив собі внутрішню галочку: «Обов’язок виконано».
Але у відповідь — тиша. Замовник відклав звіт через власні термінові справи. Через кілька днів процес зупиняється, бо для наступного кроку потрібне рішення клієнта, а час уже втрачено.
Проблема не обов’язково в чиїйсь помилці. Проблема в самому механізмі: факт відправлення повідомлення ще не означає, що потрібна дія відбулася. Але при синхронізації боксів створюється адресне завдання й сторони не зможуть сказати, що не отримували повідомлення. Тобто, таким чином ми гарантуємо один одному, що зафіксували дію й повідомили про неї. А це вже зовсім інший рівень спілкування й взаємних зобов’язань. Є завдання, тому можна очікувати й реакцію на нього.
Три системні проблеми в організаційній комунікації
- Інформація збирається вручну. Чим більше даних менеджеру потрібно зібрати з пошти, чатів та таблиць, тим більше часу він витрачає не на управління проєктом, а на підготовку інформації про нього. Саме тому краще, коли комунікація в проєктах відбувається через синхронізовані завдання.
- Повідомлення не перетворене на дію. Інформування без цільової дії створює лише інформаційний шум. Повідомлення «Потрібно погодити ТЗ» ще не означає, що ТЗ буде погоджено. Для керованого процесу потрібні відповідальна особа, строк, конкретна дія та зафіксований результат.
- Критичні кроки залежать від людської пам’яті. Якщо критична передача інформації залежить від того, чи згадав працівник написати листа, процес залишається залежним від людського фактора.
Формула керованої комунікації, контроль дій
Комунікаційний план може залишатися документом. Але критичні правила комунікації не повинні існувати тільки в ньому. Якщо від певної дії залежить наступний крок проєкту, це правило має бути частиною самого бізнес-процесу.
Для кожної критичної дії всередині системи має діяти чіткий ланцюжок:
Хто робить → Що саме робить → До якого строку → Де фіксується результат → Що відбувається далі
Що можна налаштувати в OneBox OS, керований бізнес
У OneBox OS такі правила можна налаштувати як частину бізнес-процесу: зміна етапу може запускати потрібне сповіщення, створення завдання або іншу автоматичну дію.
- Для коротких статусів: Замість складних звітів операційний статус зручно зводити до трьох параметрів: Що зроблено, Що з графіком/бюджетом, Що заблоковано (яке рішення потрібне прямо зараз).
- Для автоматичних сповіщень: Залежно від налаштування, зміна етапу проєкту може запускати формування та надсилання короткого сповіщення замовнику через передбачений канал — наприклад, Telegram або особистий кабінет.
- Для завдань-блокерів: Якщо для руху далі потрібне рішення (наприклад, затвердження ТЗ чи доступів), система створює конкретне завдання з дедлайном для відповідальної особи. Процес очікує на зафіксований результат, тому рішення не залишається лише в листуванні.
Приклад: Погодження технічного завдання
- Як буває без процесу: Менеджер пише клієнту в чат: «Подивіться, будь ласка, ТЗ». Повідомлення висить, час іде, проєкт стоїть. За наявності завдання воно синхронізовано з’являється в двох системах, так й починає працювати комунікація в проєктах більш менш належним чином. Етика спілкування – це не про церкву, а про бізнес!
- Як це працює у налаштованій системі: Перехід проєкту на етап «Очікує погодження ТЗ» автоматично створює завдання замовнику зі строком (наприклад, 24 години). Якщо відповіді немає у визначений час, система запускає нагадування або сповіщає керівника про ризик простою. Після зафіксованого позитивного рішення процес може автоматично перейти на наступний етап, якщо така логіка передбачена його налаштуванням.
Що змінюється в роботі
- Прозорість: Актуальний стан проєкту формується з даних процесу, а не збирається вручну перед кожним запитом.
- Контроль: Керівництво бачить не просто повідомлення про проблему, а конкретні незавершені дії, відповідальних і строки.
- Безперервність: Наступний крок процесу не залежить виключно від того, чи згадав хтось відправити повідомлення або нагадування.
Головний висновок: Домовленість сама по собі не виконує процес. Якщо дія критична для проєкту, правило її виконання має бути зафіксоване в бізнес-процесі та мати контрольований результат.
Що зробити далі?
Перед тим як шукати інструменти автоматизації чи переписувати регламенти, перевірте, чи є у ваших критичних комунікаціях не просто домовленість, а керований процес.
Дайте відповідь на 4 базові питання щодо вашого поточного проєкту:
- Чи є чітко визначений відповідальний за кожну критичну дію?
- Чи має кожна така дія фіксований строк (дедлайн)?
- Де саме фіксується підтверджений результат (а не просто факт відправки листа)?
- Що автоматично відбувається в системі, якщо дію не виконано вчасно?
Якщо хоча б на одне питання немає чіткої відповіді, це сигнал перевірити відповідну ділянку процесу: саме там може виникати втрата інформації, затримка або невизначеність відповідальності.
Пройдіть наш Чек-лист готовності бізнес-процесів, щоб виявити слабкі місця у вашій системі взаємодії та отримати базовий алгоритм їх впорядкування, коли комунікація в проєктах страждає. Коли інструменти вбивають сервіс: пастки карго-культу автоматизації
