Як перевірити, чи з проєктом усе гаразд, якщо ви не його проджект-менеджер
Привіт, мене звати Юлія, я Head of Delivery у Fulcrum Rocks. У цій статті розповім, як перевірити, чи все на проєкті йде за планом, навіть якщо ви не його проджект-менеджер.
Одне із завдань Head of Delivery — контролювати просування проєктів. Саме швидка об’єктивна кросфункційна оцінка не раз допомогла мені виявити приховані проблеми на проєкті, запобігти можливим ризикам і не допустити критичної ситуації.
Такий health-чек дасть змогу краще оцінити якість сервісу на проєкті, виявити те, що можна поліпшити, та уникнути проблем.
Крок 1. Почніть з юридичної документації
Починати перевіряти проєкт варто з юридичної документації. Чи є вона? Чи відповідає вона нормам? Для цього з’ясуйте:
- чи підписано контракт. Це очевидна формальність, яка іноді залишається без необхідної уваги. Як результат — проблеми у розпалі проєкту;
- актуальність контракту. Переконайтеся в актуальності підписаного документа, у тому, чи правильно зазначені дати, чи є акти приймання-передачі.
Доступ до таких документів зазвичай є у проджект-менеджера, акаунт-менеджера або Head of Delivery — це залежить від обов’язків цих фахівців у компанії. У Fulcrum Rocks, наприклад, за юридичну документацію відповідає проджект-менеджер.
Крок 2. Перевірте фінансове здоров’я проєкту
Тут аналізуємо три ключові метрики — GPM (Gross Profit Margin), дебіторську заборгованість і фактичне освоєння бюджету.
Gross Profit Margin, або GPM — це співвідношення прямих витрат (витрат на спеціалістів, серверне обладнання, інструменти) до загальних витрат на проєкті. Від загального прибутку GPM має становити більше як 50% відсотків, якщо показник менший — готуйтеся до проблем із загальною маржинальністю.
Щоб GPM не стала проблемою, прорахуйте її перед стартом роботи та переконайтеся, що вона не нижча за 50%. Для Fixed Price проєктів закладайте більшу маржинальність — можуть спрацювати додаткові ризики й GPM знизиться.
Далі перевіряємо дебіторську заборгованість, а точніше — її тривалість. Термін виплати дебіторської заборгованості визначає сама компанія. Наприклад, у Fulcrum так звана дебіторка становить до 5 днів, в інших компаніях — до 3. Якщо клієнт не виплачує дебіторську заборгованість вчасно, у майбутньому можуть виникнути питання щодо оплати.
Як перестрахуватися тут? Перед стартом проєкту підготуйте план виплат від клієнта та узгодьте його з ним. Далі стежте за дотриманням плану. Якщо клієнт відхиляється від нього — обговорюйте проблему.
Наступний індикатор — відповідність фактичного освоєння бюджету до запланованого. Наприклад, на два місяці проєкту заплановано $30 000. Але по факту використано більше. Отже, час перевірити, чи виконані роботи були передбачені в бюджеті. У разі перевикористання з’ясуйте, у чому проблема:
- Якщо спрацювали певні ризики, визначте, яка сторона є носієм цих ризиків і хто їх компенсує.
- Якщо був змінений обсяг робіт (скоуп), варто розібратися, хто був ініціатором змін, чи були вони узгоджені з клієнтом і чи погоджена додаткова оплата.
У нас було кілька кейсів, коли бюджет проєкту зріс внаслідок зміни скоупу. Один з них — проєкт Sync.ai. Ми працювали за Fixed Price моделлю і тому попередньо заклали в бюджеті статтю на буферні зміни. У результаті проджект-менеджер враховував усі зміни на проєкті як буферні. Скільки фактично годин вони займали, не відстежували. Зрештою, змін стало забагато і внутрішній бюджет проєкту збільшився. Ми одразу провели історичну ретроспективу, естімацію всіх змін і побачили, що фактичний бюджет все-таки перевищив запланований. Оскільки ми прокомунікували проблему до того, як ситуація стала критичною, клієнт погодився оплатити попередні та майбутні зміни.
Що робити, щоб така ситуація не трапилася:
- заздалегідь визначати, хто покриватиме збільшення бюджету;
- обговорювати усі зміни;
- враховувати, як усі зміни впливають на GPM проєкту.
Крок 3. Оцініть статус проєкту
Простий і водночас ефективний спосіб перевірити статус проєкту — зайти в Jira (або будь-який інший трекер завдань, яким користуєтеся). Що можна з’ясувати за його допомогою?
Якість. Її можна простежити за кількістю багів у беклозі або на дошці проєкту. Особливу увагу звертаємо на ті, в яких є severity blockers, або помилки з critical & high priority.
Визначити, яка кількість помилок є критичною для вашого проєкту, складно: все залежить від етапу, на якому вони виникли. Так, на стадії продакшену навіть один критичний баг є ризиком для компанії, оскільки він може зупинити роботу клієнта. Під час розробки кількість критичних помилок не має перевищувати
Якщо ж кількість критична, з’ясуйте, в чому причина: помилка в плануванні чи, можливо, розробник не виконує свої завдання.
Звіти. За допомогою Jira можна переглянути швидкість виконання проєкту (velocity звіт), чи встигає команда розв’язувати задачі під час спринтів і наскільки вдало.
Релізи. Ще одна нова й зручна функція Jira — ведення релізів. Ми вже впровадили її в Fulcrum і рекомендуємо спробувати іншим. Ця функція дає можливість переглянути дату релізу, оцінити обсяг робіт, перевірити прогрес просування до релізу і його реальність. Вона стала у пригоді, коли ми працювали над Kör. Оскільки проєкт мав великий обсяг завдань і швидкий темп розробки, введення релізів у Jira допомогло упорядкувати задачі та правильно їх пріоритизувати. В результаті команда стала впевненішою в тому, що робить, а процес і менеджмент розробки поліпшилися.
Ведення релізів в Jira
Статус роадмапу — порівняйте заявлений роадмап на початку проєкту з роадмапом у Jira. Бачите різницю? Час зрозуміти, що було причиною змін. Серед можливих варіантів — ризики, які спрацювали, зміна скоупу, пріоритетів, зміни в команді, неправильне планування проєкту чи його естімація.
Крок 4. Поспілкуйтеся з фахівцями
Окрім перевіряння документації, варто поспілкуватися з тими, хто має безпосередній стосунок до проєкту.
Акаунт-менеджер. Одним з останніх кроків health-чеку проєкту може бути розмова з акаунт-менеджером або перегляд його/її звітів. У Fulcrum, наприклад, акаунт-менеджери кожні два тижні зідзвонюються з клієнтом і збирають фідбек за цей період.
Клієнт. Якщо акаунт-менеджера на проєкті немає, поспілкуйтеся з клієнтом прямо. Під час розмови ставте загальні та уточнювальні запитання для отримання максимально ефективного відгуку. Визначте сфери, які вас цікавлять, наприклад, якість/комунікація/таймінги, і сформулюйте питання для оцінювання цих показників.
Прикладами запитань до клієнта можуть бути:
- Чи зрозумілий вам статус проєкту?
- Чи знаходили ви баги на продакшені?
- Яка найбільш критична ситуація сталася за цей період?
- Чи готові ви порадити нашу компанію своїм знайомим? (Це питання слугує основою для прорахунку NPS.)
HR-відділ. Крім щасливого клієнта, щасливою має бути й команда. Тож не забудьте поговорити з HR-спеціалістом. Що необхідно дізнатись у нього:
- загальний фідбек команди про проєкт;
- чи є овертайми на проєкті;
- чи працює команда у вихідні;
- чи є люди, які скаржаться на проєкт, хочуть змінити його або покинути команду.
Проджект-менеджер. Зрештою, поспілкуйтеся з проджект-менеджером. Разом обговоріть:
- проєкт за такими показниками: графік (schedule), якість (quality), команда (team), комунікація з клієнтом (customer communication);
- основні проблеми/виклики команди зараз;
- головні ризики, які ПМ передбачає на проєкті (ризики проєкту та продукту);
- додаткові питання, які могли виникнути під час вашої перевірки.
Зібравши інформацію з різних джерел, ви вже матимете певне розуміння, що ж відбувається на проєкті. Далі розробіть з проджект-менеджером план розв’язання поточних проблем (якщо вони є), повторно оцініть потенційні ризики та стежте за виконанням плану.
Наш досвід
Краще не чекати, поки з’являться проблеми, а регулярно перевіряти прогрес проєкту і запобігати можливим ризикам. Для цього ми ввели систему щотижневих звітів, які показують статус проєктів. Так, щотижня проджект-менеджер доповідає за такими параметрами, як графік, ресурси, якість, комунікація, обсяг робіт. ПМ позначає кожен з параметрів одним із трьох кольорів: зеленим, жовтим або червоним (де червоний — критичний, зелений — оптимальний). Якщо якийсь із критеріїв жовтого або червоного кольору, ПМ пропрацьовує його за схемою «результат — аналіз — дія». Усі дії в схемі переходять у задачі, які він починає імплементувати.
Ми тестуємо і кросфункційну звітність. Статус проєкту у нас оцінюють QA, бізнес-аналітик і акаунт-менеджер. У разі невідповідностей в їхніх звітах ми аналізуємо й докладніше розбираємося, в чому саме виникла проблема.
Всю інформацію зі звітів виводимо на інтерактивні дашборди разом з фінансовими показниками. Це дає змогу виявити проблемні ділянки ще на початковому етапі.
Щотижня ми проводимо півгодинний мітинг з кожним ПМ, де обговорюємо:
- основні ризики/виклики проєкту;
- головні можливості;
- ключові дії на місяць/тиждень, завдяки яким проєкт досягне успіху.
Помилки на проєкті трапляються, і це нормально, але іноді вони стають критичними. У Fulcrum Rocks такий чек допоміг неодноразово запобігати проблемам. Наприклад, у нас був кейс, коли ПМ звітував, що на проєкті все йде за планом, є невеликі технічні блокери, але їх успішно усувають. Під час звіту QA виявилося, що тестувальник вже протягом трьох тижнів не отримував білд, а клієнт не міг протестувати продукт. Таким чином невеликі технічні моменти швидко переросли в проблему, яку вже довелося вирішувати на рівні CTO компанії. Тож якби не проміжні звіти, ми могли б взагалі не дізнатися про це або ж дізналися б запізно.
