«Чтобы рельсы сошлись в одной точке»: 8 ключевых ролей в команде разработки

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

Что это за ключевые роли в команде разработки, какие обязанности они предполагают и почему их не стоит игнорировать — разобрались с Николаем Клестовым, Co-Founder и CTO в ITExpert. У него 6+ лет опыта в подборе персонала на менеджерские позиции в топовые IT-компании Украины. 

Николай консультировал и помогал закрывать кандидатов на руководящие позиции для таких клиентов, как Нафтогаз, Райффайзен Банк, Parimatch, а также в другие продуктовые и аутсорсинговые компании.

Команда разработчиков проекта VS группа с общими интересами: в чем разница

По словам CTO ITExpert, в идеальном мире группа программистов с общими интересами могла бы разработать продукт самостоятельно. Это постулирует Scrum и это звучит логично вне зависимости от методологии. Но мы не живем в идеальном мире, поэтому нужны менеджерские роли, которые помогут мониторить процессы и направлять техническую команду.

Роли в IT-проекте VS должности: есть ли отличие

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

Основные роли в команде разработчиков

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

Обязанности разработчика

Роль разработчика — обязательная в IT-команде, но количество и потребность в экспертизе девелоперов зависят от: 

• сложности решения (чем она выше — тем больше специалистов уровня Middle+ потребуется);
• стека технологий.

К примеру, простую программу или сервис может разработать один девелопер на кроссплатформенных фреймворках вроде Flutter или React Native. Если команда создает продукт для iOS и Android — нужно привлекать специалистов с соответствующими скиллами: разработчики SWIFT/Objective-C, Java/Kotlin и другие. Для создания бэкенда (внутреннего устройства) продукта нужны backend-девелоперы — например, Node.js, Python или .NET разработчики.

Обязанности QA (Manual и Automation тестировщика)

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

QA Automation инженер отличается от Manual (ручного) тестировщика тем, что последний не пишет автотесты. Ему нужно повторять тесты вручную для определенного функционала или UI, который может быть «слабым звеном». Кроме того, QA Manual Engineer не может проверить некоторые свойства продукта: сделать нагрузочное тестирование, чтобы понять, выдержит ли он наплыв миллиона пользователей. 

QA Automation специалист должен разбираться в особенностях разработки, уметь программировать, а также:

• владеть базовыми знаниями технологий и языков;
• уметь работать с системой контроля версий (Git).

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

Обязанности UI/UX дизайнера

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

Если команда также выводит продукт на рынок или масштабирует его, в команде могут появиться также такие роли:

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

Главный челлендж в работе дизайнера — сделать так, чтобы продукт понравился и заказчику, и пользователям. UI/UX дизайнер должен уметь исследовать психологию поведения пользователей, а также применять результаты тестирования в дизайне: строить CJM, выделять инсайты после jobs-to-be-done интервью и формировать персоны. В список обязанностей также входит проектирование деталей дизайна — от нотификаций до ошибок и звуков.

Кроме технических навыков у UI/UX дизайнера должны быть критическое мышление, вкус и насмотренность. А еще — умение сотрудничать. Дизайнер может не знать всех технических или бизнес аспектов продукта. Чтобы дизайн получился хорошим, нужны знания и экспертиза всей команды.

Роли в координации команды: Project Manager и Scrum Master

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

Обязанности Project Manager

Один бэклог, 100 тасков и семь разработчиков — чтобы избежать пожара в таком режиме, Project-менеджер определяет, какая методология подойдет проекту, как приоритизировать задачи и помочь команде добиться нужного результата. Он несет ответственность за проект, команду и риски. Важно: в классическом скраме нет позиции Project Manager.

Выбор правильной методологии координации команды (например, Scrum, Kanban или Waterfall) — половина успеха проекта и работы специалиста. Оставшиеся 50% — настройка автономной работы в команде, налаживание коммуникации между стейкхолдерами, планирование изменений и сроков с помощью методологий PMI, PMBOK или PRINCE2.

А что еще? PM в команде разработки:

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

Основные риски в project-менеджменте — сорвать сроки, не вложиться в бюджет и не набрать нужных специалистов на проект. Например, кандидаты могут оказаться дороже, чем планировалось, специалисты уйдут с проекта в процессе работы или их «захантит»‎ конкурент. Тогда продукт не выйдет в релиз.

В project-менеджменте главное — soft skills: эмоциональный интеллект, умение слушать, общаться и решать конфликты. Около 80% работы PM составляет коммуникация. Хард-скиллы и технический бэкграунд тоже важны, но PM необязательно быть «самым знающим человеком» в команде.

Еще проджекту нужно владеть скиллами, которые входят в PMI talent triangle: 

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

Обязанности Scrum Master

Scrum — один из самых популярных фреймворков методологии Agile, которую используют крупные компании. Гибкие методологии применяют Amazon, Netflix, Etsy и Spotify.

В Agile-командах, которые работают по скраму, часто есть отдельная роль — Scrum-мастер. РМ в таких коллективах зачастую отвечают за продукт и рабочие процессы (или отсутствует), а SM — за наличие Scrum-ритуалов и артефактов: стендапы, дейли и фасилитации. 

Выделять эту роль full-time необязательно, даже если команда работает по фреймворку. Например, в компании MacPaw обязанности скрам-мастера «шерят» среди команды. Кроме того, не все компании четко следуют артефактам фреймворка, в основном его настраивают его под себя — главное, чтобы был результат.

Скрам-мастер:

• руководит командами Scrum и Scrumban с помощью методологии Agile и практики Scrum или Kanban;
• участвует в командном планировании, расстановке приоритетов, делит объем задач на спринты;
• организовывает покер-планирование (Planning Poker, Scrum Poker) — технику оценки задач для Agile-команд до 50 человек;
• помогает проводить митинги: спринт-планирование, дейли, демо, ретро;
• гибко реагирует на изменения: без потери качества и срыва дедлайнов.

Для Scrum-мастера важно знание Agile-фреймворков, инженерных и продуктовых практик. А еще — системное мышление, коучинг, навыки планирования, управления конфликтами и умение давать обратную связь.

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

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

Роли в бизнес-менеджменте: Product Manager, Product Owner и Business Analyst

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

Обязанности Product Manager

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

Product-менеджер — роль на стыке технологий, дизайна и People Management, поэтому список компетенций для нее длинный. Главные soft- и hard-скиллы специалиста:

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

Основная обязанность продакта — не генерация «фичей», а решение проблем (болей) пользователя. Продукт, который не решает проблему — бесполезный. Более того, одного неправильного решения достаточно, чтобы оттолкнуть от проекта большую часть ЦА. Разберем этот аспект на примере McDonald’s. 

Сеть заведений фастфуда запустила специальную функцию: посетители могли сделать бургер по своему вкусу. Можно было убрать или добавить ингредиент и соус. Результаты показали: клиенты чаще всего добавляют в традиционный Big Tasty бекон. 

Тогда в McDonald’s решили выпустить новый продукт — «Биг Тейсти Бекон» — вдобавок к существующему бургеру без бекона. Итог: переделывать концепцию основного продукта рискованно, гораздо эффективнее запустить дополнительный продукт. Так вы не отпугнете потребителей — и даже привлечете новых.   

Обязанности Product Owner

В Agile-фреймворке Scrum есть отдельная позиция владельца продукта. У роли много общего с product-менеджером: если ввести запрос Product Owner на платформах вакансий, в выдаче частично окажутся результаты для продакт-менеджера — и наоборот.

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

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

Среди обязанностей Product-оунера: 

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

Необходимость в Product Owner зачастую зависит от того, внедрен ли в команде Scrum. Например, Amazon, Spotify и Atlassian не используют в работе этот фреймворк, и вакансий для PO у них нет — они открыты для продакт-менеджеров. 

Если компания работает над большим продуктом и в процессе разработки задействовано много команд, Продакт-оунер будет жирным плюсом: он «разгрузит» продакт-менеджера. В таких командах одновременно могут работать и PO, и PM.

Обязанности Business Analyst

Если вы хоть раз просматривали вакансии Business Analyst на job бордах, то точно чувствовали недоумение. Дело в том, что есть два направления бизнес-аналитиков (IT и не-IT), которые не пересекаются. Поговорим о каждом.

В не IT-сферах Business Analyst выявляет проблемы и предлагает data-driven решения для развития продукта. В этом случае, когда бизнес испытывает проблемы, он «идет» к бизнес-аналитику. А что делает аналитик? Ищет бизнес-потребности, формирует требования и координирует изменения. Бизнес-аналитик — незаменимый человек в компании.

Четыре стадии работы BA — период стабильной работы компании -> период перед изменениями -> изменения -> период после изменений. Аналитик собирает и исследует данные, изучает продуктовые метрики (в привлечении, удержании, вовлеченности юзеров), отслеживает влияние изменений в продукте на поведение пользователей. 

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

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

• составляет карту текущих технических процессов;
• участвует в сессиях пользовательского тестирования;
• пишет техническую документацию: User Story, видение, SRS, примечания к выпуску, руководства пользователя;
• знакомит с декомпозицией и моделированием функциональности (UML, BPMN).

Для этой роли важен опыт работы с блок-схемами (MS Visio, Lucidchart, draw.io), инструментами UX (Balsamiq), User Story, Use Cases, UML- и BPMN-диаграммами.

Чаще всего Business Analyst растет в Product Owner. Сильных специалистов можно встретить в Outsource и Outstaff компаниях, где есть больше практики взаимодействия с разными клиентами. В продуктовых компаниях часто нет бизнес-аналитика или эту роль выполняет человек на другой должности. Это связано с тем, что клиент продукта — конечный пользователь, это немного упрощает процесс.

Окей, Google: как понять, кто мне нужен, а без кого можно обойтись

Не существует единой оптимальной структуры команды разработчиков — в одном случае с задачей справятся специалисты, которых мы перечислили в статье, в другой — понадобится еще специалист по AI и машинному обучению, 3D-художник или UX-копирайтер.

Сначала формируются цели — к примеру, специалисты создают MVP (минимально жизнеспособный продукт). Затем можно определять требования к команде разработчиков: составу, компетенциям и обязанностям.