Представь ситуацию.

К тебе приходит заказчик и говорит что-то вроде:

… давайте просто добавим кнопку

… там дел на пару часов

… у конкурента же есть, значит и нам надо

Ты киваешь. Снаружи все выглядит спокойно.

Но внутри появляется знакомое чувство. Не тревога даже, а такое вязкое ощущение, будто ты зашел В ТУМАН.

Что делает эта кнопка?

Кто на нее нажимает?

Что происходит после?

И главное — почему сейчас?

Слова звучат просто. Слишком просто.

И ты уже знаешь по опыту, что если сейчас согласиться и молча пойти писать требования, через пару недель обязательно всплывет фраза «мы имели в виду совсем ДРУГОЕ».

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

Тут важно сразу снять обвинительный тон.

Дело не в том, что бизнес «не понимает разработку».

Просто он смотрит НА ДРУГОЙ СЛОЙ.

В голове заказчика кнопка — это:

… видимый результат

… быстрый способ что-то исправить

… символ того, что работа движется

А в реальности за этим словом часто намешано сразу несколько вещей:

… раздражение от текущего процесса

… давление сверху «почему у нас этого нет»

… обрывки идей из чужих продуктов

… надежда, что маленькое изменение даст большой эффект

Например, директор видел демо у конкурента.

Там была кнопка «Скачать отчет». И у него в голове цепочка очень короткая: есть кнопка → удобно → клиенты довольны.

Что под этой кнопкой происходит на самом деле - его в этот момент не волнует. И это нормально.

Это не его зона фокуса.

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

Я почти всегда начинаю с одного вопроса. Не вслух даже, а для себя.

ЧТО ИЗМЕНИТЬСЯ после того, как кнопка появится?

Если ответа нет или он звучит как «ну, станет удобнее», значит мы еще не в требованиях. Мы в ощущениях.

Был проект, где попросили кнопку «Отменить заказ». Формулировка простая.

Но дальше начались нюансы:

Отменить всегда или только до определенного статуса? Кто может отменять - клиент или менеджер? Что происходит с оплатой? А если заказ уже в доставке?

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

И это был честный ответ.

Он правда думал о другом результате, просто не сформулировал его словами.

Раньше я в таких ситуациях пытался сразу объяснять сложность.

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

По факту - бесполезно.

Человек НЕ ПРОСИЛ ЛЕКЦИЮ. Он хотел понять, почему простая идея внезапно обрастает вопросами.

Сейчас я делаю иначе. Я вообще не говорю про сложность.

Я говорю про ПОСЛЕДСТВИЯ.

Я не спорю с формулировкой. Я принимаю ее как черновик.

И дальше аккуратно разворачиваю:

Давайте я попробую проговорить сценарий. Пользователь нажимает кнопку.

Что должно случиться дальше?

Очень часто после этого следует пауза.

Иногда длинная. Иногда с фразой «хороший вопрос».

И вот тут важно не торопиться заполнять тишину.

Пусть заказчик САМ попробует описать результат. В этот момент он сам начинает видеть, что кнопка - это не точка, а начало цепочки.

Есть одна мысль, которая мне сильно помогает.

Я держу ее в голове, когда объясняю такие вещи.

Кнопка - это не элемент интерфейса. Это разрешение системе сделать что-то новое.

Удалить.

Отправить.

Подтвердить.

Изменить.

Как только появляется разрешение, сразу встают вопросы:

Кому можно? Когда можно? Что будет, если ошиблись? Кто потом разгребает последствия?

Я не навязываю эти вопросы.

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

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

Это тоже плохо.

Я стараюсь идти маленькими шагами:

Сначала - зачем вообще эта кнопка нужна. Потом - для кого она. Потом - что станет проще или быстрее.

Если на каком-то шаге оказывается, что ответ размытый, мы там и останавливаемся.

Не идем дальше, пока не прояснили.

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

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

… сценарий один

… пользователей мало

… последствий почти нет

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

Это сильно укрепляет доверие.

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

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

Коротко, без формальщины.

… зачем кнопка нужна

… что должно измениться после нажатия

… какие ограничения мы проговорили

… что пока не решили

Это не для отчета.

Это ЯКОРЬ,

Чтобы через месяц никто не вспоминал разговор по-своему.

Если запрос оставить в виде «сделайте кнопку», почти всегда случается одно из двух.

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

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

И не в том, чтобы усложнить жизнь.

Ты переводишь ощущение в форму, с которой можно работать.

Ты превращаешь жест в сценарий.

Ты помогаешь договориться о последствиях, а не о пикселях.

И тогда фраза «сделать кнопку» перестает быть ловушкой.

Она становится началом нормального разговора.