Михаил ЛопатинМоскваДмитровское шоссе д. 50 оф.240

Блог

Блог

Тебе пишут в 23:47 в субботу: «Срочно поправь кнопку, горит».Ты открыл письмо. «Здравствуйте, нужен сайт, бюджет есть, сроки не горят». Сердце ёкнуло — заказ!Ты боишься сказать «нет». Признай.«Ну там всё просто, сайт как у конкурентов, ты же профи — разберёшься».Ты вычитываешь ТЗ, прикидываешь сроки, радуешься новому заказу.Первая встреча. Клиент улыбается, наливает кофе и говорит: «Мы с прошлым разработчиком расстались, он оказался полным идиотом».Ты открываешь чат. Первое сообщение от клиента. И по одной фразе уже понятно: этот проект сожрёт твои нервы, время и деньги.Ты открываешь мессенджер. Там сообщение: «Привет! Тут дело на пять минут, поправишь?»Ты знаешь свой стек лучше половины отдела. Твой код читают как книгу. Ты чинишь то, что другие боятся трогать.Ты назвал цену. Клиент сказал «ок, давайте работать». Быстро. Без торга. Без паузы.

Блог

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

Дизайн
Аватар
Баннер поста

Или наоборот — приносишь подрядчику 40 страниц, а он делает всё равно по-своему.

За 16 лет я был по обе стороны. Нанимал и получал мусор. Был исполнителем и читал ТЗ, из которых нельзя понять вообще ничего.

Проблема почти всегда одна. Не в коде. В формулировках.

Вот схема, которую подрядчик тебе не даст. Потому что размытое ТЗ ему выгоднее — из него можно вывернуться.

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

🎯 Начни не с задачи, а с результата

Самая частая ошибка заказчика: описывать КАК делать.

«Сделайте кнопку синей, поставьте её справа, добавьте анимацию».

Стоп. Ты не разработчик. Не лезь в реализацию.

Твоя зона — результат. Что должно произойти после того, как всё готово.

Пиши так:

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

Пример из практики. Клиент просил «красивый лендинг». Получил красивый. Заявок ноль. А цель была — заявки. Про неё в ТЗ не было ни слова.

Результат первым. Всегда.

🧩 Раздели ТЗ на три слоя

Хорошее ТЗ — это не сплошной текст. Это три уровня.

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

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

Третий слой — детали. Тексты, референсы, ограничения, сроки, бюджет.

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

Три слоя дисциплинируют обе стороны.

📐 Приложи референсы и антиреференсы

Слова врут. «Современно», «дорого», «минималистично» — у каждого в голове своя картинка.

Дай 3-5 примеров того, что нравится. И — обязательно — 2-3 примера того, что НЕ нравится.

Антиреференсы работают сильнее. Они показывают границу.

Я всегда прошу их у заказчика. Один сказал «хочу как у Apple», а в антиреференсах оказалось всё, что похоже на Apple. Просто он не знал, как назвать то, что хочет.

Без картинок ты продаёшь подрядчику воздух. И получаешь воздух обратно.

⏳ Пропиши, что НЕ входит в задачу

Это пункт, который спасает бюджеты и нервы.

Границы проекта важнее его содержания.

Напиши прямо: «Наполнение контентом — не входит», «Интеграция с 1С — отдельно», «Мобильное приложение — не в этом этапе».

Почему это критично. 80% конфликтов на проектах — это спор «а это входило или нет». Обе стороны уверены в своём.

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

В IT очевидного не существует. Есть только записанное.

🔗 Добавь критерии приёмки

Как ты будешь принимать работу? По ощущению «нравится / не нравится»?

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

Критерии приёмки — это чек-лист. Конкретный.

  • Сайт открывается за 3 секунды.
  • Форма отправляет заявку на почту X.
  • Вёрстка корректна на телефоне и десктопе.
  • Тексты вычитаны и без ошибок.

Есть пункт — есть проверка. Нет пункта — нет претензии.

Я как исполнитель обожаю такие ТЗ. Сделал по списку — сдал. Никто не приходит через месяц с «а давайте ещё вот тут».

Это защищает и тебя, и меня.

💼 Вывод: ТЗ — это не бумажка, это твоя власть

Правильное ТЗ переносит контроль на твою сторону.

Размытое — отдаёт власть подрядчику. И потом ты платишь дважды: за первую версию и за переделку.

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

Потрать день на ТЗ. Сэкономишь месяц на переделках.

📌 Разбираю такие рабочие штуки регулярно. На Дзене выходит не всё и не всем — лента капризная. Поэтому если хочешь задать вопрос по своему конкретному ТЗ и получить от меня живой разбор, а не общие слова — заходи в Телеграм: t.me/mikhail_lopatin_tutmee . Там я отвечаю лично. Обсуждаем проекты и в ВК: vk.com/tutmee — удобно, если ты там уже сидишь.

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

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