Тимлиды часто оценивают проекты, и не все делают это хорошо. Тут многое зависит от личности самого тимлида, а также от его понимания команды. Есть много техник оценки проектов от метода “по аналогии” до PERT. Но сегодня я расскажу о том, как я применяю planning poker и другие приемы, чтобы оценивать точнее и с большей пользой.
Прежде чем говорить о конкретных подходах, стоит остановиться на основных сложностях процесса.
В оценке всегда есть две стороны: команда и клиент. Находясь между ними, тимлид или менеджер вынуждены искать баланс противоположных интересов. Завысить оценку нельзя, поскольку клиент откажется больше платить. Занижать также не стоит. В этом случае придется нарушать темп работы команды, рискуя чрезмерной усталостью, выгоранием и тем, что код отправится в продакшен недопроверенным.
Глубина проработки задачи для оценки — вопрос философский. Задачи можно обсуждать долго, тогда оценка всего спринта затянется. Но если не вникать в суть, можно упустить что-то важное, что влияет на срок исполнения.
Слабый и сильный разработчик действуют по-разному. Если задачу оценил сильный разработчик, слабый не уложится в его сроки. И наоборот, сильный сделает задачу намного быстрее, чем оценил слабый. Учитывая разницу в скорости работы, в оценке возможны разные “социальные” ошибки, когда, например, слабый разработчик будет “подглядывать”, во сколько оценивает задачу сильный, и ставить те же сроки, чтобы не объяснять, почему его “estimate” больше: “Он назвал неделю, не могу же я сказать, что это займет три? Скажу хотя бы полторы…”.
Обойти эту проблему помогает так называемый planning poker, когда в оценке участвует вся команда, не зная, кому попадется задача, причем оценивают вслепую, не видя, что предлагают коллеги.
Задачу в голове прокручивает каждый. Если заявленные членами команды сроки сильно отличаются, начинается обсуждение. В эти моменты обычно выясняется, что команда не заметила какую-нибудь фичу, которую обязательно придется реализовать в рамках задачи. После этого все переголосуют. И потом никаких претензий о том, что кто-то что-то неправильно оценил — участвовали все. Даже если ошибка будет, на поиск виноватых время уже никто не станет тратить, будет более конструктивный разговор о том, какие новые факторы появились и изменили расклад (и как можно в будущем их учесть — работа над ошибками, о ней я писал в прошлой статье в п. 5).
Точнее оценить проект помогают дополнительные вопросы клиенту. Но здесь легко можно перегнуть палку. К некоторым разработчикам не обращаются за оценкой именно потому, что они бомбардируют клиента огромным количеством писем с уточнениями. С точки зрения взаимоотношений с клиентом количество дополнительных вопросов лучше минимизировать, а это увеличивает неопределенность задачи.
Несколько советов о том, как не ошибиться
Чтобы минимизировать ошибку в оценке я придерживаюсь нескольких простых правил.
Инициирую вводный созвон с клиентом перед чтением ТЗ. На этом созвоне прошу рассказать о задаче с высоты птичьего полета: кто будет конечным пользователем, как они будут применять результат, какие будут задействованы устройства (с такими-то разрешениями), как выглядит бэкенд, если он уже существует, и т.п. После этого можно приступать к чтению ТЗ.
Читая ТЗ, я составляю список вопросов для клиента. Изучая задание, в голове надо попытаться “закодить” весь проект — представить, как он будет выглядеть. Список вопросов должен быть таким, чтобы, получив ответы, можно было сформировать достоверную оценку.
Основная идея здесь в том, что вопросы надо задавать не постепенно, а за один раз. И зачастую лучше созвониться по готовому списку вопросов, чтобы не растягивать переписку. Все-таки текст передает гораздо меньше информации. На созвоне можно и экран пошарить, если это как-то прояснит ситуацию.
Если созвон по каким-то причинам невозможен, я завожу “Google Документ”, куда дописываю эти вопросы, а заказчик по мере появления времени на них отвечает. Это более эффективный способ коммуникации по задаче, нежели персональный чат или почта. Этот документ впоследствии можно отправить разработчикам, которые будут участвовать в проекте — им не придется задавать те же вопросы еще раз.
Кстати, желательно, чтобы со стороны клиента на вопросы отвечал человек, ответственный за проект, а не бывшая секретарша директора, которая просто играет роль испорченного телефона. Так снизится риск того, что параметры проекта изменятся прямо во время работы.
Если это возможно, вывожу разработчиков “в поле”. Понимание, как продукт будет использоваться в реальности, помогает расставить некоторые точки над “и” и улучшить оценку. К примеру, разрабатывается софт для касс. А ваши разработчики 15 лет просидели за компьютером и кассу в глаза не видели. Вы их приводите к конечным пользователям, просите оформить покупку не где-нибудь, а конкретно в этом магазине. И они видят, что там сидит тетя Маша, которая пальцами одновременно две кнопки нажимает и в очках буквы на мониторе разобрать не может. В результате многие вопросы о проекте отпадают сами собой — шрифт становится больше, добавляется подтверждение операций. В голове такие вещи представить сложно. А ощущение реальности, полученное от личного визита, будет подпитывать разработчика еще год.
К сожалению, такое погружение возможно не во всех проектах.
Не оцениваю задачу, если в условии есть “и” / “или”. Например, если предлагается “сделать авторизацию и регистрацию”. Нет никаких проблем в том, чтобы разбить этот пункт на две задачи и оценить каждый из них по отдельности. Такая оценка будет точнее, потому что ты не будешь смешивать схожие, но все же отличающиеся сущности. Чем качественнее декомпозиция, тем точнее результат.
“Или” — еще хуже, оно всегда тождественно размытому ТЗ, по которому нельзя строить точные оценки. Надо или не надо делать авторизацию через социальные сети? А вдруг есть какой-то специфический API у бэкенда? Если не знаешь конкретики, ты просто не можешь дать точную оценку.
Картинка: Michael Dubakov @ Medium
Оценки в 40 часов на задачу быть не может. Это другая вариация предыдущего правила. В Agile рекомендуется декомпозировать проект на задачи не более 20 часов. Не должно быть неделимых задач на неделю работы. Мелкими порциями оценка получается гораздо точнее.
Проводя декомпозицию задачи, стараюсь ее протоколировать. Это полезно одновременно с двух ракурсов.
Во-первых, это упрощает процесс. Как только начинаешь записывать мысли на заданную тему, с удовольствием их развивает. Кстати, именно поэтому я не рекомендую декомпозицию смешивать с оценкой, т.е. выделять по одной задаче и каждую из них сразу оценивать. Лучше весь проект разбить на составляющие, зафиксировать это, а потом разом их оценить, чтобы не заставлять голову работать сразу в двух режимах.
Во-вторых, “лог” декомпозиции помогает объяснить возможное расхождение оценки с реальностью в будущем. Фактически у тебя формируется полное описание задачи — какие опции ты учитывал. К примеру, ты учел авторизацию по логину и паролю с токеном, продление токена и т.п., а заказчик оказывается хотел еще авторизацию через социальные сети, просто не написал об этом. Твой “лог” декомпозиции поможет защитить команду от претензий о том, что вы что-то оценили, но в сроки не уложились.
Приучаю команду не хвататься за сопутствующие задачи до их оформления. У разработчиков много времени тратится на дополнительные фичи. Они делают авторизацию, попутно видят, что нужно где-то что-то поправить, и углубляются в этот побочный процесс. Я же стараюсь воспитать рефлекс: увидел сопутствующую задачу — сформируй отдельный тикет. Не надо даже прогонять задачу через тимлида или менеджера. Когда тимлид будет разбирать задачи, он сам увидит ее и отправит на проработку, если это нужно. Так и отрывать от работы никого не придется (создал задачу и забыл про нее), и точность оценки сохранится.
Закладываю время на тестирование. Проводя оценку, многие забывают про тестировщиков. А на самом деле любая задача, особенно сложная, должна пройти через тестирование живыми людьми — они должны вдуматься в нее, поискать баги. Если они что-то найдут, баги отправятся к разработчикам, которые уже успели переключиться на другой контекст. Им придется снова погружаться в тему. И этот цикл может повторяться не один раз.
Время на тестирование закладывать необходимо. Как правило, эту оценку дают отдельно от того, что заявил разработчик.
Учитываю время на парное программирование и прочие особенности работы. Парное программирование помогает обмениваться опытом и мотивировать разработчиков. Они садятся вместе или шарят экран, обсуждают задачу и используемые инструменты, поочередно вносят какие-то изменения. Такой подход окупается для команды, но с точки зрения заказчика задача не двигается в два раза быстрее. На проектах, где я работал, мы не практиковали парное программирование постоянно, но некоторые задачи было удобно делать именно так. И это мы учитывали на этапе оценки.
Аналогично надо закладывать время на демонстрацию клиенту, созвоны, переписку и т.п. И вообще, чтобы укладываться в оценку, разработчик должен работать эффективно, а для этого ему надо высыпаться, нормально отдыхать (а не дежурить всей командой в выходные на продакшене) и не гнать работу быстрее-быстрее. Поэтому оценка всегда должна отталкиваться от реальной практики работы, а не оптимистичного прогноза о том, что сейчас все сядем и “сделаем пятилетку за три года”.
Закладываю время на выкладку проекта. Есть четыре вида стендов — разработка, тестирование, препродакшн и продакшн. Лучше разворачивать эти стенды на старте проекта и сразу заложить на это время. Если этого не сделать, нарушится синхронизация разработки, тестирования и деплоя, что может превратиться в настоящий затык.
Не делаю оценки сверху и снизу — называю конкретный срок. По правилам маркетинга, когда разработчик говорит “от 4 до 12 часов”, он имеет в виду “сделать быстрее, чем за 12 часов”. Клиент при этом слышит “4 часа”. Если задача выполнена за 11, разработчик будет считать, что все хорошо, а клиент останется недоволен. Бывает, что клиент недоволен, даже если задача выполнена за 4 часа и 15 минут. Поэтому даже если внутри команды (компании) составляется табличка с минимальным и максимальным сроком, а потом высчитывается среднее (в таком подходе есть определенный смысл), заказчику демонстрируется только конечный результат.
Называю сроки только в часах — не в днях или месяцах. Многие думают, что если проект оценен в 96 часов, то он будет выполнен за 12 дней по 8 часов, при условии, что над ним работает один человек. Ситуацию легко экстраполируют на двух разработчиков, называя оценку в 6 дней. Но это неверно. Есть много задач, которые друг от друга зависят. Во-первых, разработчики не могут начать работать, пока не создан шаблон проекта со всеми системами сборки и стендами (а он создается 2-3 дня с учетом пожеланий клиента). Во-вторых, все останавливается, когда проходят созвоны для планирования. В-третьих, встречаются блокирующие баги, которые не дают двигаться дальше. Иными словами, 96 часов нахождения у рабочего места вовсе не означают, что 100% времени (8 часов в сутки) будет посвящено конкретно этим задачам. Для оценки в днях можно считать, что у разработчика не 8, а допустим 6 рабочих часов в сутки (точную цифру надо определить из практики).
Всегда спрашиваю у разработчиков, сколько часов у компьютера займет задача (а не “через сколько она будет готова”). Это следствие предыдущего пункта. Взаимодействуя с командой в рамках оценки, важно правильно формулировать вопрос.
Учитываю “коэффициент команды”. Обычно в тимлиды выходят вчерашние сениоры. Они оценивают задачи, исходя из своего опыта, даже если в их команде мидлы. Возможно, сениор работает не намного быстрее, но после него почти не остается багов. У мидлов не такое качество. Поэтому в Agile есть так называемый “коэффициент команды”, который показывает разницу между оптимизмом оценивающего и реальной жизнью конкретной команды. Он высчитывается только практически: сравнивается теоретическая оценка с реальной за последние спринты. Чем тимлид лучше знает свою команду (и чем лучше он набил руку на оценке), тем ближе этот коэффициент к 1.
Среди прочего “коэффициент команды” учитывает и так называемый “оптимизм разработчиков” при выполнении оценки. Задачи всегда оцениваются, исходя из отсутствия ошибок, сытости и хорошего настроения исполнителей, отсутствия проблем в окружении. Но реальность изобилует нештатными ситуациями и от этого никак не защититься. “Коэффициент команды”, рассчитанный на разумном промежутке времени, позволяет это учесть.
Пытаясь заложить влияние команды, иногда во внутренней оценке уходят от часов к сторипоинтам. Зная, что задача займет 8 сторипоинтов, вспоминают, что на прошлой неделе 1 сторипоинт обошелся в 8 часов. Из этого прогнозируют трудозатраты. Но мне проще мыслить в часах.
Не ввожу лишних коэффициентов, чтобы не путать других участников процесса. Я часто вижу, как люди, проводя оценку на уровне команды, закладывают в нее время на торг. Но звено, проводящее оценку, не должно закладывать этот запас или учитывать другие посторонние вещи. А то получается, что разработчик оценил задачу в 8 часов, но для верности умножил на 2. Его оценку тимлид снова удвоил, подстраиваясь под команду. А менеджер из 32 часов сделал для клиента 40 (для ровного счета или как раз с целью сторговаться потом на 30 часов). Это больше похоже на гадание на кофейной гуще. Да и клиент, увидев оценку в 40 часов для 8-часовой задачи, решит, что команда ничего не умеет.
Как я отметил выше, на уровне команды надо учитывать только особенности самой команды, договорившись о том, кто закладывает в оценку форс-мажор (а он должен быть там учтен, поскольку задачи мы всегда оцениваем, предполагая, что редактор, кода не просит лицензию, разработчики не разбегуться на больничный и т.п.).
Твердо стою на своем при защите оценки. Следствие предыдущего пункта — я всегда твердо стою на своей оценке. Если я знаю, что проект будет выполняться 6 месяцев, а от меня ждут оценки в 3, я никогда не назову 4 месяца, чтобы “порадовать” заказчика или менеджера.
Надо учесть, что иногда существует и внутренний торг. Когда ты знаешь, что проект должен быть готов к Новому году, ты неосознанно начинаешь подтасовывать результаты оценки так, чтобы уложиться в оставшееся время. отлично проворачивает такие штуки. Даже если у тебя там список из 200 подзадач, они потом сойдутся так, чтобы уложиться до Нового года.
Несмотря на все это, я готов к тому, что оценка меняется. Это нормально — проекты живут, развиваются. Формируя любую оценку, я понимаю, что это характеристика проекта в данное конкретное время.
И финишное напутствие: не заставляйте разработчиков, которые не укладываются в сроки, писать длинные письма менеджерам на эту тему. Во-первых, они скорее всего постесняются. Во-вторых, менеджер наверняка будет что-то переспрашивать и лишний раз отвлекать. В-третьих, его письмо с разъяснениями просто потеряется в переписке. Я обычно прошу написать комментарий к задаче в Jira. Без участия живого человека (менеджера) это обычно проще и быстрее. А во время разбора полетов его будет легко найти. И тимлиду плюс — все задачи, которые выбились из оценки, будут прокомментированы. Опять же, работа над ошибками для повышения качества оценки в будущем.
Автор статьи: Евгений Вецель (@imater)
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.
Автор: Maxilect
