Заказчики хотят найти исполнителей на свои проекты, и собираются поместить информацию об этих проектах на досках объявлений онлайновых бирж. Разработчики собираются делать свои предложения на интересующие их проекты. И заказчиков, и разработчиков объединяет то, что они собираются размещать некоторые тексты, и все они заинтересованы чтобы их тексты были наиболее информативными и эффективными.
В данной статье мы рассмотрим некоторые существующие тенденции и выведем для себя рекомендации по постингу текстов запросов и предложений на разработку проектов.
Постинг проектов.
Раздел для заказчиков. В данном разделе выведем для себя ряд правил, которых желательно придерживаться при публикации объявлений на реализацию проектов.
Правило 1. Информативность запроса на разработку.
Очень часто можно встретить объявления о проектах, которые заключаются в одном предложении, например: «Нужен сайт организации» или «Нужен движок для сайта». Возможно, публикуя такое объявление заказчик экономит свое время. Но непонятно на что при этом он надеется, ведь маловероятно что кто-то из более-менее серьезных разработчиков таким объявлением заинтересуется. Максимум, напишут встречное предложение типа «Вышлите ТЗ на email». Или просто вместо текста предложения на проект впишут целиком свое резюме и портфолио. А большинство предложений от школьников и студентов младших курсов будет еще проще, и ограничится фразой: «Готов к труду» или «Сделаю».
В результате в ответ на не информативное объявление о проекте заказчик получает вовсе не то что он хочет. И ему приходится тратить намного больше времени связываясь по очереди с теми или иными потенциальными исполнителями, тратить массу времени на то, чтобы каждому рассказывать суть проекта и детали, и зачастую убеждаться что очередной исполнитель не подходит.
Конечно, нет надобности публиковать полное техническое задание в тексте объявления. Несколько абзацев достаточно. Но при этом очень желательно чтобы эти несколько абзацев высокоуровнево описывали что именно нужно заказчику и что нужно будет сделать исполнителю. Пример такого удачного с точки зрения информативности объявления:
Необходимо разработать плагин для браузеров версий IE 5+ и Firefox 1.5+ и выше.
Основные требования к плагину:
1. Добавляется в тулбар 2 кнопочки.
2. Одна кнопочка как букмарк, то есть при клике открывается заданный URL.
3. Вторая кнопочка открывает новое окно без тулбара, меню и статусбара, и передает туда URL страницы с которой был запущен плагин.
Необходимо получить:
1. Работающие варианты плагинов для указанных версий браузеров.
2. Хорошо документированные исходные тексты плагинов.
3. Краткая инструкция по установке и удалению данных плагинов.
Правило 2. Понятное изложение.
Если еще раз посмотреть на объявление о проекте в предыдущем пункте, можно заметить что с точки зрения литературного русского языка оно неидеально. Ведь в русском языке нет слов букмарк, клик, статусбар.
Но по мнению автора, в таких объявлениях этим можно и пренебречь, так как главное в данном случае — достижение цели информативности объявления. Специалисты, именно для которых это объявление и предназначено, в любом случае разберутся, причем такая форма для них вносит даже больше ясности чем те же упоминания русских терминов типа «закладки» и «ярлыки».
Например автор однажды потратил довольно много времени пытаясь понять, что от него хочет клиент в русскоязычном текстовом задании в предложении «На первой странице слева должны быть закладки и ярлыки документов». Потом оказалось что это имелось ввиду просто вертикальное меню, со ссылками на страницы и на документы для скачивания.
Хотя конечно нужно признать, что «панель инструментов» по-русски звучит намного лучше чем «тулбар», и «строка статуса» намного лучше чем «статусбар». По крайней мере это читается более естественно, соответственно лучше воспринимается и меньше отвлекает от самого проекта.
В общем, это хорошо если текст объявления написан правильным русским языком, но без литературных излишеств (то же касается и других языков, English, German, и так далее).
Правило 3. Грамотность.
Большинство онлайновых бирж проектов не позволяют изменять тексты объявлений после публикации. Поэтому желательно потратить некоторое время и убедиться что текст объявления составлен грамотно как с точки зрения написания, так и с технической стороны.
Иными словами, желательно проверить формулировки, аббревиатуры, технические термины. Ведь при наличии явных ошибок и опечаток в тексте объявления отношение к проекту и к самому заказчику будет со стороны потенциальных исполнителей менее серьезным.
Правило 4. Отсутствие избыточности.
Часто можно видеть случаи, когда в тексте объявлений о проектах заказчики указывают ясно избыточную информацию, которая и так может быть получена тем кому она нужна. Например, это касается контактной информации.
Биржи проектов могут публиковать эту контактную информацию в отдельных секциях если эта информация по правилам этих бирж доступна. Или же могут блокировать эту информацию если по установленным правилам эту информацию нельзя публиковать. В таких случаях лучше не добавлять работу модераторам, и вместо того чтобы включать контакты (Email, ICQ, телефон) в текст объявления, лучше заполнять соответствующие поля в пользовательском аккаунте.
Еще пример избыточной информации — это указание в тексте объявления суммы бюджета проекта, если эта цифра уже была указана в соответствующем поле при публикации этого объявления.
Избыточность бывает и в самом тексте постановки задачи. Например, в списке требований к разработчику иногда можно встретить длинные списки требований к исполнителям типа «HTML, DHTML, CSS, CSS3, XHTML, JavaScript, JPEG, GIF, опыт верстки». Это явно избыточно, да и немного неграмотно с технической стороны, по мнению автора можно было бы передать смысл и меньшим набором требований.
То есть общая рекомендация — желательно стараться минимизировать количество избыточной информации в текстах объявлений.
Правило 5. Дополнения к проектам.
Не всегда получается сделать идеальное объявление о проекте. Бывает, что после публикации объявлений начинают сыпаться вопросы от потенциальных исполнителей, часто эти вопросы однотипны.
В таких случаях имеет смысл публиковать дополнения к проектам, большинство онлайновых бирж это позволяют делать. К текстам дополнений применимы те же самые рекомендации, что и к текстам объявлений проектов.
Постинг предложений на разработку.
Раздел для разработчиков. В данном разделе выведем для себя ряд правил, которых желательно придерживаться при публикации предложений на реализацию проектов.
В целом, для текстов предложений на разработку применимы все те же правила что и для постинга проектов для заказчиков. То есть тут подходят те же правила «Понятное изложение», «Грамотность» и «Отсутствие избыточности». Но есть и дополнительные особенности.
Правило 1. Информативность предложения на разработку.
Разработчику нет смысла публиковать предложение на разработку проекта, если он не хочет получить этот проект. Но получается, что часть объявлений — это просто потеря времени, так как заказчики на них просто не обращают внимания. В основном это происходит потому, что такие объявления недостаточно информативны.
Очевидно, что в ответ на публикацию объявления по проекту, заказчик ожидает получить некоторый список предложений от потенциальных исполнителей. Исполнители бывают разные, и их предложения на разработку также бывают разными. И часто по самому тексту предложения на разработку заказчик уже может делать вывод о зрелости и серьезности подхода того или иного исполнителя.
Пусть разработчик поставит себя на место заказчика. Заказчик сделал объявление например на разработку сайта. Перечислил требования к проекту, указал некоторые детали, различные аспекты. Через некоторое время появляется около 20 предложений от разработчиков. Из них 2-3 информативных, остальные состоят из нескольких слов примерно следующего плана: «Будет сделано в лучшем виде!», «Пишите на email» или «Уже делал такое». Нетрудно догадаться, какие именно предложения в первую очередь привлекут внимание заказчика.
Конечно, часто заказчики сами провоцируют разработчиков на такие не информативные посты, публикуя не информативные объявления, не но следует этому уподобляться. Ведь это явно что если разработчик потратит лишние 5 минут и составит более информативный текст предложения на разработку, то его шансы получить проект вырастут в разы.
Вот пример достаточно информативных предложений разработчиков:
Профессиональная команда системных администраторов возьмет Ваши сервера на обслуживание. Большинство специалистов имеет многолетний профессиональный опыт (некоторые более 10 лет).
Гарантируется высокое качество, саппорт 24/7 все время online. Ваш сервер будет обслуживаться на том же высоком уровне, на котором обслуживаются клиенты из USA.
Цена стандартна: 150 USD в месяц за один сервер. Такая низкая цена объясняется тем, что процесс поставлен на конвейер, на обслуживании уже сотни серверов.
Или вот еще пример:
Имею опыт разработки кластерных систем, также систем с автоматической односторонней и двухсторонней репликацией, с поддержкой фоновых jobs для проверки целостности данных и архивирования, и так далее.
За последние 10 лет работал с Oracle, DB2, Informix, Interbase/Firebird, PostgreSQL и MySQL. Последний проект был специфический, с MySQL Cluster.
Для равномерного распределения нагрузки может быть использовать или готовый LoadBalancer, или свой диспетчер.
Могу предоставить ряд вариантов решения задачи, конечно для данного проекта будет выбран лучший вариант после ознакомления с ТЗ.
Правило 2. Информация о разработчике.
Для разработчика намного более важно чем для заказчика иметь максимально подробно заполненный профайл. С резюме, портфолио, указанием контактов.
Конечно, не стоит прямо писать в тексте предложения на разработку «Смотрите примеры моих работ в портфолио». Это и так понятно, заказчик обязательно в любом случае внимательно изучит все что известно о разработчике, прежде чем доверит ему проект и деньги.
Нужно помнить что по сути дела информация о разработчике, указанная в профайле, является продолжением предложения на разработку проекта. И чем полнее портфолио и профессиональнее составлено резюме, тем более весомо выглядит предложение на разработку проекта.
И, как и в случае с заказчиком, рекомендуется не указывать свои контактные данные в тексте предложений на разработку, они и так доступны заказчику в профайле. И не стоит публиковать в тексте предложений ссылки на десятки своих проектов, заказчик их и так посмотрит если они заданы в портфолио, хотя в некоторых ситуациях пара удачно подобранных ссылок может принести хороший эффект, особенно если это ссылки на статьи. В общем, не стоит допускать бессмысленной избыточности.