Мы продолжаем рассказывать о том, как организована работа в IT-компании. В предыдущей статье мы представили методологию SDLC (Software Development Life Cycle — жизненный цикл разработки программного обеспечения).
В этом материале мы рассмотрим основные роли и зоны ответственности в команде разработки, чтобы лучше понять, как работает “устав” SDLC в идеальных условиях. Чтобы не повторяться, укажем, что все из этих специалистов могут участвовать во всех стадиях SDLC, но в разной степени. Также оговоримся, что ниже речь идет о ролях, списки обязанностей могут быть гораздо шире, либо команды могут быть гораздо меньше.
1. Продакт-менеджер / Продакт-оунер (владелец продукта)
Отвечает за успех продукта. Чаще всего является автором идеи продукта (продуктовой гипотезы) или разрабатываемой фичи. Может выполнять почти все функции в команде и заменять практически всех ее участников. Senior product manager Александр Замахов описывает этого специалиста, как “человека, которому больше всех надо”.
“Продакт-менеджер отвечает на вопросы:
- Что конкретно будет делать команда?
- Что нужно и что будет предложено клиенту?
Высший пилотаж: ответить на вопрос “Почему мы это делаем?”, — объясняет Замахов.
Что должен знать Junior product manager
2. Проектный менеджер
Выполняет организаторскую роль и отвечает за конкретный проект по разработке продукта или фичи. Отвечает на вопрос: “Как и когда все будет сделано?”. Является ответственным за доставку ценности клиенту, за сроки и ресурсы.
“Это администратор, который по полочкам все разложит, в нужные сроки принесет, не забудет отправить все нужные запросы и собрать необходимые документы”, — делится Замахов.
Что должен знать Junior Project manager. Часть 1: стратегические аспекты
3. UX/UI-дизайнер
Отвечает за пользовательский опыт и интерфейс. Больше всего вовлечен на стадиях проектирования и тестирования. На стадии проектирования его задаче является ответить на вопрос “Как сделать продукт понятным и удобным для пользователей?”. Этот же вопрос может мутировать в “Нужна ли эта функция и не испортит ли она продукт в целом?”. На стадии тестирования он должен убедиться, что продукт действительно понятен и удобен для клиентов.
Что должен знать Junior UX/UI дизайнер
4. Бизнес-аналитик (системный-аналитик)
Бизнес-аналитик собирает требования стейкхолдеров, проводит анализ и подготавливает необходимые для разработки софта документы. Отвечает на все вопросы, включая “Что, когда, как, почему, в какие сроки, зачем и “Как мы тут оказались?”. Создает документ бизнес-требований (Что хочет заказчик?).
Системный аналитик переводит бизнес-требования в понятный разработчикам язык и создает техническое задание ( Software requirements document — документ требований к ПО) с помощью UML-диаграмм. Подробнее прочитать о происходящем на схеме можно здесь.
Что должен знать Junior бизнес-аналитик?
5. Технический лид / Разработчик
Создает код. Проще всего технического лида можно описать как самого опытного разработчика в команде. Он решает, какими инструментами будут пользоваться для разработки, какой будет архитектура (план или схема, показывающая, как разные части программы работают вместе, чтобы выполнять нужные задачи) кто и что будет разрабатывать. Может оценить, сколько времени займет разработка. Сам непосредственно пишет код, превращает идеи в работающие продукты.
Что должен знать Junior веб-разработчик: верстка и JavaScript
6. Тестировщики (QA)
Тестировщики обеспечивают качество продукта, проводя тесты на всех этапах разработки. Их цель — обеспечить, что продукт отвечает требованиям и не содержит ошибок. Обычно вовлечены на поздних стадиях SDLC, но могут принимать участие и на этапе сбора требований, чтобы избежать ошибок в коммуникациях и недоговоренностей.
В некоторых компаниях даже предпочитают эту практику.
“Получалось, что часть требований выяснялась только на этапе тестирования, когда тестировщик сталкивался с противоречиями и начинал задавать вопросы. То есть этап тестирования готового продукта, по сути, становился этапом выяснения исходных требований и попыткой доработать проект с их учётом”, — делятся опытом представители агентства Alente.
7. DevOps-инженер
DevOps это термин, в котором объединяются слова разработка (Development) и операции/эксплуатация (Operations). Обычно отвечает на вопросы “Когда можно будет скачать приложение?” и “Почему сервер упал?”. Его задача заключается в том, чтобы у разработчиков и клиентов “все работало”.
Процесс выката (“публикации”, размещения онлайн для использования клиентом) софта достаточно сложен и поэтому для этого требуется отдельный специалист, который отвечает за работу серверов и за размещение исходного кода и готовых программ.
Выше мы уже сказали, что специалисты могут совмещать разные роли в SDLC. Так продакт-менеджер Александр Замахов разрабатывал продукт с командой из двух человек (включая его самого). Это была программа для помощи казахстанцам по разным вопросам налогового декларирования.
“В команде я выполнял роль менеджера и дизайнера. У меня был один разработчик который писал весь код для этого всего дела. Какую-то MVP (минимально жизнеспособный продукт) мы запустили”, — делится он.
Как и устав в любой организации, SDLC является лишь ориентиром. На практике многие команды сталкиваются с необходимостью адаптировать процессы и быть гибкими. Идеальный сценарий предполагает, что до начала разработки все требования полностью спланированы, но в реальности команда часто работает параллельно.
Практическим примером может служить система управления бизнесом Darlean.kz. Одна платформа заменяет функционал более 10 инструментов и программ. Над ней трудится большая команда, из более чем 200 специалистов. Параллельно в компании проходят процессы сбора требований, дизайна, тестирования, разработки, формулирования и тестирования гипотез, исправления багов.
Более детально увидеть весь процесс и узнать, какой жизненный путь проходит каждая функция можно в материалах по гипотезам и их тестированию и по бизнес и системному анализу.