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

До этого я десять лет работала в финтехе. Разрабатывала банковские приложения, карточные продукты, транзакционные сервисы. Привыкла к метрикам типа конверсии и среднего чека. А потом попала на производство.

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

Я тогда поняла — здесь все по-другому.

Раньше считала открытия приложения, теперь — простои оборудования

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

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

Поэтому здесь надо по-другому тестировать гипотезы. В финтехе запустил A/B-тест — одним показываешь форму заявки на карту из трех шагов, другим — всё на одном экране. Через неделю смотришь: пошаговая форма дает 23% завершенных заявок, одностраничная — 14%. Откатываешь неудачный вариант за пять минут.

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

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

Метрики тоже изменились. Раньше я считала, сколько людей открыли приложение.  Теперь отслеживаю долю брака на производстве и загрузку мощностей.

Это меняет всю логику работы. В финтехе неудачная фича — это потерянная конверсия. Здесь неудачная фича — это остановленное производство, испорченная продукция, потери в миллионах. Я не могу позволить себе подход "запустим минимальную рабочую версию и посмотрим на реакцию". Мне нужно сразу понимать последствия.

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

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

Здесь нельзя исправить ошибку за пять минут

В финтехе можно запустить обновление в любой момент. Если что-то сломалось — откатываем за пять минут.

На производстве нельзя.

Нельзя запустить новую функцию, если на складе стоит большое количество фур. Сломаешь логистический процесс — встанет все.

Нельзя зарелизиться, если главный специалист ушел в отпуск или персонал не обучен.

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

Планирование релизов — запусков новых версий системы — теперь завязано не на спринты команды, а на производственный календарь. Смотрю, когда нет пиковых нагрузок, когда ключевые люди не в отпуске, когда есть окно для обучения персонала. 

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

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

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

Каждый считает свою задачу самой срочной — как навести порядок

Я открыла бэклог — список всех задач на разработку. Там было 300 доработок. У каждой стоял либо нулевой, либо первый приоритет. У каждой были желаемые даты, которые уже вписали в KPI заказчиков — показатели эффективности, по которым их оценивают. Разработчиков никто не спросил.

Я спрашивала у команды: как вы понимаете, за что хвататься? Для каждого заказчика его задача самая важная, самая нужная, самая срочная.

Менеджер по логистике говорит: «Уберите эти поля, на них уходит куча времени».

Менеджер по производству отвечает: «Нет, эти поля нужны для отслеживания брака».

Менеджер по продажам добавляет: «А мне вообще нужны другие поля».

Из‑за этого реальные сроки ничего общего не имели с ожидаемыми. Я тратила половину времени на объяснения, почему что‑то нельзя было сделать за два месяца.

Однажды мы сделали доработку для ценообразования. Все проверили, выкатили. Через час звонок из Турции.

«У нас сделки не проходят! Что вы наделали? Срочно исправьте!»

Мы сделали все, как просили продажи. Но продажи просили для России. Ценообразование в Шанхае должно учитывать НДС, ценообразование в Турции не должно. 

Команда откатилась. Потом полгода делала заново с учетом всех регионов.

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

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

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

Еще заказчики с большим количеством запросов стали использовать эту методику, чтобы самим понимать, какая доработка приоритетнее.

Мы создали карту стейкхолдеров. 

Начали говорить со всеми заранее. Чем раньше привлекаем коллег, тем меньше проблем на выходе.

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

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

Я научилась договариваться и помогать находить компромисс даже там, где интересы кардинально расходятся. Это навык, который работает везде — в любой индустрии, в любой роли. Умение услышать всех, найти баланс интересов, объяснить решение так, чтобы все остались довольны.

Горизонт планирования измеряется годами

На производстве проект может идти несколько лет.  Когда он стартует — все горят, готовы действовать. Через полтора года энергия снижается. Люди устают от длинного марафона. Начинают сомневаться, а нужно ли это вообще. Теряют фокус.

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

В ходе проекта возникают нюансы. Они всегда не вовремя.

Мы провели исследование рынка, что вообще есть для наших задач. Написали техническое задание. Провели тендер. Выбрали подрядчика. Подрядчик уже получил доступ.

И тут выясняется: у него нет лицензии на сервис для IT-безопасности.

Что это значит? Обычно, это был бы откат на полтора года назад. Пришлось бы доработать техническое задание, провести тендер заново. 

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

Теперь работаем по простым правилам.

• Делим проект на вехи с промежуточными результатами.

• Вовлекаем всех на начальном этапе. Здесь помогает карта стейкхолдеров.

• Вкладываемся в проработку рисков и возможных сценариев. Отражаем их на дорожной карте.

• Используем шаблоны и чек-листы. Шаблон технического задания помогает не пропустить важное. 

• Даем только диапазоны дат. От самого позитивного срока до самого негативного. 

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

• Регулярно встречаемся с заказчиками, проводим статусы. В начале проекта все заряженные, все готовы действовать. Через полтора года энергия снижается. Ее важно удерживать и увлекать заказчиков.

• Регулярные статусы и пересмотры дорожных карт помогают знать, кто что сделал, кто что делает сейчас, кто что будет делать.

Большую часть задач мы выполняем в срок. Все понимают актуальный статус и конкретных ответственных. Когда проект, над которым работал два года, выходит в продакшн — становится рабочей системой, которой пользуются люди — и начинает приносить результат, это другой уровень удовлетворения. Ты видишь реальное влияние. Ты знаешь каждую деталь этого проекта, помнишь все препятствия, которые преодолели.

Страх перед обновлениями исчез, когда начали объяснять и слушать

У нас 1200 пользователей CRM-системы.

Раньше каждые две недели они открывали систему и видели что-то страшное, новое, неизвестное. Новые поля, новые кнопки. Боялись этим пользоваться.

• Мы начали с простого. Рассылаем релизноуты — письма с описанием изменений — каждый месяц. На всех сотрудников

• Делаем регулярные демо — встречи, где показываем новые функции в действии. Рассказываем про цели доработки, нюансы. Показываем вживую как это работает

• Актуализируем инструкции. Сразу после релиза у всех есть актуальная инструкция. Можно зайти и посмотреть, что изменилось.

Но мы решили пойти дальше. Не останавливаться на формальной коммуникации.

На демо начали объяснять простым языком IT-термины. Что такое релиз? Что такое продуктивная среда? Что такое тестовая среда? Как работает архитектура системы?

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

Они перестали нас бояться. Перестали бояться задавать вопросы. Это дало большой эффект к удовлетворенности пользователей.

Да, все проблемы мы не решили. Негатив остался. Но теперь заказчики и команда понимают, что они делают, зачем делают, в каком приоритете и почему.

Команда перестала постоянно переделывать функционал. Делаем сразу целевое решение или хотя бы MVP целевого решения.

IT перестали быть теми странными людьми, которые что-то там делают непонятное. Мы стали партнерами. Нам доверяют. С нами советуются на ранних этапах, а не приходят с готовыми требованиями.

Что я поняла за это время

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

На производстве практически каждый процесс уникальный. Все знакомые инструменты приходится переосмысливать и адаптировать

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

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

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

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

Да, здесь сложнее, чем в приложениях. Нужно понимать не только IT, но и производство, химию, логистику, безопасность.

Да, здесь больше ответственности. Ошибка стоит дороже.

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