Чем занимаются разные специалисты на IT-проектах: роли, задачи и компетенции

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

Владислав Соломонов:

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

Presale

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

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

Для этого account-менеджеру нужно обладать следующими ключевыми компетенциями:

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

Account-менеджер – это профессиональный переговорщик, специалист в области бизнеса и финансов с опытом в IT.  

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

Discovery

Задача UX-команды состоит в том, чтобы спроектировать «опыт» пользователя – не просто работы с продуктом, но и взаимодействия с брендом клиента. В других случаях на первом этапе UX-команду могут и не приглашать. Но если мы говорим о разработке готовых пользовательских решений, то интерфейс нужен и важен. Конечно, интерфейс может быть продуман и самим заказчиком, но эффективнее, если дизайн спроектирует команда того исполнителя, который будет осуществлять разработку приложения.

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

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

Очень важно, чтобы на этапе Discovery к работе подключились бизнес-аналитик и архитектор. Совместно с UX-командой бизнес-аналитик прорабатывает user stories – короткие формулировки намерений, которые детально описывают, что система должна делать для пользователя. Бизнес-аналитик «копает» глубже, чем UX-специалисты: он «копает» в те решения, которые визуально не отображаются в приложении. Например, при каких условиях пользователю отправляются письма из приложения? Кто имеет право редактировать информацию о косметическом средстве, если, к примеру, его цена должна измениться в «Чёрную пятницу»? А должен ли быть таймер, который возвратит цену к её прежнему значению? От того, как выполнит работу бизнес-аналитик, во многом зависит скорость всего процесса разработки. 

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

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

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

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

Итак, UX-команда представила дизайн, его согласовали с клиентом. Бизнес-аналитик разработал user stories, а архитекторы спроектировали архитектуру приложения. Совместно бизнес-аналитик и архитекторы определили необходимые работы, их объем, критерии и т.д. Всё это ляжет в основу готового плана. Итоговый план возьмёт в работу delivery-менеджер.

Delivery-менеджер несёт полную ответственность за выполнение проекта. Основная задача delivery-менеджера – обеспечить реализацию проекта таким образом, чтобы результат полностью совпадал с ожиданиями заказчика. Delivery-менеджер руководит процессами планирования и реализации проекта, включая расстановку приоритетов для различных видов деятельности, отслеживание достигнутого прогресса, поддержку документации, создание Risk и Change Management процессов и следование им. На данный момент мы находимся только на фазе Discovery, но delivery-менеджер уже должен понимать, что нужно сделать сейчас, чтобы в конце проекта ждал успех.

Delivery-менеджер должен установить структуру проекта и убедиться, что все участники проекта понимают цели и свои обязанности. Кроме того, delivery-менеджер совместно с account-менеджером общается с заказчиком, предлагает идеи по оптимизации разрабатываемого продукта и бизнеса заказчика в целом.

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

Staffing

Фаза Discovery закончилась. Настало время формировать команды. Архитектор и delivery-менеджер приглашают на проект DevOps-инженера, performance-аналитика и лидов команд: по frontend и backend, по функциональному и автоматизированному тестированию – всего четыре тимлида. Тимлиды с участием архитектора и delivery-менеджера формируют себе команды.

Development

Начинается фаза разработки. И у delivery-менеджера, особенно если у него есть другие проекты, возникает дефицит времени. Поэтому ему на помощь приходит project-менеджер (по совместительству – scrum-мастер), который отвечает за внутренние и внешние коммуникации, выстраивает процессы и оптимизирует scrum. В частности, project-менеджер должен проводить регулярные планёрки, а также сообщать статус проекта всем стейкхолдерам. Задача project-менеджера – выстроить процессы и ежедневную работу команды так, чтобы ничего не мешало разработке и реализации проекта в заданных параметрах бюджета/времени/качества. Так как техническая сторона вопроса остаётся за delivery-менеджером, project-менеджер может не иметь технического образования, но зато должен в целом понимать процесс IT-разработки, иметь опыт ведения проектов и отличные коммуникативные навыки.

Задача DevOps-инженера на проекте – создать условия для непрерывной разработки: установить CI/CD, наладить работу инфраструктуры, помогать обеспечивать параметры качества. Таким образом, DevOps-инженер умеет работать с CI/CD-процессами, инфраструктурой (облака, серверы во внутренней сети), умеет программировать скрипты для обеспечения параметров качества.

Функциональные тестировщики, которые призваны тестировать часть frontend, разбираются с результатами работы UX-команды и бизнес-аналитика, а также пишут тест-план и тест-кейсы. Чтобы выполнить свою работу на высоком уровне, функциональным тестировщикам нельзя обойтись без таких качеств, как внимание к деталям и перфекционизм. Тестировщики-автоматизаторы, при условии правильно построенной архитектуры, могут писать автоматизированные тесты с первого дня разработки. Они занимаются покрытием тестами всего продукта. Тестировщикам-автоматизаторам так же присущи внимание к деталям и стремление к совершенству, однако немаловажным для них является и знание языка программирования, например, Java или C#.

Всё это время разработчики пишут код. Frontend-разработчики обычно пишут на JavaScript, Swift Objective-C для iOS, Kotlin или Java for Android, а backend-разработчики – на Java, C#, Python и т.д. Для того, чтобы общими усилиями получить качественный код, программистам нужны не только хорошие технические навыки, но и умение работать в команде.

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

Первый релиз на сервере разработки

В самом начале разработчики пишут код на своих локальных машинах. Но в какой-то момент поднимается интеграционный сервер, куда выкатывается 0.1 версия продукта. Это не полноценное приложение, а MVP (Minimum Viable Product) – «каркас» приложения. Он нужен, чтобы соединить локальные разработки в единое целое (проверить работу CI/CD) и провести первые общие тесты. 

Итак, мы выпустили версию 0.1 продукта и продолжаем наращивать функционал. В какой-то момент выкатываем функционал на UAT (User Acceptance Testing) сервере, где команда со стороны клиента тестирует почти готовый продукт. Со стороны клиента также может быть привлечена security-команда, которая сканирует приложение на наличие угроз безопасности. И если такие угрозы найдутся, разработчики должны их устранить.

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

Со временем команда начинает уменьшаться, на стадии UAT нужны уже все. На проекте остаются лиды с frontend и backend, тестировщик, delivery-менеджер и project-менеджер, один UX-дизайнер и частично – бизнес-аналитик. Оставшиеся члены команды дорабатывают детали продукта и согласовывают их с заказчиком.

Handover

Handover – это процесс передачи знаний и ответственности от DevOps-инженера исполнителя к DevOps-инженеру клиента или SRE-команде (Site Reliability Engineers), которые будут отвечать за стабильность production.

Важно, чтобы после Handover исполнитель в лице команды Application Support Engineers продолжил работу по поддержке продукта. Application Support Engineers – это специалисты, обладающие отличными навыками коммуникации для того, чтобы общаться с пользователями и помогать им в решении возможных проблем. Эти специалисты также обладают навыками DevOps по поддержке работы инфраструктуры. Кроме того, они способны ставить задачи команде разработчиков, которые могут подключаться для решения технических вопросов, требующих изменения в коде.

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

Когда проект переходит в стадию поддержки, начинается новая интересная жизнь продукта: добавляются такие роли, как service delivery менеджер, release-менеджер и другие. Они отвечают за работу и улучшение продукта, когда он уже используется. Но это уже другая история.

Владислав Соломонов описал процесс разработки лишь в общих чертах, однако и из общего описания ясно, что IT-проект – это сложное единство процессов, где важна роль каждого. И начинающие специалисты без опыта работы могут обучиться и попробовать себя в роли программиста, тестировщика, бизнес-аналитика или UX-дизайнера – ими можно стать «с нуля». А для того, чтобы занять роль более высокого уровня, например, лида, архитектора или project-менеджера, нужно много учиться и обладать большим опытом.