Подготовка договорной документации в заказной разработке

Подготовка документов при заказе разработки сайта или сервиса — этап, который может выглядеть сложным: каждый заказчик хочет быть застрахован от неожиданностей, включая срыв сроков и несоответствия «реальности» и «ожиданий». Но при этом не хочется, чтобы бюрократия и волокита задержали работу над проектом. Как правильно организовать процесс работы с документами, чтобы не терять время зря? И какие документы действительно важны, а без каких можно обойтись? Обо всём этом рассказываем в статье, которую мы подготовили совместно с экспертом Uplab.

Заказчики часто испытывают страх перед бюрократическими процедурами и опасаются, что процесс создания и согласования документов может существенно задержать запуск проекта. Вот главные «боли» и «страхи», о которых часто говорят на брифингах и деловых встречах.

•

Перегруженность. Каждый документ — новый массив информации, которую нужно обработать.

•

Страх перед задержками. Время — ключевой фактор в бизнесе, и любая отсрочка, в том числе из-за того, что «договор не готов», может привести к финансовым потерям.

•

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

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

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

Важно помнить: весь перечень документов, который мы приводим ниже, не является обязательным. Как правило, на каждом нашем проекте он реализуется лишь частично. А какие именно бумаги из этого списка подписываю заказчик и исполнитель, зависит от типа и масштаба проекта.

Собрали в таблице основные документы, которые оформляются на этом этапе. Ниже подробно раскроем их аспекты и содержание.

На этапе «Выбор подрядчика» заказчик ещё не запускает работу над проектом. Важное в этом периоде — описать ответственность сторон, зафиксировать взаимные ожидания и закрепить главные параметры работ: сроки, расценки, содержание. Здесь мы в Uplab выделяем пять основных документов:

•

договор;

•

план-график;

•

функциональное задание;

•

смету;

•

подход к реализации проекта.

Договор

Договор возглавляет разработку проектной документации. Как правило, проект договора — это работа юриста, специализирующегося на договорном праве и имеющего экспертизу в IT. Это может быть как штатный юрист компании на стороне заказчика или исполнителя, так и привлеченный внешний консультант. Вторая сторона обычно также привлекает юриста для экспертизы договора перед его подписанием. Договорная работа — это процесс оформления соглашений между всеми участниками. Основные аспекты, закреплённые в договоре:

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

2. Порядок приемки и оплаты. Описание критериев приемки и графика платежей. Игнорирование ведет к задержкам выплат или конфликтам из-за «недовольства качеством».

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

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

Виктор Чернышев

заместитель руководителя отдела развития бизнеса

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

План-график

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

02

Длительность шагов внутри этапов. Фиксирует временные рамки для каждой задачи. Если не оценить затраты времени заранее, то ожидания заказчика могут разойтись с ожиданиями подрядчика, и это приведет к срыву сроков.

03

Ответственные за шаги этапов. Закрепляет, кто именно отвечает за выполнение каждого блока работ. Это позволяет избежать перекладывания ответственности. Особенно если в проекте участвуют дополнительные команды (например, команда, которая обеспечивает проект DDoS-защитой).

Последовательность работ. Определяет логический порядок выполнения задач. Четкая последовательность обеспечит максимально эффективное распределение работ с учетом зависимостей между ними.

01

Конкретный результат по шагу работ. Четко описывает, что должно быть готово на выходе каждого этапа: например, ТЗ, развернутые и настроенные сервера, рабочее API. Игнорирование ведет к размытым критериям приемки и спорам о «завершенности».

04

05

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

Функциональное задание

Этот документ — результат совместной работы бизнес-аналитика (или системного аналитика), разработчиков и тимлида команды разработки. Каждый из них вносит свой вклад в документ, обеспечивая полноту, точность и реализуемость требований. Аналитики отвечают за выявление и формализацию требований, разработчики — за техническую реализуемость, а на тимлиде лежит координация и общая структура документа. Вот что включает функциональное задание.

02

Требования к технологическому стеку (формулирует разработчик). Фиксируют допустимые языки, фреймворки, систему управления базами данных, и т. д. Важны для совместимости с инфраструктурой заказчика. Игнорирование требований к стеку может привести к необходимости полного переписывания кода.

03

Требования к процессу разработки (составляет тимлид). Определяют методологию (Agile/Waterfall), частоту демо, код-ревью, тестирование. Если они не согласованы, процесс разработки будет страдать от непонимания и конфликтов, что скажется на качестве и сроках.

Функциональные требования (их формулирует бизнес- или системный аналитик). Подробно описывают, что должна делать система: например, «возможность оплаты через PayPal». Без них есть риск разработать нефункциональный продукт или уйти в бесконечные доработки.

01

Требования к документированию (формулируют бизнес- или системный аналитик). Уточняют объем и формат проектной документации. Отсутствие нужной документации приводит к трудностям с сопровождением продукта и усложняет процесс передачи его другой команде.

04

05

Требования к интеграциям (составляют бизнес- или системный аналитик). Указывают, с какими внешними сервисами должно работать ПО: например, 1С, CRM, платежные системы. Фиксирует направления интеграций и задачи, которые решаются с их помощью. Если в документах нет требований к интеграциям, это приведет к недооценке трудоемкости работ, перерасходу бюджета и срывам сроков проекта.

Критерии приемки. Четкие условия, при которых продукт считается готовым (например, «95% тест-кейсов пройдены»). Без формулировки этих условий неизбежно возникнут споры о «завершенности» проекта.

06

Смета

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

02

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

03

Нюансы по реализации. Фиксирует допущения и риски, влияющие на стоимость (например, «интеграция с 1С — только при наличии API-документации»).

Структура работ по этапам. Разбивает проект на логические блоки (анализ, разработка, тестирование и т. д.) с указанием их стоимости.

01

Технико-коммерческое предложение (подход к реализации проекта)

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

02

Подход к архитектуре. Описывает принципы проектирования системы (монолит vs. микросервисы, паттерны проектирования). Неверный выбор архитектуры ведет к проблемам в масштабируемости и к высокой стоимости изменений.

03

Подход к инфраструктуре. Фиксирует решения по серверам, облачным платформам, CI/CD. Игнорирование этого раздела может привести к проблемам с производительностью или неожиданным затратам на хостинг.

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

01

Технологический стек. Перечень языков, фреймворков и инструментов, с обоснованием выбора. Несоответствие стека требованиям проекта — риск получить неоптимальное или неустойчивое решение.

04

05

Команда проекта. Состав и роли участников, уровень их вовлеченности. Без понимания команды — риск столкнуться с нехваткой экспертизы или текучкой кадров в критической фазе.

Версионность продукта. Описан процесс присвоения новых номеров версиям: порядок и критерии.

06

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

Feature List (список функций)

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

Концептуальная модель бизнеса

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

Диаграмма потоков данных

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

Моделирование бизнес-процессов (BPMN)

За аббревиатурой BPMN (Business Process Model and Notation) скрывается так называемое «стандартизованное графическое описание бизнес-процессов». Этот документ служит «мостом» между бизнес-требованиями и технической реализацией. BPMN позволяет описать бизнес-логику выполнения действий в виде наглядной диаграммы, а также запустить отрисованный бизнес-процесс на исполнение. Документ нужен для того, чтобы все графические обозначения были понятны каждому участнику проекта.

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

Высокоуровневое техническое задание

В проектной документации «высокоуровневое техническое задание» (ВТЗ) — это документ, который описывает общие требования и цели проекта, не вдаваясь в детали реализации. ВТЗ — это верхнеуровневое описание, которое дает общее представление о том, что нужно сделать, но не уточняет, как именно это будет реализовано. Вот какие аспекты отражены в ВТЗ.

02

Пользовательские сценарии. Пошаговые flow ключевых действий (например, «Оформление заказа»). Выявляет «узкие места» в логике взаимодействия. Основа для тест-кейсов. Этот и следующие аспекты документа разрабатывает UX/UI-аналитик.

03

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

Описание пользовательских интерфейсов. Текстовое описание пользовательских интерфейсов, логики компонентов, которая не «считывается» с дизайн-макетов.

01

Матрица ролей. Права доступа для каждой роли (например, «Менеджер: может редактировать цены»). Предотвращает несанкционированные действия в рамках системы.

04

05

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

Статусная модель. Жизненный цикл сущностей (например, заказ: «черновик → оплачен → выполнен»). Определяет бизнес-правила смены состояний.

06

Дизайн- и контент-гайды

Документы по дизайну — это большая группа, включающая как контент, так и визуальный стиль продукта.

02

Прототипы интерфейсов. Интерактивные модели с кликабельными элементами. Демонстрирует пользовательские сценарии в действии. Выявляет проблемы юзабилити до начала разработки. Составляет UX/UI-аналитик.

03

Дизайн-концепция. Moodboard + ключевые экраны в фирменном стиле. Определяет визуальную идентичность продукта. Согласует эстетические ожидания с заказчиком. Обеспечивает соответствие дизайна бренд-гайдам Заказчика. За этот и последующие аспекты отвечает ведущий дизайнер проекта.

Фактура страниц. Чёрно-белые схемы экранов с расстановкой элементов. Фиксирует расположение ключевых компонентов без деталей визуала. Позволяет проверить логику взаимодействия на раннем этапе. Составляет контент-редактор.

01

Дизайн-макеты. Финальные экраны со всеми состояниями (hover/error/loading).

04

05

UI-kit. Библиотека компонентов (кнопки, формы, модальные окна). Обеспечивает консистентность интерфейса. Ускоряет разработку за счет переиспользуемых элементов.

Требования к контенту

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

02

Голос и тон (Tone of Voice). Правила стилистики (формальный/разговорный стиль, запрещенные слова).

03

Контент-потоки. Схемы создания/апрува/публикации материалов. Контроль качества до публикации. Разделение зон ответственности.

Типы и структура контента. Категории материалов (статьи, карточки товаров, уведомления) + их обязательные поля. Четкие шаблоны для авторов контента. Гарантирует полноту информации.

01

SEO-параметры. Правила формирования URL, метатеги (title/description), ALT-тексты для изображений.

04

Требования к SEO

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

Базовая оптимизация структуры сайта для индексации. Правила оформления каких-либо текстов и метатегов. Семантическая разметка (Schema.org). Внутренняя перелинковка. Эти разделы требований к SEO составляет SEO-специалист.

01

Контроль эффективности, пользовательского поведения и точек роста. Базовые метрики. Системы аналитики. Целевые события. Сегментация аудитории. Интеграция с CRM/ERP. Дашборды. Составляет веб-аналитик.

02

Низкоуровневое техническое задание

Так называют подробное и детализированное задание для команды разработки, в котором закреплены важные технические аспекты. Среди них:

02

Модель хранения данных. Правила организации данных в хранилищах. Схемы таблиц (для SQL). Составляет разработчик.

03

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

Объектная модель. Описание сущностей системы и их взаимосвязей. Основа для проектирования API и баз данных. Составляет системный аналитик или разработчик.

01

Спецификации на интеграции. Технические требования к внешним API и сервисам. Endpoints и методы. Форматы запросов/ответов (JSON/XML). Лимиты и квоты. Механизмы аутентификации. Составляет системный аналитик или разработчик.

04

05

Ёмкость серверов. Расчет необходимых ресурсов инфраструктуры. Составляет системный архитектор.

Архитектура решения. Высокоуровневая схема работы системы.

Микросервисы/монолит. Очереди сообщений (Kafka, RabbitMQ). Сервисы кэширования. Составляет системный архитектор.

06

Инфраструктура решения. Описание среды развертывания. Провайдеры (AWS/GCP/Azure). Оркестрация (Kubernetes, Docker Swarm). Мониторинг (Prometheus, Grafana). CI/CD (GitLab CI, GitHub Actions). Составляют системный архитектор и DevOps.

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

Программа и методика испытаний (ПМИ)

Составляют системный аналитик и QA тестировщик. Включает:

02

порядок приемки (этапы подписания актов);

03

методы тестирования (ручное/автоматизированное)

тест-кейсы с критериями прохождения;

01

Сценарии нагрузочного тестирования

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

Пользовательские инструкции

Руководства для конечных пользователей. Составляет аналитик.

Инструкции разработчика

Документация для сопровождения кода. Составляет системный администратор или разработчик. Что входит:

02

API Reference (Swagger/OpenAPI);

03

Логирование и мониторинг (где смотреть логи);

сборка и запуск (docker-compose, env-переменные);

01

Процедура обновления (миграции БД, rollback).

04

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