Naumen | Карьера

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

Сезон отпусков в самом разгаре ☀️ Подготовили набор летних аватарок с нашей красной пандочкой: есть готовые варианты со статусами и универсальные шаблоны, которые можно адаптировать под себя. Устанавливайте в мессенджерах, чтобы коллегам было проще понять, что вы сейчас не на связи, а вам — спокойно отдыхать и восстанавливаться ❤️ Забирайте аватарки в комментариях 👇

Иногда мы ставим задачу и даже не задумываемся, что у коллег может не быть того же контекста, что и у нас. Нам кажется, что в постановке и так все очевидно: где лежат нужные данные, что именно нужно сделать и какой результат ожидается. Но после передачи в работу появляются уточнения, дополнительные обсуждения и вопросы, которые просто не учли заранее. Мы обсудили эту проблему с Костей, специалистом по ИИ в Naumen. Он рассказал, как с помощью ИИ можно формулировать задачи понятнее, заранее находить пробелы в постановке и сокращать количество лишних уточнений в работе. 🍏Как ИИ может помочь сформулировать задачу? У нас в команде есть ассистент Dev Describer. Он помогает формулировать бизнес-требования к задачам разработки. Например, можно описать задачу своими словами: «Нужно добавить уведомление о просроченной заявке в личный кабинет». Ассистент поможет уточнить детали: 🔅когда именно показывать уведомление; 🔅для каких пользователей оно должно работать; 🔅какой текст нужен; 🔅что считается ожидаемым результатом. Если нужны дополнительные материалы — схемы, ссылки, скриншоты — мы сразу фиксируем их в задаче вместе с текстом. Во многих случаях этого уже достаточно, чтобы закрыть большую часть уточняющих вопросов еще до старта работы. 🍏А как проверить постановку перед передачей в работу? Полезно попробовать посмотреть на нее глазами исполнителя. Для этого мы используем отдельный сценарий: даем ассистенту задачу и просим найти места, которые могут помешать начать работу. Например: «Ты — исполнитель этой задачи. Тебе важно найти пробелы, которые мешают приступить к работе». После этого ассистент помогает заметить: 🔅где не хватает контекста; 🔅что можно понять неоднозначно; 🔅каких вводных не хватает; 🔅какие вопросы, скорее всего, появятся у команды. 🍏Что это дает в работе? Такая проверка занимает буквально несколько минут, но помогает заранее убрать часть недопониманий. В результате становится меньше уточнений, дополнительных обсуждений и ситуаций, когда важные детали всплывают уже во время работы над задачей. 🍏Где такой подход особенно полезен? В задачах, где много контекста, зависимостей или участников. Чем сложнее коммуникация вокруг задачи, тем выше шанс, что разные люди поймут ее по-разному. В таких сценариях дополнительная проверка помогает экономить время всей команде.

Каждый год на рынок выходит более 30 000 новых продуктов, но успеха добиваются лишь 15–20% из них. Часто проблема не в качестве продукта, а в том, что рынок меняется быстрее, чем команды успевают адаптироваться к новым запросам пользователей и технологиям. В таких условиях важно не только следить за конкурентами, но и замечать сигналы, которые только начинают набирать силу. Ксюша, руководитель продукта Project Ruler, поделилась практическим подходом к трендвотчингу: где искать ранние сигналы, как системно работать с трендами и какие изменения уже сейчас заметны на рынке управления проектами.

О тестировщиках часто говорят как о специалистах, которые просто проверяют готовые сценарии и ищут ошибки. Из-за таких представлений работа тестировщика со стороны может казаться довольно простой и предсказуемой. Когда Диана только приходила в тестирование, у нее тоже были свои ожидания от профессии. Но уже в первые месяцы работы стало понятно, что все устроено гораздо сложнее и интереснее. Поговорили с Дианой о том, как на самом деле выглядит работа тестировщика. 🍏Что оказалось самым большим заблуждением о тестировании? Мне казалось, что работа тестировщика довольно простая: проверить сценарий, найти ошибку и передать задачу дальше. Но довольно быстро стало понятно, что сама проверка — только часть работы. Перед тестированием нужно разобраться в требованиях, продумать сценарии, подготовить тестовые данные и понять, как изменения могут повлиять на другие части системы. Иногда уже на этапе анализа появляются вопросы или находятся противоречия в логике задачи. 🍏Почему «найти баг» — это не самая сложная часть? Потому что сам дефект еще нужно правильно описать и воспроизвести. Недостаточно написать, что что-то не работает. Нужно зафиксировать шаги, ожидаемый и фактический результат, приложить логи или скриншоты. И даже после этого бывают ситуации, когда ошибка у разработчика не воспроизводится. У меня был случай с массовыми инцидентами: ошибка возникала только при определенной последовательности действий и сопровождалась исключением в логах. Пришлось вместе с разработчиком проходить сценарий шаг за шагом и искать, в какой момент система ведет себя неправильно. 🍏Правда ли, что автотесты постепенно заменяют ручное тестирование? Нет. Автоматизация закрывает часть задач, особенно регрессионные проверки, но есть сценарии, которые сложно или нецелесообразно автоматизировать. Например, проверки ролей и ограничений доступа, сложные цепочки изменений или нестандартные пользовательские сценарии. В таких задачах важно не только проверить формальную логику, но и посмотреть на систему глазами пользователя: насколько поведение выглядит понятным и ожидаемым. 🍏Бывали ситуации, когда ошибку все-таки пропускали? Да, и это нормально для сложных систем. Однажды я тестировала дополнительные настройки услуги и проверила основной функционал, но не повторила те же проверки в связанном компоненте. В результате ограничения доступа работали не полностью: часть сотрудников получала доступ к функциональности, которой не должна была пользоваться. Этот случай показал мне, что тестирование — это не попытка найти абсолютно все ошибки, а работа с рисками и внимательностью к связям внутри системы. 🍏Насколько тестировщику важно понимать код? Глубокие знания программирования нужны не всегда, но базовое понимание сильно помогает в работе. Например, у меня была задача, связанная с логикой формирования поля Reply-To в письмах. В интерфейсе было непонятно, почему параметр не появляется. После просмотра Groovy-кода стало ясно, что он зависит от заполнения других полей при отправке письма. Такие вещи помогают быстрее находить причину проблемы и проще общаться с разработчиками. 🍏Как со временем изменился твой взгляд на профессию? Наверное, главное изменение — понимание того, насколько сильно тестировщик влияет на качество продукта. Это не роль «человека, который ищет ошибки». Тестировщик участвует в обсуждении логики, помогает замечать слабые места в сценариях и смотрит на систему с точки зрения пользователя. И именно поэтому тестирование оказалось для меня намного интереснее, чем я представляла в начале.

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

После такого отдыха, нужен еще один отдых 🙂 Впереди сезон отпусков — время, от которого мы обычно ждем восстановления, возможности выдохнуть и немного замедлиться после напряженного темпа. Но отпуск или длинные выходные не всегда помогают почувствовать себя лучше. Одна из причин — мы часто воспринимаем отдых как проект: заранее ждем конкретного результата, пытаемся провести «правильно», расписываем дни активностями. И если до этого был период высокой нагрузки, нервной системе может быть нужен не новый сценарий, а снижение внешнего шума: меньше решений, информации и необходимости куда-то включаться. Вот несколько неочевидных ошибок, которые мешают отдохнуть👇 🍊 Строгое планирование План сам по себе не проблема — он помогает не потеряться в днях и заранее договориться о важных вещах с близкими и друзьями. Беда в том, что отдых может превратиться в расписание, где все непременно должно состояться. В таком режиме мозг продолжает делать то же, что и на работе — держать в голове задачи, сверяться с планом, принимать решения, контролировать результат. 🍊 Ожидание быстрого восстановления После напряженного периода хочется верить, что несколько свободных дней все исправят: получится выспаться, прийти в себя и вернуться в прежний темп. Но если нагрузка длилась недели или месяцы, короткого отпуска обычно хватает только на базовое восстановление — чуть снизить напряжение и замедлиться. А когда ожидания не совпадают с реальностью, появляется разочарование: кажется, что отдых не удался, ведь сил все равно недостаточно. 🍊 Навязывание «правильного» отдыха Прогулки, книги, спорт, поездки за город — все это может работать, но только если совпадает с вашим состоянием в данный момент. Если есть усталость от решений, людей и постоянного включения, даже полезные активности могут стать еще одной обязанностью с установкой, что так правильно, надо провести время с пользой. В итоге отдых теряет главный смысл — перестает восстанавливать и снова требует усилий. 🍊 Сравнение своего отдыха с чужим В период отпусков и праздников легко поймать ощущение, что все вокруг проводят время лучше, эффективнее, интереснее. На этом фоне спокойные выходные дома начинают казаться «потерянными», даже если именно они и были нужны. Вместо восстановления появляются мысли, что мало сделал и увидел, не так провел время. Сравнение добавляет к усталости еще и чувство вины, а с ним отдыхать почти невозможно. 🍊 Активность каждый день Встречи, поездки, спорт и новые впечатления правда могут заряжать. Однако при высокой нагрузке ресурса может не хватать даже на приятные события. Любая активность требует внимания: собраться, доехать, общаться, реагировать, выбирать, переключаться. Если такими событиями заняты все дни подряд, организм не успевает перейти в режим покоя. Получается не восстановление, а насыщенная программа, после которой нужен еще один отпуск.

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

Катя руководит операционным отделом ITSM 365 в Naumen. За несколько лет ее команда выросла до нескольких тимлидов, техлидов и пятнадцати аналитиков — вместе с этим стали сложнее и внутренние процессы. Но команда решила не просто распределить задачи между конкретными людьми, а полностью пересмотреть процессы. В статье на Хабре Катя рассказывает, как менялась система консультаций внутри команды, почему руководителю сложно отпустить часть процессов и какие изменения помогли снизить зависимость от одного человека, не потеряв при этом прозрачность и управляемость. → Читать статью на Хабре

Проблемы с производительностью обычно проявляются в самый неподходящий момент: когда резко растет нагрузка или система обрабатывает сложные сценарии. Именно для таких ситуаций существует нагрузочное тестирование. Но сам процесс — это не только запуск тестов. Нужно собрать требования, подготовить инфраструктуру, настроить инструменты и синхронизировать работу команд. Егор, аналитик в Naumen Contact Center, рассказал, как внутри продукта устроено нагрузочное тестирование и почему «запустить тест» — самая простая часть. 🍏 Что такое нагрузочное тестирование? Нагрузочное тестирование показывает, насколько хорошо система справляется с большим количеством пользователей или объемом данных. В случае контакт-центра это, например: 🔅количество одновременно работающих операторов 🔅нагрузка на входящие и исходящие вызовы Нагрузочное тестирование нельзя рассматривать отдельно от остального тестирования. Оно связано и с разработкой фич, и с архитектурой, и с нефункциональными требованиями. 🍏 Почему аналитик вообще занимается нагрузочным тестированием? У каждого аналитика в нашей команде есть свои зоны экспертизы. Я, например, начал погружаться в тему производительности, поэтому нагрузочное тестирование со временем стало частью моей работы. Моя задача — анализировать требования и описывать, как именно должно проходить нагрузочное тестирование: что проверяем, какие сценарии запускаем и какие параметры считаем важными. 🍏 Когда нужно проводить нагрузочное тестирование? Есть несколько типичных ситуаций, когда без него не обойтись: 🍏Регулярные проверки перед релизом или после обновления серверов. 🍏Тестирование новых фич — если изменения потенциально могут повлиять на производительность. 🍏Запросы от клиентов или команды внедрения — когда нужно проверить нагрузку или конфигурацию. 🍏Внутренние задачи разработки — когда команде нужно проверить свои решения под нагрузкой. Однако протестировать все невозможно — это требует слишком больших ресурсов. Поэтому мы используем карту нефункциональных требований: проходим по чек-листу и смотрим, могут ли изменения повлиять на производительность системы. 🍏 Как принимается решение о проведении тестирования? Обычно это происходит на встрече по оценке фичи. В обсуждении участвуют тимлиды разработки, архитекторы, тестировщики и другие cпециалисты. Аналитик приносит информацию по изменениям, а дальше команда совместно решает, нужен ли нагрузочный тест. 🍏 Как устроен процесс нагрузочного тестирования? Процесс можно разделить на три этапа: 1. Первичная аналитика — собираем требования и определяем цель. 2. Детальная аналитика — описываем сценарии, метрики, инфраструктуру. 3. Проведение тестов — запускаем тестирование и анализируем результаты. 🍏 Почему нагрузочное тестирование требует отдельной инфраструктуры? Для более-менее реалистичного тестирования недостаточно одного сервера. В нашем случае используются несколько гипервизоров, десятки виртуальных машин, серверы генерации и приема нагрузки, а также инструменты вроде Gatling, JMeter, Grafana и Ansible. Отдельные компоненты эмулируют работу операторов и клиентов. Например, для проверки нескольких тысяч операторов фактически собирается отдельный контур. 🍏 Почему даже короткий тест может занимать полтора часа? Потому что сам прогон — только часть процесса. До запуска нужно подготовить окружение, очистить старые данные, проверить сервисы, настроить мониторинг и применить параметры. После — собрать артефакты, метрики и результаты. Поэтому тест на 20 минут превращается в полтора часа работы. 🍏 Что происходит после тестирования? После прогона команда анализирует логи, метрики, бизнес-отчеты и дашборды в Grafana. Есть основные метрики, которые проверяются постоянно. Для контакт-центра это, например, скорость установления соединения, скорость открытия экранных форм, переходов между ними и закрытия экранных форм. Если эти показатели проседают, тест нельзя считать успешно пройденным, даже если сама фича формально работает. После анализа команда либо фиксирует результаты, либо заводит задачи на доработку сервисов, окружения или инструментов.