Как не давать пустых обещаний себе, команде и заказчику
Привет, Хабр!
14 лет я работал в международной компании Airbus — компании, занимающейся авиастроением. В IT же мой путь начался совсем недавно — всего лишь чуть больше года назад. Сейчас я — релиз менеджер в компании TAGES, и мы вместе с командами разрабатываем API-центричные микросервисы.
Чем отличается управление релизами программного обеспечения и управление проектированием конструкций гражданских самолетов? Мой опыт позволяет поставить знак равенства между этими двумя видами деятельности. По крайней мере, в контексте выстраивания долгосрочных отношений между заказчиком и исполнителем.
Главной задачей любого релиз-менеджера является управление релизами посредством планирования, оценки и контроля фактических результатов, достигнутых командой разработки.
В статье мы попробуем взглянуть на релиз-менеджмент как на управление в первую очередь ожиданиями заказчика.
Пристегните ремни, откройте шторки иллюминатора, сейчас будет немного потряхивать.
Если работу, выполняемую разработчиком, оценивают по качеству написанного кода, то работу релиз-менеджера — по выстроенным отношениям с заказчиком. Если он сумел выстроить доверительные отношения, то можно сказать, что это хороший релиз-менеджер.
Доверительные отношения выстраиваются тогда и только тогда, когда релиз-менеджер дает заказчику обещания, которые исполняются на систематическом уровне.
Мы можем это обозначить следующей условной формулой:
»Управление ожиданиями = построение доверительных отношений = обещания, которые исполняются».
Начнем с примера
Давайте обратимся к европейскому опыту и посмотрим, как наши коллеги справляются с похожими проблемами. В качестве примера возьмем кейс строительства аэропорта Берлин-Бранденбург.
Изначально предполагалось, что данную воздушную гавань удастся построить за 5 лет и 2 000 000 000 € . Не удалось. В итоге бюджет и сроки выросли в три раза — до 6 лет и 14 000 000 000 €. И это не говоря про дату открытия, которую успели перенести аж 5 раз!
Очевидно, что обещания не были исполнены, доверие было утрачено, а для заказчика и исполнителя это был последний совместный проект.
Европейский опыт
Пример из ИТ
Поскольку сегодня мы все же говорим о специфике работы релиз-менеджера в IT, то рассмотрим теперь пример из этой области. Кем больше будет доволен заказчик:
Релиз-менеджером, который дал обещание сделать 100 функциональностей за год, но сделал 50?
Релиз-менеджером, который обещал 50 и выполнил 48?
На длинной дистанции обратная связь демонстрирует, что релиз-менеджер, который выполняет больший процент обещанного, воспринимается более профессиональным, опытным и востребованным.
Здесь резонно могут возникнуть вопросы: как научиться давать такие обещания? Как определить точно, почему не 50 или, скажем, 70 функциональностей? Для решения этого вопроса рассмотрим три кейса.
Вопрос: кем заказчик будет доволен?
Кейс 1: Junior
Представим, что вы — Junior руководитель веб-приложения «Интернет-магазин». У вас есть команда разработки, вы давно работаете и прекрасно знаете каждого специалиста. В какой-то момент заказчик поручил новый эпик — «Данные о клиенте». Как посчитать объем работ в часах?
Декомпозиция
Когда заказчик говорит «Эпик «Данные о клиенте», возникает проблема. А именно — это очень абстрактная вещь, с ней довольно сложно работать. Поэтому мы декомпозируем эпик. В примере ниже была использована диаграмма прецедентов (use case diagram) в UML, которая позволила выяснить, что нам предстоит разработать 19 функциональностей. Это намного конкретнее и не так абстрактно.
Декопозиция функционала
Теперь мы с этим списком идем к профильным специалистам (системному аналитику, QA-инженеру и т.д.) и спрашиваем, сколько нужно времени для реализации каждой из функциональностей. По итогу, суммируем данные и получаем 778 часов. На всякий случай добавляем к ним 20% на непредвиденные ситуации (в зависимости от проекта это число может меняться).
Экспертная оценка задач
Далее этот объем работ и задач необходимо разложить во времени и на спринты, чтобы определить срок реализации эпика.
Релизный план
Команда
Для того, чтобы подготовить релизный план, необходимо внимательно рассмотреть нашу команду и ее загрузку.
Мы знаем, что наша backend-разработчик Мария через две недели уходит в отпуск на 14 дней.
Также нам известно, что в нашу команду через две недели придет новый системный аналитик Оксана. Она только окончила университет, так что это ее первая работа.
А тут еще к нам прибегает заказчик и говорит, что эпик очень важный, его нужно сделать как можно быстрее, в идеале — за три недели.
Ни в коем случае нельзя говорить: «Да, мы все сделаем». Возьмите паузу, скажите: «Можно мне время, чтобы все обдумать?». Если вы дадите обещание, а потом не выполните, то это плохо скажется на доверии.
Знакомимся с командой
Рабочая нагрузка
Ниже представлена таблица с рабочей загрузкой. По горизонтали это время (один столбец — 1 неделя), по вертикали — специалисты.
Мы будем исходить из гипотезы, что каждый специалист может эффективно работать не более 32 часов в неделю. Это говорит не о том, что остальное время он бездельничает, а о том, что он занят коммуникацией со своими коллегами, заказчиком и т.д.
Единичкой в таблице обозначим эти 32 часа.
Рабочая нагрузка
Мы помним, что Мария уходит в отпуск, поэтому на третьей и четвертой неделе ее загрузка равна нулю.
Также мы помним, что к нам приходит новый системный аналитик Оксана, и, так как у нее нет опыта, очевидно не стоит ожидать, что она тут же покажет высокую производительность. Поэтому предположим, что она сможет работать наравне с другими сотрудниками примерно через месяц. Соответственно, в таблице можно наблюдать, что в течение нескольких недель происходит рост с 0,5 до 1.
Помимо этого мы учитываем, что эффективное вливание новичков в рабочий процесс не происходит само по себе. Поэтому Азамат, наш системный аналитик, поначалу будет онбордить Оксану. В связи с этим мы отображаем, что он тоже будет часть времени тратить не на свои рабочие задачи, а на ее обучение.
Рабочая нагрузка с комментариями
Срок работ
На основе полученных данных мы можем определить срок работ. Для наглядности все отображено на графике ниже.
По горизонтали — время в неделях, по вертикали — трудоемкость задачи в часах.
Синяя кривая — трудоемкость всего проекта. Всплеск на первой неделе объясняется появлением новых задач, характерным для начала работ над любым эпиком. Как можно заметить по графику, нам необходимо выполнить задач примерно на 800 часов.
Красная кривая — накопительная кривая продуктивности всей команды во времени, на основе ранее представленной таблицы.
Срок работ находится на пересечении двух кривых. В нашем случае он составляет 7 недель. Как можно заметить, это существенно отличается от запрашиваемых заказчиком трех недель. Так что, если бы мы сгоряча ответили: «Да, мы все сделаем», то возникли бы проблемы. Поэтому в таких ситуациях всегда лучше просить время на анализ, а не давать ответ сразу.
График на основе таблице «Рабочей нагрузки» (кейс-1)
Идем дальше. Представим, что мы показали заказчику эти расчеты, он отнесся с пониманием, но попросил сделать хотя бы за пять недель, поскольку уже дал обещание своему руководству подготовить все к следующей конференции.
Здесь мы вновь вспоминаем опасность необдуманных обещаний, а потому говорим: «Мне нужно время, чтобы все обдумать». Сразу после этого отправляемся к своему руководителю за советом, и узнаем, что данный заказчик является стратегическим партнером, поэтому очень желательно что-то придумать. Руководитель сообщил нам, что готов для этого усилить команду, но ему нужно знать, сколько следует перевести сотрудников с другого проекта, чтобы реализовать эту задачу.
Эскалация проблемы
Для того, чтобы найти ответ на этот вопрос вернемся к таблице и графику.
Объем работ для этапов системного анализа, frontend и backend-разработки сопоставим (232, 206, 214 часов соответственно), тогда как для этапа тестирования и стабилизации необходимо 126 часов. Следовательно, нам понадобится усиление в разработчиках (системным анализом занимаются уже 2 аналитика). Также мы будем использовать допущение, что призванные на помощь разработчики смогут сразу работать продуктивно, поскольку обладают контекстом и достаточной компетентностью.
Добавив данные в таблицу загрузки специалистов, мы смотрим, где теперь проходит пересечение линий. Как и предполагалось, благодаря появлению двух разработчиков пересечение кривых сдвинулось к пятой неделе.
Соответственно, для реализации этого проекта за пять недель нам потребуются дополнительные разработчики на backend и frontend.
Кого еще зовем в команду?
Кейс 2: Middle
Перейдем к следующему кейсу. Вы уже более опытный руководитель, пришли на абсолютно новый проект, который существует некоторое время. Вы не знаете характер задач, не знаете про что этот проект, не знаете свою команду.
Заказчик говорит, что нужно сделать 5 эпиков для веб-приложения банка, причем они достались от предыдущего руководителя, который оставил только нарезанные в Jira задачи, без оценки времени, что еще сильнее усложняет задачу.
Возникает вопрос — как посчитать объем работ в часах?
На данный момент у нас есть информация, что для реализации этих эпиков нужно выполнить 10 задач по SA, 14 по backend и так далее. Это всё, что известно про проект.
Бэклог проекта
Статистический подход
Для решения ситуации воспользуемся статистическим подходом. Поскольку проект уже идет некоторое время, у него должна была накопиться статистика по прошлым задачам.
В качестве примера представим, что мы выгрузили из Jira 100 старых задач по frontend. Из полученного мы видим, что минимально на задачу было затрачено 2 часа, максимально — 76, среднеарифметическое у нас выходит 28 часов, а медианное — 16 часов.
Статистические данные
С этими цифрами мы производим трехточечную оценку и получаем результат, что выполнение одной задачи по фронтенду занимает 24 часа.
Трёх-точечная оценка
Далее мы повторяем расчет по всем остальным видам работ. Результат можно наблюдать в таблице ниже. Что важно заметить, разница между медианными и средневзвешенным показателями является довольно существенной. Это говорит о высокой неопределенности на проекте, а потому нам для расчетов лучше взять средневзвешенные показатели, а не медианные, поскольку в противном случае проект может занять в два раза больше времени, чем планируется.
Статистика по типам задач проекта
Теперь простая арифметика: берем количество задачек, которые нужно выполнить, и умножаем на средневзвешенную оценку по каждому типу задачи, получая суммарную трудоемкость.
Как можно заметить, суммарная трудоемкость нашего проекта составляет 1204 часа.
Итоговый объем работ проекта (оценка)
Продуктивность команды
Как уже было сказано, мы не знаем нашу команду. Единственное, что известно, это то, что у нас есть один Senior, три Middle и два Junior. Нам неизвестно как они работают — быстро, хорошо и так далее.
Как можно работать с этой неопределенностью?
Команда проекта
В уже знакомой таблице применим немного другой подход. Будем использовать гипотезу, что Junior работает на 30% менее продуктивно, чем Middle, в то время как Senior, наоборот, на 30% более продуктивно. Соответственно, в таблице обозначим это как 0,7 (Junior), 1 (Middle) и 1,3 (Senior).
Рабочая нагрузка
Воспользовавшись полученными данными, мы можем рассчитать время реализации проекта.
Из графика ниже видно, что на реализацию нам потребуется 8,5 недель. Полученные сроки мы обсудили с заказчиком, ему они понравились, и началась работа.
График на основе таблице «Рабочей нагрузки» (кейс-2)
При этом стоит отметить, что в процессе работы может возникнуть ситуация, когда заказчик придет с дополнительными задачами (см. увеличение скоупа работ на седьмой неделе). В таких ситуациях важно помнить и проговаривать с заказчиком, что это ведет к общему повышению трудоемкости и, тем самым, сдвигает срок выполнения работ.
График на основе таблице «Рабочей нагрузки» (кейс-2), уточненный
Кейс-3: Senior
Представим, что вы уже руководитель уровня Senior. У вас в подчинении 3 команды разработки — А, Б и В. В какой-то момент приходит заказчик и спрашивает: «Дедлайн 1 октября, успеваем?». Просит дать ответ через час-два.
Работа с диаграммой работ
Мы открываем накопительную диаграмму работ в Jira и смотрим области выполненных задач, оцененных (т.е. которые нужно сделать для реализации этого проекта) и задач, которые находятся в бэклоге.
Здесь мы будем использовать гипотезу, что нынешняя продуктивность команды будет сохраняться и в будущем, а в список оцененных задач и бэклог больше ничего добавляться не будет.
Как можно заметить по диаграмме команды А, даже с имеющимися допущениями мы не успеваем в дедлайн. Для оцененных задач нам нужно еще две дополнительные недели, а если учесть бэклог, то гораздо больше.
Накопительная диаграмма работ (Команда А)
Следом смотрим вторую команду. Как можно заметить, поначалу она пробуксовывала, но затем произошел хороший рост. И здесь то же самое — мы видим, что мы не успеваем в дедлайн по оцененным задачам. А по бэклогу все и вовсе уходит на конец года.
Накопительная диаграмма работ (Команда Б)
Хуже всего ситуация у третьей команды. Как можно заметить, они либо плохо оценили задачи на старте проекта, либо что-то очень сильно изменилось, ведь их площадь оцененных задач и бэклог постоянно увеличиваются.
Как можно заметить, оцененные задачи будут сделаны только во второй половине ноября, а по бэклогу и вовсе после Нового года.
Накопительная диаграмма работ (Команда В)
Что (не) делать?
Здесь возникает вопрос — что делать? Порезать бэклог? Сдвинуть сроки? Устроить разнос командам? Приложить максимум и сделать все?
Устроить разнос командам — это аморально, потому что тогда это будет перекладыванием своей ответственности на команду.
Дать обещание приложить максимум усилий — не самый лучший вариант. Еще в начале материала мы видели, чем такое может закончиться.
Остаются два пути:
Значительно уменьшить объем работ, отобрав наиболее приоритетные задачи:
Составить список незавершенных работ;
Оценить список незавершенных работ;
Сравнить с реально доступным временем;
Приоритизировать задачи (MoSCoW или RICE);
Реализовать основные сценарии, отложить реализацию краевых сценариев.
Согласовать новые сроки и новый релизный план
Можно выбрать как один из описанных, так и их комбинацию — чуть-чуть сдвинуть сроки и что-то уменьшить из бэклога.
Если же не решать проблему, то это приведет к негативным эффектам. Таким как:
Накопление задач. Самое очевидное — откладывание решения приводит лишь к накоплению проблем, а не избавлению от них.
Снижение продуктивности. Сотрудники будут считать, что вне зависимости от вложенных усилий, все равно ничего не получится, а потому к дедлайнам они будут относится спустя рукава, ведь: «Ну, дедлайн уже пять раз переносили. Не буду укладываться и ладно, обычное дело».
Подрыв доверия к релиз-менеджеру и компании. В свою очередь, это влечет потерю доверия, а значит — контрактов, денег и перспектив.
Вывод
Подводя итог, мы можем выделить три правила:
Важно не лгать себе, команде и заказчику.
Прежде чем давать заказчику ответ, следует оценивать задачи с помощью простых математических инструментов.
Важно получать удовольствие от жизни и работы, а не выгорание, негатив и стресс.
Жизнь на реальном проекте сложнее приведенных здесь кейсов. Использование этих подходов — это не серебряная пуля, которая наверняка вас убережет от возможного провала. Однако давать обещания, не опираясь хотя бы на такие арифметические расчеты, еще опаснее.
___________________________________
Со всеми представленными в материале расчетами можно ознакомиться здесь.
Еще раз отмечу, что представленные статистические данные там выдуманные. Не стоит на них ориентироваться и говорить: «А я в статье прочел, что frontend все делает за 24 часа!»
Главная задача данного материала — показать, как можно работать с ожиданиями заказчика и реалистично оценивать возможности своей команды.
