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

Встречи / вопросы / ответы следуют друг за другом последовательно. Огромное количество денег рабочая сила потратила на «следующую большую вещь». В конце концов, появляется «новая архитектура». Быстрее, умнее, лучше, чем когда-либо прежде, во всех аспектах.

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

А потом появляется первая бизнес-команда. Они хотят реорганизовать свое приложение, используя новую архитектуру! (Какая радость!).

Команды Framework делятся своими руководящими принципами о новой архитектуре и о том, как ее реализовать, и они очень подробны (серьезно).

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

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

А потом к клубу присоединяется вторая бизнес-команда. Они начали рефакторинг своего приложения, используя новую архитектуру, и у них также есть некоторые вопросы. Значит, они пингуют и технические команды. Кроме того, у первой команды есть несколько более сложных вопросов, чем раньше, и они отправляют электронное письмо на встречу, чтобы обсудить их (и они просят некоторых одолжений, новых функций, которые также необходимы). Технические группы говорят: «О, хорошо, мы справимся с этим!».

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

Смогут ли технические команды справиться со всем этим?

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

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

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

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

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

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

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

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

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

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

Они позволят изменить.

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

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

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

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

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

Омер Коскун, консультант @TeamDefineX

www.teamdefinex.com

[email protected]