Чтобы компания работала бесперебойно, задачи прогнозируемо двигались по этапам, а результат можно было получать точно в срок, важно изначально правильно оценивать время выполнения задач. Ошибки на этапе такого планирования могут дорого обходиться, поэтому проблемой оценки задач занимаются многие компании.
Привет, Хабр. Меня зовут Артур Нек. Я Канбан-консультант, основатель компании Neogenda и управляющий партнер Kaiten. В этой статье поделюсь опытом компании Kaiten в поиске работающего способа оценки времени выполнения задач: с чего начинали, с чем столкнулись и что выбрали в итоге.
Первые шаги: освоение первого академического метода
На заре становления нашей команды мы часто сталкивались с проблемами прогнозирования времени выполнения задач. Без четкой стратегии при определении сроков мы то закладывали слишком жесткие дедлайны, то заканчивали проекты в разы быстрее планируемого, и они зависали, поскольку другие отделы ждали их, например, только через неделю. И тот и другой сценарии нас не устраивали. В итоге мы решили найти четкий алгоритм оценки времени выполнения задач.
Один из классических способов определения сроков выполнения задач — предиктивная оценка. По факту это предположение, при котором используют абстрактную величину и сопоставляют ее с реальным временем выполнения задач. Именно с этого метода в свое время мы начинали путь в поиске метода оценки времени выполнения задач.
Подход подразумевает, что нужно взять сложную задачу, разделить ее на подзадачи, а подзадачи разделить на отдельные процессы, каждый из которых оценить.
Например, при создании приложения можно выделить массивы задач разработки, тестирования и дизайна, а в каждом из массивов выделить отдельные процессы.
В нашем случае опробовать этот метод «в бою» было просто: мы используем Kaiten для управления проектами и изначально на дашборде дробим все проекты на части, за которые отвечают разные специалисты и департаменты. То есть нам было достаточно посмотреть, из каких задач и подзадач обычно состоит проект, и оценить, сколько времени занимает каждый отдельный этап.
Логика в следующем:
берем задачу — например, разработку новой фичи приложения;
смотрим, из каких подзадач она состояла;
оцениваем, сколько ушло времени на каждый этап — например, на тестирование и на выкатку в прод.
В следующий раз, когда в команду прилетит схожая задача, при оценке сроков выполнения можно отталкиваться от полученных результатов — например, сразу закладывать на тесты и релиз по десять часов.
Такой подход позволяет не только прогнозировать время на выполнение всей задачи, но и рассчитывать нагрузку на спринты — успеем ли, например, внедрить в бэкенд новую фичу в рамках одного спринта или нет.
В теории всё прекрасно, но на практике мы быстро поняли, что подход дает существенную погрешность: при оценке задачи из десяти подзадач мы должны сложить десять известных величин (продолжительность выполнения каждой подзадачи) и получить общее время. Такой «конструктор» никак не учитывает, что одни процессы можно выполнять одновременно, а другие требуют продолжительной подготовки, которую никто не считает.
В итоге от этого метода мы быстро отказались.
Попытка номер два: переход на уровень выше
Мы решили протестировать метод, который отказывается от привязки к спринтам и условным человеко-часам, а учитывает только фактическое время на выполнение всей задачи.
Здесь алгоритм такой:
Открываем сервис управления проектами (например, мы делали это через Kaiten), записи, заметки или другие источники и находим все похожие задачи.
Из всех отсортированных задач выделяем проекты с приблизительно одинаковым количеством подзадач. Главное — чтобы задания разного масштаба не попали в одну выборку. Например, мы не смешивали разработку приложений и разработку одной новой функции.
Смотрим, сколько обычно занимает путь задачи от Backlog к Released.
Такого анализа должно быть достаточно, чтобы определить, за сколько времени чаще всего выполняется та или иная задача.
Причем чем больше схожих по сложности и объему задач было выполнено, тем лучше. Тут всё просто: если в выборке пять задач и две из них сделали за 3 дня, а другие — за 1, 2 и 5 дней, прогнозирование сводится к гаданию на кофейной гуще. Аналитика на выборке в 100 задач будет явно точнее и объективнее.
Мы пошли по этому пути — изучали в Kaiten подробную статистику по времени и выполненным задачам с диаграммой распределения, после чего закладывали в прогноз сроки, которые встречались чаще всего.
Но и этот подход оказался несовершенным.
Во-первых, подход опирается на то, что задачи одного объема и сложности можно выполнить примерно за одинаковое время. Но в реальных условиях принцип «смогли тогда — сможем и сейчас» не работает.
Во-вторых, в книге «Agile: оценка и планирование проектов» Майк Кон выдвинул теорию, что вероятность реализации задачи и сроки ее выполнения сопоставимы с количеством Story Point’ов, приходящихся на задачу. Например, если однопунктовую историю можно реализовать за 12 часов, то на трехпунктовую потребуется 36 часов. Предложенная теория хороша тем, что позволяет строить линейные графики корреляции, то есть относительно просто прогнозировать время выполнения задач.
Наш опыт показал, что в реальных условиях распределение времени решения задач не нормальное, а логарифмическое.
Более того, мы столкнулись с тем, что есть кейсы, когда на выполнение как, казалось бы, простой задачи, так и заведомо сложной уходит одинаковое время. Это не правило, но довольно распространенная ситуация. Таким образом, ни прогнозируемой зависимости от сложности, ни возможности оценить задачу «в вакууме» нет.
Анализ проблем и выработка своего подхода
После проверки второго классического метода и получения провальных результатов мы поняли, что причина ошибок в прогнозировании по любому из базовых и энциклопедических методов — учет не всех факторов, влияющих на срок выполнения задачи. В таких условиях любая среда становится плохо предсказуемой.
В итоге мы решили отойти от концепции «универсальных» методов, которые на практике просто не работают и у нас не прижились, и выработали свой подход. Согласно ему при получении задачи для ее оценки учитываем множество переменных, в том числе:
Отдых, праздники, настроение. Часть специалистов банально может быть в отпуске, и без них команда уже не «затащит» сложную задачу в прежнем темпе.
Степень сформированности запроса заказчика. Можно провести десятки встреч, получить сотни файлов с техническим заданием, но всё равно не понимать, что хочет получить заказчик в итоге. Причем не обязательно проблема в заказчике, который не может сформулировать мысль, — может, просто условный деврел не объяснил правила заполнения ТЗ или менеджер решил взять в работу сырую задачу с формулировкой «они технари, им виднее — в процессе сами поймут». Нередко «не поймут» или «поймут неверно», поэтому на решение задачи уйдет больше времени, чем обещано статистикой.
Сложность задачи. Важно вникнуть в задачу и выявить хотя бы часть подводных камней еще на этапе ее согласования. Это нужно, поскольку сама задача может быть простой и выполнимой за два-три дня, но будет иметь непонятный «обвес», который станет тяжелым бременем и потребует несколько дополнительных недель.
Наличие достаточных ресурсов, специалистов, компетенций. Особенно остро стоит вопрос с компетенцией — команда может быть полностью укомплектована но, например, из-за «текучки кадров» это будут не те же люди, которые делали похожую задачу в прошлый раз. В итоге опыта в решении конкретного кейса у команды не будет.
Непредвиденные обстоятельства, которые могут быть упущены из горизонта планирования или случиться неожиданно. Нельзя быть уверенным, что условный frontend-разработчик завтра не сломает ногу или тестировщик не напишет заявление на увольнение. Гарантировать отсутствие таких «нежданчиков» просто нельзя, поэтому в сроки на решение задачи надо закладывать определенный запас.
Загрузку команды. Команда уже может быть перегружена. В таком случае даже на простую задачу может банально не хватить времени или фокус с нее будет смещен.
Более того, после нескольких «боевых тестов» такого подхода мы поняли, что лучше решать не прямую, а обратную задачу, то есть не «когда это будет сделано», а «будет ли это сделано к ХХ августа».
При таком подходе легче учесть все факторы, оценить силы команды и даже конкретизировать задачу с помощью наводящих вопросов в духе:
Понятна ли сложность задачи?
Мы будем делать только эту задачу?
Уже понятно, как решать задачу?
Есть ли зависимость от внешних подрядчиков?
Понятно, что, если команда будет делать только одну задачу и не будет зависеть ни от кого, указать корректный срок выполнения проще — обеспечивается предсказуемость.
Следуя такому подходу, ориентированному на учет множества переменных без привязки к прошлому опыту, мы смогли обеспечить высокую точность прогнозирования. Погрешность если и есть, то минимальная и в пределах допустимого. Сейчас мы используем этот паттерн как основной и не планируем от него отклоняться.
Рекомендации на основе нашего опыта
Чтобы правильно прогнозировать время выполнения задач, нужно:
Категоризировать все поступающие задачи: непонятные, простые, сложные. Причем от непонятных лучше сразу отказываться.
Собирать максимум информации о задачах: уточнять желания заказчика, формировать требования. Чем больше уточняющих данных на входе, тем выше точность прогноза.
Учитывать доступные ресурсы и непредвиденные обстоятельства. В идеале закладывать время с запасом.
Ограничивать задачи, поступающие в работу. Сложность задач должна быть допустимой при текущей загрузке команды, а количество одновременно выполняемых задач ограничено.
Следование этим рекомендациям сделает систему работы команды стабильной, а оценку времени — действительной.
