Вибрати сервіс для управління проєктами — це половина справи. Друга половина — зробити так, щоб ним справді користувалися. На практиці багато інструментів так і залишаються «ще одним застосунком», у який заглядають раз на тиждень, а реальна робота продовжує жити в чатах. Нижче — план на перші 30 днів, який допомагає уникнути такого сценарію.
Підготовка: до першого дня
Призначте відповідального за впровадження. Це не обов’язково має бути керівник — підійде будь-який співробітник, який розбирається в процесах і готовий відповідати на запитання колег. Визначте, які проєкти переносите першими, і сформулюйте, що вважатиметься успіхом через місяць: наприклад, усі завдання пілотної команди ведуться тільки в новому сервісі, а щотижневий статус-дзвінок скоротився вдвічі.
Дні 1–7: структура та базові правила
Створіть структуру: проєкти, етапи, стандартні статуси завдань. Не захоплюйтеся — п’яти-шести статусів зазвичай достатньо. Запишіть короткі правила на одну сторінку:
- як формулюється завдання і що в ньому обов’язково має бути: виконавець, строк, опис результату;
- де відбувається обговорення — у коментарях до завдання, а не в особистих повідомленнях;
- хто і коли оновлює статуси;
- як ставляться завдання колегам з інших відділів.
Проведіть півгодинну зустріч, на якій покажете інтерфейс на реальному проєкті, а не на демонстраційних даних.
Дні 8–14: пілотна команда працює тільки в сервісі
Це найважливіший етап. Домовтеся, що завдань поза системою не існує: якщо доручення прийшло в чат, його переносять у сервіс. Керівнику варто подавати приклад — ставити завдання й запитання тільки через інструмент. Збирайте зворотний зв’язок: що незручно, чого не вистачає, які сповіщення дратують.
Дні 15–21: налаштування під реальні сценарії
Скоригуйте структуру за підсумками перших двох тижнів. Підключіть потрібні інтеграції — календар, пошту, месенджер. Якщо в сервісі є облік часу, увімкніть його й домовтеся про правила заповнення. Налаштуйте шаблони для повторюваних проєктів, щоб не створювати завдання щоразу з нуля.
Дні 22–30: підсумки та масштабування
Порівняйте результат із цілями, поставленими на початку. Опитайте учасників пілота: що стало простіше, що складніше. Підготуйте коротку інструкцію для наступних команд з урахуванням знайдених помилок і тільки після цього підключайте інших.
Типові помилки
- Переносити весь архів старих завдань — це захаращує систему з першого дня.
- Налаштовувати всі функції одразу — команда губиться в можливостях.
- Залишати паралельний канал постановки завдань у чатах.
- Не виділяти відповідального — без нього впровадження згасає за кілька тижнів.
Як зрозуміти, що впровадження вдалося
Відчуття оманливі, тому варто заздалегідь вибрати кілька простих показників. Наприклад: частка завдань, поставлених через сервіс, а не в чатах; кількість завдань без виконавця або строку; час, який команда витрачає на статус-дзвінки; кількість активних користувачів за тиждень. Якщо через місяць половина завдань і далі приходить у месенджер, проблема не в сервісі, а в домовленостях — до них і варто повернутися.
Роль керівника
Впровадження майже ніколи не відбувається знизу. Якщо керівник продовжує ставити завдання голосом і в особистих повідомленнях, команда швидко зчитує, що нові правила необов’язкові. І навпаки: коли всі доручення, запитання та рішення з’являються в завданнях, інші підтягуються за кілька тижнів.
Підсумок
Навіть найкраща проджект-менеджер програма не приживеться, якщо люди не розуміють, навіщо вона їм потрібна. Місяць послідовної роботи зі зрозумілими правилами зазвичай дає більший ефект, ніж пошук «ідеального» сервісу. А якщо на етапі пілота з’ясується, що інструмент не підходить, краще змінити його одразу, поки в ньому не накопичилися сотні завдань і звички команди.
Менеджер проєктів маркетингового агентства MAVR.
Читайте також:
