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

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

Константин, специалист по ИИ в 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, иначе сборки могут тратить лишнее время на установку инструментов.

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

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

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

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

1️⃣ Где ИИ помогает в работе аналитика?

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

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

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

2️⃣ Где ИИ уже приносил заметный результат в вашей команде?

Один из ярких кейсов — анализ диалогов в колл-центре. Робот успешно находил «теплых» лидов, но конверсия в покупку оставалась низкой. 

Мы подключили анализ диалогов с помощью LLM и выяснили, что корректно работали только около 7% операторов.

Ошибки у них были довольно базовые, но их сложно заметить без детальной аналитики:

• не знали о звонках робота

• сбрасывали звонки клиентов или вызывали негатив

• повторно проводили идентификацию

• работали с плохим оборудованием

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

3️⃣ Что изменилось после этого?

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

А еще:

• итоговая конверсия увеличилась примерно в 1,5 раза

• выручка по проекту выросла в 2 раза

С точки зрения личной эффективности я теперь экономлю до 20 часов в месяц на прослушке диалогов и могу анализировать до 100 диалогов в час. 

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

4️⃣ Какие задачи еще можно отдать ИИ в работе аналитика?

Помимо анализа данных:

• подготовка презентаций 

• написание текстов

• проведение исследований

• сбор и структурирование данных

• оформление документации

Это не заменяет аналитика, но сильно упрощает старт и ускоряет процесс.

5️⃣ Какие инструменты тебе показались полезными?

Из того, что я использовала в работе:

1. GigaChat — хорошо справляется с исследованиями на российском рынке

2. SkyWork.ai и Gamma — помогают быстро собрать презентацию и структуру доклада

3. НейроЭксперт — удобно работать с файлами и базой знаний

4. Ассистенты для генерации промптов от Naumen — чтобы не просто перефразировать промпт, а уточнить задачу через вопросы и сделать его точнее

5. Кастомные агенты с использование Claude Code — чтобы автоматизировать процесс и сократить ручную работу

6️⃣ Есть ли риски или ограничения, о которых важно помнить?

Да, и об этом часто забывают. Перед использованием данных важно:

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

• обезличивать данные

• проверять результаты

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

Клиент + Продакт + Сервис = любовь QBR

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

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

1️⃣ Что такое Quarterly Business Review (QBR)

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

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

2️⃣ Зачем вообще появился этот формат

Он вырос из конкретных проблем. 

1. Клиентский сервис чаще реагировал, чем инициировал диалог — клиент приходил сам, когда уже есть проблема.

2. Продукт общался с клиентами точечно — под конкретные задачи, без системности.

3. Клиенту не хватало понимания, влияет ли он вообще на продукт.

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

3️⃣ Почему не сработали Excel-таблицы

До QBR мы пробовали собирать запросы клиентов через Excel-таблицы: менеджеры фиксировали идеи, передавали продукту, но дальше все разваливалось.

Не хватало контекста + появлялись вопросы = мотивация заполнять таблицы падала.

4️⃣ Что изменилось, когда позвали клиента в диалог

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

5️⃣ Как устроена встреча

Есть базовая структура:

• разбираем текущие вопросы и контекст по клиенту;

• обсуждаем, что происходит в бизнесе клиента;

• синхронизируемся по метрикам эффективности;

• собираем обратную связь и сложности в работе;

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

• фиксируем договоренности.

6️⃣ Что важно в ролях

1. Менеджер клиента — ведет встречу и держит контекст.

2. Руководитель сервиса — подключается к сложным вопросам.

3. Менеджер продукта — отвечает за продуктовую экспертизу.

Без полного состава встреча сильно теряет в качестве.

7️⃣ Что может пойти не так

• Встреча превращается в список «хотелок»

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

• Клиенту некомфортно отвечать на вопросы про бизнес

Стоит заранее объяснить, зачем это нужно — чтобы лучше настроить продукт под задачи бизнеса.

• Клиент приходит с негативом

Это нормально. Лучше обсудить проблему открыто, чем получить ее в отложенном виде. 

• К следующей встрече нет изменений

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

8️⃣ QBR работает, если

1. Клиентский сервис и продукт готовятся к встрече вместе.

2. Разговор идет про бизнес клиента, а не только про продукт.

3. Подключены участники со стороны клиента на разных уровнях.

4. Договоренности фиксируются и превращаются в конкретные действия.

Зачем продукту исследования

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

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

• конкурентный анализ

• глубинные интервью

• древовидное тестирование

• опросы

• юзабилити-тестирование

3️⃣ Как выглядел конкурентный анализ?

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

Разложили все по критериям UX/UI, собрали в единую базу и выделили паттерны и антипаттерны. После этого уже было с чем идти к пользователям.

4️⃣ Какую пользу получили от глубинных интервью?

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

Дополнительно прогоняли обезличенные данные через ChatGPT и находили то, что сами могли упустить.

5️⃣ Зачем понадобилось древовидное тестирование?

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

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

6️⃣ Что оказалось самым неожиданным?

Вот несколько ключевых мыслей:

• Уведомления раздражают — 8 из 10 пользователей их просто выключают и потом переживают, что что-то пропустили.

• Пользователям нужно меньше, чем кажется — основные сценарии: список или доска задач, карточка задачи и смена статуса.

• 8 из 10 пользователей не списывают трудозатраты — это стало поводом пересмотреть приоритеты и не перегружать продукт лишним функционалом.

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

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

• Блок «Недавние» очень востребован — пользователи прямо просили его добавить.

7️⃣ Был момент, когда исследования помогли не продукту, а вашей команде?

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

8️⃣ Какой главный вывод из всего этого опыта?

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

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

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

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

→ Смотрите видео на любой удобной платформе: VK Видео, Rutube и YouTube.

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

Попросили Костю, frontend-разработчика Naumen, рассказать, какие возможности DevTools он использует в работе и на что стоит обращать внимание.

1️⃣ Как открыть DevTools, если F12 не сработал

Самый простой способ — клавиша F12 для Windows/Linux. На macOS сочетание отличается, но открыть DevTools можно не только с клавиатуры.

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

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

2️⃣ Как работать с версткой во вкладке Элементы

Вкладка Элементы показывает DOM-дерево страницы — структуру документа, из которого собран интерфейс. 

Здесь можно:

• навести курсор на элемент и посмотреть, где он находится на странице

• быстро найти нужный блок через селектор

• посмотреть размеры, фон и отступы

А еще можно посмотреть доступность — как элементы переключаются через Tab.

3️⃣ Как находить итоговые стили 

Если у элемента много CSS-правил, я перехожу во вкладку Вычисленные.

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

4️⃣ Как проверять изменения без правок в коде

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

После обновления страницы все возвращается как было.

5️⃣ Как разбирать запросы во вкладке Сеть

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

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

6️⃣ Как подменять ответ бэка

В DevTools можно изменить ответ запроса и посмотреть, как на него отреагирует интерфейс.

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

7️⃣ Как проверять работу при медленном интернете

DevTools позволяют проверить, как работает интерфейс при плохом соединении. Во вкладке Сеть можно:

• выбрать готовые профили — 3G, 4G

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

• протестировать поведение приложения в режиме офлайн

8️⃣ Как работать с локальными данными

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

1. Локальное хранилище — данные, которые сохраняются надолго и не исчезают после перезагрузки страницы.

2. Сессионное хранилище — данные, которые живут только пока открыта вкладка.

3. Файлы cookie — похожи на локальное хранилище, но у них есть срок жизни и дополнительные ограничения по источнику.

Все это можно просматривать, изменять и очищать. 

9️⃣ Как менять геолокацию и часовой пояс

DevTools позволяют изменить геолокацию и часовой пояс, не меняя настройки операционной системы.

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

🔟 Как записывать пользовательские сценарии

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

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

ИИ-помощник для анализа требований

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

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

Рассказываем, как они собирали данные, какие подходы пробовали и как в итоге пришли к решению на базе RAG.

1️⃣ Чем занимается техпресейл

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

Чаще всего работа техпресейла с клиентом начинается с опросника — Excel-документа с требованиями.

2️⃣ Почему Excel-файл оказался неудобным для анализа требований

Типичный опросник — это таблица с тремя колонками:

• требование клиента

• какой продукт соответствует

• комментарии

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

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

3️⃣ С чего мы начали автоматизацию

Сначала нужно было собрать данные. Поэтому первым шагом мы:

1. Собрали все опросники за год в единый массив.

2. Привели их к единому формату.

3. Классифицировали требования.

4. Проверили и почистили данные от дублей и неточностей.

В итоге получился датасет примерно из 2 000 требований, который стал основой нашей базы для тестирования ИИ-помощника.

4️⃣ Почему классические модели не сработали

Первой идеей было использовать классические методы анализа текста. Мы пробовали TF-IDF, Bag-of-Words и стандартные модели классификации.

Но столкнулись с двумя проблемами:

• низкое качество классификации

• дисбаланс данных

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

5️⃣ Как мы пришли к RAG-подходу

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

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

Так мы пришли к подходу RAG (Retrieval-Augmented Generation) — LLM сначала находит факты в базе знаний, а уже потом формирует ответ.

6️⃣ Как работает наш ассистент

Сервис работает в Telegram-боте и поддерживает два сценария.

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

Загрузка Excel-файла — пользователь загружает файл с требованиями, после чего сервис проходит по каждой строке и автоматически заполняет:

• соответствие (да / нет / не знаю)

• комментарий с объяснением соответствия

7️⃣ Из чего состоит база знаний

Мы используем два источника:

• документацию по продуктам Naumen

• структурированные опросники из прошлых проектов

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

8️⃣ Какие есть ограничения у ассистента

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

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

Также иногда встречается типичная проблема LLM — галлюцинации. Поэтому финальную проверку ответа все равно делает системный аналитик.

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

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

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

В распределенных командах работают два формата общения:

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

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

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

Формат общения лучше выбирать под задачу. Я ориентируюсь на простое правило:

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

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

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

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

1. Что происходит?

2. В чем проблема?

3. Что нужно от собеседника?

Например:

Делаю импорт отчета клиента. Вот ссылка. Получаю ошибку Invalid format. Можешь посмотреть формат файла?

Такой вопрос можно решить быстрее, потому что у человека есть вся информация.

Почему чаты постоянно отвлекают

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

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

• критичные чаты — уведомления включены

• обсуждения без срочности — выключены

Почему важна культура обратной связи

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

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

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

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

С Настей, руководителем команды проектирования интерфейсов, разобрали эту ситуацию на примере взаимодействия аналитиков и дизайнеров.

1️⃣ Почему при согласованных требованиях все равно возникает недопонимание?

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

2️⃣ Как ты это проверила?

Я решила не опираться только на ощущения и провела быстрые интервью. Задала 20–25 коллегам два вопроса и попросила ответить коротко:  

1. Что ты делаешь на работе как аналитик или дизайнер?  

2. Что, по твоему мнению, делает другая сторона?

3️⃣ Что оказалось самым показательным в ответах?

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

4️⃣ Какие формулировки сигнализировали о недопонимании?

• «Дизайнеры делают красиво, но малофункционально».  

• «Не понимаю, что дизайнер делает две недели».  

• «Красивый интерфейс — это субъективно».  

• «Да там же просто пару экранов, что тут обсуждать?».

• «Потом допилим UX, сейчас главное выпустить фичу».

Эти фразы редко звучат в лоб, но задают тон обсуждению решений.

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

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

6️⃣ Почему возникает вопрос «что ты делал две недели»?

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

7️⃣ Насколько справедлив тезис «красиво = субъективно»?

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

8️⃣ Как правильно формулировать задачу для дизайнера?

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

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

9️⃣ Что в итоге помогает снизить напряжение между аналитиком и дизайнером?

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

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

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

Как перестать быть центром всех решений и не потерять контроль :)

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

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

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

1️⃣ Что происходит, когда процессы держатся на одном человеке

Я пришла в Naumen в 2015 году. В 2020 у меня появилась первая команда из трех аналитиков. Через год — уже две команды. Сейчас это три команды: три тимлида, два техлида и двадцать аналитиков.

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

2️⃣ Три страха, которые мешают передавать процессы

Когда я решила что-то менять, сначала пришлось разобраться со своими страхами:

1. Я стану не нужна

2. Перегружу команду

3. Команда что-то сделает не так

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

А еще я поняла: если процесс живет только при моем участии — это слабое место, а не моя ценность.

3️⃣ Как мы перестроили систему консультаций

Раньше все было просто: любой сложный вопрос — ко мне. Я объясняла одно и то же разным людям, и это отнимало все больше времени.

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

• Опытные аналитики по каждой заявке

• Скриптолог дня для базовых техвопросов

• Техлиды для сложных техвопросов

• Третья линия как финальная инстанция

В этой схеме больше нет обязательного шага «спросить у Кати» :)

Важно, что я не просто объявила новые правила. Я объяснила команде, зачем им это, и дала возможность сказать, если что‑то не работает.

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

4️⃣ Как мы перестали тратить часы на планирование дежурств

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

Теперь оставила себе только рамки: сколько слотов нужно закрыть и какие роли должны быть в дежурствах. Все остальное передала команде.

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

Я больше не держу в голове десятки нюансов — команда решает их самостоятельно.

5️⃣ Как быть с кризисными ситуациями

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

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

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

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

Когда задача считается выполненной

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

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

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

Настя, тестировщик:

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

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

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

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

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

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

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

Олег, android-разработчик:

Задача выполнена, когда:

1. Функциональность реализована и проверена вручную — примерно так, как это сделал бы тестировщик, но без учета конкретных тест-кейсов.

2. Новое поведение решает цель задачи, а не просто повторяет постановку. Иногда по ходу работы находится вариант проще для разработки/поддержки или удобнее для пользователя — выбираю его. Фича должна закрывать потребность.

3. Пограничные случаи поведения (corner cases) проработаны и учтены. В постановке не всегда учитываются моменты, которые становятся заметны в коде. Например, что показать на мобильном клиенте при 500 ответе сервера или при долгой загрузке из-за задержки ответа сервера.

4. Новое поведение покрыто тестами, есть уверенность, что его не сломают случайно. Также важно, чтобы оно не сломало существующие автотесты.

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

Как развивать документацию и продвигать техписателей

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

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

С чего вообще началась эта работа и какую задачу вы перед собой ставили?

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

Как вы к этому подошли на практике?

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

Еще мы выделили ключевых заказчиков и сгруппировали их. Это были аналитики и руководители продуктов, разработчики и тестировщики, поддержка, инженеры инфраструктуры, коллеги из маркетинга и дизайна. Благодаря этому вместо 51 интервью получилось провести 19, этого оказалось достаточно.

Как проходили интервью и что оказалось самым сложным?

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

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

Что получилось после обработки всех интервью?

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

Как вы поняли, за что браться в первую очередь?

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

Какие результаты уже есть?

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

Твой главный вывод из этого опыта?

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

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

Рассказываем, на что обращаем внимание при проверке верстки и какие моменты проверяем в первую очередь.

1️⃣ С чего начинаем тестирование верстки?

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

• максимально короткие значения — точка, пробел;

• максимально длинный текст, который можно ввести;

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

Если ограничений в ТЗ нет, смотрим, какой тип поля используется в базе данных. Часто это varchar(255), от этого и отталкиваемся при проверке.

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

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

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

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

• для кириллицы — «Щ»;

• для латиницы — «W».

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

3️⃣ Что проверяем в макете?

Например, в макете Figma мы смотрим:

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

4️⃣ Как проверяем реализацию?

В браузере используем стандартные DevTools: смотрим вкладку Elements + разделы Styles и Computed.

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

Так проще напрямую сравнивать реализацию с макетом и не теряться в длинных CSS-цепочках.

5️⃣ Что важно знать о состояниях элементов?

Чаще всего это кнопки. В DevTools можно вручную включить состояния:

• :hover

• :active

• :focus

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

6️⃣ На что еще обращаем внимание?

Отступы могут быть реализованы через padding (внутренний) и margin (внешний).

Важно помнить, что высота текстового блока определяется line-height. Если высота строки отличается от макета — поплывут и расстояния между элементами, даже если padding и margin заданы верно.

7️⃣ Когда удобно считать руками, а когда — линейкой?

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

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

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

Интересно сравнить подходы: какие проверки верстки вы считаете обязательными в своей практике, а какие — избыточными?