Привет, Хабр! Я Аня Анциферова, продакт «Цифрового вагона». Я уже рассказывала о том, зачем ПГК пошли в разработку и какие продукты мы делаем. Несмотря на то, что сейчас у ПГК существует «дочка» — ПГК Диджитал, и там трудится порядка 400 человек, мы — не ИТ-гигант. А это значит, что каждый проект, за который мы беремся, и даже каждую фичу, которую дорабатываем, мы должны оценить на предмет эффективности. И доказать, почему разработка оправдана и целесообразна. Сегодня расскажу о том, как такую базовую оценку может провести тимлид.

С чего все начинается

Когда мы говорим о разработке в ПГК Диджитал, обычно подразумеваем один из двух сценариев. Либо речь идет о доработке и расширении существующего проекта. Либо — о новом продукте. Например, над «Цифровым вагоном» мы работали несколько лет. Соответственно, мы проходили ежегодную «сверку»: показывали, какие цели перед нами ставились, чего мы достигли, куда идем дальше. Готовы ли какой-то модуль передавать в поддержку, нужно ли переходить к разработке нового модуля, что нам это даст. В общем, ежегодно защищали бюджет на разработку решения.

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

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

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

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

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

Что мы оцениваем

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

Как считать расходную часть, относительно понятно: это затраты на ФОТ, инфраструктуру, лицензии и т. д. Некоторые показатели мы рассчитываем, исходя из приближенных значений. Другие расходы оцениваем как долю от общих затрат (например, расходы на инфраструктуру). А какие-то из расходов можно вычислить с высокой точностью — это, в частности, ФОТ.

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

Автоматизированное решение vs ручное

Сначала мы сравниваем автоматизированное решение с ручным. Мы можем взять что-то, что делали вручную, автоматизировать (например, собрать прототип) и посмотреть, где мы начали лучше зарабатывать. В случае с сервисом «Цифровой вагон» сравнение выглядело так:

Мы используем нормативные документы владельца инфраструктуры и локальные документы ПГК. Опираясь на них, рассчитываем, когда ориентировочно тот или иной вагон должен выбыть в ремонт. Далее берем статистику предыдущих периодов и составляем прогноз: где будет находиться вагон, когда придет время отправлять его в депо. И на основании этого формируем план заадресации. [Кстати, о том, что такое матрица заадресации и как она выглядит, мы недавно рассказывали в нашей статье «Оптимизатор ремонтов грузовых вагонов, что за зверь?».]

Когда это происходило вручную, мы получали на выходе одну сумму затрат на ремонт в следующем месяце (план). После автоматизации расчетов мы получили другую сумму. Разница — результат, который мы засчитали как обоснование разработки. Подобная автоматизация может снизить затраты на 1–2% — на первый взгляд немного, но в денежном исчислении это ощутимая экономия.

Расчет базисного периода

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

Вагон уходит на ремонт в двух случаях: если возникла поломка, и ее нужно устранить прямо сейчас, либо если подошел срок планового обслуживания. В некоторых случаях эти два типа ремонта можно совместить так, чтобы не увозить вагон в депо два раза подряд. Наш «Цифровой вагон» позволяет оценить состояние вагона и, при необходимости, объединить текущий и плановый ремонт (вагон забраковали в текущий ремонт, а потом перебраковали в плановый).

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

Факторный анализ

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

Новый сервис позволил оперативно отслеживать длительно простаивающие вагоны. Через некоторое время мы увидели, что им активно пользуются, у сотрудников подразделения появилась возможность совершать меньше «ручных» операций. Одновременно мы стали отмечать, что и простой вагонов действительно начал снижаться (а чем быстрее вагон покидает депо после ремонта, тем больше он зарабатывает).

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

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

— Константин Сошнев, бизнес-аналитик команды разработки продуктов «Цифровой вагон» в ПГК

A/B-тест

«Цифровой вагон», помимо прочего, отслеживает состояние каждого вагона, чтобы предотвращать поломки и оптимизировать ремонты. В частности, у нас есть задача наиболее точно предсказывать, когда толщина гребня достигнет 25 мм. Это важный показатель технического состояния вагона (колесо должно плотно прижиматься к рельсу).

Если гребень тонкий, вагон могут отцепить. Но если вагон отцепляют по другой причине, а не из-за колеса, мы смотрим, в каком состоянии гребни и, при необходимости, сразу же обтачиваем колеса. Чтобы оценить результат нововведений такого плана (правильно ли мы поступаем, или все же стоило подождать), мы проводим A/B-тесты:

Группе А мы даем рекомендацию обтачивать колеса, группе B — не даем. И дальше отслеживаем, когда вагоны добегут до следующего планового ремонта. Смотрим коэффициент отцепки (это процентное соотношение количества отцепленных вагонов к общему парку вагонов в компании в определенном периоде). Если коэффициент снижается, то разница в снижении — наш эффект. Можно сказать, что «Цифровой вагон» позволил предотвратить N ремонтов (умножаем N на среднюю стоимость аналогичного ремонта, с учетом потерь на отвлечение вагона от эксплуатации, и получаем экономию за период в денежном выражении).

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