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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    ОтветитьОтветить
  5. @ Yaroslav.CH:

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

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

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

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

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

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

    ОтветитьОтветить
  7. @ Yaroslav.CH:

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

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

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *