Основы
Почему ТЗ важнее цены
Большинство конфликтов с клиентами — не про деньги. Они про разное понимание того, что должно быть сделано. Хорошее ТЗ — это страховка для обеих сторон.
⚡
Нет ТЗ = нет договорённостей
Устная договорённость «сделай сайт за X» — это гарантия конфликта. Что входит в «сайт»? Мобильная версия? Авторизация? Интеграция с CRM? Без фиксации каждый понимает по-своему.
🎯
ТЗ помогает тебе оценить объём
Невозможно точно назвать цену, не понимая что именно нужно сделать. Бриф — это способ понять реальный скоп до того, как ты назвал цифру, к которой тебя потом привяжут.
Рабочий порядок
Разговор → Бриф (вопросы) → Скоп (что входит и что НЕ входит) → Оценка → Договор / договорённости → Работа
Бриф
Список вопросов клиенту
Не задавай всё сразу. Выбирай вопросы по ситуации — 5–7 ключевых достаточно для первого разговора. Остальное уточняется по ходу.
1
Какую бизнес-задачу должен решить этот продукт / фича?
Понять «зачем», а не только «что»
2
Кто будет пользоваться этим? Кто конечный пользователь?
Влияет на UX и требования к надёжности
3
Есть ли аналоги или примеры, которые нравятся? Что именно в них нравится?
Сэкономит много итераций на дизайн
4
Какой результат нужен через 3 месяца после запуска?
Позволяет понять приоритеты функционала
1
Есть ли уже существующий код / система, с которой нужно интегрироваться?
Стоит от «чистого листа» до «разбери Legacy»
2
Есть ли предпочтения по стеку? Если есть — почему?
Команда, хостинг, экосистема
3
Какая ожидаемая нагрузка? Сколько пользователей одновременно?
Влияет на архитектуру и стоимость инфры
4
Нужна ли мобильная версия / мобильное приложение?
Часто «забывают» упомянуть, но подразумевают
5
Нужны ли интеграции с внешними сервисами? (оплата, email, CRM, API)
Каждая интеграция — это отдельная задача
1
Есть жёсткий дедлайн? Если да — почему именно эта дата?
«Жёсткий» дедлайн часто мягче, чем кажется
2
Кто со стороны клиента принимает решения? Есть ли другие согласующие?
«Ещё покажу жене/партнёру» удваивает цикл правок
3
Как быстро ты готов давать обратную связь на промежуточные результаты?
Фиксируй ожидания по коммуникации сразу
4
Нужна ли поддержка после сдачи? На каких условиях?
Часто «небольшие правки» превращаются в месяцы бесплатной поддержки
1
Есть примерный бюджет на проект? Хотя бы диапазон?
Это не торг — это понимание масштаба. Без этого можно предлагать Tesla когда нужна Toyota
2
Если нужно выбрать между сроком и набором функций — что важнее?
Помогает расставить приоритеты MVP vs полный продукт
3
Есть функции, которые точно не нужны? Что за рамками?
Зафиксировать «что НЕ входит» так же важно, как «что входит»
Оценка
Как оценить объём задачи
Оценка без ТЗ — это угадывание. Даже с ТЗ — это диапазон, а не точная цифра. Всегда закладывай буфер.
1
Разбей на атомарные задачи
«Сделать авторизацию» — не задача. «Регистрация по email, подтверждение через письмо, вход, восстановление пароля, OAuth через Google» — задачи. Оценивай каждую отдельно.
2
Прибавляй 30–50% к своей оценке
Разработка всегда занимает дольше, чем кажется. Баги, нестандартные кейсы, итерации с клиентом — всё это время. 30% буфер — это не жадность, это реализм.
3
Давай диапазон, а не точку
«2–3 недели» честнее, чем «2 недели». Точная цифра создаёт нереалистичные ожидания и давление, если что-то пойдёт не так.
4
Фиксируй допущения
«Эта оценка предполагает, что дизайн уже готов и API документация предоставлена». Если допущения изменятся — оценка тоже изменится. Клиент должен это понимать.
Риски
Красные флаги — когда осторожно
Некоторые признаки проекта или клиента повышают вероятность проблем. Это не стоп-лист, но повод задать дополнительные вопросы.
«Это несложно, сделай быстро»
Клиент не понимает объём. Ожидания завышены.
ВЫСОКИЙ
Нет бюджета («обсудим после»)
Бюджет либо очень мал, либо клиент не серьёзен.
ВЫСОКИЙ
«Сначала сделай, потом оплачу»
Работа без предоплаты — высокий риск невыплаты.
ВЫСОКИЙ
Постоянно меняющиеся требования
Признак того, что видение продукта не сформировано.
СРЕДНИЙ
Несколько принимающих решения
Мама, партнёр, инвестор — каждый добавляет правки.
СРЕДНИЙ
Клиент уже сменил 2+ разработчиков
Стоит понять почему. Часто проблема на стороне клиента.
СРЕДНИЙ
Размытое описание («как у Apple, но лучше»)
Требует детального брифа перед оценкой.
НИЗКИЙ
Решение
Когда браться, когда отказывать
Отказ от плохого проекта — это не потеря, это сохранение времени для хороших клиентов.
✓ Берись
Задача понятна и конкретна
Клиент открыт к вопросам
Есть адекватный бюджет
Ты умеешь это делать хорошо
Один человек принимает решения
Готов к частичной предоплате
✗ Откажись
«Сделай за копейки, потом дам больше»
Задача вне твоей компетенции
Клиент не слышит твои вопросы
Без предоплаты, «проверь себя»
Нереальные сроки без причины
У тебя уже плохое предчувствие
Интуиция работает
Если уже в начале разговора что-то вызывает дискомфорт — не игнорируй это. Плохой проект не становится лучше в процессе. Лучше потратить время на поиск следующего клиента.
Итого
Чеклист перед стартом работ
✓
Бриф проведён
Ты задал ключевые вопросы и получил ответы на цель, скоп, сроки и бюджет.
✓
Скоп зафиксирован письменно
Что входит и что НЕ входит — отправлено клиенту и подтверждено.
✓
Оценка с буфером
Называешь диапазон, а не точку. Допущения оценки озвучены.
✓
Предоплата получена
Минимум 30–50% до старта. Без предоплаты не начинай.
✓
Договорённости в письменном виде
Хотя бы в переписке — что делаешь, за сколько, к какому сроку, сколько итераций входит.