Руководители команд часто оценивают проекты, и не все делают это хорошо.
Здесь многое зависит от личности самого руководителя команды, а также от его понимания команды.
Существует множество методик оценки проектов от метода «по аналогии» до PERT. Но сегодня я собираюсь поговорить о том, как я использую покер планирования и другие методы для более точной и прибыльной оценки.
Прежде чем говорить о конкретных подходах, стоит остановиться на основных трудностях процесса.
В оценке всегда есть две стороны: команда и клиент. Находясь между ними, руководитель команды или менеджер вынужден искать баланс противоположных интересов.
Завысить цену невозможно, так как клиент откажется платить больше.
Это тоже не стоит недооценивать.
В этом случае вам придется нарушить темп работы команды, рискуя излишней усталостью, выгоранием и тем, что код отправится в производство непроверенным.
Глубина проработки задания на оценивание – вопрос философский.
Задачи можно долго обсуждать, тогда оценка всего спринта затянется.
Но если не вникать в суть, можно упустить что-то важное, что влияет на сроки выполнения.
Слабый и сильный разработчик действуют по-разному.
Если задачу оценивает сильный разработчик, слабый не уложится в сроки.
И наоборот, сильный выполнит задачу гораздо быстрее, чем предполагал слабый.
Учитывая разницу в скорости работы, при оценке возможны различные «социальные» ошибки, когда, например, слабый разработчик «подсмотрит», во сколько сильный оценивает задачу, и поставит одинаковые сроки, чтобы не чтобы объяснить, почему его «оценка» выше: «Он сказал неделю, я не могу сказать, что понадобится триЭ» Я скажу минимум полтора.
» Обойти эту проблему помогает так называемый покер планирования, когда в оценке участвует вся команда, не зная, кому достанется задание, и оценивают вслепую.
не видя, что предлагают коллеги.
Автор: Хкниберг из английской Википедии — перенесено из en.wikipedia в Wikimedia Commons, Public Domain
Каждый прокручивает задачу в своей голове.
Если сроки, заявленные членами команды, сильно различаются, начинается обсуждение.
В эти моменты обычно оказывается, что команда не заметила какой-то особенности, которую обязательно придется реализовать в рамках задачи.
После этого все проголосуют еще раз.
И тогда не было претензий, что кто-то что-то ошибся – участвовали все.
Даже если произошла ошибка, никто не будет тратить время на поиск виноватых; будет более конструктивный разговор о том, какие новые факторы появились и изменили ситуацию (и как их можно учесть в будущем - работа над ошибками, Я об этом писал в предыдущей статье в пункте 5 ).
Дополнительные вопросы клиенту помогают точнее оценить проект. Но здесь легко можно переборщить.
К некоторым застройщикам не обращаются за сметой именно потому, что они забрасывают клиента огромным количеством писем с разъяснениями.
С точки зрения взаимоотношений с клиентом количество дополнительных вопросов лучше свести к минимуму, а это увеличивает неопределенность задачи.
Несколько советов, как не совершать ошибок
Чтобы свести к минимуму ошибочные суждения, я следую нескольким простым правилам.Прежде чем прочитать техническое задание, я инициирую ознакомительный звонок с клиентом.
В этом звонке я прошу рассказать о задаче с высоты птичьего полета: кто будет конечным пользователем, как он будет использовать результат, какие устройства будут использоваться (с такими-то разрешениями), как выглядит бэкенд типа если оно уже есть и т.д. После этого можно приступать к чтению ТЗ.
Читая техническое задание, я составляю список вопросов клиенту.
Изучая задачу, следует попытаться «закодировать» в голове весь проект — представить, как он будет выглядеть.
Список вопросов должен быть таким, чтобы после ответа на него можно было сформировать надежную оценку.
Основная идея здесь в том, что вопросы следует задавать не постепенно, а единовременно.
И часто лучше звонить по готовому списку вопросов, чтобы не затягивать переписку.
Однако текст несет гораздо меньше информации.
Во время звонка тоже можно пошарить по экрану, если это как-то прояснит ситуацию.
Если звонок по каким-то причинам невозможен, я открываю «Google Документ», куда добавляю эти вопросы, и клиент отвечает на них по мере наличия времени.
Это более эффективный способ общения по задаче, чем личный чат или электронная почта.
Этот документ позже можно будет отправить разработчикам, которые будут участвовать в проекте — им больше не придется задавать одни и те же вопросы.
Кстати, желательно, чтобы на вопросы клиента отвечал ответственный за проект человек, а не бывшая секретарша режиссера, которая просто играет роль сломанного телефона.
Это снизит риск изменения параметров проекта в ходе работы.
Если есть возможность, я вывожу разработчиков «в поле».
Понимание того, как продукт будет использоваться в реальности, помогает расставить все точки над «i» и улучшить оценку.
Например, разрабатывается программное обеспечение для кассовых аппаратов.
А ваши разработчики сидели за компьютером 15 лет и никогда не видели кассового аппарата.
Вы доносите их до конечных пользователей, просите их совершить покупку не где-нибудь, а конкретно в этом магазине.
И видят, что там сидит тетя Маша, нажимает пальцами две кнопки одновременно и в очках не может разобрать буквы на мониторе.
В результате многие вопросы по проекту отпадают сами собой — шрифт становится крупнее, добавляется подтверждение операций.
Трудно представить себе такие вещи в своей голове.
А ощущение реальности, полученное от личного визита, подпитает застройщика еще на год. К сожалению, такое погружение возможно не во всех проектах.
Я не оцениваю задачу, если в условии есть «и»/«или».
Например, если вас попросят «сделать авторизацию и регистрацию».
Нет никакой проблемы разбить этот пункт на две задачи и оценить каждую из них отдельно.
Такая оценка будет более точной, поскольку вы не будете смешивать похожие, но все же разные сущности.
Чем лучше разложение, тем точнее результат. «Или» еще хуже, оно всегда идентично расплывчатому техническому заданию, на основании которого невозможно сделать точные оценки.
Стоит или не стоит авторизоваться через социальные сети? Что, если для бэкэнда существует какой-то конкретный API? Если вы не знаете специфики, вы просто не сможете дать точную оценку.
Изображение: Михаил Дубаков @ Medium Не может быть оценки в 40 часов на одну задачу.
Это еще одна вариация предыдущего правила.
В Agile рекомендуется декомпозировать проект на задачи продолжительностью не более 20 часов.
Неделимых задач на неделю работы быть не должно.
Небольшие порции делают оценку гораздо точнее.
При декомпозиции задачи я стараюсь ее зафиксировать.
Это полезно с двух сторон одновременно.
Во-первых, это упрощает процесс.
Как только вы начинаете записывать мысли на заданную тему, ваш мозг с удовольствием их развивает. Кстати, именно поэтому я не рекомендую смешивать декомпозицию с оценкой, т.е.
выбирать по одной задаче и сразу оценивать каждую из них.
Лучше разбить весь проект на составляющие, зафиксировать это, а потом оценивать их все сразу, чтобы не заставлять голову работать в двух режимах сразу.
Во-вторых, «логарифм» декомпозиции помогает объяснить возможное несоответствие оценки и реальности в будущем.
По сути, вы формируете полное описание задачи — какие параметры вы учли.
Например, вы учли авторизацию по логину и паролю с помощью токена, продление токена и т. д., но заказчик, оказывается, тоже хотел авторизацию через соцсети, он просто об этом не написал.
Ваш журнал декомпозиции поможет защитить команду от претензий о том, что вы что-то оценили, но не уложились в срок.
Я учу команду не хвататься за сопутствующие задачи до их завершения.
Разработчики тратят много времени на дополнительные функции.
Делают авторизацию, попутно видят, что где-то надо что-то подправить, и глубже вникают в этот побочный процесс.
Пытаюсь выработать рефлекс: если вижу связанную задачу, создаю отдельный билет. Вам даже не нужно передавать задачу тимлиду или менеджеру.
Когда тимлид просматривает задачи, он сам их увидит и при необходимости отправит на дальнейшую работу.
Таким образом, вам не придется никого отвлекать от работы (вы создали задачу и забыли о ней), а точность оценки сохранится.
Я выделяю время для тестирования.
При проведении оценок многие забывают о тестировщиках.
Но на самом деле любая задача, особенно сложная, должна тестироваться реальными людьми — они должны думать над ней, искать ошибки.
Если что-то найдут, то ошибки отправят разработчикам, которые уже перешли на другой контекст. Им придется снова погрузиться в тему.
И этот цикл может повторяться не один раз.
Необходимо запланировать время на тестирование.
Как правило, эта оценка дается отдельно от заявленной застройщиком.
Учитываю время на парное программирование и другие особенности работы.
Парное программирование помогает обмениваться опытом и мотивировать разработчиков.
Они сидят вместе или просматривают экран, обсуждают задачу и используемые инструменты и по очереди вносят некоторые изменения.
Такой подход окупается для команды, но с точки зрения заказчика задача не движется в два раза быстрее.
На проектах, где я работал, мы не постоянно практиковали парное программирование, но некоторые задачи было удобно решать именно так.
И мы это учли на этапе оценки.
Аналогично нужно выделить время на демонстрации клиенту, звонки, переписку и т.д. И вообще, чтобы уложиться в смету, разработчик должен работать качественно, а для этого ему нужно высыпаться, как следует отдыхать( а не дежурить всей командой по выходным на производстве) и не торопить работу все быстрее и быстрее.
Поэтому оценка всегда должна основываться на реальной практике работы, а не на оптимистическом прогнозе, что сейчас мы все сядем и «сделаем пятилетку за три года».
Я выделяю время, чтобы выложить проект. Стенды представлены четырьмя типами – разработка, тестирование, подготовка производства и производство.
Лучше развернуть эти стенды на старте проекта и сразу выделить для этого время.
Если этого не сделать, синхронизация разработки, тестирования и развертывания будет нарушена, что может превратиться в настоящее узкое место.
Я не делаю оценок сверху и снизу – я называю конкретный срок.
По правилам маркетинга, когда разработчик говорит «от 4 до 12 часов», он имеет в виду «сделать менее чем за 12 часов».
Клиент слышит «4 часа».
Если задача будет выполнена за 11, разработчик посчитает, что все в порядке, а клиент останется недовольным.
Бывает, что клиент недоволен, даже если задача выполнена за 4 часа 15 минут. Поэтому, даже если внутри коллектива (компании) составляется таблица с минимальными и максимальными сроками, а затем вычисляется среднее значение (такой подход имеет определенный смысл), заказчику показывается только конечный результат. Сроки даю только в часах, а не в днях или месяцах.
Многие думают, что если проект рассчитан на 96 часов, то он будет выполнен за 12 дней по 8 часов при условии, что над ним будет работать один человек.
Ситуацию можно легко экстраполировать на двух застройщиков, что дает оценку в 6 дней.
Но это не правда.
Есть много задач, которые зависят друг от друга.
Во-первых, застройщики не могут приступить к работе, пока не будет создан шаблон проекта со всеми системами сборки и стендами (а создание занимает 2-3 дня с учетом пожеланий клиента).
Во-вторых, все останавливается, когда происходят звонки по планированию.
В-третьих, есть блокирующие баги, которые мешают двигаться вперед. Другими словами, 96 часов пребывания на рабочем месте не означают, что 100% времени (8 часов в день) будут посвящены именно этим задачам.
Если прикинуть в днях, то можно предположить, что у разработчика в день не 8, а, скажем, 6 рабочих часов (точная цифра должна быть определена из практики).
Я всегда спрашиваю у разработчиков, сколько часов займет выполнение задачи на компьютере (а не «сколько времени потребуется, чтобы она была готова»).
Это следствие предыдущего пункта.
При взаимодействии с командой в рамках оценки важно правильно сформулировать вопрос.
Учитываю «командный коэффициент».
Обычно лидерами команды становятся вчерашние старшеклассники.
Они оценивают задачи исходя из своего опыта, даже если в их команде есть посредники.
Возможно Senior работает не сильно быстрее, но после него багов почти не остаётся.
Середины не имеют такого же качества.
Поэтому в Agile существует так называемый «коэффициент команды», который показывает разницу между оптимизмом оценщика и реальной жизнью конкретной команды.
Рассчитывается только практически: теоретическая оценка сравнивается с реальной для последних спринтов.
Чем лучше тимлид знает свою команду (и чем лучше он умеет оценивать), тем ближе этот коэффициент к 1. Помимо прочего, «командный коэффициент» учитывает и так называемый «оптимизм разработчиков» при проведении оценки.
Задания всегда оцениваются по отсутствию ошибок, сытости и хорошему настроению исполнителей, отсутствию проблем в окружении.
Но реальность изобилует чрезвычайными ситуациями и защититься от этого невозможно.
«Командный коэффициент», рассчитанный за разумный период времени, позволяет это учесть.
Пытаясь установить влияние команды, иногда во внутренней оценке отходят от часов к сторипойнтам.
Зная, что на выполнение задания потребуется 8 сторипойнтов, они вспоминают, что на прошлой неделе 1 сторипойнт стоил 8 часов.
Исходя из этого, прогнозируются затраты на рабочую силу.
Но мне проще думать о часах.
Не ввожу лишних коэффициентов, чтобы не путать других участников процесса.
Я часто вижу, как люди проводят оценку на уровне команды и уделяют этой оценке время переговорам.
Но подразделение, проводящее оценку, не должно включать этот резерв или учитывать другие посторонние вещи.
И получается, что разработчик оценил задачу в 8 часов, но для верности умножил ее на 2. Тимлид снова удвоил свою оценку, подстраиваясь под команду.
И менеджер сделал для клиента 40 часов из 32 (для ровного счёта или просто с целью поторговаться на 30 часов позже).
Это больше похоже на чтение на кофейной гуще.
И клиент, увидев оценку в 40 часов на 8-часовую задачу, решит, что команда ничего не может сделать.
Как я отметил выше, на уровне команды необходимо учитывать только характеристики самой команды, договариваясь о том, кто включает в оценку форс-мажорные обстоятельства (а это там должно быть учтено, так как мы всегда оцениваем задачи, предполагая что редактор кода не просит лицензию, разработчики не сбегают на больничный и т. д.).
Я твердо отстаиваю свою оценку.
Следствием предыдущего пункта является то, что я всегда твердо стою в своей оценке.
Если я знаю, что проект займет 6 месяцев, а от меня ждут, что я его оценю за 3 месяца, я никогда не скажу 4 месяца, чтобы «порадовать» заказчика или менеджера.
Следует учитывать, что иногда имеет место внутренний торг.
Когда ты знаешь, что к Новому году проект должен быть готов, ты по незнанию начинаешь подтасовывать результаты сметы, чтобы уложиться в оставшееся время.
Мозг отлично справляется с такими задачами.
Даже если у вас есть список из 200 подзадач, они потом соберутся так, чтобы успеть выполнить до Нового года.
Несмотря на все это, я готов к тому, что оценка изменится.
Это нормально — проекты живут и развиваются.
Формируя любую оценку, я понимаю, что это особенность проекта в данный конкретный момент. И последний совет: не заставляйте разработчиков, не соблюдающих сроки, писать менеджерам длинные письма на эту тему.
Во-первых, они, скорее всего, будут смущены.
Во-вторых, вероятно, менеджер снова вас о чем-то спросит и лишний раз отвлечет. В-третьих, его объяснительная просто затеряется в переписке.
Обычно я прошу комментарий по проблеме в Jira. Без участия живого человека (менеджера) это обычно проще и быстрее.
И во время разбора полетов его будет легко найти.
И плюс для тимлида — все задачи, выходящие за рамки, будут прокомментированы.
Опять же, поработайте над ошибками, чтобы улучшить качество оценивания в будущем.
Автор статьи: Евгений Ветцель ( @imater ) P.S. Мы публикуем наши статьи на нескольких сайтах Рунета.
Подпишитесь на наши страницы по адресу ВК , ФБ , Инстаграм или Telegram-канал чтобы узнать обо всех наших публикациях и других новостях Maxilect. Теги: #Управление разработкой #Управление проектами #agile #оценка задач #оценка проекта #планирование покера
-
Обнаружен Первый Вирус Ipod
19 Oct, 24 -
Несколько Фактов О «Теореме Cap»
19 Oct, 24
