В примере выше полностью отсутствует описание проекта. От слова совсем. Есть ссылка на сайт «Вот сайт: недвижимостьвсегомира.рф», мол, хотите — переходите на него и сразу все поймете.

1. Обязательно нужно сопроводить ссылку на проект двумя-тремя предложениями, которые дадут понимание того, чем занимается ваша компания. Тем самым вы уже демонстрируете заботу о разработчике и экономите ему время.
   Ему не требуется ползать по сайту, чтобы понять, кто вы на рынке недвижимости. Агрегатор? Доска объявлений? Ипотечный брокер?
   Например, Некидаем рф: Только сложная веб-разработка. Спасаем проекты и людей от недобросовестных веб-разработчиков.
   И всем сразу понятно, что мы не делаем сайты и лендинги совсем. А при возникновении проблем в веб-разработке, конфликта с текущими исполнителями нужно как можно быстрее обратиться к нам.
   
2. Нет конкретики в описании задач: «Мне нужно сделать вход, смотреть за заявками, сделать базу, видную только своим, и какой-нибудь чатик. Еще было бы неплохо сделать модуль, чтобы получать выписки онлайн, сразу же.».
   
   Описание не развернуто, оно понятно только клиенту. При чтении сразу возникает масса уточняющих вопросов:— — Ход чего?
   — Смотреть кому и за какими заявками?
   — Что должно быть в базе и кто такие «свои»? Каковы их роли и права доступа к базе?
   — Для кого должен быть реализован чат?
   — Требования к функционалу чата (возможность приложить и отправить файл, поиск по истории, пересылка сообщений, возможность добавлять в черный список, создавать группы, создавать рассылки)?
   
3. «Еще было бы неплохо сделать модуль, чтобы получать выписки онлайн, сразу же.» — правда ведь, каждому понятно, что речь идет об электронных выписках из государственного реестра на участвующие в сделках квартиры с использованием усиленной квалифицированной электронно-цифровой подписи? :-)
   
   Друзья, не ленимся. И ценим время — и свое, и разработчиков.
   В конечном счете размыто сформулированный вопрос приведет к затратам на дополнительные итерации: дополнительные вопросы — разъясняющие ответы — новые вопросы — и хорошо, если быстрые, в этот же день ответы.
   Лучше поработать подольше над запросом веб-разработчикам, чем потом бесконечно дергать себя самого, отвечая на уточняющие вопросы.
   Выделите себе сразу 2 часа, чтобы максимально полно описать проект и текущие задачи/трудности, задать качественные вопросы.
   Запрос на коленке отправлять не стоит. Для исполнителя — это признак нежелания со стороны клиента вдумчиво работать над своим же собственным проектом.
   
4. Вопрос коммуникации всегда не менее острый.
   Ранее мы уже говорили о том, как важен для успеха проекта отлаженный механизм коммуникации.
   Сегодня еще несколько слов на эту тему.
   «Можно обсудить голосом, сегодня в 17:00 у меня есть время, скайп: «корольнедвижимости» — этот пункт требует особого внимания.
   Весьма редко есть время оценить проект в день обращения клиента. Даже если такая возможность есть, могут быть дела и заранее запланированные встречи с другими клиентами.
   Например, у нас расписание общения с клиентами составлено на 2-4 дня вперед.
   То же касательно канала связи — предлагается скайп.
5. Предлагать только один канал связи — моветон. По каким-либо причинам он может быть неудобен второй стороне переговоров.
   Более того, помимо скайпа клиент не оставил никакой возможности быстро связаться с ним по телефону или через какой-либо мессенджер, если телефон такая уж секретная информация.
   Для чего нужен телефон или другой, более быстрый, канал связи?
   Если у команды сегодня появляется «окошко» не в 17:00, а в 16:30, то мы можем оперативно позвонить клиенту и предложить провести первичную консультацию в скайпе, задав необходимые уточняющие вопросы.
   
   Зачастую бывает так: пишем клиенту в обед, что в 16:30 у нас есть час, который мы готовы зарезервировать под общение с ним. В районе 23:00 клиент отвечает в том же скайпе: извините, сообщение не увидел, и парадокс — вновь в том же самом скайпе предлагает связаться, но уже завтра в 12:00.
   В таком разорванном режиме вопросов и ответов только о времени первичного общения можно договариваться 3-4 рабочих дня!
   
   Вместо этого клиенту следовало оставить другой способ связи, например, ник в Telegram, где о переговорах можно договориться в режиме реального времени, убрав пропуски по нескольку часов в ответах.
   Безусловно, в первую очередь мы предложим освободившееся «окошко» времени тому клиенту, у которого более-менее понятно описаны задачи и который не постеснялся указать быстрый способ связи с собой. Значит, человек более заинтересован в общении с нами, раз не поленился подумать и предугадать необходимость альтернативного способа связи.
   Как говорится, кто успел, того и тапки :-)
   
6. И еще один нюанс.
   Вы договорились с разработчиком, к примеру, на 17:00 в скайпе. Вы онлайн, а его нет. Прождали полчаса-час — тишина. А спустя еще 2 часа вам приходит сообщение: «Добрый день, мы в скайпе, начинаем?»
   Догадались в чем проблема? Клиент определил время связи, но не указал часовой пояс.
   
   Поэтому умнее и тактичнее предлагать общение разработчикам следующим образом:
   «Если у вас есть вопросы, предлагаю связаться по скайпу сегодня в 17:00 по Мск, завтра в 16:00 по Мск или послезавтра в утреннее время с 09:30 до 12 дня по Мск.
   Вы успеете ознакомиться с моим проектом? Какое время более удобно?
   Мой ник: «корольнедвижимости», а вот мой телефон для оперативной связи, если будет такая необходимость. Удобнее решать вопросы в переписке в WhatsApp и Telegram.»

Выделите 2 часа, чтобы подробно описать задачи проекта, текущие трудности, срочные задачи, свои пожелания, конфликты с текущими исполнителями, если они возникли, и т.д. Не пренебрегайте деталями. И обязательно разъясните в 2-3 предложениях, в чем суть вашего бизнеса!

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

Помните, что текста много не бывает. Если сомневаетесь, стоит ли писать о чем-либо, если вам кажется, что это очевидная всем мелочь, — пишите. Обязательно пишите. Нет ничего важнее мелочей!

Приводим примеры того, как вполне конкретный человек пользуется вашим товаром или услугой — это называется use-case или пользовательский кейс.

Разъясняем разработчикам на примере use-case: какая потребность у человека есть, как он получает товар/услугу, что с ней делает, что является результатом его взаимодействия с вашим товаром/услугой. Ошибочно полагать, что разработчику не нужно знать о том, как работает ваш продукт или услуга. Ведь именно то, как она работает, и отражает функционал вашего сайта в глазах вашего же клиента.

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

Предлагайте несколько временных промежутков для связи, указывайте часовой пояс. (Например, в 17:00 по Мск.) Уточняем, удобно ли?

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

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

Вы максимально быстро получите исчерпывающую обратную связь от разработчиков и приглашение на первичную консультацию.

Желаем только завершенных проектов!