Программист проектировщик кто это

Кто такой хороший проектировщик?

Хороший проектировщик – на вес золота. Остальные участники производственного процесса создают тело сайта. Проектировщик – его душу. Так каким же должен быть проектировщик, гордо называющий себя профессионалом?

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

Должен быть немножко типографом. Ему знакомы разноуровневые заголовки, поведение текста и графики, ширина строк, форматы вывода дат и чисел и прочая ерунда, которая кажется ненужной на этапе проектирования. Но потом оказывается, что Константин Илларионович Константинопольский не уместился на одной строке, а жаловаться не на кого.

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

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

Должен быть немножко сеошником. Любой сможет объяснить, почему карта сайта, тупой текст на главной и переполненное меню навигации – это отстой. Но мало кто объяснит, куда делись тысячи посетителей после переделки устаревшего сайта.

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

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

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

Должен быть немножко Лермонтовым и немножко Пушкиным. Пушкины – это люди, которые с первого дня получения задания садятся за компьютер и фигачат, фигачат, фигачат прототип, исправляя результат по десять раз на дню. А Лермонтовы из семи дней пять думают, а два делают всё начистовую с первого раза. Хороший проектировщик не ударится ни в одну из этих крайностей.

Должен быть немножко мамой и немножко папой. Хороший проектировщик не бросит своё детище после принятия прототипа и технического задания. Он будет следить за каждым этапом разработки сайта, вплоть до бета-тестирования, искореняя ошибки и несоответствия. Ведь кто может знать о проекте больше, чем он?

Профессия «Архитектор программного обеспечения» — подробное описание и обзор

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

Советуем обратить внимание на топовую подборку курсов для архитекторов программного обеспечения

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

Архитектор ПО: кто это и чем занимается

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

Основные задачи:

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

Возможные направления работы: крупные IT-компании, бизнес.

Что должен знать и уметь архитектор ПО

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

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

Уникальное предложение — -50% на ВСЕ курсы Skillbox. Получите современную онлайн-профессию, раскройте свой потенциал.

Активировать скидку →

Личные качества

Системный архитектор обладает следующими качествами:

• аналитический склад ума;
• внимательность;
• терпеливость;
• общительность;
• самоорганизованность;
• стрессоустойчивость
• умение работать в команде.

Базовые настройки любого сотрудника:

• ответственность;
• исполнительность;
• желание развиваться в профессии.

Разные стороны профессии

Инженер программного обеспечения, как и любая другая специальность, имеет особенности.

• очень высокая зарплата;
• востребованность;
• перспектива роста и возможность участия в интересных проектах;
• престижная профессия.

• высокая ответственность;
• ненормированный график;
• сидячая работа.

Зарплата в Москве и по России

Средний заработок системного архитектора в Москве можно увидеть на скриншоте с сайта trud.com за 2019/2020 год:

Средняя зарплата в регионах:

Зарплата, указанная в вакансиях профессии «архитектор программного обеспечения», начинается от 70 тыс. руб. согласно сайту hh.ru. Начинающий проектировщик ПО должен:

• собирать требования для разработки ПО;
• участвовать в проектировании архитектуры информационных систем;
• участвовать в разработке функциональных требований к модулям ПО;
• проектировать часть архитектуры сервисов, структур данных, протоколов и API;
• готовить техническую документацию;
• совместно с командой проводить проверочные мероприятия;
• участвовать в архитектурном контроле ИС;
• участвовать в приёмо-сдаточных испытаниях.

Зарплата в 100-150 тыс. руб. предлагается специалисту среднего уровня, с опытом работы больше 1-3 года. Перечень некоторых его задач:

• владеет навыками проектирования Enterprise Architecture, Solution Architecture, Technical Architecture с использованием представлений, узлов, компонент, контейнеров, коннекторов, конфигураций и интерфейсов;
• имеет опыт описания системной архитектуры (не менее 2-х завершенных проектов);
• создаёт архитектурные артефакты (принципы, технологические стандарты, руководства, модели/карты возможностей, технологические дорожные карты, ландшафтные схемы, проекты решений);
• имеет опыт разработки ПО с микросервисной архитектурой;
• имеет системное мышление и хорошие коммуникационные навыки.

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

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

Как стать архитектором программного обеспечения

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

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

Есть способ проще и быстрее получить новую специальность → онлайн-курсы архитектора ПО.

С их помощью овладеть профессией на практике можно в дистанционном формате. Преимущества таких программ:

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

Если вас заинтересовала эта профессия — ставьте плюс в комментариях, расскажем, как в ней легко стартануть ��

Как стать архитектором ПО в 2023 году

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

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

Специализации и задачи IT-архитектора

В IT-архитектуре много направлений: enterprise, solution, system, data-архитектура. У каждой специализации свои особенности, которые в том числе зависят и от стека конкретной компании. Поэтому не так просто собрать универсальный пул навыков и технологий, подходящий любому IT-архитектору.

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

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

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

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

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

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

С какими областями знаний работает IT-архитектор

Чтобы грамотно выстраивать проект, ИТ-архитектор в банке должен понимать, как устроены эти области знаний:

1. Реализация бэкенда. Где хранить данные, как к ним обеспечить доступ.
2. Реализация фронтенда. Работа с клиентом, интернетом, каналами.
3. Интеграционная архитектура. Возможности интеграции, как обеспечивать взаимодействие между системами, не положив ни одну из них.
4. Безопасная архитектура. Как правильно обеспечить взаимодействие клиентов, быстро проводить идентификацию, авторизацию клиента.
5. Использование MDM. Это системы, которые будут хранить мастер-данные по необходимым для проекта сущностям (данные клиентов, продуктов и т. д.).
6. Реализация справочников. Важно правильно распространять по своим сервисам справочную информацию.
7. Монолитная, сервисная и микросервисная архитектуры. Как они устроены, в чём разница, плюсы и минусы подходов.

Analysis Patterns: Reusable Object Models

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

Высоконагруженные приложения. Программирование, масштабирование, поддержка

Сборник ключевых принципов, алгоритмов и компромиссов для разработки высоконагруженных систем и работы с данными.

Создание микросервисов

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

Что должен знать архитектор ПО

Архитектурный фреймворк TOGAF

Важно понимать, как строится архитектура предприятий. Мы пользуемся фреймворком TOGAF: проект прорабатывается с точки зрения бизнес-требований, технологического стека, архитектуры данных. Эта методология позволяет реализовать устойчивую и высокопроизводительную систему.

Примечание 1 Если при выходе из строя n-компонента система продолжает полноценно функционировать, то её можно считать устойчивой. N — величина динамическая и может изменяться в зависимости от критичности систем.

Примечание 2 Если при увеличении нагрузки система так же качественно отрабатывает запросы, то её можно считать высокопроизводительной. Для банков этот параметр очень важен, ведь предусмотреть действия клиентов возможно далеко не всегда.

Бизнес-требования

IT-архитектор должен разработать технический сценарий реализации бизнес-задачи.

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

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

Так выглядит BPMN-модель события на изменение клиентских данных. Это также пример event-driven архитектуры, о которой пойдёт речь ниже.

Важный момент, IT-архитектор также должен проанализировать и определить потенциальные изменения, чтобы при интеграции новой системы с другими системами не произошло сбоя. Нужно уточнять у бизнеса: «Если изменятся, например, фамилия клиента или поле в паспорте, это критично?». Если да, то всё заносится в бизнес-требования.

Техническая проработка

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

ИТ-архитектор указывает, какие технологии, фреймворки используются в задаче, на чём написано приложение. Мы в Газпромбанке пишем на Java. Но бывают коробочные решения, которые требуют дополнительного внимания. Например, сервис на REST придётся серьёзно переписывать, чтобы вызывать SOAP.

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

Архитектор учитывает требования безопасности. По сути, это контроль вызовов: кто вызывает сервис, а кто является вызываемым. Если компрометирующий сервис «А» знает, как вызвать сервис «Б» из защищённой системы, то вся система перестаёт быть защищённой. Тогда нужно прописать, что сервис «Б» должен вызывать сервис «А» из доверенной зоны и возвращать данные по своим каналам.

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

Архитектура данных

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

Базы данных

В начале 2000–х были две–три основных базы данных: Oracle, MySQL. Сейчас появляется множество новых реализаций: колоночные, документоориентированные, key-value БД. Их назначение примерно одинаковое — они хранят данные, но подходы к записи, чтению, масштабированию у них абсолютно разные.

Нужно понимать, какие существуют базы данных и какая между ними разница, что они позволяют делать, почему при использовании реляционных БД не всегда можно достичь большего профита. Например, если нет потребности в ACID (Atomicity, Consistency, Isolation, Durability), то можно рассмотреть NOSQL БД. Это даст возможность записывать большие объёмы данных в БД, к тому же масштабировать хранилище будет проще, чем при использовании реляционной БД.

Интеграция

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

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

Паттерны проектирования

Event-driven архитектура

Это удобный паттерн с большими функциональными возможностями: одно и то же событие могут принимать сразу несколько сервисов, по-разному на них реагируя. Здесь нет сильной связности между поставщиком и потребителем, они существуют автономно. Как маршрутизатор событий тут актуален Kafka.

Domain-driven design (DDD)

В этом случае все данные делятся на домены. Здесь нужно на ранней стадии спроектировать систему так, чтобы не допустить протекания доменов.

Подходы domain-driven design очень актуальны в больших компаниях. Если заранее не «нарезать» предметную область и не определить основные сущности этих доменов, то со временем данные могут задублироваться в разных частях системы, и синхронная актуализация этих данных вызовет трудности.

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

GitHub про DDD: книги, видео, комьюнити, обучающие курсы.

Onion-архитектура

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

Подход CQRS

CQRS (Command and Query Responsibility Segregation) — это парадигма, при которой операции записи отделены от операций чтения. Она необходима, когда нагрузка на чтение и запись данных распределена несимметрично. Например, когда большая часть бизнес-логики и сложных проверок приходятся на write-систему, а чтение данных происходит чаще, чем вставка изменений.

Инструменты визуализации решений

• Бизнес-вижн прописывается с помощью BPMN-подходов моделирования.
• Для построения архитектурных схем можно использовать UML или Archimate нотации. Мы используем Visio, либо аналог Visio (draw.io).

Описание движения сущности в информационной архитектуре.

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

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

Софт-скилы ИТ-архитектора

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

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

Как пасти котов. Наставление для программистов, руководящих другими программистами

В книге разбираются ситуации, которые помогают лучше понять, как общаться с программистами, чтобы они вас услышали.

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

Опыт — это проработка гипотез

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

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

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

Ликбез по современной классификации It-профессий ⁠ ⁠

Вне работы редко пишу на тему IT, всё больше про литературу, но тут что-то захотелось. Почему — до сих пор иногда, бывает, читаешь романы про будущее — и там «программист» где-нибудь на космической станции. Или, того хуже, «компьютерщик». Ладно, если «сисадмин». Всё ещё хуже, если пытаются писать киберпанк и сыпать айтишными словечками. Там непременно — «хакер». Как правило, перечисленными терминами у большинства опыт знакомства с IT-специализациями и должностями исчерпывается. Потому — очень кратко, и, конечно, далеко не всё.

Нынешний спектр IT-специальностей включает в себя:

I Системных администраторов и инженеров IT

Грубо обобщим, сисадминами и айтишниками часто называют всех, работающих в It-депаратаменте, но не пишущими программы (см. ниже «программисты»), хотя это не совсем верно.

Во-первых, это «эникеи» — низшее звено, специалисты техподдержки, т.е. люди, непосредственно контактирующие с пользователями и решающие вопросы по их рабочим местам. Чаще всего в конторе, не заморачивающейся за ITIL-принципы, на них навешана ещё куча обязанностей, про которые вы не знаете, наивно полагая, что в свободное от вас время они режутся в танчики (хотя — бывает и такое). Вообще, ТП (техподдержка) обычно делится на внутреннюю и клиентскую (если компания продаёт какой-то продукт или услугу), и специалисты разделены на 1-2-3 линии. Первая линия часто даже не инженеры, а операторы-диспетчера, принимающие и классифицирующие заявки, вторая — специалисты с более высоким опытом и т.д.

Чуть выше рангом стоят серверные системные администраторы — это те, кто администрируют сервера (блин, если вы не знаете, что такое сервер — не пишите, пожалуйста, ничего, кроме романтического фэнтези). Они (грубо) подразделяются на администраторов Windows-систем («форточники», виндузятники) и администраторов Linux-(Unix)систем (линуксоиды). Если я сейчас углублюсь в их описание для тех, кто не знает — то это будет не одна страница текста. Коротко — Linux круче (а FreeBSD — «фряха» — ещё круче), используется в бизнесе крупнее среднего, таких инженеров чуть меньше (хотя сейчас в крупных городах уже почти сравнялось), им платят, как правило, побольше. Хотя есть и «форточники», которые умеют строить и админить такие сложные системы на базе MS, что заткнут за пояс по опыту любого линуксоида.

Я вам раскрою один секрет. «Сисадмином» в приличной организации называться уже немодно и даже постыдно. Да и «айтишником» тоже не особо. Моя нынешняя должность, к примеру, называется «ведущий инженер IT-инфраструктуры«. По сути, здесь совмещены функции администратора всех серверных платформ + знания коммутационных систем. Чтобы сервера и рабочие места на предприятии работали, и всем была доступна сеть (Интернет либо корпоративная), всё это ещё нужно как-то связать. Для этих целей служат железки, называемые роутерами, маршрутизаторами, коммутаторами, хабами, свичами (если не разбираетесь, что из этого синонимы, но очень хотите использовать, давайте вы просто будете эти словечки равномерно распределять по тексту произведения — всё равно читатели такие же). Самые популярные, и, как считает, надёжные производители — Cisco (вообще, читается как «сиско», но в России принято из цензурных соображений произносить «циска», «киска», «кошка» отсюда варианты сетевых инженеров, их обслуживающих — цисководы или кошкодавы, реже — сетевики — просьба не путать со специалистами сетевого маркетинга).

Ещё в крупных компаниях бывают редкие касты админы VMWare (систем виртуализации и контейнеризации — серверов-«матрёшек», хотя часто это тоже реализовано разновидностями Linux — докер, кубер, проксмокс, опенВЗ, все дела), отдельно-вынесенные по функциям администраторы СУБД (по задачам и функционалу — от обезьянок-операторов до «Data Scientists» — учёных, строющих модели данных), инженеры (и диспетчера-операторы) ServiceDesk (см. выше — систем техподдержки — приёма и обработки заявок), инженеры систем IP-телефонии и поддержки CallCentre («телефонисты«) и т.д.

UPD — тут напомнили, есть же ещё специалисты по hardware и оргтехнике — «техники-ремонтники» и т.п.

Над всеми ними реют различные начальники групп, руководители IT-отдела и IT-директора (которых от этого не менее часто тоже просят поменять картридж).

Об отдельных (самых прибыльных на сегодняшний день) разновидностях напишу чуть ниже, после

II Программистов

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

Если в команде, то структура примерно

— джуниор (юниор) дев — разработчиков, либо «младших инженеров-программистов» — описывают классы, функции, в общем, фрагменты кода внутри большой команды, часто — вчерашние студенты, знающие 1-2 языка

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

— сеньор — ведущий, руководитель проекта разработки, крупных задач. Оно же бывает TeamLead — тимлид, лидер команды, наставник молодняка — тьютор.

Да, если вас раздражает количество иностранных и хипсторских слов в наименованиях профессий, то рекомендую изобрести машину времени и вернуться лет так на 40-60 в прошлое, изменить ход истории СССР так, чтобы лидирующее место в IT и мировых языках программирования заняли языки на базе русского. Я тоже человек, в целом, вполне патриотичных взглядов, но использовать в разговоре сленг/термины на базе английского — это вынужденная мера, потому что а) адекватных по оттеночному значению вариантов на русском часто просто нет б) это устоявшиеся термины, используемые в профессиональной речи везде в) из-за среды общения ты неизбежно переходишь на чтение или даже разговор на английском во время работы. Как-то так.

Отдельно есть такая категория как FullStack-разработчик — т.е разработчик-универсал, также разбирающийся в аппаратной среде, чаще это касается веб-приложений (а сейчас уже практически всё десктопное — веб). Часто водятся в «молодых перспективных стартапах». Отдельное есть каста программистов микроконтроллерного оборудования, пишущих на питоне, жаве и древних хтонических C и Ассемблере программное обеспечение для датчиков, систем мониторинга, модных сейчас «систем умного дома», «интернета вещей», «индустрии 4.0» и т.д.

Если у вас на предприятии «программист» и «сисадмин» по набору обязанностей — одно и единственное лицо, а вы, типа, «молодой современный развивающийся бизнес», и у вас +100 человек штата — бегите, ваше руководство либо дико жмотливое, либо застряло в 90-х, либо и то, и другое.

III (В продолжение темы про программистов.)

При этом в организациях, занимающихся разработкой и продажей программного обеспечения, есть отдельная элитная каста инженеров — DevOps-ов — системных интеграторов, инженеров, обслуживающих разработчиков, и совмещающих обязанности как «серверного сисадмина», так и админа средств виртуализации, так и разработчика различных обвязок, систем мониторинга, оркестрации и т.д. (если интересно, уровень их зарплат в Екб на 2019 год — примерно в районе 100000 р., в Мск — в 2-2,5 раза выше, но я вам это не рассказывал). Недавно возникла отдельная подкаста NetOps-ов — инженеров-ЛВС-ников (коммутационщиков) в стане разработчиков — те управляют выдачей диапазонов сетей, связанностью маршрутов, доступностью машин на колокейшнах, провайдерами и т.д. Это у вас на предприятии одна локальная подсеть вида 192.168.1.0/24, а у них на западе, говорят, есть уже даже должность «менеджера сетей», в чьи обязанности входит только контроль и разграничение диапазонов IP-адресов внутри одного большого предприятия (на самом деле, и в компании из 500-1000 человек рабочих подсетей и диапазонов может быть больше сотни).

Давайте в этом же блоке упомяну, а то куда их ещё.

QA Engineer (инженер качества предоставления, тестировщик) — занимается тем, что проверяет качество работы программиста, ищет ошибки, баги в системах. Подразделяется на ручного и авто-тестировщика (который сам программист и пишет авто-тесты, скажем, для прогонов написанной системы на стендах под нагрузкой)

Технический писатель (техпис) — пишет/переводит инструкции, сценарии, бложики ведёт и т.д., сюда же копирайтеры.

IV Администраторы (инженеры) информационной безопасности

Специалист, занимающийся ■■■■■■■■■■■, ■■■■■■■■ и ■■■■■■■■■■■■■■■ на ■■■■■■■■■■■, чтобы всякие ■■■■■■■■ не ■■■■■■■■ информацию куда-нибудь в ■■■■■. Занимается охраной и соблюдением режима ■■■■■■■■■■■■, ■■■■■■■■■■■ ■■■■■ на предприятии, ■■■■■■■■■ ■■■■■■■■ ■■■■■. Если серьёзно, то тут примерно та же градация спектра компетенций, что и у сисадминов, с тем отличием, что сисадмин вам открывает, предоставляет сервисы (если у него и у руководства нет синдрома вахтёра, то именно это он и должен делать), а инженер информационной безопасности их вам закрывает, сыпя цитатами из ФЗ Минкомсвязи, нормативных документов ФСТЭК и приказов директора, например. Как правило, их не любят все, особенно сисадмины (если эти должностные обязанности из-за упомянутой жмотливости руководства объединены в одном человеке — тем более не любят). Есть более элитная каста аналитиков информационной безопасности, аудиторов, которые не столько запрещают, сколько говорят — «как нужно запрещать», либо «как нужно предотвращать» НСД и т.п.

Всё, я утомился, т.к. пишу этот пост поздно ночью в черновик. Дальше — коротко

V Вообще Аналитики — (продуктовые, системные и т.д.) — пишут, скажем, ТЗ программистам, переводя язык заказчика в язык разработчика. Либо пишут предписания, проводят аудит и т.д. Качественные системные аналитики получают поболее всех вышеперечисленных.

VI SEO-специалист — специалист поисковой оптимизации, интернет-маркетолог, ещё бывают какие-нибудь асессоры и т.п.

VII дизайнеры всякие (думал написать здесь про разновидности специализаций в GameDev, но уже устал, да и всё это уже есть).

Где-то ещё водятся архитекторы информационных систем, инженеры-проектировщики ЦОД-ов, Data Scientist-ы, инженеры в области машинного обучения и т.д

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

Напоследок — одно правило (прим. — статья изначально для писателей). Не знаешь как назвать персонажа — называй «инженер». 90% из этих профессий — инженерные, и, даже если ошибёшься, это куда менее обидно, чем назвать сисадмина «программистом», а FullStack-программиста — «компьютырщиком». Вообще, забудь слово «компьютырщик», либо применяй его, только чтобы унизить собеседника.