Сегодня получила такой вопрос. Из ответа, решила сделать пост, потому что вопрос возникает не впервые и часто вызывает путаницу.

Классическое ТЗ по ГОСТам, обычно содержит технические описания и требования, такие как описание сервисов, структуры баз данных, описание структуры данных в форматах XML или JSON и так далее. Как раз это задача системных аналитиков. Они обладают навыками работы с техническими деталями и спецификациями, и создают ТЗ в форме именно технического задания.

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

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

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

Чаще всего в продуктовых командах встречаются бизнес аналитики и технические специалисты, которые могут подхватить если это требуется, например архитекторы или девопсы, разработчики. Здесь ключевой момент в словах «если требуется», ведь в продуктовых командах создается один продукт и бывает так, что интегрировать его кастомными путями не требуется.

А вы что думаете на эту «холиварную» тему?)