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

Боль против «крутых» идей: в чём суть

Болевая проблема — это то, что люди уже ощущают в повседневной жизни или работе: то, что надёжно стоит им времени, денег, дохода, сна, репутации или создаёт риск несоответствия требованиям. Они не «заинтересованы» в решении; они уже пытаются уменьшить её влияние, даже если текущее решение страшно неровное (таблицы, ручные обходы, найм временных сотрудников или простое терпение).

«Крутая идея» — противоположность: нова, умна или захватывающа, но не связана с сильной, частой и дорогостоящей проблемой. Люди могут назвать её «клёвой» или «я бы пользовался», но они не меняют поведение и не выделяют бюджет, чтобы получить её.

Почему боль побеждает новизну

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

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

Как мы подходим к этому руководству

Это руководство следует повторяемому пути:

1. Выберите конкретного клиента и контекст.
2. Проведите customer discovery, чтобы обнаружить реальные ограничения.
3. Измерьте интенсивность боли.
4. Валидация спроса до разработки.
5. Спроектируйте MVP, который быстро приносит облегчение.
6. Позиционируйте вокруг проблемы и результата.
7. Ранние продажи для обучения.

Ожидание, которое нужно заложить сейчас

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

Почему «крутые» идеи часто проигрывают

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

Самые частые паттерны провалов

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

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

Проблема «без дедлайна»

Слабая боль порождает бесконечное откладывание. Если ваш продукт помогает с тем, что «доставляет неудобство», а не «стоит денег», покупатели постоянно откладывают: «вернёмся в следующем квартале». Это смертельно для базовых go-to-market моментов, потому что срочность превращает разговоры в решения.

Именно поэтому customer discovery должен фокусироваться меньше на том, что людям нравится, и больше на том, что они уже пытались исправить — особенно где на кону время, деньги или репутация. В терминах jobs-to-be-done: какая задача проваливается и какова цена провала?

Новизна может скрывать слабые сигналы спроса

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

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

Простой фреймворк для измерения боли

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

Шаг 1: Оцените боль (Частота × Тяжесть × Стоимость)

Проставьте каждой из трёх метрик оценку от 1 до 5, затем перемножьте.

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

Проблема, которая случается еженедельно (4), блокирует работу (5) и стоит $2k в месяц (4), получает 80 баллов. Редкая, лёгкая неприятность обычно не конкурирует.

Шаг 2: Определите, кто «владеет» этой болью

Запишите три роли:

• Пользователь: чувствует боль напрямую
• Покупатель: управляет бюджетом
• Утверждающий: должен подписать (безопасность, финансы, юристы)

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

Шаг 3: Ищите дедлайны, которые заставляют действовать

Боль становится срочной, когда к ней привязан таймер:

• сроки соответствия и аудиты
• потеря дохода (упущенные лиды, проваленные конверсии)
• риск оттока и продления контрактов
• простои, инциденты и эскалации на дежурных

Если клиент говорит «разберёмся в следующем квартале», ваша оценка боли, вероятно, приукрашена.

Шаг 4: Найдите обходные пути (доказательства боли)

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

• таблицы, ручное копирование, цепочки в Zapier
• кастомные скрипты, поддерживаемые одним человеком
• «процессные» митинги, которые существуют только для латания дыр

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

Выберите конкретного клиента и контекст

Болевая проблема превращается в бизнес, только если она принадлежит реальному человеку, в реальной ситуации, с реальными ограничениями (время, бюджет, инструменты, утверждения). «Малый бизнес» или «креаторы» — слишком широко: боль рассеивается, и обучение замедляется.

Начинайте узко, чтобы быстро учиться

Выбор конкретного клиента и контекста позволяет вам:

• быстро находить людей (вы уже знаете, где они собраны)
• слышать повторяющуюся проблему (сигнал важнее разнообразия)
• тестировать одно ясное обещание («сократить X боль в Y workflow»), а не расплывчатую ценность

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

Как заметить концентрированную боль

Ищите места, где люди жалуются срочно и подробно — особенно если одна и та же проблема проявляется повторно:

• Форумы и сообщества: треды с множеством ответов, обходными путями и просьбами о замене
• Отзывы конкурентов: оценки 2–3 звезды — золото, потому что там и что-то сломалось, и чего пользователи ждали
• Тикеты поддержки / документация: повторяющиеся «как мне…?» и «это блокирует меня»
• Вакансии и предложения агентств: когда компании платят за помощь, боль уже профинансирована

Концентрированная боль выглядит как повторяющиеся сценарии, сильные эмоции («это нас убивает») и люди, уже тратившие время или деньги на временные решения.

Простой шаблон ICP (копировать/вставить)

Используйте это, чтобы описать первого целевого клиента:

• Роль/должность:
• Тип/размер компании:
• Отрасль/ниша:
• Контекст/рабочий поток, где возникает боль:
• Триггер (когда это становится срочно):
• Текущее обходное решение/инструменты:
• Стоимость боли (время, деньги, риск):
• Кто чувствует, а кто платит:
• Где найти их на этой неделе (точный канал):

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

Customer discovery, которое находит настоящие проблемы

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

Спрашивайте о поведении, а не о мнениях

Вопросы мнения («Вы бы использовали…?», «Вам нравится…?») дают вежливые, неточные ответы. Вопросы о поведении показывают реальность.

Попробуйте подсказки:

• «Расскажите, как вы делаете это сегодня, шаг за шагом.»
• «Что запускает потребность в этом?»
• «Что вы делаете сразу после того, как всё идёт не так?»

Добивайтеcь конкретики недавними примерами

Преодолевайте туманные ответы, прося конкретный недавний случай:

• «Рассскажите о последнем разе, когда это случилось.»
• «Когда это было точно?»
• «Какие инструменты вы использовали?»
• «Кто ещё был вовлечён?»

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

Захватите полную стоимость боли

Боль измерима. Во время рассказа слушайте (и спрашивайте) о затратах:

• Время: «Сколько это заняло?» «Как часто это случается?»
• Деньги: «Сколько потратили?» «Были ли расходы на подрядчиков?»
• Риск: «Что могло бы пойти не так, если это не починить?»
• Стресс: «Как это влияет на ваш день или команду?»
• Упущенный доход: «Отложило ли это продажи, привело ли к оттоку клиентов или задержало релиз?»

Не продавайте — ищите паттерны

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

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

От заметок к проблеме, стоящей решения

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

Превратите интервью в ранжированный список проблем

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

Сделайте простую таблицу со столбцами: Проблема, Кто сказал, Частота, Тяжесть, Текущее обходное решение, Стоимость обхода. Ранжируйте проблемы быстрой оценкой (например, 1–5 за частоту и 1–5 за тяжесть). Перемножив, вы быстро увидите, что постоянно болит.

Ищите повторяющиеся формулировки и последствия

Обратите внимание на точные фразы, которые клиенты повторяют: «Мне это бесит…», «Всегда ломается, когда…», «Я застрял, ожидая…». Повторяющаяся формулировка — сигнал, что проблема на уме.

Также ищите повторяющиеся последствия — они часто сильнее, чем жалобы:

• «Мы пропускаем дедлайны.»
• «Мы возвращаем деньги клиентам.»
• «Я провожу воскресенья, работая допоздна.»

Определите чёткое problem statement

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

Для [конкретного клиента] в [конкретном контексте], [проблема] случается при [триггере], вызывая [болезненное последствие], потому что [коренная причина].

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

Решите, что игнорировать (даже если звучит интересно)

Некоторые проблемы будут выглядеть «больше» или «интереснее». Игнорируйте всё, что:

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

Остаётся ваш лучший кандидат на проблему, стоящую решения.

Проверьте спрос до разработки

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

Доказательства реального спроса

Лучшие сигналы включают обязательства:

• Предзаказы (деньги сейчас за доставку позже). Даже возвратный депозит имеет значение — он заставляет принять решение.
• LOI с чётким объёмом и ожидаемой ценой. Расплывчатое «нам интересно» — это шум.
• Пилоты с определёнными сроками, критериями успеха и доступом к данным/рабочим процессам.
• Платные пробные периоды (малые, ограниченные по времени и цене). Бесплатные триалы валидируют использование; платные — срочность.

Запустите лендинг + аутрич-тест

Создайте простую посадочную страницу с одним конкретным предложением: для кого, какая болезненная ситуация, обещанный результат и чёткий CTA (записаться на разговор, присоединиться к пилоту, оставить депозит). Затем делайте таргетированную рассылку людям, которые точно соответствуют контексту.

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

Правильно задавайте вопросы про цену

Избегайте «Сколько бы вы заплатили?» Вместо этого привязывайте цену к текущим альтернативам:

• «Что вы используете сегодня и во сколько это вам обходится (инструменты, труд, задержки)?»
• «Если мы устраним эту проблему, из какого бюджета это будет оплачиваться?»
• «Вы бы заменили X на $Y/месяц или добавили это как новую статью расходов?»

Определите метрику успеха до теста

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

Проектируйте MVP, который быстро снимает боль

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

Определите «минимальный облегчающий результат»

Напишите исход в простом языке:

• «После использования этого клиент больше не должен…» или
• «Это сокращает время/стоимость/риск X на…»

Держите его измеримым и немедленным.

Примеры:

• «Делать ежемесячный отчёт за 30 минут вместо 4 часов.»
• «Перестать пропускать фоллоу-апы с лидами на следующие 14 дней.»
• «Снизить запросы на возврат на 20% за эту неделю.»

Этот результат становится целью MVP. Всё остальное — опционально.

Приоритизируйте скорость облегчения, а не список фич

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

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

Используйте ручные шаги намеренно

Чтобы учиться быстрее, заменяйте ПО людьми, где нужно:

• консьерж-онбординг (вы настраиваете за них)
• совместная реализация (done-with-you)
• ручная очистка или импорт данных
• сервисный рабочий процесс за простой формой

Ручная работа — не провал; это способ выяснить, что нужно автоматизировать позже.

Стройте ровно столько, чтобы протестировать workflow

Когда важна скорость, используйте инструменты, позволяющие прототипировать workflow и итератировать за дни, а не недели. Например, платформа для быстрого кодинга вроде Koder.ai может быть полезна: вы описываете workflow в чате, генерируете рабочее веб-приложение (часто React на фронте и Go + PostgreSQL на бэкенде под капотом) и затем дорабатываете по мере обучения из пилотов. Если тест сработал — вы экспортируете исходники и продолжаете разработку; если нет — затраты минимальны.

Фичи вроде planning mode, snapshots и rollback помогают проводить контролируемые MVP-эксперименты, не превращая каждое изменение в рискованную перестройку.

Ясно опишите, чем MVP не является

Запишите и покажите ранним клиентам:

• не полноценный продукт
• ещё не масштабируем
• не оптимизирован для всех типов клиентов

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

Позиционирование: опишите боль и результат

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

Начните с однострочного позиционирования

Используйте простую структуру и держите её конкретной:

«Для X, у кого есть проблема Y, мы даём результат Z.»

Примеры:

• «Для менеджеров клиник, которые страдают от неявок и хаоса в расписании, мы даём предсказуемый календарь и меньше пустых слотов.»
• «Для sales ops, которые борются с грязными данными в CRM, мы даём еженедельные авто-фиксы, которые держат воронку в порядке.»

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

Превратите боль в измеримые выгоды

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

• «Сократите время на X с 6 часов/нед до 1 часа/нед.»
• «Уменьшите возвраты на 30%.»
• «Согласования за 2 дня вместо 2 недель.»

Если вы ещё не можете измерить — выберите прокси («меньше перерывов», «один источник правды», «срочная обработка») и уточните после реального использования.

Используйте формулировки клиентов в копирайте и демо

Лучший копирайт часто — прямая цитата из discovery-звонков. Держите swipe-файл точных фраз клиентов («я постоянно гоняюсь за…», «мы слепы до конца месяца…»).

Зеркальте эти слова:

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

Готовьте ответы на возражения на основе реальных альтернатив

Возражения обычно — сравнение с тем, что они уже делают. Перечислите настоящие альтернативы (таблицы, общий инструмент, агентство, «ничего не делать») и отвечайте прямо:

• «Почему не таблицы?» → «Потому что стоимость — пропущенные фоллоу-апы и непоследовательные данные. Мы автоматизируем проверки и сохраняем аудит.»
• «Почему не [большой инструмент]?» → «Вам нужна только часть, которая решает этот узкий узел. Настройка — 30 минут, а не 3 месяца.»

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

Ранний go-to-market: продавайте, чтобы учиться

Ранний выход на рынок — не growth-hack. Это миссия по установлению правды. Ваша цель — подтвердить (или опровергнуть), что боль реальна, часта и достаточно дорога, чтобы люди изменили поведение и заплатили за облегчение.

Выберите один простой канал первым

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

• Прямой аутрич: 30–50 очень таргетированных сообщений людям, соответствующим клиенту и контексту.
• Сообщества: нишевые Slack, LinkedIn-группы, форумы, профильные митапы.
• Партнёры: агентства, консалтанты или инструменты, которые уже обслуживают ваших покупателей (предлагайте рефераль или совместные продажи).

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

Продажи сейчас = обучение, а не масштаб

Относитесь к каждому питчу как к интервью с ценником. Вы проверяете:

• это «хотят исправить» или «надо исправить сейчас»?
• что они уже делают, чтобы справляться (таблицы, найм, ручные обходы)?
• что вызывает срочность (сроки, соответствие, потеря дохода, отток)?
• какой результат им действительно нужен (экономия времени, меньше ошибок, быстрее согласования)?

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

Отслеживайте простую воронку (и улучшайте её)

Держите всё просто и измеримо:

• Разговоры (квалифицированные звонки)
• Тесты/пилоты (реальное использование)
• Платные конверсии (хоть небольшие суммы)

Смотрите, где утекают лиды. Если звонки конвертятся в пилоты, но пилоты не платят — возможно, ваш MVP не даёт облегчения быстро или вы продаёте не тому покупателю.

Собирать «нет» — как золото

Каждое «нет» должно давать причину. Захватывайте её дословно и тегируйте (тайминг, цена, доверие, отсутствие фичи, неправильная персона, неясная ценность). Затем возвращайте это в:

• позиционирование («для X, кто борется с Y…»)
• объём MVP (уберите отвлекающие вещи, добавьте одно, что блокирует платёж)
• таргетирование (сузьте сегмент, который быстрее говорит «да»)

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

Метрики, которые доказывают, что вы решаете болезненную проблему

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

Начните с лидирующих индикаторов (до дохода)

Ранние сигналы — это признаки, что продукт даёт быстрое облегчение:

• Активация: момент, когда новый пользователь достигает первого значимого результата (не просто «создал аккаунт»). Чётко определите: «отправил первый счёт и получил оплату» или «разрешил первый тикет».
• Повторное использование: возвращаются ли они выполнять задачу снова в естественном цикле (день/неделя/месяц)?
• Time-to-value (TTV): сколько времени от регистрации до первого результата. Меньший TTV обычно значит более острая боль и лучшее онбординг-опыт.

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

Удержание и расширение: тест боли

Удержание — самое яркое доказательство, что проблема постоянна.

Отслеживайте retention по когортам (неделя 1 → неделя 4, месяц 1 → месяц 3) и сопоставляйте с сигналами расширения:

• добавление мест/учётных записей
• более глубокое использование (больше проектов, рабочих потоков)
• апгрейды на платные планы

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

Раннее «вежливое использование» — распознайте его

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

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

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

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

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

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

Используйте ответы, чтобы уточнить ICP и сузить problem statement. Если отток случайный и причины расплывчатые — вероятно, вы ещё не привязались к конкретной болезненной проблеме.

Когда пивотить, сужать или уходить

Большинство ранних «провалов» стартапов случается не из‑за плохого продукта, а из‑за того, что боль недостаточно сильна или вы решаете её не для того покупателя. Цель — быстро учиться и принимать чистое решение.

Сигналы, что стоит пивотнуть

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

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

Если эти паттерны повторяются в разных разговорах — вы, вероятно, не находитесь на болезненной проблеме, по крайней мере в той форме, в которой вы её описали.

Пивот аудитории vs. пивот решения

Есть два разных хода:

• Пивот аудитории, когда боль реальна, но только для более узкой группы (например, проблема остра для тимлидов, а не для отдельного сотрудника).
• Пивот решения, когда покупатель и боль верны, но ваш подход не даёт быстрого облегчения (неправильный workflow, интеграция или упаковка).

Не меняйте и то, и другое сразу — иначе вы не поймёте, что именно дало эффект.

Сохраняйте то, что сработало — и ставьте временные рамки на остальное

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

Задайте правило с временным лимитом, чтобы избежать вечной полировки: например, «за следующие 3 недели проведём 15 discovery-звонков и попробуем закрыть 3 платных пилота. Если мы не найдём владельца бюджета и повторяемого триггера срочности — уходим.»

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