Хронічні хвороби менеджерів — та що з ними робити

Привіт! Мене звати Саша. Працюю РМ ІТ-проєктів. В управлінні проєктами, командами та продуктами вже понад 7 років. В цій статті я поділюсь власним досвідом та спостереженнями про ті софтскілові проблеми, з якими, вірогідно, зіштовхувався кожен менеджер.

Гадаю, що ця стаття буде корисна як менеджерам початківцям або тим, хто тільки збирається стати менеджером, так і менеджерам з досвідом (час від часу корисно повертатись до основ).

Сьогодні хотів би поговорити про «хвороби» менеджерів. Ці хвороби добре відомі, а про способи їх подолання написано безліч статей, книжок, постів у LinkedIn.

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

Що ж це за такі недуги? Насправді вони дуже добре відомі, багато кому навіть з особистого досвіду — багатозадачність, мікроменеджмент і трудоголізм.

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

«Я можу як Гай Юлій Цезар!.. Можливо, навіть краще за нього!»

За легендою, Гай Юлій Цезар міг робити кілька справ одночасно і став «батьком багатозадачності». Ось вже понад 2000 років людство захоплюється тим, як Цезар міг однією рукою писати листи своїм легатам, а іншою переможні реляції до сенату в Рим.

А й справді, хіба це не чудово, робити кілька справ одночасно, економити свій час і бути надефективним?! Тому вже у XXI столітті цезаріанські прийоми підхопили менеджери в різних галузях.

Пам’ятаю, кілька років тому, переглядаючи вакансії, помітив, що серед вимог до менеджера був дуже популярним софтскіл «багатозадачність (multitasking)». На щастя, з часом роботодавці прийшли до усвідомлення, що багатозадачність — це міф.

Річ у тім, що наша увага має обмежений ресурс (ресурсна теорія, D. Kahneman, Attention and Effort, Citeseer, 1973), який ми можемо розподіляти, між «фокусами уваги» поки не вичерпаємо його. Але цей ресурс дуже обмежений, оскільки пов’язаний з робочою пам’яттю. Якщо робоча пам’ять вже заповнена, то додати до неї щось нове буде складно.

Тому, відповідно до ресурсної теорії, можна робити і дві, і три, і навіть десять задач одночасно, але при цьому якість і швидкість їх виконання значно впаде. Чи можна назвати одночасне виконання десяти задач яби як повноцінним виконанням? Очевидно, що ні.

У деяких країнах, наприклад, у Великобританії та Польщі, кермування і одночасне спілкування телефоном заборонено — необхідно користуватись Bluetooth навушниками або іншими варіантами гарнітури hands free. Проте дослідження Університету Юти показали, що навіть такий варіант відвертає увагу водія (дослідження тут: N. Mesgaranietal., ‘Phonetic feature encoding in human superior temporal gyrus’, Science, 2014, 343 (6174), pp. 1005-10 і тут Д. Бернетт, «Наш дивакуватий мозок», Vivat, 2019 ISBN 978-966-942-867-7, cc. 216-218).

У чому принципова різниця між водієм, який спілкується під час керування авто та РМом, який будує фінплан під час зустріч з клієнтом? Загалом, мало в чому. У першому випадку виникає ризик потрапити в ДТП, а в другому — зробити помилку і, якщо не втратити роботу, то отримати неприємності.

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

Однак не варто плутати багатозадачність і паралельність виконання. Наприклад, прокинутись вранці, піти чистити зуби і поставити електрочайник — це не багатозадачність, а паралельне виконання, тобто те, що може виконуватись автономно без значного залучення уваги.

Тому закликаю відмовлятись від «багатозадачності» і намагатись автоматизовувати свою роботу та делегувати деякі задачі. Набагато ефективніше зосередитись лише на пріоритетних задачах, які не можуть бути виконані без вас і є нагальними, ніж намагатись охопити все одразу, бувши залученим у кожен процес.

«Я сам з цим розберусь...»

Ще одна поширена проблема менеджерів — мікроменеджмент. Хронічне і непереборне бажання до залученості та управління кожним процесом в проєкті або команді.

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

Наприклад, бути обізнаним про те, що після регрес-тестування, QA виявив 2 критичних баги і наступний реліз може не відбутись — це нормально. Запитувати у розробників на кожному дейлі, чи проводили вони unit-тести (принаймні, це точно не є задачею РМа) або кожного разу контролювати і перероблювати email вашого ВА до замовника — це мікроменеджмент.

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

По-друге, мікроменеджмент змушує команду відчувати недовіру з боку РМа, вважати, що РМ не бачить у членах своєї команди професіоналів, здатних виконувати проєктні задачі. Тому він все тримає під особистим жорстким контролем.

По-третє, відсутність «helicopter view». Коли глибоко занурений у якусь діяльність, важко вийти за її межі та оцінити загальну картину, що може вплинути на проєктні рішення.

Звідки все ж береться мікроменеджмент?

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

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

Гарна «пігулка» від мікроменеджменту — делегування частини задач колегам. Якщо у вас велика проєктна команда — передайте проведення «1 on 1» зустрічей техлідам і зосередьтеся на роботі з ними. Клієнт попросив скласти для нього план релізів фіч? Попросіть ВА/маркетолога допомоги з аналізом конкурентів. Delivery Manager хоче отримати аналітику багів? Дізнайтесь, чи міг би QA проаналізувати дані із Jira.

Зрештою, менеджмент — це не просто управління «вручну». Це також розуміння, хто з вашої команди може виконати ту або іншу задачу максимально ефективно.

Не забувайте про автоматизацію своєї роботи. Використовуйте відповідні інструменти роботи, які дозволяють вам витрачати менше часу (не обмежуйте себе Excel-табличками). Створюйте шаблони, де це можливо, зрозумілі і прозорі процеси в проєкті: разом з командою дайте визначення DoD та DoR (це також піде на користь інженерній досконалості продукту), застосовуйте фреймворки (Scrum, Kanban).

Опишіть ваші «правила гри»: хто дає апрув на мердж, як відбувається онбординг нових членів команди, хто відповідає за організацію зустрічей, як відбувається репортинг і хто має бути поінформований.

«У мене дуже багато роботи...»

Іноді причиною мікроменеджменту може бути банальний трудоголізм. Нічого хорошого ні від першого, ні від другого очікувати не варто.

РМ — це учасник команди, який часто задає ритм роботи, формує культуру команди і трудову дисципліну. Тому і менеджеру важливо дисциплінувати самого себе. Не варто писати в робочі чати, відправляти листи, призначати «термінові» зустрічі, оновлювати статуси тасок на дошці поза «business hours».

Бувають різні дні, коли купа мітингів впродовж дня, тому часу, щоб зосередитись аби попрацювати з аналізом якихось даних бракує. Уявімо, що у вас був напружений графік протягом дня, ввечері ви вирішили пару годин попрацювати з командними метриками і знайшли кілька ідей як можна їх покращити. Тому вирішили написати команді о 22:00 про це в Slack: «проаналізував наш Lead time — давайте завтра обговоримо». Навіщо?! По-перше, це можуть сприймати як: «я тут знайшов кілька fuck-up’ів, треба поговорити про це, завтра буде розбір польотів». А по-друге, чому це не можна проговорити вранці?

Якщо написати розробнику: «фічу #204 можна готувати до релізу» не пізно ввечері, а наступного ранку, то нічого трагічного не трапиться: сонце не згасне, небо не впаде на землю, океан не висохне.

Згоден, що іноді ввечері попрацювати простіше, ніж вдень. Мій особистий пік продуктивності (кажучи про якусь творчу роботу або аналітику) між 23:00 та 01:00. Проте це мій особистий вибір, який я не «натягую» на команду.

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

Чому такий «трудоголізм» шкідливий для команди? Бо таким чином менеджер формує культуру «працювати багато = працювати добре», котра є прямим шляхом до вигорання команди. Коли команда бачить, що менеджер працює в неробочий час, то це формує підсвідомий сигнал: «Вам також треба! Беріть з мене приклад».

Наостанок про овертайми... Овертайми — це екстраординарний робочий процес, що є відповіддю на екстраординарні події на проєкті, наприклад, необхідно зробити хотфікс. Тому овертайми — це необхідність за певних обставин, а не норма.

Замість висновку

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

Тож ці «хвороби» хронічні, а тому їх не треба запускати, але постійно пам’ятати, чому і як вони шкодять «здоровій» роботі команди і атмосфері на проєкті.