Начну с определений.
Оценка — процесс установления значимости, стоимости, ценности уже существующего объекта.
В английском языке: Estimation/estimating — to judge tentatively or approximately the value, worth, or significance of; to determine roughly the size, extent, or nature of; to produce a statement of the approximate cost of
Легко понять, что и в английском и русском языке «оценка сроков» невозможна, возможна «оценка времени».
К сожалению, до сих пор используется термин «оценка сроков».
Оценка времени — прогнозирование времени работы сотрудника, отдела или компании, необходимого для выполнения какой-то работы.
Хочу попытаться рационализировать применимость инструмента «оценка времени» и выяснить границы его применимости.
Чтобы понять, нужна ли эффективность инструмента вообще, нужно сначала определиться с целью применения инструмента.
Я задал вопрос «для чего менеджеры просят оценить время» в нескольких сообществах, и вот какие основные ответы получил:
- ➖ «чтобы понять нагрузку на команду»
- ➕ «тендер имеет конкретные сроки»
- ➖ «чтобы бизнес знал, когда»
- ➖ «чтобы бизнес понимал, сколько стоит производство фичи»
- ➖ «чтобы бизнес мог выбрать, какую фичу делать первее»
Попытаюсь разобраться в каждой причине.
Я не смог разобраться с тем, как связана нагрузка команды и желание оценить время разработки.
Продуктовые компании занимаются созданием новой ценности для своих клиентов и обслуживают уже созданную.
Ценностью может быть как сформулированный запрос клиента, как и гипотеза менеджера по продукту, так и исправление дефекта, влияющего на работу клиентов.
Если на вход в разработку поступает больше запросов, чем разработка может выполнить, то есть всего три варианта решения этой проблемы:
- подавать меньше запросов (меньше гипотез о новых нуждах от продуктового менеджера)
- смотреть на потери информации в процессе производства и решать проблемы, найденные там
- расширять команду
Важно именно в вышеозначенном порядке проводить мероприятия, потому как они следуют в порядке убывания важности.
Если улучшать качество гипотез в апстриме (от продуктовиков) и откидывать больше «некачественных»,нужные пользователю, и потери информации не так важны, и команду не нужно расширять.
- Алексей Пименов делал недавно хороший доклад про работу с апстримом.
Если потери информации в процессе производства уменьшить, то меньше будет непродуктивной работы, и команду не нужно расширять.
Расширение команды — последний и наименее эффективный способ борьбы с проблемой «команда выполняет мало», так как расширение команды — очень дорогой и управленчески сложный процесс.
В любом случае, я не вижу, как связана «нагрузка команды» и желание пытаться оценить время выполнения запросов. Если вы понимаете, напишите мне пожалуйста.
➖ Вывод: инвестиции в оценку времени не оправданы.
Ограничение по времени тут внешнее для компании, потому кажется, что оценку времени приходится проводить.
Заказчик либо доподлинно знает ожидаемую выгоду от покупки произведённой вами системы, либо по каким-то иным (внешним для компании-исполнителя) причинам готов потратить выделенную сумму.
Компании-исполнителю же необходимо оценить, имеет ли исполнение контракта экономическую целесообразность, для этого же оценку времени придётся выполнить.
➕ Вывод: инвестиции в оценку времени оправданы.
Максимально абстрактное желание, в котором хочется разобраться.
Слышал следующие примеры причин такого желания:
- маркетинговая кампания стартует Х числа, и хочется понять, успеет ли команда запустить функционал
- событие внешнее произошло (внешнеполитическое, или экономическое, например: ЧМ по футболу), и надо понять, успеет ли команда запустить функционал
- нужна координация работы отделов
Кажется, что ситуация, когда разработку делают «заложником» некорректно спланированного маркетинга, не является нормой.
Планирование и проектирование маркетинговых работ проще (меньше неизвестных), чем планирование и проектирование работ по производству ПО.
Стало быть, ограничением в этой связке является именно процесс производства ПО, и «завязывать» работы стоит на производство ПО.
Сравните два сценария:
- разработка реализует функционал, маркетинг запускает рекламу готового функционала
- маркетинг говорит «кампания запускается тогда-то, реализуйте»
Кажется, что первый вариант не провоцирует ухудшение качества и не требует траты времени на оценку времени.
➖ Вывод: инвестиции в оценку времени не оправданы.
Иногда происходит важное внешнее событие, которое является поводом выполнить определённую разработку к определённому сроку.
В такой ситуации, кажется, оценку времени необходимо проводить, чтобы понять, как можно обеспечить выделение прогнозируемого времени с целью успеть в срок.
Вопрос, на который важно ответить в этом случае — насколько часто происходят внешние события, влияющие на работу бизнеса? Раз в год?
Если такие события приключаются чаще, то, возможно, стоит пересмотреть процессы работы?
➖ Вывод: инвестиции в оценку времени не оправданы.
Интересно разобраться в причинах этого желания.
Часто описывают следующие причины:
- чтобы мог сравнить фичи по стоимости
- чтобы понять, «стоит ли овчинка выделки»
Если от одной фичи бизнес планирует получить $1M, а от другой $2M, кажется, очевидно, что надо выбирать вторую.
«Планирует получить» тут — гипотеза продуктовой команды.
Чтобы выбирать между двумя прогнозами, нужно знать вероятность успешности каждого.
Есть ли статистика хотя бы по тому, насколько точны были прогнозы выручки раньше?
Если статистика есть, и прогнозы бизнеса сбываются с хорошей вероятностью, то, видимо:
➕ Вывод: инвестиции в оценку времени могут быть оправданы.
Если такой статистики нет, можем ли мы осознанно выбирать между значениями «$1M» и «2M»?
Кажется, что тут, скорее, «прыжок веры» — то есть можно просто брать любую из этих двух фичей в разработку.
Итак, мы решили делать какую-то из фичей. Дальше часто встаёт вопрос «стоит ли овчинка выделки».
Определение «стоит ли овчинка выделки» — это определение целесообразности разработки.
Логично заключить, что разработка тем целесообразнее, чем больше выгоды получит компания от реализации фичи.
Стало быть, нужно сравнить прогнозируемую стоимость разработки (выраженную во времени) и прогнозируемую выгоду от реализованной фичи.
Подразумевается, что, как и в предыдущем случае, бизнес умеет более-менее достоверно прогнозировать «выхлоп» от фичи.
Предположим, что выбрана была фича с прогнозируемой выручкой $1M.
Как понять, стоит ли её брать в работу?
Если прогностическая мощность гипотезы бизнеса (о выручке от фичи) базируется на статистике того, как сбывались разные другие прогнозы бизнеса, кажется логичным взять такое же по прогностической мощности предсказание сроков исполнения фичи.
Если совсем просто:
- бизнес говорит «такая фича наверное принесёт $1M, мы раньше редко ошибались в прогнозах»
- команда разработки говорит «такая фича наверное займёт 2-5 недель, мы раньше редко ошибались в прогнозах больше, чем в 2,5 раза»
Понятно ли, что ценность прогноза «слева» (у бизнеса) сильно выше, чем ценность прогноза «справа» (у команды разработки)?
Вообще получается, что если бизнес «не умеет» прогнозировать выгоду от производимой фичи, то и прогнозировать сроки исполнения на стороне разработки нет никакого смысла.
Какой смысл пытаться разобраться, займёт производство фичи три недели или три месяца, если ни та ни другая инвестиция времени в производство не оправдана?
Если же бизнес признаёт, что гипотеза «фича выстрелит» является лишь «ощущением», то есть иррациональна полностью, то вполне резонно заключить, что требовать рационального подхода к разработке просто бессмысленно — ведь велика вероятность, что бизнес целый год приносит на реализацию фичи, не приносящие никакой прибыли.
➖ Вывод: инвестиции в оценку времени не оправданы.
Мы разобрались с причинами, которые могут вынуждать оценивать время выполнения задач. Мы также поняли, что оценить ещё не потраченное время — значит попытаться спрогнозировать, сколько занять может разработка.
Теперь разберёмся c типами оценок:
- оценка, основанная на статистике
- оценка, основанная на экспертном мнении
Если сотрудник или отдел уже выполнял похожие задачи много раз, можно построить примерную картину того, сколько времени подобные задачи занимали. Полученное время можно и использовать в виде оценки.
Стоимость процедуры оценки зависит от «точности» сопоставления текущей задачи и набора каких-то подобных задач, выполненных ранее. Чем точнее нужно сопоставить, тем больше времени приходится тратить на декомпозицию и «погружение» в задачу (тем ближе этот тип оценки становится к оценке на основе экспертного мнения).
Таким образом, чем больше накоплена история выполнения разных задач, и чем точнее удаётся сопоставить оцениваемую задачу с какой-то уже выполненной, тем точнее будет полученная на основе статистики оценка.
Если подобных задач ещё не было выполнено, оценка на основе статистики не может быть выдана.
Эксперт или эксперты могут проанализировать задачу и выдать свой прогноз просто основываясь на своём опыте и знаниях. По сути, этот тип оценки похож на оценку, основанную на статистике, только статистика и «чуйка» у каждого специалиста своя.
Чем крупнее по объёму задача, и чем точнее необходимо дать оценку, тем больше объём инвестиций в декомпозицию и проектирование.
Эти два типа оценки лежат в основе практически всех систем прогнозирования.
Точность оценки прямо пропорциональна степени «понятности» оцениваемой задачи.
«Понятность» — это степень проработанности «чертежа», «плана», «скелета» — чего-то, что гарантированно будет однозначно интерпретировано и реализовано.
Возьмём за пример проект строительства котельной в г. Анадырь. Инженерно-строительная бригада может ответить точно, сколько займёт такое строительство, потому как осуществляться оно будет по точным чертежам и готовым сметам, с уточнениями в виде «северных» поправок.
Точно такую же котельную по точно такому же плану другая инженерно-строительная бригада такой же квалификации может выполнить за то же время в г. Анадырь.
Чертежи же, схемы и сметы, вместе с принципами строительства и необходимыми материалами прорабатывают в специальном НИИ строительства.
Процесс научно-исследовательской и опытно-конструкторской фазы давным-давно выполнен другими людьми, и инженерно-строительная бригада лишь компонует готовые стандарты и подходы, гарантированно работающие вместе с гарантированными рисками.
В случае производства ПО, требования и контекст всегда различны, готовых «чертежей» и смет не существует, процесс опытно-конструкторской (а порой и научно-исследовательской) «не устаканен».
- время трансформируется в сроки
- сроки трансформируются в дедлайны
- дедлайны создают стресс