Привет, Хабр! Я Костя — Lead QA в tekmates. Мы в компании создаём цифровые продукты для бизнеса. В прошлой статье я упомянул, какие техники мы используем для оценки проектных задач: на тестирование, разработку, техдолгов, архитектурных исследований и прочих. 

Проработав более трёх лет проджект-менеджером и больше года лидом QA-инженеров, я много раз оценивал задачи по времени выполнения. И не всегда это давалось (да и даётся) легко… 

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

Зачем оценивать проектные задачи?

Преимущества оценки задач могут показаться очевидными, но тем не менее задачи иногда всё равно не оценивают (или делают это криво). Поэтому кратко проговорим какие же плюсы даёт оценка задач — можете использовать это как аргументы для внедрения системы оценки в вашей компании.

Почему оценивать задачи трудно?

Подходя к оценке задач, мы сталкиваемся с трудностями, которые могут повлиять на точность и корректность оценки. В свою очередь, неправильная оценка влияет на весь проект: появляются овертаймы, перерасход бюджета, срывы дедлайнов и так далее. 

Зная эти сложности, можно учесть их при планировании, чтобы минимизировать риски.

Основные трудности:

• Неопределённость и сложность задач: когда много внутренних составляющих компонентов и связей или где не хватает аналитики.

• Неправильное определение объёма работ или его расширение в процессе. 

• Субъективность. Время выполнения задачи одного исполнителя может сильно отличаться от времени другого.

• Недостаток или отсутствие исторических данных. Без базы для сравнения оценки могут быть менее точными и более рискованными. На будущее нужно озаботиться тем, чтобы хранить исторические данные — например, похожие задачи, успешно закрытые проекты и так далее.

• Чрезмерный оптимизм или пессимизм. Первое может привести к занижению сроков и ресурсов, второе — вызвать излишние резервы и завышенные бюджеты.

• Быстрые изменения в технологиях могут сделать первоначальные оценки недействительными. Например, изменение кода, библиотек, фреймворков, оборудования, сервисов.

• Зависимость от внешних факторов: участников проектной команды, экономических факторов, политической и технологической ситуации на рынке. 

• Недоступность необходимых ресурсов: количество исполнителей и дополнительные технологические мощности или недостаточный уровень навыков у исполнителей.

• Пробелы в коммуникации между участниками проекта и стейкхолдерами.

• Давление с целью соблюдения сроков может привести к нетщательной оценке задач и вызвать целенаправленное занижение сроков и ресурсов, что приводит к перерасходу бюджета и снижению качества работы.

И что делать?

Вот пара советов:

• Разделите сложные задачи на более мелкие и понятные, чтобы упростить оценку.

• Опирайтесь на похожие задачи из прошлых проектов для оценки.

• Привлекайте экспертов для оценки сложных задач, но будьте осторожны с субъективностью.

• Уточните и зафиксируйте объём работ на начальном этапе выполнения.

• Проводите групповые встречи для оценки задач, чтобы учесть разные мнения.

• Начните собирать данные для текущего и будущих проектов, храня историю, которую можно будет использовать для анализа.

• Включите временные и бюджетные резервы в зависимости от сложности задачи на случай непредвиденных обстоятельств.

• Следите за изменениями в технологиях, чтобы быть готовыми к их внедрению.

• Проводите регулярные встречи для обсуждения прогресса и проблем.

Техники оценки задач

Техник много, можно выбрать ту, что нравится или использовать сразу несколько. Также эти методы можно применять для приоритезации задач. 

Three-point estimate. Техника «Трёх точек»

Считаем по формуле: 

или

где:

Эту технику можно использовать, когда у задач высокий уровень неопределённости. Или если они сложные, и мы можем учесть широкий диапазон возможных результатов. Ещё метод подойдёт, когда ожидаются значительные изменения или влияния внешних факторов. Трёхточечная оценка поможет учесть возможные колебания и подготовиться к ним.

Пример. Предположим, что вы оцениваете задачу по разработке нового модуля в приложении.

1. Оптимистичная оценка (O): 16 часов.

2. Наиболее вероятная оценка (R): 40 часов.

3. Пессимистичная оценка (P): 80 часов.

Расчёт ожидаемой оценки (E) по формуле:

Ожидаемая оценка: 42,6 часов. Это среднее ожидаемое время выполнения задачи.

Analogous Estimation. Аналоговая оценка

Если у вас есть исторические данные по задачам с аналогичными требованиями и сроками, объёмами работ и условиями, можно использовать эту технику. Так как метод позволяет применять уже проверенные оценки на основе реального опыта, новая оценка будет точнее.

Expert Judgment. Экспертная оценка

Можно использовать, когда проект включает новые, уникальные или очень сложные задачи, которые команда из-за недостатка опыта не может точно оценить. Эксперт, который решал подобные задачи или обладает компетенциями в решении проблем, поможет сформулировать оценку. 

Но будьте осторожны: эксперт может быть субъективен. Поэтому перепроверьте результат оценки с помощью другой техники или мнения ещё одного эксперта.

Bottom-up estimate. Оценка «Снизу-вверх»

Считаем по формуле:

Декомпозируйте сложную задачу на части и оцените каждую часть отдельно. Техника хорошо подходит для оценки времени на выполнение User Story. 

Допустим, нужно отдельно оценить время на исследование и составление требований, подготовку архитектурного решения, разработку, тестирование, отладку, резерв. Каждый отдельный пункт можно ещё глубже декомпозировать. Например, разработка может включать в себя несколько модулей, а тестирование включает в себя изучение требований, подготовку тестовых данных, само тестирование и тому подобное.

Разберём расчёты на примере такой User Story:

Как пользователь, я хочу иметь возможность зарегистрироваться на веб-сайте, чтобы получить доступ к авторизованному контенту

Разобьём на задачи для тестирования:

1. Ревью функциональных требований.

2. Ревью макетов дизайна.

3. Написание тест-кейсов.

4. Подготовка тестовой среды.

5. Подготовка тестовых данных.

6. Выполнение тестов.

7. Анализ результатов и отчётность.

Оценим время на каждую задачу:

Сложим оценки всех задач:

Таким образом, на выполнение всех задач по тестированию новой user story потребуется примерно 24,5 часа.

Planning poker. Покер планирования

Можно использовать, когда надо оценить трудоёмкость и временные затраты на выполнение задач в условиях неопределённости и отсутствия точных данных. Применять технику можно онлайн и оффлайн. Она особенно полезна, если важно учесть мнения всех участников команды и прийти к коллективному согласию.

Пример. Представим, что проектная команда работает над созданием нового функционала для мобильного приложения. Нужно оценить трудоёмкость задач для следующего спринта. Вот как это будет происходить.

Шаг 1. Подготовка

Функциональность делится на отдельные задачи или пользовательские истории. Каждый участник проектной команды получает набор карт с числовыми значениями Фибоначчи (например, 1, 2, 3, 5, 8, 13, 21 и так далее), которые представляют трудоёмкость задач (например, в часах).

Шаг 2. Описание задачи 

Владелец продукта или заинтересованный участник описывает первую задачу или историю, предоставляя все необходимые детали и отвечая на вопросы команды.

Шаг 3. Оценка

После обсуждения каждый участник команды одновременно выбирает карту с оценкой, представляющей по его мнению трудоёмкость задачи и выкладывает её на стол.

Шаг 4. Сравнение и обсуждение

Все оценки открываются одновременно. Если оценки сильно различаются, участники команды с минимальными и максимальными значениями объясняют свои мнения.

Шаг 5. Пересчёт

После обсуждения команда снова оценивает задачу. Этот процесс повторяется до тех пор, пока не будет достигнуто согласие, или оценки не станут ближе друг к другу.

Шаг 6. Фиксация оценки

Окончательная оценка фиксируется, команда переходит к следующей задаче.

С помощью покера планирования можно также приоритизировать задачи: вместо временных оценок выставлять приоритеты, выраженные в числовых значениях. Тогда задачи с более высокими цифрами нужно будет выполнить раньше других.

Что в итоге?

Оценка задач помогает планировать и распределять ресурсы, создавать реалистичное расписание работ, точно бюджетировать проектные затраты, управлять рисками, контролировать производительность, принимать обоснованные решения и улучшать коммуникацию со стейкхолдерами.

Несмотря на важность оценки, существует ряд трудностей. Чтобы их преодолеть, можно использовать специальные техники, которые помогают учесть различные аспекты при оценке задач и сделать её более точной и реалистичной.

В статье я привёл лишь часть техник, которые я использую в работе. Безусловно, есть еще множество других, поэтому пишите в комментариях — как оцениваете проектные задачи вы?