A можно без ТЗ? Пишем идеальную заявку в студию разработки

«Сделайте сайт, который будет приносить 10 баксов в день» — с такой просьбой к нам пришел клиент, когда Purrweb еще не было, а наши пуррбоссы, Саша и Антон, работали как кооператив фрилансеров. Больше деталей не было. И, знаете, иногда такой запрос лучше, чем ТЗ на 75 страниц.

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

Поехали.

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

Как-то раз нам прилетела вот такая заявка:

Казалось бы, клиент навалил кучу подробностей: рассказал про функционал (отправка текста, модерация — вот это все), сориентировал по цветам. Но стоп, вам понятно для чего это нужно? A какие будут сценарии использования? Зачем человек отправляет сообщение? С какой целью текст должен выводиться на табло и для кого? Что за табло: на футбольном матче, в бегущей строке автобуса или на билборде возле остановки?

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

Если уже есть четкое представление будущего продукта и ну очень-очень хочется описать КАК, идеальный вариант — ссылаться на другие продукты или конкурентов.

Требования по фичам важны, но не критичны. Критично донести бизнес-задачу — как в том примере с проектом на 10 баксов в день. Вряд ли кто-то возьмется за проект с таким требованием и придумает за клиента продукт с нуля (хотя кто знает).

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

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

Поэтому на начальном этапе вам нужно подготовить не ТЗ, описывающее, как программистам делать приложение, а документ для менеджера студии, отвечающий на вопрос «Зачем и для кого мы делаем это приложение?» Если уложитесь в 2 страницы — идеально.

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

Клиенты часто боятся оглашать бюджет, потому что видят в этом противостояние и торги — «Я вам скажу сколько у меня денег и вы накрутите цену!» Это хорошая позиция. Для турецкого рынка. В мире разработки все устроено чуть сложнее.

Как сэкономить время на выборе подрядчика? На берегу открыто сообщить об ожиданиях по бюджету — вот прям в самом первом письме. У такого подхода два жирных плюса:

1. Если студия работает в другом ценовом сегменте → сэкономите время на емейлах и созвонах с исполнителями → быстрее найдете подходящий вариант
2. Менеджер предложит вариант решения вашей задачи попадающий в ожидаемую сумму
   

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

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

• без финтифлюшек: просто real-time чат, который, тем не менее, свою основную задачу будет выполнять.

Это же правило работает и для дизайна: отталкиваясь от размера бюджета, принимаются решения по внедрению сложных анимаций, добавлению сложных переходов и кастомных иллюстраций.

Не понимать, сколько может стоить разработка, и ходить по рынку, чтобы прицениться — это нормально. Держите пример из жизни:

Когда у меня возникла задача напечатать книгу в одном экземпляре, я не знала рыночных цен на типографию. Допускала, что это может стоить как 4 тысячи так и 20 тысяч. Я для себя решила, что готова потратить 8 тысяч. Чтобы разом отсеять предложения за 20К, я указала бюджет в письме и разослала его в местные типографии.

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

Печать книги в типографии или разработка бизнес-идеи — понимание того, сколько ты готов в это дело инвестировать, есть всегда. Главное — поделиться собственными ожиданиями. Тогда студия предложит вам оптимальную «твердость обложки» вашего продукта.

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

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

Так однажды обжегся один из наших клиентов. В первом письме он прислал нам бриф, который ранее заполнял для другой студии. Клиенту нужно было функциональное веб-приложение по типу Airbnb. Студия, которая ранее кидала ему бриф, специализировалась на простых многостраничниках. Что мы получили? Описание проекта с тонной пометок по цветовой гамме, разверстке страниц, флеш-анимациям.

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

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

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

Предположим, что вы и так все это уже делаете. Погружаете в концепцию будущего продукта, открыто говорите об ожиданиях по деньгам. Этим самым вы уже сэкономили время на созвоны и встречи + влюбили в себя менеджера:)

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

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

Я понимаю, что рассказывать 6-ти студиям одно и тоже может быть утомительно. Но ваша задача на этом этапе — понять, насколько комфортно общаться с ребятами, на одной ли вы волне. Вы сможете пережить, если кассирша в Пятерочке раздражает вас одним своим видом. Но студия ваш долгосрочный партнер, и вы вправе отсеять всех, кто не понравился вам при личном общении. Самый просто способ это выяснить — поговорить вживую (голосом, а еще лучше с камерой).

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

Прятать контекст за трехэтажными, витиеватыми словами — это не ключ к плодотворному сотрудничеству. Это лишняя мишура, которая помешает команде въехать в суть и понять, как вам помочь. Как этого избежать? Общаться просто — вот прям на старте. Вы прекрасно справляетесь с этим дома и на работе. Поверьте, справитесь и здесь.

Да вот как-то так, пожалуй:

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

Запрос на разработку приложения — каким он должен быть?

Буду рада, если поделитесь своими мыслями и историями из жизни в комментариях.

#разработка #стартап #приложения