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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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-систему. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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