30 страниц вместо одного абзаца: почему услуга написания ТЗ на разработку окупается

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

Бриф на разработку приложения: как мы превращаем идеи в структуру

Словарь: о чем мы вообще говорим на созвонах

Мы не любим грузить терминами, но эти четыре слова — база, на которой строится смета. Если мы понимаем их по-разному, проект улетит в трубу:

• ТЗ — ваша страховка. Это подробная карта проекта, без которой разработка превращается в прогулку по минному полю.
• Функционал — список того, что приложение реально делает. «Хочу, чтобы было красиво» — это не функционал. «Нажать кнопку — получить PDF-отчет» — вот это он.
• Интеграции — «дружба» вашего сервиса с другими (банками, CRM, картами). Это самое дорогое и сложное место, которое нужно прописать сразу, а не в середине разработки.
• Бизнес-процессы — то, как работает ваша компания. Мы их просто перекладываем в код, чтобы менеджеры не делали лишних движений.

Основные понятия: что важно знать заказчику

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

• Техническое задание (ТЗ) на разработку ПО — это основной документ проекта, который детально описывает бизнес-логику, структуру данных, интерфейсы и технические ограничения будущего продукта.
• Функциональные требования — это описание конкретных действий и задач, которые должна выполнять система в ответ на действия пользователя (например, «регистрация через Telegram» или «выгрузка отчета в PDF»).
• Интеграции — это программные интерфейсы (API), через которые ваш продукт обменивается данными со сторонними сервисами: платежными шлюзами, CRM-системами или службами доставки.
• Бизнес-процессы — это последовательность действий внутри компании, которую мы автоматизируем с помощью программного обеспечения для повышения эффективности.

Ключевые показатели ТЗ: цифры и факты

Один из самых частых вопросов, с которыми к нам приходят: разработка технического задания — цена и сроки. Особенно это актуально, когда нужно подготовить ТЗ на разработку мобильного приложения или сложной CRM-системы.

Мы работаем по прозрачной модели: предварительная оценка и бриф проводятся бесплатно, а итоговая стоимость написания ТЗ фиксируется в договоре и не меняется в процессе проектирования. Это позволяет вам точно планировать бюджет еще до начала основной фазы разработки.

Чтобы лучше понимать масштаб работы, вот несколько усредненных данных из практики WAPP. Эти цифры не просто статистика, а база для оценки окупаемости разработки:

• Средний объем документации: 25–40 страниц (включая BPMN-схемы и описание API). Это уровень детализации, который сводит к минимуму риск ошибки при реализации.
• Экономия бюджета: наличие ТЗ сокращает расходы на непредвиденные правки на 30%. Вы платите за проектирование сейчас, чтобы не переплачивать за переделки потом.
• Глубина проработки: в ТЗ мы описываем минимум 12 ключевых разделов — от ролей пользователей до нефункциональных требований к нагрузке и безопасности.

Как у нас организовано общение с клиентом перед началом проекта

Со всеми клиентами мы общаемся по одной и той же схеме, независимо от их сферы деятельности.

В первую очередь проводим созвон на полчаса-час, где клиент в свободной форме рассказывает о своем видении продукта и требованиях к нему. Наш сотрудник заполняет бриф по единой форме, то есть мы сразу задаем все самые важные вопросы.

Вот как могут выглядеть ответы:

Заполненный бриф автоматически сохраняется в нашей системе, оповещение о нем приходит другим сотрудникам через чат. Специалист, который созванивался с клиентом, обсуждает бриф с коллегами. Мы собираем список уточняющих вопросов, которые зададим клиенту в письменной форме.

Составляем смету и презентацию, где показываем клиенту важность технического задания как первого этапа работы по проекту. В смете отражаем цену предстоящих работ в диапазоне «от и до», фиксирована только стоимость ТЗ.

После утверждения первичной сметы пишем ТЗ. Оно нужно не только для того, чтобы сделать проект правильно, но и чтобы верно оценить проект и не потерять деньги. На создание ТЗ уходит примерно месяц, клиент оплачивает нам эту работу.

Наконец, мы проводим переоценку проекта. Это необходимо потому, что почти всегда в ТЗ оказывается больше задач, чем было в первоначальном брифе: клиенты часто не замечают деталей привычных процессов. Финальная цена не должна быть выше отметки «до» из первоначальной сметы.

Наша цель — по максимуму раскрыть клиента. Получить от него намного больше информации, чем он мог бы сам рассказать по электронной почте. Ниже примеры того, как это у нас получается.

Клиент пришел с непродуманной идеей предложения, в которой не уточнил ни функционал, ни ЦА, — зато сказал, что хочет ИИ:

Вот как мы ответили:

Иногда бывает, что идея продумана лишь частично. Из предложенной информации нам понятно, что хочет клиент, — но непонятно зачем. Запросы этого типа часто формулируют таким образом: «Сделайте такой же сайт/сервис, как у Х (ЦА и нагрузка не определены)», «Вот ТЗ, функционала на 3–5 месяцев работы, гипотезу не тестировали», «Хотим вот такую штуку, способов монетизации не придумали».

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

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

Редко, но случается такое, что на этапе брифования мы видим — клиенту не особо нужен продукт, который он собирался у нас заказать. Не все пожелания можно «докрутить» так, чтобы получилось сначала четкое ТЗ, потом рабочая система или приложение.

Например, человек заявляет, что хочет программу, через которую будет продавать саженцы вишни. Мы спрашиваем, зачем ему это, как он будет монетизировать продукт. Он отвечает: «Пока не знаю. Мне нравится вишня, хочу увеличить ее популяцию в мире». Возможно, мы отговорим такого клиента от заказа. Потому что, если возьмемся за работу, будет высок риск того, что зря потратим свои и чужие ресурсы.

Очень деликатный момент — как понять, насколько серьезны намерения клиента и до какой степени он готов вовлекаться в проект. Мы полагаемся на свою насмотренность, задаем клиенту вопросы и мониторим спрос, то есть изучаем, какие похожие решения уже есть на рынке и как они сделаны.

Мы пробовали добавлять в бриф графу «Насколько вы будете вовлечены в проект?». По нашему опыту, отдача от нее нулевая. Одни клиенты удивляются: зачем им сильно вовлекаться? Они ведь платят нам, значит, мы должны полностью контролировать процесс. Другие отвечают, что готовы вовлекаться, а по факту оказывается, что нет. Мы пришли к выводу, что лучше спрашивать, какой сотрудник в команде клиента за что отвечает. Когда у нас возникнут вопросы по продукту, мы будем знать, к кому точечно обратиться.

1-3 ч

время на первый подробный бриф

1 мес

средний срок разработки ТЗ

0₽

стоимость предварительной сметы

Fix

фиксированная цена ТЗ

На пресейлах мы тратим на первый подробный бриф от часа до трех, чтобы точнее просчитать смету. Если это уже не первое касание с клиентом, достаточно еще 1–2 встреч, чтобы прояснить детали, которые не были понятны сначала. Если мы уже работаем над проектом, собрать дополнительную информацию можем без брифа, в процессе.

Как мы работаем: специализация и стандарты WAPP

Эти 30 страниц ТЗ — не «вода», а фундамент. Мы не просто описываем кнопки, а выстраиваем логику по стандартам (IEEE, BPMN 2.0), чтобы разработка была предсказуемой. Вот на чем держится наша специализация:

• Никакой двусмысленности: мы рисуем схемы бизнес-процессов так, чтобы их понял и заказчик, и разработчик. Это исключает ситуацию, когда программист понял задачу «по-своему» и сделал не то.
• Безопасность и право: сначала подписываем NDA, потом обсуждаем детали. Все наработки хранятся в защищенном контуре, а права на них юридически закреплены за вами.
• Техническая квалификация: каждое ТЗ проверяет техлид. Мы заранее закладываем возможность масштабирования, чтобы при росте нагрузки приложение не пришлось переписывать с нуля.
• Проверка на прочность: мы ориентируемся на стандарты OWASP. Это значит, что защита от взломов и утечек данных прописывается еще на этапе проектирования, а не «когда-нибудь потом».

Вам не нужно быть технарем, чтобы с нами работать. Достаточно рассказать о бизнесе, а мы переведем это на язык системных требований.

Эти 30 страниц — не «вода», а фундамент будущего продукта. Чтобы разработка шла предсказуемо, в состав профессионального ТЗ мы обязательно включаем четыре критических блока:

• Функциональные требования: подробное описание того, что именно должна делать система и как она реагирует на действия пользователя.
• Нефункциональные требования: описание параметров надежности — безопасности данных, скорости отклика интерфейса и возможности масштабирования при росте нагрузки.
• Use Cases (сценарии использования): пошаговое описание путей пользователя, которое позволяет исключить логические ошибки еще на этапе проектирования.
• Интеграционную схему: техническое описание того, как продукт будет обмениваться данными с внешними сервисами (CRM, платежными шлюзами или службами доставки).

Почему мы пишем ТЗ сами

Преимущество нашей компании в том, что к нам не обязательно приходить с готовым ТЗ. Мы можем сами составить его на основе словесного описания продукта, у нас предусмотрена такая отдельная услуга.

Если ТЗ составляем мы, это позволяет нам с самого начала лучше уловить суть продукта, продумать его логику и конкурентные преимущества, а также разглядеть нюансы, которые, возможно, не заметил клиент. Заказчикам не обязательно разбираться в процессах разработки. Достаточно поделиться с нами своими пожеланиями в любом формате, а мы разовьем хотелки в полноценное ТЗ.

Например, однажды мы составили ТЗ на 30 страниц и подробные схемы процессов, отталкиваясь только от созвона с заказчиком и полученной от него картинки:

Хорошо, если клиент может добавить к описанию скриншоты. Это поможет нам составить первичную схему продукта и посмотреть, что в него можно добавить. Мы соберём скриншоты в мудборд и передадим техническому писателю вместе с текстовым описанием. Вот как может выглядеть мудборд:

Вот финальная схема:

Иногда клиенты думают, что приходят к нам с ТЗ. На самом деле они приносят список первоначальных требований к продукту. Рассказывают, какие функции должно выполнять приложение, которое они хотят заказать, и какие фичи нужно в него встроить. Так тоже можно: мы сами разовьем полученную информацию в формат ТЗ.

Бывает, что клиент приходит совсем с минимумом конкретики, даже без требований. Например, просит сделать «как в Авито». И это, поверьте, очень частый запрос! Однако если что-то выглядит как Авито, дышит как Авито и передвигается как Авито — еще не факт, что это Авито.

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

Случается и другая крайность: клиент приносит ТЗ на 70 страниц. Мы его тщательно изучаем, готовим список вопросов и проясняем их на созвоне. Уходим считать смету, встречаемся на втором созвоне-презентации.

Прозрачная смета на разработку ПО: как ТЗ защищает бюджет

Мы частично автоматизировали ряд процессов при составлении сметы, например создали две полезные таблицы. Первую сделали для подсчета смет. Она считает часы работы и показывает в процентном соотношении, сколько времени уйдет на каждую задачу. Вторую применяем для расчетов часто используемых модулей. По опыту мы заметили, что многим проектам нужны одни и те же функции, и собрали их в один файл.

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

Когда все исходные данные становятся понятны, мы рассчитываем не ориентировочную стоимость продукта, а диапазон. Сообщаем клиенту: «Результат будет стоить не меньше, чем столько-то, и не больше, чем столько-то».

Чтобы сократить расходы клиенту, мы можем предложить более бюджетную версию продукта. Составим отдельную смету для каждой версии. Объясним, чем отличается функционал более простой версии и как можно его апгрейдить в будущем.

В процессе обсуждения продукта мы подскажем клиенту, как оптимизировать его функционал. В этом особенно силен Максим, основатель нашей студии. Он настоящая ходячая энциклопедия, готов бесплатно делиться ценной информацией с заказчиками. Например, запросто может подсказать, как подключать кассы и платежные системы или прямо во время созвона, с ходу сформулировать бизнес-идею.

В среднем с момента первого брифа до дня подписания контракта с клиентом проходит около месяца. Но это не потому, что мы медленно работаем. Мы убеждены: лучше сначала потратить время на подробное обсуждение, чем потом переплачивать за доработки и исправления. Выгода нашего подхода очевидна для клиента.

Прозрачная смета и коэффициент рисков

Диапазон цен в нашей смете — это не неопределенность, а обоснованная математическая модель. Обычно разница между «от» и «до» составляет 15–20%.

Это стандартный коэффициент рисков для ИТ-проектов, который учитывает:

• Отсутствие жесткой фиксации API сторонних сервисов на старте.
• Возможные уточнения бизнес-логики в процессе проектирования.
• Технические нюансы интеграций с CRM или платежными системами.

Наличие подробного ТЗ позволяет сузить этот диапазон до минимума и зафиксировать финальную стоимость разработки.

Почему нам доверяют: стандарты и практика WAPP

Проектирование в WAPP — это не просто творческий процесс, а работа по строгим отраслевым стандартам, которые дают предсказуемый результат:

• Методология: мы опираемся на международные стандарты (такие как IEEE 29148-2018), что обеспечивает полноту, непротиворечивость и проверяемость каждого требования в ТЗ.
• Визуализация процессов: схемы бизнес-логики разрабатываются в профессиональной нотации BPMN 2.0. Это исключает двоякую трактовку задач разработчиками и позволяет клиенту наглядно увидеть «путь пользователя» до начала кодинга.
• Безопасность и конфиденциальность: работа над проектом начинается только после подписания NDA. Все данные и технические решения хранятся в защищенном корпоративном пространстве с разграничением прав доступа.
• Профессиональная команда: каждое ТЗ проходит внутренний аудит техлида. Мы проектируем решения с учетом будущих нагрузок (scalability) и стандартов безопасности (OWASP), чтобы архитектуру продукта не пришлось переделывать при росте базы пользователей.