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

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

Вводная информация + Изначальное соглашение -> Аналитика -> Верстка + Программинг

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

1.Вводную информацию подали некорреткно, часть информации была лишней.

2.Аналитик на базе этой информации сделал какие-то действия и передал дизайнеру.

3.Дизайнер не сообразил, чего от него ждут и сделал проект в соответствии со своими представлениями.

4.Программист тоже сделал все, исходя из своих соображений.

5.Результат продемонстрировал заказчику, а ему не понравилось.

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

 

Самое ужасное, что многие считают это неизбежностью, и даже нормой. Но, выход из ситуации есть. Нужно назначить человека, который будет руководить всем проектом. К примеру, в некоторых фирмах эти функции возложены на отдел аналитики.

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

Бриф - это документ, формулирующий задачу аналитику. Бриф включает такую информацию: о бренде, о товарах/услугах, информацию, влияющую на разработку решения.

Коммерческое предложение - это предложение, которое адресовано клиенту. Касательно коммерческого предложения главное в нашем случае - сроки, стоимость, перечисление компонентов, входящих в проект.

График разработки - его составляют после заключения договора. Изменение графика нужно согласовывать с клиентом. В графике стоит обращать внимание на моменты изменений.

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

1.Дает возможность зафиксировать функционал и набор компонентов, который подходит разработчикам и клиенту.

2.Закрепляет денежные нюансы проекта.

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

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

1.Однозначность определений, чтобы разработчику было понятно, как это нужно воплощать.

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

3.Краткие формулировки и структурность. Списки с нумерациями, маркеры, подзаголовки - все это характеризует хорошее ТЗ.

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

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

3.Шаблоны и структура сайта - это самый «мясной» раздел, в который располагают карту сайта или всю «начинку», которую хочется разместить на странице. Здесь располагается исключительно текст, имеющий значение для разработки.

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

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

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

7.Структура информации. Каким образом в проекте будут связаны отдельные компоненты, а также сущности систем.

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

- Прототип отражает исключительно присутствие компонентов.

- Прототип увязывается с ТЗ и не противоречит ему.

- Прототип нужно создавать в тесной связке дизайнера с аналитиком.

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

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

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

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

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