🗣 ТЗ заказчика — не приговор. Как переписать требования, не поссорившись

Заказчик принёс ТЗ. Вы читаете — и волосы дыбом. Не потому что написано коряво (хотя и это бывает). А потому что ТЗ чаще всего бывает неполным. Или неконкретным. Или неясным — то есть в принципе написанным, но так, что понять, что именно нужно сделать, невозможно. Иногда там просто нет половины нужного. А иногда описанное решение через полгода положит систему, а через год её придётся переписывать. И вот вы сидите, смотрите в этот документ и понимаете: надо как-то сказать. Но не так, чтобы человека обидеть.

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

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

Честно говоря, у меня ушло года три, чтобы это понять. Раньше я сразу лез с «вот тут неправильно, давайте я объясню». Сейчас пытаюсь иначе.

Первый приём — не критиковать, а задавать вопросы. Процессы, а не решение.

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

Второй — переводить «хочу» в «для чего».

Заказчик: «Нужна выгрузка в Excel из каждого документа». Банальный пример, но показательный. Можно молча сделать — и потом неделю разгребать «а почему тут так долго», «а почему данные разъезжаются». А можно спросить: «Для чего вам эта выгрузка? Что вы с ней делаете дальше?». И часто оказывается, что выгружают, чтобы свести в один отчет. Который можно собрать прямо в системе за пять минут. Без Excel, без боли, без «а у вас версия не та».

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

Не «это архитектурно неверно». А «если сделать так, то при росте объёмов вот эта операция начнёт занимать минуту вместо секунды. Хотите посмотреть альтернативу?». Заказчику всё равно, что там «архитектурно». Ему важно, что через год будет больно. Это он понимает.

И четвёртый, наверное, главный — отдавать решение заказчику.

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

Знаете, что самое странное во всём этом? Большинство конфликтов вокруг ТЗ — вообще не про ТЗ. Они про то, что аналитик или РП не умеет вести этот разговор. Технически он может быть гением, но если на встрече звучит «ваше ТЗ — фигня» (даже завуалированно) — проект начинает срываться ещё до старта.

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

#софт_скиллы #аналитика #ТЗ #переговоры #РП #практика