Сегодня рассказываю, что нужно писать в заявке на разработку, чтобы потенциальный исполнитель четко понимал, что именно вам нужно и смог предложить что-то действительно полезное.
— Вместо как делать, лучше ответить зачем и для кого нужно делать
— Наглядные примеры
— Подробное ТЗ нужно, но попозже — как минимум после первого созвона
— Разговор вживую
— Кочующий бриф
— Роль бюджета в заявке
Ориентир — простое человеческое общение
Вместо как делать, лучше ответить зачем и для кого нужно делать
Тщательно разработав концепцию приложения/сайта и продумав сценарий его использования, бизнес-идея становится явной как никогда, а продукт обретает четкие очертания в вашей голове. Однако, при написании заявки на разработку сайта или приложения, многие зная концепцию своего продукта, часто упускают важный аспект и говорят только о функциональных возможностях, полагая, что они достаточны для описания всей концепции.
Чем чаще вы сталкиваетесь с тем, с чем живете каждый день, тем чаще эти вещи будут вам очевидны и максимально не очевидны другим.
К нам часто приходят вот такие заявки:
Перечисление функционала/дизайна не дает полного ответа на основные вопросы: какова цель продукта, как и кому он будет полезен? Чтобы команда профессиональных разработчиков могла предложить наиболее эффективный в ваших обстоятельствах вариант реализации и составить реалистичную оценку проекта, важно рассматривать его в контексте всей картины, а не только с точки зрения списка функций и требований.
Наглядные примеры
Если хотите описать как в заявке на разработку, лучше всего ссылаться на другие продукты или конкурентов.
Для заявки на разработку сайта или приложения важно указать желаемый функционал, но недостаточно. Наиболее важно для команды разработчиков услышать бизнес-задачу (которую необходимо решить) и ваши обстоятельства (предысторию и бюджет). В случае выше, где требовалось разработать выдающийся проект путем повышения конверсии и трафика, маловероятно что кто-то примется за разработку с такими ограничениями и создаст продукт с нуля.
Имея ясное представление о бизнес-цели, как именно функциональность должна быть реализована, сможет посоветовать разработчик. Конечно, это будет происходить после того, как вы укажете цели, боли и проблемы, которые продукт должен решать.
Подробное ТЗ нужно, но попозже — как минимум после первого созвона
Часто приложенные к заявке ТЗ на десятки страниц содержат описание чего угодно, но только не контекста: много умных слов о технологиях, фичах и требованиях, но ни строчки для кого делается проект и какую проблему решает.
На начальном этапе стоит подготовить документ на 2-3 страницах, называется бизнес-требования, содержащий ответы на ключевые вопросы: что мы делаем, для чего мы это делаем, какие предпосылки, зачем и для кого мы это делаем? А не описание как команда программистов и дизайнеров делает проект.
Разговор вживую
Проекты, где много контекста, без разговора двух людей очень сложно начать.
Заполняя форму заявки на сайте или подготавливая текст для отправки в чат/на имейл разработчикам, рекомендуем указать контакты и удобный канал для связи.
На этапе созвона (например, видеозвонок в Zoom), вы поймете, насколько приятно общаться с командой, есть ли общий язык между вами.
Если быть откровенным, скорее всего для IT-компании бесполезно тратить время на изучение нескольких десятков страниц ТЗ без беседы вживую.
Почти всегда на первой zoom-встрече мы предлагаем свои решения, обсуждаем, ищем наилучшие практики, которые подходят. Учитываем и бюджет, и маркетинг. Глубокое погружение в то, что нужно сделать, предлагая яркие примеры.
Кирилл Гришанин
Основатель WB—Tech
Кочующий бриф
Заполнив бриф от одной студии, не стоит его рассылать другим IT-компаниям в качестве заявки. Брифы составлены под специфику каждой компании отдельно. И велика вероятность, что проект по чужому опроснику будет понят и оценен неверно.
Часто бывает клиент заказал research в одном месте, а потом присылает это на разработку другой команде. И все. Контекст потерялся — ничего не понятно. Может это все исследование и не нужно.
Например, в WB—Tech мы не предлагаем заполнять формы/анкеты/брифы, так как предприниматели люди тоже творческие и зачастую их такое только может отпугнуть. Опрос у нас происходит в устной форме при созвоне, где мы сами фиксируем как проект будет осуществлен и далее ставим соответствующие задачи для специалистов.
Роль бюджета в заявке
Как правило, заказчики не сообщают свой бюджет при подаче заявки на разработку сайта или приложения. Но эта угадай-ка никому не нужна. Лучше сразу говорить на что вы готовы, и тогда вам предложат эффективный путь в рамках этого бюджета.
Плюсом такой открытости будет экономия времени на многочисленных электронных письмах и звонках с потенциальными исполнителями, если они работают в другом ценовом диапазоне. Таким образом, вы быстрее найдете подходящий вариант.
В WB—Tech ценообразование на разработку обосновано ставкой в час за работу команды.
Создание веб-продуктов — это не только технический процесс, но и творческий, когда каждую задачу можно решить по-разному. Например, как-то к нам пришел клиент (клининговая компания) с заявкой на разработку мобильного приложения. Что само собой подразумевает немалый бюджет. Мы им предложили реализацию бизнес-задач через low-code решение, что стоило в 1000 раз меньше. Этот модуль у них проработал спокойно 2 года, пока масштабы компании не доросли до отраслевого решения.
Правило применимо и к заявке на дизайн: указали бюджет — исполнитель сориентирует по дизайн-вариантам, анимации и иллюстрациям.
Если все же бюджет не был указан в заявке, и мы понимаем, что задача конечна, то можем назвать стоимость за проект. Но если по заявке невозможно определить какой объем труда потребуется, например, когда проект уже существует и нет никакой документации о его работе, не известно качество кода и покрытие тестами, к тому же нет связи с предыдущей командой — стоимость разработки назвать сложно. И тогда мы предлагаем сделать аудит, чтобы выяснить качество продукта, с которым предстоит работать.
Ориентир — простое человеческое общение
Когда вы объясняете свою бизнес-идею жене на кухне, другу при встрече или коллеге из другой компании, вы используете простые описания, избегая витиеватого профессионального сленга. Со студией также — пишите просто и прямо о проекте и бюджетах с самого начала общения. Это позволит команде быстрее войти в контекст и понять, как они могут вам помочь.
Если хотите обсудить ваш web-проект, напишите нам. За 10 лет мы запустили 40 сложных программных продуктов для частных инвесторов, крупных бизнесов и государственных организаций. Поможем и вам 🙂
