Проєкт «поганий» — що робити та як із цим впоратись
Будь-яку статтю можна зберегти в закладки на сайті, щоб прочитати її пізніше.
Режим читання збільшує текст, прибирає все зайве зі сторінки та дає можливість зосередитися на матеріалі. Тут ви можете вимкнути його в будь-який момент.
У безмежному світі проєктів усі рано чи пізно зіштовхуються з «поганими». Проте що це насправді означає? Не завжди це проєкт, який виходить за межі бюджету чи не вкладається в дедлайни. Часто проблема більш суб’єктивна і прихована за лаштунками командної роботи, комунікацій та цілей основних стейкхолдерів.
Проєкти зі знаком мінус: що робить їх «поганими» для менеджера
Почнемо з того, що недосконалість проєкту може бути відображенням особистого сприйняття, викликаним когнітивними упередженнями. Наш розум схильний драматизувати, коли щось іде не за планом. Брак досвіду, незнання контексту чи нечітке розуміння цілей часто спотворюють наше бачення.
У мене був досвід роботи з банком, коли всі скаржилися на «некомпетентність» працівників клієнта. Це здавалося катастрофою. Однак після ретельного аналізу й налагодження комунікації виявилося, що проблема була у відсутності ясності щодо цілей. Як тільки аналітики отримали чіткі інструкції — бінго! Усе запрацювало.
Проте є й інші випадки. Коли, на перший погляд, усе чудово — метрики виконуються, команди працюють. Водночас основна проблема залишається прихованою. В одному з проєктів команда працювала над масштабованим рішенням, а головний стейкхолдер очікував швидкого прототипу. Роботу довелося припинити.
Тому перед тим, як впадати у відчай через (поганий, ненормальний, жахливий, кепський) проєкт, варто уважно розібратися в деталях і відповісти на кілька запитань.
- Чи розумієте ви цілі й очікування стейкхолдерів?
- Чи є об’єктивні показники прогресу?
- У якому стані команда — натхненна, втомлена чи просто виконує обов’язки?
- Чи відіграють тут роль ваші упередження?
Не такий страшний кейс, як його малюють
Поняття «поганої» роботи суб’єктивне й часто залежить від обставин. Однак є певні об’єктивні ознаки, які вказують на ризики. Наприклад, відхилення головних показників від планових значень або зниження морального стану команди — явні сигнали.
Утім, враховуйте й особисте сприйняття, яке може створити ілюзію, ніби ситуація «іде не туди». Так само нечітке розуміння цілей зацікавлених сторін може породжувати незадоволення результатами.
Завжди намагайтеся змінити те, що можете
Коли маєте справу з проблемним проєктом, важливо зосередитися на аспектах у вашій зоні контролю та компетенції. Якщо ви керівник/менеджер проєкту, то план дій мусить бути таким:
- дізнайтеся реальні цілі, завдання проєкту й інтереси головних стейкхолдерів;
- скоригуйте обсяг і тривалість проєкту;
- оптимізуйте робочі процеси;
- зробіть переоцінку ризиків (якщо є) або запровадьте керування ризиками;
- оптимізуйте чи введіть прозорі та необхідні метрики залежно від обраного фреймворку керування проєктом;
- підвищуйте моральний дух і залученість команди.
Розрулити чи втекти? Три варіанти дій у кризовій ситуації
Є три основні сценарії, якщо на роботі все йде шкереберть.
- Прийняти ситуацію і нічого не змінювати.
Це підхід для тих, хто готовий «пересидіти» в складних умовах, особливо якщо терміни обмежені. Водночас варто пам’ятати: такий план дій не сприяє професійному розвитку.
- Рефлексія та поступове покращення.
Найбільш конструктивний підхід. Важливо оцінити поточний стан ситуації (as is), створити бачення майбутнього (to be) і узгодити його зі стейкхолдерами. План змін повинен містити регулярний моніторинг результатів.
- Покинути проєкт.
Якщо жодна зі стратегій не працює і ви відчуваєте постійне невдоволення, це може бути сигналом, що варто покинути проєкт. Перед цим необхідно встановити чіткі критерії, які визначають час для виходу. Наприклад, досягнення певної головної події (реліз, вихід у продакшн тощо). Важливо також заздалегідь повідомити про своє рішення та коректно передати всі знання команді.
Власний приклад
№1 — коли клієнт усе-таки не правий (роль — менеджер проєктів)
Контекст: мобільний проєкт спершу здавався звичайним. Проте під час онбордингу стало зрозуміло, що в команді є токсичний тімлід. Він уникає відповідальності за провали, перекладаючи провину на команду. Водночас клієнт постійно змінює вимоги перед релізом, що ускладнює публікацію в Apple Store та Google Play.
Рішення: реструктуризація команди, перегляд фінансової стратегії та перерозподіл ресурсів. Після стабілізації процесів, змін у колективі й отримання доступу до керування фінансами виявилось, що проєкт ледь покриває затрати.
Оскільки команда втомилася від нескінченних забаганок та змін, було запропоноване рішення перевести людей на інший проєкт, а цей закрити через нерентабельність. З’ясувалося, що директор департаменту вже деякий час хотів закінчити співпрацю із цим замовником. Тому пропозиція про закриття проєкту була вчасною і знайшла підтримку в керівництва. Це дозволило компанії ефективно перерозподілити ресурси.
Висновки: інколи краще визнати, що не варта справа заходу і спрямувати людей та зусилля на перспективніші проєкти. У цьому випадку фінансова нерентабельність проєкту + втома співробітників стали причинами для закінчення співпраці.
№2 — бюрократична пастка (роль — провідний менеджер проєктів)
Контекст: попри цікаві завдання та розуміння бізнес-процесів замовника, саме бюрократія стала перепоною в реалізації діяльності. Замовник (держструктура) сильно затягував і гальмував процеси через свій внутрішній устрій. Це демотивувало команду та призводило до непорозумінь у спілкуванні.
Рішення: щоб забезпечити кращу взаємодію, менеджер разом із частиною інженерів та аналітиків переїхали до офісу замовника.
Вони брали участь у нарадах і комунікували з основним стейкхолдером напряму. Так вдалося налаштувати живе емпатичне спілкування й отримати відповіді на необхідні запитання. Через пів року все стабілізувалось.
Висновки: по-перше, ніколи не варто поспішати покидати проєкт. По-друге, обов’язково потрібно визначити інтереси всіх зацікавлених сторін: замовник, керівництво замовника, ваша команда, ви, ваше керівництво.
№3 — власна ініціатива в Levi9 (роль — Delivery Director)
Іноді складнощі виникають не лише в зовнішніх проєктах із замовником, але й у внутрішніх ініціативах компанії. У цьому прикладі ділюся двома кейсами, які пройшли певні проблеми на початку, та з плином часу відродилися в успішні ініціативи.
- Офісна мапа для нових співробітників.
Контекст: відсутність мапи офісу для співробітників та зовнішній неконтрольований чинник — пандемія COVID-19. У компанії, де один офіс займає два з половиною поверхи, а інший — чотири, новенькі часто губилися. Менеджери власноруч планували розміщення команд. Це спричинило накладки. Ми почали розроблення інтерактивної мапи, яка мала полегшити навігацію. Однак проєкт зупинився з поширенням COVID-19. Офіси спорожніли, а потреба в покращенні зникла на невизначений термін.
Рішення: переглянути актуальність ідеї в нових умовах. Коли обмеження через пандемію були скасовані й люди перейшли на гібридний формат роботи, ідея з мапою отримала новий шанс на життя.
Згодом її масштабували для офісів у кількох країнах, додавши функціонал бронювання робочих місць та місць для авто. Мапа зараз активно використовується всіма левінайнерами по світу.
Висновки: іноді «заморожений/закритий» проєкт може відродитися в іншій формі — з новою цінністю. Не варто ховати ідею, яка не реалізувалася з першого разу.
- Уніфікована платформа для внутрішніх продуктів.
Контекст: кожна команда Levi9 створювала внутрішні проєкти під продукти за власними правилами. Через це виникала плутанина щодо доступу до них, актуальності середовищ та використаних ресурсів. Ми розробили концепцію уніфікованої платформи на базі Kubernetes. Вона мала впорядкувати ці процеси й стати базою для навчання junior-спеціалістів. Після демонстрації керівництву ідею заморозили через нестачу ресурсів: тоді на ринку бракувало інженерів навіть для комерційних завдань.
Рішення: змінити пріоритети. Системні інженери почали використовувати цю платформу насамперед як sandbox для новеньких у DevOps.
Протягом двох років на неї мігрували всі внутрішні проєкти з відповідною оптимізацією ресурсів (нині використовується вчетверо менше комп’ютерних потужностей, а це економія коштів та електроенергії), уніфіковано підхід до CI/CD, розроблено вебінтерфейс для зручності моніторингу. Після цього відбулася повторна демонстрація, завдяки якій рішення розшириться на інші офіси.
Висновки: другорядні цілі проєкту не менш важливі за основні. Тому змінюйте їхні пріоритети залежно від поточної ситуації.
Lessons learned
«Погані» кейси трапляються в кожного. Рефлексія над такими ситуаціями допомагає побачити, що варто змінити та як уникнути повторення помилок у майбутньому. Проте важливо пам’ятати, що попередній досвід заважає, якщо не враховувати унікальні виклики нового контексту.
Так звані «погані» проєкти часто насправді просто складні, неприбуткові, вимагають більше уваги або потребують переосмислення. І вчасний вихід — не поразка, якщо ви доклали достатньо зусиль для покращення ситуації.
Партнерські матеріали
