Как оценить задачи без Planning Poker и лишних слов
Привет, Хабр!
Меня зовут Александр, я занимаюсь релиз менеджментом в ИТ-компании TAGES. Эта работа требует быстрой поставки бизнес-ценности в условиях меняющегося мира. Однако непрерывность регулярных деплоев невозможна без четкого плана. А правильный план, в свою очередь, требует точной оценки трудозатрат.
В то же время большинство разработчиков на дух не переносят любые активности, связанные с оценкой времени. Даже методика Planning Poker не всегда находит отклик в командах. Это отчасти связано с предпочтением интровертных сотрудников избегать лишних встреч и звонков.
Впрочем, мой предыдущий опыт работы в авиационной отрасли подтверждает, что нелюбовь к оценке времени характерна не только для разработчиков, но и для авиационных инженеров.
Сегодня мы рассмотрим подход, который решает проблему точной оценки задач с минимальным участием разработчиков.
В предисловии к статье упоминается Planning Poker. Возможно, вы хотя бы раз о нем слышали, кому-то даже доводилось участвовать в нем. Эта техника помогает избегать «эффекта привязки».
«Эффектом привязки» ученые называют когнитивное искажение, свойственное всем людям и заключающееся в том, что оценка одного человека становится зависимой от ранее озвученной оценки другого человека.
Не будем подробно останавливаться на описании техники покер планирования — она достаточно подробно описана в Интернете, в том числе и на Хабре о ней есть немало достойных материалов.
Я поделюсь своим опытом и расскажу, как избежать «эффекта привязки» при оценивании задач без Planning Poker.
Эффект привязки
Давайте рассмотрим «эффект привязки» в контексте оценки времени. Представим, что мы собрали команду из 5 человек на груминг по бэклогу, в рамках которого происходит поочередный разбор, обсуждение и оценка задач.
В один момент кто-то из участников планирования высказал мнение, что данная фича является небольшой и для ее реализации потребуется, например, менее 16 часов.
В результате все последующие участники невольно будут отталкиваться от этой цифры и высказывать оценку с оглядкой на нее. Это может стать особенно серьезной проблемой, если первым высказал мнение авторитарный авторитетный участник.
Для наглядности рассмотрим такой пример:
Senior backend-разработчик Никита — ключевой участник команды, который в прошлом спринте сотворил чудо и затащил сложный функционал сразу на прод без единого бага. Однако в этот раз он не обладал всей информацией, в частности не знал, что для реализации новой фичи необходимы интеграции с внешними банковскими сервисами.
В то же время Алина, Middle backend-разработчик, об этом знает, поскольку была на встрече с архитектором, и изначально полагала, что на реализацию потребуется не менее 100 часов. Теперь после озвученной Никитой оценки она начинает колебаться («У Никиты же опыта больше!») и называет число, близкое к высказанному Никитой — 50 часов.
После непродолжительной дискуссии Никита и Алина соглашаются, что 40 часов с учетом интеграции с банковским сервисами хватит за глаза на реализацию фичи. Никита не только хороший разработчик, но и умеет хорошо убеждать других людей.
В итоге фича была реализована за 80 часов. И тут налицо проблема оценки времени — задача недооценена в 2 раза! А если такого «ошибочного оценивания» в бэклоге много? Сроки не ползут, они летят!
Если бы команда использовала покер планирование, то оценка Алины в 100 часов вызвала бы другой ход дискуссии и позволила бы увидеть всем участникам команды риски разработки данной фичи.
Цена Planning Poker
Несмотря на все достоинства, у покера планирования есть существенный недостаток — временные затраты многих специалистов одномоментно. Ведь, чтобы прийти к единому мнению, надо:
1. Собрать (отвлечь от работы) ряд специалистов.
2. Найти консенсус. Это редко происходит быстро, особенно, если все участники — опытные и придерживаются своего мнения.
Сильнее всего это чувствуется в больших командах. Полагаю, многие согласятся, что достигнуть консенсус между 2–3 участниками значительно проще, нежели в группе людей из 7 и более человек.
Если бэклог состоит в основном из несложных задач, то с большей вероятностью оценки разработчиков будут совпадать, так как находятся в узком диапазоне значений. В таком случае консенсус даже в большой команде достигнуть сравнительно легко.
В случае, когда бэклог состоит из нетривиальных сложных задач, либо степень неопределенности довольно высока, разброс в оценках, вероятнее, окажется значительным, а вас ждут долгие жаркие дискуссии.
Отметим, что здесь инвестиция большого количества времени оправдана, ведь вы с командой только что нашли потенциальные риски. К счастью, вы будете обсуждать их еще на ранней стадии разработки.
Так что покер планирования — блестящий инструмент, который стоит попробовать, если вы еще им не пользовались.
И рыбку съесть, и на елку влезть!
Представим, что у команды нет возможности проводить полноценный покер планирования. Однако существует потребность в достижении реалистичной оценки с учетом мнения разных исполнителей без эффекта привязки.
Предположим, что системные аналитики уже провели работу над новым эпиком: проанализировали требования и описали подробно постановки на разработку методов REST API.
Видим, что бэклог состоит из 14 новых задач, а в команде есть 3 backend-разработчика: Никита, Алина и Сергей. Нужно, чтобы они оценили эти задачи.
Следующие три раздела содержат подготовительные действия, которые необходимо выполнить, чтобы процесс оценки не отнимал много времени ни у вас, ни у разработчиков.
При желании можно пропустить это описание и сразу перепрыгнуть напрямую к разделу с оценкой времени. Однако понимание того, как устроены файлы, позволит адаптировать их именно под вашу специфику. Например, добавить столбец для еще одного разработчика или добавить макросы и дополнительные формулы, которые могут расширить функциональность инструмента.
Подготовительное действие 1. Основной файл с оценками
Данный файл (на примере Google Таблицы) будет содержать оценки всех разработчиков в одном месте.
Основной файл с оценками
1 — Название основного файла (в нашем случае это «Summary»).
2 — Название листа. В ячейке «B1» дублируем название листа (это пригодится в дальнейшем для настройки автоматических формул).
3 — Столбец будет содержать ссылки на Jira/Trello/Yandex Tracker, при переходе разработчик сможет изучить подробное описание выбранной задачи.
4 — Столбец содержит название и описание задачи (чаще всего оно совпадает с названием задачи в Jira).
5 — Столбцы с оценками времени от разработчиков, которые будут автоматически импортироваться из файлов разработчиков.
6 — Столбец, который будет содержать самую консервативную оценку по задаче.
7 — Столбец с медианной оценкой задачи.
8 — Столбец со средней оценкой задачи.
9 — Столбец с фактическим затраченным временем на задачу.
Подготовительное действие 2. Файлы с оценками для разработчиков
Для каждого разработчика необходимо создать отдельные Google Таблицы, в которых они будут выставлять оценки времени.
Первым делом создадим и настроим таблицу для Никиты:
Файл с оценками для разработчика
1 — Название файла содержит имя разработчика.
2 — Название листа. В ячейке «B1» дублируем название листа (это пригодится нам в дальнейшем для настройки автоматических формул).
3 — Столбец будет содержать ссылки на Jira/Trello/Yandex Tracker, данные будут автоматически импортироваться из основного файла (нашего «Summary»).
4 — Столбец содержит название и описание задачи, данные будут автоматически импортироваться из основного файла Summary.
5 — Столбец, в который разработчик будет вносить оценку времени в часах.
6 — Необходимо настроить доступ к файлу разработчика.
Предоставьте разработчику права на редактирование файла. Таким образом доступ к файлу будет только у вас и у разработчика Никиты. И даже если вы являетесь параноиком, вы точно гарантируете, что Алина не сможет подсмотреть оценки Никиты. Если только последний не захочет вступить с ней в сговор, но это уже риск, выходящий за рамки данной статьи :)
Настройки доступа
Теперь создадим такие же файлы для Алины и Сергея. Проще всего создать копии файлов и повторить пункты 1 и 6 для Алины и Сергея, то есть переименовать файл и настроить доступ под них.
Подготовительное действие 3. Настраиваем автоматический импорт данных
Для автоматического импорта данных воспользуемся функцией IMPORTRANGE(spreadsheet_url, range_string).
spreadsheet_url— ссылка на другую таблицу, из который мы хотим импортировать данные.range_string— диапазон данных в формате «SheetName! Range», который мы хотим импортировать.
Основной файл — Автоматический импорт оценок разработчиков
Синхронизация оценок времени
Столбец с оценками Никиты (ячейка С4):
=IMPORTRANGE("https://docs.google.com/spreadsheets/d/1icCY_nHpJMruFQPX0w1gD88G64xK75vK2uYWhD8Nhr4/edit?usp=sharing";$В$1&"!C2:C100")
Эта формула импортирует оценки времени, которые проставит Никита, из диапазона C2: C100 на листе «Бэклог» из файла «Никита». Обратите внимание, что название листа указано в ячейке B1.
Столбец с оценками Алины (ячейка D4):
=IMPORTRANGE("https://docs.google.com/spreadsheets/d/1gtaLDNGvInjfELgPqUDI4t0ZQdSYUVkcTgmriv1Ua_g/edit?usp=sharing";$B$1&"!C2:C100")
Столбец с оценками Сергея (ячейка E4):
=IMPORTRANGE("https://docs.google.com/spreadsheets/d/1AlMWqIUrVFIzgT3C9N-g2tPGQ5EtHOZlk6I6IRLxQtY/edit?usp=sharing";$B$1&"!C2:C100")
Эти формулы мы вставляем в первые строки столбцов с оценками. При этом важно открыть доступ для подключения внешних таблиц.
Настройка доступа
Файлы разработчиков — Автоматический импорт ссылок на Jira и описание
Синхронизация описания задач
Столбцы Jira issue + Описание (ячейка A4):
=IMPORTRANGE("https://docs.google.com/spreadsheets/d/1uMWqq6-OQmnrJkAko6_F3y87bIy0ZwjBuEYm9vCuxP4/edit?usp=sharing";$B$1&"!A2:B100")
Эта формула импортирует ссылки на трекер и название задачи из диапазона A2: B100 на листе «Бэклог» из файла «Summary». Обратите внимание, что название листа указано в ячейке B1.
Оценка времени
Итак, все готово для того, чтобы попробовать инструмент в действии.
Добавим ссылки на трекер, а также названия и описание задач в основной файл «Summary». Это описание автоматически импортируется в файл разработчиков для оценки времени.
Описание задач
Напишем в чат нашим разработчикам и попросим их оценить 14 новых задач:
Никита, Алина, Сергей, привет!
Пожалуйста, оцените сегодня задачи на листе «Бэклог».
Необходимо внести оценку в часах.
Округлить до целого значения.
Если есть затруднения, то можно не проставлять оценку.
Ссылки на файлы:
Никита
Алина
Сергей
Не будет лишним в первый раз проговорить с командой для чего это делается, рассказать про эффект привязки, и показать, что от них ожидается.
Разработчик самостоятельно откроет специально подготовленный для него файл, зайдет по ссылке Jira, ознакомится с постановкой, подготовленной системным аналитиком, и проставит часы для каждой задачи.
Будем считать, что информация, описанная в постановке, достаточна для корректной оценки времени. Вопрос про полноту входных данных оставим за рамками данной статьи.
Файл с заполненными оценками
После того, как все разработчики выставят оценки, будет автоматически собрана информация, с которой можно дальше работать.
Итоговая таблица с оценками бэклога
1 — Оценки задач (часы).
2 — Максимальное значение (часы).
3 — Медианное значение (часы).
4 — Среднее значение (часы).
5 — Общие суммы по максимальной, медианной и средней оценкам (в часах).
Как можно заметить, оценки Никиты, Алины и Сергея практически совпадают. Из этого можно сделать вывод, что у ребят есть консенсус о трудоемкости задач. Причем, мы достигли своей цели, избежав эффекта привязки и больших временных затрат.
Далее можно разложить этот объем работ эпика по спринтам, чтобы определить срок реализации, о чем было подробно рассказано в другой статье.
Иное дело, если оценки будут значительно отличаться. Однако даже в таком случае мы все равно сэкономим время, поскольку можем точечно обсудить только те задачи, где есть большой разброс в оценках.
Анализируем оценки
Например, здесь вы как руководитель должны:
Уточнить у Алины, почему она полагает, что на реализацию методов createCart и updatedClient необходимо столько времени, а также какие она видит риски.
Уточнить у Сергея, почему он не смог оценить метод deleteCart, а также какие моменты ему непонятны.
При необходимости можно организовать встречу по обсуждению конкретно этих вопросов уже в расширенном составе.
Ретроспектива
К таблице с оценкой полезно возвращаться после завершения работ, чтобы проанализировать разницу между плановым и фактическим временем. Такие действия будут полезны и вам, как руководителю, и разработчикам для улучшения навыка оценки трудоемкости.
Ретроспектива
1 — Фактическое время совпадает с оценкой времени.
2 — Фактическое время больше оценки времени (недооценка).
3 — Фактическое время меньше оценки времени (переоценка).
Дальнейшее использование
Подготовительные действия, с помощью которых мы настроили автоматический импорт данных, позволяют достаточно легко переиспользовать данный подход для оценок новых работ.
Самый простой вариант:
1 — Обновите ссылки и описание задач в основном файле «Summary».
2 — Удалите старые оценки разработчиков в их файлах.
Теперь вы можете снова проводить оценку в тех же файлах.
В своей практике мы предпочитаем немного другой вариант, при котором дублируем листы со списком задач, чтобы данные сохранялись. Таким образом у нас сохраняются исторические данные по прошлым оценкам:
Взаимосвязь файлов
Итог
Мы рассмотрели инструмент оценки задач, который может помочь избежать эффекта привязки практически так же хорошо, как покер планирование. Однако стоит отметить, что описанное не является его заменой. Цель статьи — поделиться еще одним инструментом, который может расширить арсенал успешного руководителя и помочь в решении похожей активности.
Как и у любого подхода, у данного инструмента есть свои плюсы, минусы, возможности и ограничения применения. Тем не менее в нашей практике он зарекомендовал себя достаточно хорошо. Буду рад, если инструмент окажется полезным и в вашей практике.
Буду рад вашим комментариям с идеями, замечаниями и мыслями.
Ссылка на папку с файлами для оценки https://drive.google.com/drive/folders/1jx7tunEft2ax90UcJzbTgI3rRC7bkEQM? usp=sharing
