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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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