Привет! Меня зовут Дмитрий Крупенин, я руковожу продуктовой разработкой в Первой грузовой компании (ПГК). Создаю интересные внутренние продукты по оптимизации управления вагонами, которых у нас достаточно много – 113 тысяч. У меня более 5 лет опыта работы в промышленных и логистических компаниях, где я разрабатывал продукты «про железную дорогу и вагоны». Сегодня хочу рассказать о том, чем отличаются внутренние продукты и работа над ними.
Что такое внутренний продукт
Когда мы говорим про цифровые продукты, обычно вспоминаются какие-то стартапы либо сервисы и приложения больших компаний, направленные на рынок b2с, массовых пользователей. Внутренний продукт – это продукт для пользователей, работающих внутри компании, то есть для внутреннего клиента.
Чаще всего цель создания таких продуктов – снижение затрат или рисков. Например, мы хотим более эффективно управлять нашими вагонами, снижая затраты на содержание парка (как пример - оптимизация ремонтов, маршрутов и проч.), или снизить риск, что клиент не примет вагон из-за его непригодности (тут можем применить, например, предиктивные модели работы с коммерческой пригодностью вагона или посоветовать провести предиктивный ремонт). Внутренним продуктом часто пользуется небольшое число экспертов, но его вклад в коммерческий успех компании может быть очень высоким.
Из чего состоят внутренние продукты
Внутренние цифровые продукты имеют довольно большой арсенал различных современных технологий, которые ничуть не хуже, чем у известных технологических компаний или стартапов. Мы говорим и про Data Science, и про прогнозные модели, оптимизационные алгоритмы, работу с большими данными и бесчисленное поле возможностей для применения автоматизации (от вездесущих excel-файлов с макросами до бесчисленных интеграций с внешними системами).
У нас в команде, как и в большинстве продуктов, есть бэкэнд- и фронтэнд-разработчики, которые программируют интерфейсы. Есть продуктовые дизайнеры, задача которых состоит в том, чтобы сложные продукты имели адекватные интерфейсы, удобные пользователю и способные решить его задачу. Да, во внутренних продуктах есть определенная специфика хотя бы потому, что их интерфейсы часто содержат большой объем информации, на основе которой будут принимать решения эксперты. Тогда на помощь часто приходит инфографика или нестандартные решения, чтобы не переложить очередную табличку из файла в веб-интерфейс, заставляя пользователя работать на трех мониторах.
Симбиоз цифрового советчика и человека
В моей практике внутренние продукты – это цифровые советчики. Они по тому или иному каналу доносят до лиц, принимающих решения (в ПГК это диспетчера, планировщики, движенцы), советы, как оптимально решать ежедневные рабочие задачи. Фактически, такие советчики дают эффект только тогда, когда их советы реализованы, воплощены в жизнь специалистами.
Да, есть цифровые советчики, которые делают все автоматически, но по большей части продукты промышленных компаний вряд ли будут стопроцентно автоматизированы. Просто потому, что невозможно запрограммировать все потенциальные ситуации, никогда нельзя точно предсказать, какой вагон внезапно окажется непригоден под погрузку или какой кусок железнодорожных путей может оказаться перекрыт.
Другими словами, есть много внешних факторов для модели, и есть человек, который контролирует ситуацию с учетом советов цифровой модели. В критические моменты человек может принять решение, отличное от того, что рекомендует ему модель, так как цифровая модель не всегда учитывает внезапно произошедший инцидент.
Самое важное в создании внутреннего продукта (советчика, цифровой модели) – его полезность и приживаемость. То есть на выходе он должен быть таким, чтобы эксперты им действительно пользовались, прислушивались к советам, которые он производит. Только тогда можно говорить о крутости продукта и его экономической эффективности.
Экономический эффект
На разных курсах для владельцев продукта мы изучаем, как можно измерить результаты с помощью метрик типа MAU, LTV, NPS и прочих. Продуктовые решения принимаются на основе данных: сколько пользователей заходит в сервис, сколько совершают покупку или делают заказ и т.д.
Однако наши внутренние продукты оперируют совершенно другими метриками и показателями. Например, когда речь идет о числе пользователей – внутри компании обычно может быть всего несколько десятков человек, которые пользуются этой разработкой. Не сотни тысяч или миллионы пользователей, как в b2с продуктах. Эта небольшая группа экспертов с помощью нашего продукта приносит компании значительный экономический эффект.
В моей практике интересные внутренние продукты – это обычно десятки миллионов рублей затрат на команду и инфраструктуру и сопоставимый экономический эффект в первый же год. Отличные проекты приносят в десятки и сотни раз превышающий свою стоимость экономический эффект. Это сопоставимо с цифровыми продуктами и сервисами, направленными на b2с.
Мы уже говорили, что внутренние цифровые продукты большой компании фактически нацелены на решение двух задач. Это либо снижение рисков, либо снижение затрат компании. В нашем случае мы, к примеру, снижаем риски получения нерелевантного парка или риски возникновения критического дефицита вагонов в том или ином регионе и, конечно же, снижаем затраты на управление парком вагонов.
Если говорить о каких-либо внутренних продуктах ПГК или других операторов железнодорожного транспорта, то одна из важнейших целей – повышение качества вагонов. Речь о контроле за коммерческой пригодностью вагонов в формате цифровых советчиков, созданных в помощь экспертам. Или, к примеру, снижение затрат на ремонты вагонов и дополнительные расходы.
Главная задача продакта при защите экономических эффектов – доказать, что именно цифровой советчик позволил добиться таких экономических показателей, а человек без подсказчика так бы не сделал. Поэтому часто приходится досконально разбираться в бизнес-процессах, просчитывая влияние других инициатив, мероприятий менеджмента и действий сотрудников. Тут на помощь приходят различные методы оценки изменений (гэпа) показателей относительно прошлых периодов, рынка, базовой линии и прочее. Обычно формулы расчета эффекта от цифрового продукта довольно сложные. Но пока ты пройдешь все стадии согласования, погружение в бизнес-процессы получается очень глубоким. Ты действительно начинаешь понимать, как работает то или иное направление бизнеса компании.
Типовые проблемы
Первая проблема – приживаемость. Если мы говорим про Facebook или Instagram, где пользователь не пользуется какой-то фичей, то мы берем и что-то меняем. Когда мы делаем какой-либо производственный советчик, призванный помогать выполнять ту или иную деятельность, то может оказаться так, что модель сделана так хорошо, что она выявляет человеческие недостатки и недоработки. И для того, чтобы скрыть их, эксперты могут начать продукт бойкотировать.
В этом случае внедрять продукт нужно обязательно с заказчиком. Это прописная истина – поддержка руководства нужна обязательно, потому что часть пользователей точно будет сопротивляться внедрению цифрового советчика. Им может показаться, что человек будет не нужен – машина будет решать все за него.
Важно выстроить хорошие отношения с конечными пользователями, рассказывая им о том, что нет, цифровой советчик не сможет заменить их. Никого не уволят, наоборот, с сотрудников снимаются рутинные операции, которые заменяет машинный расчет. Так, специалист из линейного работника, который руками выполняет расчеты, становится экспертом, который работает с инцидентами, отклонениями математической модели. Он подключается, когда нужно реально разруливать проблему и решает неординарные задачи. Например, идет ремонт на конкретном участке железной дороги, и нужно ехать в обход, но компьютер про это не знает, потому что невозможно запрограммировать все подобные случаи. Только люди могут решить такие задачи.
Вторая типовая проблема заключается в том, что большая часть заказчиков, если мы говорим про какие-то промышленные компании, еще не привыкли к agile. Для нас подход к гибкой разработке – это что-то понятное и привычное, поэтому надо не забывать обновлять знания, что MVP не равняется «промышленный продукт».
Когда мы превращаем идею в цифровой продукт, на начальном этапе проверяем гипотезы: можем ли мы сделать так или не можем; достаточно ли в компании накоплено исходных данных, на основе которых модель будет выдавать решения; какого качества эти данные. Поэтому на старте речь не идет о создании промышленного продукта: это долго, дорого и результат неизвестен. Сначала делаем минимально жизнеспособный продукт.
На защите бюджета на создание МVP ваш заказчик может подумать, что это конечная цифра расходов для получения промышленного продукта. Мы же на этом этапе говорим только об МVP и проверке гипотез. Так как это минимально жизнеспособный продукт, в нем могут быть ограничения. Где-то мы не делаем интеграцию со сложными системами или сложными модулями SAP, делаем загрузку из Excel. Не настраиваем все возможные логи, не создаем целевую инфраструктуру и т.п.
Конечно же, после того, как мы закончим проект и захотим все это передать на поддержку, его надо будет доделывать. То есть преобразовать модель, созданную для проверки гипотез, в полноценный продукт, который будет максимально стабильно работать. У него будет целевое быстродействие и его можно будет эксплуатировать так, что служба поддержки сможет разруливать проблемы с этим цифровым продуктом с минимальным вовлечением команды.
Требования к команде
Отдельно стоит отметить степень погружения в предметную область. В моей практике, если речь идет о разработке каких-либо продуктов b2c, которыми мы привыкли пользоваться, каждый разработчик, как правило, с этим сталкивался и понимает, что и зачем он делает. А когда ты набираешь команду в логистический продукт для того, чтобы управлять вагонами, задачу понимает далеко не каждый разработчик. Даже продакты и бизнес-аналитики не всегда знают, как маршрутизируют вагоны, что такое конвенции на железной дороге, как вагоны ремонтируются и т.д.…
Приходится очень глубоко погружаться в предметную область, потому что нужно понимать, что вы делаете и какие данные есть в цифровом продукте. И почему они должны быть именно в таком виде.
Один из краеугольных камней решения проблемы – наличие бизнес-заказчика и бизнес-транслятора внутри компании. Если в команде разработчиков для индустриальной компании нет людей, которые имеют большой опыт работы, к примеру, на железной дороге, в нефтехимии или металлургии, результата не достичь. Ровно потому, что без такого человека в команде любой цифровой советчик будет попросту похоронен после релиза, так как не будет учитывать те искомые «пятьдесят два параметра».
И конечно, важно иметь ввиду, если кто-то покидает команду, и приходится набирать новых людей, то потребуется значительно больше времени на их погружение в предметную область, то есть до того момента, когда начнут появляться первые результаты для компании. Невозможно просто вот так прийти, набрать за месяц команду, чтобы она через два месяца выдала какие-то результаты. Это очень сложно. И скорее всего месяц, а то и больше, команда будет погружаться в профессиональную сферу, чтобы выявить технологии производства, управления вагонным парком или особенности получения данных от железной дороги – то есть научится разговаривать с заказчиком на одном языке.
Приживаемость продуктовой разработки
Еще один важный фактор – в промышленности цифровизация только начинается. Поэтому здесь важны фреймворки продуктовых команд.
Не все заказчики, бизнес-трансляторы и эксперты понимают, что такое user-story, Customer Journey Map и другие модные словечки. Им понятно, что такое «написать ТЗ» и совершенно непонятно, что такое «проверить гипотезу».
Часто представители бизнеса думают, что они ТЗ написали – значит, так и будет, не понимая, что это может не сработать, не прижиться и не взлететь. Поэтому важно донесение правил: как мы работаем, как работает IT-команда, как формируется бэклог, и в каком формате мы собираем данные. Почему у нас agile, а не fools ТЗ, какие результаты мы даем каждый спринт и почему делаем работу именно в таком порядке.
Все это нужно постоянно рассказывать заказчикам, особенно тем, кто никогда не работал с IT-продуктами. Правила работы, особенности сбора бизнес-требований, формат взаимодействия – все это привычно для цифровизаторов, но может быть абсолютно непонятно железнодорожникам, нефтяникам или металлургам.
Суперважно фреймворки не только разрабатывать, но и постоянно о них напоминать, возвращаться к ним в течение всего проекта. Жестко отслеживать эти правила, чтобы цифровой продукт в конце концов получился четким и работоспособным с точки зрения IT-моделей, удобным для заказчика и конечных пользователей. Потому что цель каждого IT-разработчика, чтобы его продукт, в который вложено столько сил и труда, прижился и качественно работал. Ведь не секрет, что это не только польза для конкретной компании, но качественный вклад в ваше личное портфолио.
