[Текст опублікований за підтримки Work.ua — сайту із пошуку роботи №1 в Україні]
Про управління проектами написали безліч книг, проте більшість з них — теорія, відірвана від реальності. Часто стається так, що методи, які працюють на папері, неможливо застосувати в житті. Тому загальні поради я замінив прикладами з реального проекту, у якому нещодавно брав участь. Щоб уникнути звинувачень в рекламі бренду, я навмисне не називатиму клієнта. Але, повірте, ця історія — не вигадана, а всі збіги — не випадкові.
Що таке робоче пекло?
З дитинства усі пам’ятають байку Івана Крилова «Лебідь, рак та щука». Ця байка — чудова ілюстрація того, як відсутність загального розуміння завдання, егоїзм виконавців й невизначена мета стають причинами провалу всього проекту.
У сфері замовної веб-розробки така ситуаціє стається часто: виробництво (розробники й дизайнери), клієнт та керівник проекту тягнуть одну справу в різні боки. Не важко уявити, що може зробити така неузгодженість навіть з найперспективнішим проектом.
Інший вияв підвищеної температури робочого процесу — величезна кількість завдань, серед яких не визначають пріоритетних. Усі завдання, на думку виконавця, надзвичайно важливі та термінові. Як наслідок — жодного із завдань не виконують на належному рівні, а працівник перебуває в постійному стресі.
Ще одна ознака — відсутність мети. Людина не розуміє, чого вона прагне й чим має завершитися проект. Так виникає ситуація, коли завдання не мають критеріїв готовності. Працівник опиняється у ситуації нескінченної щоденної рутини.
В результаті учасник проекту вирішує питання на свій розсуд, сидить у задачах, не розуміючи, до чого вони ведуть. Співробітник ніби й щось робить, а результату немає.
До чого призводить постійне пекло в роботі?
Пекло дорівнює вигорянню. Підсумок неструктурованої роботи — зниження активності, працездатності й зацікавленості виконавця. До вигоряння схильні як окремі працівники, так і загалом уся команда проекту— негатив одного працівника швидко передається іншим.
Звичайно, не для всіх керівників настрій команди має важливе значення, якщо проект все одно реалізують. Але вигоряння практично завжди веде до порушення термінів. Секрет в тому, що чим ближче завершення проекту (якщо ці обриси все ж можна розгледіти), то більше хочеться розслабитися.
Ще одна поширена причина проґавлених дедлайнів — великий обсяг неструктурованих завдань. Це тисне на всю команду й заважає зазирнути дещо наперед, щоб вибудувати пріоритети. Це теж веде до вигорання.
У результаті маємо негатив з усіх боків: клієнт не бачить результату, команда не бачить сенсу, а менеджер щодня пропускає через себе десятки різних завдань не свідомо, а на автоматі. Навіть відпустка не допомагає — фахівець повертається до того ж пекла, яке тисне ще більше. Що ж робити?
Як не жити в пеклі?
Саме з такою ситуацією зіткнулася моя команда, коли ми почали реалізовувати проект з аналітики для великого ритейлера будівельних матеріалів і товарів для будинку.
Ось що ми мали: безсистемний потік вхідних завдань від різних департаментів компанії, які не вибудували систем пріоритетів, відсутність чіткої системи роботи, втомлені співробітники, які не розуміють, навіщо вони все це роблять.
Тому з першого дня ми почали глобальну перебудову.
Єдиний фронт роботи. Для початку варто пояснити клієнтові: для успіху проекту йому потрібно включитися в проект. Комунікація «клієнт-підрядник» повинна бути максимально відкритою. Клієнт стає частиною команди: у нього з’являється зацікавленість в результаті, розуміння процесів і можливостей.
Найперше ми разом з представниками замовника об’єдналися в команду й перестали бачити одне одного за принципом «клієнт-підрядник». Ми впровадили scrum-дошку, на яку вносили всі вхідні завдання, спільно розглядали їх й розставляти пріоритети. Ми долучили до процесу всіх постановників завдань з різних підрозділів, щоб не грати в зіпсований телефон. Так у кожного члена команди з’явилося розуміння завдань.
Так ми припинили бути «учасниками проекту» й перетворилися в «командних гравців». Погодьтеся, що навіть символічна зміна статусу підвищує відповідальність і зацікавленість у результаті.
Робочий ритм. Пекло — це не лише величезна кількість завдань, а й постійна відсутність роботи. Одного дня вам не зрозуміло, куди подіти себе від нескінченної кількості запитів, а вже завтра — робити нічого. Такі робочі «гойдалки» призводять до того, що працівник не може виконати важливого завдання в потрібний момент. Робочий процес варто побудувати так, щоб навантаження розподілялося рівномірно.
З беклога (списку завдань) ми брали до тижневого спринту лише таку кількість завдань, яку реально могли виконати. Але як знайти оптимальне завантаження? По-перше, завдяки досвіду. Нам знадобилося 4 тижні, щоб упевнитися — ніхто не перевантажений, але й не простоює. Жоден командний гравець не вигорів, а це означало, що ми на правильному шляху. По-друге, прогноз виконання кожного завдання визначала вся команда. Ми збирали аргументи, погоджувалися або переконували, знаходили золоту середину, з якою погоджувалися всі. Так ми навчилися краще оцінювати свої можливості й брати в спринт максимальну кількість завдань.
Але робочий ритм вибудовується не відразу, важливо бути гнучким і вносити коригування, коли щось йде не так. Наприклад, після трьох спринтів з’ясувалося, що насправді ми робимо тільки 80% завдань, які беремо до роботи.
Ми перебудувалися і надалі точніше оцінювали навантаження, поволі збільшуючи продуктивність команди.
Як налаштувати робочий процес
В технології SMART для створення цілей, які працюють, треба, щоб вони відповідали п’яти принципам:
конкретність (S — specific);
вимірність (M — Measurable);
досяжність (A — Attainable);
значущість або актуальність (R — Relevant);
обмеженість у часі (T — Time-bound).
Після того, як ми означимо фронт робіт і поставимо робочий темп, потрібно витратити трохи часу й підготувати завдання так, щоб заощадити час у майбутньому. Існує три базових дії, які допоможуть привести будь-яке завдання до ладу.
Декомпозиція. Будь-який проект розділяється на завдання такого обсягу, щоб можна було щодня спостерігати динаміку їхньої реалізації. Максимум — один раз на два дні. Якщо завдання займає більше часу, існує ймовірність отримати не той результат.
Наприклад, у нас є завдання — з’ясувати причину відмов від покупки під час оформлення її в мобільному додатку. Ми розклали його на такі завдання: написати технічне завдання (1 день), перевірити реалізацію (півдня), провести аналіз даних (1 день), написати технічне завдання на виправлення логіки додатка (1 день).
Без деталізації ми б почали роботу без її обсягу, що призвело б до неправильного визначення термінів.
Формалізація. Часто найбільша проблема — комунікація. Сенс завдання не передається до кінця і в учасників команди виникає різне розуміння результату. Тому потрібно проговорювати з командою всі невеликі точки руху завдання, чітко розуміти, яким має бути результат роботи. Ця дія допомагає уникнути непотрібних емоційних обговорень, коли час вже втрачено, а потрібного результату немає. Емоції, зрештою, безпосередньо впливають на продуктивність працівників в цілому. Зрозумілі завдання — запорука спокою в колективі.
Пріоритизація. Усі завдання необхідно вибудувати за ступенем важливості. Багато хто розставляє пріоритети спрощено — важливе, середнє, низьке. Але коли завдань багато, як зрозуміти, яке з них важливіше? Пріоритети варто максимально деталізувати.
У кожен спринт ми брали 50-60 завдань. Така їхня кількість на одній лінійці створювала хаос і не дозволяла зрозуміти, яке ж завдання, загалом, важливіше. Тому ми застосовували лінійку пріоритетності від 100 до 10 тис. Це дозволило визначати важливіше завдання навіть серед двох подібних.
Важливо мати людину, яка визначатиме пріоритетність завдань та їхнє потрапляння до спринту. У нашому випадку це був керівник відділу аналітики клієнтів, який розумів діяльність компанії та міг визначити важливість запитів, що надходять одночасно від 8-10 департаментів.
Важливий відступ: під час роботи з беклогом пріоритизацію треба проводити першочергово. Адже завдання надходять у різному стані, частина з них спонтанна, емоційна й відірвана від реальності, деякі стають не актуальними ще до того, як потрапляють в роботу. Розбір кожного завдання — втрата часу.
Не забувайте про гнучкість. Зміни відбуваються постійно, завжди можуть (і будуть) з’явитися нові ввідні. Разом з командою час від часу переглядайте пріоритети завдань. Для цього добре годиться принцип Парето: 20% зусиль дають 80% результату, а інші 80% зусиль — лише 20% результату. Найперше — додавайте завдання, які матимуть користь для проекту.
Командні активності
Навіть щоденні зустрічі на 15 хвилин для обговорення роботи над завданнями знижують ризик дискомунікації. Ще одна з командних активностей — демонстрація результатів роботи безпосередньо виконавцем, а не менеджером. Це залучає виконавця до процесу й підвищує рівень його відповідальності. Корисно проводити ретроспективу — регулярні зустрічі всієї команди проекту після закінчення кожного спринту, де обговорюють проблеми, які виникли, та способи їхнього вирішення.
Наша команда складалася зі співробітників студії, представників компанії-замовника і консалтингового агентства. Звичайно, величезну роль зіграла правильна комунікація та впровадження щоденних активностей. Але також нам вдалося налагодити мікроклімат, де всі учасники згуртувалися й були готові зробити майже все, допомагаючи одне одному й підтримуючи. Потрібно не лише ставити правильні запитання, а й створювати довірливі відносини, отримувати чесні відповіді. Тільки так комунікація приноситиме результат, а не існуватиме для «аби було».
Нещодавно, уже перебуваючи поза проектом, я отримав важливий зворотний зв’язок: нові керівники проекту не цікавляться в учасників команди їхнім настроєм і не стежать за тим, щоб вони були на емоційному підйомі. З власного досвіду знаю, що поганий настрій — ознака того, що незабаром співробітник «згорить». І якщо можна помітити це й виправити на ранньому етапі, зробіть це. До того ж командний гравець знатиме, що завжди може звернутися до вас і чесно обговорити проблеми проекту.
Вибудуваний ритм, проста й зрозуміла комунікація, командна робота —ключові інструменти для того, щоб залишити робоче пекло й досягти у проекті успіху. Я вірю, що у будь-якої історії є альтернативний кінець — десь у паралельній реальності лебідь, щука і рак зрушать віз й привезуть його за адресою.
Оригінал — Костянтин Франгуріді
Адаптований переклад — Віра Курико
Зображення — unplash.com
