Чем отличаются внутренние IT-продукты от внешних?

Начинающие IT-специалисты при выборе карьеры часто ориентируются на известный им розничный сектор и выбирают сферу создания цифровых продуктов для массовых клиентов. Но есть и другой путь для качественного профессионального роста. Руководитель продуктовой разработкой в Первой грузовой компании (ПГК) Дмитрий Крупенин рассказывает, чем отличаются внутренние продукты для крупных компаний и работа над ними.

— Больше 5 лет я работаю в промышленных и логистических компаниях, где создаю продукты «про железную дорогу и вагоны». Сейчас делаю интересные внутренние продукты по оптимизации управления вагонами ПГК, которых у компании достаточно много – 113 тысяч.

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

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

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

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

Самое важное в создании внутреннего продукта – его полезность и приживаемость. То есть на выходе он должен быть таким, чтобы эксперты им действительно пользовались, прислушивались к советам, которые он производит. Только тогда можно уверенно говорить о крутости сервиса и его экономической эффективности.

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

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

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

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

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

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

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

Поэтому так важно донесение правил: как как работает IT-команда, как формируется бэклог, и в каком формате идет сбор данных. Почему у нас agile, а не fools ТЗ, какие результаты мы даем каждый спринт и почему делаем работу именно в таком порядке. Все это нужно постоянно рассказывать заказчикам, особенно тем, кто никогда не работал с IT-продуктами.

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

Хотите узнать больше? Более полный материал по этой теме читайте здесь.