Должности при разработке ПО: роли и обязанности от Product Owner до DevOps

Зачем понимать роли в команде разработки

Каждый, кто хоть раз участвовал в IT-проекте, слышал термины Product Owner, Scrum Master, Tech Lead, DevOps. Но что они означают на практике? Кто за что отвечает и как эти роли взаимодействуют?

Понимание ролей критически важно по трём причинам:

• Новичок в команде быстрее встроится в процесс, если знает к кому обращаться с какими вопросами

• Менеджер сможет правильно сформировать команду и распределить ответственность

• Разработчик поймёт контекст решений — почему Product Owner поставил задачу именно так, почему Tech Lead выбрал именно эту архитектуру

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

Продуктовые роли: что делать?

Продуктовые роли отвечают на вопрос «что делать?». Они определяют направление, приоритеты и ценность продукта.

Product Owner (PO)

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

Ключевые обязанности:

Пример работы PO на практике:

# Упрощённая модель приоритизации бэклога
# PO оценивает задачи по матрице ценность / сложность

tasks = [
    {"name": "Авторизация через OAuth", "value": 9, "effort": 7},
    {"name": "Тёмная тема", "value": 3, "effort": 4},
    {"name": "Экспорт в PDF", "value": 8, "effort": 5},
    {"name": "Мультиязычность", "value": 6, "effort": 9},
]

# Рanking по соотношению ценность/усилия
for task in sorted(tasks, key=lambda t: t["value"] / t["effort"], reverse=True):
    ratio = task["value"] / task["effort"]
    print(f"{task['name']:30s}  ratio={ratio:.2f}  (value={task['value']}, effort={task['effort']})")

Результат показывает, что «Экспорт в PDF» имеет лучшее соотношение — высокая ценность при умеренных усилиях. Именно такой анализ PO проводит регулярно.

Частая ошибка: PO пытается управлять сроками и людьми. Это задача менеджера, а не Product Owner. PO управляет бэклогом, а не людьми.

Product Manager (PM)

Product Manager работает на более высоком уровне. Если PO — тактик (что делать в этом спринте), то PM — стратег (что делать в этом квартале и почему).

Обязанности PM:

• Анализ рынка и конкурентов

• Определение целевой аудитории и сегментов

• Монетизация и бизнес-модель

• Roadmap на 6-12 месяцев вперёд

• Метрики продукта (retention, churn, LTV)

Stakeholder (Заказчик)

Stakeholder — владелец бизнеса или ключевой заказчик. Обычно не участвует в ежедневной работе, но:

• Утверждает бюджет и стратегические решения

• Даёт финальное одобрение на запуск

• Формулирует требования на высоком уровне

Разработочные роли: как делать?

Разработочные роли отвечают на вопрос «как делать?». Они превращают требования в работающий продукт.

Tech Lead

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

Обязанности Tech Lead:

Пример: решение Tech Lead по выбору БД

# Сравнение баз данных для проекта — упрощённый чек-лист Tech Lead
import json

def evaluate_database(name, criteria):
    """
    criteria: dict с баллами 1-10 по ключевым параметрам
    """
    weights = {
        "performance": 0.3,
        "scalability": 0.25,
        "team_experience": 0.2,
        "ecosystem": 0.15,
        "cost": 0.1,
    }
    score = sum(criteria[k] * w for k, w in weights.items())
    return score

databases = [
    ("PostgreSQL", {"performance": 8, "scalability": 7, "team_experience": 9, "ecosystem": 9, "cost": 9}),
    ("MongoDB",    {"performance": 7, "scalability": 9, "team_experience": 5, "ecosystem": 7, "cost": 7}),
    ("SQLite",     {"performance": 6, "scalability": 2, "team_experience": 8, "ecosystem": 6, "cost": 10}),
]

results = [(name, evaluate_database(name, c)) for name, c in databases]
for name, score in sorted(results, key=lambda x: x[1], reverse=True):
    print(f"{name:15s}  score={score:.2f}")

В данном примере PostgreSQL выигрывает за счёт высокого опыта команды и богатой экосистемы — типичный выбор Tech Lead для enterprise-проекта.

Software Engineer (Developer)

Разработчик — основная рабочая сила команды. Делится по специализациям:

• Backend — серверная логика, API, базы данных

• Frontend — интерфейс, клиентская логика, UX-реализация

• Fullstack — и то, и другое

Типичный день разработчика:

# Упрощённый workflow разработчика за день
git pull origin main           # обновить код
git checkout -b feature/auth   # создать ветку фичи
# ... 3 часа работы ...
pytest tests/test_auth.py      # запустить тесты
git add . && git commit -m "feat: add OAuth login"
git push origin feature/auth   # запушить ветку
# создать Pull Request, дождаться code review

QA Engineer (Tester)

Инженер по тестированию обеспечивает качество продукта. В современных командах QA — это не просто «кликать кнопки», а строить систему тестирования.

Уровни тестирования:

Пример автоматизации тестов на pytest:

import pytest
from fastapi.testclient import TestClient
from main import app

client = TestClient(app)

def test_login_success():
    response = client.post("/api/login", json={
        "username": "test@example.com",
        "password": "correct_password"
    })
    assert response.status_code == 200
    assert "token" in response.json()

def test_login_wrong_password():
    response = client.post("/api/login", json={
        "username": "test@example.com",
        "password": "wrong_password"
    })
    assert response.status_code == 401

DevOps Engineer

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

Ключевые задачи DevOps:

Пример CI/CD пайплайна (GitHub Actions):

name: CI/CD Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run tests
        run: pytest --cov=app tests/
      - name: Lint
        run: ruff check app/

  deploy:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to production
        run: |
          docker build -t myapp:latest .
          docker push myapp:latest

SRE (Site Reliability Engineer)

SRE — это DevOps с фокусом на надёжность. Если DevOps строит пайплайны, то SRE гарантирует что система не падает.

Ключевые концепции SRE:

• SLA (Service Level Agreement) — договорённости о доступности

• SLO (Service Level Objective) — целевые показатели

• Error Budget — допустимый процент сбоев

# Расчёт error budget — пример из практики SRE
# SLA: 99.9% uptime в месяц

MONTH_MINUTES = 30 * 24 * 60  # 43200 минут
SLA_PERCENT = 99.9

allowed_downtime = MONTH_MINUTES * (100 - SLA_PERCENT) / 100
print(f"SLA: {SLA_PERCENT}%")
print(f"Разрешённый даунтайм: {allowed_downtime:.1f} минут/месяц")
print(f"Это примерно {allowed_downtime / 60:.1f} часов")

Результат: при SLA 99.9% разрешено около 43 минут простоя в месяц. SRE следит чтобы этот бюджет не был исчерпан.

Дизайн и UX: для кого делаем?

Роль дизайна часто недооценивают, но именно UX/UI определяют будет ли продукт удобным для пользователей.

UX Designer

UX-дизайнер изучает пользователей и проектирует взаимодействие:

• Исследования — интервью, опросы, карты пользовательского пути

• Прототипы — wireframes в Figma, интерактивные прототипы

• Юзабилити-тестирование — наблюдение за реальными пользователями

UI Designer

UI-дизайнер отвечает за визуальную часть:

• Дизайн-система (цвета, шрифты, компоненты)

• Иконки, иллюстрации, анимации

• Адаптив под разные экраны

Управление: как организовать процесс?

Без управления даже самая сильная команда работает хаотично. Управленческие роли обеспечивают порядок.

Scrum Master

Scrum Master — фасилитатор Agile-процесса. Это не менеджер, а «слуга команды».

Что делает Scrum Master:

Пример структуры спринта:

# Упрощённое планирование спринта
sprint_capacity = 5 * 8 * 0.75  # 5 дней, 8 часов, 75% эффективность
print(f"Ёмкость спринта: {sprint_capacity:.0f} часов")

stories = [
    {"name": "Регистрация пользователей", "estimate": 13},  # story points ~ часов
    {"name": "Восстановление пароля", "estimate": 8},
    {"name": "Профиль пользователя", "estimate": 5},
    {"name": "Настройки уведомлений", "estimate": 3},
]

total_estimate = sum(s["estimate"] for s in stories)
print(f"Запланировано: {total_estimate} часов")
print(f"Остаток ёмкости: {sprint_capacity - total_estimate:.0f} часов")

Engineering Manager

Engineering Manager управляет людьми, а не задачами:

• Найм и онбординг

• Оценка эффективности (performance review)

• Карьерный рост команды

• Разрешение конфликтов

Project Manager

Project Manager — планирование, сроки, ресурсы. Чаще встречается в waterfall-проектах, но используется и в Agile.

Специализированные роли

По мере роста проекта появляются узкоспециализированные роли.

Как выглядит команда на разных этапах

Состав команды меняется по мере роста проекта.

Стартап (1-5 человек)

Рост (5-20 человек)

Добавляются:

• Выделенный QA Engineer

• DevOps Engineer (ручной деплой больше не работает)

• UX/UI Designer

• Tech Lead (один разработчик берёт на себя архитектуру)

Зрелый продукт (20+ человек)

Полная команда:

• Product Manager + Product Owner

• Несколько команд разработки с Tech Lead в каждой

• QA-отдел (автотесты, нагрузочное тестирование)

• DevOps/SRE-отдел

• Engineering Manager на каждую команду

• Security Engineer, Data Engineer и другие по необходимости

Типичные проблемы взаимодействия ролей

Даже при правильных ролях возникают конфликты. Вот самые частые:

PO vs Tech Lead

Конфликт: PO хочет фичу «завтра», Tech Lead говорит что нужно переделать архитектуру.

Решение: PO объясняет бизнес-ценность и дедлайн. Tech Lead предлагает компромисс — временное решение с планом рефакторинга.

Разработчик vs QA

Конфликт: Разработчик считает баг «не воспроизводим», QA — что это критичная проблема.

Решение: QA предоставляет шаги воспроизведения и логи. Разработчик проверяет на тестовом окружении. При спорах — решение Tech Lead.

DevOps vs Разработчик

Конфликт: Разработчик локально всё работает, на сервере — падает.

Решение: Контейнеризация (Docker) устраняет разницу между окружениями. CI/CD пайплайн ловит проблемы до продакшена.

Как выбрать роль для карьеры

Выбор роли зависит от навыков и интересов:

Заключение

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

В небольших командах один человек часто выполняет несколько ролей — разработчик может быть и Tech Lead, и DevOps. По мере роста команды роли разделяются, и понимание каждого становится ещё важнее.

Ключевой принцип: роли — это не иерархия, а распределение ответственности. Product Owner не «главнее» Tech Lead — они просто отвечают за разные аспекты продукта. Успешный продукт создаётся когда все роли работают слаженно, уважая зону ответственности друг друга.