📌 Как взаимодействуют роли в IT-разработке и где тут системный аналитик В каждой команде есть роли, но не всегда есть четкое понимание, кто за что отвечает. Особенно когда артефакты пересекаются, а процессы - не всегда формализованы. Чтобы расставить точки над «i», я собрал схему. Она построена вокруг системного аналитика на базе вопросов - «что?», «где?» и «как?». 🔹 Бизнес-аналитик отвечает на вопрос «что?» - что необходимо реализовать? - его зона ответственности: Vision, BRD, бизнес-контекст и цели. 🔹 Архитектор отвечает на вопрос «где?» - где необходимо реализовать? - с опорой на BRD и Vision формирует ADR и архитектурные решения. 🔹 Системный аналитик отвечает на вопрос «как?» - как необходимо реализовать? - на выходе SRS, сценарии, спецификации, схемы интеграции и логика, понятная и разработке, и тестированию, и поддержке. Эта связка работает только в том случае, если каждый делает свою часть. Системный аналитик не должен «додумывать» за BA, не обязан закрывать пробелы в архитектуре, не обязан отписывать вместо QA. 🧩 Его задача - трансляция требований в реализацию. Именно через него проходят все входные артефакты (BRD, ADR), и именно он делает из них понятную инструкцию на выход: для разработчиков, тестировщиков, поддержки. Чтобы: • разработка могла реализовать функциональность с первого раза • QA смог протестировать по сценарию • поддержка могла ответить на вопрос не из головы, а из документации 🛠️ Все это - не про теорию. Это про ежедневную практику. Как сделать так, чтобы задачи шли в спринт без десятка уточнений, чтобы при увольнении ключевого сотрудника знания остались, а не исчезли. Картинка в посте - схема взаимодействия, адаптируйте под свою реальность. #SA #процесс @fokin_media