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

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

Вопрос: как меньше тратить времени на оценку задач и больше на действительную полезную работу по проекту?

Что такое эстимейты?

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

Уточню, речь про оценки в разработке новых продуктов. Если речь идёт о штамповании однотипных задач на потоке, то и проблемы такой нет.

Эстимейты — устаревшая практика, которая не добавляет ценности в процесс разработки продуктов.

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

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

Как перестать гадать?

На эту тему есть два сочетающихся закона, оцените иронию.

  • Закон Паркинсона — работа расширяется, чтобы занять всё отведённое под неё время.
  • Закон Хорстмана — работа сокращается, чтобы уместиться в отведённое на неё время.

Основной трюк в том, чтобы перейти от «как долго это займёт» к «что мы можем успеть за этот промежуток времени». Вот несколько шагов на пути к этому.

Перейти к прогнозам на данных вместо оценок на глаз

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

Резать и нормализовывать задачи

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

Во-первых, на длинном промежутке времени это неважно. Выбросы сгладятся.

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

Таким подходом снижается риск позднего обнаружения скрытой сложности.

Движение небольшими задачами несёт дополнительную пользу:

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

Флексить функционал

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

Добавление времени или повышение стоимости — плохие решения в этих ситуациях. Понижать качество — не вариант.

Не торговаться за часы

Самая большая боль оценок — это оплата за часы из оценок. Скрытая сложность и новые вводные неизбежно приведут к изменению состава работ. Но если в договоре, письменном или устном, был коммитмент на функционал за часы, то будет спор. И в нём обязательно кто-то будет в проигравших. Как правило, исполнитель, который будет кранчить за свой счёт под давлением клиента или начальника. При этом взаимное доверие снизится.

Чтобы этого избежать, лучше договориться либо на оплату фактического времени — time and material. Или продавать время большими блоками, например, неделями или месяцами без привязки к конкретным задачам. Да, последнее очень похоже на зарплату :)

Куда копать дальше?

Моё отношения к оценкам за годы работы прошло через все стадии: от страха через покорение экселя к пониманию бессмысленности и переосмыслению.

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

Вот ещё несколько вопросов и возражений, которые часто возникают на этом этапе.

Как же стори поинты?

Про них уже писал, даже Рон Джеффрис, который считается их изобретателем, считает их фигней.

Что с оценками в размерах футболок, попугаях и прочем?

Единственная польза от этой оценки — понять, что задачи недостаточно декомпозированы.

Что читать?