У сложных проектов есть неприятный парадокс. В них могут работать сильные специалисты. У компании может быть понятная стратегия, опытная технологическая команда, профессиональный маркетинг, хороший продукт и поддержка первого лица. Каждая функция по отдельности способна выполнять свою работу качественно — и всё же проект начинает замедляться, решения конфликтуют, сроки расползаются, а результат оказывается слабее суммы вложенных в него усилий. Причину обычно начинают искать внутри функций. Проверяют IT, меняют процессы, усиливают project management, уточняют KPI, проводят новые встречи. Но иногда проблема находится совсем в другом месте.
Она находится между функциями. Именно там стратегия должна превратиться в продукт. Продукт — встроиться в технологическую архитектуру. Технология — учитывать поведение клиента. Маркетинг — знать, что именно и когда выйдет на рынок. Служба поддержки — понимать будущий клиентский путь. А решения разных подразделений должны складываться в одну систему раньше, чем каждый начнёт оптимизировать собственный участок. За годы работы со сложными проектами я всё чаще воспринимаю это пространство как отдельную профессиональную область. Я называю её Strategic Project Architecture.
Чем сложнее проект, тем меньше его результат принадлежит одной функции. И тем важнее становится архитектура связей между ними.
Мобильный банк как тест на организационную архитектуру
Особенно хорошо я увидел это во время работы с Converse Bank. На первый взгляд задача выглядела вполне привычно: развитие мобильного банка. Но мобильный банк давно перестал быть просто IT-продуктом. Для банка это одновременно технология, продуктовый канал, клиентский интерфейс, инструмент продаж, часть бренда, среда коммуникации и всё чаще — основная точка ежедневного контакта клиента с компанией.
Каждая из этих частей находилась в зоне ответственности разных людей. Технологическая команда отвечала за реализацию и стабильность. Retail — за банковские продукты и бизнес-логику. Marketing — за предложение, коммуникацию и восприятие. UX — за сценарии пользователя. Информационная безопасность — за ограничения и риски. Customer Service — за последствия всех этих решений в реальном общении с клиентом. Именно поэтому вопрос развития мобильного банка очень быстро перестал быть вопросом исключительно разработки. В начале 2023 года CEO банка предложил изменить существующую модель управления этим направлением. В ответ я предложил создать CFT — постоянную cross-functional team, собранную вокруг самого продукта.
Идею поддержали. Особенно глубоко в дальнейшую работу включились руководитель Retail и руководитель mobile development. Это решение оказалось для меня важным далеко за пределами одного конкретного проекта. Мы фактически изменили объект управления. Раньше мобильный банк легко было воспринимать как набор задач, которые последовательно переходят от бизнеса к IT, затем к маркетингу и дальше по организационной цепочке.
В новой модели появился общий контур, внутри которого продукт можно было видеть целиком. И это принципиально другая конструкция.
Самая дорогая ошибка — управлять частью системы как всей системой
Большинство компаний организовано по функциям. Это логично. Финансы должны хорошо заниматься финансами. IT — технологиями. Marketing — маркетингом. Retail — бизнесом. Проблема появляется тогда, когда результат компании перестаёт совпадать с границами её организационной структуры. Клиент не видит подразделений.
Он видит один мобильный банк. Ему безразлично, какая команда отвечала за конкретный экран, кто согласовывал текст, кто определял бизнес-правило и кто занимался интеграцией. Если приложение работает неудобно, для клиента неудобен банк. Если коммуникация обещает одно, а продукт ведёт себя иначе, для клиента ошиблась компания.
Организация при этом может состоять из отдельных команд, каждая из которых формально сделала всё правильно. Именно поэтому один из самых важных вопросов сложного проекта звучит очень просто:
кто отвечает за результат, который существует между функциями?
Обычно на этот вопрос нет очевидного ответа. Project manager отвечает за движение проекта. Product owner — за продукт. Руководители функций — за свои направления. CEO — за компанию в целом. Но кто проектирует саму систему зависимостей между этими уровнями? Здесь и возникает пространство Strategic Project Architecture.
Сильные специалисты сами по себе систему не создают
В Converse Mobile это проявлялось постоянно. Возьмём информационную безопасность. Любое серьёзное security-решение имеет техническую сторону. Но в мобильном банке оно почти неизбежно влияет и на клиента. Изменилось правило безопасности — значит, может измениться сценарий входа. Изменился сценарий входа — значит, потребуется новое объяснение. Новое объяснение затрагивает интерфейс, тексты, Customer Service и иногда маркетинговую коммуникацию.
Технически правильное решение должно пройти через несколько профессиональных языков прежде, чем превратиться в нормальный клиентский опыт. То же самое происходило с UX. Можно провести качественное исследование пользователей. Можно получить сильный дизайн. Можно создать прекрасные прототипы. Но между исследованием и работающим продуктом находится длинная цепочка решений.
Что именно из исследования становится продуктовым приоритетом? Что требует изменения бизнес-логики? Что возможно реализовать технологически? Что должно войти в текущий цикл разработки? Как новое решение повлияет на существующие сценарии? Как его объяснить пользователю? Исследование само по себе не меняет продукт. Дизайн сам по себе тоже. Ценность появляется тогда, когда разные дисциплины связываются в один последовательный процесс принятия решений.
Сложные проекты редко разваливаются из-за отсутствия профессионалов. Чаще они теряют скорость и качество в момент передачи решений от одного профессионального мира другому.
Архитектурный разрыв
Со временем я начал использовать для таких ситуаций понятие архитектурного разрыва. Это момент, когда необходимые элементы проекта существуют, но механизм их соединения недостаточно определён. Есть стратегия. Есть команды. Есть бюджет. Есть roadmap. Есть ответственность внутри подразделений. Но остаются вопросы, которые буквально проваливаются между ними.
Кто принимает решение, если бизнес и технология предлагают два одинаково обоснованных варианта? Кто определяет последовательность действий, если работа одной команды зависит от решения другой? В какой момент маркетинг должен получить информацию о будущем релизе? Как клиентская обратная связь превращается в продуктовый приоритет?
Кто замечает, что локально эффективное решение одного подразделения создаёт проблему для всей системы? Это и есть архитектурные вопросы. И решать их очередной встречей обычно бесполезно. Проблема редко состоит в том, что люди мало общаются. Иногда они общаются даже слишком много.
Проблема в отсутствии конструкции, которая объясняет, какие решения должны приниматься совместно, где находится ownership и как зависимые решения превращаются в одно движение проекта.
Почему project management здесь недостаточно
У хорошего project management есть огромная ценность. Он помогает следить за сроками, задачами, ресурсами, зависимостями и исполнением. Но существует уровень, который появляется раньше списка задач. Представим ситуацию.
Business хочет вывести новый продукт. Technology видит архитектурное ограничение. UX понимает, что исходный сценарий будет неудобным. Marketing уже строит вокруг продукта коммуникацию.
Management ожидает от запуска конкретный коммерческий эффект. Что именно в этой ситуации нужно поставить в task tracker? Сначала нужно определить саму конструкцию решения. Возможно, изменить продукт.
Возможно, последовательность разработки. Возможно, предложение. Возможно, ожидания по срокам. Возможно, сам способ измерения результата.
Только после этого проект снова становится набором управляемых задач. Именно здесь я провожу для себя важное различие.
Project management организует исполнение конструкции. Strategic Project Architecture помогает эту конструкцию создать.
Что делает Strategic Project Architect
Я использую этот термин как описание работы, а не как новую эффектную должность. Первое, что делает Strategic Project Architect, — расширяет объект управления до его реального размера. Если компания говорит: «мы делаем новое приложение», реальный проект может включать продуктовую модель, процессы, технологии, customer experience, маркетинг, поддержку, данные и изменение поведения сотрудников. Если управлять только приложением, большая часть проекта останется за пределами общей конструкции.
Вторая задача — увидеть зависимости раньше, чем они превратятся в проблему. Какое решение открывает возможность следующего? Что нельзя делать параллельно? Какие функции должны договориться до начала реализации? Где изменение одной части системы автоматически меняет другую? Третья — создать архитектуру решений. В сложных проектах мало определить, кто что делает.
Гораздо важнее определить, кто с кем принимает решения, на каком уровне и по каким вопросам. Четвёртая — создать общие рабочие артефакты. Это может быть blueprint, roadmap, decision register, matrix, единая design system или иной инструмент. Название вторично. Хороший артефакт выполняет одну функцию: несколько профессиональных команд начинают работать с одной версией реальности.
И пятая задача, возможно самая сложная, — защищать общий результат от локальной эффективности. Потому что практически любое подразделение способно доказать, что действует рационально внутри своей системы координат. Но проекту от этого не обязательно становится лучше.
CFT не была способом проводить больше совещаний
Смысл cross-functional team в Converse Mobile для меня заключался именно в этом. Мы не пытались заменить профессиональные функции общей командой. Их экспертиза оставалась на месте. Менялась система связей.
Retail приносил бизнес-логику и понимание продукта. Mobile development — технологическую возможность и ограничения. Marketing — клиента, предложение и коммуникацию. Другие функции подключались там, где решение требовало их компетенции. Появился контур, в котором противоречия можно было увидеть раньше и обсуждать как часть одного продукта. Позднее в эту же систему всё глубже начали входить исследования, UX, клиентская обратная связь, дизайн и новые продуктовые решения. Самым важным результатом этой модели я считаю даже не конкретные релизы.
Гораздо важнее другое. Мобильный банк начал существовать внутри организации как единый продукт, а не как совокупность задач нескольких подразделений. Это фундаментальное изменение.
Когда каждый прав — проект особенно уязвим
Есть проекты, проблемы которых очевидны. Не хватает ресурсов. Ошиблась команда. Не работает технология. Непонятна стратегия. Такие ситуации неприятны, но диагностировать их относительно легко. Намного сложнее проект, в котором каждый по-своему прав.
IT обоснованно защищает архитектуру. Business обоснованно требует коммерческий результат. Marketing обоснованно думает о клиенте и рынке. InfoSec обоснованно ограничивает риск.
UX обоснованно требует удобства. Управленческая задача начинается там, где все эти профессионально правильные позиции должны превратиться в одно решение. Именно поэтому сегодня, когда я вхожу в сложный проект, меня в первую очередь интересует не список задач. Я смотрю на связи.
Где находится ownership результата? Какие решения пересекают границы нескольких функций? Где разные команды используют разные определения одной проблемы? Какие зависимости никто не держит целиком?
В какой точке профессионально правильное решение одной команды может ухудшить общий результат? Очень часто настоящая проблема проекта находится именно там.
Архитектура результата
За последние годы мой взгляд на сложные проекты сильно изменился. Я всё меньше вижу их как последовательность задач и всё больше — как систему взаимозависимых решений. Стратегия определяет продукт. Продукт меняет технологию. Технология формирует клиентский опыт. Клиентский опыт влияет на коммуникацию и продажи. Реальное поведение клиента возвращается в продукт и снова меняет стратегические решения. Эта система живёт сразу в нескольких профессиональных мирах.
Поэтому человеку, который отвечает за её целостность, вовсе не нужно быть лучшим программистом, лучшим маркетологом или лучшим продуктовым экспертом в комнате. Его задача другая. Он должен понимать достаточно много о каждой из дисциплин, чтобы видеть пространство между ними. И вовремя замечать момент, когда проект перестаёт быть набором профессиональных решений и нуждается в архитектуре, которая соберёт их в один результат.
Для меня именно это означает Strategic Project Architect.
Сила сложного проекта определяется не только качеством его частей. Она определяется тем, насколько хорошо эти части умеют работать как одна система.
Сегодня компаниям всё чаще приходится собирать такие системы из очень разных источников. Сильную IT-команду можно привлечь с рынка. UX/UI — отдать специализированному агентству. Внутри компании уже есть Retail, Marketing, Finance, Compliance, Operations. У инвестора или собственника есть идея, амбиция, бюджет и срок. Проблема начинается в тот момент, когда все эти сильные участники должны превратиться в один проект. Кто соединит бизнес-видение с технологической архитектурой? Кто проследит, чтобы продукт, клиентский опыт, операционная модель и коммуникация развивались синхронно? Кто увидит противоречие между двумя профессионально правильными решениями до того, как оно станет дорогой переделкой? Кто будет держать в поле зрения не отдельные workstreams, а весь результат — от первоначального замысла до момента, когда решение действительно начинает работать для людей?
Строить все необходимые компетенции внутри одной компании ради каждого большого проекта часто слишком долго и слишком дорого. Современный рынок уже давно научился покупать лучшую специализированную экспертизу снаружи. Но чем больше таких экспертиз соединяется в одном проекте, тем выше становится цена их оркестровки. Именно из этого понимания я основал USPACE. USPACE работает с собственниками, инвесторами и руководителями компаний, которые запускают сложные интегрированные проекты и хотят пройти путь от амбиции до работающего результата, сохранив управляемость сроков, инвестиций и решений. Мы можем работать рядом с внутренними командами компании, технологическими партнёрами, агентствами, консультантами и другими внешними экспертами. Наша задача — собрать из этих сильных элементов одну работающую архитектуру проекта и удерживать её целостность по мере того, как проект становится сложнее.
Потому что в конечном счёте значение имеют не количество вовлечённых команд, не объём созданных документов и даже не факт запуска. Значение имеет другое. Реализовано ли то видение, ради которого проект вообще начинался. Уложился ли он в разумные сроки и инвестиционную логику. И главное — получили ли в итоге люди, внешние клиенты или сотрудники, решение, которым они действительно пользуются. Когда это произошло, проект закончен.
А до этого момента архитектура результата всё ещё требует управления.
