При подобном развитии событий крайне сложно избежать и ментальных ловушек, перечисленных выше. При отсутствии общего продуктового видения корректные адаптация и применение гибких практик становятся невозможными, так как отсутствует продукт, на реализацию которого и направлены сами гибкие практики. Наиболее частым случаем, встречающимся на практике при применении такого подхода, является бесконечный «Waterfall со стендапами», в который погружаются разрозненные команды, отвечающие за автоматизацию конкретных уровней рассмотрения продукта (в нашем примере их представлено четыре, но может быть и существенно больше при мелкой грануляции технологий автоматизации, применяемых в организации). При этом можно клеить на доску сколько угодно стикеров с описанием решаемых задач, синхронизировать бэклоги команд на соответствующих статусах, использовать современные инструментальные средства поддержки гибких практик, но не будет главного – согласованной работы над продуктом. Для упрощения производственной деятельности, пытаясь ускорить разработку тяжеловесных платформ, будут применяться новые и новые шаблоны проектирования, не ведущие к созданию ценности, но с какого-то момента существующие сами по себе. Ну и выход на «плато стабильности» эффекта Даннинга – Крюгера для подобным образом собранного сообщества также будет затруднен. Некая команда (например, реализующая фронтальное представление продукта при помощи «омниканальной платформы») будет продолжать находиться на «пике тупости», основываясь на относительно невысокой скорости реализации требуемого продуктового функционала другой командой, обладающей априори меньшей емкостью в терминах гибких практик (в качестве примера можно привести команду, отвечающую за ведение частного аналитического продуктового учета), которая, погрязнув в задачах и техническом долге, окажется зажатой в «обрыве сознания».

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

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

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