Чем продуктовый подход отличается от проектного, почему реальная эксплуатация быстро разрушает идеальные планы и в каких случаях систему действительно стоит развивать как продукт.
В корпоративном ИТ до сих пор можно встретить убеждение, что если цифровую систему запустили в срок и уложились в бюджет – значит работа сделана и все хорошо (на одном из обучений по управлению проектами мне довелось встретить подход к оценке успешности проекта – «если заказчик доволен, значит проект завершен хорошо»). Это, на мой взгляд, и есть главная ошибка, потому что на самом деле для промышленной системы день запуска – это не финиш. Скорее, наоборот: с этого момента у нее и начинается реальная жизнь.
У проекта главный вопрос – получится ли собрать систему и довести ее до запуска. У продукта вопрос глубже – сможет ли система дальше жить в эксплуатации, меняться вместе с процессом, переживать споры между бизнесом, ИТ, пользователями – и продолжать приносить пользу. Полагаю, что именно в этом месте проходит граница между проектом и продуктом.
Пока процесс крутится вокруг сроков, объема работ и закрытия этапов – это еще проектная история. А когда начинаются споры о приоритетах, пересмотр исходных вводных, адаптация под ограничения реальной эксплуатации, повторная защита ценности системы перед заказчиком – вот это уже больше похоже на продукт.
Реальная эксплуатация как точка истины
Лучше всего это видно в промышленных контурах, где система работает внутри живого процесса. Сейчас мы развиваем цифровое решение для заказчиков в нефтегазе и химии – систему управления фланцевыми соединениями (в международной практике это называется «flange management system»). На самом старте концепция выглядела очень логично: браузерный и мобильный интерфейсы, цифровые статусы, пошаговая фиксация операций, данные вносятся по месту работ. Потом мы выехали к потенциальным пользователям в поля – и вылезли моменты, которые заставили кое-что пересмотреть и доработать в планах развития продукта: например, на части месторождений нет нормального мобильного интернета, а на некоторые площадки нефтеперерабатывающих заводов с телефоном вообще не пускают.
В такие моменты больше не получится сказать «это вне рамок проекта» – система должна работать, поэтому приходится искать решение под реальные условия эксплуатации. В описанной выше ситуации мы, например, параллельно проработали гибридный сценарий: специальный бумажный чек-лист, который быстро заполняется на месте, а уже в полевом офисе распознается, переводится в цифру и загружается в систему без ручного перенабора. На словах это не звучит как прорывное решение, но на практике отличие проекта от продукта складывается как раз из таких мелочей: «проект» ссылается на ТЗ, в то время как «продукт» ищет способ сохранить ценность в условиях реального использования системы.
Дальше встает вопрос владения – кто вообще то самое единое ответственное лицо корпоративного продукта. Ответ «пусть им будет ИТ» на практике не очень работает: ИТ качественно закрывает вопросы с архитектурой, надежностью, скоростью реализации, интеграциями. Но у внутреннего продукта почти всегда есть бизнес-цена и бизнес-цель, поэтому конечный владелец в корпоративной системе чаще всего находится на стороне бизнеса. И между бизнесом, ИТ и пользователем почти всегда нужен человек, который умеет переводить с языка одной стороны на язык другой, выявлять актуальные потребности реальной эксплуатации, приоритизировать задачи и отстаивать интересы продукта в соответствии с выбранной стратегией. Без этой связки корпоративный продукт быстро скатывается в одно из двух: либо в бесконечную очередь фичей, либо в технически безупречную штуку, которой никто не хочет пользоваться.
Отдельная боль – метрики. Продукт далеко не всегда получается объективно измерить через MAU, ретеншн и количество фич в релизе. Смотреть надо на другое и с другой точки зрения. Например, если говорить о нашем продукте: насколько быстрее формируются дефектные ведомости и ремонтная документация, становится ли прозрачнее история по конкретному узлу, получается ли точнее планировать работы и материалы, снижается ли вероятность технологических нарушений из-за человеческого фактора, не теряются ли замечания где-то между подрядчиком, механиком и итоговым отчетом. В нашем случае некоторые целевые метрики выглядят так:
Наименование метрики
Без использования софта
С софтом
Передача знаний по предприятию новому сотруднику
до 2 месяцев
до 1 недели
Подготовка дефектных ведомостей для подготовки ремонта
от 1 месяца
до 5 дней
Избыточные закупки МТР
до 30%
до 5%
Пробелы в истории выполнения работ
вероятны
отсутствуют
Вероятность нарушения технологии обслуживания
до 35%
до 5%
Поиск актуальной информации по фланцевому соединению в реестре
до 2 часов
до 1 минуты
Подготовка отчета по итогу ремонта
до 10 дней
до 10 минут
Вот это как раз те метрики, которые имеют реальное значение – результаты, которые дает продукт пользователям. Но тут важно удержаться от соблазна «продать» то, что напрямую не связано с продуктом: например, нам очень хотелось сказать, что наш софт дает «увеличение времени полезной работы персонала за смену» с 35% до 55%, но в больших промышленных процессах на этот показатель влияет столько всего, что приписывать эффект одной конкретной системе – это, по меньшей мере, непрофессионально и недальновидно. Здесь очень многое зависит от дисциплины подрядчиков, регламентов предприятия, корпоративной культуры, строгости контроля соблюдения стандартов и многого другого.
Отдельная метрика – экономический эффект. С учетом специфики цифровых продуктов эту метрику также бывает непросто посчитать, особенно учитывая уже упомянутое желание «красиво продать». Нередко экономический эффект от внедрения продукта, особенно в первые несколько месяцев, целесообразно рассматривать с производственно-управленческой точки зрения (предотвращение потери данных, повышение управляемости качества работ, снижение человеческого фактора и т.д.) – то есть не обещать экономию «миллионов» сразу. Это объясняется тем, что улучшения, которые даст внедрение цифрового продукта, могут показать «экономику» не сразу – например, эффекты «сокращение вероятности простоя оборудования и срыва срока пуска» и «повышение промышленной безопасности» могут проявить себя в горизонте нескольких лет эксплуатации промышленных активов предприятия, при этом стоимость простоя в нефтегазовой и нефтегазохимической промышленности может исчисляться десятками и даже сотнями миллионов рублей в сутки. Здесь напрашивается аналогия с подушкой безопасности или системой курсовой устойчивости в автомобиле – она может никогда не пригодиться и за 10 лет эксплуатации, но в экстренной ситуации ее наличие может спасти жизнь и здоровье.
После запуска начинается самое веселое
Есть еще одна линия разлома между проектом и продуктом – «развитие против поддержки». На словах развивать систему хотят все. В жизни внутренняя корпоративная система, оказывается зажатой между инцидентами, обязательными и срочными доработками, интеграциями, техдолгом и свежими запросами бизнеса. Если продуктовой логики нет, дальше вероятен один из двух сценариев: либо операционная текучка съедает любое развитие, и система потихоньку костенеет, либо команда упорно рисует красивый роудмэп, в упор, не замечая реальные боли эксплуатации. Плохо и то, и другое. И здесь поддержка – это именно те ребята, которые дают самую неприятную, но при этом самую честную правду о системе – что реально работает и требует внимания команды, а что живет только в презентациях.
Также важно не путать пилот с продуктом. Пилот – это вход в реальность, а не доказательство зрелости решения. В корпоративной среде сразу после пилота начинается этап, который, как правило, затягивается: согласование со всеми вовлеченными функциями, внутренние требования ИТ и безопасности, поиск бюджета, попадание в цикл планирования закупок, расстановка приоритетов на стороне заказчика. Пользователи иногда готовы начать использовать продукт хоть с завтрашнего дня, но компания физически не может принять такое решение быстро, даже когда всем все нравится. И это просто свойство большой организации, где любое внедрение пропускают через несколько контуров оценки риска и согласования – это нужно принять и понимать заранее. Поэтому корпоративный продукт живет не только в логике функций, но и в логике доверия, готовности самой компании к изменениям и длинного цикла принятия решений. Здесь еще хотелось бы сказать о репутации разработчика и о его умении выстраивать и развивать длительный диалог с потенциальными заказчиками – но это уже тема другого материала.
И еще одна мысль напоследок: не каждую корпоративную систему стоит превращать в продукт. Эту ошибку тоже совершают часто. Если система закрывает узкую стабильную функцию, почти не касается бизнес-логики, существует в режиме регламентной поддержки и ее ценность не приходится раз за разом заново обосновывать – честнее назвать ее «поддерживаемой системой», а не «продуктом». Если «продуктом» называть все подряд, сам подход быстро обесценивается. Продуктовая модель имеет смысл там, где после запуска неизбежна борьба за приоритеты, изменения, данные, качество эксплуатации и экономический эффект. Там, где система просто должна стоять и не падать, вполне хватает нормальной поддержки и дисциплины изменений (как тут не вспомнить поговорку «работает – не трогай»).
Поэтому продуктовый подход в корпоративных системах начинается не с переименования «проджект-менеджера» во «владельца продукта», а с первого настоящего столкновения с реальной эксплуатацией. Когда оказывается, что рабочие процессы различаются на разных объектах даже в рамках одного предприятия, технологические объекты работают не по идеальной схеме, исходных данных не всегда достаточно, интеграции сложнее и объемнее – вот тогда действительно заканчивается проект и начинается продукт.
В корпоративном ИТ главный вопрос давно уже не в том, где заканчивается внедрение. Главный вопрос – где начинается ответственность за то, как эта система будет жить и развиваться дальше. Вот это уже точно продукт.