DevOps-инженер управляет инфраструктурой: настраивает серверы, CI/CD-пайплайны, мониторинг, логирование. Автоматизация развертывания сокращает время вывода новых функций в продакшн с дней до часов, снижает риск человеческих ошибок при релизах. Если разработчики строят здание, девопсер прокладывает к нему дороги, подключает электричество, водопровод. При этом DevOps-инженера может и не быть, потому что базовую инфраструктуру разработки способен настроить сам разработчик. Эта роль опциональна, с возможностью привлечения на частичную загрузку.
Дизайн и проектирование
Бизнес-системный аналитик (Business/System Analyst) описывает, как система должна работать. Разбирается в предметной области, собирает бизнес-требования, отвечая на вопрос «что нужно сделать», превращает их в описания функциональных и нефункциональных требований, то есть описывает «как это должно работать». Разрабатывает спецификации, описывает API, продумывает интеграции между сервисами, рисует диаграммы. Это переводчик между двумя мирами: бизнес говорит про «увеличить конверсию», разработчики — про «добавить эндпоинт». Аналитик превращает первое во второе так, чтобы обе стороны понимали друг друга.
Дизайнер (UI/UX) проектирует пользовательский интерфейс и опыт взаимодействия с продуктом. UI отвечает за визуальную часть: цвета, типографику, расположение элементов. UX — за логику взаимодействия: насколько легко пользователю достичь своей цели. Хороший UX позволяет пользователю не замечать интерфейс. Как с удобной обувью: если вы о ней не думаете, значит, она подобрана правильно.
Архитектор (Architect)продумывает, как будет устроена система: из каких частей она состоит и как они общаются друг с другом. Принимает ключевые технические решения по выбору используемых технологий, подходов, чтобы продукт был надежным и его можно было спокойно развивать.
Управление
Владелец продукта (Product Owner/Manager)отвечает за актуальность продукта: зачем команда его создает, какую бизнес-ценность должен принести результат. Формирует приоритеты исходя из пользы для бизнеса, задает направление, переводит стратегию в понятные цели для разработчиков. Его зона ответственности: смысл и результат.
Проектный менеджер (Project Manager) отвечает за операционную часть, тактику: соблюдение регламентов, сроков, трекинг времени, своевременное обновление статусов задач, эскалация проблем, разбор факапов. Обеспечивает передачу проектных знаний и контекста между участниками. Его задача — сокращать издержки на коммуникациях, повышать эффективность, слаженность работы команды и стейкхолдеров.
Эксперт предметной области (Subject Matter Expert) знает о бизнесе и всех его нюансах. Это не IT-специалист, у него своя основная работа, но без его участия команда неизбежно начинает гадать или додумывать. Важно закладывать участие такого человека в план заранее: эксперта придется регулярно отвлекать, поэтому на проекте обычно нужен выделенный ресурс хотя бы около 5 часов в неделю на вопросы и разъяснения.
Возникает логичный вопрос: можно ли вообще отдать на аутсорс управленческие роли? Да, но не все. Например, внешним подрядчиком нельзя заменить владельца продукта: только внутри компании он точно знает цели бизнеса и приоритеты. Так же не получится привлечь внешнего эксперта предметной области — его может дать только заказчик, потому что именно он лучше всех понимает процессы, правила своей компании. К таким людям на проекте всегда нужен регулярный доступ, иначе команда может сбиться с курса.