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

Стоимость разработки предпроектной и проектной документации может составлять существенные 10-20%. В этой статье мы рассмотрим основные документы и подскажем вам, как вы можете сэкономить, выиграв при этом в качестве работ.

Перед запуском нового проекта, или перезапуске существующего крайне желательно свести имеющуюся у вас информацию в единый документ. Этот документ можно назвать “Сопроводительной запиской”. Стандартного формата у нее нет, т.к. у каждой компании свой объем информации и правила ее распространения (внутренние документы конфиденциальны и возможно предоставление лишь выдержек). Какую же информацию стоить включить в сопроводительную записку:

• KPI проекта - если вы не формулировали до этого момента, то рекомендуем сделать это теперь. Если ваш проект имеет фиксированный бюджет, то лучше указать эту информацию изначально. Подгонять стоимость проекта под эту цифру порядочная студия не станет (а зачем вам сотрудничать с непорядочными?), а время на итерациях по согласованию сметы вы сможете сэкономить.
• Выдержки из вашей маркетинговой стратегии, так или иначе касающиеся вашего проекта.
• Ваше мнение о текущем проекте (как сильные стороны, так и слабые) и пожелания к будущему.
• Сторонняя аналитика вашего проекта или бизнеса (аудиты, исследования TNS и т.п.).
• Пожелания к проекту от ваших сотрудников, или подразделений - эта информация ляжет в основу функциональных требований к проекту.
• Если ресурс у вас уже существует, то крайне важно собрать обратную связь от ваших посетителей (это могут быть постоянные партнеры или клиенты, с которыми у вас есть контакт). Обращение к ним за помощью и советом никак не обременит их - они станут ценить вас гораздо выше. Если вы захотите провести опрос, анкетирование или исследование, то в этом случае лучше обратится к компаниям, специализирующимся на этом.

Бриф

Как только вы сформируете сопроводительную записку, вы сможете начать контактировать с подрядчиками, если же вы планируете реализовать проект самостоятельно, то этот пункт можете пропустить.

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

Если исполнитель предлагает вам интервью - не отказывайтесь от него.

Функциональные требования

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

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

Какую информацию желательно добавить в функциональные требования:

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

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

Пользовательские истории (User story)

Вы “ударили по рукам” с подрядчиком и перешли к разработке. Это первый документ, за который вам предложат заплатить. Если стоимость укладывается в ваш бюджет, то рекомендуем его сформировать.

Это немного похоже на психотерапию - его разработка поможет вам лучше понять ваших клиентов. Если вы планируете реализовывать проект по SCRUM/Agile, то вам будет трудно обойтись без него. Не рекомендуем вам браться за него самостоятельно, если у вас нет соответствующего опыта.

User story вкратце описывает:

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

Прототип

Второй документ, за который вас попросят заплатить. Стоимость разработки прототипа уже ощутима, от него не отказаться (если студия позволяет это сделать, то это, как минимум, должно вас насторожить).

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

Разрабатывать прототип необходимо по следующим причинам:

• Для получения более точного представления о проекте (как с точки зрения структуры, так и с точки зрения логики) вами и вашим подрядчиком
• Для выявления логических нестыковок на начальном этапе

Нужно учитывать несколько важных особенностей прототипа:

• Это не дизайн, а лишь визуальный список элементов на странице. Именно поэтому большинство элементов черно-белые.
• Отрабатывает лишь функционал front-end, или 1-2 сценария в рамках back-end.

Если для вас важен интерфейс административной или сервисной панели проекта, то рекомендуем также воспроизвести этот функционал в пототипе.

Прорабатывать ли юзабилити на этапе прототипа? В этом случае нет универсального ответа. Общий совет таков: если это возможно сделать в рамках прототипа, то делайте, но предварительно согласовав наличие элементов и общей логики навигации. В этом случае ui/ux специалиста не будут подгонять, и можно будет приступить к следующим работам.

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

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

Техническое задание

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

Рекомендуем ТЗ оформлять как приложение к договору на разработку проекта.

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

Что должно содержать ТЗ:

• Бизнес-процессы, реализуемые в проекте
• Алгоритмы, в виде блок-схем и описания
• Описание логики работы front-end и back-end
• Перечисления полей и типов их данных, с которыми происходит взаимодействие для корректного проектирования базы данных
• Технические требования к оборудованию или программному обеспечению
• Процедура интеграции, формат и протокол обмена данными
• Технологические и функциональные ограничения
• Условия тестирования для успешной сдачи проекта
• Условия по переносу данных из ранее существовавшего проекта
• Описание процесса запуска (внедрения) проекта.

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

Отсюда же становится понятен ответ на вопрос “Как быть с актуальность ТЗ?”. В процессе реализации проекта от ТЗ приходится отклоняться по различным причинам, и чтобы к моменту сдачи или при необходимости ознакомится с документацией по проекту не приходилось растерянно опускать руки, рекомендуем минимум еженедельно актуализировать этот документ. В первую очередь в этом заинтересован Заказчик, но нередки случаи, когда эту работу берет на себя менеджер со стороны исполнителя.

Обратите внимание что, как правило, интеграция описывается в ТЗ только со стороны проекта. Если у другого сервиса нет штатной интеграции или она не подходит для ваших задач (например 1С Предприятие), то все вопросы останутся на вашей стороне, т.к. рабочую интеграцию исполнитель подтвердит вам просто “прогоном” эталонного файла. Если необходимо вести разработку параллельно, то не затягивайте с ней.

Дорожная карта (roadmap) проекта

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

На этом мы заканчиваем наш обзор. Желаем вам ясных документов и успешных проектов.