SA | IT | Александр Турченко

Хм..🤔

Если бы меня спросили, какими навыками должен обладать человек, чтобы стать системным аналитиком, я бы назвал эти 5 пунктов.⬇️

1⃣ Умение слушать и задавать вопросы
Не принимать требование как единственно верное, а разбираться в сути проблемы. Постоянно задавать вопросы: «Почему?», «Для чего это нужно?», «Какую проблему мы решаем?». Иногда выясняется, что задачу можно упростить или она вообще не нужна.

Пример:
Заказчик просит «сделать уведомления по email при каждом статусе заказа». Аналитик уточняет, сколько статусов и правда важны получателю. Выясняется, что важны только 2 из 7 статусов, остальные — техническая информация, которая только спамит и не нужна пользователю.

2⃣Презентация/умения объяснять
Уметь понятно доносить информацию до разных участников проекта: разработчиков, тестировщиков, стейкхолдеров. Включает согласование решений и защиту своей позиции, если предложенный вариант проще или правильнее.

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

3⃣ Умение договариваться
Часто у заказчика, разработки, менеджмента и других участников проекта разные интересы и ожидания. Аналитик должен находить компромисс и помогать команде прийти к решению, которое устроит всех и будет реализуемо.

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

4⃣ Структурное мышление
Умение превращать большой объем информации в понятную структуру. Выделять главное, систематизировать требования, строить схемы процессов и оформлять документацию так, чтобы она была понятна всей команде.

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

5⃣ Адаптивность
В проектах требования и задачи могут меняться. Заказчик передумал, появились новые вводные, приоритеты сдвинулись. Аналитику важно быстро перестраиваться, учитывать изменения и актуализировать требования.

Пример:
Команда неделю прорабатывала требования к одной фиче. Затем бизнес меняет приоритет, в фокус попадает другая задача. Аналитику нужно быстро разобраться в новых требованиях, зафиксировать их и объяснить команде, что изменилось и почему.


А какие навыки назвали бы вы?? 🤔

🤩🤩🤩🤩

Сегодня разбираем CQRS: что это за паттерн, какие у него плюсы и минусы, и когда его действительно стоит внедрять. 😊

Сегодня разбираем RBAC и ABAC, две популярные модели управления доступом.

В карточках:
🤩что такое управление доступом
🤩что такое RBAC
🤩что такое ABAC
🤩примеры использования
🤩сравнение RBAC и ABAC

А вы знакомы с этими моделями?
☺️ — да, знаком(а)
🦆 — нет, слышу впервые

🔥 Мини-задача

Есть рюкзак и набор вещей для похода.

Что нужно сделать:
🔣положить в рюкзак все вещи, кроме фонарика
🔣заменить бутылку воды на термос
🔣положить аптечку в рюкзак
🔣проверить, все ли нужные вещи лежат в рюкзаке
🔣достать карту из рюкзака

Вопрос:
какие HTTP-методы вы бы использовали для каждого действия?

Пишите свои варианты в комментариях ↘️

Как вы считаете, как часто нужно менять работу?

И что должно быть поводом для смены: отсутствие роста по ЗП, выгорание, отсутствие интересных задач, токсичная команда или просто прошло 1–3 года и пора двигаться дальше?

Название звучит как начало мексиканского фильма, но речь пойдет о рабочем подходе. 🧑‍🌾

3 amigos (Three Amigos) — это встреча перед стартом разработки конкретной задачи, на которой сходятся три точки зрения для обсуждения предложенного решения, выявления возможных альтернативных сценариев, а также для формирования общего понимания контекста.

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

🔣Кто входит в команду «3 amigos»?

🔣Бизнес — отвечает за бизнес-контекст, цели, ценность функционала и ожидания пользователей.
🔣Разработка — оценивает решение с технической точки зрения, выявляет ограничения и предлагает варианты реализации.
🔣Тестирование — смотрит на требования с точки зрения проверяемости, тестовых сценариев, рисков и возможных edge cases.

Состав встречи не обязательно ограничивается тремя ролями, всё зависит от задачи, затронутых систем и участников, которые нужны для её проработки.

🔣 Как проходит?

1. Подготовка к встрече
Перед встречей важно подготовить базовый контекст по задаче:
🔣описание задачи и цели изменений;
🔣основные требования и сценарии;
🔣ограничения, зависимости и спорные моменты;
🔣вопросы, которые нужно обсудить с командой.

2. Проведение встречи
На встрече участники вместе разбирают задачу:
🔣обсуждают предложенное решение;
🔣уточняют требования и ожидания;
🔣рассматривают альтернативные сценарии;
🔣выявляют риски, ограничения и неочевидные кейсы;
🔣фиксируют вопросы, которые требуют дополнительной проработки.

3. Итоги встречи
По итогам встречи у команды должно быть общее понимание:
🔣что именно нужно реализовать;
🔣какие требования и сценарии согласованы;
🔣какие риски и ограничения учтены;
🔣какие вопросы остались открытыми;
🔣кто и что должен доработать перед стартом разработки.

🔣Главные преимущества

🔣Единое понимание задачи
Участники заранее синхронизируются по контексту, требованиям, ограничениям и ожидаемому результату.

🔣Меньше недопонимания в разработке
Спорные моменты и неочевидные сценарии обсуждаются до старта реализации, а не во время разработки или тестирования.

🔣Раннее выявление рисков
Команда заранее замечает технические ограничения, пробелы в требованиях, сложные edge cases и потенциальные проблемы.

🔣Более точные требования
За счёт разных точек зрения требования становятся полнее, понятнее и лучше подготовленными к реализации.

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


Делитесь, какие подходы вы используете в команде ⬇️⬇️

🤩🤩🤩

Недавно на собеседовании мне задали вопрос:
«Что такое CMS?»
А я в голове такой:
«ЦМ… что?» 🔨
Понял, что не понимаю, о чём речь. Поэтому решил разобраться, что это такое, и заодно написать об этом. 📝

Популярные CMS
🤩WordPress
🤩1C-Битрикс
🤩Joomla
🤩Drupal
🤩OpenCart

А вы используете CMS в своём проекте? 🤩
🥰 — Да
⛔️ — Нет
🐶 — Не знаю, что используется в проекте

💜🔸🟨🛅🌷🧡🔸 🛅💮🔽🔽👉🔸💜

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

Логика функции уже находится в коде, но её доступность управляется через флаг, специальный переключатель. Это позволяет гибко запускать изменения и контролировать, когда и для кого функция будет активна.

⭐️ Чем отличается от обычного релиза

➖Обычный релиз — выкатили код, и новая функция сразу стала доступна пользователям.
➖Релиз с Feature Toggles — код уже выкатили, но саму функцию можно включить позже и отдельно управлять её доступностью.

⭐️ Как применяются

➖Постепенный запуск
Фичу сначала включают для небольшой части пользователей. Если всё работает стабильно, постепенно расширяют на всех.

➖Тестирование
Разным группам пользователей можно показывать разные варианты функции и сравнивать метрики. Это удобно для A/B-тестов и проверки гипотез.

➖Быстрое отключение
Если новая функция работает нестабильно, её можно сразу выключить. Остальная часть приложения при этом не затрагивается.

➖Доступ для отдельных групп
Функцию можно включать только для отдельных групп пользователей: сотрудников, тестировщиков или VIP-пользователей.

⭐️ Где может жить логика

➖На фронтенде
➖На бэкенде
➖В gateway или edge-слое
➖В фоновых процессах (jobs)


А вы знакомы с Feature Toggles? 🤩🤩

😎— Да, используем в работе

💩— Слышал(а), но не применял(и)

🤔 — Нет, только узнал(а) сейчас