В предыдущей статье из цикла «Особенности национальной ИТ-трансформации» речь шла о проблемах понимания готовности бизнеса к изменениям.
Переход к гибким формам организационного управления и продуктовому подходу требует реформирования процесса разработки, начиная с верхнего уровня управления. Готовность бизнеса определяется через возможность выстраивать внутренние коммуникации по другим правилам.
А кроме того, ИТ-трансформация потребует перестройки структуры управления в компании, развития новых компетенций и кадрового потенциала, улучшения инженерных практик, внедрения нового стека технологий, приобретения необходимых инструментов и много чего ещё. Сложность и ресурсозатратность такого пути становится большим барьером на старте.
Однако бизнесу хорошо известно, что чем выше риск, тем больше прибыль. Это весомый аргумент, который помогает преодолеть сопротивление к необходимости изменений, как только становится понятно, какую выгоду можно от них получить.
Чего бизнес ожидает от ИТ-трансформации?
По мнению экспертов, занимающихся оценкой особенностей продвижения гибких методологий управления в России, есть топ пять основных выгод, которые бизнес ожидает получить от перехода к продуктовому подходу и гибким практикам в ИТ.
- Ускорение поставок и выхода продуктов на рынок;
- Повышение качества продуктов;
- Изменение границы бизнеса и получение новых источников дохода;
- Улучшение процессов;
- Баланс бизнеса и ИТ.
Не претендую на то, что детально раскрою все механизмы, но давайте пройдёмся по этим пунктам в духе ожидания/реальность и попробуем разобраться, как это работает на практике.
Ускорение поставок и выхода продуктов на рынок. Когда заходит речь об ускорении, непременно говорят о более точном попадании в ожидания клиентов, о возможности настроить персональный маркетинг, изменить цепочки поставок и расширить целевую аудиторию за счёт оперативного реагирования на изменения рынка. Все эти цели очень привлекательны, но звучат как лозунг, а не как реальное основание ввязываться в глубокие системные изменения.
О чем на самом деле стоит задуматься бизнесу на практике: как часто и регулярно принятые бизнес-идеи доходят до релиза? Соответствует ли эта периодичность требованиям рынка? Насколько часто нарушаются договорённости по срокам поставки новой функциональности? Сколько в принципе бизнес-идей отклоняется без надежды на реализацию? Много ли проектов навечно кануло в разработку и так и не дошло до потребителей? Сколько стоили не реализованные бизнес-идеи?
Если в вашей компании есть ощутимые проблемы по затронутым вопросам, можно кидать первый камешек на чашу весов в пользу трансформации управления ИТ разработкой.
Одним из ключевых моментов digital-трансформации является перестройка рабочего процесса в соответствии с продуктовым подходом. А для этого прежде всего необходимо существующий рабочий процесс проявить, сделать видимым и понятным. Описать, как функционируют разработка, тестирование и поддержка, и где копятся проблемы. Провести анализ всего ИТ-ландшафта, понять связи и взаимодействия между отдельными командами и системами.
А затем, в соответствии с практиками и методологиями, которые предлагает продуктовый подход, снизить жёсткость системы, сбалансировать взаимодействия между отдельными структурами и упорядочить рабочие процессы.
Ускорение происходит не за счет того, что люди начинают работать быстрее, а за счет того, что процессы становятся более управляемыми: очищаются от лишней работы, не приносящий ценности бизнесу, и избавляются от тормозящих зависимостей, согласований и блокировок.
А налегке, без обременения балластом ненужной работы и вредных процессов, поставка работающего продукта действительно становится более эффективной и предсказуемой.
Повышение качества продуктов – залог стабильного существования в новых рыночных условиях. Сейчас потребительский спрос уже не в той мере зависит от удобства совершения сделки, сколько от лояльности к бренду или поставщику. Когда перед потребителем открыт весь мир, соревнование за качество становится фактором выживания в конкурентной среде.
Но прежде, чем мечтать о повышении лояльности клиентов, задумайтесь, а как у вас с качеством сейчас? Сколько бизнес-идей приходится откатывать назад, на доработку из-за багов? Какая у ИТ-разработки есть обратная связь о качестве, кроме очереди дефектов? Часто ли вы продавливаете бизнес-задачи на скорость, имея на руках возражения о том, что это повлечёт неоптимальное техническое решение, способное сильно нарушить работу системы в будущем? Знаете ли вы о существовании технического долга и необходимости его выплачивать за счёт бизнес-задач?
Если есть проблемы по этим пунктам – готовьте второй камешек на весы, склоняющие к изменениям.
После того, как рабочий процесс проявлен и выявлены существующие проблемы в ИТ-разработке, с ними надо работать предметно. Это постоянный и непрерывный процесс улучшения, который будет двигаться небольшими шагами, последовательно и неотвратимо.
Практики продуктового подхода позволяют сделать работу над качеством регулярной, и защищают её от попыток отложить на потом. На первом этапе отстройки рабочего процесса усилия направляются на то, чтобы снизить количество проблем, напрямую влияющих на качество– технический долг в системе, устаревшие технологии, недостаток ресурсов (особенно квалифицированных специалистов) и т.п. Это та программа-минимум, к которой правильное применение продуктового подхода и связанных с ним методологий управления приведут гарантировано.
Затем начинается работа посложнее, когда организационное управление направлено на развитие сотрудничества всех заинтересованных сторон и обмен компетенциями, влияющими на создание качества. При этом ожидания заказчика могут быть расширены за счёт экспертного знания со стороны ИТ- разработки о функциональной архитектуре систем и возможностях среды эксплуатации. Это уже история зрелой компании, прошедшей серьёзный отрезок пути изменений.
Изменение границы бизнеса и получение новых источников дохода. Опять же первое, о чем хочется думать бизнесу – это о расширении масштабов и выходе на новые рынки. Но задача изменения границ и поиска новых источников на самом деле далеко не всегда по это. Зачастую речь идёт о том, что вести бизнес в прежних границах становится проблематично, а доходы опасно снижаются.
В текущих реалиях точка ведения бизнеса все больше смещается в online. Изменяются фундаментальные принципы логистики и коммерции. Различные интеграторы и маркетплейсы меняют структуру бизнеса не только у чувствительных к этому финансового сектора и ритейла, но и многих куда более неповоротливых и монолитных структур. Изменяются каналы коммуникаций и межведомственного взаимодействия. Развитие цифровых сервисов и платформ даёт бизнес-возможности, расширяющиеся с каждым днём. Повсеместно возникающие стартапы, необремененные необходимостью масштабироваться, меняют стандарты потребления и повышают планку R&D перед крупным бизнесом.
В этих условиях появляются советующие требования к развитию ИТ- ландшафта. Задайтесь вопросом, как перераспределены ресурсы между новыми проектами и теми, которые давно обеспечивают стабильность вашей компании? Сколько изменений вам требуется, чтобы соответствовать смещению границ бизнеса в этих условиях? Много ли вспыхивает пожаров, когда поставка новой функциональности критически необходима для поддержки доходов? Как вы тушите эти пожары, деньгами или специалистами?
Если есть ощущение, что ваш бизнес не успевает за нарастающими изменениями внешней среды, что вам постоянно приходится закладываться на большие риски и инертность системы, то готовьте третий камешек, вам от него не увернуться.
Здесь можно говорить о многих практиках, заложенных в гибкие подходы к управлению и целенаправленно снимающих жёсткость системы. Однако, на мой взгляд, главным ответом на быстрые изменения внешней среды может стать перестройка командного управления.
Оговорюсь, я не подразумеваю, что необходимо сделать каждую команду разработки гибкой по канону Agile – кроссфункциональной, самоорганизующейся и выделенной на один конкретный продукт. Это очень хороший подход, но на сложных крупных ИТ-ландшафтах трудно достижимый. Однако провести определённые организационные изменения, которые заметно снизят жёсткость управления в ИТ-разработке можно практически всегда. Опять-таки через разумное применение практик продуктового подхода.
Прежде всего, необходимо провести функциональные границы сервисов в экосистеме компании и настроить процессы коммуникации. Это позволяет сместить фокус процессного управления на поставку ценности для бизнеса и развитие сотрудничества внутри команды и между всеми заинтересованными сторонами.
Эти общие принципы поддерживаются любой методологией организации рабочего процесса, декларирующей гибкое управление и продуктовый подход. Выбор обусловлен особенностями ИТ-ландшафта, но поступательное следование принципам и правильное применение соответствующих инструментов гарантировано приводят к формированию нужных результатов.
Разумеется, потребуются дополнительное обучение команды и длительная отстройка рабочего процесса, которые придётся драйвить и пилотировать на старте. Но изменение границ бизнеса и новые источники доходности всегда требуют подобной поддержки, вне зависимости от выбранного подхода.
Улучшение процессов обычно подразумевает оптимизацию стратегического планирования и повышение эффективности работы, за счёт роста продуктивности отдельных сотрудников. Однако, прежде чем что-то улучшать, необходимо это нечто измерить. А когда речь идёт о нематериальной деятельности ИТ-разработчиков, вопрос о том, как проводить регулирование не всегда прояснён.
Какими метриками ИТ-разработка в вашей компании пользуется сейчас? Сколько незавершённой работы существует в данный момент в системе? Как балансируется нагрузка и распределение задач от бизнеса? Насколько предсказуемы риски и сроки поставки требуемого функционала? Как измеряется эффективность работы и достижения результата? Насколько хаотично функционирует ИТ-разработка? Что тормозит процессы развития? Какие сигналы вы используете для принятия решений в краткосрочном и долгосрочном периодах?
Если большинство решений принимается субъективно, исходя из опыта, методом проб и ошибок, если есть проблемы с измеримостью рабочих процессов – это очередной камешек на весы необходимости трансформации подхода к управлению.
Процессные практики, на которые опирается продуктовый подход, уделяют пристальное внимание проявлению, визуализации и устранению потерь. Введение набора метрик и регулярная работа с метриками, позволяющими следить за текущим состоянием системы, являются обязательными шагами. Как минимум они позволяют измерить время, которое бизнес-задачи проводят в процессе работы, прогнозировать объем поставляемых функциональных изменений по срокам, отслеживать количество дефектов и возвратов в работе. А максимум зависит только от настойчивости лидеров изменений.
Метрики делают процесс разработки более явным и управляемым. Когда культура измерений становится частью рабочего процесса, можно говорить о выявлении проблемных мест и рисков, и направленной работе по улучшению процессов.
Помимо этого, обязательно уделяется внимание техническим решениям и их реинженирингу, как системному плановому процессу, а не случайной деятельности. Тоже самое касается функциональной архитектуры, её документации и трансляции для комплексного понимания.
Плановый упорядоченный системный подход к работе над задачами, не доставляющими ценности бизнесу, но являющимися важной частью обеспечения работоспособности продукта, позволяет улучшить процессы на разных уровнях. Практики организационного управления дают защиту от давления бизнес-задач над другими аспектами разработки. Причём защиту достаточно жёсткую, чтобы удерживать развитие процессов по всем аспектам деятельности равномерно.
Эта работа не заканчивается никогда. Практика непрерывного улучшения – одна из ключевых в этих подходах. Начинаясь в отдельных командах, она в итоге затрагивает всю экосистему компании и не перестаёт развиваться.
Баланс бизнеса и ИТ сам по себе процесс сложный и противоречивый. Выгода тут проявляется через более точную фокусировку ИТ-разработки на ожиданиях бизнеса. Причём важным достижением становится не только следование фиксированным требованиям, но и расширение их с привлечением экспертизы разработчиков. Хочется, чтобы соучастие профессиональных специалистов, владеющих комплексным видением архитектуры и возможностей системы, смещалось в область генерации новых бизнес-идей. Чтобы велась совместная проработка и поиск эффективных решений и улучшения качества, причём начинался этот процесс как можно раньше.
Ожидания заказчика от ИТ-разработки зачастую фиксируются в форме техзадания, существенно ограничивающего реальное понимание целей продукта. В какой форме осуществляется передача требовании в вашей компании? Часто ли требования теряют актуальность до того, как будут реализованы в разумные сроки? В каком объёме вносятся дополнения и исправления в ходе работы над задачами? Вовлечены ли разработчики в процесс анализа бизнес-идей? Часто ли возникают отсылки на недостаток ресурсов разработки для реализации той или иной концепции?
Если есть трудности во взаимопонимании между бизнесом и ИТ разработкой, то это повод для совместного разговора и перестройки. Однако, не спешите ронять камушек на весы трансформации, поскольку в этом аспекте она потребует серьёзных уступок с обеих сторон.
Важной частью организационных изменений, которые необходимо проделать для достижения баланса между ИТ и бизнесом является создание чётких, понятных и явных правил, которые должны будут соблюдать все заинтересованные стороны. Эти правила действуют в обоих направлениях: как разработка должна будет стремиться к глубокому пониманию целей и ценностей создаваемого продукта, так и бизнес должен будет ограничивать свои желания реальными ресурсами сервисов.
Камнем преткновение здесь часто становится нежелание обеих сторон преодолевать барьер понимания. ИТ-разработка склонна обезопасить свою зону ответственности следованием техническому заданию и разграничением функций между исполнителями. Бизнес не слишком горит желанием погружаться в процесс разработки, и старается продавить выполнение своих задач.
Практики гибкого управления и продуктового подхода стремятся разрушить эту стену. Вовлеченность во взаимные процессы и следование установленным правилам взаимодействия без попытки что-то продавить являются неотъемлемой частью этих практик. Это действительно требует заметной перестройки не только на уровне организационного управления, но и на уровне мышления и представлений о собственной зоне ответственности.
Часто непонимание того, как в реальности можно выстроить культурное взаимодействие в компании становится сильным аргументом в пользу того, чтобы вовсе не начинать этот процесс. Однако на практике все не так уж страшно.
Человеческое сознание способно проявлять чудеса гибкости и адаптации, когда речь заходит о взаимной выгоде и сокращении издержек. Достаточно чётко проявить выгоду от смены ответственности, и коллектив приспособится к новым условиям быстрее, чем вы успеете сменить технологический стек.
Управление человеческими ресурсами и так является необходимым и отлаженным процессом в бизнесе. Остаётся только сфокусироваться на следовании принципам и практикам digital-трансформации и последовательно применять соответствующие методы и инструменты в контексте организации людей.
Сделать переходный процесс понятным каждому участнику и грамотно распределить роли, проявить конкретную выгоду для каждого и снизить обычное сопротивление изменением – задача не за пределами возможностей. А о том, в чем заключаются эти выгоды и роли, я планирую рассказать в следующей статье из этого цикла. Так что, если тема для вас актуальна – следите за публикациями.
Как видите, никакой магии в том, как работает трансформации в ИТ нет. Есть необходимость понимания подходов, обоснованного выбора практик, грамотного применения соответствующих им методологий и инструментов. Во всем этом можно и нужно разбираться, пока неумолимый ход эволюции не привёл к вымиранию вашего бизнеса.
