Одна з причин затримки термінів здачі проєктів або навіть відвертих провалів – незрозуміле завдання, яке помилково було взято в роботу без додаткових уточнень і роз’яснень від замовника. Особливо часто цим «грішать» новачки, тому перший час вам, як проєктному менеджеру, краще підстрахуватися і перевіряти таски. Детальніше про те, що важливо на естимейті, розповість Lead Software Engineer at SoftServe Олексій Голубєв.
Ця стаття – продовження циклу «Шпаргалка для менеджера». У попередніх двох розповіли про «хороші та погані» питання під час інтерв’ю та особливості онбордингу технічних фахівців.
Що таке естимейт?
Естимейт (від англ. estimate – оцінка, приблизний розрахунок) – це термін, широко використовуваний у різних сферах діяльності, від бізнесу до інженерії та програмування. Естімейт є оцінкою часу, ресурсів, вартості або інших ключових параметрів, необхідних для виконання певного проєкту або завдання.
Ключові аспекти естімейта такі:
- Приблизність. Естимейт завжди є приблизним розрахунком. Він ґрунтується на доступній інформації та досвіді, але не може враховувати всі можливі змінні та несподіванки.
- Використання в управлінні проєктами. В управлінні проєктами естімейти допомагають планувати бюджет, розподіляти ресурси та визначати терміни. Вони є ключовим елементом у методологіях проєктного менеджменту, таких як Agile та Scrum.
- Техніки оцінювання. Існують різні техніки для створення естімейтів, включно з експертними оцінками, аналітичними методами, історичними даними, а також статистичними та ймовірнісними моделями.
- Важливість для бюджетування. У бізнесі естімейти часто використовуються для бюджетування проєктів і можуть впливати на ухвалення рішень щодо інвестицій та розподілу фінансових ресурсів.
- Застосування в розробленні ПЗ. У сфері розробки програмного забезпечення естімейти допомагають планувати спринти, розподіляти завдання між командами та керувати очікуваннями клієнтів.
Естимейт – це потужний інструмент у руках професіоналів, що дає змогу планувати та прогнозувати ключові аспекти проєктів і завдань. Хоча він ніколи не буває абсолютно точним, правильно складений естимейт може значно поліпшити планування та управління в будь-якій сфері діяльності.
Виклики та обмеження
Одним із ключових викликів при створенні естимейтів є невизначеність. Багато факторів можуть змінитися, що вплине на точність оцінок. Проєкти можуть еволюціонувати, і вимоги до них можуть змінюватись, що потребує перегляду та коригування естимейтів.
Суб’єктивність оцінок і вплив людського фактора також є важливими аспектами. Це може включати в себе надлишковий оптимізм або песимізм під час оцінювання.
Кому і для чого потрібні естімейти
Естимейти мають важливе значення в різноманітних галузях і для різних професіоналів. Вони допомагають у плануванні, ухваленні рішень та управлінні ризиками. Давайте розглянемо основні групи, для яких естімейти виявляються особливо корисними:
Керівники проєктів і команди управління проєктами
Мета: Розрахунок часу, ресурсів і бюджету, необхідних для досягнення цілей проєкту.
Застосування: Естімейти допомагають у складанні планів проєкту, визначенні термінів доставки та розподілі завдань між членами команди.
Розробники та інженери
Мета: Оцінка часу і зусиль, необхідних для реалізації технічних завдань або розробки продуктів.
Застосування: Використовується для планування спринтів в Agile-методологіях, визначення пріоритетів і розподілу робочого часу.
Фінансові аналітики та бухгалтери
Мета: Передбачення витрат, доходів та інших фінансових показників.
Застосування: Важливо для складання бюджетів, фінансового планування та аналізу рентабельності проєктів.
Маркетологи та рекламники
Мета: Оцінка ефективності рекламних кампаній, витрат на маркетинг і очікуваної віддачі від маркетингових зусиль.
Застосування: Допомагає в плануванні рекламних кампаній, розподілі бюджету та прогнозуванні результатів маркетингових ініціатив.
Підприємці та стартапи
Мета: Оцінка потреб у фінансуванні, ресурсах і часі для запуску та розвитку нового бізнесу.
Застосування: Використовується для залучення інвестицій, планування зростання та управління ризиками.
Клієнти та замовники
Мета: Отримання інформації про вартість, терміни та ресурси, необхідні для реалізації їхніх запитів або проєктів.
Застосування: Допомагає в ухваленні рішень про те, чи варто починати проєкт, і у виборі підрядників на основі їхніх оцінок.
Одиниці виміру естимейта
Одиниці виміру естимейта можуть значно варіюватися залежно від контексту та сфери застосування. Важливо обирати одиницю виміру, яка найточніше відображає характеристики проєкту або завдання. Нижче наведено найпоширеніші одиниці вимірювання естимейтів:
- Час. Години/Дні/Тижні/Місяці: Широко використовуються в проєктному управлінні для оцінки тривалості завдань або проєктів. Людино-години/Людино-дні: Застосовуються для оцінювання обсягу роботи, враховуючи час, який знадобиться одній людині для її виконання.
- Вартість. Валютні одиниці (долари, євро, гривні тощо): Використовуються для оцінки бюджету проєкту, витрат на матеріали, оплату праці та інші витрати. Відсотки від бюджету: Це може бути відсоток від загального бюджету проєкту, виділений на певне завдання або етап.
- Ресурси. Одиниці ресурсів (матеріали, обладнання тощо): Оцінка кількості необхідних матеріалів або обладнання. Людські Ресурси (кількість співробітників, команд): Оцінка чисельності персоналу або команд, необхідних для виконання завдання.
- Комплексні одиниці. Бали Зусиль/Складності (в Agile-методологіях): Це відносна оцінка зусиль або складності завдання, часто використовувана в скрам-методології. Функціональні точки: Застосовуються в розробці ПЗ для оцінювання функціональності та складності програмних продуктів.
- Якісні показники. Рівні пріоритету (високий, середній, низький): Використовуються для визначення важливості або терміновості завдань. Оцінки ризику (високий, помірний, низький): Оцінювання потенційних ризиків, пов’язаних із проєктом або завданням.
Вибір відповідних одиниць виміру критичний для точності та корисності естимейта. Неправильний вибір може призвести до непорозуміння, неправильного розподілу ресурсів або навіть до провалу проєкту. Важливо, щоб обрані одиниці були зрозумілі всім учасникам проєкту і відповідали специфіці завдання або проєкту.
Контроль естимейту від розробників
Project manager відповідає за роботу команди та реалізацію проєкту загалом. У разі будь-яких проблем відповідальність завжди на ньому, тому необхідно, щоб на всіх етапах учасники команди дотримувалися загальноприйнятих правил та інструкцій.
Під час естимейту PM-у важливо стежити за тим, щоб:
- Розробник або розробниця не брали завдання з блокерами або відразу їх документували. Це допоможе убезпечити команду від можливих претензій клієнта, якщо раптом будуть питання щодо таких тасків.
Блокер – це перешкода, яка ускладнює або унеможливлює виконання завдання. Наприклад, відсутність якихось даних або доступів.
- IT-фахівець естимейтив тільки ті завдання, в яких йому зрозуміло, що потрібно зробити і який результат має бути. Якщо розробник або розробниця бачать, що завдання поставлено не коректно, бракує якоїсь інформації для виконання завдання, їм обов’язково потрібно уточнити всі деталі у team lead-а, у вас, як project manager-а, або у замовника. Річ у тім, що виконання будь-якого завдання без чіткого технічного завдання – це потенційна точка ризику для всього проєкту.
- Тести мають бути враховані в тасках. Вони за своєю суттю фіксують поведінку застосунку. Коли в продукт вносять зміни, завжди є ймовірність появи технічних помилок або порушення роботи в бізнес-логіці. Тести дають змогу це врахувати і відстежити. Додайте до цього те, що програмісти в середньому витрачають на їхнє створення близько 20% свого часу, – і отримаєте важливу складову таски, від якої сильно залежать терміни. При цьому прибрати тести небажано, оскільки це може негативно позначитися на кінцевому результаті і доведеться потім все переробляти.
В іншому процес оцінювання завдання навіть у новачків проходить без особливих питань. Мета PM-а на цьому етапі – переконатися, що всі учасники команди беруться виконувати тільки зрозумілі завдання з усією необхідною інформацією для їх реалізації. Тоді робота над проєктом буде проходити легше і без сильних ризиків для кінцевого результату, але про це поговоримо в наступній статті циклу «Шпаргалка для проєктного менеджера».