BIG_DATA_SYSTEMS_ANALYSIS Telegram 176
Недавно столкнулась с хейтом к этому посту. Комментатор возмущался, что "понаберут с улицы" и "как вообще может быть связаны ТЗ и sql". Вот что случается, когда смотришь на мир слишком узко и сталкиваешься с вещами вне своей специфики.

Связь, на самом деле, очевидна, если понимать, как работают процессы в хранилище данных. ТЗ описывает не только саму задачу, но и контекст: что именно нужно сделать, с какими ограничениями и какие бизнес-требования лежат в основе (т.е. зачем вообще мы это делаем, согласитесь – важное понимание). SQL, в свою очередь, — это лишь один из возможных инструментов реализации описанного в ТЗ.

Безусловно, есть компании и команды, где просто физически нет возможности (а порой и необходимости, если всё делает 1 человек) писать ТЗ. Но у нас в хранилище этот процесс работает чётко: крупные задачи передаются от системных аналитиков дата-инженерам именно через ТЗ. Мы продумываем решение, экспериментируем, описываем его и только потом передаём на реализацию.
Речь не о каких-то мелких правках, а о чём-то более масштабном. Например, о загрузке данных с новых источников новым методом (у нас дата-инженеры занимаются только разработкой, без исследования самих данных) или доработке текущих и разработке новых фреймворков.

К примеру, при подключении нового API-источника системный аналтик сначала анализирует, как меняются данные со временем, какие поля обязательны, какими методами забирать те или иные сущности, какие ограничения накладывает сам API, и где могут возникнуть потенциальные проблемы. После этого он описывает метод загрузки сущностей в виде ТЗ и передёт его (после ревью, конечно) дата-инженерам, которые уже занимаются разработкой технической части: настройкой пайплайнов, написанием ETL-скриптов, внедрением методов обработки и трансформации. Т.е. реализацией.

И вот здесь я вижу огромную ценность доступной и поддерживаемой документации. Говорю это, исходя из своего опыта. Сейчас мне приходится работать с горой незадокументированного легаси, которое создавалось годами в условиях ограниченных ресурсов, правилось ASAP-требованиями и чаще всего не имеет описаний ни в коде, ни документации. Даже скромное ТЗ на этапе разработки, могло бы помочь понять, какие изменения вносились и зачем. Теперь же приходится тратить время (очень много времени) на разбор неочевидных решений.

Моё имхо: без документации слишком много зависит от устных договорённостей. Это не отслеживаемо, не поддерживаемо и не безопасно — т.е. огромный риск, особенно если кто-то из ключевых сотрудников покинет проект.

А как у вас? Есть ли в вашей компании практика написания ТЗ или всё держится на неформальных договорённостях и тасках в jira?

#документация
🔥6👍2



tgoop.com/big_data_systems_analysis/176
Create:
Last Update:

Недавно столкнулась с хейтом к этому посту. Комментатор возмущался, что "понаберут с улицы" и "как вообще может быть связаны ТЗ и sql". Вот что случается, когда смотришь на мир слишком узко и сталкиваешься с вещами вне своей специфики.

Связь, на самом деле, очевидна, если понимать, как работают процессы в хранилище данных. ТЗ описывает не только саму задачу, но и контекст: что именно нужно сделать, с какими ограничениями и какие бизнес-требования лежат в основе (т.е. зачем вообще мы это делаем, согласитесь – важное понимание). SQL, в свою очередь, — это лишь один из возможных инструментов реализации описанного в ТЗ.

Безусловно, есть компании и команды, где просто физически нет возможности (а порой и необходимости, если всё делает 1 человек) писать ТЗ. Но у нас в хранилище этот процесс работает чётко: крупные задачи передаются от системных аналитиков дата-инженерам именно через ТЗ. Мы продумываем решение, экспериментируем, описываем его и только потом передаём на реализацию.
Речь не о каких-то мелких правках, а о чём-то более масштабном. Например, о загрузке данных с новых источников новым методом (у нас дата-инженеры занимаются только разработкой, без исследования самих данных) или доработке текущих и разработке новых фреймворков.

К примеру, при подключении нового API-источника системный аналтик сначала анализирует, как меняются данные со временем, какие поля обязательны, какими методами забирать те или иные сущности, какие ограничения накладывает сам API, и где могут возникнуть потенциальные проблемы. После этого он описывает метод загрузки сущностей в виде ТЗ и передёт его (после ревью, конечно) дата-инженерам, которые уже занимаются разработкой технической части: настройкой пайплайнов, написанием ETL-скриптов, внедрением методов обработки и трансформации. Т.е. реализацией.

И вот здесь я вижу огромную ценность доступной и поддерживаемой документации. Говорю это, исходя из своего опыта. Сейчас мне приходится работать с горой незадокументированного легаси, которое создавалось годами в условиях ограниченных ресурсов, правилось ASAP-требованиями и чаще всего не имеет описаний ни в коде, ни документации. Даже скромное ТЗ на этапе разработки, могло бы помочь понять, какие изменения вносились и зачем. Теперь же приходится тратить время (очень много времени) на разбор неочевидных решений.

Моё имхо: без документации слишком много зависит от устных договорённостей. Это не отслеживаемо, не поддерживаемо и не безопасно — т.е. огромный риск, особенно если кто-то из ключевых сотрудников покинет проект.

А как у вас? Есть ли в вашей компании практика написания ТЗ или всё держится на неформальных договорённостях и тасках в jira?

#документация

BY В мире больших данных




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

View MORE
Open in Telegram


Telegram News

Date: |

The group’s featured image is of a Pepe frog yelling, often referred to as the “REEEEEEE” meme. Pepe the Frog was created back in 2005 by Matt Furie and has since become an internet symbol for meme culture and “degen” culture. ZDNET RECOMMENDS Over 33,000 people sent out over 1,000 doxxing messages in the group. Although the administrators tried to delete all of the messages, the posting speed was far too much for them to keep up. Add the logo from your device. Adjust the visible area of your image. Congratulations! Now your Telegram channel has a face Click “Save”.! On Tuesday, some local media outlets included Sing Tao Daily cited sources as saying the Hong Kong government was considering restricting access to Telegram. Privacy Commissioner for Personal Data Ada Chung told to the Legislative Council on Monday that government officials, police and lawmakers remain the targets of “doxxing” despite a privacy law amendment last year that criminalised the malicious disclosure of personal information.
from us


Telegram В мире больших данных
FROM American