Шукаємо причини овертаймів в команді: чек-лист для менеджера

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

Розглядайте список як неприоритизированный і не є кінцевим. Ви можете пробувати все нижчеперелічене (у форматі healthcheck) або застосовувати при аналізі проекту на ретроспективах або інших зустрічах, щоб визначити конкретні кроки більш предметно.

Процес складання/оновлення розкладу проекту

Можливо, сама перша область для аналізу. Коли ви думаєте про понаднормової роботі, це завжди питання контролю виконання проекту і, як наслідок, розбіжності між планом і фактом. Так чому б не почати з точки створення цих планів?

Логічно, що менеджер проектів повинен розбиратися не тільки з метриками та інформацією, але і з процесом як таким. Нижче представлений ряд питань для перевірки:

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

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

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

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

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

Опрацювання змісту проекту

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

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

Якщо ви стикаєтеся з проблемою опрацювання змісту, можна скористатися наступними запитаннями:

Існує процес управління змінами в проекті?
Поінформовані всі учасники проекту про те, яким чином обробляються зміни в проекті?
Є на проекті steering committee? Прописана його роль у вирішенні конфліктів, пов'язаних із змінами в змісті?
Як виглядає сесія product backlog refinement, якщо вона є?
Які обов'язки та роль власника продукту, якщо такий є?

Грунтуючись на своєму досвіді, виділю найбільш часто зустрічаються проблеми:

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

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

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

Управління вимогами

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

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

Усім залученим працівникам відома мета проекту/бачення продукту?
Використовуються гнучкі цілі при побудові дорожніх карт? Як вони формулюються?
Яка документація використовується для трасування вимог?

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

Управління залученням зацікавлених сторін

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

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

Щоб визначити проблему такого характеру, достатньо кілька разів направити клієнта в русло грамотно побудованого процесу і подивитися на наслідки. Так ви зможете відповісти собі на два питання:

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

Крім зацікавлених сторін всередині вашої компанії, необхідно піддати ретельному аналізу зовнішніх стейкхолдерів. Ви можете скористатися наступними питаннями, щоб визначити, в якому стані знаходиться робота із зацікавленими сторонами на проекті:

Чи існує список всіх зацікавлених сторін проекту?
Існує градація зацікавлених сторін проекту? На що вона впливає?
Використовуються просунуті моделі аналізу стейкхолдерів (матриці, когнітивні карти)? Якщо так, яким чином ці артефакти оновлюються?
Яким чином збирається зворотній зв'язок від зацікавлених сторін?
Який зараз рівень задоволеності різних стейкхолдерів від проекту? Які останні дії зроблені для зміни цього показника?

Найбільш поширені практичні проблеми:

Команда не знає всіх стейкхолдерів, крім спонсора проекту («Ми працюємо з цим власником продукту»).
Взаємозв'язки між різними групами стейкхолдерів не аналізуються.
Репортинг здійснюється шляхом додавання всіх зацікавлених осіб копію листа (більше 15 осіб).
Зворотній зв'язок по проекту або його результатами збирається тільки з малої частини зацікавлених сторін, частіше всього з однієї людини.

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

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

Взаємні поступки

Взаємні поступки (кращий переклад trade-offs, який мені вдалося придумати) можуть ставитися до всіх перерахованих вище областях. У широкому сенсі я відношу взаємні поступки до частини роботи із зацікавленими сторонами, так як найпоширеніший trade-off — це співвідношення бізнес-завдань і технічних задач. Згадайте, наприклад, як визначається довжина спринту в Scrum: одним з критеріїв є як раз trade-off між бізнесом (якому потрібно побільше і швидше) і технологією (потрібно подовше робити і поменше розпорошуватися).

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

Скористайтесь наступними питаннями:

Використовується на проекті поняття технічного боргу? Всі ознайомлені зі змістом?
Яким чином команда проекту керує технічним боргом (візуалізація, моніторинг, репортинг та інше)?
Включена робота над технічним боргом в порядок денний сесій планування?
Яким чином ведеться пріоритизація завдань з урахуванням накопиченого технічного боргу?
Яким чином технічні завдання включаються в список робіт? Наскільки сильно пручається бізнес і наскільки команда здатна комунікувати потреби?
Чи включають дорожні карти проекту роботу над технічними enablers?

Приклад з практики. Після чергового релізу і відсутність бюджету команда кілька днів в авральному порядку вирішувала завдання технічного боргу. При аналізі ситуації з'ясувалося кілька речей. По-перше, клієнт не був tech-savvy, і роботи по роз'ясненню того, з яких елементів може складатися бэклог , з ним ніколи не проводилися. По-друге, в команді був відсутній definition of done, щоб працювати з очікуваннями клієнта щодо готовності нової функціональності. Отже, спочатку на черговому огляді спринту підняли питання про те, що більшість зворотного зв'язку від клієнта повинно бути марковано як «технічний борг».

Наприклад, виникли питання до швидкодії системи. Замість створення безглуздих карток типу «я, як система, хочу працювати швидше» (так-так, таке, як виявилося, на проекті бувало) внесли помітки, щоб відрізняти завдання, пов'язані з технічним боргом. По-друге, трохи пізніше розробили і затвердили definition of done, окремим пунктом якого стало: «Не створено технічного боргу, або створений елемент технічного боргу зі складністю не більше 5 сторі-пойнтів». Команда перестала працювати над ним понаднормово і зробила великий крок на шляху до zero debt policy.

Система показників

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

Пропоную звернути увагу на наступні аспекти:

Впливають проектні метрики на співробітника безпосередньо (перегляд зарплати, отримання відпустки та інше)?
На які області проекту спрямовані метрики? Спрямовані вони на співробітника, команду, проект у цілому?
Кому і як репортятся проектні метрики?
Які рішення приймаються на підставі проектних показників?
Хто має доступ до проектних метрик?

На практиці часто зустрічаються такі випадки:

Проектні метрики використовуються для перформанс-рев'ю окремого співробітника.
Проектні метрики спрямовані на відстеження індивідуальної ефективності членів проектної команди.
Проектні метрики занадто складні або їх занадто багато, так що вони інтерпретуються некоректно по відношенню до членів команди.
Граничні значення проектних показників завищуються з метою «підстьобнути» команду.

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

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

Замість післямови

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

Опубліковано: 18/11/19 @ 11:01
Розділ Різне

SEO Блог