Всем привет, мои дорогие друзья. Поговорим сегодня о том, каким образом можно подойти к оценке трудозатрат по разработке ПО. У каждого в карьере наступает момент, во время которого придут и просят: "сколько будет стоить разработать эту функциональность?". И, разумеется, на такие вопросы уже давали ответы и знают какие есть способы. Рассмотрим несколько вариантов:
Аналоговая оценка
Делаем оценку на основе уже решенных задач, аналогичных по масштабу, сложности и технологиям. Типичный подход - это подумать над тем, были ли задачи похожие в копилке решенных. Зачастую так оно и есть, не думаю, что каждый раз мы решаем совершенно разные задачи и однотипных не было. А это значит, что можно использовать этот подход в своем арсенале.
Как применять
- Вспомнить и зафиксировать, сколько времени заняли похожие задачи в прошлом.
- Подкорректировать оценку, если текущая задача сложнее/проще аналогичной.
- Подкорректировать оценку, учитывая новый стек технологий, состав команды, внешние риски.
Пример:
Если в проекте пришла задача сделать интеграцию с другим сервисом, то можно обратиться и посмотреть у себя, не было ли сделано других задач по интеграции. Скорее всего для решения задачи по интеграции придется решать похожие проблемы, что сразу может дать стартовую оценку, которую уже подкорректировать в соответствии с особенностями новой задачи.
Также, те кто уже имел дело с реализацией интеграций, знают какие задачи нужно решить, например вопрос и тестированием интеграции. С поддержкой интеграции и прочим.
Плюсы такого подхода:
- Быстро - за счет аналогичных, уже решенных задач, часть оценки приходит быстрее, чем если бы оценивать ее с нуля.
- Эмпирически проверено - есть уже готовые результаты с затраченным временем по аналогичной задаче.
- Хорошо работает с опытной командой
Минусы такого подхода:
- Требует наличия опыта и исторических данных. Действительно, чтобы использовать этот подход, нужно уже иметь в арсенале команды решенные аналогичные задачи, что не всегда так.
- Субъективность - возможна ошибка при "кажущемся" сходстве. Здесь таится большая проблема, которая может выстрелить, так как подход аналогий не всегда корректен.
Метод экспертной оценки
Собираем мнение нескольких опытных разработчиков или архитекторов, чтобы получить обоснованную оценку.
Здесь также интересен подход, так как можно получить мнение из разных сторон. Например, есть мнение технического спеца, который находится на полях и знает детали реализации, а есть мнение архитектора проекта, который понимает на более высоком уровне задачу и ее связь с общей архитектурой. Также есть смысл узнать мнение у человека, который не погружен в проект, который сможет посмотреть непредвзято на ситуацию.
Как применять:
- Сформулировать задачу понятно и подробно
- Запросить оценку у 2-4 специалистов
- Усреднить результаты или обсудить расхождения, чтобы прийти к общему мнению.
Плюсы такого подхода:
- Учитываются разные точки зрения.
- Часто дает более точные оценки.
- Повышает вовлеченность команды.
Минусы такого подхода:
- Требует большого времени на обсуждение.
- Возможно групповая предвзятость.
Декомпозиция
Разбиваем задачу на более мелкие подзадачи, оцениваем каждую и складываем итог.
Такой подход, я уверен, использовали все без исключений. Когда нужно понять детальную оценку и сложно вывести ее в моменте, но проще разделить задачу и посмотреть на оценки каждой из частей.
Как применять:
- Разбить задачу на подзадачи уровня: написать компонент, настроить CI, написать тесты и тд
- Оценить каждую по очереди в часах/днях
- Учесть буфер на дефекты, правки, коммуникацию (обычно + 10-30%)
- Сложить оценки всех подзадач
Пример:
Задача реализовать интеграцию с другой системой:
1. Обсудить контракт по взаимодействию.
2. Реализовать контракт по интеграции на моковых данных.
3. Реализовать требуемую логику в замен моковых данных.
4. Написать тесты
5. Заложить время на багофикс во время тестирования ф-ти.
Плюсы такого подхода:
- Очень детально. При таком подходе можно рассмотреть задачу с разных частей, которые в общем оценке могут сильно повлиять, но которую можно не вспомнить при других подходах.
- Легко верифицировать. Оценки по декомпозированным частям легче оценить на объективность и поправить нужную сторону
- Удобно для отслеживания хода выполнения. Такой подход дает сразу возможность по реализации критического пути на основе декомпозированных частей и создать нужные тикеты для отслеживания. Также можно использовать как Acceptance Criteria.
Минусы такого подхода:
- Трудоемко на старте. На декомпозицию потребуется больше времени, чем сказать общую оценку.
- Сложно применять, если задача слабо понятна или нестандартная.
- Возможна завышенная оценка. В ходе декомпозиции можно заиграться и дать оценку выше требуемой.
Метод оценки с диапазионом (Min/Max)
Вместо одной жесткой цифры, указать оптимистическую, реалистическую и пессимистическую оценку. Это помогает лучше учесть риски, неопределенности и варьирующиеся сценарии. Тогда в итоговом результате можно будет получить не просто одну цифру, а коридор, в рамках которого будет идти оценка.
Формат оценки:
- Min - оценки, при условии, что все пойдет идеально, без сбоев и отклонений. Например при тестировании не будут
- Most Likely (ML) - реалистическая оценка на основе опыта.
- Max - если все пойдет не по плану, возникнут проблемы, баги, блокеры и т.д.
Как применять:
- Простой вариант - "На эту задачу уйдет от 2 до 5 дней, в среднем, скорее всего, будет 3-4 дня"
- Сложный - подсчитать по формуле PERT - Оценка = (Min + 4*ML + Max) / 6
Пример:
Min=2d, ML=4d, Max=7d
Оценка = (2 + 4*4 + 7)/6 = 4.2d (дня)
Плюсы такого подхода:
- Хорошо отражает реальность - задаче редко идут строго по плану.
- Учитывает неопределенность, особенно на ранних этапах.
- Поволяет эффективно планировать буферы и ресурсы.
- Отлично комбинируется с декомпозицией или аналогией.
Минусы такого подхода:
- Требует больше времени на оценку (надо думать над каждой границей).
- Может быть неинтуитивным для новичков в команде.
- Иногда трудно определить Min и Max, особенно при высоких рисках.
Когда лучше использовать:
- Если задача туманная или новая.
- Если команда работает с разным уровнем опыта.
- Если менеджмент или заказчики хотят видеть риски в цифрах.
- При планировании в условиях ограниченных ресурсов и сроков.
Оценка "на глаз"
Нужно выдать очень быстро приблизительную оценку, основанную на интуиции, личном опыте и ощущении объема. Чаще всего используется в переговорах, при предварительном планировании, при оценке выполнимости задачи. Оценка предполагает большой коэффициент на покрытие потенциальных рисков. Также ожидается, что эта оценка будет подвергнута изменению после решения оценить должным образом.
Как применять:
- Оцени уровень задачи в голове: "это что-то простое, средней сложности или АД?"
- Дай диапазон на уровне "часов/дней/недель"
- Скажи в слух, что это грубая оценка.
Пример:
- а сколько займет времени интеграция с X?
- На глаз - где-то 1.5 - 2 недели. Но потребуется уточнить после получения детального анализа ТЗ.
Плюсы такого подхода:
- Очень быстро. Да, оценка дается в течении.
- Часто достаточен для принятия решений на высоком уровне.
- Экономит ресурсы на стадии, где точность еще не критична.
Минусы такого подхода:
- Может сильно ошибаться (в обе стороны).
- Не годится для фиксации сроков и бюджета.
- Зависит от опыта - новичку сложно давать оценку даже "на глаз".
Когда использовать:
- На первом звонке или встрече.
- Когда просят "прикинуть, дорого ли выйдет".
- До появления ТЗ или макетов.
- При оценке множества задач, чтобы понять, какие самые тяжелые.
Poker Planning
Отдельно стоит поговорить о покер планировании.
Это подход, когда собирают команду и предлагают оценить в слепую каждую задачу в каких-то единицах (попугаях, сторипоинтах, человекоднях и так далее). Оценки ставятся, обычно, в соответствии с числами фибоначчи (1, 2, 3, 5, 8, 13, 21, ..). Когда оценки сильно разнятся, начинается обсуждение:
- одни рассказывают про технических долг
- другие - про подводные камни в интеграции
- третьи - про UI и тестирование
Таким образом происходит дополнительная депомпозиция в процессе обсуждения. Пусть и устная, без написания всех подзадач.
Это методика по использованию комбинированного подхода в оценке, когда каждый участник команды высказывает свою оценку (экспертная оценка), исходя из собственного опыта (аналоговая оценка) и понимания задачи. Задача может быть как цельной, так и декомпозированной (пример подход по декомпозиции).
Формат голосования и диапазон ответов от разных людей помогает заметить, где есть расхождения в понимании объема. Это как Min/Max, только коллективный - ты сразу видишь, где кто-то видит "1", а кто-то "8" и почему.
Причем так как в использовании этого подхода будут оценивать задачи не всегда погруженные в суть задаче по той или иной причине, то это можно сказать и оценка на глаз.
Итого PokerPlanning = экспертная оценка + min/max + декомпозиция + аналоговая оценка + оценка на глаз
Просто что это все подается в игровой, демократичной и вовлекающей форме.
Из неочевидного плюса - это помогает также сгладить эффект доминирующего мнения, потому что сначала каждый оценивает втайне. То есть он еще и психологически продуманный.
Из минусов такого подхода можно указать, что для проведения эффективного покер планирования требуется слаженная команда и умеющий проводить такую активность человек. Сразу не будет ВАУ эффекта, так как не все сразу проникнутся этим подходом.
Выводы
В процессе разработки ПО не существует универсального способо по оценке задач - каждая ситуация требует адаптации подхода под контекст, степень неопределенности, начилие опыта и доступных данных.
Чтобы добиться наибольшего результата, нужно стремиться использовать комбинированных подход, в котором используются несколько методов:
1. На старте проект - приняются аналогии и грубые оценки, чтобы определить масштаб
2. На этапе планирования - задачи декомпозируются, уточняются через экспертов и оцениваются в формате Min/Max
3. Внутри командной работы - применяется Planning Poker, что обеспечивает прозрачность, согласованность и реалистичность оценки
4. Для быстрых решений - допустимы предварительные оценки на глаз, с обязательным уточнением позже.
Такой подход помогает учитывать как скорость, так и точность, адаптируясь к меняющимся условиям проекта.
На этом все, спасибо за внимание, оставляйте в комментариях свое мнение по этому поводу.