Аналитика в эпоху ИИ

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

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

Ваня и Динара, аналитики Naumen, рассказали, для чего используют ИИ сейчас, что по-прежнему контролируют сами и какие навыки становятся важнее.

• Что можно делегировать ИИ

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

Чаще всего использую ИИ для:

• поиска необходимой информации;

• обработки встреч и фиксации итогов и договоренностей;

• написания скриптов;

• работы с документацией.

А еще с ИИ бывает проще разобраться в новой для себя области.

Динара, бизнес-аналитик:

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

Еще его можно подключить на этапе «белого листа»: получить несколько подходов, от которых можно оттолкнуться.

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

• Почему ИИ нужно проверять

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

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

В конечном итоге ответственность за то, что получилось, будешь нести ты, а не ИИ.

Динара, бизнес-аналитик:

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

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

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

• Какие навыки становятся важнее 

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

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

Еще один навык — работа с самим ИИ: точно ставить задачу, передавать контекст и понимать, какие данные безопасно ему отдавать.

Динара, бизнес-аналитик:

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

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

• Как ИИ изменит работу аналитика

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

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

Аналитику при этом все равно придется валидировать результат.

Динара, бизнес-аналитик:

Для меня ИИ — не самоцель, а способ освободить время для мышления.

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

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

Подборка материалов: что почитать разработчику

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

➡️ Разбираем фичи по кусочкам: атомарные коммиты как внутренняя дисциплина

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

➡️ Автоматическая генерация UI-настроек

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

➡️ Инструменты, которые упрощают iOS-разработку

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

➡️ Хороший код: как понять, что его будет удобно менять

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

➡️ Как ломался пиннинг в Java 21 и что починили в Java 24

Как менялась работа виртуальных потоков от Java 21 к более новым версиям: от проблемы с пиннингом до изменений в JDK 24 и дальнейшего развития Project Loom.

Сохраняйте пост, чтобы материалы были под рукой 🧡

Как масштабировать знания, а не нагрузку

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

С этим столкнулась команда клиентского сервиса ITSM 365. Кира, бизнес-аналитик клиентского сервиса и куратор командной базы знаний, рассказала, как команда постепенно выстроила систему работы со знаниями.

1️⃣ База знаний сама по себе проблему не решает

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

• Актуальность — обновляем материалы и следим, чтобы они не дублировались.

• Доступность — встраиваем статьи в рабочий процесс.

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

• Ответственность — поддерживаем базу всей командой.

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

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

2️⃣ Нужные инструкции должны быть под рукой

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

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

3️⃣ Иногда достаточно простого решения

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

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

4️⃣ ИИ там, где он действительно экономит время

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

Раньше на такую работу могло уйти около получаса, сейчас — в среднем 3–5 минут.

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

5️⃣ Что изменилось в работе

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

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

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

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

Тестирование в эпоху ИИ

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

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

• Делегировать техническую рутину

Даша, младший тестировщик в команде релизного тестирования SMRM:

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

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

• Подключить дополнительную проверку

Катя, тестировщик в команде релизного тестирования SMRM:

Перед составлением тест-плана сначала анализирую задачу с ИИ. Потом сама внимательно все продумываю и еще раз возвращаюсь к нему, чтобы проверить, не пропустила ли что‑то.

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

• Анализировать изменения и дефекты

Даша, младший тестировщик в команде релизного тестирования SMRM:

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

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

• Использовать готовых ИИ-помощников

Катя, тестировщик в команде релизного тестирования SMRM:

У нас в команде уже есть несколько готовых ИИ-помощников. Один может пройтись по дефекту и подсказать, что стоит поправить. Другой анализирует покрытие автотестами — подсвечивает, что уже покрыто, а что нет.

Есть и ревьюер тест-кейсов, который помогает находить в них недочеты.

Важно: результаты ИИ тоже нужно проверять

Даша, младший тестировщик в команде релизного тестирования SMRM:

Пока ИИ не меняет процесс тестирования радикально. Но помогает не тратить время на долгий поиск информации и быстрее разбираться в сложном.

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

Катя, тестировщик в команде релизного тестирования SMRM:

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

Что ИИ меняет в работе с кодовой базой

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

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

Ринат, iOS‑разработчик в Naumen, рассказывает, почему так происходит и что это меняет в работе команды.

🔸 ИИ продолжает то, что уже есть

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

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

🔸 Правила нельзя оставлять только в голове

Важно заранее договориться:

• где живет конкретное бизнес‑правило;

• какие состояния допустимы;

• что должно остаться неизменным;

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

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

🔸 ИИ не отменяет архитектуру и тесты

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

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

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

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

Собрали на осень пять книг, которые помогают тренировать эти навыки и по-другому смотреть на привычные рабочие ситуации 📚🧡

• «Системное мышление», Донелла Медоуз

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

• «Думай как математик», Барбара Оакли

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

• «Принцип ставок», Энни Дьюк

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

• «Гиперфокус», Крис Бэйли

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

• «Алгоритмы для жизни», Брайан Кристиан и Том Гриффитс

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

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

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

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

Как устроен процесс и что он изменил, рассказала Таня, продуктовый аналитик Naumen Erudite.

1️⃣ Зачем продуктовым аналитикам следить за конкурентами?

Для нас здесь три основные цели:

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

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

3. Делиться информацией с командой — данные о конкурентах нужны не только аналитикам, но и руководителю продукта, пресейлам и проектным командам.

2️⃣ Почему решили менять прежний подход?

Информация о конкурентах хранилась в разных источниках — Google-таблицах, Jira, Miro, Confluence. Поэтому не всегда было понятно, где искать нужные данные и насколько они актуальны.

В таблице накопилось больше 50 компаний, которые мы анализировали и за которыми хотим следить. Ориентироваться в таком объеме становилось все сложнее.

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

3️⃣ Как удалось собрать все в систему?

Выбрали Miro как единую базу знаний: там храним краткую информацию о конкурентах, роадмап анализа и ссылки на подробные материалы — кейсы, проекты, скриншоты, презентации и видео с мистери-шоппинга.

В Miro сравниваем конкурентов по выручке, формату работы продукта и наличию функций. За подробностями можно перейти в Confluence, на сайт или в документацию компании.

4️⃣ Как сделали анализ регулярным?

Добавили повторяющиеся задачи: раз в две недели смотрим рассылки, Telegram-каналы и обновления продуктов, а раз в полгода пересматриваем роадмап анализа.

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

Мистери-шоппинг проводим, когда открытых источников недостаточно.

5️⃣ Почему недостаточно пересматривать всех конкурентов раз в год или два?

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

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

6️⃣ Как понять, кого анализировать в первую очередь?

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

Для сравнения определили критерии: финансовую динамику, формат работы продукта — в облаке или инфраструктуре клиента — и наличие функций на базе LLM. Так проще ориентироваться среди 50+ компаний и выбирать, кого изучать подробнее.

7️⃣ Какие инструменты помогают следить за изменениями?

Для десяти ключевых конкурентов настроили Google Alerts — раз в неделю получаем подборку новостей о них. Еще подписались на Telegram-каналы и рассылки компаний, а раз в две недели выделяем час на просмотр источников.

8️⃣ Что изменилось после перестройки процесса?

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

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

Подборка материалов: что почитать аналитику

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

➡️ ИИ для бизнес-аналитика

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

➡️ Как подружить работу дизайнера и аналитика

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

➡️ Мягкие навыки аналитика

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

➡️ Как продуктовый аналитик помогает разработке двигаться быстрее 

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

➡️ Рецепты самопомощи аналитика

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

Сохраняйте подборку, чтобы материалы всегда были под рукой ❤️

Хороший код: как понять, что его будет удобно менять

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

Вместе с Ринатом, iOS-разработчиком в Naumen, разбираемся, почему хороший код проверяется следующей задачей, как проявляется сложность изменений и на что стоит смотреть при оценке кода.

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

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

Так что даже не самое удачное решение какое‑то время не доставляет особых проблем.

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

Именно в этот момент становится понятно, насколько код вообще рассчитан на изменения.

Простая задача может оказаться дорогой

Одна из задач у нас на планировании звучала безобидно:

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

Само условие укладывается в несколько строк. Но сначала приходится выяснить, где на самом деле живет это правило: в сетевом клиенте, в сервисе авторизации, в middleware.

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

Смотреть нужно на изменение, а не на файл

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

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

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

Мне в этом контексте близко описание сложности изменений у Джона Оустерхаута. Он выделяет три характерных проявления.

• Маленькая правка расползается по системе

Добавили поле в модель и приходится менять сетевой слой, хранилище, аналитику, несколько экранов и тестовые данные.

Иногда это естественная цена изменения контракта, а иногда — признак того, что одно знание размазано по проекту.

• Для локальной работы нужно слишком много контекста

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

• Есть зависимости, о которых разработчик даже не знает

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

Эти признаки полезнее многих разговоров о «чистом коде»: о длине метода можно спорить, а вот с последствиями изменения — сложнее.

Обычно я смотрю на три вещи

1. Сколько мест потребуется затронуть?

2. Сколько информации нужно восстановить перед работой?

3. Как быстро мы узнаем, что ошиблись?

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

Как ИИ помогает специалистам по безопасности

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

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

1️⃣ Как ИИ помогает разбирать инциденты?

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

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

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

2️⃣ Как ИИ помогает проверять защищенность приложений?

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

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

3️⃣ Может ли ИИ находить уязвимости еще на этапе разработки?

Да. Современные модели умеют находить типовые веб‑уязвимости — например, SQL‑инъекции, XSS и CSRF, — участвовать в ревью кода и объяснять, почему выбранный подход может быть опасен.

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

4️⃣ Где еще он может пригодиться?

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

5️⃣ Какие ограничения важно учитывать?

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

Отдельный вопрос — работа с чувствительными данными. Для таких сценариев разумнее использовать локальные модели без доступа в интернет.

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

→ Подробнее своим опытом Евгений поделился в статье.

Ошибки при работе с ИИ. Часть 2

Продолжаем разбирать частые ошибки при работе с ИИ вместе с Константином, экспертом по ИИ в Naumen.

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

4️⃣ Верим, что ИИ знает все

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

В чем суть

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

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

Как исправить

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

2. Для проверки и поиска актуальных фактов используйте внешние инструменты — поисковые модули, RAG, MCP или другие подключения к источникам данных.

3. Не перегружайте контекст и подключайте нужные модули.

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

• Плохой промпт: «Какая сейчас актуальная версия библиотеки X и какие методы в ней устарели?».

• Хороший промпт: «Используй официальную документацию библиотеки X, подключенную через MCP. Проверь актуальную версию и методы, которые помечены как устаревшие. Укажи дату релиза и добавь ссылки на соответствующие разделы документации».

5️⃣ Не спрашиваем ИИ, как с ним работать

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

В чем суть

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

Как исправить

1. Опишите ИИ, что хотите сделать и что не получается.

2. Спросите прямо в чате, как лучше подступиться к задаче.

3. Если сложно сформулировать запрос, попросите ИИ задать уточняющие вопросы и помочь собрать ТЗ.

6️⃣ Не экспериментируем с подходами

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

В чем суть

Работа с ИИ — это навык, которому нужно учиться, как когда-то работе с Word или Excel. Он развивается через практику, изучение возможностей и поиск своего рабочего формата.

Как исправить

1. Пробуйте разные подходы к задачам.

2. Тестируйте разные модели и связки инструментов.

3. Ищите свой рабочий формат и продолжайте экспериментировать.

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

Подборка материалов: что почитать тестировщику 

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

➡️ Мифы о тестировании

Какие ожидания от профессии расходятся с реальностью и чем на самом деле занимается тестировщик.

➡️ Тестирование верстки

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

➡️ Как начинающему тестировщику выстраивать рабочий диалог в команде

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

➡️ Инструменты ручного тестирования

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

➡️ Как тестировать требования

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

Сохраняйте подборку, чтобы материалы всегда были под рукой ❤️

Ошибки при работе с ИИ. Часть 1

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

Пообщались с Константином, экспертом по ИИ в Naumen, и собрали несколько частых ошибок, которые встречаются в работе с нейросетями. 

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

1️⃣ Решаем все задачи в одном чате

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

В чем суть

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

Как исправить

1. Открывайте новый чат под новую тему.

2. Большую задачу делите на этапы.

3. Перед следующим этапом делайте выжимку.

2️⃣ Ставим задачу без необходимых рамок

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

В чем суть

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

Как исправить

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

• Плохой промпт: «Вот документ с заметками, таблицами и ссылками. Проанализируй его и выдели главное».

• Хороший промпт: «Проанализируй документ и выдели: ключевые показатели, отклонения, возможные причины и риски. Не используй информацию из черновых заметок и внешних ссылок. Результат собери в таблицу: показатель → значение → отклонение → комментарий».

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

→ Полезный инструмент для голосовой надиктовки задач и контекста для ИИ.

3️⃣ Передаем ИИ конфиденциальные данные

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

В чем суть

При работе с внешними ИИ-сервисами правила работы с данными зависят от платформы и тарифа. Поэтому важно понимать, что можно передавать, а что нужно обезличить.

Как исправить

1. Удалите или замените API-ключи, пароли, имена и контакты плейсхолдерами.

2. Уберите данные, без которых и так можно решить задачу.

3. Если сомневаетесь, попросите ИИ подсказать способ обезличивания на нейтральном примере.

• Плохо:

  API_KEY=7hd83k...
user_name=Иван Иванов
user_phone=+7...

• Хорошо:

  API_KEY=KEY_HERE
user_name=USER_NAME
user_phone=PHONE_NUMBER

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

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

Как давать и принимать обратную связь

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

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

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

🔸 Когда обратную связь дают вам

• Сначала уточните, о чем речь

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

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

Что именно стоит изменить?
Можешь привести пример?
Какого результата ты ожидал?

Чем конкретнее комментарий, тем проще понять, нужно ли что-то менять и что именно.

• Отделяйте наблюдение от оценки

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

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

Можешь подсказать, где именно была ошибка и на что она повлияла?

• Не спешите соглашаться или спорить

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

Спасибо за обратную связь. Я подумаю над этим и вернусь с ответом.

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

🔸 Когда обратную связь даете вы

Хорошая обратная связь отвечает на три вопроса: что произошло → на что это повлияло → что делать дальше.

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

«Ты безответственный», «ты постоянно все затягиваешь» звучат как вывод о человеке. С таким выводом сложно что‑то сделать — остается только соглашаться с ним или защищаться.

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

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

• Обсуждайте, что именно стоит изменить

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

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

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

Что можно сделать иначе в следующий раз?

• Говорите не только об ошибках

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

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

Как сделать встречу 1:1 полезной для себя

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

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

1️⃣ Определите, что хотите обсудить

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

2️⃣ Говорите конкретно

Вместо «все сложно» расскажите, что именно происходит, приведите пример и объясните, как это влияет на работу. Так будет проще вместе найти решение.

3️⃣ Не ограничивайтесь проблемами

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

4️⃣ Сформулируйте, какая помощь нужна

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

5️⃣ Просите обратную связь

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

6️⃣ Зафиксируйте договоренности

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

Что в итоге?

1:1 — это не отчет перед руководителем, а возможность повлиять на свою работу, вовремя получить поддержку и обозначить то, что для вас действительно важно.

Почему современные интерфейсы иногда усложняют жизнь

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

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

1️⃣ Как изменилось взаимодействие человека с интерфейсами?

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

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

2️⃣ Почему даже современный интерфейс может утомлять пользователя?

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

3️⃣ Получается, «проще» не всегда означает «лучше»?

Именно. Иногда в погоне за минимализмом или новыми трендами мы убираем то, что было интуитивно понятно. 

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

4️⃣ Можно ли создать интерфейс, который будет удобен для всех?

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

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

5️⃣ Как понять, что новое решение действительно улучшает интерфейс?

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

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

Подборка книг по эффективной работе в команде

Эффективная работа в команде строится на «трех китах»: доверии, четких целях и умении конструктивно общаться. Именно продуктивное взаимодействие с коллегами позволяет быстрее и качественнее достигать общих результатов.

Собрали подборку книг, которые помогут отработать эти навыки на практике.

• «Наука общения», Ванесса Ван Эдвардс

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

• «Пять пороков команды», Патрик Ленсиони

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

• «Идеальный командный игрок», Патрик Ленсиони

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

• «Правила команды. Искусство думать вместе», Максим Поташев, Павел Ершов

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

• «Как создать настоящую команду», Дэвид Шервин, Мэри Шервин

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

Почему хорошие вопросы ценятся не меньше хороших ответов

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

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

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

Спрашиваем «как», не разобравшись с «зачем»

❌ «Как нам реализовать эту фичу?»

✔️ «Какую задачу решаем этой фичей? Есть ли другие способы?»

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

Не проверяем, был ли похожий опыт в команде

❌ «Как правильно настроить X?» 

✔️ «Кто-нибудь в команде уже настраивал X или сталкивался с похожей задачей?»

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

Не даем контекста

❌ «У меня ошибка, можете помочь?»

✔️ «Получаю ошибку X при действии Y. Уже проверил A и B, но проблема осталась. Вот лог / скрин / ссылка. Подскажите, где еще посмотреть?»

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

Просим оценку, когда нужна обратная связь

❌ «Правильно ли я сделал?»

✔️ «Что можно улучшить в этом решении? Есть ли риски, которые я не учел?»

Вопрос «правильно ли?» часто сводит ответ к короткому «да» или «нет». Но в работе важны нюансы: возможные риски, альтернативы, слабые места. Если сразу попросить не оценку, а обратную связь, обсуждение получится полезнее.

Не задаем фокус для ответа

❌ «Что думаешь?»

✔️ «Посмотри, пожалуйста, логику: понятно ли, какую проблему решаем и почему предлагаем именно такое решение?»

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

Автоматизировать, нельзя делать вручную

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

Константин, специалист по ИИ в Naumen, рассказал, какие задачи стоит автоматизировать в первую очередь и по каким признакам понять, что процесс действительно подходит для ИИ.

Проверьте процесс по трем критериям

Перед тем как автоматизировать любую задачу, ответьте на три вопроса.

1. Боль. Насколько процесс раздражает, отнимает время или приводит к ошибкам?

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

3. Стоимость автоматизации. Есть ли понятные правила, по которым выполняется задача, или каждый делает ее по-своему?

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

В первую очередь автоматизируйте работу с информацией

Практически любая задача, связанная с обработкой информации, — хороший кандидат для автоматизации.

Например:

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

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

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

Следующий шаг — база знаний команды

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

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

• отвечает на вопросы;

• находит нужные фрагменты;

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

• снижает количество однотипных вопросов внутри команды.

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

Например, вместо поиска по нескольким чатам можно просто спросить ассистента: «Как у нас проходит релиз продукта?» или «Какие требования сейчас действуют для этой интеграции?».

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

Например, менеджер по продажам может попросить: «Объясни простыми словами, как работает эта функция, чтобы я мог рассказать о ней заказчику без технических терминов».

Создать такого ассистента сегодня можно несколькими способами

• Для команды

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

• Для общей базы знаний

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

• Для личной работы

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

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

Как перестать вручную поддерживать экран настроек

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

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

Илья, iOS‑разработчик в Naumen, рассказывает, как пришел к подходу, при котором разработчику достаточно описать новое свойство, а интерфейс собирается автоматически.

Почему задача оказалась сложнее?

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

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

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

Почему обычный экран настроек не решил проблему?

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

Чтобы добавить новую настройку, нужно было каждый раз:

• добавлять свойство;

• добавлять соответствующий UI‑компонент;

• настраивать обработку;

• связывать с хранилищем данных.

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

В этот момент я вспомнил про Reflection. В Swift этот механизм ограничен и фактически работает как интроспекция, но даже этих возможностей оказалось достаточно для решения задачи.

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

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

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

• для булевых значений — переключатели;

• для текста — поля ввода;

• для чисел — поля с ограничением на числовой ввод.

Что изменилось после внедрения такого подхода?

Теперь для добавления новой настройки достаточно описать новое свойство и добавить необходимые метаданные. После этого настройка автоматически появляется в интерфейсе.

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

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