Компании хотят видеть бизнес-результаты от ИТ-проектов, но может ли традиционное управление ИТ-проектами обеспечить их достижение? По мере сокращения временных циклов внедрения новых ИТ-систем пользователи и ИТ-отделы все чаще рассматривают ИТ-результаты не как проекты, а как продукты, пишет на портале InformationWeek Мэри Шеклет, президент консалтинговой компании Transworld Data.

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

Менеджер проекта отвечает за тактическое управление проектом от начала до конца, но не обязательно отвечает за создание видения конечного ИТ-продукта и за то, как он будет полезен бизнесу сегодня и в будущем.

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

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

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

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

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

Вот несколько способов формирования культуры управления продуктами в ИТ-службе:

Называйте проекты с учетом их бизнес-целей. ИТ-специалисты и пользователи склонны называть проекты по терминологии ПО или процессов, на которые они направлены. Распространенными названиями проектов являются «ERP», «CRM» и т. п. Это хорошо, но в названиях проектах должны быть ссылки на бизнес-замысел.

Например, вместо того чтобы просто назвать проект «CRM», можно указать его бизнес-цель: «Повышение доходов и лояльности путем создания 360-градусного представления о каждом клиенте, чтобы каждый сотрудник компании понимал его».

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

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

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

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

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

Определяйте людей, способных стать менеджерами по продукту. Не каждый сотрудник ИТ-отдела может или хочет стать менеджером по продукту. Есть те, кто предпочитают оставаться «инкапсулированными в ИТ» и не выходить в мир пользователей или бизнеса. Другие могут быть заинтересованы, но им не хватает навыков общения, ведения переговоров и видения, которые необходимы менеджеру по продуктам.

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

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

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

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

Я сделала три вещи:

  • Сформулировала бизнес-причину перехода на новую систему, которая заключалась в том, что мы не сможем продвинуть компанию вперед в области технологий и бизнес-процессов, пока не перейдем на аппаратное и программное обеспечение, способное расти вместе с нами.
  • Еженедельно информировала пользователей о ходе конверсии с помощью гистограммы «процент выполнения», которую могли видеть все желающие.
  • Проводила стратегические встречи с бизнес-лидерами всей компании для выработки стратегических направлений развития бизнеса и технологий после завершения преобразования. Благодаря этому ИТ для бизнеса смогли стратегически двигаться вперед.