Андрей Николаевич Трушкин

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


Скачать книгу

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

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

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

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