В эволюции взаимодействия ИТ-разработки и бизнеса период простой автоматизации процессов уступил место интеграции информационных продуктов в бизнес-модели. Теперь ИТ-разработка не только поддерживает бизнес, но и является непосредственным соучастником его развития, предоставляя новые возможности для создания ценности.
Разумеется, автоматизация бизнес-процессов всё ещё является преимущественным использованием информационных систем, однако тренд в сторону включения ИТ-разработки в развитие бизнес-моделей непрерывно нарастает. И уже наметилось смещение в сторону следующего шага, когда бурный рост информационных технологий становится основой для экспериментов и поиска новых источников для бизнеса. Создание экосистем управления потребителями, омниканальность, персонализация, цифровая логистика, монетизация данных и многое другое – это энейблеры уже сегодняшнего дня.
И в чем подвох?
Когда ИТ-разработка становится уже не поддержкой, но полноценным соучастником развития бизнеса, жизненно важным является соответствие скорости реагирования на изменяющиеся запросы бизнеса. Интенсивность создания ценности в ИТ-продуктах должна соответствовать темпам развития бизнес-моделей.
Разумеется, в зависимости от особенностей бизнеса эти темпы будут очень разные. Где-то и проектный подход сохранит свои несомненные преимущества в организации управления ИТ-разработкой. Однако он плохо работает на высоких скоростях в тех секторах бизнеса, где быстрый отклик на изменение рынка является залогом успеха, а также там, где непрерывное совершенствование качества продукта составляет бизнес-ценность.
В таких компаниях последовательно идёт трансформация организационного управления в сторону гибких методологий. В принципы организации труда заносятся Agile, DevOps, продуктовый подход.
Все эти методологии декларируют клиентоориентированность, необходимость устранения барьеров между бизнес-заказчиками и ИТ-разработчиками. Однако зачастую непосредственным соучастникам трансформации совершенно непонятно, для чего им эти коммуникации? Какая зримая польза от их усилий, и куда эти усилия необходимо прилагать?
Сделай то, не знаю что!
Чаще всего в компаниях цифровая трансформация является стратегической инициативой, спускаемой сверху. Обозначаются некие целевые состояния, изменения, охватывающие крупномасштабные бизнес-структуры. На непосредственных провайдеров этих изменений, заинтересованных лиц, поддерживающих устойчивость бизнес-моделей и эффективность бизнес-процессов, приземляются некие установки без конкретного разъяснения, как это должно работать.
Иными словами, на уровень линейных менеджеров прилетает распоряжение выстроить взаимодействие с ИТ-разработкой, исходя из новых стратегий развития. И явно обозначается, что в случае неудачи спросят тоже с них.
Уполномоченные таким образом представители бизнеса оказываются в ситуации, когда стратегия изменений им понятна, а вот тактика реализации в руки не даётся. Предполагается, что специалисты высокого уровня, каковыми являются владельцы бизнес-функций, в состоянии сами принимать решения и отлаживать коммуникации с ИТ-разработкой в новых целевых состояниях.
И это действительно так. Только вот типичный линейный менеджмент хорошо умеет управлять, используя привычные инструменты, на директивах и дедлайнах. Более того, сам бизнес зачастую имеет жёсткую бюрократическую иерархическую структуру и не собирается меняться. Оставляя все отстройки новых организационных структур в сторону гибких методологий управления исключительно на стороне ИТ-разработки.
Замечено, что разработчики легче и с большим энтузиазмом воспринимают цифровую трансформацию. Им она более понятна, чем бизнес-заказчикам, с которыми они взаимодействуют. Не в малой степени это происходит потому, что айтишники постоянно находятся в состоянии получения новых знаний. У них происходящие изменения являются естественным продолжением эволюции управления, которая в их мире всегда была интенсивной.
А вот бизнесу, живущему в системе иерархии рангов уже лет триста, очень сложно осознать необходимость стать командным игроком и понять свою роль в управлении ИТ-продуктом. Цепочка создания ценности рассыпается на отдельные звенья.
Это не мои проблемы!
Чем это чревато? Изменения, производимые на стороне бизнеса, не синхронизированы с действиями ИТ.
Когда речь заходит о необходимости продуктового подхода, бизнес подразумевает под этим свой собственный бизнес-продукт. А ИТ-разработчики – информационную систему, над приращением функциональных возможностей которой работают.
Это расхождение в самых базовых понятиях может быть совершенно не очевидно самим соучастникам процесса.
Ответственные за бизнес-область менеджеры сосредоточены на развитии бизнес-продукта. Это огромная работа в физической среде: управление закупками оборудования и расходных, обучение и развитие персонала, согласование юридических аспектов, бюджетирование, регламентация, лицензирование… Очень много процессов может изменяться в соответствии со стратегическими задачами компании в развитии бизнеса! А следовательно, требовать управления от конкретных владельцев бизнес-функций.
В этом аспекте бизнес склонен делегировать внутреннее развитие ИТ-систем в руки профессионалов от разработки и ожидать готового результата по своему запросу. То есть он совершенно не рассматривает в качестве продукта информационную систему и не включает в контур своей деятельности необходимость управления ИТ-продуктом. Зачем?
Даже приняв на себя роль владельца ИТ-продукта, представитель бизнеса продолжает вести себя как сторонний заказчик. Искренне недоумевая, почему он должен тратить свой ресурс на управление непрозрачными и непонятными ему процессами.
Кто крайний?
Бизнес хочет получить результат по своему запросу на изменение той или иной функциональности от команды ИТ-разработки. И результат он получает. И очень удивляется! Потому что результат сильно далёк от его ожиданий.
Представьте, что в вышеописанной ситуации включения ИТ-разработки в бизнес-модели раз за разом результат не будет соответствовать ожиданиям. При интенсивном потоке запросов и сильной зависимости процессов в физической среде бизнес-области с возможностями интегрированных ИТ-систем.
Тогда имеем следующую ситуацию: управляя бизнес-продуктом, его владелец проделывает большое количество дорогостоящих подготовительных изменений, но результат от ИТ-разработки для него остаётся непредсказуем. Уже пора обучать персонал, менять скрипты, заключать договоры? Стоит ли проделывать сложную работу, если в итоге в решающий момент она окажется невостребованной, потому что разработка выдала не то, что ожидалось?
Если отбросить в сторону эмоциональный контекст и поиски виноватых, в сухом остатке будет острая необходимость сфокусировать команду ИТ-разработки на поставку бизнес-ценности, а не только лишь результата. То есть ИТ-продукт должен развиваться строго в направлении, выбранном бизнесом.
Делай, что нужно, а что не нужно – не делай!
Так делается первый шаг на пути управления ИТ-продуктом. Понимание ценности задач, запросов на изменение находится в руках бизнеса.
Донесение ценности, постоянная фокусировка на ожиданиях бизнеса требует отстройки непрерывного обмена информацией, циклов обратной связи, устойчивых коммуникаций.
А кроме того, ИТ-разработчикам вовсе не хочется делать лишнюю работу, которая на выходе будет отвергнута и выброшена в мусор. Это демотивирует, лишает смысла и продуктивности. В сложной интеллектуальной деятельности, которой является создание программных продуктов, отсутствие значимых, зримых, воплотившихся в материальные изменения результатов работы очень быстро подавляет продуктивность.
Представьте себе ситуацию, когда вы пишете сочинение на чётко сформулированную тему, а вам за него ставят самую низкую оценку с формулировкой «тема не раскрыта». И так раз за разом. Очень скоро вы будете писать такие сочинения без всякого энтузиазма, потому что создаётся устойчивое впечатление, что любим решением будут недовольны. Или «сами не знают, чего хотят». А тогда зачем прилагать усилия?
Поэтому фокусировка на ценности, на том, что действительно двигает развитие бизнеса, очень важна. В нематериальной интеллектуальной деятельности нет другого способа получить желаемый результат и замотивировать людей. Тут не помогают скрипты, ГОСТЫ и шаблоны, потому что слишком велика неопределённость в пространстве поиска решений.
Поэтому довольно быстро бизнес осознает, что в новой ситуации надо делать шаг в сторону управления ИТ-продуктом и фокусировать команду на бизнес-ценности. В том числе, чтобы не оказаться крайним в ситуации, когда деятельность ИТ-разработки выдаёт некачественный результат и тем самым тормозит развитие.
Какие инструменты есть для этого в руках бизнеса – тема отдельной статьи. Если вы зафиксируете в комментариях ваш интерес на эту тему, я обязательно поделюсь своими наработками.
Итак, первый шаг в выстраивании коммуникаций между заинтересованным владельцем бизнес-функций и командой, развивающей ИТ-продукт, сделан. Уже прекрасно! Что часто происходит дальше?
Сделаю за час в течение недели до конца месяца
Предположим, что команда разработчиков научилась фокусироваться на ценности, и результаты их работы соответствуют ожиданиям бизнеса. Но поставка ценности в бизнес-среду идёт с непредсказуемой частотой, как правило, слишком медленно.
Со стороны бизнеса это означает, что линейные менеджеры не знают когда и в каких точках прилагать усилия по развитию собственного бизнес-продукта. Когда инициировать всю ту механику перестройки бизнес-процессов, о которой уже говорилось выше? Как прогнозировать развитие и удерживать управление всей бизнес-области как единым целым?
Именно потому, что бизнес несёт ответственность за очень большое количество сложных процессов, он обожает управление на дедлайнах. Так можно разложить в связную схему последовательность действий, алгоритм запуска бизнес-процессов, поэтапные изменения.
Однако, к сожалению, возможность регулировать поставки ценности от ИТ-разработки на дедлайнах – это опасная иллюзия. Причём бизнес-владельцы продукта прекрасно об этом знают. Их распространённый приём: если на ожидаемый срок накинуть 30% времени, то попадём точно в срок. На этом, зачастую, и строится прогнозирование сложных и дорогостоящих изменений.
Когда темп развития бизнеса ускоряется, этот подход больше не работает.
Бизнес делает следующий шаг, приносит дорожную карту развития бизнес-продукта и пытается синхронизировать её с дорожной картой развития ИТ-продукта. Чтобы задать нужный темп разработчиками. И бездны великие распахиваются у него под ногами, потому что оказывается, что размерность элементов работы у этих продуктов фатально не совпадает. То, что бизнес считает задачами и измеряет штуками, для ИТ-разработчика является функциональным сценарием и рассыпается на десятки задач.
Вопрос синхронизации темпов создания ценности в единой цепочке – это снова тема для отдельной статьи. Это сложный процесс, который начинается с выстраивания общей системы понятий и терминов. Что уж говорить, даже к такому важному и полезному инструменту как дорожная карта продукта подходят далеко не сразу. А изначально диалог ведётся на пальцах, как и положено глухонемым.
Хочешь сделать что-то хорошо, сделай это сам!
Итак, уже два шага навстречу друг другу в процессе выстраивания коммуникаций. Уже начинает просыпаться сознание, что существенная часть управления развитием ИТ-продуктов находится в руках бизнеса, может им контролироваться.
Дальше закономерно возникают новые вопросы: а какое количество бизнес-задач в принципе способна решать команда ИТ-продукта? Какова её пропускная способность? Каков недостаток в ресурсах? На каких данных можно делать обоснованный прогноз о поставке ценности? Какие метрики позволят оценить возможности для бизнеса на различных этапах, от планирования развития бизнес-продукта, до оценки прогресса по текущим запросам. И так далее, и так далее.
Все это в какой-то момент приводит к тому, что создаётся единый интерфейс управления ИТ-продуктом. В этом интерфейсе бизнес и ИТ-разработчики действуют в поле единого понимания целей развития и производимой бизнес-ценности, пользуются общей терминологией, учатся применять и развивают инструменты управления рабочими процессами, основывают свои выводы на едином пространстве данных, создают систему правил для организации комфортной среды коммуникаций и оперативного обмена информацией.
Отстройка такого интерфейса – необходимый элемент, позволяющий переключиться с ручного микроменеджмента отдельно взятых запросов на управление потоком изменений в требуемом темпе. И, разумеется, этот интерфейс индивидуален, но подходы к его выстраиванию в целом сходные. Двигаясь пошагово навстречу друг к другу, бизнес и ИТ-разработка проявляют «серые зоны» и вырабатывают организационные изменения, необходимые для совместного управления продуктом.
Ещё о сложности мира
Что важно отметить. В исторически сложившемся ИТ-ландшафте крупных компаний крайне редко бывают ситуации, когда развитие бизнес-продукта зависит от одной конкретной информационной системы. Как правило, развитие бизнеса базируется на целом спектре ИТ-продуктов со своей спецификой управления.
Это означает, что у одного ИТ-продукта роль Владельца продукта (PO) в бизнесе делегирована нескольким стейкхолдерам. Каждый из которых является для продуктовой команды равноценно важным источником запросов. Для ИТ-разработчиков это очень травмирующая ситуация, которая усложняет применение практик гибких методологий управления в их рабочих процессах.
С другой стороны, каждый бизнес-продукт точно так же в своём развитии зависит не от одного ИТ-продукта, а от определённой функциональной области со сложной и сильно связанной экосистемой информационных систем. А это означает, что бизнес-владелец должен управлять не одним ИТ-продуктом, а целой пачкой систем, соучаствующих в создании ценности. Что конечно же требует больших ресурсозатрат.
Все это надо учитывать при выстраивании интерфейса управления ИТ-продуктами. Отказ от такого управления исключает возможность выстраивания единой цепочки создания ценности и интеграции цифровых технологий в бизнес-модель. Разделение процессов в бизнесе и ИТ-разработке должно последовательно и осознанно устраняться.
Надеюсь, эта статья помогла вам ответить на вопрос: зачем бизнесу управлять ИТ-продуктами? Не сомневаюсь, что она породила множество других вопросов: кто? как? с помощью чего? Но это уже совсем другая история.
