Люди поколения Z (родившиеся в 2000-х) отличаются непостоянством привычек — они с легкостью меняют гаджеты, сервисы или другие цифровые продукты, оказывая тем самым давление на их разработчиков. Это давление как никогда до этого велико, пишет на портале ComputerWeekly главный консультант в области облачных сервисов, ИИ и взаимодействия с пользователями сингапурской исследовательской компании Ecosystm Тим Шиди.

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

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

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

Если в эпоху «цифровой трансформации 1.0» для проведения экспериментов отбиралась отдельная команда, которая действовала по бимодальной («затворнической») модели. Для этого ей выделялся отдельный бюджет и она наделялась специальными полномочиями, в то время как остальная часть бизнеса продолжала развиваться проторенной тропой. С одной стороны, это неплохая схема для опробования цифровых инициатив, но реальность такова, что «цифра» по факту затрагивает каждый аспект бизнеса.

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

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

Совместная работа для достижения единой цели

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

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

Совместные команды состоят из следующих специалистов:

  • Менеджер по продуктам и менеджер проектов. По большей части в их обязанности входят надзирательские функции. При работе бок о бок опыт этих специалистов должен дополнять друг друга. Они должны наблюдать за процессом разработки, следить за улучшением продуктов и услуг.
  • Разработчики и специалисты по обеспечению качества продукта (Quality assurance, QA). Последние непрерывно проводят совокупность мероприятий, охватывающих все технологические этапы разработки, чтобы проект не замедлял развитие.
  • DevOps-специалисты. Они по мере необходимости задействуются для обеспечения разработчиков облачной инфраструктурой и платформенными сервисами.
  • Группа по изучению пользовательского опыта/взаимодействия. В ее задачу входит тесное сотрудничество с ИТ-службой для придания продукту или услуге законченного вида. Имеется в виду создание интуитивно понятного интерфейса управления и других опций, которые бы привлекали клиента к их дальнейшему применению.

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

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

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

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

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