Учимся оценивать задачи всей командой

Привет тимлид!

Наверняка тебе знакома ситуация, когда на созвоне по оценке задач лиду приходится читать требования от бизнеса вслух, чтобы команда могла прикинуть хуй к носу и оценить задачу чисто по ощущениям. А потом окажется, что оценка никак не соответствует реальности. Я такое наблюдал почти везде, где работал. Люди еще гордо называют это скрамом, хотя, как по мне, это просто лень.

У нас в команде все планирования проводились точно так же. Мы собирали созвон, я шарил команде экран, на котором открывал каждую задачу и читал требования. Затем пытался вытянуть из команды оценку. Чаще всего мне становилось скучно, и я говорил как бы я оценил эту задачу, чтобы команда могла облегченно покивать и согласиться с моей оценкой. Потом мы въёбывали спринт и на ретро обсуждали, как много "нюансов" всплыло во время разработки.

Устав оправдываться на ретро, я стал читать требования каждой задачи, чтобы заранее увидеть "нюансы" и устранить их до старта разработки. Это помогло, но со временем я понял, что перерабатываю. Мне приходится включать голову за всех разработчиков, а зарплату мне платят только за себя. В итоге друг мне посоветовал ввести спорную (но, как оказалось, работающую) практику с написанием "домашки".

Домашка?

Домашка.

Ответы на 3 вопроса по каждой планируемой задаче. Ответы разработчик присылает в личку лиду до начала созвона с оценкой.

Вопросы звучат так:

• Что хотят?
• Как это сделать?
• Сколько будет стоить?

Ответы выглядят примерно так:

Задача FRONT-228.

Что хотят?

Разметить кнопку заказа аналитикой, чтобы понять сколько пользователей начали заказ, но не завершили.

Как это сделать?

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

Сколько будет стоить?

3SP

Задача FRONT-1337

...

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

Если совсем упрощать, то алгоритм оценки задачи выглядит так:

"Совсем заигрался в начальника со своими домашками!", - сказали бы вы, но у меня закрыты комментарии. Да и не делился бы я своей шизой, если бы у нее не было результатов.

К тому же, команда растет и каждый раз объяснять новым людям, зачем у нас такие правила, становится все скучнее. Поэтому я решил, как и с дейликами, написать заметку, чтобы не повторяться.

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

Потому что это базовые вопросы, без которых невозможно понять объем задачи. Не хочешь на них отвечать? А как ты собрался оценивать объем работы, не зная его?

Что хотят?

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

Как это сделать?

Если браться за задачу без подготовки, то можно сильно удивиться неожиданным проблемам в процессе выполнения. Вот наглядная иллюстрация мэмом:

Вот бы мы могли заранее предугадать хотя бы часть проблем... Стойте! Так можем же! Если откроем код и прикинем, как будем делать эту задачу, то заметим, какие блокеры могут возникнуть по ходу выполнения. А если еще и инфру вокруг кода пощупаем, так вообще сведем шансы роста сложности задачи к минимуму.

Сколько стоит?

В SP, в часах, в рублях, да хоть в DOGE - не важно, в чем вы оцениваете задачи. Главное - записать свою оценку, чтобы потом не тупить на покер-планировании, вспоминая сколько ты хотел запросить за эту задачу

Зачем письменно?

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

Представь тот же процесс, но на созвоне. Как быстро тебе надоест бубнеж коллег, пока ты пытаешься вчитаться в требования к задаче, разобраться в коде и понять, как работает какой-нибудь server side events по спеке? Вот и я думаю, что лучше спокойно заварить чайку в удобное тебе время и погрузиться в изучение.

Почему бы не шарить эту домашку сразу всей команде? Зачем в личку?

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

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

К тому же, если постоянно шарить домашки всех членов команды, то канал с ними превратится в спам. Люди просто перестанут вчитываться, так же, как перестают хорошо ревьювить объемные MR-ы в больших количествах.

А как же обсуждение в команде?

Если ты хочешь подсветить что-то, то не стесняйся создавать тред и тегать команду. Треды позволяют вовлечь в обсуждение не только твою команду, но и техписов/стейкхолдеров/любого, кто может тебе помочь ответом.

Когда вы соберетесь на оценку, большинство вопросов уже будет разрешено. Останется только поиграть в покер-планирование и обсудить детали.

Такой подробный анализ займет кучу времени, где его взять?

У нас с бизнесом есть договоренность: в каждый второй понедельник спринта мы устраиваем "день тишины". Это когда разработчиков не отвлекают от анализа задач вопросами, созвонами или написанием кода. Если кто-то закончил с анализом до конца рабочего дня, то пусть лучше почитает книжку или прогуляется. Это все еще полезнее, чем пытаться одновременно погружаться в задачу и отвечать на вопросы других команд.

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

В итоге это win-win ситуация для бизнеса и разработки.

Результаты у такой практики есть?

Да. Честно говоря, я удивлен насколько хорошо это работает.

После введения домашки вопросов к требованиям стало в несколько раз больше - видно, что люди стали вчитываться в задачи. Многие моменты уточняются и правятся в макетах еще до старта разработки. Все это экономит кучу времени на переделках.

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

При найме новых программистов это тоже помогло. Лиду стало проще понять уровень новичка по тому, как он подходит к изучению задачи. Я бы вообще давал тестовое в виде такой домашки, но никто не любит тестовые...

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

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

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

А минусы?

Внедрить домашку было тяжело. Старожилы видели в этом нарушение их свободы. Хех. Ирония в том, что именно из-за них появился этот процесс. В любом случае, я понимал какую цель преследую, поэтому не стеснялся продавливать свое решение. Лучше быть мудаком в глазах команды, чем продолжать за них работать.

Даже сейчас время от времени кто-то из команды филонит и присылает откровенные отписки. Когда таких отписок становится слишком много, я иду в личку и стараюсь вернуть человека в русло процессов. Но таков путь - никто никогда не будет следовать правилам на 100%, даже я. Тут только смириться и учиться убеждать людей.

Это же временная практика?

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

Домашка - это инструкция (фреймворк, епта) для анализа задачи. Она помогает начать погружаться в оценку задачи, а не играть в казино из стори поинтов на планировании.

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

Рекомендуешь внедрять во все команды?

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

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

Если же с оценкой нет проблем, а команда не факапит спринты, то не устраивай лишнюю бюрократию. Ты уже работаешь в хороших условиях.