Comments 7
На картинке не тот замок, в котором после завершения строительства пришлось лестницу для короля спешно достраивать, чтобы он мог покидать покои без проблем?
Судя по Wikipedia нет, ваш пример как раз характеризует об архитектурных проблемах проекта, которые возможно имели место быть и при строительстве этого замка. Шамбор мне всегда казался несколько сумасшедшим, но красивым. Этаким строительным воплощением проекта, с кучей костылей, которые к сожалению не выглядят столь прекрасно как этот замок.
Если я не ошибаюсь — она слева на фото — справа от левой башни, это как я понимаю как раз правое крыло, покои короля. Из-за этого замок несимметричен.
В проекте не был предусмотрен выход для короля минуя толпу лизоблюдов, а отдохнуть от них хотелось
В сожалению поиском не нашел — все забивает лестница Леонардо
А замок красив, не отнять
В проекте не был предусмотрен выход для короля минуя толпу лизоблюдов, а отдохнуть от них хотелось
В сожалению поиском не нашел — все забивает лестница Леонардо
А замок красив, не отнять
Для любого архитектора важна глубина и широта технических знаний и опыта, это гораздо, гораздо важнее навыков коммуникации и рисования бесполезных картинок. Помните, заказчикам и пиэму пофигу реббит у вас там или кафка, а вот когда ваше решение начнет просирать данные — им совсем не пофиг. И оставьте уже коммуникации аналитикам, они в том числе и для вас требования собирают-согласуют, лучше теснее коммуницируйте с владельцами продуктов и пиэмами, ведь лучше семь раз вовремя, чем один раз хорошо и с блестящей архитектурой. У меня всё.
я частично не соглашусь, конечно в первую очередь должна быть ответственность за то, чтобы все работало, в смысле выбранные технологии обеспечивали выполнение поставленных задач, но коммуникации тоже очень важны. При этом коммуницировать может не сам архитектор на всех уровнях, он может это частично отдать аналитику или developer advocate, но сам процесс должен быть. Может быть я немного идеализирую, но я считаю, что часто как раз из-за плохо проведенной коммуникации проект не взлетает. Решение не только должно быть принято, но и донесено до всех участвующих почему именно такое решение принято. Например, если разработчики против или не понимают почему тут должна быть вот такая технология — важно проработать этот момент — показать чем руководствовались, какие альтернативы рассматривали. ИТ — область высокоинтеллектуальных сотрудников, и с ними не получится работать как на стройке — инженер сказал как делать, а вы молчите и делайте. На мой взгляд вот такое «спускание решений сверху» и не приятие и не понимание их командой часто причина того, что внутренее сопротивление очень сильно замедляет реализацию проекта.
Sign up to leave a comment.
Круглый стол «Архитектор ИТ проекта», сентябрь 2018