Як не пропустити цінні ідеї та не потонути в океані ентузіазму

Шаблон повідомлення зворотного звʼязку від команди

На написання цього тексту мене надихнули вже два випадки, коли мені випала можливість поділитись своїм власним досвідом та дієвим інструментом щодо отримання зворотного звʼязку від команди. Я тут в менші мірі розглядаю такі його категорії як "скарга", а більше фокусуюсь на випадках, коли команда генерує пропозиції та ідеї, що спрямовані на покращення діяльності компанії. Це можуть бути пропозиції по зміні бізнес-процесів, необхідності найму додаткових фахівців, запуску нових продуктів чи зміні бізнес-моделі.

Впевнений, що кожний управлінець, який не ігнорує, ба більше - заохочує, появу ідей всередині його команди стикається з численною їхньою кількість. Все б нічого, але більшість цих пропозиції звучать біля кавової машини, не до кінця сформульовані, прораховані та оформлені. Ініціатор, що спілкується та доносить ці ідеї, повірте, впевнений, що його робота завершена. "Я ж подав ідею, вона крута - давайте організовуйте її впровадження". І тут перед управлінцем виникає дилема - опрацьовувати кожну таку ідею чи якісь ігнорувати, в якихось розбиратись більш детально. В результаті частина команди фрустрована, адже "я подав ідею, а вона далі нікуди не пішла. Більше не буду цього робити". Інша частина теж далека від відчуття задоволення, адже управлінець цікавиться ідеєю, але просить більш детально її опрацювати. "Він просто хоче мене завантажити роботою, а моя мета була подати ідею". Саме тому критичною є необхідність систематизувати цю взаємодію, донести до команди необхідність більш ретельно пропрацьовувати кожну пропозицію та надавати її в зрозумілому форматі з чіткими кроками в імплементації. Тут виникає перши дисонанс, адже генерувати ідею - нічого не вартує, якщо ти людина креативна. А от реалізація потребує менш творчих компетенцій: дисциплінованості, вміння фокусуватись та, напевно, найбільш важливої - готовність брати на себе відповідальність.

Рік тому мав честь проходити курс Global security system, яку викладав Марк Войджер в першому семестрі мого навчання в American University Kyiv. Курс, який має неочевидну дотичність до бізнесу надав мені досить глибокі інсайти про комунікацію з командою та отримання пропозиції від неї. В рамках взаємодії групи з Марком ми мали писати так звані position paper. Це свого роду есе, але дуже структурованого формату. Саме формат мене зацікавив найбільше, адже, за словами Марка, його з можливими коригуваннями використовують представники органів державного управління США (звучить круто). Я адаптував формат даного документу до бізнес потреби та описав яким чином регламентована кожна його частина. До цієї статті долучений знімок екрану, який Ви можете використовувати як конструктор для створення свого власного шаблону.

Використання подібного роду стандарту дозволяє управлінцю отримувати чіткі, зрозумілі по формату, короткі пропозиції від своєї команди. Це вже не розмова біля кавової машини чи в авто по дорозі у відрядження. Ні, це більш грунтовна аналітично-продумана робота колективу. Ось пару ключових тез, які я хотів би виділити як "важливі" при впровадженні та подальшому використанні цього інструменту.

Комунікація

Важливо, щоб з командою була проведена ретельна комунікація на тему "чому потрібен стандарт". На жаль, далеко не всі розуміють, яку кількість корисної (і не дуже) інформації отримує керівник зсередини та ззовні. Саме тому важливо, щоб кожен в команді вчився висловлювати та описувати думки стисло з ключовими наголосами та акцентами. Якщо команда це зрозуміє - Ви на правильному шляху, якщо ні - повторюємо комунікацію знову і знову. Тут Вам треба не покора, а співпраця.

Дотримання стандартів

Якщо вказано, що в розділі має бути 2-3 речення, то їх має бути 2-3 інакше подання не читається. Ніяких змін в тексті кольором, підкреслюванням, жирним шрифтом чи списками. Це полегшує Вашу подальшу роботу з документом. Якщо вказано, що в цілому подання має бути до 2 сторінок А4, то більше 2 сторінок Ви також не читаєте.

Вертикальна структура

Структура подання сформована таким чином, щоб управлінець міг зануритись в питання чи окремі пункти настільки, наскільки він хоче це зробити. Якщо він не бачить в цьому потреби - все має бути зрозуміло з першої частини та з частини "Підсумкові рекомендації". Знову ж таки, цей документ не фінальний і у разі прийняття рішення щодо подальшого опрацювання пропозиції ще потрібно буде чимало попрацювати, але... краще до того, як Ваша команда зануриться в нелегку працю деталізації пропозиції непогано мати можливість їй сказати "ок, це цікаво - давайте", або "друзі - це не наш пріоритет". Це значно знизить непотрібне використання ресурсів Вашої команди.

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

Сподіваюсть, мій досвід стане і Вам у нагоді!

#feedback #team #operationaleffectiveness #ideahub