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

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

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

Каким может быть рост?

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

«И тот, и другой рост — долгосрочный, иногда сложный, процесс. Ведь никто не вырастает в одно мгновение:)», — Катя, руководитель операционного отдела в ITSM365

На что нужно обращать внимание?

И для сеньора, и для тимлида важны:

• готовность нести ответственность за принятые решения;

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

• хорошая обратная связь от коллег.

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

Но иногда наставничество формирует неверное представление о работе тимлида, поэтому стараюсь дать еще несколько тимлидских задач, чтобы человек по максимуму смог погрузиться в работу и понять, стоит ли идти этим путем дальше», — Катя, руководитель операционного отдела в ITSM365

Что мешает росту?

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

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

Как оценивать личный прогресс и рост?

Чтобы отслеживать свой прогресс, важно ставить четкие цели и вести трек достижений.

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

«Также регулярная обратная связь от коллег помогает объективно оценить сильные и слабые стороны», — Рома, руководитель проектного отдела

Ключевые маркеры роста

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

• Расширение зоны ответственности — нужно постепенно переходить к управлению командой и стратегическому формированию проекта.

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

Как ощущается рост в моменте?

Сейчас я оцениваю себя как мидл+, и мой рост складывается из нескольких аспектов:

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

«Например, моя зона ответственности — работа над новым интерфейсом», — Сережа, разработчик в отделе разработки сервисов на базе SMP

• Расширенная экспертиза — несмотря на то, что сейчас в основном занимаюсь фронтенд-задачами, у меня также есть знания в бэкенде и опыт работы в техподдержке.

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

Где искать мотивацию и как не застопорить рост?

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

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

Антон, архитектор решений в 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-систему. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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