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

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

Пока команда занята своими задачами, у других игроков появляются новые функции и меняется фокус. Поэтому в 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%. Кроме того, уменьшилось количество дублирующего кода, а интерфейс стал более единообразным и предсказуемым для пользователей.

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

Как посмотреть на задачу глазами исполнителя

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

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

1️⃣ Как ИИ может помочь сформулировать задачу?

У нас в команде есть ассистент Dev Describer. Он помогает формулировать бизнес-требования к задачам разработки.

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

Ассистент поможет уточнить детали:

• когда именно показывать уведомление; 

• для каких пользователей оно должно работать; 

• какой текст нужен;

• что считается ожидаемым результатом.

Если нужны дополнительные материалы — схемы, ссылки, скриншоты — мы сразу фиксируем их в задаче вместе с текстом.

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

2️⃣ А как проверить постановку перед передачей в работу?

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

Например: «Ты — исполнитель этой задачи. Тебе важно найти пробелы, которые мешают приступить к работе».

После этого ассистент помогает заметить:

• где не хватает контекста;

• что можно понять неоднозначно;

• каких вводных не хватает;

• какие вопросы, скорее всего, появятся у команды.

3️⃣ Что это дает в работе?

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

4️⃣ Где такой подход особенно полезен?

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

Как замечать тренды раньше конкурентов

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

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

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

Что такое трендвотчинг

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

Это не фиксация текущего состояния рынка, а попытка понять, куда он движется дальше.

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

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

Трендвотчинг позволяет смотреть шире:

• какие технологии становятся доступнее;

• какие решения набирают популярность в смежных индустриях;

• какие темы растут в поиске и популярны в отраслевых обзорах.

Так можно заметить изменения раньше, чем они станут массовыми.

Где искать ранние сигналы 

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

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

• Product Hunt, Trend Hunter и Springwise — чтобы следить за новыми продуктами и идеями;

• Google Trends и Яндекс.Вордстат — чтобы анализировать интерес пользователей;

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

Как понять, что тренд действительно важен

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

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

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

2. Расширьте его синонимами и альтернативными формулировками.

3. Сравните данные по регионам и сегментам аудитории.

4. Посмотрите динамику и сезонные всплески интереса.

5. Автоматизируйте мониторинг, создав дашборды и оповещения.

Как встроить трендвотчинг в рабочий процесс

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

Когда сигналы собраны, их можно структурировать с помощью:

• Trend Canvas — для глубокого анализа тренда;

• упрощенного SWOT-анализа — для быстрой первичной оценки.

Чек-лист работы с трендами

• Формулировка цели и задач исследования.

• Сканирование сигналов — системный поиск и сбор информации.

• Интерпретация и систематизация.

• Оценка и приоритизация. 

• Эксперименты и тесты — прототипы, MLP, пилоты.

• Масштабирование и интеграция.

Какие тренды уже заметны на рынке

Один из самых заметных трендов сегодня — развитие low-code и no-code подходов.

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

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

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

Почему выигрывают внимательные

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

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

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

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

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

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

Ассистент работает с материалами встреч напрямую

Мы подключили ассистента к материалам встреч в Контур Толк через MCP. Поэтому теперь не нужно искать транскрипции и вручную передавать их в языковую модель для обработки.

Например, достаточно спросить:

• «Что было на встрече с командой X?»

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

• «Какие договоренности зафиксировали по проекту?»

Ассистент: «Команда согласовала сроки и распределила зоны ответственности».

• «О чем говорили на последнем созвоне?»

Ассистент: «Обсуждали проблемы интеграции и дальнейшие шаги по проекту».

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

Важно: ИИ не заменяет человека

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

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

Как ИИ помогает разобраться в незнакомом проекте

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

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

Можно дать ИИ репозиторий, документ или ссылку и попросить:

• объяснить, о чем проект;

• рассказать, какие технологии используются;

• подсказать, с чего лучше начать изучение.

Например: «Я junior-разработчик. Объясни, что делает этот репозиторий и какие технологии здесь используются».

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

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

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

Егор, аналитик в Naumen Contact Center, рассказал, как внутри продукта устроено нагрузочное тестирование и почему «запустить тест» — самая простая часть.

• количество одновременно работающих операторов

• нагрузка на входящие и исходящие вызовы

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

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

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

3️⃣ Когда нужно проводить нагрузочное тестирование?

Есть несколько типичных ситуаций, когда без него не обойтись:

• Регулярные проверки перед релизом или после обновления серверов.

• Тестирование новых фич — если изменения потенциально могут повлиять на производительность.

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

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

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

4️⃣ Как принимается решение о проведении тестирования?

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

5️⃣ Как устроен процесс нагрузочного тестирования?

Процесс можно разделить на три этапа:

1. Первичная аналитика — собираем требования и определяем цель.

2. Детальная аналитика — описываем сценарии, метрики, инфраструктуру.

3. Проведение тестов — запускаем тестирование и анализируем результаты.

6️⃣ Почему нагрузочное тестирование требует отдельной инфраструктуры?

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

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

7️⃣ Почему даже короткий тест может занимать полтора часа?

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

8️⃣ Что происходит после тестирования?

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

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

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

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

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

Ринат, iOS‑разработчик Naumen, рассказал об инструментах, которые помогают ему решать такие задачи и упрощать повседневную работу.

• Periphery: поиск мертвого кода в Swift‑проектах

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

Periphery помогает находить такие места и наводить порядок перед изменениями в кодовой базе.

Как использую

Запускаю Periphery перед рефакторингом — например, когда нужно обновить модуль профиля с сотнями файлов.

periphery scan

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

Что важно знать: результаты всегда нужно проверять вручную. Инструмент может не учитывать динамические вызовы, reflection, Objective-C runtime, storyboard-ссылки или код, который используется через строки.

• Network Link Conditioner: тестирование слабой сети

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

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

Как использую

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

Что важно знать: проверять стоит не только низкую скорость интернета, но и нестабильность сети. А еще важно не забывать выключать Conditioner после проверки :)

• just: короткие команды вместо длинных инструкций

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

just собирает основные сценарии работы в одном месте и запускает их через короткие понятные команды. В итоге justfile становится чем‑то вроде живой документации проекта.

Как использую

Чтобы каждый раз не вспоминать синтаксис, храню основные сценарии работы в justfile.

test:
    xcodebuild test -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone 15'
format:
    swiftformat .
    swiftlint
clean:
    rm -rf ~/Library/Developer/Xcode/DerivedData

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

just test
just format
just clean

Что важно знать: just не заменяет CI, Makefile или build system. Это скорее удобный слой для повседневных команд. Поэтому лучше держать justfile простым и не превращать его в большой набор скриптов.

• Mint: фиксация версий CLI-инструментов на Swift

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

Как использую

Вместо глобальной установки SwiftLint, SwiftFormat, XcodeGen или других CLI‑инструментов можно хранить версии в Mintfile и запускать их одинаково у всех разработчиков.

mint run realm/SwiftLint
mint run nicklockwood/SwiftFormat

Что важно знать: Mint полезен именно для Swift CLI-пакетов. Для Ruby-gems, Node.js-инструментов или системных утилит понадобятся другие менеджеры. Также важно кэшировать установленные бинарные файлы в CI, иначе сборки могут тратить лишнее время на установку инструментов.