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

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

Не ждите от клиента готовое ТЗ

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

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

Мы не увидели в тексте продуманную идею продукта, поэтому ответили так:

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

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

Именно поэтому мы в WAPP решили брифовать клиентов и писать подробное ТЗ своими силами. Это удобно клиенту, ведь мы точнее определяем стоимость проекта и указываем вилку «от и до». И удобно нам — меньше вероятность, что в ТЗ останутся неучтенные детали.

Заполняйте бриф в диалоге с клиентом

Мы в WAPP выработали алгоритм работы, которым пользуемся на всех новых проектах. 

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

У нас в WAPP есть стандартный набор вопросов:

А это пример ответов клиента:

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

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

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

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

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

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

Сложнее, когда у заказчика совсем нет конкретики. Знаете такой мем: если что-то выглядит как утка, дышит как утка и передвигается как утка — еще не факт, что это утка? Мы его вспоминаем, когда очередной клиент просить сделать «как в Авито». Этот маркетплейс невероятно популярен в качестве референса. Однако фразу «как в Авито» можно интерпретировать тысячами разных способов.

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

Что делать с описанием проекта, которое прислал клиент

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

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

Одним из элементов мудборда может быть рабочая схема продукта:

А уже на базе рабочей схемы можно создать финальную — например, такую:

Что в итоге: если подрядчик пишет ТЗ своими силами, он глубже погружается в продукт с первых шагов

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

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