PM в электротехнике: почему здесь не работает Agile
Производитель оборудования АСУ ТП берёт продуктового менеджера из IT. Через полгода картина одна: человек умный, инструменты знает, но продукт не движется. Ретроспективы есть. Дорожная карта есть. Результата нет. Дело не в квалификации. Дело в том, что промышленный продукт — это другая физика.
Почему IT-PM не работает в промышленной автоматике В IT: собрал обратную связь, добавил фичу, выкатил, измерил. Цикл — 2–4 недели. Продукт — это код, который обновляется ночью без остановки производства. Контроллер ПЛК или модуль ввода-вывода — другая история. Аппаратный ревизионный цикл: полгода-год от изменения схемы до первой партии со склада. Поменялся интерфейс коммуникации — нужно обновить прошивку, пересогласовать схему с системным интегратором, перепройти испытания на ЭМС. Одна «быстрая» итерация растягивается на квартал. Agile сам по себе не вреден. Проблема — когда его применяют не там.
Три задачи, которых нет в IT-продукте Технические компромиссы на уровне схемотехники. PM в электротехнической компании должен понимать, почему заказчик не может перейти на PROFINET, если весь завод работает на MODBUS RTU. И что запрос «добавить 4 аналоговых входа» — это не строчка кода, а пересмотр топологии платы. Без этого понимания продуктовая дорожная карта живёт в параллельном мире от возможностей инженерного отдела. Длинный жизненный цикл продукта. Оборудование АСУ ТП стоит на объектах 10–15 лет. Думать нужно не о совместимости с текущей SCADA, а с теми системами, которые заказчик будет эксплуатировать через 7 лет. Это особая работа с документацией, политикой поддержки старых прошивок, выбором компонентной базы без риска снятия с производства. Двухнедельный цикл планирования здесь — инструмент тактики, не стратегии. Регуляторика как часть продуктовой стратегии с первого дня. Новая линейка ПЛК для энергетики потребует соответствия требованиям РЗА, внесения в реестр российского ПО, сертификации по ГОСТ Р. PM, который не закладывает это в план разработки на этапе концепции, гарантированно срывает сроки вывода продукта на рынок. Не потому что плохо поработал — потому что не знал, где мина.
Три вещи, которые меняют ситуацию Три практики для PM в этой среде. Прямой выход на наладчиков и системных интеграторов — не через продажи, а в поле. Именно они первыми видят, что документация неполная, а разъём не тот. Экспертный совет из ГИП и главных энергетиков на стороне заказчика. Не фокус-группа раз в квартал, а рабочий канал по реальной эксплуатации. Отдельное направление в плане разработки под регуляторные требования — синхронизированное с продуктовым, но со своими рисками и контрольными сроками.
PM в АСУ ТП — это не «тот же продуктовый менеджер, только с железом». Другой горизонт планирования. Другая цена ошибки. Другой тип диалога с инженерной командой. Agile помогает управлять задачами. Но промышленный продукт строится архитектурными решениями, у которых нет кнопки «откатить».
Насколько IT-методологии управления продуктом приживаются в промышленной автоматике — по вашему опыту?
#МенеджерПродукта #АСУТП #Электротехника #ПромышленнаяАвтоматика #ProductManagement