Привет, Хабр!
Меня зовут Александр, я занимаюсь релиз менеджментом в ИТ-компании 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
