Блог свободен от NOFOLLOW!

Техническое задание. Нужно ли его делать и кто должен быть его автором

Дата: 10-09-2009 | Автор: Yaroslav.CH | Рубрика: Организационные вопросы
Метки:

7

Мы вынесем этот пункт отдельно, поскольку он является основополагающим в вопросе взаимоотношений между заказчиком и исполнителем. Часто возникает вопрос — нужно ли техническое задание и кто его должен писать?

Ответ на первую часть вопроса — да, нужно. Представьте себе, что вы начинаете ремонт в доме, но не указываете строителям где и в каком количестве должны быть выведены розетки, где будут располагаться краны, где подключать технику, как будет расставлена мебель и так далее. Техническое задание на разработку сайта это, по-сути, план-схема по которой определяется что, как и каким образом будет сделано, расставлено и расположено.

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

Существует три варианта создания технического задания:

1.«Ведущий — разработчик, ведомый – заказчик». ТЗ создается разработчиком (его представителем) на основе личного общения с заказчиком. То есть, менеджер встречается с заказчиком, обсуждает детали сайта и после встречи готовит на основе своих записей черновик ТЗ для согласования. Такой вариант оптимален в том случае, если заказчик не до конца уверен в том, что именно он хочет увидеть на сайте, а разработчик готов предоставить свои варианты реализации.

2.«Ведущий — заказчик, ведомый – разработчик». ТЗ создается самим заказчиком и предоставляется разработчику, после чего последний корректирует его в соответствии с необходимыми уточнениями и добавляет в него соответствующие технические аспекты. Чаще всего применяется в том случае, если заказчик твердо знает — что именно он хочет получить в результате разработки.

3.«Типовой проект». Сайт создается на основе шаблонного ТЗ. И хотя такой вариант встречается достаточно часто, не рекомендуется его использовать по простой причине — вам же нужен оригинальный сайт, ведь верно? Тогда какой же смысл брать «болванку» в качестве его схемы.

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

Комментарии 7 комментариев

перейти к форме для комментирования

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

ОтветитьОтветить

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

По методу работы идеальным считаю расширенную модель из пункта 1:

* З. создает задание на получение КП (это такое незо_ТЗ :), но уже достаточно полноценное, листах на 10, например)

* И. пишет КП не просто с вилкой по деньгам и срокам а уже с точным данными, и в КП есть ценник на написание ТЗ и на создание проекта (пока всё бесплатно)

* З. принимает КП (обычно я собираю несколько КП таким образом), выбирает, ободряет, подписывает договор и так далее.

* З. оплачивает

* И. разрабатывает ТЗ, предоставляет З; З. утверждает

* начинается работа по созданию проекта согласно ТЗ.

Имея ТЗ работать не по нему — означает кого-то «минусовать». Т.е. одна из сторон по=любому пострадает, либо И переработает, либо З. недополучит. Второе страшнее :)

Что касается работы без ТЗ, это действительно имеет право на жизнь, не обязательно с фрилансерами, но с очень мелкими проектами, когда студия, например, выполняет маленькие однотипные проекты и З. точно понимает, что он хочет такое же. Это легко показать на основе одной студии... хотя, не буду пиарить.

ОтветитьОтветить

если проект маленький, то можно все «на пальцах» объяснить и сделать, а если долгий по времени и большой проект, то обязательно писать — жить спокойнее и заказчику, и разработчику.

ОтветитьОтветить

@ xoxol: спасибо за комментарий. В изложенной схеме есть один изъян:

* И. пишет КП не просто с вилкой по деньгам и срокам а уже с точным данными, и в КП есть ценник на написание ТЗ и на создание проекта

На основании только лишь КП, написать 100% точную сумму и сроки, не имея на руках ТЗ — очень проблематично. Именно поэтому, я всегда пишу драфт сметы, а не ее «чистовик». Более подробно я писал об этом моменте в статье «Заказчик умеет считать или 7 правил для уверенности в себе».

ОтветитьОтветить

@ Yaroslav.CH:

Нет, Вы меня не поняли. Самое главное в предыдущем пункте.

Заказчик сначала пишет «Задание на получение КП». Это ещё не полноценное ТЗ, которое описывает все технические ньюансы, все грани проекта, вплоть до интерфейсов.

Но оно включает в себя: описание разделов, механизмов, схему взаимодействия и разделов и механизмов между собой; и также включает в себя требования «визаульные», «дизайнерские» и так далее...

Составление «задания на получение КП» ложится обычно на мои плечи. Я вообще в работе кропотлив очень, и в итоге готовое ТЗ на половину состоит из моего задания.

Думаю даже, что моё задание будет в некоторых случаях круче, чем полное ТЗ в некоторых студиях, или потянет на полноценное ТЗ с точки зрения Заказчика. Просто я перфекционист )

ОтветитьОтветить

@ xoxol: ок, но только не понятен один момент — в какой роли Вы выступаете? Со стороны заказчика или со стороны исполнителя? :)

ОтветитьОтветить

@ Yaroslav.CH:

В «длинной» схеме я представитель заказчика (основной род деятельности).

А занимаясь мелкими типовыми проектами без ТЗ — выступаю как Исполнитель :)

ОтветитьОтветить

А Вы оставили комментарий? Ваше мнение очень важно!

Все комментарии до публикации проходят обязательную ручную модерацию, согласно Правил комментирования. Если вы планируете комментарий только ради обратной ссылки на ваш сайт – не трудитесь, смысла нет.