Когда задача считается выполненной

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

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

Мы поговорили с коллегами и попросили их рассказать, в какой момент для них задача считается завершенной. Их ответы читайте ниже.

Настя, тестировщик:

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

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

Ваня, системный аналитик:

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

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

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

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

Олег, android-разработчик:

Задача выполнена, когда:

1. Функциональность реализована и проверена вручную — примерно так, как это сделал бы тестировщик, но без учета конкретных тест-кейсов.

2. Новое поведение решает цель задачи, а не просто повторяет постановку. Иногда по ходу работы находится вариант проще для разработки/поддержки или удобнее для пользователя — выбираю его. Фича должна закрывать потребность.

3. Пограничные случаи поведения (corner cases) проработаны и учтены. В постановке не всегда учитываются моменты, которые становятся заметны в коде. Например, что показать на мобильном клиенте при 500 ответе сервера или при долгой загрузке из-за задержки ответа сервера.

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

5. Новое поведение поддерживаемо и расширяемо: его сможет понять и продолжить другой разработчик.

Как развивать документацию и продвигать техписателей

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

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

С чего вообще началась эта работа и какую задачу вы перед собой ставили?

Мы начали с целей. Во‑первых, хотелось сформировать понятное представление о роли технических писателей внутри команды. Во‑вторых — понять, чего заказчики действительно ждут от документации.

Как вы к этому подошли на практике?

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

Еще мы выделили ключевых заказчиков и сгруппировали их. Это были аналитики и руководители продуктов, разработчики и тестировщики, поддержка, инженеры инфраструктуры, коллеги из маркетинга и дизайна. Благодаря этому вместо 51 интервью получилось провести 19, этого оказалось достаточно.

Как проходили интервью и что оказалось самым сложным?

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

Сложнее всего было работать с эмоциональными запросами. Потому что важно не останавливаться на эмоции, а докапываться до сути. Очень помогал метод «5 почему»: позволяет превратить раздражение в конкретное и решаемое требование.

Что получилось после обработки всех интервью?

Мы сгруппировали потребности и получили 12 направлений. Самые заметные — это нехватка понимания роли технических писателей, запрос на обновление интерфейса документации и очень сильная боль у разработчиков по поводу документации по API.

Как вы поняли, за что браться в первую очередь?

Использовали простой фреймворк приоритизации «ценность / усилия». Смотрели не только на то, как часто звучит проблема, но и на силу боли. Поэтому, например, поиск в документации стал приоритетнее аналитики — о нем говорили реже, но намного острее.

Какие результаты уже есть?

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

Твой главный вывод из этого опыта?

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

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

Рассказываем, на что обращаем внимание при проверке верстки и какие моменты проверяем в первую очередь.

1️⃣ С чего начинаем тестирование верстки?

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

• максимально короткие значения — точка, пробел;

• максимально длинный текст, который можно ввести;

• соответствие ограничениям из постановки — например, максимально доступно 64 символа.

Если ограничений в ТЗ нет, смотрим, какой тип поля используется в базе данных. Часто это varchar(255), от этого и отталкиваемся при проверке.

2️⃣ Почему проверяем текст с пробелами и без?

Очень частый кейс: текст с пробелами красиво переносится, а без пробелов — вылезает за границы или ломает блок.

Иногда нам кажется, что пользователь так точно не напишет, но ничто не мешает ему назвать кнопку: «дезоксирибонуклеиноваякнопка». Поэтому проверяем с пробелами и без пробелов, а еще смотрим, как ведет себя перенос строк.

Для таких проверок удобно использовать максимально широкие буквы:

• для кириллицы — «Щ»;

• для латиницы — «W».

Это простой способ увидеть помещается ли текст, переносится ли он корректно на следующую строку и не вылезает ли за контейнер.

3️⃣ Что проверяем в макете?

Например, в макете Figma мы смотрим:

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

4️⃣ Как проверяем реализацию?

В браузере используем стандартные DevTools: смотрим вкладку Elements + разделы Styles и Computed.

Computed удобнее — отображаются итоговые значения после применения всех CSS-правил: размер шрифта, высота строки, цвета, отступы.

Так проще напрямую сравнивать реализацию с макетом и не теряться в длинных CSS-цепочках.

5️⃣ Что важно знать о состояниях элементов?

Чаще всего это кнопки. В DevTools можно вручную включить состояния:

• :hover

• :active

• :focus

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

6️⃣ На что еще обращаем внимание?

Отступы могут быть реализованы через padding (внутренний) и margin (внешний).

Важно помнить, что высота текстового блока определяется line-height. Если высота строки отличается от макета — поплывут и расстояния между элементами, даже если padding и margin заданы верно.

7️⃣ Когда удобно считать руками, а когда — линейкой?

Иногда проще посмотреть padding и margin и сложить их значения. Но если блоки визуально хорошо видны, помогает линейка: измеряем расстояния не только в браузере, но и вообще на экране.

Для текста и иконок лучше ориентироваться на границы блоков и отступы, а не пытаться измерять «на глаз».

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

Интересно сравнить подходы: какие проверки верстки вы считаете обязательными в своей практике, а какие — избыточными? 

Развитые софт-скилы для аналитика — +1000 к долгосрочному профессиональному успеху, ведь с ними преуспевать в работе будет проще. Благо софты, как и харды, всегда можно прокачать. 

Поэтому делимся несколькими важными для аналитика софт-скилами и рассказываем о методах тренировки этих «мягких» навыков.

Стратегическое мышление, или, иначе, helicopter view

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

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

Фасилитация встреч

Суть навыка в умении вести переговоры и выстраивать коммуникацию так, чтобы находить компромисс между конфликтующими сторонами. 

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

Понимание потребностей и выявление требований

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

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

Самоорганизация

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

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

Коммуникация и обмен информацией

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

Как развивать: через практику живого общения с другими людьми и через понимание, что перед нами человек, которому, как и нам, важна ясность. Документы — это тоже общение. Концепцию можно передать через схемы, диаграммы, таблицы, они проще воспринимаются при чтении. Можно использовать user stories и рассказывать истории так, чтобы командам разработки и заказчика были понятны суть и ценности предлагаемого решения.

Требования по регистрации событий ИБ часто выглядят формально и обобщенно. Но именно здесь во внедрении возникает больше всего вопросов, рисков и договоренностей, которые важно зафиксировать заранее.

Мы поговорили с Лизой, аналитиком по информационной безопасности, о том, как она работает с этими требованиями и что помогает избежать разночтений с заказчиком.

Почему регистрация событий ИБ — это всегда вызов

Событие ИБ — состояние системы, указывающее на важное с точки зрения безопасности действие, например, нарушение политики ИБ или сбой. 

Звучит просто, но в реальности возникает множество проблем:

• требования часто сформулированы абстрактно — «иные действия пользователей», «события, связанные с безопасностью»;

• невыполнение требований ИБ может заблокировать весь проект;

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

Откуда берутся требования

Во внедрении я сталкиваюсь сразу с несколькими источниками:

• требования по защите персональных данных — например, приказ ФСТЭК № 21;

• документы регуляторов с описанием инцидентов и состава событий;

• отдельные требования финансовых организаций;

• внутренние документы заказчика, к которым не всегда есть доступ;

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

Недавно в нормативке появились практические ориентиры. ФСТЭК выпустил рекомендации по базовой настройке регистрации событий безопасности — с примерами настройки логирования в ОС.

Как я структурирую требования по событиям ИБ

Чтобы работать с этим массивом, я условно делю требования на четыре группы.

Общие требования

Сроки хранения архивов журналов, источники событий, уровни системы: от ПО до сетевого оборудования.

Общий перечень событий

Самый опасный пункт — «иные действия пользователей». Моя тактика: фиксировать конкретный список событий, показывать демо и добиваться согласования, чтобы исключить разночтения.

Состав полей события безопасности

Важно понимать не только что регистрируется, но и какие атрибуты попадают в лог. Я всегда ставлю себя на место специалиста SOC: хватит ли этих данных, чтобы расследовать инцидент?

Мониторинг и передача в SIEM-систему

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

Что я вынесла из практики

1. Требования в ТЗ — это только часть картины, всегда нужно копать глубже.

2. Требования меняются по ходу проекта и это нормально.

3. Все договоренности важно фиксировать письменно.

4. Нужно учитывать не только нормативные документы, но и локальные требования заказчика.

5. Про SIEM-интеграцию стоит думать сразу, чтобы не пришлось переделывать позже.

6. Важно заранее договориться, кто и сколько хранит логи.

→ Подробнее своим опытом Лиза поделилась в статье.

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

Делимся ее ответами на непростые вопросы, с которыми может столкнуться руководитель в команде джунов.

Как понять, что сотрудник застрял в задаче, но боится сказать?

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

Как быть, если команда боится просить помощи, даже когда тяжело?

Я сталкивалась с этим в своей команде: каждый видел, что у других завал, и считал, что жаловаться неуместно. Начала проговаривать на общих созвонах, что просить помощи — нормально, это не слабость. Потом попробовала сама писать в личку с конкретными вопросами. До сих пор периодически пишу: «Привет! Вижу, что у тебя много задач. Давай заберу какую-нибудь?» и почти всегда в ответ получаю ссылку на задачу, которую можно передать. Ведь принять помощь гораздо проще, чем просить о ней самому.

Что делать, если в команде очень разные стили работы?

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

Как говорить о повторяющихся ошибках, чтобы не потерять доверие?

Если ошибка повторяется или нарушаются договоренности, я говорю об этом строго, но без давления. Наедине обсуждаем, почему так произошло и что помешало. Также подробно разбираем, как можно было поступить по-другому. Человек не закрывается и понимает, что ошибка — не повод для страха, а точка роста.

Как помочь, если сотрудник теряет уверенность в себе?

Многие джуны (и я сама раньше) сталкиваются с синдромом самозванца. Они не видят свои достижения, стесняются радоваться успехам. Мы завели доску «победы недели» — каждую пятницу на ретро сотрудники фиксируют свои успехи и рассказывают о них всей команде. Когда признание приходит не только от руководителя, но и от коллег, человек по-настоящему начинает видеть свою ценность. На «1:1» мы тоже обсуждаем сильные стороны с конкретикой и примерами, чтобы сотрудник видел точки роста и сильные стороны.

→ Подробнее своим опытом Вика поделилась в статье.

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

Диана, инженер по тестированию в Naumen, делится личным опытом: как перестать бояться задавать вопросы, говорить о багах без конфликтов и выстраивать рабочие отношения на старте.

Как я справилась со страхом задавать вопросы

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

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

Как говорю о багах, чтобы меня поняли

Первые разговоры с разработчиками были волнительными. Мы смотрим на систему по-разному: я — через интерфейс, разработчик — через код. Иногда даже называем одну и ту же кнопку иначе.

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

Когда я сообщаю о баге, всегда прикладываю:

• шаги воспроизведения;

• скриншоты или видео;

• ожидаемое и фактическое поведение;

• логи.

Что я делаю, если разработчик говорит «у меня все работает»

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

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

Ответы коллег могут быть сухими и перегруженными техническими деталями. Если я не до конца поняла, я прямо пишу об этом и прошу объяснить проще.

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

Что помогает выстроить рабочий контакт:

• приносить максимум информации;

• избегать обвинений — мы ищем решение, а не виноватого;

• предлагать созвон, если переписка не помогает;

• не бояться переспрашивать;

• напоминать аккуратно, если задача «зависла».

Почему важно уточнять требования

Аналитики формируют требования, а тестировщики проверяют реализацию. Казалось бы, все должно быть просто: есть ТЗ — идем по нему. Но на практике почти всегда возникают нюансы.

Требования могут быть неполными, измениться в процессе или трактоваться по‑разному. Поэтому я стараюсь задавать вопросы еще до начала тестирования и фиксировать все договоренности прямо в задаче, чтобы была единая «точка правды» для всей команды.

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

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

Почему полезно делиться опытом

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

И сама стараюсь делать то же самое: делиться тем, что знаю, помогать, если кто‑то только погружается в проект. Команда работает лучше, когда в ней не боятся спросить и не жадничают знаниями.

Когда я только шла в тестирование, мне казалось, что главное — это внимательность, логика и документация. Со временем стало понятно: на первом месте — умение взаимодействовать с людьми.

→ Подробнее своим опытом Диана поделилась в статье.

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

• «Думай медленно… Решай быстро», Даниэль Канеман

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

• «Предсказуемая иррациональность», Дэн Ариели

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

• «Высоконагруженные приложения», Мартин Клеппман

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

• «Гибкое сознание», Кэрол Дуэк

Книга о том, как наше отношение к трудностям и ошибкам определяет успех. Дуэк доказывает, что способности можно развивать через «установку на рост». Полезно тем, кто руководит людьми или хочет расти сам.

• «Ментальные ловушки», Андре Кукла

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

• «Профессиональная разработка программного обеспечения», Стив Макконнелл

Книга о системности, ответственности и качестве в разработке. Макконнелл объясняет, что делает разработчика профессионалом: от планирования и коммуникации до оценки рисков и качества.

• «Верховный алгоритм», Педро Домингос

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

• «Искусство тестирования программ», Гленфорд Майерс

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

• «Жалоба — это подарок», Джанелл Барлоу, Клаус Мёллер

Барлоу и Мёллер учат видеть в жалобах не угрозу, а помощь. Книга о том, как правильно реагировать на обратную связь, сохранять доверие и превращать недовольство в развитие.

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

Мы поговорили с нашими тестировщиками Дашей и Алёной о том, какие навыки особенно важны, какие технологии меняют подход к работе и как развиваться в профессии, где все постоянно меняется.

Что происходит с профессией?

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

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

Почему ИИ — главный тренд?

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

Какие навыки важны?

Чтобы быть полезным тестировщиком, важно развивать как технические, так и гибкие навыки:

• Внимательность, критическое и системное мышление — чтобы видеть не только конкретную ошибку, но и ее влияние на продукт в целом.

• Английский язык — чтобы читать логи, понимать настройки.

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

Что еще необходимо?

• REST, HTTP, Linux, Docker — это основа, особенно если вы работаете с DevOps‑задачами. Чтобы глубже тестировать инфраструктурные задачи, полезно пройти курсы и прокачать навыки.

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

Как развиваться тестировщику?

• Развитие через практику и обмен опытом

Новые подходы можно черпать на конференциях, например, Heisenbug, SQA Days. Дополнительное развитие — брать задачи не только по тестированию, но и по улучшению процессов, участвовать в аналитике, работать над задачами смежного продукта, тестировать мобильное приложение. Наставничество также помогает расти — учишься вместе с теми, кого поддерживаешь.

• Развитие через ИТ-сообщество и техбазу

Начинающим тестировщикам будут полезны материалы Артёма Русова. У него есть сайт и тг-каналы: @qachanell, @qa_sklad.

Развиваться помогают и внутренние ресурсы в компании: коллеги делятся опытом, обсуждают кейсы, рассказывают, как решают задачи. Если у вас в компании есть что‑то подобное — не упускайте. Это классный способ расти и смотреть на профессию шире.

Полезные книги:

1. «Тестирование DOT COM», Роман Савин

2. «Тестирование ПО», Святослав Куликов

В Naumen распределенность — обычная история: офисы в разных городах, часть команд работает полностью удаленно. Отдел технического пресейла — один из таких кейсов. Его руководитель, Паша, работает удаленно, как и большая часть команды.

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

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

Чем занимается наша команда

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

В команде 9 человек, почти все работают удаленно и живут в разных городах. Мы разделены на две группы по продуктам: Low Code и NoCode.

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

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

В чем была главная сложность

Самая заметная сложность — непрозрачная нагрузка. В основном мы взаимодействуем с менеджерами по продажам: изначально они писали напрямую сотрудникам моей команды. Задачи размазывались, терялись, пересекались.

В такой системе:

• невозможно оценить загрузку;

• нельзя планировать ресурс;

• нет общей картины, кто чем занят.

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

Как мы выстроили систему

В 2022 году мы внедрили следующие изменения:

• собрали таск-трекер на базе нашей платформы Naumen SMP;

• сделали Telegram-бота и перевели всю коммуникацию с менеджерами туда.

Теперь процесс выглядит так:

1. Менеджер оставляет запрос в боте.

2. Тимлид ведет коммуникацию и ставит задачу на одного из сотрудников.

3. Сотрудник берет задачу в работу, оформляет результат, закрывает.

Мы ушли от личных сообщений и получили понятную нагрузку, удобный контроль и прогресс. Работать стало спокойнее.

Как поддерживаем связь внутри команды

Удаленной команде без постоянного взаимодействия довольно сложно работать. Поэтому у нас есть несколько форматов:

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

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

Один-на-один со мной — каждый месяц встречаюсь с сотрудниками: обсуждаем годовые цели и путь к ним.

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

Что важно в распределенной команде

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

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

Когда такие люди собираются в одной команде — неважно, где они территориально. Все и так работает.

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

Ира, продуктовый аналитик в группе AI-решений, рассказывает, как она организует эту работу на практике: от подготовки задач и взаимодействия с разработкой до поиска решений.

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

Что я собираю перед тем, как задача уходит в разработку

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

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

Как определяются приоритеты

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

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

Какие артефакты ускоряют реализацию

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

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

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

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

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

Что помогает выстраивать эффективную работу с разработкой

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

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

Как я сокращаю количество уточнений и переделок

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

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

Инструменты, которые помогают работать быстрее

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

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

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

В будущем планируем сделать ориентир на роадмап.

В работе тестировщика важно иметь под рукой инструменты, которые ускоряют проверки, упрощают рутину и позволяют глубже разбираться в поведении системы. Вместе с Ариной и Катей из команды релизного тестирования SMRM собрали подборку таких инструментов.

Pairwise online tool — инструмент для генерации парных комбинаций проверок

Pairwise‑тестирование позволяет проверить все пары параметров и избежать полного перебора вручную. Онлайн‑инструмент автоматически генерирует комбинации и при необходимости учитывает определенные условия.

В чем польза:

• сокращает количество проверок без потери покрытия;

• учитывает логические условия и исключает невозможные сочетания;

• упрощает тестирование форм, статусов и сложных конфигураций;

• ускоряет подготовку кейсов, в том числе для группы автоматизации.

Катя: Использую Pairwise, когда нужно быстро собрать оптимальный набор проверок. Но важно учитывать ограничения: если дефект зависит от 3–4 условий, техника может его пропустить, а найденный баг сложнее локализовать — непонятно, какой параметр повлиял на воспроизведение.

Visual Studio Code — удобный редактор для создания, чтения и редактирования файлов

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

В чем польза:

• красиво раскрашивает код до читаемого, удобная навигация;

• позволяет делать поиск по нескольким файлам одновременно;

• подходит для анализа конфигураций и настроек системы;

• поддерживает расширения — все доступно в бесплатном магазине. 

Катя: Использую VS Code как легкий и удобный текстовый редактор — аналог Notepad++. Для разработчиков, мне кажется, он еще полезнее: напоминает полноценную IDE, только в более гибком формате.

Bug Magnet — расширение для Google Chrome с библиотекой тестовых данных

Bug Magnet подставляет в поля формы готовые тестовые значения: длинные строки, разные алфавиты, необычные символы, валидные и невалидные email‑адреса, числа, города и многое другое. 

В чем польза:

• ускоряет проверку форм и валидации;

• предлагает значения, которые сложно придумать вручную;

• поддерживает разные режимы ввода — вставка, симуляция ввода с клавиатуры;

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

Арина: Bug Magnet выручает, когда нужно быстро заполнить форму разными граничными значениями. В один клик получаешь данные, которые вручную подбирать долго и неудобно.

Flaticon — библиотека бесплатных иконок для интерфейса

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

В чем польза:

• есть большое количество бесплатных иконок;

• предлагает варианты под светлую и темную тему;

• можно скачать в форматах PNG и SVG;

• упрощает выбор готовых размеров под Android, iOS и веб.

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

Burp Suite — инструмент для тестирования безопасности веб‑приложений

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

В чем польза:

• позволяет перехватывать и подменять запросы и ответы;

• помогает изучать авторизацию и поведение параметров;

• дает возможность автоматизировать переборы значений через Intruder;

• упрощает анализ и сравнение запросов с помощью Decoder и Comparer;

• визуализирует структуру сайта и все перехваченные запросы.

Арина: Burp Suite кажется сложным из-за количества модулей, но на практике все просто: перехват — подмена — отправка — анализ. Это удобный инструмент для проверки авторизации, поведения параметров и работы безопасности в целом.

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

1. Давать осмысленные имена сразу же

Хорошие названия переменных, функций и классов экономят время всей команде: код проще читать, легче понимать и поддерживать. А еще чем меньше вопросов «что делает эта функция?» или «что содержит переменная?», тем лучше.

2. Декомпозировать код и избегать вложенности

if внутри if или for внутри for путают: каждое разветвление создает еще одну ветку, которую приходится держать в голове. Лучше разбить логику на небольшие части — код становится прозрачнее и надежнее.

как не надо:

функция заказать_пиццу(адрес):
  если адрес_валиден(адрес):
    если у_ресторана_ингредиенты():
      если клиент_может_платить():
        печать "Пицца заказана!"
      иначе:
        печать "Недостаточно денег"
    иначе:
      печать "Нет ингредиентов"
  иначе:
    печать "Адрес некорректный"

как надо:

функция заказать_пиццу(адрес):
  если не адрес_валиден(адрес):
    печать "Адрес некорректный"
    вернуть
  
  если не у_ресторана_ингредиенты():
    печать "Нет ингредиентов"
    вернуть
  
  если не клиент_может_платить():
    печать "Недостаточно денег"
    вернуть
  
  печать "Пицца заказана!"

3. Регулярно делать рефакторинг

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

4. Настроить линтер и форматер

Линтер — статический анализатор кода, который следит за определенным стилем написания кода. Так как у каждого из нас свой подход, нам нужен «инструмент-судья», который беспристрастно оценит оформление кода. Форматер помогает автоматически исправить код и привести его к единому виду. 

5. Комментировать только неочевидную бизнес-логику

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

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

Мы поговорили с коллегами о том, какие навыки и подходы помогают им двигать продукты вперед и принимать сильные решения. Делимся их мыслями с вами.

Что важно для продакта?

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

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

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

Какие скиллы нужны?

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

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

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

4. Любопытство и интерес — это основа генерации идей и внедрения инноваций. Важно не бояться задавать вопросы, например, «А что если?» и тестировать гипотезы.

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

Как развиваться продакту?

Продакту важно уметь говорить понятно — не нужно усложнять формулировки и смыслы. Например, помогают курсы по аргументации и выстраиванию речи — выражать свои мысли становится проще. 

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

Что почитать:

• Пиши, сокращай 2025: Как создавать сильный текст / Ильяхов М., Сарычева Л.

• Спроси маму: Как общаться с клиентами и подтверждать правильность идей, когда все вокруг врут / Фитцпатрик Р.

• Telegram-каналы с полезным контентом о продуктовой разработке и бизнес-трендах: Epic Growth, RB.RU, Product Management & AI, Продакты не нужны, Заметочки b2b продакта, Губкин | Про AI и B2B-продукты, Strategic move: стратегия, продукт и AI, Продуктовое мышление / от ProductSense и Клиентский опыт и качество.

Тестирование требований — это не про поиск багов в коде. Это процесс проверки того, насколько сами требования корректны, полны и понятны.

Зачем это вообще нужно?

Ошибки в требованиях → баги в реализации → потери времени и денег.

Тестирование требований позволяет:

• Выявлять дефекты до этапа кодинга

• Экономить время команды

• Делать ожидания всех сторон прозрачными

• Повышать качество продукта без доработок «в последний момент»

Как понять, что требование хорошо сформулировано:

Какие техники тестирования требований использовать?

Взаимный просмотр
Показываем свою работу коллегам

Вопросы
Уточняем у заказчиков и коллег

Тест-кейсы и чек-листы
Прорабатываем набор вопросов для проверки требований

Рисунки
Наглядно представляем приложение

Прототипирование
Делаем наброски интерфейса и переходов между экранными формами

Исследование поведения системы
Мысленно моделируем работу пользователя с системой

Как проверить количество и атомарность?

1. Делаем блок-схему, чтобы увидеть дубли и лишние шаги

2. Проверяем, что требование описывает Create / Read / Update / Delete / List

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

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

5. Ищем отсылки на неопределенную информацию — если есть «и т.д.», «как обычно», стоит уточнить

6. Проверяем на союз «и» — часто он объединяет в одном требовании сразу два, а иногда и больше

Как проверить выполнимость и однозначность?

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

Что важно:

• Терминология

• Отсутствие качественных определений

• Простое изложение

• Возможность составить набор тестов

• Тестирование внешних сервисов

Как проверить актуальность и последовательность?

Если требование забыли, потеряли или поняли не так — беда в процессе.

На что обращаем внимание:

• Одно требование описано в одном месте

• Есть user story или хотя бы сценарий использования

• У автора требований есть знание предметной области

• Учтены интересы всех пользователей

• Договоренности из чатов перенесены в документацию

• Согласована дата последнего обновления требований и документации

Хорошие требования — это результат не только опыта, но и осознанной практики.

Разработка в 2025 году — это уже не только про умение писать код. Важно уметь работать в связке с ИИ, быстро адаптироваться к новым инструментам и смотреть на задачи шире, чем строки кода. Автоматизация ускоряет процессы, языковые модели становятся полноценным помощником, а кибербезопасность требует внимания как никогда раньше.

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

Что формирует будущее разработчиков

1. ИИ и языковые модели. Инструменты вроде Cursor/Windsurf и LLM помогают быстрее и качественнее выполнять то, что вы уже умеете, или разобраться в новой теме. LLM берут на себя «черновую» работу: исправляют опечатки, улучшают оформление кода, помогают с декомпозицией задач и первичным код‑ревью. Это снижает нагрузку и освобождает время под архитектурные решения.

2. Кибербезопасность. С ростом объема данных и активным использованием ИИ‑решений увеличивается и число атак. В 2025 году безопасность уже не «дополнительная опция», а критически важный аспект разработки. В приоритете: оперативное устранение уязвимостей, поддержка зависимых библиотек в актуальном состоянии, а также проектирование безопасных систем.

Главные скиллы

— Промпт‑инжиниринг и итеративный подход. Чем лучше вы понимаете и формулируете задачу для LLM, тем лучше результат. Разбивайте сложные задачи на небольшие, пошагово уточняйте вводные, добавляйте контекст, референсы и критерии качества.
 — Умение адаптироваться к изменениям. Мир меняется быстро: нужна гибкость и готовность учиться новым инструментам и подходам.
 — Осознанное применение ИИ. ИИ ускоряет рутину, но не заменяет понимания. Код или решения без осознания внутренних механизмов сложнее поддерживать; сырые и неадаптированные ответы часто дороже, чем написать с нуля.
 — Критическое и системное мышление. Хороший разработчик видит систему целиком, задает вопросы, сравнивает варианты и думает на несколько шагов вперед: архитектура, влияние изменений, риски и стоимость владения.

Как развиваться разработчику

1. Книги, курсы и пет‑проекты. Рабочая связка: цель → план → небольшой прототип → разбор ошибок. LLM помогают собрать персональный план обучения: перечисляете, что знаете и что хотите изучить, — получаете черновой roadmap и список практик.

2. Конференции и митапы. Это возможность обменяться опытом и задать вопросы. Сильно прокачивает подготовка собственного доклада: структурируете знания, получаете обратную связь, улучшаете подходы.

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

Виртуальные потоки кажутся простым способом ускорить I/O. Но на Java 21 многие сталкивались со стагнацией из‑за пиннинга: когда код входит в synchronized и внутри выполняет блокирующую операцию (I/O, wait(), ожидание монитора), виртуальный поток «прибивается» к carrier‑потоку и не может отмонтироваться. Под нагрузкой это быстро исчерпывает пул carrier‑потоков и «замораживает» обработку. Часто как побочный симптом растет число соединений в CLOSE_WAIT, потому что обработчики не успевают корректно закрывать сокеты.

Что изменилось:

В JDK 24 реализован механизм, благодаря которому виртуальные потоки больше не пиннятся внутри synchronized, включая ожидание монитора и Object.wait()): JVM умеет корректно «размонтировать/перемонтировать» поток. Это почти полностью снимает главный источник проблем с Loom и в большинстве случаев избавляет от необходимости переписывать synchronized на ReentrantLock ради масштабируемости. Редкие источники пиннинга остались вне synchronized, например, JNI — их стоит искать профилированием и наблюдаемостью (JFR‑события).

Дальше — еще удобнее в JDK 25:

Scoped Values становятся финальными — надежная альтернатива ThreadLocal для передачи неизменяемого контекста без накладных расходов и утечек. Structured Concurrency остается в статусе preview и хорошо сочетается с моделью виртуальных потоков.

Что имеет смысл сделать уже сейчас без перелома архитектуры:

1. Планировать переход на JDK 25, чтобы получить финальные Scoped Values и полный набор улучшений Loom.

2. Запускать задачи через Executors.newVirtualThreadPerTaskExecutor() или фабрику Thread.ofVirtual() — так вы используете Loom «как задумано».

3. Проаудировать горячие пути — убрать блокирующие вызовы из‑под synchronized, сузить критические секции. При необходимости оставлять ReentrantLock, но не рассчитывать на него как на универсальное лекарство от пиннинга.

4. Включить наблюдаемость — отслеживать события пиннинга виртуальных потоков, рост очередей/времени ожидания и аномальный CLOSE_WAIT.

5. Там, где сегодня используются тяжелые ThreadLocal, по возможности переносить на Scoped Values после обновления до JDK 25 и обновлять библиотеки до версий с поддержкой Loom.

Как именно работает исправление пиннинга и как лечить «больные места» рассказали в статье Виртуальные потоки в Java: эволюция, практика, подводные камни.

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

Чтобы изменить такую объектную модель, например, добавить или удалить атрибут, нужно внести изменения в схему базы данных, то есть выполнить 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-систему.