[Управление проектами, Управление продуктом] Архитектура Пизанской башни
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Всем привет. Находясь на «удаленке» дома, сложно не вспоминать о прошлых путешествиях и не уйти в философию. Своими размышлениями делюсь в преддверии курса «Agile Project Manager», в создании которого участвовал.
Конец сентября, Пиза, 7 лет назад. Экскурсовод-итальянец перед восхождением на Пизанскую башню с гордостью рассказывает туристам краткую предысторию: башня возводилась в несколько этапов, была завершена почти через 200 лет после начала строительства, и уже на первом этапе был обнаружен крен из-за слишком мягких грунтов под фундаментом… С этого момента начинаю слушать внимательней: оказывается, архитекторы башни не решились отдать голову на отсечение и отказаться от дальнейшего возведения, зато последовательно работали над балансировкой сооружения десятилетиями. Благодаря этому, а также определенным усилиям наших современников, мы имеем возможность не только лицезреть, но и посещать поистине выдающийся архитектурный памятник.
Меня впечатляют сроки проектов того уже сравнительно просвещенного времени. Однако в нынешнем бизнес-мире мало кому захочется повторить такой подвиг – строить веками – ни современники, ни тем более потомки его не оценят. Но можно заметить, сохраняя аналогию со строительством и на порядки ускорив время, что зачастую разработка архитектуры нынешних организаций напоминает балансировку строящейся и одновременно падающей башни. При этом дуют сильные ветра, регулярно происходят землетрясения, а жильцы уже въехали и активно занимаются перепланировкой. Было бы здорово сделать башню лёгкой и упругой, чтобы она не ломалась, а невзначай упав, возвращалась назад, как неваляшка. Но чем выше мы поднимаемся, тем быстрее мы строим, чем больше внимания уделяем верхушке и красивой отделке, тем тяжелее она становится и грозит обрушить всю башню даже при небольшом наклоне.
Аналогично, последние годы современное профессиональное сообщество прилагает максимум усилий, убеждая окружающих и самих себя, в непрерывности рождения нового. Не спорю, технологии эволюционируют, а светлые головы рождают инновационные идеи. Но желающих приобщиться (заработать) намного больше: вспомним, как несколько лет подряд партнеры международных консалтинговых компаний в дорогих костюмах перемещались из кабинета в кабинет с предложением «юберизовать ваш бизнес», ориентируясь на уважаемого за технологичность, но убыточного агрегатора, по сути, без материальных активов. За ними следующими шли энергичные ребята в футболках, обещая сначала реализовать «любой каприз» на блокчейн, потом сократить половину сотрудников благодаря ИИ, и так до бесконечности. Приглядевшись можно заметить, что «старые» бизнес-модели в большинстве своём никуда не исчезают, а скорее переизобретаются и скрываются под новой терминологией. Из широко известных, действительно, выглядит актуальной «платформенная модель», которая тоже в общем-то не на пустом месте появилась. Она требует значительных инвестиций, зато при успешном воплощении, даёт прирост эффективности и потенциал по доле рынка.
Чаще всё сводится к улучшению упаковки (ой, извините — клиентского опыта), чтобы ручеек потребительского спроса менял своё русло в желаемую сторону. Это суррогат. В реальности, если я захочу индивидуальный клиентский опыт, мне придётся стать очень богатым. А если я, допустим, попрошу встроить в мой автомобиль простенький автопилот не по цене нового авто, а по цене хорошего гаджета, то не выйдет без замены платформы, – не предусмотрено и всё тут. С одной стороны, нас подталкивают к смене автомобилей с той же регулярностью, что и смартфонов, но этот вопрос больше про социум и экологию. С другой стороны, как только мы касаемся архитектуры, легко поменять «на лету» уже не получается. К примеру, стратегические цели компании обновляются регулярно, и намного чаще, чем архитектурные принципы, призванные обеспечивать выполнение долгосрочной стратегии (при условии её наличия).
Поделится ли кто-нибудь успешным опытом внедрения нового бизнес-процесса сразу на десятки тысяч клиентов и сотни сотрудников, в режиме двухнедельных спринтов? Кто-то скажет, легко – это по agile. Но я не про разработку интерфейсов, не про добавление бизнес-правил, не про A/B-тестирование, а непосредственно про «релиз процесса» с нуля – и мы обнаруживаем, что платформу сложно создать по Scrum, но последнему надо обеспечить нормальное функционирование в прикладных сферах. Платформа не состоит из одних пользовательских историй примерно также, как успех онлайн ритейла не так сильно зависит от веб-сайта. Параллельно представим пример из другой сферы: на сколько сильно обрадуются CEO или CFO рекомендациям списать «лишнее» оборудование и арендовать место в новом дата-центре с созданием гибридного облака. Почему вы не подумали об этом раньше, обязательно спросят они с серьезным видом. В итоге, конечно, нужна инфраструктура-по-запросу, но затраты на такой сервис будут зависеть от нашей предусмотрительности.
Суммирую размышления: целью корпоративного архитектора, совместно с другими лидерами трансформации, является долгосрочное обеспечение необходимой и предсказуемой гибкости для детального проектирования и последующих «непрерывных улучшений» на фоне обеспечения устойчивости «конструкции в целом». Данная парадигма не претерпела существенных изменений за десятилетия, только мотивация выражалась другими словами и потребность в гибкости не всегда была столь очевидна. Поэтому модный термин «agile-архитектура» звучит курьёзно, а вот архитектура гибкой организации – вполне уместно.
Сейчас нам открыты реальные способы сделать организацию в целом более гибкой – и это важнее и сложнее, чем поддержать гибкость технически и организовать соответствующий цикл разработки, благодаря микросервисам, контейнерам, непрерывной сборке и т.д. Как минимум, лидерам программ трансформации и портфелей проектов нужно принять тот факт, что внутри исполнения их планов команды будут применять гибкие методологии, и надо суметь оставить для них достаточно пространства. Но больших успехов можно добиться, кардинально пересмотрев организационно-функциональную структуру компании и модель управления. При этом, гибкость должна находиться в очерченных допустимых границах, определяемых стратегией инвестиций, целями портфелей и дорожными картами программ. Тогда маловероятно, что здание бизнеса компании внезапно начнёт валиться, и его придется много месяцев подправлять и балансировать. Определение правильного сочетания гибкости и устойчивости – вполне решаемая задача.
оригинал
===========
Источник:
habr.com
===========
Похожие новости:
- [C++, Программирование] Антипаттерн “константа размера массива” (перевод)
- [Карьера в IT-индустрии, Развитие стартапа, Управление продуктом, Управление разработкой] Дорожная карта развития продукта: Курс Создание программного продукта и управление его развитием
- [JavaScript, ReactJS, VueJS] Микросервисы во фронтенде
- [Урбанизм] Жизнь под давлением: как устроены водонапорные башни
- [JavaScript, Node.JS, Разработка веб-сайтов] Компоновщик в JavaScript (перевод)
- [Управление продуктом] Как понять, что новая фича принесет пользу продукту, а не навредит ему?
- [Usability, Управление проектами] Золотое кольцо скучнейших экскурсий: как это пытаются исправить
- [Microsoft SQL Server, SQL, Администрирование баз данных] Введение в графовые базы данных SQL Server 2017 (перевод)
- [Управление проектами, ERP-системы, CRM-системы, Управление разработкой, Финансы в IT] ERP-система: управление показателями на стыке коммерции и IT
- [Agile, Интервью, Управление персоналом, Управление проектами] Однодневный спринт — реальность или вымысел?
Теги для поиска: #_upravlenie_proektami (Управление проектами), #_upravlenie_produktom (Управление продуктом), #_agile, #_arhitektura (архитектура), #_upravlenie (управление), #_korporativnaja_kultura (корпоративная культура), #_blog_kompanii_otus._onlajnobrazovanie (
Блог компании OTUS. Онлайн-образование
), #_upravlenie_proektami (
Управление проектами
), #_upravlenie_produktom (
Управление продуктом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 00:11
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Всем привет. Находясь на «удаленке» дома, сложно не вспоминать о прошлых путешествиях и не уйти в философию. Своими размышлениями делюсь в преддверии курса «Agile Project Manager», в создании которого участвовал.  Конец сентября, Пиза, 7 лет назад. Экскурсовод-итальянец перед восхождением на Пизанскую башню с гордостью рассказывает туристам краткую предысторию: башня возводилась в несколько этапов, была завершена почти через 200 лет после начала строительства, и уже на первом этапе был обнаружен крен из-за слишком мягких грунтов под фундаментом… С этого момента начинаю слушать внимательней: оказывается, архитекторы башни не решились отдать голову на отсечение и отказаться от дальнейшего возведения, зато последовательно работали над балансировкой сооружения десятилетиями. Благодаря этому, а также определенным усилиям наших современников, мы имеем возможность не только лицезреть, но и посещать поистине выдающийся архитектурный памятник. Меня впечатляют сроки проектов того уже сравнительно просвещенного времени. Однако в нынешнем бизнес-мире мало кому захочется повторить такой подвиг – строить веками – ни современники, ни тем более потомки его не оценят. Но можно заметить, сохраняя аналогию со строительством и на порядки ускорив время, что зачастую разработка архитектуры нынешних организаций напоминает балансировку строящейся и одновременно падающей башни. При этом дуют сильные ветра, регулярно происходят землетрясения, а жильцы уже въехали и активно занимаются перепланировкой. Было бы здорово сделать башню лёгкой и упругой, чтобы она не ломалась, а невзначай упав, возвращалась назад, как неваляшка. Но чем выше мы поднимаемся, тем быстрее мы строим, чем больше внимания уделяем верхушке и красивой отделке, тем тяжелее она становится и грозит обрушить всю башню даже при небольшом наклоне. Аналогично, последние годы современное профессиональное сообщество прилагает максимум усилий, убеждая окружающих и самих себя, в непрерывности рождения нового. Не спорю, технологии эволюционируют, а светлые головы рождают инновационные идеи. Но желающих приобщиться (заработать) намного больше: вспомним, как несколько лет подряд партнеры международных консалтинговых компаний в дорогих костюмах перемещались из кабинета в кабинет с предложением «юберизовать ваш бизнес», ориентируясь на уважаемого за технологичность, но убыточного агрегатора, по сути, без материальных активов. За ними следующими шли энергичные ребята в футболках, обещая сначала реализовать «любой каприз» на блокчейн, потом сократить половину сотрудников благодаря ИИ, и так до бесконечности. Приглядевшись можно заметить, что «старые» бизнес-модели в большинстве своём никуда не исчезают, а скорее переизобретаются и скрываются под новой терминологией. Из широко известных, действительно, выглядит актуальной «платформенная модель», которая тоже в общем-то не на пустом месте появилась. Она требует значительных инвестиций, зато при успешном воплощении, даёт прирост эффективности и потенциал по доле рынка. Чаще всё сводится к улучшению упаковки (ой, извините — клиентского опыта), чтобы ручеек потребительского спроса менял своё русло в желаемую сторону. Это суррогат. В реальности, если я захочу индивидуальный клиентский опыт, мне придётся стать очень богатым. А если я, допустим, попрошу встроить в мой автомобиль простенький автопилот не по цене нового авто, а по цене хорошего гаджета, то не выйдет без замены платформы, – не предусмотрено и всё тут. С одной стороны, нас подталкивают к смене автомобилей с той же регулярностью, что и смартфонов, но этот вопрос больше про социум и экологию. С другой стороны, как только мы касаемся архитектуры, легко поменять «на лету» уже не получается. К примеру, стратегические цели компании обновляются регулярно, и намного чаще, чем архитектурные принципы, призванные обеспечивать выполнение долгосрочной стратегии (при условии её наличия). Поделится ли кто-нибудь успешным опытом внедрения нового бизнес-процесса сразу на десятки тысяч клиентов и сотни сотрудников, в режиме двухнедельных спринтов? Кто-то скажет, легко – это по agile. Но я не про разработку интерфейсов, не про добавление бизнес-правил, не про A/B-тестирование, а непосредственно про «релиз процесса» с нуля – и мы обнаруживаем, что платформу сложно создать по Scrum, но последнему надо обеспечить нормальное функционирование в прикладных сферах. Платформа не состоит из одних пользовательских историй примерно также, как успех онлайн ритейла не так сильно зависит от веб-сайта. Параллельно представим пример из другой сферы: на сколько сильно обрадуются CEO или CFO рекомендациям списать «лишнее» оборудование и арендовать место в новом дата-центре с созданием гибридного облака. Почему вы не подумали об этом раньше, обязательно спросят они с серьезным видом. В итоге, конечно, нужна инфраструктура-по-запросу, но затраты на такой сервис будут зависеть от нашей предусмотрительности. Суммирую размышления: целью корпоративного архитектора, совместно с другими лидерами трансформации, является долгосрочное обеспечение необходимой и предсказуемой гибкости для детального проектирования и последующих «непрерывных улучшений» на фоне обеспечения устойчивости «конструкции в целом». Данная парадигма не претерпела существенных изменений за десятилетия, только мотивация выражалась другими словами и потребность в гибкости не всегда была столь очевидна. Поэтому модный термин «agile-архитектура» звучит курьёзно, а вот архитектура гибкой организации – вполне уместно. Сейчас нам открыты реальные способы сделать организацию в целом более гибкой – и это важнее и сложнее, чем поддержать гибкость технически и организовать соответствующий цикл разработки, благодаря микросервисам, контейнерам, непрерывной сборке и т.д. Как минимум, лидерам программ трансформации и портфелей проектов нужно принять тот факт, что внутри исполнения их планов команды будут применять гибкие методологии, и надо суметь оставить для них достаточно пространства. Но больших успехов можно добиться, кардинально пересмотрев организационно-функциональную структуру компании и модель управления. При этом, гибкость должна находиться в очерченных допустимых границах, определяемых стратегией инвестиций, целями портфелей и дорожными картами программ. Тогда маловероятно, что здание бизнеса компании внезапно начнёт валиться, и его придется много месяцев подправлять и балансировать. Определение правильного сочетания гибкости и устойчивости – вполне решаемая задача.  оригинал =========== Источник: habr.com =========== Похожие новости:
Блог компании OTUS. Онлайн-образование ), #_upravlenie_proektami ( Управление проектами ), #_upravlenie_produktom ( Управление продуктом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 00:11
Часовой пояс: UTC + 5