Куда должен расти департамент ит

Кто такой ИТ-архитектор и насколько перспективна эта профессия

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

Об авторе: Антон Мартынов — руководитель архитектурного комитета глобальной ИТ-компании SimbirSoft, кандидат технических наук. Стаж в ИТ-сфере 21 год, из них 15 лет — в проектировании ИТ-архитектуры.

Кто такой ИТ-архитектор и чем он занимается

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

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

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

В задачи ИТ-архитектора входит:

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

Насколько популярна профессия ИТ-архитектора

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

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

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

Как стать ИТ-архитектором

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

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

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

Очень часто ИТ-архитекторы вырастают в таком сотрудничестве и взаимодействии на проектах. Как правило, в эту профессию приходят опытные backend-, frontend-, web-разработчики и системные администраторы. Хорошо, если на старте карьеры есть возможность поучаствовать в сложных проектах помощником ИТ-архитектора. Это помогает гораздо быстрее войти в профессию и понять, как именно то, о чем пишут в книгах, реализуется на практике.

Hard skills, без которых не обойтись в работе ИТ-архитектора

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

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

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

Что касается этих требований, для начала достаточно изучить теоретические вопросы по книгам (например, Software Architecture in Practice и Designing Software Architectures: A Practical Approach), статьям, видеороликам и другим открытым источникам. А уже потом начать применять эти методы на практике. Далее для расширения кругозора и профессиональных знаний нужно будет изучать документацию, следить за информационными источниками (прежде всего, англоязычными), на которых появляются данные о самых передовых технологиях.

Soft skills, необходимые для успеха в этой профессии

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

В целом, ИТ-архитектору необходимо развивать следующие soft skills:

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

Какие перспективы перед специалистами открывает эта профессия

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

Опыт и полученные в этой профессии навыки позволят специалистам впоследствии вырасти до технического директора (CTO) или директора по цифровой трансформации (CDTO). Поскольку работа ИТ-архитектора подразумевает сочетание технических и управленческих компетенций, а также комплекс hard и soft skills, которые могут помочь построить карьеру и стать в перспективе CTO или CDTO.

Как понять, хотите ли вы быть ИТ-архитектором

Перепрофилироваться в ИТ-архитектора стоит, если:

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

Кроме этого, у вас должно быть непреодолимое желание трудиться в ИТ-сфере, способность быстро обучаться и усваивать огромные массивы информации.

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

Требования к ИТ-архитекторам коммерческих проектов: чек-лист

К кандидатам на должность архитектора в ИТ-компаниях обычно предъявляются следующие требования:

• Опыт работы в ИТ сфере — не менее пяти лет.
• Опыт проектирования и разработки архитектуры коммерческого проекта.
• Опыт написания технической документации, составления презентации и их защиты перед заказчиком.
• Наличие сертификата архитектора и по соответствующему направлению/стеку (желательно).
• Понимание основ сетевых и web-технологий (RESTful, HTTP, TCP/IP).
• Знание базовых принципов тестирования (различные виды тестирования, опыт практического применения).
• Знание стандартов и методик разработки и модификации программных продуктов
• Опыт проектирования архитектуры нагруженных систем.
• Знание и опыт применения базовых паттернов проектирования.
• Знание основ контейнеризации (Docker, Kubernetes и так далее).
• Понимание общего процесса разработки программного обеспечения.
• Умение обеспечивать баланс между стоимостью разработки и гибкостью решения для быстрого внедрения будущих требований.
• Умение выбирать и обосновывать выбор технологий.
• Умение контролировать реализацию: заложить каркас системы и вести архитектурный надзор.
• Умение прорабатывать и принимать решение по адаптации продукта к новым требованиям бизнеса, даже если в начале процесса проектирования они не были известны в полном объеме.

Этот список может незначительно меняться в зависимости от специфики проектов, но в целом он показывает общий уровень требований к специалисту.

Куда расти программисту в IT-компании

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

21 мая 2019 Read ~ 7 минут

Для программиста рост от junior до senior – естественное развитие в профессии, связанное с улучшением навыков. Однако очень сложно выбрать стратегию, как дорасти до высшей ступени: в IT нет универсальных критериев, что должен уметь разработчик на каждой позиции. А как развивать карьеру, когда уровень senior уже пройден?

Содержание:

Как может развиваться карьера программиста

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

Вертикальный рост

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

Время перехода на каждую позицию, от junior к senior, зависит не только от самого разработчика, но и от компании, в которой он работает. Например, программист может 5 лет проработать в небольшой компании и стать senior-разработчиком. При переходе в другую организацию он будет претендовать на ту же позицию, но на собеседовании может оказаться, что для нового работодателя его знаний не хватает. Возможен и другой сюжет, когда программист надолго застревает в статусе middle: выполняет одни и те же задачи и самостоятельно не принимает важные решения на проекте. Это может произойти не только с теми, кто не стремится улучшать свои профессиональные навыки, но и с программистами, у которых мало возможностей для роста в пределах своей компании.

Рост из junior в middle

Каждый программист начинает карьеру с позиции junior. Это отправная точка вашего маршрута, с которой будет отсчитываться профессиональный опыт. Когда junior приходит в компанию, часто за ним закрепляют ментора. Он курирует новичка, может проверять его работу. Как правило, уже через 1-2 года junior повышает свой уровень до middle-разработчика.

В отличие от junior, middle-программист – самостоятельный специалист в команде разработки, который не нуждается в контроле более опытных коллег. Middle-разработчик понимает, какие фреймворки и библиотеки лучше подходят для каждой задачи. На проекте он уже может отвечать за отдельные модули и функции приложения. Достигнув уровня middle, программист сосредоточен не только на своем коде, но и начинает интересоваться архитектурой решений.

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

Рост из middle в senior

Senior-программист – основной специалист в команде разработки. Как правило, помимо своего стека технологий, он интересуется архитектурой программного обеспечения, проектирует отдельные части системы. Senior-разработчик уже не просто исполнитель, а скорее, соавтор технических идей. С опытом он накопил достаточно знаний, чтобы оценивать риски и предупреждать ошибки в разработке.

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

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

Куда двигаться дальше senior-программисту

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

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

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

Должность lead-разработчика (Team Lead) может стать переходным этапом из программирования в менеджмент, так как уже включает в себя управление командой. Team Lead организует процесс работы во время проекта, делегирует задачи другим разработчикам. Также он может проводить собеседования с новыми специалистами, отвечать за их адаптацию и обучение. На этой позиции нужно оценивать работу коллег, разбирать чужой код. Эта роль подойдет тем, кто готов к ответственности за команду. В некоторых компаниях Team Lead может выполнять и обязанности менеджера проекта, то есть активно взаимодействовать с заказчиком.

Роль менеджера проектов (Project Manager) станет новым профессиональным опытом для разработчика. Однако такой переход будет комфортным не для каждого программиста – вместо часов наедине с компьютером и кодом, большую часть рабочего времени придется проводить в коммуникации с коллегами и клиентами. Чтобы senior-программисту вырасти в успешного менеджера, нужно развивать компетенции по модели T ( T-shaped skills ) , то есть дополнять свою специализацию навыками из других сфер (управление командой, делегирование задач, риск-менеджмент, знания различных индустрий). Потенциальных менеджеров проектов среди разработчиков обычно выделяет отношение к проекту как к личному делу. Им важно не только закончить свою часть работы, но и увидеть результат всей команды.

Если хотите не только управлять проектом, но и решать технические проблемы, то роль Delivery Manager подойдет вам больше, чем работа менеджера проектов. Это новая роль в IT, и пока такую вакансию можно встретить только в крупных компаниях, где в проекте задействованы десятки человек. Delivery Manager отвечает за все аспекты проекта, включая архитектуру приложения и другие технические вопросы.

Горизонтальный рост

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

Эксперт

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

IT-евангелист

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

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

IT-консультант

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

В каких компаниях больше возможностей для профессионального роста

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

Начинающим разработчикам лучше выбирать крупные сервисные компании, где будет возможность поработать в разных проектах и командах, – считает Сергей Голубенко – S oftware Architect в ScienceSoft. – Программист всегда учится у более опытных коллег, и если в команде мало специалистов, то ограничен и трансфер знаний. А проработав 5-7 лет в IT-компании, где сотни сотрудников, программист получит профессиональный капитал, с которым будет проще реализоваться в любой компании, как сервисной, так и продуктовой, или развивать свой стартап.

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

Куда ведет карьерная лестница

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

Карьера в IT: должность Support Engineer

Представляем новую статью из серии «Карьера в IT». Она посвящена должности Support Engineer — этот специалист занимается техподдержкой уже выпущенных продуктов компании.

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

По данным ДОУ, среднему украинскому инженеру техподдержки 26 лет, он имеет зарплату $300-700 и опыт работы 2 года.

Задачи и обязанности

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

Профессия Support Engineer разбита на 5 уровней (Levels), по номеру которого можно сразу с большой точностью определить, что из себя представляет конкретная позиция. Эта структура не имеет ничего общего с карьерной лестницей, а только с расположением работника поддержки на линии «Клиент — ядро продукта». Чем ниже уровень, тем ближе к клиенту и тем дальше от ядра. Поэтому из первого уровня практически невозможно дорасти до третьего-четвертого из-за разницы в специфике задач и требований к кандидатам, так как каждый уровень — это совершенно другая сфера деятельности.

Level 0 (Колл-центр). Основная задача — первичная обработка запроса пользователя: уточнение учетной информации пользователя, краткое описание проблемы. Иногда — выдача пользователю заранее согласованной информации (ответов на часто задаваемые вопросы). В особо сложных случаях — вызов дежурного инженера.

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

Level 1. Сотрудники первого уровня поддержки сортируют запросы, поступающие в почту, отделяют явный мусор (в корзину) от простых вопросов (отвечают сами) и профильных вопросов (отправляют коллегам уровнем выше или в соответствующий отдел), отвечают на телефонные звонки.

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

Карьерно продвинуться можно отсюда либо во второй уровень (техническая экспертиза), либо в менеджмент поддержки (управление), либо в отдел продаж.

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

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

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

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

Из инженеров поддержки второго уровня получаются отличные Technical Pre-Sales Engineers и Product Trainers (если есть хорошие социальные навыки), SLA-менеджеры (если есть склонность к формализации процессов) и изредка — инженеры поддержки третьего уровня (если склонность к поддержке инфраструктуры больше, чем к поддержке непосредственно продукта).

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

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

Инженер техподдержки изучает присланную информацию и, как правило, реагирует по одному из трех сценариев:

• Дает рекомендации по решению проблемы, если проблема известна и уже есть готовое решение или продукт работает должным образом, просто необходимо разъяснение, или нужны изменения в конфигурации аппаратного среды, где установлен продукт;
• Запрашивает дополнительные данные (диагностические приложения, новые логи продукта с заданными параметрами, дополнительные снимки экрана), если информации недостаточно, после чего дает рекомендации по решению проблемы;
• Идентифицирует, что проблема в недостатке продукта, и переводит заявку на команду разработчиков, после чего они изготавливают патч, который тестирует инженер техподдержки и передает пользователю.

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

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

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

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

Level 4. Встречается гораздо реже первых трех. Фактически, это девелоперы, которые в компании давно и досконально знают внутренности продукта или его части, потому что сами его программировали. С клиентами они не контактируют, инциденты не разруливают. В их задачи входит быстро починить критическую проблему в системе, которая уже ушла к пользователям. Их основные источники задач — багтрекеры.

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

Дальше речь пойдет непосредственно о L2/L3/L4 Support Engineers.

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

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

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

Преимущества и недостатки

В своей должности инженеров техподдержки привлекает разнообразие задач, насыщенный ритм работы:

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

«Знания ценятся не столько глубокие, сколько разнообразные, и очень важны определенные личностные качества — дружелюбие, выдержка, настойчивость».

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

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

Также отмечают, что эта должность — один из вариантов относительно легкого входа в отрасль:

«Для меня Support Engineering — это переходной этап от работы системным администратором до разработки ПО. Впрочем, работа достаточно разноплановая, нескучная, задачи могут быть достаточно сложными и интересными. Есть возможность проявить себя».

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

Из недостатков — обилие стрессовых ситуаций, сложности непосредственного карьерного роста:

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

«У других команд есть цель, которую они видят, к которой движутся. У нас же — такой себе День сурка, ведь письма будут всегда и пользователи будут всегда, и вот когда мы поможем вот этой за ней придет другая».

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

Упоминают и проблемы в отношениях с коллегами из других отделов:

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

«Большое кол-во девелоперов, QA и т.п. не являются людьми высокой культуры общения, что нередко бывает серьезным препятствием при обсуждении/эскалации инцидентов или попытках выудить у них информацию, которая саппорту крайне необходима для анализа риквеста. Девелоперы «всегда очень заняты». Нередко люди в других отделах считают саппорт самой низкой ступенью в компании с вытекающим отношением. Если объяснить более детально, люди не всегда понимают важность саппорта и не оказывают треюбущейся саппорту поддержки. Например, приложение может быть описано довольно слабо техническим писателем (и это не редкость), и информацию можно получить только у тех, кто имеет непосредственное отношение к созданию архитектуры или определению функционала. Задача для саппорта часто бывает сложной, и ты чувствуешь себя в качестве «попрошайки».

Как стать и куда двигаться дальше

Для L2 Support Engineers нужны базовые знания Windows/Linux OS, баз данных, общие знания в области системного администрирования, сетей, архитектуры системы. Для L3 — более глубокие знания по вышеупомянутым темам, а также хорошие знания Unix Based OS, навыки скриптования, знание мониторинговых систем.

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

«Работа в саппорте, на мой взгляд, чем-то похожа на „передовую“ на войне. Здесь нужна стойкость, быстрая реакция, конечно же знание своего дела и стрессоустойчивость».

Из личных качеств:

• стрессоустойчивость;
• усидчивость;
• хорошая память;
• обучаемость, умение быстро находить информацию для решения проблем.

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

Возможные карьерные пути инженера техподдержки:

• Дорасти до Support Lead — заниматься более сложными задачами, расширять или же, наоборот, углублять свой опыт, координировать работу отдела;
• Стать проектным менеджером, если хочется развиваться не по техническому, а по управленческому пути. Этому поможет баланс софтскиллов и технического бэкграунда, умение решать конфликты. Если же интересно работать с клиентами, можно рассмотреть позицию Technical Account Manager или бизнес-аналитика;
• Стать системным администратором, если нравится работать с инфраструктурой, занимается настройкой и обеспечением стабильной работы техники;
• Стать DevOps, если интересно писать сценарии и хочется самостоятельно создавать инфраструктуру, поднимать проекты, автоматизировать развертывание;
• Стать DBA, если нравится администрировать и проектировать базы данных, писать SQL запросы;
• Стать QA или разработчиком.

P. S. Благодарю за помощь в написании статьи Елену Логодскую и еще 28 украинских инженеров техподдержки, которые рассказали DOU о своей профессии. Приведенные в статье цитаты взяты из их рассказов.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

От джуна до синьора — уровни квалификации PM-ов

Кто-то скажет, что Junior, Middle и Senior — только штампы, потому что в каждой компании будет свой набор требований к позиции PM-а. Однако такие ярлыки позволяют договориться об ожиданиях для специалиста и компании.

Знать уровни квалификаций полезно всем: новички в профессии поймут, к чему стремиться, РМ-ы с опытом увидят, какие навыки улучшить, чтобы приобрести более высокую позицию, а руководители и product owner-ы найдут в статье критерии подбора PM-ов для разных типов проектов.

Роль PM-а в теории и на практике

В теории, исполняющая организация (компания, которая выполняет проект), назначает РМ-а руководить командой и отвечать за достижение целей проекта, в том числе, за классический проектный треугольник: скоуп, сроки, стоимость и четвертую составляющую — качество.

Это теория, которую мы все знаем. На практике, менеджер проекта выполняет три группы функций:

• Занимается координацией и фасилитацией деятельности команды , помогает команде делать работу, организует ее. Проводит встречи и составляет для них расписание, документирует результаты.
• Руководит командой. Здесь PM уже не просто координатор, а руководитель в прямом смысле этого слова.
• Отвечает за достижение целей: вместе с командой несет ответственность за достижений целей проекта (того самого проектного треугольника).

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

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

Зачем нужны уровни квалификации PM-ов

Не во всех организациях есть разделение на senior, middle и junior, хотя, по факту, обязанности у этих специалистов будут разными.

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

• Размер команды: проект будут делать 3 человека или 100? Очевидно, что для разного размера команд и квалификация менеджера должна быть разной.
• Распределенность команды : не столько по географическим локациям, сколько по организациям. В каких-то проектах участвуют разработчики со стороны клиента, а где-то добавляется подрядчик, да еще и не один. Чем больше участников — тем сложнее проект, и тем опытнее должен быть менеджер.
• Сложность проекта: включая как организационную, так и техническую сложность. Одна задача — сделать интернет-магазин. И совсем другая — разработать приложение, которое управляет медицинским девайсом, например, мозговым нейростимулятором. Понятно, что для разной сложности задач нужны РМ-ы с разным уровнем квалификации.
• Engagement модель: тип контракта, по которому компания работает с клиентом: просто предоставляет специалистов либо делает полный проектный цикл — Time and Materials или Fixed-Price проект.
• Важность и рискованность проекта. Когда компания небольшая и половина сотрудников работает на одного клиента, наверняка, этому клиенту будут искать самого опытного менеджера, потому что высока важность и риски. Если такой клиент уйдет, придется уволить половину сотрудников.

В маленьких организациях ответить на вопрос «Кому поручить проект?» — довольно несложно. Если в организации 3-5 PM-ов, руководство знает всех этих менеджеров в лицо и по имени, знает их навыки.

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

Но что делать, если организация большая? Если в ней работает 20, 30, 50 проектных менеджеров? Для того, чтобы упростить решение вопроса, кому поручить проект, чтобы сгруппировать РМ-ов по их знаниям и опыту, как раз и вводятся уровни квалификации.

Чем отличаются PM-ы разных уровней

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

Опыт

Опыт — это не только о том, сколько лет проработал человек в профессии, но и опыт в типах проектов: в количестве, сложности, размере:

• Длительность и количество: 20 проектов, которые длились по 2 месяца, или 3 проекта, каждый длительностью в 2 года — это очень разный опыт.
• Типы проектов: Outstaffing, когда компания предоставляет людей, но не отвечает за сроки и бюджет, или Fixed-Price проекты, где вся ответственность лежит на организации и, соответственно, на проектном менеджере.
• Размеры команд — управлять командой из 5 человек или из 25 нужно по-разному.

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

Знания

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

Soft skills

Важен стиль менеджмента и то, как человек работает с мотивацией. Стиль управления влияет на тип проекта, который PM-у доверит руководство: где-то подходит демократичный стиль, а где-то нужно, чтобы PM быстро принимал решения в стиле command and control.

Хорошее знание английского — фактически, обязательный навык, чтобы пройти собеседование на роль РМ-а. Если специалист работает в аутсорсинге, и клиенты преимущественно иностранные, то очевидно, что senior вряд ли будет иметь плохой английский. Скорее всего, коммуникативные навыки на английском или немецком (если компания работает с Германией), тоже будут достаточно высоки.

Дальше разберем, какие знания, опыт и навыки нужны для каждого уровня квалификации.

Junior PM

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

Это больше координационная роль и роль фасилитатора:

• Junior PM ведет отчетность работы команды, обычно по шаблонам, утвержденным клиентом либо руководством.
• Хотя джун не отвечает за все ограничения проекта: скоуп, сроки, стоимость, качество, он часто следит за рутинными вещами, например, time-tracking.
• Работает не полностью самостоятельно, а под чутким руководством более опытных коллег.
• Джуны чаще приходят на проект, который кем-то уже начат, и ведут этот проект по более-менее накатанному процессу.

Middle PM

Если джуниор — это сотрудник, который только начинает свой профессиональный путь, то миддл уже поработал РМ-ом 2-3 года, и может самостоятельно вести стандартные проекты с командой до 25 человек, без частого вмешательства руководителя.

Middle PM берет на себя больше ответственности:

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

S enior PM

Это сотрудник, который проработал в своей профессии 5 лет и больше. Он ведет большие и сложные проекты. Кроме этого, PM уровня senior сталкивается c вещами, которые не входят в обязанности чисто проектного менеджера:

• Senior может собеседовать и принимать на работу других РМ-ов.
• Участвует в пресейле на том этапе, когда компания еще не подписала контракт с клиентом, но уже нужно делать оценку проекта.
• Может проконсультировать клиента, какой тип контракта или какой процесс подходит больше, — скрам, канбан или проект очень большой и нужен, например, scaled agile framework.
• Работает и с текстами контрактов, конечно, не с юридической частью, а с тем, чтобы прописать в контракт корректные предположения и риски, или процедуру приемки проекта.
• Отвечает за финансы не одного, а нескольких проектов и программ.
• Может руководить программами и портфелями проектов.
• Имеет развитые навыки коммуникации, потому что синьору нужно не только находить правильные решения, а еще и вести переговоры с заказчиками и командой в сложных, порой стрессовых ситуациях.

Куда расти дальше

Давайте посмотрим, куда может вырасти синьор, поработав какое-то время на своей позиции. Какой карьерный путь возможен для senior PM:

• Менеджер программы или портфеля — управляет несколькими связанными между собой проектами. При этом, управляет не лично, а через подчиненных — других PM-ов, которые занимаются непосредственным управлением проектами. А задача програм-менеджера состоит в том, чтобы спланировать программу, учесть все зависимости при составлении плана и поставить всю программу в целом, а не только какой-то отдельный проект.
• Руководитель проектного офиса (РМО head) — через роль програм-менеджера либо сразу, в зависимости от размеров организации. В разных организациях проектные офисы выглядят по-разному: где-то это просто центр компетенции, где сидят опытные РМ-ы, разрабатывают процессы и дают советы, как быть в той или иной ситуации. В других — проектный офис отвечает за delivery (чтобы все проекты в компании шли хорошо). Поэтому, когда вы подойдете к этому этапу карьеры, нужно будет узнать, какой именно проектный офис в компании.
• Вырасти из PMO head в руководители всего delivery илиChief Delivery Officer (в аутсорсинге эта позиция часто отвечает уже не только за проектный менеджмент, но и за все остальные аспекты производства ПО — инжиниринг, тестирование, DevOps, консалтинг и т.д.).
• Аккаунт менеджер — отвечает за бизнес-сторону взаимоотношений с клиентом: следит за тем, чтобы все сервисы, предоставляемые клиенту, шли хорошо, смотрит, какие сервисы можно допродать клиенту, и больше заработать. Аккаунт менеджер, обычно, будет следующей после PM-а точкой эскалации: если возникают какие-то проблемы, клиент обращается именно к аккаунт менеджеру.
• Синьор может стать консультантом , и консультировать другие команды и компании по процессам разработки, кризисным ситуациям и т.д.

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

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

Александр Крючков

17 лет опыта в IT, Senior PM, Program Manager, Head of Presale Сейчас работает Head of Presale в Avenga, до этого был Program Manager в Ciklum. 17 лет опыта в IT, 14 из которых управлял проектами и программами численностью до 120 человек. Специализируется на работе в аутсорсинге разработки программного обеспечения. Спикер и ментор курса Supreme PM.