"Разбазарить ресурс на ремонт багов": как оценить эффективность ИТ-команды

Представьте, что разработчики постоянно срывают сроки выполнения задач. Первая мысль – разогнать всех и набрать новую команду. Но это вряд ли исправит ситуация, потому что причина обычно кроется совсем в другом: неправильное планирование. Как определять настоящие источники трудностей при разработке ИТ-продуктов и оценивать эффективность ИТ-команды, рассказывает Ярослав Карасев, директор по продукту GeekBrains.

Что такое ИТ-команда

ИТ-команда – это группа людей с разными ролями и разной функциональностью, которая работает вместе над общим проектом. Руководителем проекта становится product- или project-менеджер. В проектной команде, работающей по методологии Scrum, назначается Scrum-мастер. Он следит за выполнением методологии Scrum в командной работе. Административных ролей в команде больше нет, все остальные – более функциональные.

Product-менеджер отвечает за решения по продукту, не всегда он самостоятельно пишет техническое задание для коллег. Далее всё передается дизайнеру. В команде есть frontend и backend-разработчик, один или несколько. Frontend верстает, а backend создаёт функциональность "под капотом".

Также есть вспомогательные функции. Допустим, существует такая роль, как ответственный за упаковку. Отдельный сотрудник в проекте не только ведёт конкретную разработку, но и проверяет все тексты. Он отвечает за передачу смыслов ИТ-проекта при помощи текста и визуала: это одновременно и редактор, и копирайтер, и сх-исследователь. Но это необязательная роль, её необходимость зависит от проекта. Есть проекты, где даже frontend-разработчик не обязателен, если всю функциональность может сделать backend.

В качестве команды нередко предполагается обособленная группа людей, которая увеличивает какую-то метрику. В такой команде могут быть роли, отвечающие именно за неё. Например, если это маркетинговый проект в ИТ, то в команде будет маркетолог. Его задача – например, настройка SEO и создание семантического ядра.

Как измерять результаты команды

Критерии оценки зависят от размеров компании, команды, проектов. Чаще всего эффективность ИТ-команд оценивают тремя способами.

Оценка продуктовой эффективности по метрикам. Вся команда работает на какую-то метрику, измеряет и проверяет ее: выросла или упала, в каком направлении она движется. Основной подход в продуктовой оценке следует из юнит-экономики. У каждого бизнес-юнита есть свои показатели рентабельности, выручки, затрат, прибыльности. Это основные метрики. А дальше – целый хвост метрик, которые косвенно влияют на основные. Например, от конверсии опосредованно зависит количество привлеченных клиентов, выручка от них и стоимость их привлечения.

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

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

Одна из основных "косвенных" метрик – конверсия. Её можно разделить на два вида. Первая конверсия – сколько людей, поступивших в "воронку продаж", оставило заявку. Вторая конверсия – сколько из оставивших заявку купило продукт. Иногда в небольших проектах две эти конверсии не разделяют, а просто измеряют конверсию из уникальных пришедших пользователей в новых покупателей.

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

Проектный подход неприменим в случаях, где сложно выбрать какую-то конкретную исчисляемую метрику. Возьмём, к примеру, разработку LMS (система управления обучением). Когда внедряешь там какую-то новую функциональность, сложно сказать, что она каким-то образом повлияет на продуктовую метрику. Некоторые метрики не всегда можно адекватно посчитать. Например, показатели, связанные с удовлетворённостью пользователей: NPS, CSAT , CSI и прочие.

Финансовый подход. Некоторые вещи с точки зрения эффективности ИТ-команды измеряются вкладом в капитализацию. Такой подход работает в компаниях, которые вышли на IPO, либо стремятся к этому, либо отчитываются по стандартной финансовой отчетности. Например, мы оцениваем вклад команды за месяц в капитализацию платформы. Если команда за месяц усилила её функциональность и капитализацию – она работала эффективно. А если она разбазарила весь ресурс на ремонт багов или на исследования, которые не влияют на прирост стоимости, то финансовый результат будет отрицательным. Компания вложила ресурсы и не получила роста капитализации.

"Оценка оценки". Это не совсем "классический" метод, но в нём тоже есть свой смысл. Команды разработки тоже занимаются планированием. Они определяют, сколько времени уйдёт на ту или иную задачу. И мы оцениваем, насколько команда попала в свои оценки. Например, было заявлено сделать фичу за неделю, а по факту делали 2 месяца – это неэффективная работа команды. А если планировали сделать за 5 дней и выполнили за 5 дней в должном качестве, команда сработала эффективно.

Причины неэффективности ИТ-команд

Конфликт интересов. Это основная причина, в которую упираются многие ИТ-проекты. Когда product или project-менеджер планирует проект, он хочет закончить его как можно быстрее. Это часто приводит к плачевным последствиям. Если на выполнение задач ставится неадекватный дедлайн, без учёта привычного для людей рабочего ритма, никто не будет выкладываться на 300%, чтобы уложиться в эти сроки.

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

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

Нарушение работы по процессам или отсутствие процессов. Это настоящий бич современного бизнеса: люди не привыкли дисциплинированно работать. Соблюдение процессов и в целом операционный менеджмент очень часто недооценивают. А это сильно влияет на результат.

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

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

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

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

Пути решения основных проблем

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

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

Определение проблемы – половина ее решения. Чтобы выявить проблему, нужен человек, который будет этим заниматься. Обычно это обязанность операционного менеджера, либо менеджера проекта, либо менеджера команды. В Scrum для этих целей есть Scrum-мастер.

Выявлять проблемы можно подсчётом метрик. Если мы считаем метрики и после выполнения задач продолжаем следить за тем, сколько принесла конкретно эта задача, то команда будет быстро находить причины неэффективности.

Если команда постоянно срывает сроки – как правило, проблема в планировании. Project или product-менеджеру надо уделять больше внимания при планировании тех или иных вещей. Если разработчики постоянно ошибаются в оценке сроков работ – больше не давать им планировать и составлять планы за них. К сроку, который озвучивает разработчик, многие прибавляют 30% времени на форс-мажоры. И тогда ожидания у всех уже более реалистичные. Если что-то происходит, то проект не вылетает из графика.

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

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