В статье рассмотрен идеальный процесс разработки и обозначены самые слабые точки любой разработки, связанной с интернет-маркетингом.
Идеальный процесс разработки, по идее, схематично выглядит так:
Это при условии, что было достаточно вводной информации, а с клиентом есть соглашение, например, в виде договора. Однако, даже если аналитики, дизайнеры и программисты работают идеально, у такой схемы все равно есть множество слабых точек, которые обнаруживаются уже в процессе разработки:
Вводная информация подана некорректно, какая-то информация была лишней.
Аналитик на основе всей этой информации что-то сделал и передал дизайнеру.
Дизайнер, в свою очередь, не понял, что от него требуется, и сделал так, как представлял сам.
Программист тоже сделал все по-своему.
Результат показали клиенту, а он оказался недоволен.
В результате, практически во всех студиях в последний день проекта происходит это:
И многим это кажется неизбежным, и даже нормальным. Однако, выход из этой ситуации есть. Надо назначить кого-то, кто будет курировать весь проект. Например, в некоторых компаниях этим занимается отдел аналитики.
Даже если этот человек-куратор найден, ему необходим инструмент. И этим инструментом является бюрократия. Она помогает избежать «последнего дня проекта». Бюрократия, в данном случае, не является чем-то негативным, как все привыкли, а наоборот, стоит на страже проекта. Бюрократия процесса разработки требует обязательного наличия следующих документов: брифа, коммерческого предложения, графика разработки, технического задания, прототипов, художественного задания.
БРИФ – это постановка задач от проектировщика аналитику. Бриф состоит из: информации о компании; информации о бренде; информации по товарам/услугам; информации, важной для разработки решения.
КОММЕРЧЕСКОЕ ПРЕДЛОЖЕНИЕ - это суммарное предложение, адресованное клиенту. Главное, чего касается коммерческое предложение в нашем случае - это стоимость, сроки и перечисление компонентов, которые будут входить в проект.
ГРАФИК РАЗРАБОТКИ составляется после заключения договора. Изменение графика разработки должно согласовываться с клиентом. В графике разработки надо обращать внимание на те моменты, когда он был изменен.
ТЕХНИЧЕСКОЕ ЗАДАНИЕ – это самое сложное основополагающее проекта. ТЗ – это продукт работы аналитика предназначенный для разработчика.
Задачи, которые решает ТЗ:
Помогает зафиксировать тот набор компонентов и функционал, который устраивает клиента и разработчиков
ТЗ сохраняет проект в рамках просчитанной сметы
ТЗ служит основополагающим документом, к которому могут апеллировать все участники проекта. Например, если заказчика что-то не устраивает он может показать это, и разработчики должны будут это исправить. С дугой стороны если клиент хочет больше чем описано в ТЗ, то разработчик может отказаться реализовывать это, сказав, что в ТЗ прописан этот элемент, а не какой-либо другой и что надо продолжать работу с ним.
Принципы составления ТЗ:
ТЗ составляется очень жестким образом. Это не картиночки, не абзацы текстов, не подробнейшее описание реализации проекта. ТЗ - это прежде всего задание. Оно требует:
Однозначности определений, что бы разработчик понимал, как это надо реализовывать. Это задание, но в то же время однозначное с отсутствием толкований.
Исчерпывающего характера описаний. Если описывается проект, то должен описываться список: что туда входит, как он группируется, реализуется, какие позиции вносятся по умолчанию. Но при этом позиции, которые понятны разработчику не обязательны. Лучше всего описывать так: у нас есть каталог, который можно фильтровать по таким принципам. Соответственно если сказать разработчику что у нас есть каталог фильтраций, он это поймет, а если ему описывать каждое понятное ему действие, то его мозг просто «взорвется».
Краткости формулировок и структурности. Очень удобно ТЗ представлять в виде структурированного списка с нумерацией. Этот документ помогает избежать различных логических срывов при работе. Чтобы проверить структурность ТЗ надо список, который у нас есть представить в виде текста не изменяя не слова, а только расставляя запятые. И если текст получается согласованным, то можно смело преступать к работе. А если появляются какие-то «смысловые дыры», то это значит, что в ТЗ мы что-то упустили. Потому что на самом деле ТЗ это и есть абзацы текста, только структурированные для хорошей видимости.
Структура сферического ТЗ в вакууме:
• Общие положения - это юридический раздел, который говорит, как ТЗ связано с договором.
• Технические требования к сайту и ПО. Например, различный адаптивный дизайн, информация о домене, требование к CMS.
• Структура сайта и шаблоны – это самый «жирный и мясной» раздел в котором находится карта сайта или весь «фарш», который хочется расположить на странице. Здесь находится только текст, важный для разработки.
• Функциональные описания, то есть таблицы, блок-схемы, касающиеся того как отдельные компоненты нашей системы будут связаны между собой.
• Интеграция со сторонними системами, похоже на функционально описание, только говорящее о том, как наш проект будет связан с внешними системами.
• Сценарии использования. Описание и примеры того, как пользователи будут пользоваться сайтом.
• Структура данных. Как именно в проекте будут увязаны отдельные компоненты и сущности систем между собой.
ПРОТОТИП - это графическое представление технического задания, при этом важно понимать, что это не финальный дизайн.
Прототип отражает только наличие компонентов
Прототип должен быть связан с ТЗ и не противоречить ему
Прототип должен создаваться в тесной связке аналитика с дизайнером
Прототип полезно согласовывать с заказчиком, так как ТЗ в чистом виде могут воспринимать не все.
ХУДОЖЕСТВЕННОЕ ЗАДАНИЕ – это симбиоз того, что было создано на этапе брифа и симбиоз технического задания. Это документ, предназначенный для дизайнеров.
Художественное задание состоит из: ключевой информации о компании и ее позиционировании; описания целевой аудитории; референсов (сюда уже может входить информация о цветах); технических ограничений; структуры сайта; описания шаблонов, удобного для дизайна с вычищенным профессиональным описанием. При решении задач важно понимать, какая именно реакция ожидается от потребителя.
Правильное использование проектной документации помогает прикрыть слабые места разработки. Аналитик сможет правильно передавать информацию дизайнеру и программисту. А те в свою очередь получат документ о проекте, в котором будут прописаны ошибки, и их еще можно будет быстро исправить. Проектную документацию важно вести правильно.
Под некорректным техническим заданием подразумевается: заказ технически сложной системы, составление исполнителем излишне подробного технического задания, за подробностями, которого не видно сути проекта, затруднения с дизайном, затруднение с программированием, трудности в коммуникации, успешный запуск проекта вопреки техническому заданию, а не благодаря ему.
При некорректном техническом задании возникают проблемы со стороны исполнителя такие как излишне подробное, громоздкое и нечитаемое техническое задание.
Правильное техническое задание подразумевает: запрос на разработку проекта из нескольких составных частей, составление комплекта технического задания на каждую из частей, согласование с клиентом проекта и модернизация проекта.
В идеале, бюрократия процесса разработки должна помочь студии делать проекты, которые будут приносить людям пользу, а не просто получить бабло или выкатить хоть что-то. C помощью такой бюрократии можно легко и спокойно делать проекты, правильно взаимодействуя с клиентом, благодаря правильной технической документации и правильному построению процесса. Такие проекты будут полезны и студии, и заказчику, и людям, которые будут взаимодействовать с этим проектом.
Доклад был представлен Алексеем Бородкиным, директором по аналитике агентства интерактивных коммуникаций qb interactive, на конференции IBC Russia 2013.
Подготовила Ирина Струкова
Обсудить
Комментарии