Примерно 3 года назад скоростной Интернет только осваивал широкие просторы нашей родины и был доступен далеко не каждому, но именно тогда фриланс и удалённая работа стали активно развиваться. В это же время большинство бизнесменов из невиртуальных секторов экономики начали знакомиться с виртуальным миром: в качестве инвесторов самых разных проектов, как заказчики продуктов, являющихся логическим продолжением их бизнеса, но уже в сети. Хлынул поток фрилансеров на рынок и началось…

А началось в большинстве случаев немного кустарно. Конечно, сам термин «техническое задание» был многим известен, но он в основном не привязывался к данной ситуации. Зачем же нам ТЗ, когда мы на словах можем нормально понять друг друга, да и вообще это очередная бюрократия думали как заказчики, так и фрилансеры. И поначалу, когда проекты были несложными, разнообразия в функционале не было большого, все как-то обходились. Но после первого совместного опыта многие участники этого процесса столкнулись с первыми проблемами.

Так, работодатели столкнулись с тем, что оказывается, им сделали не тот продукт, о котором они мечтали и на который они надеялись, а часто и вовсе пришлось доплачивать за что-то, а исполнители столкнулись с тем, что проект на самом деле оказался сложнее, чем думалось вначале, пришлось что-то лишнее сделать бесплатно. На бумаге между сторонами отсутствовало чёткое описание объёма работ, в итоге ожидания ни одной из сторон не оправдались.

В отличие от большинства заказчиков, которые списывали плохой результат на непрофессионализм исполнителей, последние решили внедрять в свою работу такое «бюрократическое понятие» как техническое задание. Как первый шаг появились так называемые брифы – по сути опросные листы, которые могли содержать разный набор вопросов по теме проекта, на основе них составлялось общее понимание того, что будет. Примерно в это же время неожиданную популярность стали обретать многочисленные приложения для соц. сетей и флеш-игры, и вот по играм стало понятно, что тут без ТЗ уже мало что хорошего можно сделать.

В итоге в настоящее время исполнители в 99% случаев просят у заказчика ТЗ, кто-то готов написать его и самостоятельно за дополнительную плату. Брифы тоже остаются распространёнными, но стоит честно сказать, что смысла в них почти нет. Соглашаются на них в основном заказчики, далёкие от сферы ИТ, а предлагают к заполнению не совсем честные студии и фрилансеры. Ведь в брифе не содержится достаточной информации по объёму работ, там может быть много пунктов по дизайну сайта, для этого вида работ может и достаточно (и то не всегда), для сайтов-визиток на готовых движках тоже (но тут также далеко не всегда), а вот для остального польза сомнительна. По сути это просто пыль в глаза, чтобы исполнитель виделся сразу как специалист с серьёзными намерениями и трата времени.

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

На этом этапе происходит проектирование, именно этот этап определит вид и содержание будущего сайта, игры или иного продукта. Не стоит недооценивать важность этой работы, какое будет ТЗ, такой и будет проект, если оно плохое, то шансы получить что-то хорошее по итогам всех работ также малы. В лучшем случае это приведёт к большим задержкам, так как в процессе работ придётся многое менять, пересогласовывать и обсуждать, в худшем проект просто получится таким, как он написан – т.е. почти никаким.

Если речь идёт о комплексном проекте, к примеру сайт под ключ, то в хорошем ТЗ должно быть предусмотрено как минимум 2 чётких раздела: один конкретно для дизайнеров, другой – для программистов. Конечно, им будет полезно иногда посмотреть чужой раздел, но чтобы они не утонули в потоке лишней и ненужной информации, у них должен быть свой раздел, где нет ничего лишнего, с ним они будут работать чаще всего.

Есть даже ГОСТы для ТЗ, однако здесь всё же нужна золотая середина. Вот в этом случае как раз пользы может быть меньше, чем толку, и это уже излишняя бюрократизация. К сожалению, написание по ГОСТу может породить ТЗ на таком формальном языке, что его поймут не многие, а это главное. ТЗ – должно быть понятно всем сторонам. Уверены, что если кто-то всё же захочет поискать информацию по таким ГОСТам, найдёт её самостоятельно, в Интернете много информации по этой теме, не будем подробнее на этом останавливаться.

Как и любая услуга, написание ТЗ стоит денег. Есть студии или фрилансеры, что готовы сами для заказчика его подготовить, как правило, цена включается в общую стоимость проекта или оговаривается отдельно. Тут кто во что горазд в маркетинге. Однако стоит предупредить, что если строить работу верно, то именно по ТЗ определяется итоговая цена на сам проект, потому до его готовности сказать, что его цена уже включена в цену проекта, да ещё и назвать её – это не то что лукавить, скорее обманывать. Знайте, если вам говорят до ТЗ точную цену на весь проект, утверждая, что туда включена цена и за само ТЗ и готовы начать сразу после аванса, то вас, скорее всего, ждут по проекту проблемы, это просто попытка привязать к себе клиента любой ценой. Конечно, примерные ориентиры до ТЗ вам сказать смогут, но помните – на этом этапе главное именно ТЗ, потому выбирайте того, кто его сделает вам по подходящей цене и при подходящих условиях. Честный разработчик, который в виде дополнительной услуги предлагает написание ТЗ, никогда не будет требовать заказывать именно у него. Это отдельная услуга. Конечно, лучше если всё делает в комплексе одна группа специалистов, но выбор за вами.

Цена за ТЗ не такая маленькая, как может показаться, порой она составляет до 15-20% от последующей стоимости самого проекта, это довольно сложная и кропотливая работа, которая может продлиться не один месяц и предстать в виде 100 страниц убористого текста. Но не стоит пугаться, всё зависит от масштабов самого проекта, простой продукт требует и небольшого ТЗ, которое всё равно необходимо, но денежных ресурсов и затрат по времени оно потребует не так много, за то спасёт от многих проблем всех.

Что касается схемы оплаты, то тут всё не так просто. ТЗ – специфический продукт, его нельзя скрыть от глаз заказчика до момента оплаты, потому авансовую схему исполнители редко любят. Для обоих сторон будет наиболее приемлемо использовать системы безопасных сделок, о которых мы писали в предыдущей статье, заключение договора, ну а 100% аванс по тем исполнителям, у кого хорошие отзывы, опыт, если всё указывает на их добропорядочность.

Многочисленные фриланс-порталы, к сожалению, пока не уделяют должного внимания вопросам ТЗ. Нам кажется, что здесь большая роль именно у администраций порталов, необязательно принуждать всех переходить на ТЗ, но нужно всячески оповещать пользователей о необходимости использовать ТЗ всегда, стараться убедить в этом и фрилансеров, и заказчиков. Наш портал http://www.best-lance.ru планирует в будущем также всё больше внимания уделять этому вопросу. А всем, кто хочет помочь рынку стать цивилизованнее – доносите эту статью до заинтересованных лиц. Фрилансеры, если Вы натыкаетесь на непонимание у заказчика по поводу необходимости ТЗ – попробуйте просто дать ссылку на эту статью, может заказчик извлечёт для себя полезное зерно в ней и согласится с вами, поймёт. Возможно, отсылка к тому, что это мнение администрации одного из сайтов удалённой работы и частных услуг сыграет свою роль и будет иметь вес и значение.

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