ENG
Цифровая трансформация на основе анализа данных — процесс, требующий серьезной экспертизы, командной координации и управленческой воли. Сегодня на большие проекты в этой области все чаще привлекают Agile-компетентных специалистов. Насколько методология продуктовой разработки подходит для решения задач этого типа и масштаба?
В России и в мире
Около 20% компаний в России, занимающихся цифровой трансформацией, действительно качественно перестроили свою работу: провели редизайн организационной структуры и адаптировали новую систему ценностей. В США и Европе эта доля существенно выше и достигает 50%. Безусловные лидеры — ИТ-сектор, финансовые и страховые организации, различные отраслевые экосистемы (например, симбиоз ритейла, телекома и логистических операторов).
В арьергарде же те направления, которые исторически слабо вкладывались в ИТ. Это строительство, фармсектор, добывающая и перерабатывающая промышленность. Их отставание обусловлено финансовой моделью работы, спецификой задач, культурой компании, возможностью привлечения лучших руководителей, способностью этих руководителей понимать необходимость изменений и иметь навыки для качественной адаптации такого рода изменений.
Но сегодня компании из «отстающих» в плане цифрового развития областей стремятся ликвидировать разрыв. Делают они это, «переманивая» ценнейший актив — цифровых экспертов и руководителей, занятых в «авангардных» отраслях, и это — основополагающий фактор успеха, потому что для цифровой трансформации, особенно заточенной на изменения через продвинутую аналитику бизнес-данных, сама ИТ-инфраструктура, например, — всего лишь средство. Важнее получить экспертное заключение о том, какая именно ИТ-инфраструктура нужна и как ее правильно настроить и эксплуатировать.
В условиях дефицита кадров и экспертизы не получится даже запустить проект трансформации. Некому будет определить необходимые технологии, продумать их правильное применение даже в рамках самой современной инфраструктуры и солидного бюджета. Речь идет именно об уровне компетенций специалистов, которые принимают решения и следят за результатом. При этом ключевую экспертизу лучше выращивать внутри компании, получая точечную помощь у консультантов и подрядчиков.
Шаблон запуска data-проекта
Основной фактор успеха data-проектов при цифровой трансформации — заинтересованность внутреннего заказчика. Нет заказчика — нет финансирования, нет мотивации в принятии ключевых решений, нет приоритезации данной активности. «Спонсором» проекта должно выступить руководства от бизнеса, четко понимающее цели. Как правило, это топ-менеджмент.
Второе — правильно выстроенная команда, которая готова сделать финальный продукт. Неважно, внутренняя это команда или внешняя, главное — цельность, сыгранность коллектива по всей вертикали, от экспертов до руководящего состава.
Третье — детальное планирование на старте, тщательная проработка всех аспектов, включая планы работы и митигацию рисков. Сюда входит всё: предполагаемые архитектурные решения, ИТ-инструменты, бюджет, критерии оценки качества. В небольших компаниях этот пункт опционален, особенно если организация придерживается гибких методологий, может позволить себе работать с прототипами и менять курс по ходу проекта. В корпорациях все иначе: лучше перестраховаться, сделать предпроекты — небольшие тестовые «забеги», которые обеспечивают измеримость и другие критерии, что повышает шансы на окончательное одобрение на уровне заказчиков и спонсоров.
Четвертый момент — выбор оптимальной методологии. Здесь большую роль играет переход от взаимодействия в формате «заказчик — исполнитель» к работе в одной команде согласно принципам методики Agile.
При таком подходе грамотные владельцы продукта, которые находятся на стороне бизнеса, могут обеспечивать успех проекта, распределяя приоритеты и корректируя направление работ для достижения оптимального качества продукта. В свою очередь за исполнением задач следят ИТ-лидеры: Scrum-мастера, тимлиды — с учетом видения архитектуры, возможностей инфраструктуры и так далее.
Сложности непродуктового Agile
Одна из главных сложностей применения Agile к data-проектам заключается в невозможности декомпозировать некоторые задачи в спринты. Например, загрузка данных в новую систему или в хранилище в крупных компаниях может выполняться более недели. Или в рамках проекта требуется провести закупку ИТ-решений — в наших условиях это занимает 3–6 месяцев. Плюс в крупных организациях пока не могут полностью отойти от длительных согласований документации, местами в бумажном виде. Все эти составляющие проекта нельзя «упаковать» в Agile-спринт.
Кроме того, многие чувствительные данные нельзя передавать в среды разработки и тестирования. В случае с классической разработкой это не несет больших проблем, потому что там не требуется много данных для создания качественного решения. Но в рамках data-проектов продуктом являются сами данные: можно сильно потерять в качестве итогового решения, даже используя самые современные алгоритмы маскирования.
Конечно, разработчики (особенно в случаях привлечения подрядчиков), по-хорошему, не должны видеть промышленные данные, финансовую информацию, персональные данные и так далее. Но разрабатывать адекватные решения, не видя, для чего конкретно они предназначаются, — тяжело. Для преодоления этого вызова появляются отдельные роли в рамках проекта, которые получают ограниченный доступ к данным. И тут возникают повышенные риски информационной безопасности, сложность к выдаче прав, требования к инфраструктуре.
Отчет за месяц по заданным параметрам в масштабе крупного бизнеса, например на производстве, не может быть готов на 50% или 20%. Отчет либо готов, либо нет, что также не бьется с Agile в классическом виде метода. Преодолевать это противоречие можно только вырабатывая продуктовый подход к проектам. Нужно ставить цели трансформации, которые предусматривают вывод более или менее «упакованного», понятного нового функционала.
Data-driven подход
Важной основой для запуска успешных data-проектов в Agile является переключение на подход, основанный на данных. Компания должна научиться управлять данными в компании: знать о местах их хранения, понимать их качество, следить за доступностью и безопасностью.
Более «приземленная» цель — внедрять инструменты управления данными, встраивать анализ с точки зрения работы с данными в общий конвейер процесса изменений. Работа с данными должна полноценно встраиваться в производственный цикл, в котором сотрудники начинают реально управлять данными. В эту цепочку интегрируется человек, data-инженер, который прорабатывает процессы.
Следующая цель — решение бизнес-задач на основе анализа данных. Для этого на рабочих столах менеджеров появляются инструменты QlikView, Tableau и другие. Менеджеры компании узнают, как из дашбордов получать оперативную отчетность, продвинутую аналитику и прогнозы.
Далее появляются целые отделы, которые могут целенаправленно работать с данными для бизнеса. Измеряться по эффективности работа такого отдела может показателем Time to Market или пропускной способностью, скоростью и объемами анализируемых данных. Например, отдел может добиться того, что бизнес принимает решения на основе анализа данных не трехдневной данности, а на максимально свежих цифрах и выводах, вплоть до режима реального времени. Закладывать обновленные принципы работы с данными нужно в организации «сверху вниз», расширяя и при необходимости обновляя персонал. На текущем этапе особенно важной становится роль Chief Data Officer (CDO), который должен нести изменения, меняя культуру и преодолевая любое сопротивление.
Третий этап — появление новых конкурентоспособных продуктов, сгенерированных на базе работы с данными. Речь может идти о новых форматах визуализации, например с помощью VR-технологий, которые могут помочь видеть отчеты в реальном времени в наглядной выкладке прямо на экране VR-очков.
Но в таких проектах не обойдется и без подводных камней. Все они связаны с различными сценариями сбоя на уровне ролей внутри команды. Например, если владелец продукта не справляется со своей функцией, ее должен нести либо верхнеуровневый бизнес-руководитель, у которого не будет хватать времени и погруженности в детали, либо представитель ИТ, не умеющий мыслить как бизнес-менеджер. И то, и другое негативно повлияет на фокус проекта.
Аналогично, если архитектор неправильно выберет решение на уровне ИТ-системы, или тимлид неправильно спланирует техническую реализацию, или «инфраструктурщики» предоставят неверный программно-аппаратный комплекс, а системный аналитик допустит ошибки в проектировании, итог одинаков — пострадают сроки и качество.
Цена ошибки, обнаруженной завтра, всегда будет выше, чем у найденной сегодня. Поэтому лучше инвестировать в предпроект или прототип, чем сразу выводить в продуктив целевое решение, не проработав все риски. Если упустить хотя бы один из компонентов проекта, однажды можно обнаружить, что несколько месяцев напряженной работы десятков специалистов уйдут в ноль и в работающее техническое решение не эволюционируют. Выход из таких ситуаций — либо вкладываться в доработку решения со всеми издержками, либо перезапускать проект с нуля.
Вмешаться в проект могут и внешние факторы. Например, при разработке отчета мы рассчитываем на то, что источником данных будет выступать SAP. И всё проектирование, разработку команда затачивает под эту предпосылку. А затем выясняется, что у нас произошло импортозамещение — все переводится на 1С.
Изменение приоритетов и требований бизнеса также может полностью поменять смысл проекта. К примеру, компания продавала один вид продукции, но произошли отраслевые или глобальные потрясения — все, со следующего квартала она будет продавать совершенно другие товары с другими характеристиками. А значит, наш продуманный data-ориентированный проект в рамках цифровой трансформации разворачивается на 180 градусов.
Чтобы избежать таких неожиданностей, важно вести проактивный мониторинг рисков, проблем и возможностей с пониманием того, кто в команде должен «отлавливать» подобные риски, а также — как их отрабатывать.
