Русский
Русский
English
Статистика
Реклама

Архитектура Пизанской башни

Всем привет. Находясь на удаленке дома, сложно не вспоминать о прошлых путешествиях и не уйти в философию. Своими размышлениями делюсь в преддверии курса Agile Project Manager, в создании которого участвовал.





Конец сентября, Пиза, 7 лет назад. Экскурсовод-итальянец перед восхождением на Пизанскую башню с гордостью рассказывает туристам краткую предысторию: башня возводилась в несколько этапов, была завершена почти через 200 лет после начала строительства, и уже на первом этапе был обнаружен крен из-за слишком мягких грунтов под фундаментом С этого момента начинаю слушать внимательней: оказывается, архитекторы башни не решились отдать голову на отсечение и отказаться от дальнейшего возведения, зато последовательно работали над балансировкой сооружения десятилетиями. Благодаря этому, а также определенным усилиям наших современников, мы имеем возможность не только лицезреть, но и посещать поистине выдающийся архитектурный памятник.

Меня впечатляют сроки проектов того уже сравнительно просвещенного времени. Однако в нынешнем бизнес-мире мало кому захочется повторить такой подвиг строить веками ни современники, ни тем более потомки его не оценят. Но можно заметить, сохраняя аналогию со строительством и на порядки ускорив время, что зачастую разработка архитектуры нынешних организаций напоминает балансировку строящейся и одновременно падающей башни. При этом дуют сильные ветра, регулярно происходят землетрясения, а жильцы уже въехали и активно занимаются перепланировкой. Было бы здорово сделать башню лёгкой и упругой, чтобы она не ломалась, а невзначай упав, возвращалась назад, как неваляшка. Но чем выше мы поднимаемся, тем быстрее мы строим, чем больше внимания уделяем верхушке и красивой отделке, тем тяжелее она становится и грозит обрушить всю башню даже при небольшом наклоне.

Аналогично, последние годы современное профессиональное сообщество прилагает максимум усилий, убеждая окружающих и самих себя, в непрерывности рождения нового. Не спорю, технологии эволюционируют, а светлые головы рождают инновационные идеи. Но желающих приобщиться (заработать) намного больше: вспомним, как несколько лет подряд партнеры международных консалтинговых компаний в дорогих костюмах перемещались из кабинета в кабинет с предложением юберизовать ваш бизнес, ориентируясь на уважаемого за технологичность, но убыточного агрегатора, по сути, без материальных активов. За ними следующими шли энергичные ребята в футболках, обещая сначала реализовать любой каприз на блокчейн, потом сократить половину сотрудников благодаря ИИ, и так до бесконечности. Приглядевшись можно заметить, что старые бизнес-модели в большинстве своём никуда не исчезают, а скорее переизобретаются и скрываются под новой терминологией. Из широко известных, действительно, выглядит актуальной платформенная модель, которая тоже в общем-то не на пустом месте появилась. Она требует значительных инвестиций, зато при успешном воплощении, даёт прирост эффективности и потенциал по доле рынка.

Чаще всё сводится к улучшению упаковки (ой, извините клиентского опыта), чтобы ручеек потребительского спроса менял своё русло в желаемую сторону. Это суррогат. В реальности, если я захочу индивидуальный клиентский опыт, мне придётся стать очень богатым. А если я, допустим, попрошу встроить в мой автомобиль простенький автопилот не по цене нового авто, а по цене хорошего гаджета, то не выйдет без замены платформы, не предусмотрено и всё тут. С одной стороны, нас подталкивают к смене автомобилей с той же регулярностью, что и смартфонов, но этот вопрос больше про социум и экологию. С другой стороны, как только мы касаемся архитектуры, легко поменять на лету уже не получается. К примеру, стратегические цели компании обновляются регулярно, и намного чаще, чем архитектурные принципы, призванные обеспечивать выполнение долгосрочной стратегии (при условии её наличия).

Поделится ли кто-нибудь успешным опытом внедрения нового бизнес-процесса сразу на десятки тысяч клиентов и сотни сотрудников, в режиме двухнедельных спринтов? Кто-то скажет, легко это по agile. Но я не про разработку интерфейсов, не про добавление бизнес-правил, не про A/B-тестирование, а непосредственно про релиз процесса с нуля и мы обнаруживаем, что платформу сложно создать по Scrum, но последнему надо обеспечить нормальное функционирование в прикладных сферах. Платформа не состоит из одних пользовательских историй примерно также, как успех онлайн ритейла не так сильно зависит от веб-сайта. Параллельно представим пример из другой сферы: на сколько сильно обрадуются CEO или CFO рекомендациям списать лишнее оборудование и арендовать место в новом дата-центре с созданием гибридного облака. Почему вы не подумали об этом раньше, обязательно спросят они с серьезным видом. В итоге, конечно, нужна инфраструктура-по-запросу, но затраты на такой сервис будут зависеть от нашей предусмотрительности.

Суммирую размышления: целью корпоративного архитектора, совместно с другими лидерами трансформации, является долгосрочное обеспечение необходимой и предсказуемой гибкости для детального проектирования и последующих непрерывных улучшений на фоне обеспечения устойчивости конструкции в целом. Данная парадигма не претерпела существенных изменений за десятилетия, только мотивация выражалась другими словами и потребность в гибкости не всегда была столь очевидна. Поэтому модный термин agile-архитектура звучит курьёзно, а вот архитектура гибкой организации вполне уместно.

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


Читать ещё:


Источник: habr.com
К списку статей
Опубликовано: 11.09.2020 20:19:02
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Блог компании otus. онлайн-образование

Управление продуктом

Управление проектами

Agile

Архитектура

Управление

Корпоративная культура

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru