Назад

Как написать заявку на разработку сайта или приложения? Рассказываем и показываем

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

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

ЧТО и ЗАЧЕМ вместо КАК

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

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

заявка на разработкуПонятно КАК и даже ЧТО, но непонятно ЗАЧЕМ

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

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

Живые сценарии использования (что и зачем) > Функционал и желаемые цвета (как)

Как описывать КАК

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

Хочу виртуальную карту, как в Яндекс.Деньги. Механику фильтрации, как у Авито. Бронирование, как у AirBnB, а дизайн в стиле HeadSpace

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

READ MORE  Дизайн MVP: этапы, инструменты, результаты

ТЗ иметь не обязательно

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

Поэтому на начальном этапе вам нужно подготовить не ТЗ, описывающее, как программистам делать приложение, а документ для менеджера студии, отвечающий на вопрос «Зачем и для кого мы делаем это приложение?» Такой документ может называться Business Requirements Document (BRD). Идеально, если получится уложиться в 2 страницы.

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

Сначала бизнес-требования, потом требования к реализации

Про деньги

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

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

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

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

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

заявка на разработкуСлева: все прелести чата. Справа: только получение и отправка сообщений

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

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

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

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

READ MORE  Пять правил разработки медицинских приложений: опыт Purrweb
Обсудить бюджет со студией —  это сотрудничество, а не противостояние

Есть заполненный бриф, сгодится?

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

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

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

Куча требований, которые ну вот вообще не про бизнес-задачи 🙁

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

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

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

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

READ MORE  7 заповедей хорошего UX-дизайна

Будьте готовы к созвонам

«Я написал понятную заявку, а студии все равно пушат на созвон»

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

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

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

заявка на разработкуБез предварительного созвона студии вряд ли сходу возьмут такую заявку в оценку

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

В заявке сообщите, в какое время вы доступны для звонка, укажите контакты и удобный канал для связи

Живые люди — живой язык

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

заявка на разработкуСложное и запутанное — это когда перечитал два раза и все равно не въехал

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

Пишите как говорите

Как бы выглядела идеальная заявка на разработку сайта/приложения