Ролевая модель и рынок в корпоративном ИТ

Всем привет. Давненько ничего не писал. Вот, решил структурировать текущие представления о том, как устроен корпоративный ИТ-рынок с точки зрения ролей внутри ИТ-интеграторов.

Описал основные роли в ИТ-проектах. А затем посмотрел, как обстоят дела в корпоративном ИТ на примере самой популярной платформы в РФ - 1С.

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

Референсная область: 1С. потому что а) популярно; б) известна мне лучше остальных. В остальных областях могут быть небольшие отличия, но спроецировать можно. Например, где-то есть UX/UI, побольше релиз-менджеров. Но чем дальше от производства - тем больше роли пересекаются по задачам и количеству специалистов.

Пост может быть полезен для:

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

Ограничения:

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

Обобщенная ролевая модель

Разработчик

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

Одна из самых поулярных вакансий на рынке. Стать разработчиком просто (с точки зрения доступности материалов) - начиная от курсов, заканчивая оплачиваемыми стажировками в фирмах-франчайзи 1С.

Аналитик

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

Занимается, в том числе, подготовкой проектных решений, постановкой\приемкой задач разработки, демонстрациями, пресейлами.

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

Вход в профессию также неплохо изучен. Как правило, аналитик получается:

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

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

Плохо: думать, что аналитик только анализирует

Хорошо: думать, что аналитик анализирует, а затем создает артефакты в виде проектных решений, постановок, демо и тд.

Консультант

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

Консультациями пользователей
Отработкой запросов в таск-трекере (1-2 линия поддержки)
Проводит первичные интверью

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

Тестировщик

Сами видите, что запроса на рынке на такую позицию почти нет. В идеале, это отдельный человек, который тестирует разработку, как правило вручную. Потому что не вручную - это уже QA.

На практике, тестируют разрабы, аналитики. Иногда - пишутся автотесты.

Методолог

Не самая распространенная роль. Но тем не менее, она есть. По ощущениям, методологи чаще всего требуются:

При разработке продуктов (например, компания пишет свое решение для операционного лизинга, нужен методолог)
На больших корпоративных проектах, где есть время и деньги на выделение роли метолога, как и на полноценную разработку регламентов и описание процессов

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

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

Плохо: применять методолога как аналитка

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

Откуда брать: из аналитиков, из экспертов в предметной области, из консалтеров (не путать с Консультант)

Архитектор

На практике - либо самый крутой разраб, либо самый крутой аналитик, который отвечает за содержание проекта.

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

Технический архитектор отвечает за технологию и вообще всю разработку. Верифицирует проектные решения, готовит те проектные решения, где описаны технические аспекты. С недавних пор - еще и за CI/CD контур (это про правильные обновления и тестирование)

Функциональный архитектор - тот, кто отвечает за

Итоговое содержание системы
За технологию и вообще производство аналитического блока

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

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

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

Возможные названия из этого раздела:

РП, архитектор, техлид, тимлид, технический архитектор, функциональный архитектор, главный аналитик, главный разработчик

Откуда расти: из произвоства. Разрабы, аналитики.

Руководитель проекта

В идеале - РП отвечает за итоговый результат проекта. А именно:

Содержание
Бюджет
Сроки
Удовлетворенность клиента

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

Так что ответить на вопрос Кто такой хороший РП сложно - слишком разные требования в разных местах. Но на мой взгляд, хорший РП точно обязан:

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

Откуда брать:

Из аналитиков, растить с нуля. Изредка - из разрабов, но те как правило проходят сперва метаморфозу в аналитиков.

Product manager

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

Пока что по ощущениям, запрос на рынке на такую позицию отсутствует. По крайней мере, в 1С. Несмотря на то, что деятельность по созданию продуктов в той же 1С - осуществляется активно и регулярно.

Откуда брать:

Из аналитиков, растить с нуля. Изредка - из разрабов, но те как правило проходят сперва метаморфозу в аналитиков. Ну или растить.

Руководитель направления

Уровень мидл-менджмента. Направление может определяться продуктом, предметной отраслью, составом подчиненных

Главное отличие от менеджера проекта - деятельность носит процессный характер.

Как правило, проекты реализуются в рамках определенного направления. То есть, когда запускается проект внедрения 1С:УХ, руководитель направления выделяет ресурсы под проект. При этом, РП может быть как внутри направления, так и отдельно, в рамках проектного офиса.

Нередко руководитель направления выполняет роль куратора, BDM, аккаунта.

Что может быть в KPI:

Выручка по направлению
Маржинальность проектов
Объем продаж
Количество сертификатов
Количество сотрудников
Рост квалификации
Количество запущенных проектов

Откуда брать:

На усмотрение руководства. Как правило, это так или иначе бывшие РП.

Руководитель отдела

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

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

Задачи те же, но как мне кажется, фокус может быть размыт чуть больше.

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

Не будем забывать про РО инхаус. Как правило, это отдел внутри ИТ-департамента, к которому приписаны разработчики, аналитики, менеджеры (реже).

Откуда брать:

На усмотрение руководства. Как правило, это так или иначе бывшие РП, разработчики, аналитики.

Business development manager

Пошли новые термины.

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

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

Важнно помнить, что BDM в не-ИТ аутсорсе решает иные задачи - вывод на рынок, развитие бизнеса в целом и тд.

BDM:

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

Вот небольшая схема о месте BDM (по версии имени меня)

Откуда брать:

РП, Продакты.

Аккаунт

Коротко - печень на ножках.

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

Аккаунт не участвует во внедрении, принимает участие в продаже. Генерирует лиды по клиенту.

Аккаунт активно вмешивается в проект, если:

Наносится ущерб долгосрочным отношениям
Наносится ущерб его KPI по клиенту
Нужна помощь с выходом на ЛПР высокого уровня

Главное качество аккаунта - уметь дружить и иметь связи. Хорошие аккаунты ездят на очень хороших машинах и подчиняются непосредственно CEO.

В 1С, например, главный аккаунт чаще всего - это директор франчайзи.

Откуда брать:

Менеджеры по продажам, BDM, люди со связями в отрасли - бывшие CEO, CIO

Менеджер по продажам

Может быть двух типов:

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

KPI МП могут быть такими:

Объем продаж
Выручка
Оплаты (cash flow)
Какие-то Kpi по холодным продажам

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

Оплаты (cash flow)
Какие-то Kpi по холодным продажам

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

Откуда брать:

чаще всего с hh.ru

QA

Если коротко и обобщенно - человек, который умеет наладить и проводить автоматизированное тестирование. Редкий зверь пока что. Но девопс развивается, а с ним и инструменты автоматизированного тестирования. С точки зрения физики, смысл в QA появляется в продуктовой разработке.

Откуда брать:

Растить из разрабочтиков или хантить с рынка.

Devops

Здесь как правило ожидается специалист, который может развернуть поддерживать CI/CD контур.

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

Стоят дорого, требуется далеко не везде. Перспективная область профессионального развития.

Откуда брать:

Растить из разрабочтиков или хантить с рынка.

Релиз-менеджер 1С

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

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

Так и в применении CI контура для автоматических деплоев.

Откуда брать:

Растить из аналитиков, разработчиков, хантить с рынка.

Специалист 1С

Пережиток прошлого. Специалист на все руки. Часто требуется в инхаус. Огорчает большое количество вакансий на эту тему.

Специалист-мультиинструменталист. И пишет код, и тестирует, и ругается с пользователеями, и управляет проектом.

Работа в такой роли приводит к выгоранию, клинической депрессии и уходу в геймдев.

Откуда брать:

Если вам нужны такие люди - лучше задумайтесь над большими изменениями в компании.

UX 1С

Дизайнер пользовательского опыта. Крайне редко требуется при разработке единичных продуктов на платформе 1С. Увеличивает стоимость продукта. Применение в 1С ограничено наличием автоматически генерируемых форм.

Качество интерфейсов контролируется адекватностью проектной команды и бизнес-заказчика.

Откуда брать:

Вероятнее всего, с рынка.