Роль системного аналитика в проектах с Computer Vision и Machine Learning

Если смотреть в целом, то задачи системного (либо фуллстак) аналитика в проекте с CV+ML не сильно отличаются от выполняемых в других доменах: тот же сбор, валидация и документирование требований, разработка спецификаций, а для тех, кто "постарше" — проектирование архитектуры, ну и дальше опционально могут добавляться user acceptance testing, обучение ключевых пользователей, функциональное тестирование, онбординг юнцов, организация и проведение корпоративов и вообще все, что можно придумать. 👨‍💻 Трактовать эту роль в разных компаниях могут по-разному: например, на текущем проекте мне пришлось выполнить несколько PM-задач в процессе формирования нового R&D-отряда (в общем-то, проработать рабочие процессы и организовать интеграцию с продуктовой командой, к которой я все еще на 50% принадлежу). 😎
Тем не менее, каждый домен имеет свои особенности. Если сравнивать ML с доменом ERP, в котором у меня есть достаточно большой опыт, то можно заметить, что основное отличие: требования в ERP в основном четко формализуемы и детерминированы ("сделайте кнопку, чтобы у меня проводки вот по этому счету бахались"), 📞 в то время как при работе с распознаванием всяких штук на видео всегда имеется высокая степень неопределенности и даже функциональные требования могут быть завязаны на метрики, где метрика — измеримое Acceptance Criteria:

"Котиньки на фотографии должны сегментироваться с точностью 95%". 😿

Что это добавляет в мою работу, как системного аналитика? Проведение исследований, от которых будет зависеть дальнейшее движение продукта (не даром же у я на 50% в R&D-отряде). Важно отметить, что я даже близко не ML-специалист, но я прихожу к ним с конкретным запросом: "Есть гипотеза, надо проверить". Для примера рассмотрим мой недавний кейс.

Сектор "Кейс" на барабане
Есть ML-ка, которая сегментирует и распознает дорожные знаки, по знакам, соответственно, можно определить правонарушение, в размеченной вручную зоне на кадре. Бывает так, что знаки к камере повернуты "спиной" и тогда такой кадр не получится использовать в суде. При разметке зон действия знака возникла потребность помечать такие знаки, развернутые к камере. Однако бывают ситуации, когда знак развернут к камере углом, при котором человеческий глаз может понять, что именно за знак, а вот ML — под вопросом. 📹 Нужно было определить, требуется ли придумывать отдельный "статус" для таких сцен, а мне для этого надо было понять, в какой момент (при каком угле поворота) ML перестает распознавать знак и можно ли (нужно ли?) как-то дообучить модель. С запросом на такое исследование я и пошел к ML-команде. После чего моей задачей было провалидировать результаты исследования с требованиями стейкхолдеров принять решение: вводим "промежуточный" статус или нет.

Мораль: в любой сфере есть своя специфика и нюансы, поэтому в первую очередь нужно качать софт-скиллы, но это не точно.

#системныйанализ #ML #DL #AI #CV #computervision #machinelearning

Short Polling vs Long Polling: донимать пустыми запросами или ждать у моря погоды

Не так давно писал спеку по фиче, которая предполагает передачу данных в режиме реального времени. Не вдаваясь в детали, это разработка микросервиса, который определенным образом монтирует видео и было требование того, чтобы на UI в режиме реального времени видеть статус обработки. 🎬
Изначально для этой цели я предполагал использовать WebSocket: открывать канал связи и получать сообщения напрямую с сервера, однако после обсуждения с архитектурной командой было принято решение, что держать открытыми соединения по каждой заявке на монтаж видео лишь для того, чтобы красиво рисовать полоску загрузки на экране... Охренеть как Немного расточительно. 👌 Поэтому про WebSocket пост будет как-нибудь потом, а сегодня мы поговорим про Polling.

Polling — это в некотором смысле имитация обмена данными в режиме real-time, можно сказать в режиме псевдо-реального времени. Мы не передаем сообщение напрямую с сервера на клиент, клиент запрашивает данные с сервера, но делает он это автоматически с заданной регулярностью. Есть две концепции: Short Polling и Long Polling.

Short Polling — клиент с заданным интервалом (например, каждые 2 секунды) отправляет на сервер запрос по схеме «Есть ли что-нибудь новое?». Сервер всегда сразу отвечает — либо с новыми данными, либо с пустым ответом. Представим себе ребенка в машине, который с интервалом отправляет запрос спрашивает маму за рулем:

"Мы уже приехали? Мы уже приехали?"

Он будет спрашивать это вне зависимости от того, молчит ли мама или уже рявкнула на него:

"ЕЩЕ НЕТ!" 💥

Long Polling — Клиент отправляет запрос, сервер не отвечает сразу, а «замораживает» запрос до тех пор, пока не произойдет нужное событие ИЛИ не истечет таймаут (например, 30 секунд). Как только событие происходит, сервер немедленно отправляет ответ клиенту. Клиент, получив ответ, тут же отправляет следующий запрос. По аналогии с предыдущим примером, это ребенок, случайно хлебнувший утром батиного чая с коньяком и поэтому он задает вопрос бате за рулем и спокойно ждет ответа, пока на стороне сервера таймаут:

"Сколько времени нам еще ехать?"

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

Философское завершение: выбор между подходами — это классический компромисс между простотой и эффективностью.

P.S. Современными альтернативами для обоих подходов являются WebSocket (для двусторонней постоянной связи), его мы уже упоминали сегодня, Server-Sent Events (SSE) (для потоковой передачи данных от сервера к клиенту), gRPC Streaming и некоторые другие технологии, но везде есть свои нюансы и их мы обсудим в другой раз. 🔗

#системныйанализ #Архитектура #WebDevelopment #websocket #HTTP #интеграции

«А вот по поводу той фичи...» — как вести интервью со стейкхолдером, который хочет говорить о другом.

Большую часть своей карьеры я играю на позиции именно FullStack-аналитика, поэтому коммуникация со стейкхолдерами и сбор требований — важная часть моей работы и не часто удается переложить её на бизнес-аналитика. Вряд ли я кого-то удивлю, сказав, что есть разные классы стейкхолдеров и у всех них разные цели, задачи и потребности. Product Owners, конечные и ключевые пользователи, заказчики, инвесторы, support и т.д.: каждый будет заботиться о чем-то своем. ✍️ Мой сегодняшний пост будет не о том, как глобально дирижировать оркестр ожиданий стейкхолдеров, но как говорить с одной группой людей о том, что на самом деле волнует другую группу во время интервьюирования. 🎤

Я сейчас работаю над задачей, инициатором которой был... Лид команды разработки. Как так получилось? Есть некоторая проблема с накоплением излишних и дублирующих данных в БД. С момента проектирования прошло какое-то количество времени, часть бизнес-процессов поменялась, часть просто не была учтена при проектировании, внедрена новая функциональность и вообще много всего изменилось. Инициатива заключается в том, чтобы редизайнить схему данных для устранения имеющихся проблем. На данный момент мне кажется, что решение в конечном счете будет заключаться в денормализации, но детали еще предстоит выяснить. ⚙️

В чем на данный момент заключается моя задача? Выяснить у ключевых пользователей существующие на данный момент бизнес-сущности, взаимосвязи между ними, варианты их взаимодействия с точки зрения бизнеса и потом переложить это на модель данных. По этой теме я и решил пообщаться с одним из key users, тем более что контакт у нас с ним налажен очень хороший 💬 (unlimited бар на корпоративе сыграл в этом не последнюю роль, за что спасибо нашей компании). Сложность здесь в том, что его, как стейкхолдера, чьи подчиненные пользуются системой, вообще-то не особенно интересуют наши модели данных, таблицы, БД и как вообще все их объекты выглядят у нас под капотом. Поэтому в конечном счете диалог пришел к:

"Схема данных — это хорошо, но вот что нам реально нужно, так это предзаполнение полей вот на этом экране, а также..." 🖥

Ну, и так далее в таком духе. Thank God, у меня фича по этой теме давно в работе, поэтому я честно смог сказать, что работа кипит и скоро будем проводить UAT. 🗓 Интервью в итоге получилось максимально эффективным — я получил исчерпывающие ответы и очень классный схематичный рисунок в придачу, со своей стороны поделился статусом текущих задач.

Какой бы вывод я мог бы сделать для себя? Есть много разных приемов для эффективного ведения переговоров, которые я стараюсь использовать. Существуют приемы, направленные именно на выявление требований, они тоже есть в моем арсенале. Но самое эффективное из того, что я пробовал — это вставать на сторону интервьюируемого и искренне погружаться в его запросы и разделять ценности. Когда человек понимает, что вы играете в одной команде, он перестает быть оппонентом по переговорам, а становится напарником в общем деле создания хорошего продукта. Ведь если вы в одной команде, то как вы помогаете напарнику, так же и он поможет вам. Важно уметь напоминать об этом союзе, демонстрируя свою заинтересованность. 🔝

Философское саммари: Сбор требований — это не просто извлечение информации из головы стейкхолдера. Это ведение переговоров для укрепления взаимовыгодного партнерства.

#СборТребований #StakeholderManagement #Коммуникации #Переговоры #системныйанализ #softskills #IT

Инструменты, которые я использую в работе. Краткий обзор. 🔨

⚙️ Документирование: Для документирования (требования, спеки и т.д.) использую только Confluence 🖼️ и работаю с этим инструментом каждый день, тут особо ничего интересного. Из аналогов знаю Notion и Yonote, но в работе ими не пользуюсь (хотя использую для личных заметок). Ах да, и еще немного Swagger 👩‍💻 для API.

⚙️ Контроль задач: Чтобы не отходить далеко от Confluence, сразу скажу про таск-трекер — Jira 👩‍💻, тут тоже ничего особенного. Здесь веду и свои задачи и те, которые выставляю на разработку.

⚙️ Моделирование: Вот тут сейчас будет жесткий байт на комменты мое непопулярное мнение: я для моделирования использую Draw.io. Полетели тапки. Пока все от меня не отписались, я поясню: 1⃣В Confluence есть патч для интеграции Draw.io, поэтому все модели оказываются интегрированы прямо в доки и их можно редактировать там даже без изменения самого дока. Это очень удобно. 2⃣Универсальность. Да, я иногда пользуюсь и PlantUML, и Camunda, и dbdiagram.io (это для ER), но если нужна именно модель (визуальненько) просто удобнее это делать в одном месте. Поэтому UML, BPMN, C4, ER — все тут, в Draw.io.

⚙️ БД: А вот здесь ситуация обратная в сравнении с предыдущим пунктом в плане универсальности, поскольку для каждой БД я использую свой клиент. PgAdmin 👩‍💻 для Postgres, MongoDB Compass для Mongo, S3 Browser для S3. Раньше я использовал Dbeaver, подходящий и к Pg и к Mongo, но не углубляясь в детали, на текущем проекте он не очень мне подходит.

⚙️ Интеграции: Само собой это Postman 👩‍💻 — каждый день (тестирование API и запуск моков), очень редко SOAPUI и Insomnia, т.к. Postman в принципе покрывает всю необходимую функциональность. А также использую "Инструменты разработчика" браузерах, у нас web UI, поэтому очень удобно смотреть какие методы с UI вызываются, какие данные передаются и принимаются.

⚙️ Работа с кодом: GitLab 👩‍💻 для доступа к кодовой базе для чтения кода, если нужно что-то локально позапускать, то IntelliJ IDEA 👩‍💻, а конкретно PyCharm 👩‍💻 и RustRover.

⚙️ Прототипирование UI: Готовьте ваши тапки, на сцене снова Draw.io! Причины те же, что и в пункте с моделированием, а также хочу сказать, что у Draw.io есть классная типа "либа" Bootstrap как раз для прототипирования интерфейсов, очень удобно. Figma 👩‍💻 мне не очень удобна, это вообще скорее для дизайнеров, пробовал еще Pencil — тоже не фонтан. Из популярных помню Miro и Unidraw, коллеги на проекте ими пользуются, я не очень.

⚙️ AI: Ну, конечно, куда сейчас без него. В основном это DeepSeek и ChatGPT, ничего изощренного. Основные Use Cases: набросать код Mermaid для диаграммы по описанию, составить шаблон какого-нибудь дока, иногда SQL-запрос или просто накидать идей для дальнейшей проработки. Конечно, любой результат работы чудо-машины нужно править руками, а просить написать Эй-Ай доку... Это просто не работает, поэтому все доки я всегда пишу руками, но надо сказать, что они у меня чертовски хороши.

⚙️ Всякое прочее разное: Бывают штуки, которые используешь редко, но иногда они пригождаются. Всякие JsonValidator, Grafana, Prometheus... Paint. ✏️ (Нет).

⚙️ Телеграмчик: Чтобы постить всякое себе в канал. Огромное спасибо за Markdown разметку, я ее обожаю.

Философский финал в восточном стиле: Ученик попросил мастера показать его лучшую кисть. Мастер указал на свою руку. 🎨

#системныйанализ #инструментарий #диаграмма #bpmn #UML #confluence

🖥Тестирует ли что-нибудь системный аналитик?
Мой ответ на данный вопрос будет провокационный, потому что я считаю, что... Да, аналитик может принимать участие в тестировании, но...

Есть один нюанс.

🛠 В разработке любого сложного программного продукта обычно принимает участие QA, который выполняет огромное количество разных видов тестирования: ручное функциональное, нагрузочное, регрессионное тестирование, white box/black box, тестирование как негативных, так и позитивных сценариев и чёрте что еще. ⚙️
Системный/fullstack аналитик — это по традиции человек-оркестр (мемчик на эту тему прилепил к посту), но все-таки весь спектр задач тестировщика на него взвалить не получится. 🤪Тем не менее, два вида тестирований, в которых я стараюсь участвовать:

➡️Функциональная приемка — это ручное функциональное тестирование позитивного сценария сразу после того, как разработчик выполнил задачу и задеплоил ее на тестовый стенд (хотя в некоторых случаях я разворачиваю доработку у себя локально для этих целей). Основная задача тут — верхнеуровнево провалидировать соответствие выполненной работы заявленным требованиям и аппрувнуть выполнение со своей позиции. Либо заранее начать бухтеть, если что-то не соответствует с моей точки зрения.
➡️User Acceptance Testing — все то же самое, но уже совместно со стейкхолдером/ключевыми пользователями. Посидеть вместе, потыкаться в новую функциональность, собрать ОС.

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

Как обычно философствую в конце: участие системного аналитика в тестировании — это не про поиск багов, а про валидацию ценности. Хотя, если честно, находить и описывать баги тоже периодически приходится.

#SystemAnalysis #Тестирование #QA #UAT #ФункциональнаяПриемка #BusinessAnalysis

🔛 Фича-флаги: что делать, чтобы не класть весь прод разом
Честно скажу, я совсем недавно узнал, как это на самом деле называется: Feature Flag. Я, в общем-то, всегда звал это просто — рубильник. 💩 Ну да ладно, короче, к сути.

Фича-флаг, он же Feature Toggle, а также Feature Flag (как же чертовски круто это все звучит) — это переключатель, который позволяет включать или выключать функциональность в работающем приложении без перевыпуска кода.

Ну грубо говоря как-то так:

if feature_flag.is_enabled('new_payment_system'):
    use_new_payment()
else:
    use_old_payment()

После того, как по моим постановкам пару раз положили прод там, где лучше бы этого было не делать, я начал частенько прописывать необходимость рубильника. ✅ (Чтобы я не сидел потом, как эта несчастная псина на картинке).

Зачем вообще это все нужно?
🟣Безопасные релизы. Увидели проблему? ➡️ Выключаем тумблер ➡️ Фича не работает, хотя код уже в проде.
🟣Dark Launches. Можно задеплоить код в прод, но не показывать его пользователям (пока не пришло время).
🟣Условный доступ: включить фичу только для внутренних тестировщиков/конкретной группы пользователей.
🟣Для A/B-тестов, но это для PO, наверное, интересно, я за такое вообще не шарю. 🤷 Просто знаю, что так делают.

Какие есть способы дернуть рубильник?
🔴Таблица в БД: плюс в том, что возможно динамическое изменение без перезапуска. Минусы — нужна соответственно инфраструктура (сама БД).
🔴Переменные окружения. Переключение через .env файл достаточно просто реализовать, но из минусов — переключение флага скорее всего потребует перезапуска.
🔴Конфигурационные файлы (JSON, YAML, TOML, .properties) — примерное те же минусы и плюсы, что в случае с переменными окружения.
🔴Специальные сервисы фича-флагов (их, оказывается, много всяких есть): LaunchDarkly, Split, Flagsmith, Unleash, CloudBees Feature Management. Тут и гибкость в настройке, и изменения в режиме реального времени, но с другой стороны зависимость от еще одного сервиса.

Что важно учитывать:
⚠️ Постараться Не забывать убирать флаги после полного внедрения фичи;
⚠️ Постараться Документировать флаги — какие есть, для чего, кто отвечает;
⚠️ Постараться Не превращать систему в спагетти-код из условий.

In conclusion: Фича-флаги — это не просто технический инструмент, это стратегия безопасной поставки изменений.

#SystemAnalysis #FeatureFlags #Разработка #python #IT #businessanalysis

✍️ Нормально делай — нормально будет: пост о нормализации БД

Наверное, как бы качественно и продумана ни была бы БД на старте проекта (на этапе Proof of Concept или MVP), если продукт развивается, если добавляются новые фичи, логика, бизнес-процессы и т.д., то скорее всего рано или поздно все-таки потребуется что-то в имеющейся модели данных перестроить. 👷 Один из способов реорганизации БД называется нормализацией. Собственно, вот и у меня сейчас есть потребность в нормализации некоторых таблиц в БД, что привело к идее поста. 🥺 Кстати, одну таблицу при этом придется денормализовать, так как выделенная в рамках таблицы сущность является излишней с точки зрения бизнес-объекта. 💥 Да, и такое бывает.

Нормализация — это процесс организации данных в базе для устранения дублирования и обеспечения их целостности. Часто её представляют как строгий этап проектирования, который нужно выполнить перед написанием первой строки кода. 🌳 Однако на практике всё часто иначе: нормализация становится необходимым шагом уже в процессе развития работающей системы. И не потому что "жмяк-жмяк и в продакшн", а потому что система растет и процессы усложняются.

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

По канону есть три фазы нормализации (вспомню свое ERP-прошлое, поэтому разберу на примере с заказами на поставку):
1️⃣ Первая нормальная форма (1NF)
Цель: Убрать повторяющиеся группы и сделать все значения атомарными.
Действие: Если в заказе может быть несколько товаров, их нужно вынести в отдельную таблицу.

CREATE TABLE orders (order_id INT PRIMARY KEY, customer_name VARCHAR, customer_phone INT, order_date DATE);
CREATE TABLE items (item_id INT PRIMARY KEY, order_id INT NOT NULL, product_name VARCHAR, product_price NUMERIC(10, 2), FOREIGN KEY (order_id) REFERENCES orders(order_id));

2️⃣ Вторая нормальная форма (2NF)
Цель: Устранить зависимость неключевых полей только от части составного ключа.
Проблема: Цена и название товара в items зависят только от product_name, а не от всей пары (order_id, product_name).
Действие: Создаём справочник товаров.

CREATE TABLE products (product_id INT PRIMARY KEY, product_name VARCHAR NOT NULL, price NUMERIC(10, 2));
CREATE TABLE items (item_id INT PRIMARY KEY, order_id INT NOT NULL, product_id INT NOT NULL, price_at_order NUMERIC(10, 2), FOREIGN KEY (order_id) REFERENCES orders(order_id));

3️⃣ Третья нормальная форма (3NF)
Цель: Убрать транзитивные зависимости, когда поле зависит не от первичного ключа, а от другого поля.
Проблема: Телефон клиента в таблице orders зависит от его имени, а не напрямую от order_id.
Действие: Выносим данные о клиенте в отдельную сущность.

CREATE TABLE customers (customer_id INT PRIMARY KEY, name VARCHAR NOT NULL, phone INT);
CREATE TABLE orders (order_id INT PRIMARY KEY, customer_id INT NOT NULL, order_date DATE NOT NULL, FOREIGN KEY (customer_id) REFERENCES customers(customer_id));

По традиции философский вывод: главный критерий необходимости нормализации — не объём данных сам по себе, а появление требований, которые сложно или рискованно реализовывать в текущей денормализованной модели.

P.S. Во время подготовки поста ни одно дерево не пострадало я пользовался прикольным SQL-валидатором, чтобы чекать, что у меня не совсем дичь в запросах написана (может, кому тоже пригодится): SQL-Validator.

#SystemAnalysis #БазыДанных #Нормализация #SQL #DataModeling #postgresql #erd #системныйанализ

🚨 Не войти не в ту дверь: идентификация, аутентификация, авторизация

📣Пост навеян интересной движухой у нас на работе, а именно — проектированием системы управления доступом, IAM. Не вдаваясь в детали, проектировать будем с самого нуля и я скажу честно, это видится интересной задачей. Ввиду текущей загрузки я ей буду заниматься мало, но буду менеджерить работу по ней и помогать новому коллеге-аналитику. В любом случае будет увлекательно! 🐈

Итак, пару слов о IAM. IAM — Identity and Access Management, управление идентификацией и доступом. Этот термин включает в себя все три компонента: идентификация, аутентификация и авторизация. Чуть детальнее:
✅ Идентификация — процесс распознавания пользователя. Иными словами, необходима для того, чтобы разобраться с вопросом: "Вы кто такой? Я вас не звал..." В контексте ИТ-продуктов: пользователь предоставляет email/номер телефона/логин (классика), публичный ключ (в асимметричных схемах), Client Certificate (для mTLS), whatever, сообщая тем самым системе свой уникальный идентификатор. В результате система понимает, под каким именем вы хотите работать и должна провалидировать в принципе наличие такого идентификатора. Это не даёт доступа, это просто декларация.
✅ Аутентификация — проверка заявленной идентичности. После успешной аутентификации система создаёт для пользователя сессию (хранимую на сервере или в БД) или выдаёт подписанный токен (например, JWT). Механизмы делятся по типу проверяемого фактора:

🔘Что вы знаете (Knowledge): пароль, pin-код;
🔘Что у вас есть (Possession): OATH TOTP (коды из приложений типа Google Authenticator), FIDO2 / WebAuthn (аппаратные ключи — Yubikey), мобильное приложение с push-подтверждением;
🔘Что вы есть (Inherence): Биометрия (отпечаток, лицо).

✅ Авторизация — предоставление прав на выполнение определённых действий или доступ к ресурсам после успешной аутентификации, иными словами — разделение по ролям. В рамках одного и того же ИТ-продукта у кого-то будет годмод (например, у специалиста поддержки), а кому-то можно будет только посмотреть. Реализовать авторизацию можно непосредственно в коде приложения/микросервиса, через API Gateway или на отдельном сервере авторизации. Из современных подходов можно отметить:

🔘RBAC (Role-Based Access Control): Классика. Пользователю назначается роль (ADMIN, EDITOR, VIEWER), а роли привязаны к разрешениям. Реализуется через таблицы в БД или специализированные сервисы.
🔘ABAC (Attribute-Based Access Control): Гибкая модель. Решение принимается на основе атрибутов пользователя, ресурса, действия и контекста.
🔘ACL (Access Control Lists): Простое прикрепление списка разрешений прямо к ресурсу («Кто может читать этот файл»). Это подходит только к очень простым сценариям.

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

В качестве вывода: разделение процессов IAM — основа для проектирования безопасной, понятной и масштабируемой системы управления доступом.

#SystemAnalysis #безопасность #авторизация #аутентификация #архитектура #системныйанализ #cybersecurity

➡️ Agile vs Waterfall: философия планирования разработки

🤔 Последнее время периодически ловлю себя на том, что где-то в закулисье подсознания у меня происходит переосмысление отношения к гибким методологиям разработки, а именно — к Agile. Так что сегодня будет воскресный пост как раз про этот ваш Agile, а именно про фреймворк Scrum. 🥊 В противоположном углу ринга мы разместим каскадную модель Waterfall и прикинем, с кем из этих двоих мы будем меньше деплоить кринжа на прод сможем эффективнее поставлять ценность заинтересованным сторонам. 🎩

Начнем с Agile и сразу оговоримся — тут, конечно, каждый сам себе что-то напридумывал, сам как-то себе его понимает и в целом, надо сказать, Agile принято называть не столько методологией, сколько системой ценностей и принципов. 🤔 Т.е., тут у нас никакой строгости, тоталитаризма, разве что парочку ритуалов исполнять нужно, а чтобы точно никто ни в чем наверняка не разобрался — вот вам Манифест Agile, там все написано.

Ближе к делу:
🟢Agile (Гибкая методология): Итеративный и инкрементальный подход. Работа разбита на короткие циклы (спринты, итерации). План пересматривается в конце каждого цикла на основе обратной связи и новых данных.
🟢Waterfall (Каскадная модель): Последовательный линейный процесс. Этапы идут строго друг за другом: Сбор требований ➡️ Дизайн ➡️ Разработка ➡️ Тестирование ➡️ Внедрение. План, бюджет и сроки фиксируются в начале.

Закономерный вопрос:

А что, в Agile нет процесса сбора требований, дизайна системы, разработки, тестирования и релиза?

Да нет, все это мы тоже там делаем... Может, мы сначала тестируем, а потом разрабатываем? Ну это ж совсем бред какой-то. 🤪

В чем тогда суть-то?
Весь смысл в единице планирования. В Waterfall единица платнирования — потребность, это Scope-Driven подход, в Agile единица планирования — время (Time-Boxed). В каскадной модели у нас определен scope работ и мы решаем, за сколько времени мы можем это сделать. В гибкой модели в фокусе только время, а точнее — фиксированный отрезок времени, которым мы мерим все. Фиксирована длина спринта (time-box) — 1, 2, 3 недели и мы под это время подстраиваемся, решая, а что полезного мы сможем сделать за условные две недели. ⏳

Зафиналим: все эти дейлики, ретро, скрам мастера, стендапы и прочие атрибуты Agile в конечном счете не являются сутью. Все, что действительно важно — это конкретный отрезок времени, в котором команда будет перформить. Это непривычно, что мы не ставим во главу угла глобальный результат, ведь там у нас лишь двухнедельные циклы и надежды на то, что в итоге мы придем к чему-то крутому. Это не лучше и не хуже "водопада", само по себе это не позволит быстрее или качественнее пилить фичи, просто это попытка компенсировать уровень неопределенности при разработке. 🏖

#SystemAnalysis #Agile #Waterfall #УправлениеПроектами #Scrum #BusinessAnalysis

🌚 Не только реляционные, но и NoSQL: как мы используем MongoDB

Вообще, основная БД на проекте у на PostgreSQL 👩‍💻 ("Surprise Motherfucker", кто бы мог догадаться?), однако для пары сервисом у нас также подключена MongoDB 👩‍💻, там у нас всего несколько таблиц коллекций и в частности у нас там хранятся данные по парковкам.

Кратко про отличия:
🟡PostgreSQL (реляционная модель): Данные структурированы, разложены по таблицам со строгой схемой. Связи между таблицами обеспечиваются внешними ключами. Работа строится на языке SQL и операциях JOIN.
🟡MongoDB (NoSQL): Данные хранятся в виде гибких JSON-подобных документов в коллекциях. Схема может быть динамической, нет строгих связей, упор делается на вложение данных и денормализацию (кстати, про нормализацию у меня был пост вот тут, кому интересно).

В чем преимущество хранения данных в MongoDB? Прежде чем отвечать на этот вопрос, хочется уточнить, что определенная модель данных для парковок у нас есть и в Postgre, но конкретно в рамках данного микросервиса, который интегрируется с одним открытым API с данными о парковках, удобнее было сделать Mongo:
1️⃣ Все данные — это фактически просто JSON, практически в том же виде, в каком мы получаем данные по API;
2️⃣ Легкое моделирование иерархических данных: структура типом парковки, адресом и координатами в рамках одного документа. В реляционной БД соответственно потребуется несколько таблиц, которые нужно будет джоинить;
3️⃣ Производительность при чтении. Это пункт, вытекающий из предыдущего. Для получения всех данных о парковке мы делаем один запрос по _id;
4️⃣ Встроенная геопространственная поддержка. Легко работать с GeoJSON (вообще в Postgre тоже можно и это не сложно с помощью расширений, таких как PostGIS, но я все-таки добавлю это в плюс для Монги). В рамках одной фичи я вообще хотел бы тут реализовать определение отношения координаты к обрасти (полигону координат) через 2dsphere для MongoDB, но это пока планы на будущее;
5️⃣ Шардинг из коробки: возможность горизонтального масштабирования за счет шардирования без дополнительных активностей.

Конечно, использовать везде MongoDB не получится и реляционные БД еще долго будут оставаться основным способом хранения данных. Недостатки NoSQL модели (конкретно Монги):
1️⃣ Отсутствие Join. Да-да, я чуть выше указал, что нам не нужно использовать джоины в Монге ввиду некоторых ее преимуществ... Но иногда почти всегда они все-таки нужны, чтобы связывать данные из разных таблиц. Тут же, чтобы связать данные из двух коллекций, нам нужно будет сделать два отдельных запроса;
2️⃣ Избыточность данных. С одной стороны, здорово, что все данные об одной парковке у нас в рамках одной записи, с другой стороны в рамках каждой записи у нас есть, например, информация о категории парковки.
3️⃣ Всякие технические ограничения в виде проблем с консистентностью, ограничением транзакций, неполной поддержкой ACID. Все это делает Монгу недопустимой к использованию во всяких бухгалтерских, финансовых, платежных и других требовательных к транзакционности системах (объединил все в один пункт, чтобы не писать много).

Попробую сделать какой-нибудь вывод: MongoDB отлично подходит для определенных сценариев (Каталоги, Документ-ориентированные данные и т.д.), но важно понимать ее ограничения и правильно оценивать требования проекта.

#SystemAnalysis #БазыДанных #MongoDB #PostgreSQL #NoSQL #Архитектура #BusinessAnalysis #системныйанализ

😄 Нет, на самом деле наша последняя рабочая неделя не похожа не этот мемчик сверху. 👆У нас уже вторую неделю, как фриз на деплой: все хотят провести праздники спокойно. 🎁
До 🔠🔠 осталось всего ничего, сил пилить вдумчивые посты совсем не осталось, так что до конца объявляю серию постов на расслабоне. 😴

И раз уж я тут упомянул про фриз на деплой, поделюсь историей из своей практики, когда такое решение не подходило. Истории этой два года и я тогда еще работал в ERP-домене. Я делал очень большую фичу, связанную с контролем платежных бюджетов и проведением платежей. Это все делалось в рамках ERP огромной компании, в которой велись тысячи разных бизнес-процессов для сотен филиалов и дочерних обществ и сама эта фича — большая разработка, фактически система внутри системы. А самая хитрость была в чем? Старт промышленной эксплуатации должен был быть ровно с начала календарного года, чтобы все финансовые процессы (связанные с этой системой) стартовали уже в рамках нее. Сразу уточню: возможность не привязываться к началу года с последующим проведением миграции данных рассматривалась, но было принято решение, что это практически невозможно будет сделать безболезненно. 💭

Короче, стартовали с нового года. Предварительно задеплоили все на прод, я расставил фича-флаги, чтобы все это работало только с первого января (кстати, тут у меня был пост про фича-флаги, кому интересно), а после этого укатил на зимние праздники в женой в ОАЭ на Фуджейру. 💨 С одной стороны, было очень много тестов фичи, проверок и так далее, с другой — огромное количество зависимостей... Короче, покрыть все тестами не получилось, а я, как аналитик, упустил часть контекста системы при разработке (ввиду ее, системы, огромности), что в определенных ситуациях приводило к неправильной работе.

В общем, бизнес начал уже колотить документы в системе, не все идет гладко, а на работе с доступом к системе один дежурный программист, который вообще вне контекста доработки, и ребята из поддержки (спасибо им, они прикрыли мою жопь и нашли много решений в моменте, чтобы продержаться до глобального исправления ❤️). Я на пляжике с телефоном без доступа к логам, отладке, только со скриншотиками пытаюсь придумать, как обойти какие-то баги, продержаться до конца праздников, вернуться и все исправить. Все, конечно, хорошо закончилось, но было стрессово. Улетать из ОАЭ тогда очень не хотелось. 😏

Вывод: лучше не деплоить перед НГ, даже если очень хочется.

#SystemAnalysis #BusinessAnalysis #системныйанализ #личныйопыт #erp #разработка

😊 Все чаще отовсюду слышим, что скоро нас всех заменить AI. Что ж, хотел бы я посмотреть, как этот ваш AI накидается в дрова на скорость с девопсами на корпоративе. 🥃
У нас вчера был копроратив, это было очень круто, а тем временем тут я продолжаю серию предновогодних постов. 🎁

#личное #новыйгод