Как оценивать ресерчи

Давай для начала определимся с тем что я имею ввиду под "ресерчем".

Ресерч — это те самые задачи, где непонятно вообще ничего. Критериев приемки нет, внешние интеграции, или завязка на другие команды. Чтобы хоть как-то оценить такие задачи, сначала нужно убрать хотя бы часть этой неопределенности. И только тогда можно попытаться выдать что-то, что хотя бы отдаленно похоже на адекватную оценку.

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

Когда сталкиваемся с задачами, полными неизвестного, кажется, что самый простой выход — угадать, сколько нужно заложить сверху, что бы точно не ошибиться. Звучит заманчиво? Но вот в чем загвоздка: такой подход делает небольшие ресерчи большими задачами, а большие ресерчи причиной продолбанного спринта. В итоге бизнес получает иллюзию планирования из-за того что видит оценку, которая проставленна наугад.

Для нашей команды оценка это обещание, которое мы даем бизнесу. Если мы закоммитились на набор задач в спринте, то обязаны их закрыть. Это вопрос не только завершенных тикетов, но и предсказуемости команды. Чем стабильнее мы в оценках, тем больше бизнес нам доверяет. А доверие — это ключ к свободе: чем больше бизнес доверяет команде, тем больше она может принимать решений.

Как мы оцениваем ресерч?

В нашей команде мы поняли, что оценить ресерч нереально. Почему? Потому что неопределенность — его суть. Мы не знаем, что именно делать и как это делать, пока не погрузимся в задачу. Любая оценка — это гадание, ведь новые данные могут всплыть в любой момент и всё поменять. Вот почему мы не пытаемся предсказать итог, а просто выделяем фиксированное время и показываем либо результат, либо то, что накопали к этому сроку.

На практике это выглядит так:

Допустим, нам пришла задача — подключить антифрод-скрипт. Мы понимаем, что оценить задачу сложно из-за множества неизвестных: нужна документация, общение с подрядчиками, и интеграция может занять неопределенное время. Поэтому мы создаем отдельную задачу на ресерч, выделяем три дня на исследование и фиксируем это в комментариях. Разработчик за это время изучает документацию и готовит план по интеграции. Если за три дня не удается всё закрыть, он описывает к чему пришел и на чем остановился, что бы другой разработчик смог перехватить его ресерч в следующем спринте.

Ты скажешь: 'Ну а разве это не гадание, когда просто даешь три дня на ресерч?', и будешь прав. Гадание заключается в том, что мы не можем точно предсказать, сколько времени понадобится для устранения всех неизвестных. Мы выделяем фиксированные три дня на исследование, но не гарантируем, что за это время ресерч будет полностью завершен.

Разница в том, что эти три дня — это не обещание завершить ресерч, а просто выделение ресурсов. Бизнес соглашается, что готов потратить это время на то, чтобы уменьшить неопределенность. В конце итерации бизнес получает больше информации по задаче и может решить, что делать дальше: либо снова дать ресерч на доработку, чтобы получить больше ясности, либо отказаться от задачи вовсе. Таким образом, бизнес выигрывает: он получает больше данных, не теряя предсказуемости, и все остальные задачи в спринте не страдают.

Может показаться, что бизнес теряет кучу времени, ведь решение о том, что делать с ресерчем, можно принять только в начале следующей итерации. Но это неизбежная плата за итеративную разработку. Мы же все знаем, что менять скоуп спринта в процессе нельзя? Вот если начать выделять на ресерч больше времени это так же приведет к незакрытому спринту.

Хотите быстрее принимать решения? Добро пожаловать в канбан или какую нибудь другую методологию.

Почему часы а не сторипоинты?

Почему бы просто не закинуть сторипоинты в ресерч и не ломать голову над капасити на планировании, ведь команда всё равно считается в СП? Звучит как будто так будет проще - лиду не придется прикидывать потери команды в СП, при бронировании времени на ресерч. А так в планировании появляются две системы координат — часы и сторипоинты, и нужно как-то дружить это в голове.

Сторипоинты - это попытка оценить трудозатраты на выполнение задачи. Но как оценить трудозатраты на ресерч, если мы даже не знаем, что именно придется делать? Сложность задачи неизвестна, а значит, СП тут не подходят. Частенько лиды просто приравнивают СП к часам и выделяют те же три дня, только под видом сторипоинтов. Получается, что мы формально избавляемся от двух систем, превращая СП в нормочасы. Тогда зачем называть это сторипоинтами? Не проще просто перейти на оценку в часах? (Это вообще интересная тема, но не для этой статьи)

Если оценивать ресерч в СП, то появляется еще одна проблема:

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

Теперь вопрос: кто виноват? Разработчик ведь честно старался выполнить задачу, оцененную в 8 СП, и не его вина, что она оказалась сложнее, чем ожидалось. Нужно ли теперь снижать нагрузку на команду в следующем спринте, раз они не справились с предыдущим? В общем проблема неявного приведения СП к часам опять становится проблемой.

В итоге, проще сразу использовать таймбоксы для ресерчей, не пытаясь натянуть сторипоинты на задачи, где ничего не понятно. Конечно, лиду придется включать интуицию при определении капасити спринта, но он и так это делает, когда кто-то уходит в отпуск или заболевает, да? Так что переживет. Главное что у нас опять предсказуемая команда, которую можно планировать.