Как работает техзадание и смета

Вы вложили душу в проект, а получили фразу: «Мы думали, вы имели в виду другое»?

Знакомо? Эта фраза убила больше IT-проектов, чем все технические баги вместе взятые. Я сам через это проходил. Заказчик кивает, говорит «да, всё ок», а через месяц выясняется, что его видение и ваше — это две разные вселенные. Итог: сорванные сроки, потерянные деньги и испорченные нервы.

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

Почему ТЗ — ваша страховка, а не бюрократия

Техническое задание — это не список пожеланий. Это юридически значимый документ. Он:

• Фиксирует, что именно вы делаете и за что платите
• Помогает оценить реальную стоимость и сроки
• Защищает от бесконечных «а давайте еще добавим вот эту кнопку»
• Позволяет объективно сказать: «Всё готово, принимайте работу»
• Снижает риск недопонимания в 3-5 раз (проверено на практике)

Пример из жизни: Один стартап заказал разработку сайта. В ТЗ было сказано «форма обратной связи». Разработчик сделал простую форму. А заказчик хотел, чтобы она сама отправляла данные в CRM и ставила задачи менеджерам. В итоге — переделка за отдельные деньги и задержка на 2 недели. Если бы в ТЗ расписали сценарий: «Пользователь заполняет форму → данные летят в CRM → менеджеру приходит уведомление», этого бы не случилось.

Из чего состоит качественное ТЗ для веб-разработки

1. Бизнес-требования: зачем мы это делаем

Что должно быть:

• Цели проекта (например, увеличить продажи на 20%)
• Кто ваша целевая аудитория и что ей нужно
• Ключевые метрики успеха (конверсия, время на сайте)
• Какую бизнес-проблему решаем

Чем опасно отсутствие: Вы получите технически идеальный продукт, который никому не нужен. Он не будет продавать.

2. Функциональные требования: что система должна делать

Что должно быть:

• Подробное описание каждой функции
• Пользовательские сценарии (User Stories): «Как клиент, я хочу...»
• Роли пользователей (админ, менеджер, клиент) и их права
• Бизнес-процессы (как заказ попадает в работу)

Пример: Вместо «каталог товаров» напишите: «Пользователь заходит на страницу каталога, видит фильтры по цене и категории, может добавить товар в корзину в один клик».

Чем опасно отсутствие: Критические функции будут пропущены. Доделывать их — дорого и долго.

3. Технические требования: на чем это работает

Что должно быть:

• Требования к скорости загрузки и нагрузке (сколько человек одновременно)
• Интеграции с внешними системами (CRM, 1С, платежки)
• Требования к безопасности (защита данных)
• Технологический стек (если важен для вас)

Чем опасно отсутствие: Сайт упадет при первом наплыве посетителей. Или его взломают. А интеграция с 1С выльется в огромные доп. расходы.

4. Требования к дизайну и UX: как это выглядит

Что должно быть:

• Ссылки на сайты, которые вам нравятся (референсы)
• Требования к удобству (юзабилити)
• Адаптивность под телефон и планшет
• Гайдлайны бренда (цвета, шрифты, логотип)

Чем опасно отсутствие: Вы получите «коробку», которая работает, но выглядит ужасно и неудобна. Клиенты уйдут к конкурентам.

5. Критерии приемки: когда работа сдана

Что должно быть:

• Четкие условия: «Работа считается выполненной, когда...»
• Тест-кейсы для проверки (например, «зарегистрироваться, заказать товар, оплатить картой»)
• Метрики производительности (страница грузится не дольше 2 секунд)

Чем опасно отсутствие: Бесконечные споры «это баг, это фича». Вы не сможете доказать, что работа сделана.

Как составить смету, которую не придется пересматривать

Смета — это не просто цифры. Это план ваших трат. Вот типичные ошибки, которые превращают бюджет в дыру:

• «Шапкозакидательские» оценки: «Да мы за месяц все сделаем!» — без учета рисков и правок.
• Неучтенные работы: Забыли про тестирование, документацию, настройку сервера. А это деньги.
• Скрытые costs: Лицензии на софт, хостинг, услуги дизайнера — всё это не входит в «разработку».
• Отсутствие резерва: Нет запаса на непредвиденное. Любая мелочь — и вы в минусе.

Что должно быть в прозрачной смете:

• Детализация по этапам: Проектирование — 20 часов, дизайн — 40 часов, верстка — 60 часов.
• Трудозатраты в часах: По каждому виду работ. Так вы видите, за что платите.
• Стоимость ресурсов: Часовая ставка разработчика, дизайнера.
• Дополнительные расходы: Лицензии, хостинг, домены, API.
• Резерв на риски: Обычно 15-30% от суммы. Это ваш «подушка безопасности».
• Условия изменения сметы: Когда и как можно добавить работы и сколько это будет стоить.

Методы оценки, которые действительно работают

1. PERT-оценка

Не гадаем, а считаем по формуле. Оцениваем каждую задачу в трех вариантах:

• Оптимистичная: Если всё идеально
• Реалистичная: Наиболее вероятный сценарий
• Пессимистичная: Если всё пошло не так

Формула: (Оптим + 4×Реалист + Пессим) / 6. Это даст вам взвешенную оценку, близкую к реальности.

2. Оценка по аналогии

Посмотрите на похожие проекты, которые вы уже делали. Сколько времени и денег они заняли? Используйте эти данные.

3. Покомпонентная оценка

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

Как ТЗ и смета меняются при использовании платформ

Если вы используете платформу (например, Falcon Space), процесс упрощается. Вам не нужно изобретать велосипед.

В ТЗ можно меньше описывать:

• Техническую архитектуру (ее уже за вас продумали)
• Базовые функции (личные кабинеты, права доступа — это есть «из коробки»)
• Интеграции (готовые API-механизмы)

В смете появляется ясность:

• Лицензия платформы — фиксированная сумма, вы знаете ее сразу
• Типовые доработки — предсказуемая стоимость
• Резерв на риски можно снизить (платформа стабильна и проверена)

Чек-лист: проверьте ТЗ и смету перед подписанием

Для ТЗ:

• ☐ Есть описание бизнес-целей
• ☐ Все функции описаны конкретно и измеримо
• ☐ Есть критерии приемки для каждой функции
• ☐ Описаны все интеграции
• ☐ Указаны требования к производительности и безопасности
• ☐ Есть примеры дизайна
• ☐ Документ понятен даже не-технарю

Для сметы:

• ☐ Все работы детализированы в часах
• ☐ Указаны доп. расходы
• ☐ Есть резерв 15-30%
• ☐ Понятна система оплаты
• ☐ Прописаны условия изменения сметы
• ☐ Нет скрытых позиций

Что делать, когда требования меняются

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

1. Формализуйте запрос: Заказчик пишет, что именно и почему меняется.
2. Оцените влияние: Как это повлияет на сроки, бюджет и другие функции.
3. Примите решение: Заказчик решает, готов ли он платить.
4. Зафиксируйте: Внесите правки в ТЗ и смету, подпишите допсоглашение.

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

Часто задаваемые вопросы (FAQ)

Полезные материалы по теме

• ТЗ для сайта: образец и инструкция по составлению
• Оценка IT-проекта: сроки, бюджет, риски
• Скрытые расходы IT-проекта: что учесть в бюджете