Как оценить задачу
В статье изложен гайд по построению процесса оценивания задач разработки, применение которого позволит аргументированно отвечать на вопросы заказчика в духе “За сколько вы это сделаете”, а также добавит пресказуемости в планы загрузки проектных команд.
Благодарности
Большое спасибо моим коллегам Илье Мясникову и Алёше Янке за помощь в подготовке контента и моей жене Алисе Литичевской за ее вычитку и редактуру.
Лирическое отступление
Для того, чтобы не было завышенных ожиданий от результата, важно помнить, что любая оценка, будучи разновидностью прогноза, представляет собой некий компромисс. С одной стороны, чем точнее нужна оценка, тем больше времени она занимает, и уже возникает вопрос об оценки времени оценки, etc. С другой стороны, если зафиксировать объем времени, отведенный на оценку, то при оценивании задачи с высокой степенью неопределенности, снижается точность и, как следствие, полезность такой оценки. Список подобных не добавляющих ясности утверждений можно продолжить, в связи с чем в сообществе уже довольно давно продвигается тема, что эти самые оценки никому не нужны. Увы, при всей привлекательности и простоте такого подхода, он редко работает. Рано или поздно у кого-то из бизнеса возникнет закономерный вопрос “За сколько вы это сделаете?” и на него нужно будет аргументированно ответить и, в идеале, попасть в озвученные цифры.
Еще одной распространенной практикой является оценивание на основе разбиения задач на классы эквивалентности исходя из предположения, что время работы над задачами одного класса примерно одинаково. К сожалению, разбинение юзерсторей и, тем более, эпиков на классы является отдельной сложной задачей, требующей значительных временных затрат. Более того, результаты такой задачи, как правило, субъективны, поскольку зависят от оценивающего и его внутреннего понимания эквивалентности. Этот подход хорошо работает для сабтасок, на которые разбиваются юзерстори, именно в таком виде он и будет применен в данном гайде.
Снижение неопределенности
Прежде чем приступать к оцениванию, нужно узнать, зачем оценка нужна вопрошающему, ибо непонимание того, зачем что-то делается, всегда снижает качество результата. Ниже приведу несколько реальных примеров ответов на этот вопрос, а также того, как они повлияли на оценку.
Пример 1. Бюджет проекта согласуется сразу на весь год, поэтому работы должны гарантированно уложиться в озвученнную оценку. Все понятно, при оценивании нужно быть как можно более пессимистичным, считая, что все, что может произойти, обязательно произойдет.
Пример 2. Нужна примерная оценка для того, чтобы спланировать работу других продуктовых команд, которые будут потребителями создаваемого функционала. Также все понятно, нужна реалистичная оценка, нет нужды учитывать невероятные сценарии.
Пример 3. Согласно проекту нового договора, если команда не уложится в озвученный срок, то все последующие работы не будут оплачены. А вот тут непонятно. Отношения с заказчиком переходят в разряд “перетягивания каната”, их стоит либо поменять, либо закончить.
Как видите, вовремя заданный вопрос “Зачем нужна оценка” способен сэкономить немало нервных клеток, а также повысить качество самой оценки.
Снижение процессной неопределенности
Для повышения точности оценки необходимо хорошо понимать, на что при разработке тратится время, из каких конкретно шагов и ритуалов состоит процесс разработки команды, оценивающей задачу. Сюда относятся ежедневные стендапы, итоговые демо, ревью требований, приемка сделанного с бизнесом, etc. С каждой из выявленных активностей следует сопоставить коэффициент, характеризующий вклад активности в оценку задачи. Вычислить такой коэффициент в общем случае не самая простая задача, однако есть эвристики, позволяющие достичь вполне приемлемого результата. Так, допустим, раз в неделю проводится демо, длящееся час, на котором присутствет вся команда. Это значит, что демо занимает 2.5% рабочего времени в неделю, следовательно, ему соответсвует коэффициент 1.025 с возможной поправкой на время, необходимое на переключение контекста.
Когда список активностей составлен и коэффициенты определены, из него следует сделать чеклист, по которому можно будет пробежаться в конце оценивания и умножить промежуточный результат на все коэффициенты.
Снижение неопределенности по задаче
Пытаться “в лоб” оценить юзерстори или, тем более, эпик — плохая идея, такие задачи, как правило, имеют высокий уровень неопределенности, и при оценке они все равно мысленно расчленяются на сабтаски. Этот неявный процесс стоит сделать явным, как минимум, для того, чтобы и команда, и заказчик одинаково понимали, что конкретно планируется сделать в рамках задачи. После того, как получившаяся декомпозиция больше не вызывает ни у одной из сторон вопросов о том, что конкретно будет делаться и что получится в результате, ее следут зафиксировать на доске задач в виде сабтасков или чеклиста к задаче. Теперь, когда вся подготовка сделана, можно приступть к оцениванию.
Зафиксированный список сабтасков можно оценивать по аналогии на основе опыта, накопленного участниками команды в рамках как текущего проекта, так и всех предыдущих. На первый взгляд, процесс кажется достаточно простым: нужно найти похожую задачу в своем опыте и, в зависимости от текущего контекста, скорректировать время, затраченное в прошлом на ее выполнение. Реальность, увы, несколько сложнее. Декомпозиция подразумевает выбор и фиксацию конкретного решения задачи, имеющего свои сильные и слабые стороны, столкновение которых с реальностью порождает риски. Например, предлагаемое решение будет плохо работать на определенных данных, при этом не известно, какие данные будут вносить пользователи, следовательно, выбирая это решение, мы рискуем. О том, что делать с рисками, поговорим в последующем разделе.
Учет рисков
Существует изрядное количество способов описания и оценки рисков, полное рассмотрение которых выходит за рамки данного гайда. Для простоты примем, что для учета рисков при оценке необходим их вес в виде числа, описание лежащей в основе проблемы, а также ее технических и бизнесовых последствий.
Пример. Использование RabbitMQ в задаче гарантированной последовательной обработки сообщений для одного ключа не позволяет горизонтально масштабировать сервисы-обработчики без передеплоя. Как следствие, в момент нагрузки очереди не будут оперативно обрабатываться, что для некоторых бизнесов означает прямые финансовые потери. Итоговый вес расчитывается как произведение вероятности проблемы 10 и ее важности 10, оба значения берутся по дестибальной шкале, получаем вес 100.
После того, как список сформирован, риски нужно упорядочить по весу, в зависимости от требований к оценке сформировать задачи по купированию наиболее приоритетных из них, после чего оценить добавленные задачи вместе с остальными. Риски, которые остались не рассмотренными, также стоит сохранить в виде отдельного списка. Получившиеся результаты нужно обязательно утвердить у бизнеса, чтобы ни у одной из сторон не возникало в последствии вопросов, купирование каких рисков было учтено при оценке, а каких нет и почему.
Итоговое описание процесса
- Уточнить, зачем вопрошающему нужна оценка, поскольку понимание, для чего она нужна и как будет использоваться, повышает качество результата.
- Выявить, на что тратится время при разработке, и сформировать чеклист с коэффициентами, на которые будут умножаться “сырые” оценки.
- Выполнить декомпозицию предложенных к оцениванию задач на сабтаски и утвердить полученную декомпозицию с бизнесом для того, чтобы обе стороны одинаково понимали что в итоге будет делаться и какой результат будет получен.
- Описать риски и дополнить декомпозицию задачами по купированию наиболее приоритетных из них и, как и в предыдущем пункте, утвердить результаты у бизнеса.
- Выполнить оценку получившегося списка подзадач с учетом уже имеющегося опыта разработки.
- Умножить оценки на коэффициенты из сформированного в п. 2 чеклиста.
- В качестве результатов процесса зафиксировать итоговую декомпозицию с оценками, а также список рисков, которые не были рассмотрены при ее формировании.
Заключение
Применение предложенного гайда для построения процесса оценивания позволит сделать получение ответа на вопрос “За сколько вы это сделаете?” прозрачнее и предсказуемее, а главное, этот процесс можно будет улучшать. Мы в компании Byndyusoft проводим воркшопы по оцениванию задач для того, чтобы шарить понимание процесса, а также собирать фидбек для его улучшения.