Как системному аналитику мне часто приходится проектировать новые решения - продумывать структуры, описывать преобразования и рисовать схемы и как будто бы все.

Но на практике я часто начинаю писать код.

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

Так я могу проверить: - подходят ли выбранные структуры данных - правильно ли работают фильтры и преобразования - учтены ли пограничные случаи - можно ли вообще реализовать задуманное

Формально моя задача спроектировать решение, подготовить ТЗ и передать его дата-инженеру. Но если ограничиться только схемами и описанием, во время разработки возникает множество уточнений.

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

Поэтому я пишу код.

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

С другой стороны, возникает вопрос: не выполняю ли я чужую работу?

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

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

Окончательного ответа у меня пока нет.

Должен ли системный аналитик ограничиваться схемами и ТЗ? Или рабочий прототип - нормальная часть проектирования?

Интересно узнать, как эта граница устроена в ваших командах.

#системныйаналитик #датаинженерия #dataengineering #аналитика #проектирование #PySpark #витриныданных #разработка #архитектура #IT