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

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

После этого обычно выбирают один из двух путей. Одни решают, что ChatGPT и Claude годятся разве что для написания черновиков и досужих развлечений. Другие начинают искать некий «правильный промпт»: покупают книгу с заголовком вроде «580 промптов для ChatGPT», сохраняют пост «50 запросов, которые заменят маркетолога», тащат в закладки GitHub-репозиторий с тысячей шаблонов или подписываются на Telegram-канал, где каждое утро публикуют очередной «промпт, о котором вам больше нигде не расскажут».

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

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

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

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

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

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

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

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

У сильного промпта четыре слоя:

• Контекст — что происходит на самом деле
• Метаконтекст — через какую оптику смотреть на ситуацию
• Интенция — зачем нужен результат и что он должен изменить
• Формат — как модели подойти к задаче, прежде чем выдавать ответ

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

Разберём на одном примере.

Контекст: что происходит на самом деле

Самая частая ошибка — считать существенные детали «и так понятными».

Представьте, что вам говорят: «Нужно разгрузить автомобиль». Работа понятная. Через минуту уточняют: это не легковая машина, а грузовик. Затем: грузовик забит бетонными блоками. Затем: он застрял в болоте. И наконец: болото находится на Луне.

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

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

Было:

Напиши ответ клиенту, который отказался от сделки.

Стало:

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

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

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

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

Метаконтекст: через какую оптику смотреть

Контекст отвечает на вопрос «что случилось». Метаконтекст — на вопрос «через какую рамку это интерпретировать».

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

Один и тот же лес лесник, ботаник и художник опишут по-разному. Лесник увидит состояние древесины, просеки и пожарные риски. Ботаник — виды растений, почвы и связи в экосистеме. Художник — свет, композицию и цвет. Лес один, но вопросы к нему разные.

С отказавшимся клиентом происходит то же самое:

• Роль: «Посмотри на ситуацию как руководитель отдела продаж в B2B SaaS» — фокус на следующем шаге, риске потери сделки и тактике переговоров
• Модель: «Проанализируй ситуацию через воронку продаж» — фокус на этапе, где клиент выпал из процесса, и на проблемах демо или оффера
• Методология: «Используй принципы переговоров Фишера и Юри» — фокус на интересах сторон, а не на позиции «у вас дорого»
• Точка зрения клиента: «Посмотри на ситуацию глазами клиента» — фокус на том, почему прежние аргументы не сработали
• Экономическая оптика: «Оцени ситуацию с точки зрения совокупной стоимости владения и экономики внедрения» — разговор о цене лицензии превращается в разговор о затратах, потерях и окупаемости

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

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

Что спросить себя: чья экспертиза, какая теория или какая точка зрения сделает ответ действительно полезнее?

Интенция: чтобы что

Теперь самый неудобный вопрос: зачем вам вообще нужен этот ответ?

Не «что требуется сделать», а «что должно измениться после результата». Это и есть интенция.

С одним и тем же отказавшимся клиентом можно решать разные задачи:

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

Факты остаются теми же. Но меняются цель, логика ответа, тон и критерии качества.

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

Что спросить себя: «Чтобы что мне этот ответ?» А затем ещё раз: «Чтобы что мне это?» Второй вопрос часто отделяет формальный запрос от реальной потребности.

Например, «нужно письмо клиенту» может оказаться задачей «понять, можно ли ещё спасти сделку». А «нужно ревью кода» — задачей «не пропустить риски перед релизом». Исходный артефакт один, но задачи разные.

Формат: как оформить ответ

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

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

Несколько полезных конструкций:

• Несколько стратегий: «Предложи три стратегии ответа. Для каждой укажи преимущества, риски и условия, при которых она уместна»
• Premortem: «Представь, что этот ответ окончательно сорвал сделку. Почему это произошло? Перепиши письмо так, чтобы снизить эти риски»
• Адвокат дьявола: «Сформулируй сильнейшую позицию клиента против нашего предложения. Затем подготовь ответ, который не игнорирует эти возражения»
• Самокритика: «Подготовь черновик, затем оцени его глазами скептичного клиента и перепиши с учётом слабых мест»
• Сценарии: «Дай вариант для случая, если клиент готов к разговору; если уже выбрал конкурента; и если цена — только прикрытие для другого возражения»
• Несколько тональностей: «Подготовь жёсткую, нейтральную и мягкую версии. Кратко поясни, в какой ситуации выбрать каждую»

В этом и состоит значительная часть «изощрённых техник» из платных библиотек промптов. Их ценность не в экзотических названиях. Они не дают модели остановиться на первом гладком тексте.

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

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

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

Один запрос, четыре слоя

Вернёмся к исходной формулировке.

Запрос А:

Напиши ответ клиенту, который отказался от сделки.

Теперь — версия, в которой закрыты все четыре слоя.

Запрос Б:

Мы продаём B2B SaaS для автоматизации ручного процесса у клиентов среднего бизнеса. После демо клиент отказался от сделки, сославшись на цену. Три месяца назад ему уже предложили скидку 15%, поэтому дополнительную скидку сейчас не рассматриваем. По косвенным признакам клиент сравнивает нас с конкурентом. На демо команда клиента не увидела достаточно убедительной экономической выгоды от внедрения, хотя ручной процесс занимает несколько сотрудников и приводит к ошибкам.Посмотри на ситуацию одновременно как руководитель отдела продаж в B2B SaaS и как консультант по принципиальным переговорам. Отдельно оцени ситуацию глазами клиента: какие риски, сомнения или ожидания могут скрываться за формулировкой «слишком дорого»?Наша цель — вернуть клиента к предметному разговору без дополнительной скидки. Нужно сместить обсуждение с цены лицензии на стоимость текущего ручного процесса, риски бездействия и измеримый эффект от внедрения. При этом нельзя давить, спорить с возражением клиента или звучать как шаблонный продавец.Сначала предложи три стратегии следующего контакта. Для каждой укажи логику, риски, признаки того, что она уместна, и пример первого шага. Затем выбери оптимальную стратегию при имеющихся данных и объясни выбор.После этого подготовь короткое письмо клиенту: спокойное, уважительное, без канцелярита и агрессивного продавливания. Письмо должно приглашать к следующему разговору и содержать один конкретный вопрос, который поможет выяснить истинную причину отказа.В конце перечисли, каких данных не хватает для следующей итерации и как они могут изменить выбранную стратегию.

Разница между А и Б — не в количестве слов как таковом. Во втором запросе модель понимает, что происходит, через какую оптику рассматривать ситуацию, к какому результату прийти и каким путём работать.

Никакой магии. Просто задача перестала быть недосказанной.

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

Как уточнить свой промпт с помощью нейросети

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

Поэтому я собрал системный промпт-усилитель. Он берёт сырой запрос и превращает размытое «хочу вот это» в внятно поставленную задачу.

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

Дальше можно действовать как удобно:

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

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

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

А вот и сам системный промпт:

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

Когда мера становится целью, она перестаёт быть мерой

Это не я придумал — это закон Гудхарта, сформулированный ещё в 1970-х. Экономисты это давно поняли: как только показатель становится целью управления, он перестаёт отражать то, для измерения чего изначально создавался. Современный рынок найма воспроизводит этот эффект с неизменной точностью. Современный подходы в IT-найме требуют цифры как доказательство результата. Итог закономерен: мы получили ситуацию, когда специалисты в IT научились производить цифры — часто в ущерб самому результату.

Вот что происходит на практике.

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

Дизайнер стоит перед похожей развилкой. Можно потратить два месяца на пересборку информационной архитектуры — убрать лишние шаги в процессах, сделать продукт логичным, консистентным и предсказуемым. Это огромная работа. Результат почувствуют пользователи, но он не выразится в мгновенном изменении «до/после». А можно запустить серию A/B-тестов на кнопках и заголовках — и получить заветное «поднял конверсию шага на 12%». Рынок аплодирует второму. Первое же как-будто остаётся за кадром.

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

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

Два мира — два Шапиро

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

А теперь один вопрос: по статистике, от 80 до 90% IT-продуктов и стартапов проваливаются. Проекты закрываются, продукты не выходят в прод, компании банкротятся. Это нормальная, честная статистика, в которой высокая неопределённость — часть ДНК индустрии.

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

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

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

Что теряет бизнес?

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

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

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

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

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

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

Разбор по ролям: кто гневит старину Гудхарта

Разработчик

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

Всё это важно. Всё это тяжело. И всё это совершенно непродаваемо в строчке резюме.

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

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

UX/UI-дизайнер

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

Это тонкая, долгая работа. Когда она сделана хорошо, пользователь просто не замечает интерфейс — он просто пользуется продуктом без лишнего трения. Измерить это почти невозможно. Сравнить «было / стало» трудно, потому что хорошая информационная архитектура не создаёт всплесков удоволсьтвия. А показатели удовлетворения пользователей — не умею оценивать отдельно качество интерфейса и качество сервиса.

Поэтому дизайнер идёт туда, где есть быстрая и понятная цифра. A/B-тест кнопки: красная против зелёной, большая против маленькой, «Купить» против «Положить в корзину». Тест даст результат за две недели, и этот результат можно представить в виде подтвержденных достижений. Иногда в ход идут агрессивные приемчики — навязчивые поп-апы, тёмные паттерны. Они краткосрочно поднимают конверсию. В долгосрочной перспективе разрушают доверие к продукту. Но в резюме остаётся только подтвержденная конверсия, а долгосрочный эффект упущен.

Самое горькое: дизайнер, который несколько месяцев перестраивал логику продукта и сделал его действительно понятным, выглядит в резюме слабее того, кто провёл тридцать A/B-тестов подряд. Рынок не различает качество вмешательства — он ориентирован на количество измеримых изменений.

Продакт-менеджер

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

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

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

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

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

Аналитик данных

Настоящая аналитика — это часто неудобный разговор. «Ребята, наши данные грязные, мы не можем доверять этим выводам». «Этот A/B-тест был настроен неправильно, результаты невалидны». «Метрика, на которую мы ориентируемся уже два года, не отражает реальное поведение пользователей».

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

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

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

QA-инженер

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

Поэтому QA учится считать. Количество заведённых багов, объём тест-кейсов, процент покрытия кода автотестами. Если KPI завязан на эти цифры — поведение меняется немедленно: баги дробятся на несколько карточек, тест-кейсы пишутся на очевидные сценарии, автотесты покрывают простые пути, а не критические края.

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

Тимлид и руководитель

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

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

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

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

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

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

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

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

Чтобы сравнивать между собой десятки идей, команды используют разные методы. Один из самых популярных — RICE: он предлагает оценивать задачу по четырем параметрам — скольких пользователей она затронет (Reach), насколько сильно повлияет (Impact), насколько команда уверена в этой оценке (Confidence) и сколько ресурсов потребуется на реализацию (Effort). Затем все это собирается в одну формулу, после чего появляется число, которое выглядит как вердикт, вынесенный самой вселенской объективностью.

И вот здесь начинается самое интересное.

С Reach и Effort еще можно как-то жить. Охват иногда можно прикинуть по аналитике, а трудозатраты — по опыту команды и похожим задачам. Но дальше в комнату вползает какая-то метафизика.

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

А потом появляется Confidence — и ситуация становится почти комической. Официальные описания RICE предлагают присваивать уверенности проценты вроде 100%, 80% или 50% в зависимости от того, насколько команда верит в свои оценки. Но проблема в том, что «степень веры» не существует как реальный измеряемый показатель: нет прибора, который покажет, что ваша уверенность сегодня ровно 80%, а не 63% и не «после обеда упала до 40%».

То есть что происходит на практике? Сначала команда выдумывает численное значение будущего эффекта. Потом выдумывает численное значение своей уверенности в этом выдуманном эффекте. А потом перемножает одно с другим так, будто речь идет о физических величинах, полученных в лаборатории, а не о коллективной фантазии, оформленной в Google Sheets.

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

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

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

Но и это еще не все. Даже если закрыть глаза на странную природу Confidence, остается вторая проблема: сам человек (причем как конкретный ответственный руководитель продукта, так и целые коллективы и продуктовые команды) очень плохо обращается с неопределенностью. И здесь полезно сослаться не просто на «какого-то Канемана», а на Даниэля Канемана — психолога, одного из главных исследователей принятия решений в условиях неопределенности, нобелевского лауреата по экономике за работы о систематических ошибках человеческого мышления. Его исследования и вся поведенческая экономика выросли из простой, но неприятной идеи: люди ошибаются. И делают это не случайно, а вполне предсказуемо.

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

Первый — WYSIATI, то есть «what you see is all there is», по-русски примерно «что видим, с тем мы и работаем». Канеман описывал его так: человек строит суждение на основе доступной информации и почти не учитывает критически важные пробелы в знании. Мы берем то, что легко складывается в понятную историю, и ведем себя так, будто этой истории уже достаточно для принятия решений.

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

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

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

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

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

Классический пример — техдолг и качество взаимодействия. Добавить еще одну фичу почти всегда проще продать, чем переписать хрупкую архитектуру, убрать визуальный шум, унифицировать интерфейсы или навести порядок в дизайн-системе. У фичи есть понятный релиз, понятный PR внутри компании и шанс быстро показать красивую цифру. У качества и технического фундамента эффект размазан, отсрочен и часто выражается не ростом чего-то, а предотвращением деградации. А предотвращенную катастрофу, как известно, очень трудно презентовать на слайде с заголовком «Q3 wins».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Классы

На большом карьерном треке у каждого сотрудника есть право на самоопределение. Работа в команде, в компании и в проекте — это возможность явно (или не очень) ответить на главный вопрос — «Кто я такой?». Не просто профессионал — а какой именно профессионал, с какими особенностями и подходами, в чем его отличие от множества других сотрудников.

В D&D есть подобная идея. Классы (как и профессии) — это фундамент жизни персонажа: воин, маг, плут, жрец. Путь развития каждого влияет на все поступки, решения и мировоззрение. Но и это лишь вершина айсберга. А самое интересное открывается дальше.

Внутри каждого класса (класс=профессия) есть субклассы — конкретные пути развития в рамках выбранного профессионального пути. А на пересечении классов и субклассов в D&D рождаются совершенно уникальные комбинации: например, жрец домена Бури, который одновременно является чародеем Дикой магии.

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

Про дизайнеров я уже рассказывал: там у меня сложилась классификация на SX, CX, LX и NX. Но субклассы есть в любой профессии — просто их не всегда называют вслух. Среди бэкендеров одни — «архитекторы», думающие схемами и контрактами; другие — «оптимизаторы», живущие в графиках нагрузки и профайлерах; третьи — «продуктовые», для которых код это просто способ доставить фичу пользователю. Среди QA — «процессники», выстраивающие методологию тестирования, и «охотники за багами», у которых чутьё на слабые места системы. Среди фронтендеров — «компонентщики», «аниматоры», «интеграторы». Эти классы редко описаны в HR-документах, но они есть. И ваша задача как Мастера игры — нащупать их в своей партии. Если в ваших корпоративных документах нигде не описано такое тонкое различение путей в рамках одной профессии — то, видимо, вам придётся составить такую классификацию самому.

Что это даёт?

Во-первых, понимание, что люди ограниченно взаимозаменяемы. Два senior-бэкендера с одинаковым грейдом — не одно и то же. Субкласс еще как влияет! Бэкендер-архитектор спроектирует красивую систему, но будет неделями тащить простую CRUD-задачу. Продуктовый бэкендер закроет её за день, но в архитектурную дискуссию принесёт только сумятицу. Поменять их местами — значит сломать оба проекта.

Во-вторых, понимание, кого куда ставить, кого где искать, развивать и корректировать. Не «нужен ещё один разработчик», а «нужен бекендер-оптимизатор, потому что у нас деградирует производительность».

В-третьих, понимание сильных сторон и слепых зон. У каждой профессии и субкласса есть и то, и другое — и это не баг, а свойство выбранного пути.

Чистые субклассы vs мультиклассы

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

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

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

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

Специфические навыки

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

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

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

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

Две ловушки для Мастера игры

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

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

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

Грейды

Грейды так плотно вошли в нашу жизнь, что объяснять их не нужно: Junior, Middle, Senior, Lead — эта лесенка есть в любой IT-компании. Но большинство компаний совершает одну и ту же ошибку: привязывает грейд к профессии, а не к субклассу внутри профессии.

Из-за этого случаются забавные истории. Senior-бэкендер не может закрыть задачу, на которой буксует middle, — потому что middle архитектор по классу, а senior всю жизнь писал продуктовый код. Senior-продакт из delivery не справляется с discovery-задачей, которую middle закрыл бы за неделю. Senior-QA не справляется с нагрузочным тестированием, хотя его middle-коллега делает это с закрытыми глазами. Senior системный аналитик с опытом интеграций тонет в задаче по сбору бизнес-требований, которую middle с заказчиками решил бы за пару встреч. Формально все «сеньоры». Фактически — разные люди с разными навыками, которых грейд сравнял в одну категорию. Получается забавная история — в обычной корпоративной системе грейды скорее путают управленцев, чем помогают им ориентироваться в способностях и навыках конкретных специалистов.

В D&D все логичнее: уровень всегда привязан к классу и подклассу. Жрец Домена Жизни 5 уровня и жрец Домена Войны 5 уровня — оба «пятёрки», оба жрецы, но один в бою лечит партию, а второй сам встаёт в первый ряд и машет молотом. Никому не придёт в голову поменять их местами в сложной схватке. А в IT мы регулярно ставим знак равенства между сеньорами разных субклассов внутри одной профессии. И удивляемся позже на post-mortem анализе: а где же я ошибся?

Как правильно

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

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

Что это даёт руководителю

• Честные ожидания. Когда вы зовёте senior-продакта из delivery, вы заранее знаете, что discovery — не его сильная сторона, и не ставите её ему как KPI.
• Прозрачное развитие. Сотрудник видит, какие конкретно навыки нужно прокачать до следующего грейда. Не «стань сеньором», а «вырасти вот здесь и здесь».
• Адекватный найм. Вы ищете не «middle-разработчика», а «middle-разработчика-оптимизатора» — и понимаете, что именно проверять на интервью.
• Меньше политики. Грейд перестаёт быть результатом харизмы или выслуги лет.

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

Перки

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

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

В D&D это что-то вроде проклятого артефакта или дикой магии: меч, который наносит тройной урон, но раз в день случайно бьёт владельца; чародей, способный одним заклинанием перевернуть бой, но рискующий вызвать магический хаос. Сила и слабость связаны намертво. Хочешь силу — мирись с побочными эффектами.

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

Перки встречаются в любой роли. Разработчик, который продуктивен только ночью, и за ночь делает то, на что команда тратит неделю. Системный аналитик, который не выносит совещаний, но в одиночку расписывает интеграции, по которым месяцами идут согласования. Продакт, игнорирующий любые фреймворки, но с редким чутьём на продукт — там, где остальные строят гипотезы, он сразу видит ответ. QA-параноик, тормозящий все релизы, но не пропускающий критичные баги в продакшен.

Перк — это не косяк

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

Социальная проблема перков

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

У этого вопроса нет идеального ответа. Поэтому хороший Мастер игры с самого начала старается изолировать рабочий контур носителя перка от общего: ставить его на задачи, где перк раскрывается, и оберегать от задач, где перк превращается в проблему. Не прятать его от команды — но и не сталкивать с ней в режимах, где конфликт неизбежен. Это требует тонкой работы с распределением задач и постоянного объяснения коллективу, за счёт чего именно этот сотрудник получает свои поблажки.

Что важно держать в голове руководителю

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

Перки — это не недостаток системы, а её часть. Просто с этой частью нужно играть осознанно.

Квента (личная история)

В D&D квента — это предыстория персонажа: где родился, кем были родители, через что прошёл, как получил свой первый шрам и почему ненавидит гоблинов. Без квенты герой — это просто набор циферок: 14 силы, 12 ловкости, владение длинным мечом. С квентой он становится живым: понятно, что им движет, чего он боится, на какие квесты он откликнется, а от каких откажется.

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

Что это даёт руководителю

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

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

Где граница

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

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

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

Главный вывод

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

Фракции

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

В D&D фракции — это гильдии, ордена и тайные общества: Арфисты, Зентарим, Альянс Лордов. Персонаж может быть членом партии и одновременно — членом фракции, у которой свои цели, ресурсы и обязательства. Иногда интересы партии и фракции совпадают. Иногда — расходятся. И тогда персонаж оказывается в положении выбора.

Спектр фракций

Фракции бывают очень разные — от «несерьёзных» до тех, что реально определяют ход проекта.

• Бытовые и неформальные. Те, кто ходит вместе на обед. Те, кто обсуждает аниме в отдельном чате. Курящие. Бегуны. Родители маленьких детей.
• Профессиональные сообщества по интересам. Внутренний клуб фронтендеров, чат системных аналитиков, гильдия дизайнеров — люди одной специальности, которые обмениваются практиками поверх формальной структуры команд.
• Идеологические. Сторонники конкретного подхода: «за чистый Agile», «за монолит», «за дизайн-систему любой ценой», «за тесты сначала».
• Формальные органы влияния. Архитектурный комитет, продуктовый совет, дизайн-ревью. Это уже фракции с реальной властью: они принимают решения, которые потом исполняет вся команда.
• Альянсы по проектам. Те, кто три квартала тащил один тяжёлый проект и теперь связан общим опытом сильнее, чем штатным расписанием.

Любая из этих фракций может оказаться важнее формальной иерархии в конкретной ситуации.

Жизнь внутри фракций

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

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

Слепое пятно удалёнки

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

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

Что с этим делать

• Знать карту. Минимальная задача — понимать, какие фракции существуют в вашей команде и кто в каких состоит. Это не паранойя, это базовая управленческая навигация.
• Не пытаться разрушать неформальные фракции. Они возникают сами и нужны людям. Бороться с ними — значит бороться с человеческой природой и проигрывать.
• Работать с формальными фракциями как с центрами силы. Если архитектурный комитет принимает важные решения — он должен быть согласован с продуктовыми целями, а не жить отдельной жизнью.
• На удалёнке — создавать поводы. Неформальные созвоны, виртуальные кофе, открытые каналы. Не чтобы шпионить, а чтобы оставаться в курсе того, чем дышит команда.

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

Ачивки

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

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

Из этого следует неожиданный вывод:

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

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

Ачивки — это ориентиры, а не поглаживания

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

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

«Мы знаем, через что вы проходите»

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

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

D&D-параллель

В хороших настольных играх Мастер выдаёт опыт не за «зачищенное подземелье», а за достижение значимых сюжетных вех. Это называется milestone leveling, и оно работает лучше, чем формальный подсчёт убитых монстров: игроки начинают целиться в сюжет, а не в фарминг. То же и в команде: ачивки за вехи и поведение, а не за активность и метрики ради метрик.

И ещё: в D&D у каждой ачивки есть имя. «Убийца дракона», «Спаситель деревни», «Дипломат фракций». Это не «опыт +500», это история, которая становится частью персонажа. В IT-команде это работает так же: ачивка должна иметь имя, чтобы стать частью профессиональной квенты сотрудника, а не строчкой в HR-системе.

Чего делать не надо

• Не выдавать ачивки автоматически по KPI. Это превращает их в зарплату.
• Не выдавать всем поровну, чтобы «никого не обидеть». Это убивает сигнал.
• Не выдавать за то, чего сами не цените. Команда быстро это считывает.
• Не превращать ачивки в единственный язык признания. Они работают только в системе из one-to-one, обратной связи и нормального человеческого внимания.

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

Вместо итога

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

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

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

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

1. Универсальных правил дизайна не существует — но аудитор делает вид, что они есть

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

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

Банальный пример — размер шрифта. Многие чек-листы требуют: «Все надписи не меньше 14pt, иначе пользователям неудобно читать». Звучит разумно. Но разваливается при первом же практическом рассмотрении.

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

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

2. Аудитор всегда выдаёт среднюю оценку — а не честную

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

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

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

3. Исправил одно — сломал другое. И так по кругу

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

Лучше на примере. UX-аудитор проверял интерфейс доставки суши и роллов. Первое замечание: «Где граммовка? Пользователь не понимает размер порции — значит, вы что-то скрываете, доверие падает».

Логично. Добавили граммовку к каждой позиции. Показали второму аудитору. Новое замечание: «Зачем вы цифры в заголовок вставили? Теперь половина заголовков на странице — малозначимые граммы. Цифры в названии отвлекают внимание, сделайте отдельное поле в карточке».

Ладно. Переделали — вынесли граммовку в отдельное поле. Показали третьему аудитору. Новое замечание: «Из-за дополнительного поля карточки стали выше, на экране теперь помещается меньше позиций». И тут же: «Вы вообще видели хоть одного пользователя, который понимает, 30 г суши — это много или мало? Это большой кусок или маленький? Для 99% людей эта цифра ни о чём не говорит. Вы потратили ценное экранное место на абсолютно бесполезную информацию».

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

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

4. Аудитор верит в здравый смысл. Пользователи — нет

«Сделать логичнее» и «сделать удобнее» — это не одно и то же. Это вообще про разные вещи.

Расскажу один реальный случай. Начало 2010-х. Онлайн-оплата ещё была в новинку — многие пользователи боялись вводить номер карты в интернете и предпочитали платить наличными при получении. Нам было важно увеличить долю онлайн-платежей. Логика простая: пользователь боится — дай ему гарантию безопасности. Добавили на страницу значок: «Платежи защищены, сторонняя платёжная система гарантирует безопасность».

Итог: доля онлайн-оплат значительно упала.

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

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

5. Аудитор придирается к тому, к чему можно придраться — а не к тому, что реально важно

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

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

В типичном отчёте UX-аудитора все пункты перечислены в примерно одинаковом формате: «Здесь кнопка неудачно расположена», «Здесь шрифт мелковат», «Здесь иконка непонятна». Никакого разграничения по степени влияния на бизнес-результат. А ведь именно это разграничение — самое ценное знание. Потому что ресурсы ограничены, и команда всегда стоит перед выбором: что чинить в первую очередь.

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

6. Аудитор не может смотреть на интерфейс глазами вашей аудитории — особенно если она специфична

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

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

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

7. Аудитор видит то, что есть на экране. Но не видит того, чего там не хватает

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

Ошибки бывают двух видов: ошибки реализации (что-то сделано неправильно) и ошибки концепции (чего-то важного нет вообще). Аудитор хорошо видит первые и почти всегда пропускает вторые — потому что несуществующее невозможно заметить при визуальном осмотре.

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

Семь грехов названы. Но было бы нечестно остановиться только на критике.

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

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

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

Термин «UX/UI-дизайнер» давно превратился в профессиональный монолит — удобный, но бессодержательный. За ним скрываются минимум четыре принципиально разных способа мыслить и работать. Эту классификацию можно использовать двояко: как описание отдельных ролей в команде — или как внутренние векторы, которые в разной пропорции присутствуют в каждом специалисте.

Четыре вектора:

• SX (system experience) — систематизатор: думает атомами, компонентами и правилами сборки
• CX (customer experience) — исследователь: думает потребностями, сценариями и путями пользователя
• LX (layout experience) — композитор: думает пространством, визуальным языком и эстетикой экрана
• NX (narrative experience) — нарратор: думает идеями, образами, метафорами и впечатлениями

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

SX-дизайнер

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

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

Внешний конфликт
С LX-дизайнером — тот хочет сделать красиво и нестандартно, а SX говорит: «в этом нет никакой системы». Конфликт регулярный и почти неизбежный: один видит исключение как творческую свободу, другой — как технический долг. С разработкой — она хочет быстро и просто, он хочет правильно и масштабируемо: «нельзя просто захардкодить, нужно вынести в переменную». С руководством — оно не понимает, зачем тратить спринт на «какие-то компоненты», если можно просто нарисовать экран и отдать в разработку. Объяснить ценность системы человеку, который мыслит фичами и дедлайнами — отдельное искусство, которым SX-дизайнер владеет редко.

CX-дизайнер

Слепые зоны
Так глубоко погружён в потребности пользователя, что регулярно теряет из виду бизнес-ограничения и техническую реализуемость. Может принести «идеальное решение» после трёх недель исследований — и оно будет действительно идеальным для пользователя, но абсолютно нереализуемым в существующей архитектуре и за разумный бюджет. Другая слепая зона — визуальное мышление: CX-дизайнер часто недооценивает роль формы. Ему кажется, что если сценарий правильный — остальное детали. Но пользователь воспринимает не сценарий, а экран. Наконец, склонность к бесконечному исследованию — это не только достоинство, но и ловушка. Исследование становится способом отложить ответственность за решение: пока есть вопросы — не нужно отвечать.

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

Внешний конфликт
С NX-дизайнером — тот предлагает смелые, неочевидные идеи, CX отвечает: «это не подтверждено исследованиями, мы не знаем, как на это отреагируют пользователи». Это конфликт доказательства и интуиции, и он особенно разрушителен, когда оба правы. С руководством — оно хочет результат сейчас, а CX говорит: «нам нужно ещё одно интервью, ещё один раунд тестирования». Руководство воспринимает это как нерешительность, CX — как профессиональную ответственность. С SX — системщик проектирует то, что есть, а CX постоянно ставит под сомнение саму модель: «а правильную ли задачу мы вообще решаем?» Это ценный вопрос — но заданный в пятый раз на середине спринта, он разрушает всё.

LX-дизайнер

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

Внутренний конфликт
Между красотой и функцией. Хочет сделать так, чтобы было красиво — но интерфейс должен работать, а не висеть в галерее. Постоянный выбор: пожертвовать гармонией ради читаемости или читаемостью ради гармонии. Это не абстрактная дилемма — это конкретные решения каждый день: размер шрифта, контраст, плотность информации. Глубже — конфликт между личным вкусом и объективными требованиями. LX-дизайнер развивает вкус годами, и он становится его профессиональным инструментом — но вкус субъективен, а интерфейс должен работать для всех. Момент, когда личная эстетика начинает доминировать над задачей, — это момент, когда LX-дизайнер становится опасен для проекта.

Внешний конфликт
С SX — тот режет всё, что выбивается из системы, и не понимает, зачем нужно исключение ради «красоты». Это один из самых частых и изматывающих конфликтов в дизайн-команде: оба технически правы, но говорят на разных языках. С CX — тот регулярно напоминает, что пользователи не замечают красоту, зато сразу замечают непонятность, и предлагает упростить то, над чем LX работал неделю. С руководством — оно не видит разницы между «сделано» и «сделано хорошо», искренне не понимает, зачем переделывать то, что «и так работает», и воспринимает перфекционизм LX-дизайнера как неэффективность.

NX-дизайнер

Слепые зоны
Живёт в пространстве идей — и именно поэтому плохо ориентируется в ограничениях. Может предложить концепцию, от которой захватывает дух, но которую невозможно реализовать ни в срок, ни в бюджет, ни в рамках существующей системы. Склонен недооценивать повторяющиеся «скучные» задачи — а именно они составляют 80% реального дизайна: онбординг, формы, таблицы, уведомления. NX-дизайнер хочет работать с кульминацией — но продукт состоит в основном из будней. Ещё одна слепая зона — измеримость: его работа плохо поддаётся метрикам. Как измерить силу метафоры или глубину впечатления? Это делает его вклад невидимым для тех, кто мыслит дашбордами и конверсией.

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

Внешний конфликт
С SX — система убивает нарратив: любая нестандартная идея разбивается о «у нас так не принято» и «это нарушает паттерн». С CX — исследования не оставляют места для неожиданного: «пользователи привыкли к стандартным паттернам, не нужно их удивлять». Это приговор для NX-дизайнера, потому что удивление — это и есть его работа. С LX — тот реализует идею технически грамотно, но не так, как она звучала в голове: форма правильная, но душа куда-то делась. С руководством — самый острый и регулярный конфликт: «это красиво, но что это даёт бизнесу?», «зачем нам платить за концепцию, которую никто не просил?». NX-дизайнер с трудом переводит ценность своей работы на язык бизнеса — и это системная проблема, а не личная.

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

В этом инженерном мире не было места для «царя горы» или единого национального лидера. Авторитет здесь измерялся вкладом в open-source, качеством кода и элегантностью решений сложных инженерных задач.

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

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

Физики и лирики цифровой эпохи

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

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

Поколение сирот на руинах ВНИИТЭ

Этот поиск лидера обострился до предела именно в России 90-х. С распадом СССР рухнула вся советская система дизайна — громоздкая, идеологизированная, но всё же система. Исчез ВНИИТЭ (Всесоюзный научно-исследовательский институт технической эстетики), закрылись всесильные худсоветы, которые десятилетиями выполняли роль верховных арбитров вкуса.​

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

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

Три роли для одного героя

К концу 90-х стало очевидно, что негласный конкурс на звание «дизайнера №1» — это кастинг на три ключевые социальные роли, которые пустовали:

1. Арбитр. В мире, где любой мог назвать себя дизайнером, нужен был кто-то с достаточно громким голосом и смелостью, чтобы публично вершить суд: отделять «хороший» дизайн от «плохого» и формировать хоть какие-то критерии качества.
2. Переводчик. Новому русскому бизнесу, который начал осваивать интернет, был необходим «переводчик с дизайнерского на человеческий» и наоборот. Тот, кто сможет объяснить на языке прибыли и эффективности, зачем тратить тысячи долларов на сайт, который еще вчера студент делал за бутылку пива.
3. Ролевая модель. Молодым специалистам, вошедшим в профессию без дипломов и ориентиров, нужен был живой пример. Доказательство того, что дизайн — это не только творчество, но и успешный бизнес, путь к признанию и благополучию.

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

Хронология стремительного взлета Артемия Лебедева и его Cтудии на заре Рунета (с 1995 по 2010 г.)

К моменту, когда Артемий Лебедев в 1995 году основал одну из первых в России студий веб-дизайна, у него за плечами уже было два провала. В 1992 году, в семнадцать лет, он вместе с партнером открыл студию «А-Квадрат» — графический дизайн, логотипы, полиграфия. Через год студия закрылась: рынок полиграфии был переполнен конкурентами, готовыми работать за копейки.

В 1993 году Лебедев решил попробовать себя в одиночку и основал студию «Артографика». Он столкнулся с типичной проблемой: клиенты хотели увидеть портфолио, а у него его не было. Тогда он придумал хитрый ход, основанный на принципе «Fake it till you make it». Лебедев создал папку с логотипами и фирменными стилями для несуществующих компаний и выдавал их за свои работы. Этот трюк помог ему получить первые заказы.

Параллельно Лебедев работал в журнале «Итоги» под руководством легенды советского графического дизайна Аркадия Троянкера. За свой первый серьезный проект — разработку стиля для «МакЦентра» — Артемий получил три тысячи долларов. В то время на эти деньги можно было купить четверть московской квартиры.

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

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

48 часов в сутки

В октябре 1995 года двадцатилетний Лебедев выучил HTML, запустил домашнюю страницу и объявил об открытии студии WebDesign. Офиса не было — работал на кухне родительской квартиры. Клиенты, если соглашались на встречу, приходили прямо домой. Штат студии, конечно же, состоял из одного Лебедева, который делал абсолютно всё: придумывал концепции, рисовал дизайн, писал HTML-код. Позже он вспоминал об этом периоде: «На это все у меня уходило 48 часов в сутки».

В октябре 1996 года появился Metro.ru — некоммерческий проект о московском метро. Черный фон, материалы о станциях метро, схемы, история. Чистый энтузиазм, никакой коммерции. Сайт стал одним из первых популярных тематических сайтов Рунета.

Первые крупные заказы пришли благодаря сотрудничеству с Антоном Носиком — идеологом и медиадиректором знаковых интернет-проектов того времени. Ключевым клиентом стал Cityline, один из первых и крупнейших провайдеров в стране, который через свое контент-агентство NetSkate активно финансировал создание сайтов. Для них студия Лебедева разработала целую серию проектов.​

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

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

1997 год оказался поворотным. Артемий разработал дизайн для поисковой системы Яндекс, которая была представлена публике 23 сентября. В нижней части страницы появилась знаменитая надпись, которая просуществует следующие восемнадцать лет: «дизайн — Студия Артемия Лебедева». Примерно в то же время продолжалось сотрудничество с Центральным банком России, начатое еще в 1996-м.

Лебедев параллельно проводил провакативные эксперименты с интернет-сообществом. Он создал виртуального персонажа — Катю Деткину, критика Рунета, публикующего язвительные обзоры сайтов. 4 марта 1997 года Катя «умерла», написав собственный некролог. Метапровокация произвела множество обсуждений среди пользователей интернета. Одновременно появился НЖМД — «Название Желающие Могут Додумать», коллекция фотографий абсурдного дизайна. Читатели присылали снимки уродливых вывесок и нелепых объектов городской среды, Лебедев отбирал и комментировал с сарказмом.

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

Переименование и эффект вездесущности

В 1998 году WebDesign официально переименовали в «Студию Артемия Лебедева». Это была ставка на персональный бренд. Клиент нанимал не безликую компанию, а того самого Лебедева, чье оформление он уже видел на других сайтах.

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

За следующие несколько лет клиентская база студии значительно выросла. Такие компании, как Xerox, Hewlett-Packard, General Motors, Nissan и Procter & Gamble, заказывали дизайн для своих российских представительств и локализацию. Этот факт стал важным сигналом для рынка: студия работает не только над локальными проектами, но и сотрудничает с крупным международным бизнесом.

1999 год стал ключевым. Одновременно на трех самых посещаемых порталах российского интернета появились копирайты студии: Яндекс, Lenta.ru, Gazeta.ru. Внизу каждого сайта была размещена активная ссылка: «Дизайн — Студия Артемия Лебедева».

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

К 2000 году в Студии Лебедева сложилась четкая структура: Лебедев отвечал за дизайн, Константин Моршнев — за технологии и программирование, а Денис Шохин — за менеджмент и финансовую сторону. На сайте студии появились первые публикации «Ководства» — фирменных заметок Артемия Лебедева, которые начались как серия онлайн-глав будущей книги. В них он в фирменной безапелляционной манере формулировал главные принципы своей работы: от правил типографики и проектирования интерфейсов до общей философии дизайна как решения практических задач, а не украшательства. То, что через несколько лет станет настольной книгой для нового поколения дизайнеров, начиналось как серия простых и понятных профессиональных советов.

Медийный монстр и делегирование

В 2001 году дизайнер Артемий Лебедев создал личный блог в ЖЖ под ником tema. Он писал о дизайне, путешествиях, политике и повседневной жизни, не стесняясь критиковать всех подряд. К середине 2000-х его блог вошел в топ-3 русскоязычного Живого Журнала, собрав более ста тысяч подписчиков.

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

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

Но главное событие случилось 22 ноября 2002 года. В этот день студия объявила о назначении трех арт-директоров: Романа Воронежского, Ильи Михайлова и Олега Пащенко. В пресс-релизе Лебедев объяснил решение с характерной иронией: «Пять лет назад я был единственным дизайнером в студии и сам рисовал все проекты от начала до конца — на это у меня уходило 48 часов в сутки. Сейчас у нас работает 20 дизайнеров. До сегодняшнего дня все нарисованное ими проходило через меня. Стало уходить уже 72 часа в сутки. Это перебор».

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

Монументальные проекты

Период с 2003 по 2007 год для Студии Артемия Лебедева был временем крупных корпоративных контрактов. «Альфа-Банк» заказал полный редизайн сайта, Samsung доверил локализацию для российского рынка, «Газпром» и Центральный банк стали постоянными клиентами. Портфолио студии превращалось в карту российской экономики.

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

1 сентября 2006 года запустился «Бизнес-линч» — один из самых обсуждаемых проектов студии. Формат был прост: читатели присылали свои работы, а Лебедев и арт-директора писали на них жесткие, порой зубоскальные, порой полезные рецензии. За 13 лет существования проекта сам Лебедев написал две тысячи семьдесят семь таких разборов. «Бизнес-линч» стал ежедневной открытой школой дизайна, которая на разборе реальных ошибок и удач сформировала вкус нового поколения.

Апогей империи

В 2008 году Лебедев стал представителем акционеров SUP Media — компании, владевшей «Живым Журналом». Из самого популярного блогера он превратился в одного из управленцев платформы, получив возможность влиять на её развитие.​

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

К 2010 году, на пятнадцатилетие студии, итоги выглядели внушительно. Двести пятьдесят Сотрудниок, более тысячи реализованных проектов и статус бессменного лидера в главном отраслевом рейтинге веб-студий Tagline с 2006 года. Клиентское портфолио читалось как список крупнейших компаний страны и мира: Яндекс, Газпром, Альфа-Банк, Центральный банк России, Samsung, Microsoft. Копирайты студии стояли на сотнях топовых сайтов Рунета, «Ководство» стало образовательным стандартом, а «Бизнес-линч» — ежедневной школой для тысяч дизайнеров.

Император по умолчанию: почему мы до сих пор живем в «эпохе Лебедева»

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

Эта безальтернативность кажется почти естественной, как закон природы. Но если налить себе бокал чего-нибудь задумчивого и отмотать пленку в туманную эпоху dial-up и ICQ, когда интернет еще пах свободой, возникает еретический вопрос: а был ли вообще выбор? Действительно ли трон «главного дизайнера всея Руси» был пуст и просто ждал своего предприимчивого узурпатора?

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

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

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

Так кто же были эти князья, которые добровольно (или по незнанию) отдали «великое княжение» этому дерзкому московскому узурпатору? Давайте совершим путешествие в прошлое и познакомимся с титанами, которые тоже имели все шансы стать номером один.

Дмитрий Кирсанов — интеллектуал и просветитель дизайнеров Рунета

В конце 1990-х, когда Лебедев строил свою империю, рядом с ним стоял другой титан, равный по влиянию, но совершенно иной по духу — Дмитрий Кирсанов.

Если в пантеоне русского веб-дизайна и был свой Моисей, то это, без сомнения, Дмитрий Кирсанов. Он вывел целое поколение растерянных дизайнеров из пустыни безграмотности. Его книга «Веб-дизайн», вышедшая в 1999 году, стала для многих дизайнеров того времени Скрижалями Завета. Это был не просто сборник советов «как сделать кнопку выпуклой», а первый в России фундаментальный труд, попытка осмыслить новую отрасль дизайна с помощью вечных законов гармонии, композиции и психологии восприятия.

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

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

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

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

Только сейчас, благодаря следам в социальных сетях, где Дмитрий никогда не был особенно активен, удалось восстановить его жизненный путь. Эти следы привели в канадский Галифакс. Оказалось, Кирсанов не умер (был и такой слух), он просто выбрал другой путь. Он переехал в другую страну и начал новую жизнь.

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

Кирсанов, который еще из России успешно работал с зарубежными компаниями, сделал осознанный выбор. Заработанные деньги и авторитет он инвестировал не в масштабирование бизнеса в России, а в личную свободу. Он переехал, чтобы писать новые книги на английском, открыл для себя мир IT-технологий не только со стороны дизайна, вносил свой вклад в open-source проекты, особенно в развитие графического редактора Inkscape, развивал другие личные проекты связанные с разработкой в большей степени, чем с дизайном. Он выбрал путь мастера-одиночки, работающего на весь мир из своего уединенного кабинета.

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

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

Вадим Игонин и мир корпоративного дизайна

На заре 2000-х, в эпоху дикого цифрового капитализма, у Лебедева был еще как минимум один равный по силе и влиянию соперник — Вадим Игонин, основатель и арт-директор легендарного агентства DEFA. История их негласного противостояния — это не просто борьба двух студий, а столкновение двух философий, двух кардинально разных путей к успеху. И то, почему победителем в гонке за звание «дизайнера №1» в итоге стал именно Лебедев, говорит о природе славы и бизнеса в России больше, чем любой рейтинг.

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

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

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

Лебедев сделал ставку на максимальный шум. Он понял, что в формирующемся медиапространстве важен не тот, кто лучше работает, а тот, кто громче об этом говорит. Скандалы, публичные нападки на конкурентов (включая обвинение DEFA в плагиате), нецензурная лексика — все это было топливом для его PR-машины. Он был ньюсмейкером, и каждое его действие, будь то создание логотипа или очередной пост в ЖЖ, становилось инфоповодом.​

Игонин же предпочитал тишину. Он был практически невидим в публичном поле. Его общение с миром сводилось к редким, сдержанным комментариям для отраслевых СМИ и выступлениям на закрытых профессиональных конференциях. Он не строил личный бренд и не вступал в публичные перепалки. Его репутация строилась не на словах, а на делах — на внушительном списке клиентов, среди которых были «Билайн», «Норильский никель», Procter & Gamble и Danone. DEFA была знаком качества, который не нуждался в громкой рекламе.

В профессиональной же среде DEFA и «Студия Лебедева» были абсолютно сопоставимыми величинами. В рейтингах они шли бок о бок, а многие эксперты считали, что с точки зрения чистого профессионализма и качества исполнения DEFA даже превосходила конкурента. Но в народном сознании победил Лебедев. Почему?

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

Антон Болотов и рождение дизайнера-предпринимателя

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

Родившись в 1976 году, он был почти ровесником Лебедева, но всегда избегал публичности. Его имя редко появлялось в СМИ, но его проекты говорили сами за себя. Болотов входит в число первопроходцев, которые формировали визуальный облик и технологическую основу ранних российских веб-проектов. В конце 1990-х — начале 2000-х годов, когда веб-дизайн в России был всё ещё дикой целиной, Болотов начал разрабатывать дизайн-ориентированные решения для интернет-проектов в своем бюро Болотов.ру.

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

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

Болотов же быстро разочаровался в клиентской работе. Хаотичный и непредсказуемый рынок заказной разработки конца 90-х, где приходилось «воевать» с клиентами, очень скоро перестал привлекать его. Вместо этого он сосредоточился на создании собственных успешных продуктов.​

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

Drive.ru и Drive2.ru: на заработанные от Rorer деньги Болотов создал свои медиа-проекты. Сначала — эстетское издание об автомобилях Drive.ru, а затем — крупнейшее в Рунете автомобильное сообщество Drive2.ru.​

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

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

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

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

Максим Орлов и его республика несогласных

Если Лебедев строил империю, то Максим Орлов и его агентство ONY методично возводили рядом с ней маленькую, но гордую и независимую республику. Это история не о попытке свергнуть тирана, но о создании жизнеспособной альтернативы в мире дизайна.

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

С другой стороны, такой радикализм по определению отрезал их от 90% рынка. Для большинства заказчиков их работы в 2000—2010 выглядели как «недоделанные», вызывая главный вопрос: «А где, собственно, дизайн?».

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

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

Призраки оперы: трагедия уходящей эпохи

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

Это пантеон титанов: Андрей Логвин и Владимир Чайка, гении плаката, чьи работы выставлялись в музеях мира; Сергей Шанович, демиург телевизионного дизайна, буквально создавший визуальный язык НТВ и ТНТ; Денис Башев и Эркен Кагаров, виртуозы айдентики, рисовавшие логотипы и знаки, которые мы видим каждый день, не зная их создателей, и множество других имен, известных впрочем только для специалистов креативных индустрий. В их мире дизайн был высоким искусством, почти религией.

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

Но главная трагедия «старой гвардии» была даже не в снобизме, а в аналоговой природе их работы. Автор плаката, логотипа или телезаставки анонимен для зрителя. Его имя растворено в продукте. Чтобы узнать, кто это сделал, нужно быть специалистом, читать отраслевые журналы. Лебедев же, благодаря простому копирайту в футере сайта, взломал этот код анонимности. Он нашел способ атрибутировать каждую свою работу, превратив ее в вечный рекламный двигатель. Это был инструмент, которого у «офлайн-магистров» просто не было.

Эти два мира — мир высокого дизайна и мир цифрового бизнеса — долгое время существовали параллельно, почти не замечая друг друга. Символичным актом, обозначившим конец этой эпохи, стал приход Эркена Кагарова, одного из столпов «старой гвардии», в студию Лебедева в 2013 году. Это было не просто кадровое решение. Это был своего рода акт признания.

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

Заключение

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

Он единственный из титанов своего времени увидел в хаотичном и нелепом Рунете 90-х не просто возможности, а новую арену для игры. Он осознал, принял и, возможно, даже сформировал правила этой «Игры престолов».:

1. Присутствуй везде. Пока другие концентрировались на узких задачах, он строил тотальную медийную империю.
2. Говори ясно. Когда другие использовали язык сложных дизайнерских терминов, Лебедев говорил на понятном каждому языке: немного провокационно, с вызовом, но и с ясными аргументами.
3. Будь автором. Важно подписывать свои работы и рассказывать о них. Объяснять их суть, общаться не только с профессионалами, но и с широкой аудиторией.

В эпоху когда можно было побороться за звание главного дизайнера России, каждый выбрал свою дорогу. Кирсанов покинул Россию и мир большого дизайна. Игонин выбрал закрытый мир корпоративной элиты. Болотов — создание собственных продуктов. Орлов — идеологическую борьбу на поле дизайна и свой стиль. «Старая гвардия» выбрала оставаться на своей понятной им территории. Все они добились колоссального успеха и признания, но в своих собственных «королевствах». Лебедев же оказался самым прагматичным и голодным до славы. Он не стал строить замок в отдельном княжестве. Он построил свою столицу на пересечении всех дорог, и со временем все дороги стали вести к нему.

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

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

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

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

К счастью, существует простой и эффективный фреймворк, который превращает неловкий разговор в конструктивный диалог. Это модель BOFF.

Глава 1. Анатомия BOFF: Разбираем модель по косточкам

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

B — Behavior (Поведение): Только факты

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

• Неправильно: «Ты опять пишешь грязный код и не думаешь о команде».
• Правильно: «Вчера ты залил в main коммит без описания и номера задачи в Jira».
• Неправильно: «Тебе, кажется, вообще плевать на безопасность проекта».
• Правильно: «При разработке нового модуля ты использовал библиотеку [название библиотеки] версии 1.2, которая помечена как устаревшая и имеет известную уязвимость».

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

O — Outcome (Результат): Конкретные последствия

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

• Кейс 1: «...из-за того что у коммита не было описания (Outcome), тестировщик не смог понять, что именно нужно проверять, и потратил час, чтобы найти тебя и выяснить контекст. Мы потеряли время всей команды».
• Кейс 2: «...использование этой уязвимой библиотеки (Outcome) блокирует нам прохождение аудита безопасности, из-за чего мы не можем выкатить релиз для ключевого клиента».

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

F — Feeling (Чувства): Человеческий фактор

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

Главное правило — говорить только о себе через «Я-сообщения».

• Неправильно: «Ты меня подводишь и заставляешь нервничать».
• Правильно: «Меня это нервирует, потому что мы могли бы делать все быстрее, но из-за таких вещей ползем, как черепахи».
• Правильно: «Я из-за этого постоянно нервничаю. Если мы провалим аудит безопасности, нас вообще заставят отчитываться перед директором».

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

F — Future (Будущее): Совместный поиск решения

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

• Неправильно: «Чтобы этого больше не было, ты должен всегда писать подробное описание к коммитам».
• Правильно: «Давай подумаем вместе, как мы можем исправить эту ситуацию, чтобы она не повторялась?».
• Правильно: «Что тебе могло бы помочь не забывать об этом в будущем? Может, нам стоит настроить pre-commit hook, который будет проверять наличие номера задачи?»

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

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

Глава 2. Почему BOFF — это стандарт, а не опция

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

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

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

• Ошибка №1: Разговор без B (Поведения) — «Личный наезд»Что это? Вы пропускаете конкретные факты и сразу переходите к оценкам, результатам или своим чувствам.
  Как звучит: «Меня бесит твоя невнимательность!» или «Из-за тебя у нас опять проблемы с релизом».
  Что происходит: Это худший вариант для начала разговора. Сотрудник не понимает, что именно он сделал не так, и воспринимает ваши слова как личное оскорбление. Вместо того чтобы анализировать проблему, он начинает защищаться, спорить или молча копить обиду. Диалог невозможен, вы получаете демотивированного и обиженного специалиста.
• Ошибка №2: Разговор без O (Результата) — «И что с того?»Что это? Вы указываете на конкретное действие, но не объясняете его последствий.
  Как звучит: «Ты снова оставил в макете дробные пиксели. Меня это раздражает».
  Что происходит: Сотрудник видит факт, но не понимает его значимости. Его внутренняя реакция: «И что? Какая разница? Зачем так нервничать из-за мелочей?» Без связки с реальным ущербом для проекта (поехавшая верстка, лишние баги, потраченное время) ваша обратная связь кажется необоснованной придиркой. Мотивации что-то менять не возникает.
• Ошибка №3: Разговор без F (Чувств) — «Отчет робота»Что это? Вы сухо излагаете факты и последствия, переходя сразу к поиску решения.
  Как звучит: «Ты не задокументировал эндпоинт. Из-за этого разработчик потратил лишний час. Что будем с этим делать?»
  Что происходит: Вроде бы все по делу, но звучит как формальная выписка из протокола. Отсутствие человеческой эмоции может быть воспринято двояко: либо проблема не так уж и важна для вас, либо вы просто формально исполняете роль «начальника». Это снижает вовлеченность и не создает ощущения общей ответственности.
• Ошибка №4: Разговор без F (Будущего) — «Рэнт-н-ран» (Rant and Run)Что это? Вы высказали все: и факты, и последствия, и свои чувства, но на этом и закончили.
  Как звучит: «Ты опять использовал уязвимую библиотеку! Из-за этого мы проваливаем аудит, и я в бешенстве!» — и после этого вы уходите.
  Что происходит: Это разговор в никуда. Вы выплеснули негатив и оставили сотрудника одного с чувством вины, стыда и полной неопределенности. Он получил критику, но не получил инструмента для исправления. Проблема не только не решается, но и усугубляется накопленным напряжением.

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

Глава 3. Практический воркшоп: от эксперимента до санкций

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

Шаг 1. «Домашняя работа»: подготовка к разговору

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

1. Соберите факты (Behavior). Не полагайтесь на память. Откройте Jira, Figma, GitHub. Найдите конкретные примеры: номер задачи, где не было обновлений; ссылка на коммит без описания; скриншот макета с дробными пикселями. Ваша цель — оперировать неоспоримыми данными.
2. Проанализируйте последствия (Outcome). Оцените реальный ущерб. Сколько часов разработки было потеряно? Сколько лишних багов завел QA-отдел? Как это повлияло на сроки релиза? Если можете, оцифруйте результат. «Мы потеряли полдня работы» звучит убедительнее, чем «это всех замедлило».
3. Определите цель и эмоции (Feeling & Future). Спросите себя: «Чего я хочу достичь этим разговором?» и «Что я на самом деле чувствую?». Цель — не выплеснуть раздражение, а решить проблему. Ваши эмоции — это сигнал о важности проблемы, а не повод для обвинений. Эта внутренняя калибровка поможет сохранить конструктивный тон.

Шаг 2. «Рукопожатие»: ратификация договоренностей

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

• Проговорите итог вслух. Используйте простые и четкие формулировки. Ваш авторский вариант отлично подходит: «Итак, подытожим — мы договорились, что ты будешь проверять макеты на дробные пиксели перед передачей в разработку».
• Используйте силу эксперимента. Чтобы снизить сопротивление и страх перед новым процессом, предложите попробовать его как тест. «В этот раз ради эксперимента мы сделаем следующим образом. Все согласны?». Эта фраза снимает давление и представляет изменение как временную меру, которую можно будет пересмотреть.
• Задокументируйте (опционально, но рекомендуется). Короткое сообщение в общем чате или комментарий в задаче: «По итогам нашего разговора договорились о...» Это не про бюрократию, а про создание «общей правды», к которой можно будет апеллировать.

Шаг 3. «Замыкая цикл»: контроль и эскалация

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

• Позитивное подкрепление — это обязательно! Если на следующей проверке вы видите, что сотрудник выполнил договоренность, — обязательно похвалите его. «Слушай, я посмотрел твои последние макеты — ни одного дробного пикселя. Отличная работа, спасибо, что отнесся к этому серьезно!» Это закрепляет желаемое поведение лучше любых наказаний.
• Если договоренность не выполнена. Это не катастрофа, а повод для второго, более глубокого разговора по BOFF. Невыполнение договоренности — это новое Поведение (B).«Иван, привет. На прошлой неделе мы договаривались, что ты будешь добавлять описание к коммитам (B). Я проверил последние три и увидел, что описаний по-прежнему нет (O). Я обеспокоен (F), потому что это говорит о том, что наша первая беседа не помогла решить проблему. Давай подумаем еще раз, что нам мешает и как это исправить (F)?»

Шаг 4. «Изменение правил»: когда слов недостаточно

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

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

• Пример 1 (мягкий контроль): «Раз у нас не получается не забывать об этом, давай попробуем по-другому. Теперь перед тем, как отдать задачу в тестирование, ты будешь звать меня на 5-минутное ревью, и мы будем проверять этот пункт вместе, за ручку».
• Пример 2 (автоматизация контроля): «Похоже, ручной контроль не работает. Я поставлю задачу бэкенду, чтобы мы добавили в наш CI/CD пайплайн шаг, который будет автоматически блокировать коммиты без номера задачи».
• Пример 3 (административные меры): В крайних, систематических случаях это может быть официальное предупреждение или перераспределение обязанностей («Хорошо, раз с этой частью работы возникают сложности, давай ты сосредоточишься на [другая задача], а этот блок мы передадим другому разработчику»).

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

Часть 2. Как принимать фидбэк и использовать BOFF на 200%

Введение ко второй части: Умение слушать — суперсила настоящего лидера

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

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

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

Глава 4. «Обратный BOFF»: Превращаем любую критику в конструктив

Представьте типичную ситуацию: к вам врывается разгневанный руководитель смежного отдела и бросает: «Ваша команда опять все сломала! Из-за вас у нас встали продажи! Я так больше работать не могу!»

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

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

Как это работает: от обвинения к фактам

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

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

Ваши действия:

1. Сначала — амортизация. Не спорьте. Признайте чувства собеседника.«Понимаю ваше беспокойство/разочарование. Спасибо, что поделились этим. Давайте разберемся, чтобы я мог все исправить».
2. Запрос B (Поведения): Ищем конкретику.«Чтобы я лучше понял, не могли бы вы привести конкретный пример? Какое именно действие (или бездействие) моей команды привело к таким мыслям?»
3. Запрос O (Результата): Уточняем реальный ущерб.«Понял. А к каким именно негативным результатам это привело с точки зрения ваших метрик/целей?»
4. Запрос F (Чувств): Понимаем эмоциональный фон (используйте осторожно).«Я вижу, что эта ситуация вызывает у вас сильные эмоции. Это потому, что она ставит под угрозу годовой бонус отдела?»
5. Переход к F (Будущему): Фокусируемся на решении.«Хорошо, теперь картина ясна. Как, по-вашему, нам стоит поступать в будущем, чтобы избежать подобных ситуаций? Какие шаги с нашей стороны вы бы хотели видеть в первую очередь?»

Кейс: Диалог со стейкхолдером

Давайте посмотрим, как это выглядит в реальном диалоге:

Стейкхолдер: (Врываясь в кабинет) «Сергей, ваша последняя фича — это катастрофа! Она абсолютно бесполезна и только всех путает!»Вы (Менеджер): (Спокойно) «Иван, понимаю, звучит так, будто мы сильно вас подвели. Спасибо, что пришли сразу ко мне. Давайте разберемся.(Запрос B): Можете показать, о каком конкретно поведении фичи или ее элементе идет речь? Что именно пользователи делают не так, как ожидалось?»Стейкхолдер: «Да вот эта новая кнопка экспорта! Никто не понимает, куда сохраняется отчет!»Вы: «Понял, кнопка экспорта.(Запрос O): А к каким последствиям это уже привело? Нам в техподдержку начали поступать жалобы?»Стейкхолдер: «Да! Пять жалоб за утро! А главное, отдел продаж не может выгрузить отчеты для ключевых клиентов, у них сделки горят!»Вы: «Пять жалоб и срыв подготовки отчетов для продаж — это серьезно. Теперь я понимаю масштаб проблемы.(Переход к F): Смотрите, прямо сейчас я попрошу дизайнера переделать этот флоу и мы выкатим хотфикс в течение двух часов. А на будущее — как вы считаете, что нам нужно изменить в процессе, чтобы такие неочевидные решения не попадали в релиз? Может, нам стоит включать вас в финальное демо перед выкаткой?»Стейкхолдер: (Уже спокойнее) «Да, давайте я буду смотреть финальную версию. Спасибо, что оперативно реагируете».

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

Высший пилотаж: Проактивный запрос обратной связи

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

Как это сделать:

«Коллеги/руководитель, мы закрыли проект X. Я бы хотел получить от вас обратную связь по моей работе, чтобы в будущем быть еще эффективнее. Если удобно, давайте прямо по BOFF:Были ли в моем поведении моменты, которые вам показались неоптимальными?Привело ли это к каким-то негативным результатам?Что бы вы посоветовали мне изменить в будущем?»

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

Глава 5. BOFF для продвинутых: Нестандартные сценарии

Освоив базовое применение BOFF для коррекции и получения обратной связи, вы готовы перейти на следующий уровень. Гибкость модели позволяет использовать ее далеко не только в классических беседах «руководитель-подчиненный». Эта глава посвящена трем нестандартным, но крайне важным сценариям, которые выведут ваше мастерство коммуникации на новый уровень.

Сценарий 1: Позитивная обратная связь по BOFF — как хвалить, чтобы это работало

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

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

Как это выглядит:

• B (Поведение): «Мария, я заметил, что перед релизом ты по своей инициативе написала подробную инструкцию для службы поддержки с описанием новой фичи и возможных вопросов пользователей».
• O (Результат): «Благодаря этому в первую неделю после релиза у нас не было ни одного эскалированного тикета от поддержки. Они смогли решить все вопросы самостоятельно. Это сэкономило нам минимум 10 часов работы разработки».
• F (Чувства): «Я невероятно горд, что в команде есть люди с таким проактивным подходом. Это очень вдохновляет».
• F (Будущее): «Это отличный пример для всей команды. Давай подумаем, как мы можем сделать это нашей стандартной практикой для всех крупных релизов?».

Такой фидбэк не только мотивирует Марию, но и масштабирует ее успешный опыт на всю команду.

Сценарий 2: Групповой BOFF — как говорить с командой о проблемах

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

Цель: Сфокусировать команду на общей проблеме и инициировать совместный поиск решения.

Как это выглядит (на примере ретроспективы):

• B (Поведение): «Коллеги, давайте посмотрим на факты. В этом спринте 15 из 30 задач были заблокированы и простаивали в среднем по два дня из-за ожидания код-ревью».
• O (Результат): «В итоге мы не выкатили ключевую фичу Х, которую обещали бизнесу, и сорвали сроки по всему релизу».
• F (Чувства): «Я чувствую досаду и беспокойство, потому что мы, как команда, не смогли выполнить наше обязательство, хотя у каждого из нас были все возможности».
• F (Будущее): «Это наша общая ответственность. Давайте вместе подумаем, как мы можем изменить наш процесс код-ревью, чтобы этого больше не повторялось? Какие у вас есть идеи? Может, выделить специальное время? Или ввести лимит на время ревью?».

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

Сценарий 3: BOFF для своего руководителя — высший пилотаж

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

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

Правила игры:

1. Выберите правильное время и место. Только тет-а-тет, когда руководитель не «в огне».
2. Начните с «запроса разрешения». «Иван Иванович, у меня есть пара мыслей по поводу наших планерок. Удобно, если я поделюсь? Это займет 5 минут».
3. Используйте максимально смягченные формулировки, фокусируясь на процессах, а не на личности.

Как это выглядит:

• B (Поведение): «Я заметил, что на последних нескольких командных встречах мы часто уходим в обсуждение технических деталей, которые касаются только двух-трех человек».
• O (Результат): «Из-за этого встречи затягиваются, а остальная часть команды теряет фокус и просто ждет окончания, хотя могла бы в это время работать над задачами. По моим ощущениям, мы теряем суммарно 3-4 часа командного времени в неделю».
• F (Чувства): «Я немного переживаю, что это снижает общую эффективность и может вызывать у ребят фрустрацию».
• F (Будущее): «У меня есть идея, что если нам попробовать выносить такие глубоко технические вопросы на отдельные, более короткие встречи с вовлеченными специалистами? Это позволило бы сделать общие планерки короче и сфокусированнее. Что вы думаете на этот счет?».

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

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

Общее заключение: От модели к культуре

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

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

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

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

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

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

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

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

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

Это огромный шаг вперёд по сравнению с хаотичным перебором идей или ограниченностью AARRR-воронки. Мы научились создавать правильные гипотезы.

Но здесь нас поджидает следующая ловушка. Сформулировав сильную, релевантную и недорогую в проверке гипотезу (например, «Гипотезу UX-улучшения» о сокращении полей в форме регистрации), мы рискуем упаковать её в стандартный, упрощённый шаблон. Например: «Мы считаем, что сокращение полей с 7 до 3 увеличит конверсию в регистрацию на 25%».

И что дальше? Мы проводим A/B-тест, получаем рост на 18% и ставим галочку. Гипотеза «почти подтвердилась». Но что мы узнали на самом деле? Почему рост именно 18%, а не 25%? Связан ли он с нашим действием или с сезонным всплеском трафика? А главное — как этот локальный успех приблизил нас к глобальной цели компании по увеличению годовой выручки?

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

Именно для этого, в дополнение к 6-уровневой модели генерации, необходим фреймворк для формулировки и дизайна эксперимента. Давайте назовем его моделью ABCD.

Ограничения старых карт: почему стандартные формулы заводят в тупик

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

Чаще всего в работе встречаются два популярных подхода:

1. Формула «Если..., то..., потому что...»
   Это, пожалуй, самый распространенный шаблон. Он заставляет четко связать три элемента: действие, ожидаемый результат и причину, по которой этот результат должен наступить.
• Пример: «Если мы добавим видеообзоры в карточки товаров, то конверсия в покупку вырастет на 10%, потому что пользователи смогут лучше оценить товар и развеять свои сомнения».
  Это прекрасный инструмент для тренировки логического мышления и отсеивания идей со слабой аргументацией.
2. Шаблон «Мы верим, что...»
   Этот формат, популярный в Agile-среде, фокусируется на убеждении команды и четко отделяет его от критериев успеха.
• Пример: «Мы верим, что упрощение процесса регистрации до одного клика через соцсети для новых пользователей приведет к росту числа регистраций. Мы поймем, что правы, когда доля успешных регистраций вырастет с 15% до 25%».
  Этот подход отлично разделяет само предположение и измеримые данные, которые должны его подтвердить или опровергнуть.

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

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

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

Второй вопрос — методологический. Шаблон «Мы верим, что... и мы убедимся, когда...» создает опасную иллюзию, будто «убедиться» можно одним-единственным, абсолютно объективным способом. Он не заставляет нас критически оценивать сам метод проверки. А ведь именно от него зависит результат. Спросить у ста пользователей, купят ли они ваш продукт за 100 долларов, и попросить десять из них реально ввести данные карты для покупки — это два совершенно разных эксперимента с потенциально противоположными выводами.

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

От «что» и «почему» к «зачем» и «как именно»

Если 6-уровневая модель отвечает на вопрос «О чём гипотеза?», то полная модель ABCD отвечает на вопросы «Зачем мы её проверяем и как именно это будем делать?». Она превращает любую, даже самую простую гипотезу об оптимизации, в полноценный исследовательский проект.

Модель ABCD — это не замена 6-уровневой структуры, а её логическое завершение. Это фреймворк, который «оборачивает» любую сгенерированную вами гипотезу, делая её строгой, прозрачной и стратегически осмысленной.

Вот её компоненты:

A → B: Суждение (The Statement, from A to B)

Это ядро, сама суть вашего предположения. Оно описывает связь между условием (A) и следствием (B). Ключевое преимущество модели ABCD в том, что она не ограничивает вас одним типом суждений.

• Гипотеза о решении: Это классика. «Если мы внедрим адаптивную систему скидок (A), то средний чек повторных покупок вырастет на 20% (B)». Здесь мы проверяем эффективность конкретного действия.
• Гипотеза о проблеме: Здесь мы ничего не создаем, а проверяем наше понимание клиента. «Мы считаем, что у владельцев небольших интернет-магазинов (A) основная сложность не в привлечении трафика, а в обработке возвратов (B)».
• Гипотеза о корреляции: Здесь мы ищем скрытые закономерности в данных. «Мы предполагаем, что пользователи, заполнившие свой профиль на 100% (A), имеют показатель удержания (retention) в 3 раза выше среднего (B)».

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

C: Ценность (The Core Value)

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

Представим гипотезу: «Если мы перекрасим кнопку "Купить" из синего в зеленый (A), то конверсия вырастет на 1% (B)». Теперь добавим компонент C: «Это важно, потому что наш годовой OKR — увеличить выручку на 30 миллионов, и этот 1% принесет нам всего 5 тысяч (C)». Сразу становится очевидно, что игра не стоит свеч.

Ценность — это не только деньги. Это может быть и стратегическое знание. Например: «Нам важно понять, действительно ли наши пользователи готовы платить за премиум-поддержку (C), потому что это определит всю нашу стратегию монетизации на следующий год». В этом случае даже провал гипотезы принесет огромную пользу, уберегая компанию от многомиллионных инвестиций в неверном направлении.

Ценность — это мост между вашей гипотезой и стратегией бизнеса. Компонент, которого так не хватает в стандартных шаблонах. Он заставляет вас ответить на вопрос: «И что с того?». Этот вопрос моментально отсеивает эксперименты, которые ведутся «просто ради метрик».

• Пример: «Проверка этой гипотезы важна, потому что повышение CTR на этом шаге воронки, согласно нашей юнит-экономике, напрямую влияет на стоимость привлечения клиента (CAC). Снижение CAC на 7% — это ключевая задача нашего отдела на этот квартал (C)».

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

D: Дизайн проверки (The Design of the Test)

Это самый честный компонент модели. Он заставляет ответить на вопрос «Как именно мы это узнаем?» и признать, что результат неотделим от метода.

Вместо расплывчатой фразы «...мы убедимся, увидев рост конверсии», компонент D требует строгости.

• Метод: Что мы будем использовать? A/B-тестирование, глубинное интервью, «партизанский» тест на лендинге, анализ логов?
• Контекст: На каком сегменте аудитории? В какие сроки? Какие еще факторы могут повлиять на результат (например, сезонность или рекламная кампания конкурента)?

Например: «Мы проверим это с помощью A/B-теста на 50% нового трафика из США в течение 4 недель. Результат будем считать значимым при уровне достоверности 95% (D)». Такая формулировка не оставляет места для двойных толкований и делает эксперимент по-настоящему научным.

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

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

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

1. Генерация: С помощью 6-уровневой модели вы определяете, что сейчас самое время сфокусироваться на «Гипотезе поведения пользователей» и конкретно на «Гипотезе ключевого действия (Activation Action)». Вы формулируете базовое предположение: «Кажется, пользователи, создавшие более 5 задач в первую сессию, становятся лояльными».
2. Формулировка и дизайн: Теперь вы «оборачиваете» это предположение в модель ABCD:
• (A→B): Мы предполагаем, что пользователи, создавшие >5 задач в первую сессию (A), имеют показатель удержания на второй неделе 70% против 20% у остальных (B).
• (C): Нам важно подтвердить это, потому что если это так, то вся наша стратегия активации новых пользователей будет сфокусирована на том, чтобы довести их до создания 5 задач. Это наш потенциальный "aha-момент", который может стать ядром всего онбординга.
• (D): Мы проверим это, проанализировав данные по всем новым пользователям за последние 3 месяца. Мы разделим когорты по неделям, чтобы исключить влияние сезонности. Мы также проверим, нет ли других факторов, коррелирующих с удержанием (например, источник трафика).

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

Заключение

Переход на модель ABCD — это смена парадигмы. Это отказ от роли «исполнителей задач» в пользу роли «исследователей и стратегов».

• Это заставляет говорить о деньгах и целях. Вместо споров о цветах кнопок вы начинаете обсуждать, какой эксперимент принесет максимальную пользу для достижения годовых OKR.
• Это повышает научную строгость. Вы перестаете обманывать себя результатами, полученными ненадежными методами, и начинаете проектировать честные эксперименты.
• Это превращает провалы в ценные уроки. Если гипотеза не подтвердилась, у вас есть четкая система для анализа: проблема была в нашем изначальном суждении (A→B) или в дизайне нашего эксперимента (D)?

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

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

Часть 1: Структура гипотез (6 уровней)

Эта часть отвечает на вопрос: «О чём наша гипотеза?»

🔹 1. Гипотеза проблемы

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

Сильная базовая гипотеза: «Мы считаем, что родители школьников испытывают постоянный стресс из-за отсутствия простого способа контролировать питание и расходы ребёнка в школе».

Подвиды:

• Гипотеза существования рынка
• Комментарий: Отвечает на вопрос: «Есть ли достаточное количество людей с этой проблемой, чтобы это было экономически целесообразно?»
• Пример: «Мы считаем, что в городах-миллионниках существует не менее 100 000 владельцев собак, которые регулярно сталкиваются с проблемой поиска дог-френдли заведений, что формирует достаточный рынок для нашего приложения».
• Гипотеза критичности проблемы
• Комментарий: Проверяет, насколько сильно «болит» у пользователя. Достаточно ли, чтобы он начал активно искать решение?
• Пример: «Потеря чеков и ручной учёт расходов для фрилансеров является настолько критичной проблемой, что они готовы платить до 500 рублей в месяц за сервис, который автоматизирует этот процесс».
• Гипотеза осознанности проблемы
• Комментарий: Понимают ли пользователи, что у них вообще есть проблема, и могут ли они её сформулировать?
• Пример: «Мы предполагаем, что начинающие авторы осознают, что их тексты "сухие", но не могут самостоятельно определить причину, и активно ищут инструменты для "улучшения стиля"».
• Гипотеза мотивации искать решение
• Комментарий: Проверяет, предпринимают ли пользователи уже какие-то действия для решения проблемы.
• Пример: «Мы видим, что менеджеры проектов уже сейчас пытаются строить диаграммы Ганта в Excel, что доказывает их мотивацию искать инструмент для визуализации планов работ».

🔹 2. Гипотеза решения

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

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

Подвиды:

• Гипотеза ценности
• Комментарий: Отвечает на вопрос: «Будет ли наше решение воспринято как полезное?»
• Пример: «Мы верим, что функция автоматической транскрибации Zoom-встреч будет воспринята менеджерами как ключевая ценность, экономящая им до 3 часов в неделю».
• Гипотеза монетизации
• Комментарий: Проверяет готовность пользователей платить за предложенное решение.
• Пример: «Пользователи нашего бесплатного фоторедактора готовы платить 299 рублей в месяц за доступ к "волшебному ластику", удаляющему лишние объекты с фото».
• Гипотеза дифференциации
• Комментарий: Отвечает на вопрос: «Почему пользователи выберут нас, а не существующие альтернативы?»
• Пример: «Наше решение по совместному редактированию документов будет воспринято как более быстрое и интуитивно понятное по сравнению с Google Docs, что станет ключевым фактором выбора для небольших креативных команд».

🔹 3. Гипотеза поведения пользователей

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

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

Подвиды:

• Гипотеза ключевого действия (Activation Action)
• Комментарий: Ищет то самое «первое успешное действие», после которого пользователь становится лояльным.
• Пример: «Мы считаем, что пользователи, которые в первую сессию добавили в наш таск-менеджер более 5 задач, с вероятностью 70% вернутся в продукт на следующей неделе».
• Гипотеза удержания (Retention)
• Комментарий: Проверяет, какое действие или ценность заставит пользователя возвращаться.
• Пример: «Если мы будем отправлять еженедельное пуш-уведомление с персональной статистикой, это увеличит удержание пользователей нашего музыкального сервиса на 10%».
• Гипотеза отказа/оттока (Churn)
• Комментарий: Выявляет точное место или причину, по которой пользователи уходят.
• Пример: «Столкновение с пятишаговым процессом верификации аккаунта является основной причиной, по которой 40% новых пользователей удаляют наше финансовое приложение».

🔹 4. Гипотеза продуктового роста

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

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

Подвиды:

• Гипотеза оффера
• Комментарий: Проверяет, какой формат предложения наиболее эффективно стимулирует целевое действие.
• Пример: «Предложение "Пригласи друга и получите оба по 500 бонусных рублей" увеличит виральность больше, чем оффер "Скидка 10% на следующий заказ"».
• Гипотеза канала
• Комментарий: Определяет, через какой канал можно наиболее эффективно привлекать нужный сегмент.
• Пример: «Рекламная кампания в TikTok принесёт нам больше регистраций от аудитории 18-24 лет, чем контекстная реклама в Яндекс.Директ».
• Гипотеза контекста / месседжа
• Комментарий: Проверяет, как ситуация или формулировка влияет на восприятие ценности.
• Пример: «Сообщение "Осталось всего 3 места на вебинар", показанное за день до события, вызовет больше регистраций, чем стандартное напоминание».
• Гипотеза виральности
• Комментарий: Ищет механики, которые побуждают пользователей естественным образом приглашать других.
• Пример: «Если дать пользователям возможность поделиться результатами своего теста в виде красивой картинки, это увеличит виральный приток трафика на 15%».

🔹 5. Гипотеза корреляционной зависимости

Суть: Это предположение о существовании устойчивой статистической зависимости между показателем A и показателем B.

Сильная базовая гипотеза: «Мы предполагаем, что долгосрочная ценность (LTV) пользователя в нашем SaaS-сервисе как-то связана с тем, насколько активно он пользуется API для интеграций».

Подвиды:

• Паттерны поведения
• Комментарий: Ищет связь между действиями внутри продукта и его ценностью для пользователя.
• Пример: «Увеличение количества комментариев, оставленных пользователем под статьями, коррелирует с ростом его LTV».
• Влияние этапов воронки
• Комментарий: Проверяет, как изменение метрики на одном этапе воронки влияет на другие.
• Пример: «Увеличение конверсии в регистрацию на 10% напрямую влечёт за собой увеличение количества первых покупок на 4%».
• Влияние внешних факторов
• Комментарий: Оценивает, как активность пользователей зависит от внешних условий.
• Пример: «Количество заказов в нашем сервисе доставки продуктов питания статистически зависит от прогноза погоды: чем хуже погода, тем больше заказов».

🔹 6. Гипотеза оптимизации

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

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

Подвиды:

• Гипотеза UX-улучшения
• Комментарий: Проверяет, как упрощение пользовательского пути влияет на конверсию.
• Пример: «Сокращение полей в форме регистрации с 7 до 3 увеличит её завершение на 25%».
• Гипотеза улучшения копирайтинга/визуала
• Комментарий: Оценивает влияние текста и изображений на вовлечённость.
• Пример: «Замена текста на кнопке с "Отправить" на "Получить бесплатный урок" повысит CTR этой кнопки на 15%».
• Гипотеза редизайна
• Комментарий: Проверяет влияние обновления визуального стиля на метрики доверия или вовлечённости.
• Пример: «Обновление дизайна личного кабинета в более современном стиле приведёт к увеличению среднего времени на экране на 10%».
• Гипотеза технической производительности
• Комментарий: Оценивает, как скорость работы продукта влияет на поведение пользователей.
• Пример: «Снижение времени загрузки каталога товаров с 2 секунд до 500 мс увеличит глубину просмотра на 20%».
• Гипотеза сценариев использования
• Комментарий: Проверяет, как предложение новых путей взаимодействия с продуктом увеличивает вовлечённость.
• Пример: «Добавление готовых шаблонов для проектов в наш таск-менеджер увеличит частоту создания новых проектов на 30%».
• Гипотеза контента
• Комментарий: Оценивает, как добавление или изменение контента влияет на удержание и активность.
• Пример: «Внедрение коротких обучающих видео в онбординг увеличит долю пользователей, успешно завершивших настройку профиля, с 40% до 60%».

Часть 2: Как выбрать, что проверять? (3 слоя анализа)

Эта часть отвечает на вопрос: «Стоит ли проверять эту гипотезу сейчас и какой ценой?» Любую гипотезу из 6 категорий выше можно проанализировать по этим трём слоям.

LAYER 1: Слой Риска

• Суть: Оценить, насколько гипотеза критична для выживания и успеха продукта.
• Уровни:
• Гипотезы выживания (Высокий риск): Если они неверны — продукта не будет. Это почти все Гипотезы проблемы и Гипотезы монетизации. Их нужно проверять первыми.
• Гипотезы роста (Средний риск): Если не сработают, продукт не будет расти. Это Гипотезы роста и Гипотезы поведения.
• Гипотезы оптимизации (Низкий риск): В худшем случае вы потратите время. Это все Гипотезы оптимизации.

LAYER 2: Слой Ресурсов

• Суть: Оценить, какой ценой мы можем проверить гипотезу.
• Уровни:
• "Бумажные" тесты (Почти бесплатно): Опросы, интервью, фейковые лендинги. Идеально для проверки гипотез проблемы и ценности.
• MVP / Прототипы (Дёшево): Интерактивные макеты, ручная имитация функции. Подходит для проверки гипотез решения и UX.
• Полноценная разработка (Дорого): A/B тесты, внедрение сложных функций. Используется для проверки гипотез оптимизации и роста, когда риски уже сняты.

LAYER 3: Слой Бренда и Этики

• Суть: Оценить, как гипотеза повлияет на доверие пользователей и репутацию компании.
• Уровни:
• Укрепляющие доверие: Гипотезы о прозрачности, улучшении поддержки, честности. (Пример: «Если мы сделаем процесс отмены подписки проще, лояльность клиентов вырастет»).
• Нейтральные: Большинство A/B тестов.
• Рискованные для бренда ("Тёмные паттерны"): Гипотезы, которые могут улучшить метрики за счёт негативного опыта. (Пример: «Если скрыть кнопку отмены подписки, отток уменьшится»). Такие гипотезы следует проверять с особой осторожностью или не проверять вовсе.

Как это работает вместе:

1. Сгенерируйте гипотезу, используя 6 уровней (например, «Гипотеза удержания»).
2. Оцените её по 3 слоям:
• Это гипотеза роста (средний риск).
• Её можно проверить через MVP (дёшево).
• Она укрепляет доверие к бренду.
3. Примите решение: Гипотеза важна, недорога в проверке и позитивна для бренда. Берём в работу

Почему ваша система гипотез не работает? Разбор популярных моделей и альтернативный подход

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

Самый распространённый подход к классификации гипотез — это модель AARRR (Acquisition, Activation, Retention, Referral, Revenue). Она кажется логичной: берём каждый этап воронки и придумываем, как его улучшить. Но в этом и кроется её главная слабость.

AARRR — это отличный инструмент для измерения здоровья продукта, но очень плохой — для поиска идей. Он заставляет искать ключи под фонарём — не потому, что они там потеряны, а потому что там светло. Вы фокусируетесь на вопросе «Как нам поднять Retention на 5%?», но упускаете из виду куда более важный: «А есть ли в нашем продукте ценность, ради которой стоит возвращаться?». AARRR подталкивает к локальным оптимизациям, но не помогает найти фундаментальные проблемы.

Хорошо, а что насчёт других классификаций?

Есть и другие модели, но у них свои недостатки.

1. По типу изменения (UX, Tech, Business). Эта классификация удобна для распределения задач по командам (дизайнерам, разработчикам, маркетологам), но она ничего не говорит о ценности и риске гипотезы. Гипотеза «перекрасить кнопку» и «ввести новый тариф» могут попасть в одну категорию, хотя их влияние на бизнес несопоставимо.
2. По источнику (от пользователей, от команды, из данных). Полезно для понимания, откуда пришла идея, но абсолютно бесполезно для её оценки. Идея от гендиректора и идея, основанная на 20 интервью с клиентами, требуют совершенно разного подхода к проверке, но в этой системе они равны.
3. Разделение на гипотезы проблемы и решения. Это уже теплее! Этот подход, популяризированный многими экспертами, заставляет сначала доказать наличие проблемы, а потом предлагать решение. Это огромный шаг вперёд по сравнению с хаосом. Но и здесь не хватает глубины. Что происходит после того, как мы придумали решение? Как его растить и улучшать? Эта модель часто оставляет нас на полпути.

Чем отличается предлагаемый подход?

Предлагаемая 6-уровневая модель — это не просто ещё одна классификация. Это иерархическая система мышления, которая объединяет лучшие черты существующих подходов и устраняет их недостатки.

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

2. Она детализирована и конкретна.
В отличие от AARRR, которая просто говорит «ищи в Retention», эта модель даёт конкретные подкатегории для размышления. Например, на уровне Проблемы она заставляет задуматься:

• А рынок вообще есть (гипотеза существования)?
• Людям действительно «больно» (гипотеза критичности)?
• Они понимают свою боль (гипотеза осознанности)?
• Они уже пытаются что-то делать (гипотеза мотивации)?

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

3. Она дополнена слоями для принятия решений.
Любую гипотезу, из любого уровня, можно оценить по трём практическим «фильтрам»:

• Слой Риска: Это проверка на выживание продукта или просто небольшое улучшение?
• Слой Ресурсов: Сколько нам будет стоить проверка этой идеи?
• Слой Бренда: Не повредим ли мы доверию пользователей в погоне за метриками?

Итог: от плоской классификации к объёмной системе

В то время как другие модели предлагают плоскую, двухмерную картинку, этот подход даёт объёмную, многослойную систему.

• AARRR говорит, где посмотреть.
• Проблема/Решение говорит, с чего начать.
• 6-уровневая модель даёт полную карту местности, компас и даже высотомер, чтобы вы точно знали, где находитесь, куда идти и какой маршрут выбрать.

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