Annual Open Tech Conference - ISsoft Insights 2021. June 19. Learn more.
×Закрыть

Як перевірити, чи з проєктом усе гаразд, якщо ви не його проджект-менеджер

Привіт, мене звати Юлія, я 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. Але по факту використано більше. Отже, час перевірити, чи виконані роботи були передбачені в бюджеті. У разі перевикористання з’ясуйте, у чому проблема:

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

У нас було кілька кейсів, коли бюджет проєкту зріс внаслідок зміни скоупу. Один з них — проєкт Sync.ai. Ми працювали за Fixed Price моделлю і тому попередньо заклали в бюджеті статтю на буферні зміни. У результаті проджект-менеджер враховував усі зміни на проєкті як буферні. Скільки фактично годин вони займали, не відстежували. Зрештою, змін стало забагато і внутрішній бюджет проєкту збільшився. Ми одразу провели історичну ретроспективу, естімацію всіх змін і побачили, що фактичний бюджет все-таки перевищив запланований. Оскільки ми прокомунікували проблему до того, як ситуація стала критичною, клієнт погодився оплатити попередні та майбутні зміни.

Що робити, щоб така ситуація не трапилася:

  1. заздалегідь визначати, хто покриватиме збільшення бюджету;
  2. обговорювати усі зміни;
  3. враховувати, як усі зміни впливають на GPM проєкту.

Крок 3. Оцініть статус проєкту

Простий і водночас ефективний спосіб перевірити статус проєкту — зайти в Jira (або будь-який інший трекер завдань, яким користуєтеся). Що можна з’ясувати за його допомогою?

Якість. Її можна простежити за кількістю багів у беклозі або на дошці проєкту. Особливу увагу звертаємо на ті, в яких є severity blockers, або помилки з critical & high priority.

Визначити, яка кількість помилок є критичною для вашого проєкту, складно: все залежить від етапу, на якому вони виникли. Так, на стадії продакшену навіть один критичний баг є ризиком для компанії, оскільки він може зупинити роботу клієнта. Під час розробки кількість критичних помилок не має перевищувати 10–15% від усіх помилок на проєкті.

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

Звіти. За допомогою 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 компанії. Тож якби не проміжні звіти, ми могли б взагалі не дізнатися про це або ж дізналися б запізно.

👍НравитсяПонравилось15
В избранноеВ избранном4
Подписаться на автора
LinkedIn

Похожие статьи




Підписуйтесь: Soundcloud | Google Podcast | YouTube


7 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

GPM, мабуть, рахується від доходу — не від прибутку?

только для меня тут написаны банальные очевидные вещи?

Вопрос: а кому это нужно, если не менеджеру?

Владельцу/цам бизнеса конечно. Если проектов сильно больше чем 1. Скажем их 100+ или еще больше, очень может быть что есть такие — где люди вкалывают без выходных, отпусков и по 12 часов в день. А этот проект ещё и убытки приносит при всем этом ибо: клиент сел на голову, текучка кадров которую надо закрывать вливаниями в рекрутинг и т.д. . Поэтому и вводят PMO — которые по идее проверяют что все проекты следуют единому стандарту компании.

Вот мне почему — то кажется, что владельцы бизнеса на 100+ проектов не читают этот сайт, или читают но мало

Подписаться на комментарии