НовостиОбзорыСобытияIT@WorkРеклама
ИТ-бизнес:

Блог

Может ли хороший “системный архитектор” получиться из специалиста, который два-три года не тянул лямку рядового программера?

Ещё одна заметка в преддверии “Праздника ИТ-специалиста”, который будет отмечаться завтра.

В комментарии к моему недавнему посту “ИТ-специалисты. Спрос и предложение. Кто в дефиците, а кто в избытке?”
директор Центра компьютерного обучения при  МГТУ им. Н. Э. Баумана Дмитрий Гудзенко написал: “Рынок насытился "полуучками", теперь работодателю нужны более квалифицированные кадры. Так что если раньше, чтобы найти работу, надо было 2 - 3 курса пройти, то теперь 5 - 6 нужно. Перешёл своеобразный переход от количества к качеству”.

Мне захотелось уточнить: о ком в данном случае идет речь -- "полуучках" c вузовскими дипломами, или о тех людях, которые освоили ту или иную ИТ-премудрость в школе, техникуме или самостоятельно?

Вот как ответил на этот вопрос Дмитрий Гудзенко: “Речь идёт о людях, которые обладают поверхностными знаниями – им с 2009 г. стало намного сложнее найти работу, так как работодатель может выбирать, и выбирает более серьёзных специалистов. А где были получены поверхностные знания – в вузе, на курсах, самостоятельно – не столь важно. Реально технические вузы даже половины потребности в ИТ-специалистах не удовлетворяют, так что роль курсов повышения квалификации велика”.

О том, кого именно следует считать ИТ-специалистами, мы уже писали. Хотя, конечно, взгляды на соответствующий список могут быть разные. К примеру, к какой категории трудящихся следует причислять продавцов ИТ-секций магазинов? К труженикам прилавка (которым все равно, что продавать) или все же к ИТ-специалистам?

Говоря о рынке ИТ-труда,  Дмитрий Гудзенко отмечает ещё одну его особенность: “В абсолютных цифрах знатоков Excel всегда будет больше (как предлагаться, так и спрашиваться), чем, к примеру, знатоков SQL. В то же время у нас падает (но не умирает насовсем) спрос на курсы подготовки начальных пользователей. В настоящее время соответствующие группы формируются в основном из пожилых людей или людей, недавно приехавших в Москву.  В то же время выше среднего растет спрос на так называемые “тяжёлые” курсы: к примеру, “Информационная безопасность” (локомотив здесь – курс “Этичные хакер”) и различные курсы подготовки разработчиков (Microsoft, 1C, PHP, и т. д)”.

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

Но я что-то сомневаюсь, что хороший “системный архитектор” может получиться из специалиста, который два-три года не тянул лямку рядового программера. А вы что думаете на этот счет?


Roman
Ну, собственно, программистом системному архитектору быть и вовсе не обязательно. Системный архитектор должен хорошо знать продукты компании, где он работает, разбираться в рынке современных IT-технологий, понимать стратегию компании в отношении разработки и продвижения программных продуктов, координировать работу программистов. Также он обязательно должен обладать хорошо развитым абстрактным мышлением, умением анализировать, умением оценивать риски разрабатываемого проекта, выявлять возможные проблемные моменты. Уметь определять низкую эффективность используемых подходов, инструментов, методов, и заменять их при необходимости или искать новые подходы. Должен знать методологию и стандарты проектирования, инструментов анализа и проектирования IT-систем, перспективных концепций развития IT-систем, методов ИТ-консалтинга. Знать цели, методы и технологии управления проектами. В личностном отношении у него должен быть высокий уровень коммуникабельности (деловой, разумеется), он должен уметь построить доверительные отношения с заказчиком, обладать способностью брать на себя инициативу по обеспечению соблюдения требований и учета интересов бизнеса в процессе реализации проектов. Должен быть инициативным, целеустремленным и креативным... А программистом он быть не обязан...
Александр
«Может ли хороший муж получиться из молодого человека, который два-три года не тянул лямку рядового влюбленного?» Смешно, правда? Думаю, что хорошие специалисты получаются только из людей, искренне влюбленных в свою профессию и ее «эпсилон-окрестность». А разве влюбленность похожа на «тягу лямки»? И разве у вас не возникает желание тотчас перестать быть «рядовым», стоит самую малость влюбиться? С первым днем весны вас, кстати :)
Если отвлечься от каторжно-бурлаковской терминологии в формулировке вопроса и прейти к его сути, то краткий ответ «нет, не может», гораздо более полно, аргументированно и довольно захватывающе освещен в серии блестящих эссе, вошедших в книгу «97 этюдов для архитекторов программных систем»: «Архитектор должен быть практиком», «Архитектор – прежде всего разработчик», «Одна строка кода стоит 500 строк спецификаций», «Попробуйте, прежде чем сделать выбор», «Проектируйте только то, что сможете запрограммировать» - пожалуй, сами статьи можно и не читать, одних названий достаточно.
Общепризнанные библии для архитекторов вроде GoF’а и «Архитектуры корпоративных программных приложений» наряду с UML-ными диаграммами щедро иллюстрированы программным кодом, так что для эффективного усвоения материала знать какой-то язык с  С-подобным синтаксисом не помешает.
Положим, бессмертный труд Кернигана и Ричи был предварительно проштудирован и паттерны из приведенных выше трудов успешно легли на неиспорченный практикой мозг начинающего архитектора. Вот тут, как правило, начинается настоящее веселье.. Нам доводилось получать решения простого тестового задания («разработать наборчик юнит-тестов для некоего контейнера элементов»), содержащие дюжину паттернов, среди которых могли оказаться даже такие, казалось бы внезапные, для этого задания штуки как MVP, отыскать само решение в этой толпе стратегий, инъекций, фабрик, моделей, представлений и их предъявителей – бонусный квест для приемщика задания. Все эти болезни вроде овердизайна (или «патологии шаблонов» в «97 этюдах..») и «аналитического паралича», конечно, излечимы, а лекарство – практика!
Более того, для того, чтобы отвергать идеи, требующие для своей реализации неприемлемых ресурсных затрат, уже на стадии зиготы и проверять «наколенными» прототипчиками свои сомнительные задумки архитектор должен постоянно держаться «на плаву» - уметь разрабатывать и хорошо чувствовать стоимость разработки. Так что не стоит лишать архитекторов главного удовольствия в нашей отрасли – можно и нужно их привлекать к программированию, например, критичных с архитектурной точки зрения кусков системы, иначе они быстро портятся, превращаясь в менеджеров 
2 Дуров Илья: строительные метафоры и аналогии уже, увы, не в моде в области разработки софта («Лучшие программы не строят – их выращивают» - название еще одного этюда из 97-ми). Хотя с требованиями по части широты кругозора соглашусь, у настоящих зодчих тут, кстати, все гораздо сложнее: «Идеальный архитектор должен быть человеком образованным, математиком, знатоком истории, осведомлённым в философии, разбирающимся в музыке, не чурающимся медицины, посвящённым в тонкости юриспруденции, знакомым с астрономией и космологическими теориями». Наверное, поэтому Барри Хокинс в этюде «’Архитектор программного обеспечения’ пишется со строчной буквы» заявляет: «.. дерзостью будет настаивать на том, что архитектор программного обеспечения должен стоять на одной ступени с Адвокатом, Доктором и Зодчим».

Александр, Зодчий по софту,
ЗАО «Лаборатория Касперского»
Александр
Что-то никто не сказал, что хороший системный архитектор должен любить:
- разумную простоту (в т.ч. упрощать, чтобы было легче разобраться тем, кто будет поддерживать код после авторов);
- читать и разбирать (в т.ч. чужой код, разный, часто брошенный авторами);
- и главное помогать разработчикам (в т.ч. аргументированно решить, как лучше сделать, договориться, подобрать компоненты среди того, что уже сделано, найти такие пути доработки, которые позволяют сэкономить время и усилия).

Это действительно не очень важно?