С каждым годом я все больше убеждаюсь, что 60% проблем в проекте возникают из-за нечетко поставленных начальных требований проекта. Обычно эти требования должны быть описаны в техническом задании, которое создается ТЕХНИЧЕСКИМ специалистом, а не заказчиком.

Когда нет ТЗ:

  • вероятно вы немного экономите в начале проекта, но не волнуйтесь, доработки и постоянные правки по проекту очень быстро нивелируют эту разницу и увеличат бюджет.
  • исполнитель проекта имеет смутное представление, что вы в итоге хотите получить. Как думаете, сможет ли он сделать что-то внятное в этом случае?
  • вы совершенно не представляете реальный бюджет проекта. Да, у вас может быть некоторая оценка проекта от исполнителя, но это скорее вера в эту оценку, а не расчет. Либо вы переплатите, либо исполнитель будет работать себе в убыток.
  • постоянно возникают споры и стычки с исполнителем – делать или не делать в рамках проекта. Если ТЗ есть – то у вас все прописано, что нужно сделать, и споры бывают только, когда пункты прописаны неконкретно.

Важное примечание – техническое задание – это не мелкая деталь проекта. По бюджету это примерно 10-20% стоимости проекта. Т.е. не совсем корректно требовать от исполнителя сделать ТЗ за 2 дня бесплатно. Чем лучше и точнее ваше ТЗ, тем ниже риски завести проект в трясину. У нас были случаи, когда мы в угоду заказчику делали быстрый набросок ТЗ, но практика показывает, что такой подход ведет в будущем к перерасходу и дополнительным переделкам.

Хорошая аналогия – это план дома. Если у вас плохой план дома, то как бы ни старались строители, все равно получится плохой результат. А если перед постройкой вообще нет плана?

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

Основные компоненты технического задания:

  1. визуальные макеты страниц
  2. структура сайта
  3. описание предметной области и бизнес-логики по ключевым процессам.
  4. описание требований (ТЕХНИЧЕСКИХ!) для страниц и модулей.
  5. системные и иные требования.
  6. элементы проектирования системы (таблицы, проработка узких мест)

Главный вывод: ТЗ должно быть в проекте. И делать его должен технический специалист на платной основе.

Так зачем создавать техническое задание?

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

Если вам понравилась статья, помогите, пожалуйста с распространением этого материала в Сети.

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

Ваш e-mail не будет опубликован.