Роли и должности в разработке ПО

Итак, вот примерно роли и их описание. Я расскажу, как я это вижу, потому в других компаниях это может и будет отличаться.

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

• интерн - временный девелопер, делает какой то маленький проект под присмотром прикрепленного старшего товарища
• джуниор - наносит небольшую, но постоянную пользу проекту/компании, также под присмотром. Делает всю самую простую и скучную работу. Может взять на себя реализацию небольшой фичи.
• мидл - может взять на себя один проект / сервис полностью, сделать его сам или в составе команды
• сеньор - обычно отвечает за продукт/набор продуктов, помогает всем, кто ниже по рангу, отвечает на все технические вопросы по продукту (или сервису). Определяет все технические решения для команды или группы команд. Властелин кода и архитектуры уровня продукта короче. В идеале, у каждой команды свой сеньор, в реале у сеньора может быть несколько команд. Короче, если есть проект/продукт/задача, любой технический вызов, который команда не вывозит, привлекается сеньор. Сеньор при желании может вытянуть проект любой сложности из жопы в релиз. Серьор помогает команде работать эффективно. В общем, если всё плохо, то зовут сеньора и все становится хорошо. Также сеньор может вывезти проект в одного, при желании. Определяет различные инициативы внутри своей вотчины, ведет презентации. Подчиняется Senior SDM, работает плотно с принципал девелопер.
• принципал девелопер - отвечает за набор продуктов, руководит сеньорами (ну как руководит, сотрудничает :)), определяет то, как продукты/сервисы могут взаимодейсвовпть между собой.
• архитектор - определяет линию партии, обычно привлекается, когда тербуется руководство для создания нового о продукта / сервиса, определяет дизайны высокого уровня, документы с диаграммами - его основной инструмент. Если честно, полезный архитектор - птица редкая.

Менеджмент

• SDM - Software Develoment Manager - менеджер, который владеет командой и продуктами. Привязан к одной команде. Определяет общий приоритет проектов. Следит за командой, решает организационные задачи, помогает всем, чем может. aka Начальник отдела.
• Senior SDM - руководитель для SDM, руководит по сути всем, что происходит в его юристдикции, определяет вектор развития всего своего департамента, решает все организационные вопросы на своем уровне. aka Глава департамента.
• Project Manager - руководит проектами, может иметь 10-20 проектов параллельно. Может не вдуплять техническую часть вообще, его работа - организовать работу проекта, организовать кросс-командные взаимодействия, сделать за проектом, решать все орг вопросы, подготовить все необходимые документы, отвечает также за планирование проекта. В общем, он переживает за проект больше всех, ведет проект от начала до конца. Для понимания, у команды может быть несколько проектов одновременно, у проекта может быть несколько команд одновременно. Потому у проекта должен быть один ответсвенный человек и это project manager.
• Product manager - тот, кто отвечает за конкретный продукт или продукты. Определяет как продукт будет работать с точки зрения бизнеса. Определяет вектор развития продукта с точки зрения бизнеса. Не вдупляет в тех часть, но лушче всех знает как его продукт работает, какие в нем есть фичи, кто и как его использует и тд.
• BA - Business Analyst - это аналитик, его задача - обычно оценка новых фич, по уровню знания примерно как Product Manager, но ничего не определяет, но отвечает на воросы девелоперов типа "а как юзер должен взаимодействовать с продуктом в фиче Х продукта У?"

Универсальный солдат

• Team Lead. Когда я был тимлидом, я совмещал сеньора, девелопера, скрам мастера, прожект менеджера. Короче, когда я стал тимлидом, ко мне подошел директор, показал пальцем на команду, на заказчика и попросил сделать хорошо. Все остальное делаешь сам, то есть: работа с заказчиком, понимание проблемы, дизайн, вся необходимая документация, набор/тренинг команды, выстраивание процесса (agile, scrum, что хочешь вообще), выстраиваешь SDLC процесс, руководишь проектом, работаешь с дизайнерами, тренируешь доевеперов, если команда не вывозит тех задачу - делаешь сам. В общем, организуешь всё, максимум независимости.

Качество ПО

Бытует мнение, что QA это просто сидишь и тыкаешь в продукт, пока не найдешь баг. Это не так.
Есть рядовые QA, обычно являются частью команды. Работа такого QA - это управление качеством каждого продукта, которым они владеют.

Эти QA

• определяют планы тестирования для продуктов.
• для каждой задачи, QA должны не только понять суть задачи с точки зрения бизнеса, но и убедиться, что задача решена девелопером именно так, как задумано, и что никакой другой функционал не поломан при этом. По сути задача не считается законченной, пока QA не дал на это согласие. Мало того, тестирование каждой задачи документируется, с указанием как именно тестирование было проведено и почему оно считается успешным.
• QA владеет и выполняет регрессионное тестирование перед каждым релизом. Следовательно QA определяет план регрессионного тестирования вплоть до мелких подробностей для каждого из тестов
• Если владеет в автоматизацию, то пишет автоматизированные регрессионные тесты.
• Юнит тесты пишут девелоперы, QA обычно вообще не интересны юнит тесты. Если это, конечно, не Software dev in test, которых я не видел никогда.
• Помимо регрессионных тестов, выполняет все остальные виды тестов (например, smoke testing, etc)
• так как количество QA обычно сильно меньше, чем девелоперов, то QA владеют общей картиной гораздо лучше сраднего девелопера, разбираются и в задачах, поставленных девелоперам, и в продукте. QA плотно работают и с девелоперами и с бизнес аналитиками.
• QA - это последняя линия защиты от багов и задач, реализованных ненадлежащим образом.

Есть Lead QA - обычно управляют качеством проектов, то есть это такие типа Project Manager, только в проектах они отвчают за качество. Например, они отвечают за интеграционное тестирование кросс-комндных фич. Вообще все вопросы по качеству проекта адресуют Lead QA, lead QA работает вплотную с QA команд.

Многие компании отказываются от QA и перекладывают ответсвенность QA на девелопера, Lead QA на Project Manager.

Немножко про UX.

Я встречал заблуджение, что UI/UX дизайнер клепает бездумно дизайны форм и не парится. Я расскажу из моего опыта работы с UI/UX дизайнерами здорового человека.

UI/UX дизайнер начинает работу задолго до девелопера. Он опеределяет то, как конечный юзер будет взаимодействовать с продуктом. Да, все элементы интерфейса определены дизайнером.
UI/UX дизайнер в идеале участвует во всех обсуждениях новых фич на уровне бизнеса.

Казалось бы, что тут сложного? Но!

• Чтобы нарисовать интерфейс, надо понять, что именно юзер хочет сделать и зачем. То есть дизайнер должен понимать бизнес задачу до самых мелких деталей. Интерфейс, который не нужен или излищен, будет являться фейлом работы UI/UX дизайнера.
• Юзер не будет использовать интерфейс, который ему не нравится. Все элементы интерфейса должны быть гармоничными и логичными для юзера и задачи, которую он решает. Но юзер не знает заранее, что для него логично, а что нет. Но юзер не знает заранее, что для него гармонично, а что нет. Попробуйте решить такую задачу.
• Зачастую, реализация фронта и API бекенда отталкиватеся от UI. А значит и оценка фронта работ отталкивается отуда же. Девы смотрят на дизайн страницы, но видят в нем что то типа "вот тут надо подгрузить товары для грида, тут надо АПИ для кнопки". Девы обычно не видят работы, которая стоит за дизайном и не задаются вопросом "а зачем тут грид и кнопка? что она дает заказчику?". Хорошие девы таким вопросом задаются и быстро становятся сеньорами. Пример - дизайнер может придумать такой элемент упрвления, который будет очень простой для юзера, но очень сложный для реализации девелоперам. Дизайнер будет защищать UI experience, он выступает как адвокат юзера в таких случаях.
• UI/UX дизайнер должен хорошо знать дизайн продукта и все фичи продукта, чтобы дорабатывать дизайн своими наработками. Если ты поставил кнопку, а такая кнопка уже есть в другом месте и там её нажимать удобней - ты об этом узнаешь скорее всего уже от юзера. Удачи пояснить Project Manager, SDM, девелоперам и QA почему ты профукал их время на работу, которая не нужна.
• UI/UX вдадеет так называемой концепцией продукта, то есть все решения, что были вынесены для дизайна, все концепции дизайна, всё это вотчина дизайнера.

UI/UX дизайнеры плотно работают со всеми, от бизнеса до девелоперов.

Зачастую ролью дизайнера пренебрегают, и тогда эту роль дают программистам. Так и рождаются формы с миллиардами бессмысланных полей.

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

Для понимания, это не какое то жесткое разделение, есть некоторые девиации. Например, сеньор может вполне работать в паре с джуном или выступать как скрам мастер для команды или организовать кросс-департаментное взаимодействие. Также и для других ролей.
Например, если есть крупный проект, на него могут назначить сильного мидла вместо сеньора. Тогда мидл будет работать на уровне серьора и может это испольщовать для своего повышения.
Ну и другие девиации возможны. Обычно всё сильно зависит от скиллов, SDM может совмешать Project manager работу и тд. Потому писанина выше - это просто ориентир, но не какие то жесткие правила.