tgoop.com/big_data_systems_analysis/176
Last Update:
Недавно столкнулась с хейтом к этому посту. Комментатор возмущался, что "понаберут с улицы" и "как вообще может быть связаны ТЗ и sql". Вот что случается, когда смотришь на мир слишком узко и сталкиваешься с вещами вне своей специфики.
Связь, на самом деле, очевидна, если понимать, как работают процессы в хранилище данных. ТЗ описывает не только саму задачу, но и контекст: что именно нужно сделать, с какими ограничениями и какие бизнес-требования лежат в основе (т.е. зачем вообще мы это делаем, согласитесь – важное понимание). SQL, в свою очередь, — это лишь один из возможных инструментов реализации описанного в ТЗ.
Безусловно, есть компании и команды, где просто физически нет возможности (а порой и необходимости, если всё делает 1 человек) писать ТЗ. Но у нас в хранилище этот процесс работает чётко: крупные задачи передаются от системных аналитиков дата-инженерам именно через ТЗ. Мы продумываем решение, экспериментируем, описываем его и только потом передаём на реализацию.
Речь не о каких-то мелких правках, а о чём-то более масштабном. Например, о загрузке данных с новых источников новым методом (у нас дата-инженеры занимаются только разработкой, без исследования самих данных) или доработке текущих и разработке новых фреймворков.
К примеру, при подключении нового API-источника системный аналтик сначала анализирует, как меняются данные со временем, какие поля обязательны, какими методами забирать те или иные сущности, какие ограничения накладывает сам API, и где могут возникнуть потенциальные проблемы. После этого он описывает метод загрузки сущностей в виде ТЗ и передёт его (после ревью, конечно) дата-инженерам, которые уже занимаются разработкой технической части: настройкой пайплайнов, написанием ETL-скриптов, внедрением методов обработки и трансформации. Т.е. реализацией.
И вот здесь я вижу огромную ценность доступной и поддерживаемой документации. Говорю это, исходя из своего опыта. Сейчас мне приходится работать с горой незадокументированного легаси, которое создавалось годами в условиях ограниченных ресурсов, правилось ASAP-требованиями и чаще всего не имеет описаний ни в коде, ни документации. Даже скромное ТЗ на этапе разработки, могло бы помочь понять, какие изменения вносились и зачем. Теперь же приходится тратить время (очень много времени) на разбор неочевидных решений.
Моё имхо: без документации слишком много зависит от устных договорённостей. Это не отслеживаемо, не поддерживаемо и не безопасно — т.е. огромный риск, особенно если кто-то из ключевых сотрудников покинет проект.
А как у вас? Есть ли в вашей компании практика написания ТЗ или всё держится на неформальных договорённостях и тасках в jira?
#документация
BY В мире больших данных

Share with your friend now:
tgoop.com/big_data_systems_analysis/176