1.Проблемы составления ТЗ

Основная проблема, как ни парадоксально звучит, - вообще нежелание составлять ТЗ.
В какой-то мере это можно понять, если сумма работ маленькая. Однако лично я руководствуюсь принципом, что четко нужно работать всегда, независимо от суммы.
(Хотя так считают далеко не все. И здесь на форуме много раз можно было прочесть- «что ты дергаешься за 10/150 баксов?», «подумаешь, я тоже могу забыть отдать 15 баксов» и тп)

Разумеется, если задание складывается в три строчки, то оформлять его может показаться глупым (например, при мелких форумных сделках). Но в этом случае хотелось бы порекомендовать сделать так. Все переговоры в аське свести в эти 3-4-5 строк и записать единым постом. Затем перебросить заказчику. И попросить проверить каждый пункт. Ибо в процессе разговоров легко теряются нюансы. Потом возникают недоразумения. Впрочем, и без них…противно бывало когда-то лазить по истории и перечитывать, что ж там настучал заказчик и как это понимать.

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


Для справки
Есть такая тактика у работодателей. Проверять на маленьких (тестовых по факту) заданиях уровень знаний и исполнительскую дисциплину. Чтобы прикинуть - можно ли в дальнейшем поручить человеку большее. Иногда тактики нет - просто сохраняют контакты мелькнувшего «кодера, приятного в общении». Знаю по себе - поиск исполнителя/партнера я начинаю со знакомых в мессенджерах (да и вы наверняка так же), а не с объявлений на форумах.
Более того, мой личный опыт (и знакомых тоже) показывает, что очень часто один клиент приводит еще двух (в среднем). Для примера - к моему великому удивлению в одном из компьютерных магазинов города хозяева рассказали, что основной приток покупок дает вовсе не реклама в СМИ, а рекомендации их клиентов. В качестве подтверждения, как пример, они привели оформление гарантий для множества покупателей из соседнего городка, которые косяками тянулись именно в этот магазин, хотя рядом торговали конкуренты по более низким ценам. Но..их знакомым все понравилось, техника работала, гарантии соблюдались, обслуживание на уровне, и покупатели предпочитали не рисковать и идти проторенной дорожкой.

2.А что делать, если заказчику лень писать ТЗ? Или он этого не умеет делать?

Вот как описывает эту ситуацию один из «руководителей» на своем блоге:

Мой личный опыт показал, что есть категории исполнителей, неспособных писать технические задания. Я это отношу к специфике занятий и людей. И хоть ты расшибись, но эти категории граждан вам ТЗ не родят. Не обижайтесь, перечисляю в порядке убывания способности НЕ написать техническое задание:
Дизайнеры;
Web-программисты;
Программисты.

Очень странный опыт, однако…( http://beta.delta-z.com/index.php/archives/200)

1 вариант.
Вы убеждаете заказчика напрячься и все-таки написать;
Для упрощения процедуры подбрасываете бриф, подробную анкету, образцы готовых работ, ТЗ с других заказов и просите выбрать/подчеркнуть нужное. Как правило, так поступают фирмы, набившие руку на общении с сотнями клиентов (крупные компании вообще смотрят в сторону аутсорсинга и могут нанимать консалтинговые конторы для составления ТЗ и аудиторов для его проверки – но это не наша история).
Искусство составления подобных схем формализации потребностей клиента втайне вроде бы не держится, но все же, имхо, сугубо индивидуально. Т.е. например, у меня своя методика беседы с заказчиком, и… я не видела в сети среди сотен вариантов ни одного реально полезного на 100% ТЗ, например, на дизайн сайта.

2 вариант.
Вы пишите ТЗ вдвоем с заказчиком, по методу «интервью», завершаете в одиночку и пересылаете итоговый документ на подпись.

3 вариант.
Отказываетесь от работы. Возможно, вам попался клиент, который ну очень смутно представляет, что он хочет (было и такое, и не раз) и его невнятные помыслы распознать невозможно. Даже если он искренне собирается за что-то заплатить деньги - впереди будет одна морока. Я в таких случаях предпочитаю не браться.

При любом варианте согласование ТЗ, как правило, процесс интерактивный, а заодно и итерационный. Хотя случай, когда ТЗ идеальное, а заказчик – профессионал в вашей сфере – тоже не самый лучший. С вас спросят по полной, уж будьте уверены=))
Вот поэтому я бы посмела все же порекомендовать начинающим не работать с посредниками, особенно фирмой – вариантов для лавирования и отступления будет гораздо больше. И начинать с небольших заказов, чтобы постепенно влится в систему фриланса, получив опыт.
Хороший вариант также делать работу малой командой – но тут и деньги придется делить на 2-3 человек.
(Материал о работе команды при подготовке IT проекта можно почитать по ссылке в конце текста)

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

1. Принято считать, что первый кто называет цену - проигрывает. В тех случаях, когда спрашивают «сколько стоит ваша работа», держа руку на кошельке…
2. Работодатели не любят оплачивать поэтапно. Исполнителю, наоборот, выгодно именно так.
3. Называя минимальную цену вы рискуете не найти того, кто бы сделал за такие деньги за вас в случае форс-мажора.
4. На фрилансе много школьников с минимальными ценами. Конкурировать с ними можно портфолио, уровнем знаний и уровнем ведения переговоров. Но лучше всего и не пытаться.
Интересный прием – просмотреть незакрытые проекты в «глубине» сайта. Как правило, заказчик бывает расстроен тем, что не нашел исполнителя и скорее всего может искренне вам обрадоваться (но, как вариант, исполнитель уже найден на стороне, а проект забыли закрыть).

Типичная ситуация, когда нубы сбрасывают цены, вы находите себе недорогого компаньона/исполнителя, он пропадает, и с такими деньгами на которые уже договорились с клиентом что-то сделать бывает трудно. Желательно искать золотую середину по оплате.

5. Ваша цена должна соответствовать портфолио. Часто именно его солидность влияет напрямую на стоимость работ. У дизайнеров - напрямую. Если даже вы можете большее, но нет тому доказательств – не обижайтесь.

6. В случае важных заказов принято назначать стоимость неустойки (штрафы).

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

Могу отметить, что нарушение сроков - это бич большинства работников студенческого возраста. Необходимости соблюдать сроки не видят, отвлекаются на что попало, соблазняются понятно чем…
Вывод простой. Или не браться за срочные заказы, или делать их за двойную цену, но все развлечения отложить до лучших времен. Однако побеждает то ли жадность, то ли жадность то ли переоценка своих сил. Нарушения сроков продолжаются.


7. В случае мелких просьб доделок/переделок лучше сделать их бесплатно. Но мягко оговорить, что делаете одолжение, и большая по объему работа будет стоить денег.

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

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


4. Сдача проекта

Вроде бы широко и всюду расписаны правила подстраховки со стороны исполнителей. И тем не менее кто-то время от времени попадается.

Пример.
Недавняя тема на форуме античата о том, что не заплатили за проект, который делался 6 недель. Основная проблема была в том, что все работы велись на сервере заказчика.

Перечислю на всякий случай законы фриланса:
1. Исходники отдаются заказчику только после полной оплаты. Для тестирования достаточно скомпилированной версии (для десктопных приложений). Можно ограничить функционал.
Пример.
При компиляции СУБД на FoxPro пользовалась ReFox-om с высоким уровнем защиты (3-4). Сама декомпилировала делфи, VB, VBA, FoxPro (вытащенные из сети).
Что-то удавалось полностью, что-то частично (формы).

2. Скриншоты дизайна присылаются в jpg, можно с водяными знаками, можно в масштабе 80%.
3. Все серверные скрипты располагаются только на собственных серверах. Заказчику в лучшем случае дается доступ в админку (без этого бывает не обойтись) для тестирования.
4. Прежде чем заказчик выудит ворох ошибок, попросите потестировать/оценить работу своих знакомых. Ситуация, когда программист не видит собственных элементарных ляпов и полностью всю проверку перекладывает на плечи заказчика – раздражает.
5. Показывая промежуточный вариант, всячески подчеркивайте, что это не окончательный вариант, и вы готовы исправить все, о чем вас попросят.
6. Сроки всегда должны быть оговорены. Даже если это два месяца для мелочевки, лучше назначить неделю. Иначе все может закончится тем, что найдется другая работа, намного выгоднее.
7. Вопрос кому принадлежат разработки оговаривается также особо. Возможны варианты. Но как правило, на что-то стоящее заказчики пытаются получить полные права.

5. Библиография =)

1. Список примеров технических заданий
http://www.antula.ru/weborder-tz.htm
2. Один из примеров брифа (мне не все нравится в нем):
http://malkin.com.ua/wp-content/uploads/2008/06/brief.doc
3. Жизнь без технического задания.
КомпьютерраОнлайн. http://www.computerra.ru/think/286727/
4. О работе команда над IT проектом (прим.-злобно. матерно. остроумно)
http://balzatul.multiply.com/journal/item/1040