Архитектор это проектировщик – коротко о профессии, зарплата специалиста. Чем занимается архитектор инженерных систем? Какие предметы нужно сдавать для обучения?

ᐅ Чем отличается архитектор от проектировщика?

Архитектор и проектировщик лишь для непосвященных могут казаться специалистами одной сферы. Но это вовсе не так. Чем отличается архитектор от проектировщика? Давайте узнаем!

В строительстве много профессий, которые на первый взгляд должны заниматься одним и тем же.

Разобраться, что входит в обязанности архитектора и проектировщика нелегко, но это две абсолютно разные профессии. Проектировщик от архитектора отличается и кругом задач, и сферой работы.

В строительных и технических университетах много факультетов и специализаций, и выбрать абитуриентам, на какой из них поступать достаточно сложно. Почти все эти профессии направлены на создание и строительство безопасных и красивых объектов.

И, тем не менее, каждая из них имеет свои особенности, свой круг обязанностей, ответственность. Прежде чем поступать на какой-либо факультет, желательно ознакомиться, чем придётся заниматься, какие перспективы, зарплаты и возможность продвижения.

Чем же отличается архитектор от проектировщика?

Чтобы ответить на этот вопрос, надо рассмотреть, чем занимается архитектор и инженер-проектировщик. Если говорить просто, архитектор от проектировщика отличается тем, что первый придумывает облик здания, эстетичный вид, вписывает в определённый стиль и изображает всё это на бумаге. А инженер-проектировщик разрабатывает проект от чертежа до подготовки технического задания, от котлована до коммуникаций.

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

Чем еще отличается архитектор от проектировщика?

Если рассматривать, чем архитектор отличается от проектировщика подробнее, то начинать надо с момента требований при поступлении. Архитектор должен иметь художественный вкус, хорошо рисовать, уметь создавать макеты и конструировать в системе 3D.

В этой профессии необходим не только математический, но и творческий талант, своё видение, креативность, абстрактное мышление, чтобы создавать неповторимые проекты.

Архитектор отличается от проектировщика тем, что должен уметь работать с цветовыми решениями, разбираться в материалах и использовать их в выгодном ключе, продумывать облик здания, планировать коробку, стены, кровлю, пол, отделку. Это всё должно быть подробно описано, нарисовано, просчитано. И только потом этот проект передаётся следующим отделам, которые будут проводить свои расчёты и после утверждения  начинать его осуществлять.

Получается, что эта профессия более творческая и, возможно, кому-то покажется, что более перспективная. Но это лишь вопрос выбора.

При этом, проектировщик от архитектора отличается тем, что может быть востребован в разных отраслях, не обязательно это будет строительство. Но если сравнивать обязанности с архитектором, то и обязанности проектировщика надо рассматривать в строительстве.

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

У архитектора клиентом является инвестор или заказчик, который желает получить разработку нужного проекта. А у инженера-проектировщика клиентом является архитектор, который предлагает рассчитать подготовленный им проект здания.

При продвижении в должности, архитектор может стать главным архитектором проекта. Но это не всем удаётся. Архитектор может работать в проектных организациях, в управлении архитектуры города или района и градостроительстве.

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

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

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

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

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

Быть может, сходу не так и очевидно, чем архитектор отличается от проектировщика и часто может показаться, что первый имеет больше возможностей и перспектив. Но это два разных вида деятельности и оценить, какая из них лучше невозможно. Каждый должен выбирать то, что ему нравится больше.

При этом, чем инженер не отличается от проектировщика точно – так это возможностью реализовать себя в работе. Главное же в том, что каждый претендент должен оценить свои силы, таланты и знания. И тогда любая профессия принесёт радость творчества и материальный достаток.

Профессия Архитектор

Специалист, занимающийся проектированием зданий, а также разработкой планировки и интерьера помещения.

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

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

Области знания: черчение, физика, математика, геология, ИТ, химия, геодезия

Компетенции

• Организация городской среды и проектирование объектов строительства
• Разработка концепции развития местности
• Прогнозирование развития архитектуры гражданских и промышленных зданий и их комплексов
• Создание чертежей и необходимых расчетов
• Создание интерьеров и экстерьеров гражданских и промышленных зданий, сооружений и их комплексов
• Осуществление авторского надзора за процессом строительства
• 3D-визуализация будущего строения

Важные качества

Личные качества: развитое пространственное воображение, точный глазомер, умение находить креативные, нестандартные решения, развитые творческие и художественные способности, наблюдательность, ответственность

Soft skills: креативное мышление, навыки убеждения и аргументации, нацеленность на результат, выработка и принятие решения

Профессиональные навыки: знание строительных норм и ГОСТов; знание методов проектирования и расчетов, навыки разработки необходимой документации и архитектурных чертежей, базовые знания по картографии, геодезии и экологии, базовые математические знания, художественные навыки в области рисунка, графики и композиции.

Где работает

• Конструкторские бюро при министерствах и ведомствах
• Проектные институты
• Архитектурные подразделения промышленных предприятий
• Архитектурные и реставрационные мастерские
• Образовательные учреждения
• Частная практика

Потенциальные работодатели

• Минстрой России
• “ПИК”
• SPEECH Чобан&Кузнецов
• Центр городских исследований Московской школы управления «Сколково»
• КБ «Стрелка»
• Главные управления архитектурного градостроительства городских администраций
• Крупные девелоперские компании
• “РОСНАНО”
• РАО «ЕЭС России»
• “Газпром”
• “Русский алюминий”
• Холдинг «Сибур»

Вузы, в которых готовят специалистов по профессии «Архитектор»

• Московский архитектурный институт 
• Санкт-Петербургский государственный архитектурно-строительный университет 
• Государственный университет по землеустройству 
• Военный инженерно-технический университет Министерства обороны РФ 
• Нижегородский государственный архитектурно-строительный университет 

Более подробно познакомиться с вузами, осуществляющими подготовку по этой профессии, Вы можете на сайте:

«Поступай правильно»

«Поступи онлайн»

Компании-партнеры

ожидания VS реальность / Softline corporate blog / Habr

Привет, Хабр.

Меня зовут Анна Лисовская, я ИТ-архитектор департамента развития корпоративных продаж. Идею этого поста мне подсказал бывший сокурсник, которому внезапно стало скучно в разработке. В один прекрасный день он решил, что больше не хочет писать код, начал искать возможности для развития в смежных ИТ-областях и атаковал меня вопросами об особенностях работы ИТ-архитекторов. Из беседы стало ясно, что даже коллеги-айтишники слабо представляют себе сложности и особенности профессии ИТ-архитектора. Не исключено, что заблуждения, в которых пребывал мой бывший сокурсник, достаточно расхожи.

Я собрала свой опыт и опыт коллег в пост в формате «ожидание/реальность». Такой формат мне видится наиболее полезным с точки зрения работы с ожиданиями относительно профессии ИТ-архитектора – часто среди айтишников эти ожидания либо не совсем верны, либо завышены. Много тонких моментов становятся очевидны только при полном погружении в профессию. Лучше узнать о них «на берегу» и поразмышлять, сможете ли вы с ними мириться. Хочется думать, что мои заметки будут полезными для других айтишников, которые намереваются переквалифицироваться в ИТ-архитекторы.

Ожидание: чтобы стать успешным ИТ-архитектором, нужно хорошо знать «железо» и софт.
Реальность: работа ИТ-архитектора – это в основном people management.

За ИТ-архитекторами в головах представителей других айтишных профессий почему-то закрепился образ интровертов, которые легко цитируют документацию, досконально знают, как работает то или иное программное и аппаратное обеспечение, и целыми днями рисуют конфигурации ИТ-систем. Это верно лишь отчасти. ИТ-архитектор действительно обладает широчайшим кругозором, хорошо знает, как работают софт и оборудование, но главным скиллом в его профессии является people management. ИТ-архитектор должен иметь навыки или хотя бы задатки управления командой, поскольку именно он собирает на проект специалистов самых разных направлений. Держа в голове архитектуру проекта, он ставит задачи конкретным специалистам, следит за качеством и сроками исполнения тех или иных работ и в конечном счете отвечает за то, чтобы вся команда выполнила задачу, поставленную бизнес-заказчиком. При этом ИТ-архитектор должен очень хорошо уметь говорить с бизнесом на его языке. И при представлении своего видения той или иной ИТ-системы должен обращать внимание не только на технологическую красоту и изящество решения в целом, но и подчеркивать его экономическую целесообразность.

Ожидание: любого технического образования достаточно для работы ИТ-архитектором.
Реальность: базового образования, как правило, не хватает; учиться нужно постоянно.

Глупо отрицать, что техническое образование – это база практически для каждой ИТ-профессии. Но так же не слишком дальновидно утверждать, что диплома любого технического вуза хватит на освоение профессии ИТ-архитектора. Ни один российский вуз не выпускает готовых специалистов по данному профилю. Например, я училась в петербургском Политехе на радиофизическом факультете. Это здорово помогло на заре карьеры, когда я работала техническим ассистентом по продаже оборудования Cisco. Бэкграунд инженера-физика помог понимать процессы, на основе которых работает современное коммуникационное «железо». Благодаря этой форе в виде знаний по предметной области мне было легче, чем коллегам-новичкам. Вместе с тем, я достаточно быстро поняла, что даже фундаментального образования радиофизика мне мало, и приняла решение получить второе высшее по своему тогдашнему профилю – по сетям. Меня повысили до системного инженера, допустили к оборудованию и стали привлекать на встречи с вендорами и клиентами. Собственно, с того момента и началось самое интересное. Я много работала непосредственно с «железками», настраивала сетевое и серверное оборудование, привыкала общаться с заказчиками, постепенно понимала, как устроен ИТ-бизнес, как строится взаимодействие с вендорами и дистрибьюторами.

Не берусь утверждать, что мой вариант восхождения по «лестнице знаний» единственно верный. Среди коллег из числа ИТ-архитекторов есть специалисты, которые начинали вчерашними выпускниками университетов, а затем всё глубже погружались в предметную область. Узнать больше им помогали вендорские курсы и сертификации, курсы учебных центров, семинары и другие образовательные мероприятия. Но вне зависимости от того, какой способ развития выбран, ИТ-архитектор учится практически постоянно. Нужно быть готовым инвестировать в это обучение как минимум свое время, как максимум – и время, и деньги. Например, среди моих знакомых есть человек, который в прошлом был прожженным гуманитарием — он выпускник философского факультета СПбГУ. В свое время поставил себе цель стать ИТ-архитектором. На это он потратил несколько лет своей жизни — получил высшее техническое образование, дополнительно «прокачал» свои навыки на вендорских курсах и сейчас работает на позиции ИТ-архитектора в крупном центре обработки данных.

Ожидание: необходимые знания можно добрать самостоятельно – все есть в интернете.
Реальность: нужно знать, какие знания добирать; самых ценных знаний в открытом доступе нет.

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

Также у некоторых вендоров невозможно получить техническую информацию по другим каналам, кроме официального обучения. Такой информации нет в интернете. Ее нельзя где-либо купить.

Ожидание: быть архитектором в компании-вендоре лучше, чем работать с заказчиками.
Реальность: развитие идет быстрее, если работаешь на разноплановых проектах.

Конечно, трудиться ИТ-архитектором в вендоре престижно. Мощный соцпакет, размеренный рабочий график и отсутствие постоянной «гонки» способствуют погружению в особенности конкретного решения. Для этого требуются вполне конкретные качества — здоровая дотошность, усидчивость, умение правильно преподнести лучшие качества решения конкретному клиенту в формате презентации или публичного выступления. Да, эти качества сделают из вас профессионала, но, на мой взгляд, работа ИТ-архитектором в провайдере или интеграторе существенно быстрее повысит вашу экспертизу и профессиональный уровень в целом. Работа на разных проектах расширяет технический кругозор, приучает к общению с самыми разными людьми и учит искать решения, оптимальные для всех сторон, задействованных в процессе.

Если мы говорим про архитектора в заказчике, то от него в значительной степени требуется умение убеждать в необходимости преобразований ИТ-инфраструктуры таких «сложных» людей, как генеральный и финансовый директора. В их картине мира ИТ – это служба, которая тратит деньги. Часто, чтобы объяснить необходимость финансирования проекта, ИТ-архитекторы со стороны заказчика, вендора и интегратора объединяют усилия и продумывают аргументацию вплоть до конкретных формулировок. По своему опыту могу сказать, что пара таких совместных мозговых штурмов помогла намного лучше понять основные закономерности, по которым функционируют механизмы принятия решений в российских компаниях.

Ожидание: программист легко может переквалифицироваться в ИТ-архитектора.
Реальность: у системного инженера больше шансов начать новую карьеру.

На мой взгляд, более благоприятные начальные условия построить карьеру ИТ-архитектора у системных инженеров. Они лучше представляют, как работает оборудование, они сами все настраивали, у них есть опыт ликвидации всевозможных сбоев. У инженеров не всегда может хватать теоретической базы, но благодаря опыту они быстрее эту базу нагонят. На втором месте – разработчики. Толковый программист действительно может стать архитектором по ПО – особенно если такой программист принимал участие в создании больших информационных систем и понимает их логику. А дальше он просто берет навыки построения ЛВС, вычислительной инфраструктуры, систем хранения данных и пр. Еще сложнее переквалифицироваться в ИТ-архитекторы из пресейлов. Пресейл более-менее знает теорию, но с оборудованием он знаком по верхам, поскольку не «крутил» его настройки руками и не устранял причины сбоев и не пытался понять природу их возникновения.

Ожидание: труд ИТ-архитектора – это постоянный креатив.
Реальность: рутины хватает, особенно бумажной работы.

Часто будущие архитекторы думают, что их работа состоит исключительно из проработки решений и построений систем, но это не так. Рутины более чем достаточно, и связана она не в последнюю очередь с подготовкой документации по проектам. Впрочем, основную часть такой работы можно поручить команде, а самому проконтролировать ее качество документов и свести их воедино. Как видим, people management всплывает и здесь.

Ожидание: ИТ-архитектор может развиваться только как эксперт в технологиях.
Реальность: все зависит только от вас. Вырасти можно в абсолютно любом качестве.

ИТ-архитектор – универсальный специалист, который хорошо знает ИТ-оборудование и программное обеспечение, и наряду с этих обладает компетенциями менеджера. Это дает, пожалуй, самые широкие возможности для карьерного роста среди всех ИТ-специальностей. Ты можешь расти как технический эксперт, нарабатывать специализацию и в конечном итоге стать одним из лучших специалистов в своей предметной области. Либо ты можешь развиваться как управленец – как минимум стать менеджером проектов, а как максимум — директором по ИТ в заказчике. Особенно если заказчик как раз в данный момент подыскивает ИТ-директора под стратегическую задачу модернизации инфраструктуры. Словом, даже если в один прекрасный день вы поймете, что не хотите быть ИТ-архитектором, ваш многогранный опыт с одинаковым успехом позволит стать и крутым экспертом в технологиях, и выполнять административные функции.

Ожидание: ИТ-архитектор – профессия, где удачно балансируются работа и время для жизни.
Реальность: рабочий день с 9 до 18 – не про системного архитектора; работа достаточно стрессовая.

ИТ-архитектор – это центральный персонаж при создании информационных систем. Именно от архитектора зависит, состоится ли проект, заработает ли на этом проекте компания. В этом смысле груз ответственности нередко давит – особенно когда заказчик ставит сжатые сроки, и ты просто не имеешь права подвести проектную команду. Пример из жизни: на часах 10 утра, рабочий день только начался. Звонит представитель заказчика и просит коммерческое предложение к полудню. Или аналогичное обращение прибывает в 21:00, и уже к утру клиент просит прикинуть, сколько будет стоить оборудование для развертывания ИТ-системы. Я выкручиваюсь – звоню своим людям в дистрибьюторах и вендорах, прошу быстро выдать мне стоимость решения. Многое, если не всё, помогают решить нормально выстроенные отношения. Коллеги не подводят, но жесткие рамки, в которые часто ставят заказчики, — дополнительный источник стресса.

Заключение

Интерес к профессии ИТ-архитектора со стороны разработчиков и представителей других айтишных специальностей подкрепляется неплохой зарплатой. Но эта работа подойдет не всем. Она не для вас, если:

1. Вам не очень нравится нести ответственность не только за себя, но и за того парня.
2. Вы считаете, что ваша доступность по телефону или по электронной почте должна быть ограничена рамками рабочего дня.
3. Вы не слишком любите людей и не хотите искать к ним подход, чтобы достигать своих целей.
4. Перспектива готовить или проверять проектную документацию вызывает у вас зевоту.
5. Вы с трудом ладите с «Пауэр Поинтом» и не слишком в восторге от того, что вам нужно выступать перед клиентами.
6. Вы считаете себя самым компетентным специалистом и не считаете нужным объяснять что-либо тому, кто с вами не согласен.

Если у вас нет вышеперечисленных особенностей характера, но при этом есть желание развиваться, становиться лучше и осваивать новые предметные области, то добро пожаловать в ряды ИТ-архитекторов. Возможно, кое-какие детали остались за рамками поста. Пишите вопросы в комментариях, я постараюсь ответить.

Анна Лисовская, ИТ-архитектор департамента развития корпоративных продаж группы компаний Softline.

Проектирование — Википедия

Проекти́рование — процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или её части (ISO 24765).^[1] Результатом проектирования является прое́кт — целостная совокупность моделей, свойств или характеристик, описанных в форме, пригодной для реализации системы.^[2]:272

Проектирование, наряду с анализом требований, является частью большой стадии жизненного цикла системы, называемой определением системы (англ. system definition). Результаты этой стадии являются входной информацией для стадии реализации (воплощения) системы (англ. system realization).^[2]:268

Проектирование системы направлено на представление системы, соответствующее предусмотренной цели, принципам и замыслам; оно включает оценку и принятие решений по выбору таких компонентов системы, которые отвечают её архитектуре и укладываются в предписанные ограничения.^[2]:272

В настоящее время существует сильная тенденция рассматривать архитектурное и детальное проектирование как различные виды деятельности; делаются попытки определить их как отдельные практики, однако эти виды проектирования в значительной мере «переплетены». Архитектурные решения в сравнении с «обычными» проектными решениями рассматриваются как более абстрактные, концептуальные и глобальные; они нацелены на успех всей миссии и на наиболее высокоуровневые структуры системы.^[2]:272 Детальное проектирование, в свою очередь, определяется как процесс детализации и расширения предварительного проекта (архитектуры) до такой степени, при которой проект полностью готов к реализации.^[1]

В античные времена проектирование рассматривалось как «наука архитектора»^[3]. Деятельность архитектора была связана не только с возведением зданий, но и с созданием строительных и военных машин. Описание системы знаний и принципов организации этой науки представлено в труде римского архитектора и механика Витрувия, жившего 2 тысячи лет назад в эпоху Цезаря и Августа^{[источник не указан 88 дней]}.

Проектирование в СССР[править | править код]

В ранний период истории СССР проектирование являлось одним из наиболее «узких мест» строительства. Существовало индивидуальное кустарное проектирование. Только в 1929 году начинали создаваться специальные проектные организации^{[источник не указан 1075 дней]}.

Проектные конторы разделялись на республиканские и местные. Республиканскими конторами, проектирующими гражданское строительство, являлись: Гипрогор и Коммунстрой, деятельность которых координировалась с проектными конторами областного значения — в частности по Москве — МосПроект, МособлжилСоюз, по Ленинграду — Жилгражданстрой и т. д.

В целях построения единого плана работ по проектированию гражданского строительства для 1932 года как правило устанавливалось, что:

а) программы республиканских проектных контор РСФСР по гражданскому строительству охватывали проектные работы для сверхлимитного индивидуального, типового и нижелимитного типового строительства;

б) программы местных проектных контор (автономных республик, краевых и областных) охватывали проектные работы для нижелимитного не типового строительства и по приспособлению типовых проектов к земельным участкам; проектирование для сверхлимитного индивидуального и типового строительства допускалось в порядке плановой увязки этих работ с программами указанных выше республиканских проектных контор^{[источник не указан 1075 дней]}.

Внутри процесса проектирования, наряду с расчетными этапами и экспериментальными исследованиями, часто выделяют процесс конструирования.

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

Слово «конструкция» часто употребляется в значении «структура», «устройство», например, конструкция предложения в лингвистике или организация эстетического материала в искусстве.

Конструирование может осуществляться:

Чертёж дверных конструкций

По отраслям деятельности[править | править код]

Можно привести следующие примеры видов проектирования по отраслям деятельности:

По подходу к проектированию[править | править код]

Функциональное проектирование[править | править код]

Любой инженерный объект служит для осуществления одной или нескольких функций в использующих его системах, то есть функция — первична, объект — вторичен. Так, основной функцией автомобиля является перевозка грузов и людей, основной функцией ручки — оставить чернильный след на поверхности (бумаге и т.п.), книги — выступать носителем письменной информации и т. д.

Функциональное проектирование представляет наиболее общий подход к описанию систем. Определяются граничные условия и желательные входы и выходы, составляется подробный перечень функций или операций, которые должны выполняться^[4]. При функциональном проектировании осуществляется синтез структуры и определяются основные параметры объекта и его составных частей (элементов), оцениваются показатели эффективности и качества процессов функционирования. Результатом проектирования, как правило, являются принципиальные, функциональные, кинематические, алгоритмические схемы и сопровождающие их документы^[5].

Оптимальное проектирование[править | править код]

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

Кроме того, вариантов решения практической задачи практически всегда несколько, и перед разработчиком встаёт проблема аргументированного выбора окончательного варианта.

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

Большое значение в оптимальном проектировании отводится подготовке на этапе технического задания полного перечня требований к разрабатываемому объекту, выделению среди них показателей качества и преобразованию наиболее важных из них в критерии оптимизации. Показателен в этой связи девиз одной японской фирмы — «Мы не создаем технику, мы создаем человека».

Системное проектирование[править | править код]

Основные части проектирования

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

При создании объектов их уже необходимо было рассматривать в виде систем, то есть комплекса взаимосвязанных внутренних элементов с определенной структурой, широким набором свойств и разнообразными внутренними и внешними связями. Сформировалась новая проектная идеология, получившая название системного проектирования.

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

Принципы системного проектирования[править | править код]

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

• Практическая полезность:
  • деятельность должна быть целенаправленной, устремленной на удовлетворение действительных потребностей реального потребителя или определенной социальной, возрастной или иной групп людей;
  • деятельность должна быть целесообразной. Важно вскрыть причины, препятствующие использованию существующих объектов для удовлетворения новых потребностей, выявить вызывающие их ключевые противоречия и сконцентрировать усилия на решении главных задач;
  • деятельность должна быть обоснованной и эффективной. Разумным будет использование не любого решения задачи, а поиск оптимального варианта;
• Единство составных частей:
  • целесообразно любой объект, сложный ли он или простой, рассматривать как систему, внутри которой можно выделить логически связанные более простые части — подсистемы, единство частных свойств которых и образует качественно новые свойства объекта-системы;
  • разрабатываемые объекты предназначены для людей, ими создаются и эксплуатируются. Поэтому человек также обязан рассматриваться в качестве одной из взаимодействующих систем. При этом должно приниматься во внимание не только физическое взаимодействие, но и духовно-эстетическое воздействие;
  • внешняя, или как её ещё называют — жизненная среда, также должна рассматриваться в качестве системы, взаимосвязанной с проектируемым объектом;
• Изменяемость во времени:
  • учёт этапов жизненного цикла объекта;
  • учёт истории и перспектив развития и применения разрабатываемого объекта, а также областей науки и техники, на достижениях которых базируются соответствующие разработки.

Нисходящее и восходящее проектирование[править | править код]

Ведение разработки объекта последовательно от общих черт к детальным называется нисходящим проектированием. Его результатом будут требования к отдельным частям и узлам. Возможен ход разработки от частного к общему, что образует процесс восходящего проектирования. Такое проектирование встречается, если одна или несколько частей уже являются готовыми (покупными или уже разработанными) изделиями.

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

Например, разрабатывая при нисходящем проектировании автомобиль (от общей схемы к его частям, например, — к мотору), необходимо увязать общую компоновку с размерами и мощностью уже выпускаемых двигателей. В противном случае придётся разрабатывать применительно к данной компоновке новый двигатель, либо изменять первоначальные варианты его расположения или схему компоновки всего автомобиля.

Проектирование, как осознанная целенаправленная деятельность, обладает определённой структурой, то есть последовательностью и составом стадий и этапов разработки проекта, совокупностью процедур и привлекаемых технических средств, взаимодействием участников процесса.

В настоящее время существуют два представления структуры проектирования, подобные по форме, но различные по целям и подходам к деятельности. Это — структура в виде стадий разработки проектной документации (стадий проектирования) и структура процесса проектирования^{[источник не указан 88 дней]}.

Стадии проектирования[править | править код]

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

Стадии разработки проектной документации

Стадии проектирования регламентированы стандартами ГОСТ 2.103—2013^[6] и ГОСТ Р 15.301—2016^[7]. Последовательность выполнения всех стадий образует официальную структуру процесса разработки проектной документации, которая, как правило, используется при официальных взаимоотношениях между заказчиком и исполнителем или между соисполнителями работ. Сама документация необходима для отчёта перед заказчиком о проделанной работе, возможности проверки или повторения разработок другими исполнителями, подготовки производства и обслуживания изделия в период эксплуатации.

Стадии создания других систем регламентируются своими стандартами, например, для автоматизированных систем — ГОСТ 34.601—90^[8].

Структура устанавливает стадии разработки конструкторской документации на изделия всех отраслей промышленности и этапы выполнения работ внутри каждой стадии, то есть состав документации и виды работ, что помогает ответить на вопрос «Что нужно делать?» в процессе проектирования. Основные стадии структуры включают:

• Эскизный проект (ЭП) — совокупность документов, содержащих принципиальные решения и дающих общее представление об устройстве и принципе работы разрабатываемого объекта, а также данные, определяющие его назначение, основные параметры и габаритные размеры. В случае большой сложности объекта этому этапу может предшествовать аван-проект (предпроектное исследование), обычно содержащий теоретические исследования, предназначенные для обоснования принципиальной возможности и целесообразности создания данного объекта.

При необходимости на стадии ЭП проводят изготовление и испытание макетов разрабатываемого объекта.

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

В процессе разработки проектной документации в зависимости от сложности решаемой задачи допускается объединять между собой ряд этапов. Этапы постановки ТЗ и технического проектирования могут входить в цикл научно-исследовательских работ (НИР), а этапы технического предложения и эскизного проектирования — образовывать цикл опытно-конструкторских работ (ОКР)^{[источник не указан 88 дней]}.

Структура процесса проектирования[править | править код]

Процесс решения задачи проектирования

Проектирование — целенаправленная деятельность, которая обладает последовательностью процедур, ведущих к достижению эффективных решений. Соответственно, должна быть структура процесса решения задачи проектирования, которая помогает ответить на вопрос «Как это делать?». В настоящее время предложен ряд структур и алгоритмов проектирования, совпадающих в основных чертах и различающихся только в содержании или названии отдельных этапов.

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

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

Следующие этапы образуют внутреннее проектирование. Они нацелены на поиск решения задачи и выполняются разработчиком. Сюда входят этапы синтеза принципа действия, структуры и параметров проектируемого объекта:

• На этапе синтеза принципа действия отыскивают принципиальные положения, физические, социальные и т. п. эффекты, которые составят основу функционирования будущего изделия. Это могут быть основополагающие нормы, фундаментальные законы и правила, их частные случаи или следствия. Работа ведётся с принципиальными моделями и их графическим представлением — блок-схемами. Этому этапу соответствует заключительная стадия ТЗ и стадия технического предложения структуры проектирования по ГОСТ 2.103;
• На этапе структурного синтеза на основе выбранного принципа действия создаются варианты начального графического представления объекта — структуры, схемы, алгоритмы, упрощённые эскизы. В соответствии с ГОСТ 2.103 этот этап включает стадию эскизного проектирования;
• На этапе параметрического синтеза отыскиваются значения параметров объекта, находится численное, в том числе оптимальное, решение проектной задачи, создаётся подробная документация или описание объекта, чертежи изделия и его частей. Этот этап соответствует стадиям технического и рабочего проектирования.

Вследствие неполноты начальных знаний о задаче процесс проектирования — итеративен, с каждым циклом итерации цели проектирования всё более уточняются, появляется необходимость в дополнительных функциях и, как следствие, — потребность в разработке дополнительных частей и узлов. Решение частных проектных задач, дополняющих основное решение, также проводится в соответствии с представленной последовательностью.

На каждом этапе внутреннего проектирования выполняются следующие процедуры:

• выбор модели (то есть основополагающего принципа, вида блок-схемы и расчетной схемы),
• выбор метода решения, в том числе метода оптимизации,
• решение,
• анализ полученных результатов и принятие решения.

Замечено, что эффективность проектируемого объекта определяется: в первую очередь — выбранным принципом действия, во вторую — предложенной структурой и в третью — соотношением параметров.

Проект повторного применения — это документация на объект строительства, по которой получено положительное заключение государственной экспертизы, построен и введен в эксплуатацию объект. Использование проектов повторного применения в проектировании позволяет затраты на проектирование и экспертизу свести к минимуму. Также сокращается срок проектирования^{[источник не указан 88 дней]}.

• Эвристические методы
  • Метод итераций (последовательного приближения)
  • Метод декомпозиции
  • Метод контрольных вопросов
  • Метод мозговой атаки (штурма)
  • Теория решения изобретательских задач (ТРИЗ)
  • Метод морфологического анализа
  • Функционально-стоимостной анализ
  • Методы конструирования
• Экспериментальные методы
• Формализованные методы
  • Методы поиска вариантов решений
  • Методы автоматизации процедур проектирования
  • Методы оптимального проектирования

• Сидоров А.И. Основные принципы проектирования и конструирования машин. — М.: Макиз, 1929. — 428 с.
• Орлов П.И. Основы конструирования: Справочник: В 2-х книгах. — М.: Машиностроение, 1988. — ISBN 5-217-00222-0.
• Хорошев А.Н. Введение в управление проектированием механических систем: Учебное пособие. — Белгород, 1999. — 372 с. — ISBN 5-217-00016-3. Электронная версия 2011 г.
• ISO/IEC/IEEE 24765:2010 Systems and software engineering — Vocabulary. — 2010.
• ГОСТ Р ИСО/МЭК 15288—2008. Системная инженерия — Процессы жизненного цикла систем. — 2008.
• Kossiakoff A., Sweet W. N., Seymour S. J., Biemer S. M. Systems Engineering Principles and Practice. — 2-е изд. — Hoboken, New Jersey: A John Wiley & Sons, 2011. — 599 с. — ISBN 978-0-470-40548-2.
• Pyster, A., D. Olwell, N. Hutchison, S. Enck, J. Anthony, D. Henry, and A. Squires (eds). Guide to the Systems Engineering Body of Knowledge (SEBoK) version 1.0. — The Trustees of the Stevens Institute of Technology, 2012.

Как стать архитектором ПО

Статья посвящена этапам становления архитектором ПО. Первая из серии статей, посвященных этой тематике. Начни с неё и может ты захочешь пройти этот путь!

Вы когда-нибудь задумывались над тем, какие возможности карьерного роста есть у разработчика? Какие направления для роста открыты? А главное, что случается с разработчиками старше 45 лет? Вот есть среди ваших друзей разработчик старше 45 лет? Я лично знаю нескольких таких, и многие из них истинные хардкорные программисты, которые работали еще с перфокартами.

Существует несколько возможностей карьерного роста, которыми разработчики могут воспользоваться:

• Первое и, наверное, самое очевидное – это карьерный рост в сфере вашей работы. Если вы junior-developer, то развивайтесь до middle и senior-developer, а затем уже занимайте роли тим лидов.
• Переход на другой стек технологий. В настоящее время большое количество разработчиков уходит в мобильную разработку на iOS и Android, которые только набирают силу.
• Перейдите на управленческую роль. Как разработчик могу вам сказать, что самой большой кадровой проблемой, которую я видел, является нехватка компетентных управленцев. Талантливый управленец очень дорого обходится компании, поэтому их сложно найти. Если управленец будет иметь технический бэкграунд, то это позволит ему быть на одной волне с разработчиками.
• Станьте архитектором ПО. Это направление будет рассмотрено в данной серии статей.
• Уход из сферы IT. Да, бывает, что такое случается. Никогда не поздно начать делать то, что вам нравится.

За последние восемь лет, я вначале работал с Java EE, затем перешел на работу с iOS и стал тим лидом. Я был руководителем различных команд разработчиков и работал с различными стеками технологий, включая Android и Web стеки. Создал архитектуру сетевого уровня взаимодействия для нескольких сервисов, разрабатываемых компанией, с помощью сокетов и REST API. За это время работы я познакомился с ролью управленца и с перспективами развития в этом направлении, при том, что позицию тим лида занимал уже более двух лет. На своей следующей позиции, моей целью является быть архитектором ПО.

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

Эта серия статей поможет вам в том случае, если вы относитесь к одной из нижеприведенных категорий:

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

Перед тем как переходить к более узконаправленным вопросам, необходимо определить, кто такой архитектор программных решений и его обязанности.

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

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

Во-первых, давайте рассмотрим характерные черты архитектора:

• Коммуникабельность. Разговаривая со многими архитекторами программных решений, я все время слышал, что коммуникабельность является одной из наиболее важных особенностей архитектора. В течении рабочего дня они разговаривают с заказчиками на языке бизнеса, управленцами любого уровня, бизнес-аналитиками и разработчиками. Если в вас присутствует природная харизма и вы знаете как убеждать людей, то это будет гигантским плюсом для вас, так как очень важно уметь объяснять свои действия корректно. Архитекторы – это лаконичные, красноречивые и компетентные спикеры. Архитектор, с которым я разговаривал имеет отлично развитые навыки коммуникации и убеждения. Еще одной причиной, почему навык коммуникации очень важен является то, что роль архитектора требует от него принимать участие в большинстве дискуссий, и зачастую, компромисс должен быть достигнут с учетом, что результат дискуссий должен удовлетворять всем его участникам, то есть быть приемлемым и выгодным для всех.
• Широкий и глубокий уровень технических знаний. Это должны быть очевидно, так как никто, например, с медицинским бэкграундом, не сможет стать архитектором программных решений. Вдобавок, архитектор, чаще всего обладает знаниями нескольких технологических стеков, и при этом на довольно приличном уровне, а также должен иметь хорошее представление об еще нескольких. Архитектор также должен быть готов к тому, что ему придется составлять огромное количество технической документации, отчетов и диаграмм.
• Ответственность. Вы должны понимать, что решения архитектора чаще всего стоят очень дорого. Поэтому человек на данной позиции берет на себя большое количество ответственности и должен подходить к своей работе и решениям также ответственно. Если ошибка разработчика стоит нескольких дней работы одного человека, то ошибка архитектора может стоить нескольких лет человеко-часов работы, если проект сложный!
  

• Стрессоустойчивость. Эта должность подразумевает, что вы будете принимать решения, а значит, что вы будете задавать вопросы и вам необходимо получать на них ответы. Вы будете работать с различными людьми из разных сфер, и вам придется привыкнуть к тому, что требования могут быстро поменяться или даже условия ведения бизнеса могут измениться. Исходя из этих причин, вы должны быть готовы к стрессовым ситуациям и вам следует научиться скрывать свои негативные эмоции. Эмоциям, в принципе, нет места на работе. Работа всегда намного приятнее, если приносит вам только положительные эмоции. Поэтому, если вы выбрали эту должность только из-за денег, то еще раз хорошо подумайте.
• Управленческие способности. Сюда входят как организационные, так и управленческие способности. Способность руководить командой, которая может состоять из абсолютно разных специалистов, это очень полезный навык.
• Аналитические способности. Даже если специалист имеет очень широкий кругозор технических знаний, он испробовал различные технологии в своих личных проектах или принимал участие в различных совместных проектах, это не гарантирует, что он сможет легко изменить образ своего мышления и рассуждать как архитектор. Одной из наиболее важных задач является способность объяснять абстрактные проблемы в форме некоторых конечных реальных объектов системы, которые разработчики, в свою очередь, оценивают, проектируют и разрабатывают. Отличные навыки коммуникации являются необходимостью для того, чтобы понятно объяснять абстракции в форме конечной системы для всех участников команды и заказчика. Всегда есть необходимость в уравновешивании, так называемой «чаши весов». На одной стороне этой чаши находится бизнес составляющая, а на другой располагается, непосредственно, разработка. Архитектору необходимо соблюдать баланс, основываясь на требованиях обоих сторон.

Если мы говорим об обязанностях архитектора, то есть отличный пример из 19 века, суть которого заключается в конструкции моста. В то время тестирование новопостроенных мостов состояло из следующего: ответственные за постройку моста инженеры, архитекторы вставали под мост и находились там, пока первые машины проезжали по нему. Получается, что они отвечали за прочность конструкции своими жизнями. Итак, если у вас возникает вопрос – за что отвечает архитектор программных решений в проекте? То ответ будет таким – он отвечает за все.

Если убрать все громкие и красивые фразы, то работа архитектора включает в себя:

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

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

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

• Изучить несколько стеков технологий и опробуйте их на практике. Мои текущие знания сконцентрированы только в области iOS разработки. Следует попробовать Android, несколько серверных языков, начать работу с Python, и освежить знания Java EE. Архитектор – это специалист широкого профиля (full-stack developer), поэтому очень важно иметь большой объем технических знаний.
• Читайте литературу. Очень важно, определить для себя некоторое количество значимых книг и статей, которые будут помогать вам развиваться в этом направлении. Обычно, самым простым способом найти подобную литературу – это спросить у профессионалов в этой области, чтобы получить их рекомендацию. В одной из следующих статей, я планирую привести список такой литературы.
• Найдите наставника. Желательно найти архитектора программных решений на вашем текущем месте работы. Зачастую, проще получить опыт от уже натренированного специалиста, чем начинать рассматривать каждую из областей с нуля. Очень важно быть подготовленным по части задавания вопросов своему наставнику, так как глупые вопросы никому не нравятся.
• Проходите курсы, получайте сертификаты. Существует множество различных курсов и сертификатов, но лишь немногие стоят своих денег, а курсы по высокоуровневым технологиям стоят больших денег. Лично для себя я прошел несколько курсов, посвященных становлению архитектором, на Luxoft (http://www.luxoft-training.com/it-course/ARC-001/), которые полностью оправдали потраченные на них средства. Очень важно, чтобы лектор был профессионалом своего дела и мог спокойно ответить на любой вопрос из этой области. Что касается сертификатов, перед началом, лучше разобраться, а будет ли котироваться тот или иной сертификат, авторитетна ли та система, которая их выдает, среди архитекторов программных решений, и стоит вообще его получать. Эту проблему я рассмотрю следующей статье этой серии.

Одной из самых важных частей является чёткий и понятный анализ поставленного плана. Что сделано, что необходимо рассмотреть, и где нужно ускориться, а что убрать из целей, в качестве ненадобности.

Если вас заинтересовала эта вводная статья из серии статей о том: «Как стать архитектором ПО», или если у вас внезапно возникла мысль попробовать этот путь, то хорошенько подумайте, точно ли вы этого хотите.

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

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

Стояние на одном месте в области IT – это есть синоним слову стагнация и личной скованности в жизни.

4 ключевые ошибки при построении карьеры в IT-сфере
Отказ после собеседования: как стоит реагировать
Дайджест материалов по трудоустройству в сфере IT
Готовимся к собеседованию в Google: 8 месяцев непрерывной работы

Ссылка на оригинальную статью
Перевод: Александр Давыдов