Привет, Хабр! Мопед не мой я просто разместил объяву. (с) В этой статье я расскажу о процессах и ролях, которые придумали до меня и тут будет просто пересказ как оно было с моих слов. Я в IT 13 лет. Первый мой опыт управления командой был … в молодости в рейдах WoW где я был лидером рейда ака РЛ. В общем рейд это нападение на сильного монстра куда собирается много игроков вместе и РЛ их организует.  Сейчас я CTO стартапа Dish&Fork ^{[ссылка удалена мод.].} Сейчас мы на стадии бета тестирования в Москве.  

Менеджер Продукта ака Продакт  

Если сравнить со строительством дачи, то Продакт это заказчик, владелец дачи. Задача Продакта чтобы в системе было максимум полезных и нужных для пользователя фич. Для этого он проводит опросы пользователей, следит за метриками как новая фича повлияла, например на конверсию, отток пользователей, LTV. Как сказал мне один мой коллега (очень хороший Продакт) - моя цель сделать пользователя счастливым, дать ему то, что ему нужно на самом деле, а не то, что он думает, что ему нужно. Я думаю, это скорее слова мечтателя. Хотя, когда я смотрел “Школу Менеджеров Яндекса” там был пример поведения хорошего Продакта, который укладывается в эту парадигму: Приходит парень к тренеру и говорит, что хочет накачаться. Плохой Продакт это как тренер, который просто начинает его тренировать. Хороший Продакт — это тренер, который спросит зачем он хочет прокачаться и если клиент скажет, что, например, чтобы себя защитить смог то посоветует ему сходить на бокс или самбо вместо качалки. 

Менеджер Проекта ака Прожект  

Проектный Руководитель команды в матричной структуре. Если сравнить со строительством это Прораб. Если сравнить с игрой и тем самым рейдом в WoW то это Рейд Лидер. Проект — это мероприятие, ограниченное во времени. Тут считают, что каждый спринт — это мини проект с набором целей. Задача Прожекта следить за тем, чтобы равномерно распределялись задачи между членами команды (собственно, он им их и ставит) и следить чтобы процесс внутри команды соблюдался. Надсмотрщик если одним словом описать его работу. Набирает людей в команду и убирает их из нее. Строит план график работ и диаграммы Ганта согласно списку фич и роадмапу от Продакта чтобы Продакт примерно понимал, когда будет готова конкретная фича. В молодых командах еще по идее оптимизирует процесс чтобы его улучшить и пишет инструкции по процессу. В этой компании уже все процессы регламентированные и задокументированные поэтому, собственно, только следить за их соблюдением и остается. 

Бизнес Аналитик ака ВА 

Его цель задокументировать что именно хочет заказчик/Продакт. Какая должна быть фича которую тот захотел добавить или что именно и как нужно поменять в старой фиче. ВА пишет ТЗ со стороны бизнеса, то, как видит систему пользователь, грубо говоря ТЗ про фронт. ТЗ про то, как система реагирует на действия пользователя и как с ним взаимодействует в целом. Набор сценариев и альтернативных сценариев к ним.  Бизнес ТЗ набор если то. Если пользователь выбрал пароль короче 8 символом, то показываем ему сообщение - пароль должен быть длиннее 8 символов. Если пользователь выбрал пароль без прописных букв, то показываем пользователю ошибку - пароль должен содержать прописные буквы. Обычно это так же в графическом виде в виде дерева исходов изображают. BPMN диаграмм. 

Системный Аналитик ака SA  

Его цель спроектировать и задокументировать техническую структуру системы. Часто они в том числе пишут и то какие таблицы должны быть в БД. Какую БД использовать. Какой протокол передачи данных. Какие сущности будут в системе (User, Book).  ТЗ со стороны системы, ТЗ со стороны разработчиков, грубо говорят ТЗ про бек. Тут используют различные UML диаграммы. В основном диаграммы классов со связями между ними вроде композиции и т. д. главного системного аналитика команды называют Архитектором системы. 

Архитектор 

Технический руководитель проекта. Решает какой протокол передачи данных использовать, Какую БД, на какие микросервисы поделить проект и прочие технические вопросы. Оформляет это в виде ТЗ системы. По сути, главный системный аналитик проекта. 

Дизайнер 

Грубо говоря, если рассматривать Бизнес ТЗ как книгу, то Дизайнер тут иллюстратор что делает иллюстрации к Бизнес ТЗ чтобы разработчикам было наглядно видно, что именно хочет заказчик (Продакт) получить в итоге. В процессе он думает, как покрасивее (UI) и поудобней для пользователя (UX) отобразить то, что написано в Бизнес ТЗ. 

Фронтенд Разработчик ака Фронтендер 

Тут надо сказать, что всех фронтов и Web и Mobile и Desktop объединил в одну группу. Различия в том, где запускается приложение в Браузере, на iOS, на десктопе Windows и т. д.  Согласно ТЗ и дизайну реализует часть системы, которую непосредственно видит пользователь и которая работает на устройстве пользователя. Решает какие технические решения на уровне кода и конечной реализации применить чтобы реализовать ТЗ. Какую библиотеку использовать для локализации, какой стиль кода и т. д. 

Бекенд Разработчик ака Бекендер

Согласно ТЗ и иногда поглядывая на дизайн реализует часть системы, которая работает на серверах. Так же как фронтендер решает какие технические решения на уровне кода и конечной реализации применить чтобы реализовать ТЗ. Какую библиотеку использовать для локализации, для работы с БД, какой стиль кода и т. д. только в части системы, работающей на стороне сервера. 

Специалист по Автоматизированному тестированию ака Авто Тестер

Главная задача QA (отдел качества) проверить что система работает согласно ТЗ и Дизайну. Сравнивают что написано в ТЗ с тем, что сделано на самом деле. Так же если находят какое-то поведение, не описанное в ТЗ, то предлагают его туда внести с описанием как в этом случае должна вести себя система. Например, показать пользователю сообщение - “Фу таким быть! Больше так не делай!”. Тут надо сделать оговорку что QA в целом тот, кто отвечает за качество продукта ака количество багов. Чем выше уровень квалификации QA и чем больше у них власти, тем выше качество продукта при этом дольше и дороже. Авто Тестеры пишут тесты, тест роботов, что имитируют поведение пользователей, жмут на кнопки, заполняют формы и имитируют поведение фронтенда - делают запросы к API. Обычно эти тесты после изменений системы запускаются чтобы проверить что изменения ничего не сломали.  

Специалист по Ручному тестированию ака Тестер 

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

DevOps  

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