Зачастую бизнес‑объекты в информационных системах хранятся в классических реляционных базах данных, где каждому атрибуту объекта соответствует колонка в таблице.

Чтобы изменить такую объектную модель, например, добавить или удалить атрибут, нужно внести изменения в схему базы данных, то есть выполнить DDL‑операцию. Она сопровождается блокировками таблиц и увеличением времени простоя при работе с данными. Кроме того, при увеличении числа атрибутов можно превысить ограничение на количество колонок в таблице. Например, в Postgres их можно создать не более 1600.

Эти проблемы можно устранить, используя хранение данных в формате JSON. Основные преимущества такого подхода:

• отказ от фиксированной структуры таблиц;

• гибкость без необходимости изменения схемы.

Обращение к динамическим полям может осложниться при работе с Hibernate до версии 6.2. Более ранние версии не позволяют обращаться к полям внутри JSON на уровне HQL, что ограничивает возможности фильтрации и сортировки. Поэтому оптимальный вариант — использовать Native SQL. Hibernate позволяет регистрировать SQL‑функции, чтобы вызывать их из HQL‑запросов. Пример регистрации такой функции для Postgres приведен ниже:

registerFunction("jsonQuery",
    new SQLFunctionTemplate(StandardBasicTypes.STRING,
        "jsonb_path_query_first(?1, ?2)::varchar"));

• Первый параметр — колонка в БД, внутри которой хранится JSON, выполняющий запрос.

• Второй параметр — запрос в виде JSON Path, который позволяет добраться до определенных полей.

Пример структуры JSON и использования на ней SQL-функции в запросе:

{
  "CPU_Brand": "Intel",
  "CPU_Model": "Xeon 8380",
  "RAM_Size_GB": 64
}

SELECT obj.id
FROM userObject obj
WHERE jsonQuery(obj.json, '$.CPU_Brand') = 'Intel'

При работе с более сложными вещами, например, фильтрация объектов с вложенными данными, SQL Server требует применения конструкций CROSS APPLY и openjson.

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

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

1. Обращайтесь за помощью к коллегам в сложной ситуации и не бойтесь задавать вопросы.

2. Сохраняйте фокус на конечной цели — решение задачи для конкретного пользователя.

3. Практикуйте публичные выступления, активно участвуйте в дискуссиях и не пренебрегайте общением с коллегами и офлайн‑коммуникациями.

4. Защищайте свои границы при взаимодействии с другими людьми и учитесь «держать планку» в конфликтах.

5. Работайте над образом надежного и ответственного профессионала, соблюдайте дедлайны и выполняйте договоренности.

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

Неопределенность — одна из главных трудностей, с которой аналитик сталкивается при обработке требований в сфере информационной безопасности (ИБ). Требования часто сформулированы расплывчато и без конкретики. В процессе внедрения программных продуктов имеется классический набор требований из нормативной документации: ИАФ, УПД, ОПС, РСБ и т.д. В части реализации мер по регистрации событий ИБ (РСБ) аналитик внедрения сталкивается с несколькими группами требований:

1. Общие требования задают базовые правила для защиты данных, определяют сроки хранения и перечень источников событий, которые необходимо фиксировать. 

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

3. Состав полей событий безопасности наполнен идентификатором события, датой и временем, результатом выполнения, идентификатором субъекта, объекта или ресурса доступа и другими данными. Чтобы корректно определить состав, важно учитывать потребности инженера ИБ со стороны заказчика. 

4. Мониторинг предусматривает проработку механизмов просмотра и анализа, передачи в SIEM-систему. 

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

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

Чтобы этого избежать, аналитики и продакты проводят приемку аналитики. Аналитик, проработав задачу и определив, как ее лучше решить, приносит свое видение продакту еще до начала разработки. В ходе обсуждения они вместе корректируют спорные моменты и приходят к общему решению. Это позволяет объединить разные взгляды и улучшить качество финального результата.

Три важных плюса приемки аналитики:

1. Два взгляда на решение — сокращается количество ошибок, команда на несколько шагов ближе к истине и идеальному решению.

2. Действия согласованы — продакт заранее знает, что именно будет реализовано и может объяснить на этапе тестирования или демонстрации продукта, почему сделано так, а не иначе.

3. Усилия команды объединены — аналитик не остается один на один с задачей и понимает, что совместная работа помогает эффективнее выполнить задачу, улучшить реализацию и повысить удовлетворенность команды и клиентов.

Аналитик в своей работе стремится найти решение: прийти к определенному выводу, сделать прогнозы, составить требования к работе системы. Иногда он слишком погружается в эти процессы и буквально живет поиском решения задачи. А когда находит — «влюбляется»‎ в это решение. Чрезмерная уверенность в своей правоте приводит к отторжению любых альтернатив и интерпретации информации в свою пользу. 

Происходит это по нескольким причинам: 

• специализация на одной области,

• предвзятое мышление,

• стремление к идеальному результату, без учета реальности или ограничений. 

Чтобы не допустить «‎влюбленности»‎ в свое решение, важно:

1. Проверять гипотезы — подвергать свое решение сомнению, формулировать его как гипотезу, которую нужно проверить. 

2. Рассматривать альтернативные решения — задавать себе вопрос «А как еще можно достичь этих целей?».

3. Расширять фокус и обучаться — смотреть на решение с позиции наблюдателя и быть открытым для новых идей и подходов.

4. Получать обратную связь — не бояться критики, коллеги могут заметить то, что было пропущено.   

«‎Влюбленность»‎ в свое решение может поставить работу в тупик. Поэтому необходимо сохранять гибкость и быть готовым рассматривать альтернативные подходы. А еще помнить, что решение — это не характеристика человека. Оно может быть как правильным, так и неправильным, как идеальным, так и не очень.

Аналитику на проектах или продуктах приходится довольно много работать с требованиями. А в сложных проектах, исследованиях и стартапах неопределенность требований — достаточно частое явление. На 100% избавиться от неопределенности не получится: мы не можем контролировать абсолютно все. Но зато можем снизить риски и исключить потери для компании за счет снижения неопределенности. 

Вот небольшой план действий, который поможет работать в условиях неопределенности:

• Создайте mindmap и используйте как базу знаний, чтобы исключить вероятность что-то упустить.

Как создать mindmap: разбиваете свою зону ответственности на области неопределенности → раскладываете области на аспекты → аспекты разделяете на вопросы, на которые нужно ответить и получить решение, и инструменты, которые нужны для ответа на вопросы.

• Составьте чек-лист для типовых задач — так вы сможете быстро выполнять стандартные задачи, особенно если это срочные дела: в помощь аспекты, вопросы и инструменты из mindmap’а.

• Уточняйте вопросы при помощи инструментов.

• Действуйте итеративно — всегда возвращайтесь к тем вопросам, которые сразу не удалось прояснить.

• Если кажется, что что-то упустили, перепроверяйте.

• Актуализируйте — если появляются новые инструменты и вопросы, которые помогли уточнить необходимую информацию, добавляйте их в mindmap.

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

Умение задавать вопросы и делать это своевременно — один из самых полезных навыков. Во-первых, это ускоряет процесс, а, во-вторых, в результате получается именно то, что нужно клиенту. Вроде всё просто. Но почему мы продолжаем пренебрегать вопросами, положившись на «потом как-нибудь разберусь»? Всему виной страх осуждения и боязнь выглядеть некомпетентно. Отсюда получаем: незаданный вопрос — невыявленную потребность — несобранные требования — реализованный не в полном объеме проект. Коммуникация провалена на самых ранних этапах. Рассказываем, как же её наладить и почему не стоит бояться задавать глупые вопросы.

1. Помните: самый глупый вопрос — незаданный вопрос.

2. Задавайте уточняющие вопросы (даже если их много). Чем больше информации на старте проекта, тем меньше проблем в конце.

3. Перепроверяйте поступающую информацию от клиента — он тоже человек и может ошибаться, а еще искажать факты или умалчивать то, что «очевидно». 

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

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

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