Проектная документация: что нужно требовать от исполнителя

1054

В статье рассмотрен идеальный процесс разработки и обозначены самые слабые точки любой разработки, связанной с интернет-маркетингом.

Идеальный процесс разработки, по идее, схематично выглядит так:

Это при условии, что было достаточно вводной информации, а с клиентом есть соглашение, например, в виде договора. Однако, даже если аналитики, дизайнеры и программисты работают идеально, у такой схемы все равно есть множество слабых точек, которые обнаруживаются уже в процессе разработки:

  1. Вводная информация подана некорректно, какая-то информация была лишней.
  2. Аналитик на основе всей этой информации что-то сделал и передал дизайнеру.
  3. Дизайнер, в свою очередь, не понял, что от него требуется, и сделал так, как представлял сам.
  4. Программист тоже сделал все по-своему.
  5. Результат показали клиенту, а он оказался недоволен.

В результате, практически во всех студиях в последний день проекта происходит это:

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

Даже если этот человек-куратор найден, ему необходим инструмент. И этим инструментом является бюрократия. Она помогает избежать «последнего дня проекта». Бюрократия, в данном случае, не является чем-то негативным, как все привыкли, а наоборот, стоит на страже проекта. Бюрократия процесса разработки требует обязательного наличия следующих документов: брифа, коммерческого предложения, графика разработки, технического задания, прототипов, художественного задания.

БРИФ – это постановка задач от проектировщика аналитику. Бриф состоит из: информации о компании; информации о бренде; информации по товарам/услугам; информации, важной для разработки решения.

КОММЕРЧЕСКОЕ ПРЕДЛОЖЕНИЕ — это суммарное предложение, адресованное клиенту. Главное, чего касается коммерческое предложение в нашем случае — это стоимость, сроки и перечисление компонентов, которые будут входить в проект.

ГРАФИК РАЗРАБОТКИ составляется после заключения договора. Изменение графика разработки должно согласовываться с клиентом. В графике разработки надо обращать внимание на те моменты, когда он был изменен.

ТЕХНИЧЕСКОЕ ЗАДАНИЕ – это самое сложное основополагающее проекта. ТЗ – это продукт работы аналитика предназначенный для разработчика.

Задачи, которые решает ТЗ:

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

Принципы составления ТЗ:

ТЗ составляется очень жестким образом. Это не картиночки, не абзацы текстов, не подробнейшее описание реализации проекта. ТЗ — это прежде всего задание. Оно требует:

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

Структура сферического ТЗ в вакууме:

• Общие положения — это юридический раздел, который говорит, как ТЗ связано с договором.

• Технические требования к сайту и ПО. Например, различный адаптивный дизайн, информация о домене, требование к CMS.

• Структура сайта и шаблоны – это самый «жирный и мясной» раздел в котором находится карта сайта или весь «фарш», который хочется расположить на странице. Здесь находится только текст, важный для разработки.

• Функциональные описания, то есть таблицы, блок-схемы, касающиеся того как отдельные компоненты нашей системы будут связаны между собой.

• Интеграция со сторонними системами, похоже на функционально описание, только говорящее о том, как наш проект будет связан с внешними системами.

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

• Структура данных. Как именно в проекте будут увязаны отдельные компоненты и сущности систем между собой.

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

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

ХУДОЖЕСТВЕННОЕ ЗАДАНИЕ – это симбиоз того, что было создано на этапе брифа и симбиоз технического задания. Это документ, предназначенный для дизайнеров.

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

Правильное использование проектной документации помогает прикрыть слабые места разработки. Аналитик сможет правильно передавать информацию дизайнеру и программисту. А те в свою очередь получат документ о проекте, в котором будут прописаны ошибки, и их еще можно будет быстро исправить. Проектную документацию важно вести правильно.

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

При некорректном техническом задании возникают проблемы со стороны исполнителя такие как излишне подробное, громоздкое и нечитаемое техническое задание.

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

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

Доклад был представлен Алексеем Бородкиным, директором по аналитике агентства интерактивных коммуникаций qb interactive, на конференции IBC Russia 2013.

Подготовила Ирина Струкова

Оксана Мамчуева
Журналист, новостной редактор, работает на сайте с 2009 года. Специализация: интернет-маркетинг, SEO, поисковые системы, обзоры профильных мероприятий, отраслевые новости рунета.