Архитектура цифровых платформ. От настоящего к будущему - страница 7

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

– Ключевым элементом mindset является фокус на продукте, представляющем ценность для партнеров и клиентов организации, его создающей. Далеко не всегда определить продукт оказывается простой задачей, во многом корректное формирование продуктового видения конкретной организации требует серьезного изменения мышления и позиционирования себя на рынке, частным случаем которого является уход от продуктологов к владельцам продуктов.

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

• Современный архитектурный mindset должен успешно обходить ментальные ловушки, связанные с гибкими практиками, информационной безопасностью, шаблонами проектирования, эффектом Даннинга – Крюгера (подробно рассмотрены в «Архитектуре цифрового мира»). И платформы также должны успешно противостоять той ментальной лености, которая тянет нас в указанные ловушки.

Возвращаясь к представленному выше примеру платформенного подхода, основанного на множестве «платформ», можно отметить, что он полностью игнорирует современный mindset. Фактически в нем отсутствует видение продукта – нет общей продуктовой концепции (а во многих случаях она окончательно «добита» наличием платформенных команд). Создание и развитие продукта, отвечающие требованиям современного цифрового мира, при таком подходе невозможны ввиду необходимости синхронизации рабочего процесса огромного количества специалистов разных направлений деятельности. В особо запущенных случаях деградации организации понятие продукта сводится к его визуальному или процессному представлению. В таком ракурсе невозможно обеспечить перманентное интенсивное развитие, так как векторы «развития» каждой применяемой «платформы» оказываются строго разнонаправленными, результат же получается аналогичным басне И. А. Крылова «Лебедь, щука и рак». Ведь самостоятельное развитие каждой «платформы» может затормозить общее продуктовое развитие, останов же платформенного развития приведет к бесконечному наращиванию продуктового функционала на стремительно устаревающей технологической базе.

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