«Сделайте сайт, который будет приносить 10 баксов в день» — с такой просьбой к нам пришел клиент, когда Purrweb, компании по разработке MVP, еще не было, а наши пуррбоссы, Саша и Антон, работали как кооператив фрилансеров. Больше деталей не было. И, знаете, иногда такой запрос лучше, чем ТЗ на 75 страниц.
Сегодня рассказываю о том, как правильно подготовить заявку на разработку сайта/приложения в студию. А именно, о том, как сделать так, чтобы человек по ту сторону электронного ящика четко понял, что вам нужно и вернулся с чем-то полезным.
ЧТО и ЗАЧЕМ вместо КАК
Если долго вынашивать концепт приложения и досконально продумывать сценарии его использования, сама бизнес-идея начинает казаться очевидной. Позади куча дискуссий с женой и друзьями, продукт на сто раз прокручен в голове и уже приобрел четкие очертания. Зная концепцию от и до, многие в момент написания заявки на разработку сайта/приложения пропускают whole-picture уровень и начинают перечислять функционал, полагая, что фичи — это и есть контекст. На деле, это не так.
Как-то раз нам прилетела вот такая заявка:
Казалось бы, клиент навалил кучу подробностей: рассказал про функционал (отправка текста, модерация — вот это все), сориентировал по цветам. Но стоп, вам понятно для чего это нужно? A какие будут сценарии использования? Зачем человек отправляет сообщение? С какой целью текст должен выводиться на табло и для кого? Что за табло: на футбольном матче, в бегущей строке автобуса или на билборде возле остановки?
На деле, фичи и цвета не помогают ответить на самый главный вопрос: что за продукт и зачем он нужен пользователям и бизнесу? Чтобы студия могла предложить подходящее решение и предоставить максимально близкую к реальности оценку, важно видеть картину в целом, а не список фичей и требований в вакууме.
Живые сценарии использования (что и зачем) > Функционал и желаемые цвета (как)
Как описывать КАК
Если уже есть четкое представление будущего продукта и ну очень-очень хочется описать КАК в заявке на разработку сайта/приложения, идеальный вариант — ссылаться на другие продукты или конкурентов.
Хочу виртуальную карту, как в Яндекс.Деньги. Механику фильтрации, как у Авито. Бронирование, как у AirBnB, а дизайн в стиле HeadSpace
Требования по фичам важны, но не критичны. Что критично для заявки на разработку сайта/приложения, так это донести бизнес-задачу — как в том примере с проектом на 10 баксов в день. Вряд ли кто-то возьмется за проект с таким требованием и придумает за клиента продукт с нуля (хотя кто знает). Пример утрированный, но очень иллюстративный — есть понятная бизнес-цель, а то, как именно лучше реализовать функционал, студия сможет посоветовать сама. Разумеется, после того, как вы сообщите о бизнес-целях, ограничениях и болях, которые продукт должен закрывать.
ТЗ иметь не обязательно
Иногда в заявке на разработку сайта или приложения нам прилетают ТЗ на 40+ страниц с детальными требованиями ко всему, что только возможно: к эргономике, технической эстетике, защите информации от несанкционированного доступа и тд. Как правило, такие документы составлены сухо — перечисление требований и ноль контекста.
Поэтому на начальном этапе вам нужно подготовить не ТЗ, описывающее, как программистам делать приложение, а документ для менеджера студии, отвечающий на вопрос «Зачем и для кого мы делаем это приложение?» Такой документ может называться Business Requirements Document (BRD). Идеально, если получится уложиться в 2 страницы.
Бывает, что наличие ТЗ важно для бухгалтерии, чтобы бухгалтер мог подтвердить расход на найм студии разработки. При таком сценарии мы можем создать документ в процессе работы, например, на этапе дизайна. А еще мы слышали, от друзей наших друзей, что некоторые студии готовы подписать ТЗ задним числом и это тоже норм 🙂
Сначала бизнес-требования, потом требования к реализации
Про деньги
Клиенты часто боятся огласить бюджет в заявке на разработку сайта или приложения. По большей части это происходит из-за того, что они видят в этом противостояние и торги — «Я вам скажу сколько у меня денег и вы накрутите цену!» Это хорошая позиция. Для турецкого рынка. В мире разработки все устроено чуть сложнее.
Как сэкономить время на выборе подрядчика? На берегу открыто сообщить об ожиданиях по бюджету — вот прям в самом первом письме. У такого подхода два жирных плюса:
- Если студия работает в другом ценовом сегменте → сэкономите время на емейлах и созвонах с исполнителями → быстрее найдете подходящий вариант.
- Менеджер предложит вариант решения вашей задачи попадающий в ожидаемую сумму.
Разработка софта — кто бы что ни говорил, это и про креатив в том числе. Любая фича может быть реализована разными способами. Например, вы хотите добавить в приложение real-time чатик. Оценить такой функционал можно по-разному:
- C финтифлюшками: с возможностью отслеживать, когда человек печатает; когда прочел; ставить даты и удалять/редактировать сообщения.
- Без финтифлюшек: просто real-time чат, который, тем не менее, свою основную задачу будет выполнять.
Это же правило работает и для дизайна: размер бюджета ориентирует по наличию сложных анимаций, переходов и кастомных иллюстраций.
Не понимать, сколько может стоить разработка, и ходить по рынку, чтобы прицениться — это нормально. Держите пример из жизни:
Когда у меня возникла задача напечатать книгу в одном экземпляре, я не знала рыночных цен на типографию. Допускала, что это может стоить как 4 тысячи, так и 20 тысяч. Я для себя решила, что готова потратить 8 тысяч. Чтобы разом отсеять предложения за 20К, я указала бюджет в письме и разослала его в местные типографии. В итоге я собрала круг ребят, которые могли сделать работу, не вылезая за рамки бюджета: одни предлагали заменить твердую обложку на мягкую, другие посоветовали более бюджетную бумагу. Ожидания по затратам были оправданы, а задача закрыта.
Печать книги в типографии или разработка бизнес-идеи — понимание того, сколько ты готов в это дело инвестировать, есть всегда. Главное — поделиться собственными ожиданиями. Тогда студия предложит вам оптимальную «твердость обложки» вашего продукта.
Обсудить бюджет со студией — это сотрудничество, а не противостояние
Есть заполненный бриф, сгодится?
Студии часто предлагают заполнить бриф. Практика хорошая: заполняя полотно вопросов, клиент уже сам для себя может разложить проект по полочкам. Например, задуматься о тех аспектах проекта, которые мог упустить ранее. Может нужен оффлайн режим? Все ли роли пользователей учли: админ, может модератор, отдельный интерфейс для менеджера поддержки?
Заполнять брифы очень даже полезно. А вот рассылать бриф, заполненный для одной студии, по другим — идея не очень-то хорошая. Так однажды обжегся один из наших клиентов:
В первом письме он прислал нам бриф, который ранее заполнял для другой студии. Клиенту нужно было функциональное веб-приложение по типу Airbnb. Студия, которая ранее кидала ему бриф, специализировалась на простых многостраничниках. Что мы получили? Описание проекта с тонной пометок по цветовой гамме, разверстке страниц, флеш-анимациям.
В будущем нам тоже понадобятся цвета, но на этапе оценки разработки приложения, есть более весомые вещи, которые нужно продумать на старте: пользовательские сценарии, серверная логика, интеграции. Зачем обсуждать разверстку страницы, когда еще даже нет гипотез по монетизации приложения?
Это все равно, что думать о покупке купальника для отпуска, на деньги с зарплаты, которую вы получите на работе, на которую еще даже не устроились.
Поэтому такой бриф мало поможет менеджеру студии разработки вернуться к вам с внятным ответом. Зато первоначальная студия по этому брифу подготовит классную и точную оценку на создание посадочной страницы. Но это ведь не то, за чем вы сейчас пришли, верно?
Даже если вы присылаете заполненный бриф профильной студии, нужно учитывать, что у студий может быть разный подход, разная специализация или просто плохо составлен бриф. В таком случае ваше собственное описание проекта в гугл доке будет помогать больше, чем заполненный вами же чужой бриф.
Будьте готовы к созвонам
«Я написал понятную заявку, а студии все равно пушат на созвон»
Предположим, что вы и так все это уже делаете. Погружаете в концепцию будущего продукта, открыто говорите об ожиданиях по деньгам. Этим самым вы уже сэкономили время на созвоны и встречи + влюбили в себя менеджера 🙂
В Purrweb мы считаем, что коммуникация — это тоже инвестиции в проект. Уже во время поисков подходящей команды придется вкладывать время в общение. Если вы не готовы уделить пару часов в день на коммуникацию с потенциальными подрядчиками уже на этом этапе, то стоит задуматься, откуда вы будете брать время и силы в будущем.
Мы уже обсуждали огромные ТЗ, которые приходят в первой заявке на разработку сайта/приложения. Если быть честным, студия не станет инвестировать время в разбор 38 страниц, пока не пообщается с вами лично.
Я понимаю, что рассказывать шести студиям одно и тоже может быть утомительно. Но ваша задача на этом этапе — понять, насколько комфортно общаться с ребятами, на одной ли вы волне. Вы сможете пережить, если кассирша в Пятерочке раздражает вас одним своим видом. Но студия ваш долгосрочный партнер, и вы вправе отсеять всех, кто не понравился вам при личном общении. Самый просто способ это выяснить — поговорить вживую (голосом, а еще лучше с камерой).
В заявке сообщите, в какое время вы доступны для звонка, укажите контакты и удобный канал для связи
Живые люди — живой язык
И последнее. Когда мы с друзьями пишемся в каком-нибудь Telegram-чатике, коммуникативные навыки всегда на пике: это общение по существу и на понятном языке. По какой-то странной причине все это начинает скатываться в трубу, как только речь заходит о деньгах и бизнесе: простота теряется, а текст превращается в нечто сложное и запутанное.
Прятать контекст за трехэтажными, витиеватыми словами — это не ключ к плодотворному сотрудничеству. Это лишняя мишура, которая помешает команде въехать в суть и понять, как вам помочь. Как этого избежать? Общаться просто — вот прям на старте. Вы прекрасно справляетесь с этим дома и на работе. Поверьте, справитесь и здесь.
Пишите как говорите
