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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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