Оценка задач в командах

Справедливая оценка задач всегда была камнем преткновения. Сколько себя помню, оценивали задачи очень условно и очень примерно. Чаще не попадали в сроки, чем попадали.

Всем привет. Меня зовут Макс Брызгалов. Я ведущий дизайнер в такси "Максим" и куратор комьюнити дизайнеров продукта "Дизайн Ресурсы". В сфере я уже более 6 лет, за это время поменял несколько ролей. Работал без процессов совершенно. Работал работником, которому объясняют, как наработать. Работал в команде, где помогал настраивать процессы. Наконец, настраиваю процессы в команде сам. Очень редко получается, что команда работает одинаковым составом несколько лет. Постоянно что-то меняется: люди, их роли, проекты и так далее.

Сколько времени мы ищем способы сделать работу более эффективной, столько и пытаемся сформировать критерии оценки работы.

Пишу о запуске продуктов. О поиске ценности и роста. О командах и процессах. Об интерфейсах и пользователях.

Подписаться на канал

- Бизнес рассматривает оценки как обязательства. Разработка как предложения;

- Для бизнеса понятны абсолютные оценки во временных отрезках;

- Оценка задачи в "человеко-часах" в 95% неправильная и почти всегда занижена;

- Оценка задачи требует существенных затрат множества людей, а сам процесс оценки не несёт бизнес-ценности;

- Скоуп представляет собой свалку задач. Нет понимания какая из задач приоритетнее.

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

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

Зачем нам вообще нужна эффективность? Она нужна затем, чтобы достигать тех же желаемых результатов с меньшими затратами ресурсов. Во многих случаях это означает, что у нас появляется возможность отправить высвобожденное на решение других насущных проблем и улучшать качество жизни.

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

Перед нами стояла цель: понять какой объём задач мы сможем выполнить за определенный отрезок времени (за спринт). Для этого нам подошла относительная оценка. Дальше я подробнее расскажу, что же она из себя представляет и как ее можно использовать внутри команд.

Для того чтобы понять, что такое относительная оценка хотел бы привести классический пример. Итак, для начала представьте себя астрофизиком, которому необходимо решить задачу по определению диаметров планет Солнечной системы. Сможете ли вы сходу назвать диаметр планеты Уран? Скорее всего, без помощи Google, ответить на вопрос будет сложно. Если оценка происходит в команде, вариантов будет огромное количество. Споры будут бесконечными и прийти к общему знаменателю будет практически невозможно. А если переформулировать вопрос: сколько диаметров Земли уместится в одном диаметре Урана? При ответе на этот вопрос обычно не возникает противоречий. Как правило, все сходятся на ответе 4 диаметра, что является верным ответом.

Когда мы сравниваем между собой объекты, оценка становится проще и в команде возникает меньше споров и противоречий. То есть за оценку берется не абсолютная величина(например в часах), а относительная (например в хвостах, размерах футболок и так далее).

Фундамент процесса оценки – увидеть значимость бизнес-задачи, сложность работы и основные риски. На основе этих данных происходит оценка.

Значимость бизнес-задачи (зачем результат выполненной работы нужен бизнесу). Минимально допустимый функционал, без которого задача будет иметь нулевую ценность для бизнеса.

Сложность работы. Как и в примере выше нам нужно определить какие объекты мы будем сравнивать между собой. Для этого определяем какую задачу будем считать самой простой (например задизайнить форму обратной связи. Эту задачу мы оценим в 1sp) и какую задачу будем считать самой сложной (например, разработать дизайн сервиса. Эту задачу мы оценим в 100sp).

Риски. Мы чего-то не знаем, не умеем, что-то зависит не от нас. Чем выше риски, тем выше диапазон оценок. В таком случае разумно попытаться снизить риски на этапе планирования: аналитика разного рода, консультация у экспертов, согласование вопросов с заказчиками.

Для себя я выделил несколько основных принципов, при которых оценка будет эффективна для команды.

- Высокая скорость оценки. Команда не тратит много ресурсов на оценку каждой задачи.

- Командная работа. Важно, чтобы в оценке принимала участие вся команда. Таким образом вы рассмотрите задачу со всех сторон, учитывая контекст, основные риски и разные точки зрения.

- Относительность. Сравнивать относительные объекты между собой проще, а выбор оценки вызывает меньше споров в команде

Стоит так же затронуть тему самой задачи. Все входящие запросы на этапе аналитики и планирования разбираются на составные части. Запросы превращаются в проекты. Будем считать, что под проектом имеется в виду комплекс действий для успешной реализации идеи. А проекты, в свою очередь, декомпозируются на задачи.

Задачи должны быть декомпозированы так, чтобы её выполнение не занимало больше 1 спринта. Стараемся придерживаться правила: задача = одно действие. Например, "Подготовить адаптив мобильной версии сайта". После того как задачи декомпозированы, можно переходить к приоритизации.

Сначала выделяем задачи с наибольшей бизнес-ценностью. Затем "Сложность работы". Риски. Потом в порядке важности все оставшиеся задачи.

Через несколько спринтов уже можно снимать первые метрики и посчитать какое количество sp делает команда за спринт. Следить за этой метрикой нужно постоянно, снимая показатели в конце каждого спринта.

Конвертировать в таком случае sp во время не нужно. Когда приходит запрос от бизнеса, на этапе анализа можно будет сказать сколько спринтов понадобится команде на то, чтобы этот запрос закрыть.