Меня зовут Александр, я CTO компании AppFox. Мы более 10-ти лет занимаемся заказной разработкой и также имеем собственные продукты.
В этой статье мы рассмотрим, почему важна оценка задач в проекте, имеет ли значение, работаете вы в аутсорс или продуктовой компании, коротко пройдемся по основным методам оценки проектов и в конце я расскажу, как мы оцениваем проекты в AppFox.
Вспомните, когда вы только начинали изучать свой первый язык программирования и пошли решать задачи на Codewars (если, конечно, в то время он уже был). Насколько точно вы могли прогнозировать сроки решения задачи? Скорее всего, вилка ответов могла расходится от «Я решу эту задачу за 1 час» до «Я не решу эту задачу никогда». Что-то изменилось с тех пор? Я говорю не о сложности задач, которая, несомненно, изменилась за время вашей карьеры, а о прогнозировании сроков.
Оценка будущих работ занимает много времени, раздражает и даже демотивирует команду. Но, к сожалению, без нее никуда. Большинство заказчиков с вами не захотят иметь дело, если вы заявите, что не используете предварительную оценку задач. Кроме того, в последнее время заказчики хотят сделку. Т.е. фиксированную стоимость конечного продукта.
Хочу сразу оговориться, что под заказчиком я подразумеваю не только стороннего клиента компании, но также product manager, CEO и вообще любого представителя бизнеса, который в вашей компании имеет полномочия добавлять таски на доску.
Тем не менее, нужно признать, что точная оценка сроков проекта — это не про угадайку, а про уровень профессионализма команды разработки.
Правильное прогнозирование задач — это навык, который определяет, будет ли ваша команда успешной или погрязнет в вечном «пожаротушении». И чем выше ваша должность, тем более отчетливо вы понимаете: оценка — это не просто техническая задача, это коммуникация с бизнесом на языке времени и ресурсов.
Оценка сроков — одна из самых сложных и критически важных задач в управлении разработкой. Мы постоянно сталкиваемся с тем, что даже опытные разработчики склонны либо недооценивать, либо переоценивать время, необходимое для выполнения задач. Ошибки в оценках приводят к срыву дедлайнов, переработкам, конфликтам с заказчиками, потере доверия к команде со стороны бизнеса и репутационные риски для всей компании.
Не важно, работаете вы в аутсорсе или в продуктовой компании — оценка рассчитывается всегда одними и теми же инструментами и методами, потому что, как я писал ранее, у вас всегда один заказчик. И он может быть внутри вашей компании, а может — со стороны. Но, в любом случае, от вас ждут максимально точных прогнозов по срокам.
В аутсорсе от оценки зависит прибыль и удовлетворенность клиента, а в продукте — эффективность инвестиций и выживаемость компании на рынке.
В аутсорсе заказчик платит за часы, и если вы недооценили сроки, то либо придется работать в убыток, либо объяснять клиенту, почему проект затягивается. В продуктовой разработке ошибки в оценках приводят к сдвигу релизов, упущенной выгоде и недовольству стейкхолдеров.
Главное отличие в том, что в аутсорсе оценка часто фиксируется в контракте, а в продукте может корректироваться. Но в любом случае, если разработчики систематически ошибаются в сроках, это подрывает доверие к команде.
Конечно, точная оценка начинается с точного ТЗ. Чем подробнее — тем лучше. Но давайте будем честны: в реальных проектах полностью исчерпывающее ТЗ — это редкость. Его либо нет вообще, либо оно слишком общее, либо требует стольких усилий на составление, что становится экономически невыгодным.
Мы часто работаем в условиях неопределенности. Это значит, что в любом проекте появятся задачи, которые изначально не были видны. Или задачи, которые кажутся знакомыми, но в итоге приносят сюрпризы. Поэтому даже при наличии ТЗ всегда нужно учитывать «коэффициент неопределенности».
Итак, в реальности ТЗ никогда не бывает идеальным:
Что делать?
Очень часто ошибка в оценке сроков происходит не из-за плохого планирования, а из-за разного понимания конечного результата. Вы думали, что нужно сделать MVP, а заказчик рассчитывал на полноценный продукт. Вы готовили демо, а продуктолог ждал стабильную версию с масштабируемой архитектурой.
Представьте себе, что вы разрабатываете нейросеть для обучения пользователей языку Лики (естественный язык из семейства Торричелли в Папуа — Новой Гвинее). Вам и вашей команде кажется очевидным, что это - задача на Research. Вы называете сроки и успешно укладываетесь в них. Но, к вашему удивлению, вместо восхищения, что «продукт научился говорить на языке папуасов и почти не ошибается», на вас сыпется шквал негодования, так как представители бизнеса ожидали от вас готовый продукт с оптимизацией ресурсов на AWS. Не называю имен компаний и реальной цели продукта, но это — действительный кейс.
Нужно чётко различать:
Если проект начинается как MVP, но превращается в полноценную систему — это прямой путь к провалу сроков, если не договориться об этом заранее. Все стороны — от разработчиков до бизнеса — должны понимать, что именно строится на первом этапе и какие у этого последствия для масштабирования.
Как избежать проблем?
Каждый проект содержит в себе риски: технологические, организационные, юридические. Это могут быть:
Я хотел бы сказать, что крайне важно донести риски до заказчика и получить от него пруф на готовность к возможным последствиям. Но, запомните, заказчик никогда не будет на вашей стороне в этом вопросе. Все, что вы можете и должны – максимально минимизировать риски и заложить время на их решение.
Методы оценки проекта (PERT, Planning Poker, Wideband Delphi)
Для минимизации субъективных ошибок и неопределенности есть проверенные методы оценки сроков:
PERT (Program Evaluation and Review Technique) — это инструмент управления проектами, предназначенный для анализа сроков выполнения задач. Он был разработан в 1950-х годах для сложных проектов с высокой неопределенностью, таких как разработка ракетных систем (проект Polaris).
PERT помогает определить:
Допустим, задача имеет оценки:
Преимущества:
Недостатки:
PERT полезен для сложных проектов, где важно оценить риски задержек. Он позволяет менеджерам планировать сроки с учетом оптимистичных и пессимистичных сценариев.
Planning Poker — используется в Agile-командах (чаще всего мы применяем именно этот метод). При оценке сметы сложные или спорные задачи помечаются в комментариях, как задачи для оценке методом покерного планирования. После чего собирается группа для проведения данного мероприятия.Planning Poker — это техника оценки задач в гибких методологиях разработки, таких как Scrum. Она помогает команде достичь консенсуса в оценке сложности задач, используя story points.
В сессии обычно принимают участие разработчики, тестировщики, аналитики и другие члены команды, которые будут работать над проектом. Для оценки используются карты с числами, например, из последовательности Фибоначчи (1, 2, 3, 5, 8, 13, 21 и т.д.).
Проектный менеджер или бизнес-аналитик представляет задачу. Он объясняет, что нужно сделать, зачем это нужно и какие критерии приемки должны быть выполнены. Команда задает вопросы для полного понимания задачи.
Каждый участник выбирает карту с оценкой. Оценка проводится в story points, которые отражают сложность задачи, объем работы и неопределенность. Чем больше число, тем сложнее задача.
Оценка проводится анонимно. Участники не должны влиять друг на друга, поэтому карты переворачиваются одновременно.
Обсуждение расхождений. Если оценки сильно различаются (например, один участник поставил 2, а другой — 8), те, кто поставил самые высокие и самые низкие оценки, объясняют свою позицию. Это помогает выявить недопонимание или учесть аспекты, которые кто-то упустил.
После обсуждения команда снова оценивает задачу. Процесс повторяется, пока не будет достигнут консенсус.
Пример:
Wideband Delphi — это структурированный метод прогнозирования и оценки, основанный на мнении экспертов. Он был разработан в 1940-х годах корпорацией RAND для военных проектов, а затем адаптирован для управления IT- и инженерными проектами.
Задача: оценить время разработки нового модуля ПО.
Раунд 1 (оценки экспертов в днях):
Медиана: 20 дней Диапазон: 10–30 дней
Обсуждение:
Раунд 2 (скорректированные оценки):
Итоговая медиана: 20 дней
Wideband Delphi – это мощный инструмент для консенсусной оценки, особенно полезный в условиях неопределенности. Он сочетает независимость мнений с коллективным анализом, что повышает точность прогнозов. Данный метод мы использовали в проектах для Т Банк. Метод дает максимально точную оценку, но, как было указано выше, очень зависит от конкретных экспертов. Не подходит незрелым командам.
Опыт прошлых проектов
Один из самых надежных способов улучшить оценку сроков — опираться не только на интуицию и опыт, но и на фактические данные из завершенных проектов. Однако на практике многие команды либо не собирают такие метрики, либо не анализируют их системно.
Допустим, в прошлом проекте было:
Вывод:
Данные прошлых проектов — это «калибровка» для экспертной оценки. Они не заменяют опыт, но делают его точнее. Чем больше статистики, тем меньше неожиданностей в новых сроках.
Дополните свою систему оценки метриками, и вы увидите, как растет точность прогнозов.
Всем добра!
И помните, ошибки в оценках неизбежны. Важно учиться на них и корректировать процесс всю жизнь)