Как написать объём работы

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

Что такое объём работы?

Объём работы (SOW) — это документ, который излагает, какая работа будет проделана, какие результаты есть, и временная шкала и бюджет для их завершения. Это контракт между ожиданиями и реальностью — вещь, на которую оба вы и ваш клиент указывают, когда кто-то спрашивает «было ли это включено?»

Каждый проект, который идёт набок, может отследить проблему к отсутствующему или нечёткому объёму работы. Клиент ожидал пересмотров, которые не были предусмотрены в бюджете. Временная шкала предполагала, что контент прибудет вовремя. «Маленькое добавление» превратилось в две лишние недели разработки. Хорошо написанный SOW предотвращает всё это.

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

SOW vs Объём работы vs Краткий проект

Эти три документа постоянно путаются. Вот разница:

• Объём работы (SOW): Что вы доставите, временная шкала и бюджет. Это рабочее соглашение, на которое обе стороны ссылаются на протяжении проекта.
• Объём работы: Более формальный, прилегающий к контракту документ, который включает всё в SOW плюс юридические условия, пункты расторжения, положения об интеллектуальной собственности и подробные критерии приёма. Если SOW — это пожатие рук, объём работы — это нотариальная версия. Используйте шаблон объёма работы для этих контрактов.
• Краткий проект: Высокоуровневый обзор целей проекта, аудитории и контекста. Это вводная информация к SOW, не замена для неё. Вы можете получить краткий проект от клиента, затем написать SOW на основе того, что он содержит.

Когда использовать какой: большинство проектов агентства и фрилансера нуждаются в SOW как минимум. Сложные или высокостоимостные контрактов — всё, что превышает $25,000 или включает юридические рассмотрения — требуют полного объёма работы.

Шаг 1: Определите цели проекта

Начните с того, почему проект существует. Напишите 3–5 измеримых целей, которые определяют, как выглядит успех. Не расплывчатые мечты — конкретные результаты.

Плохо: «Переосмыслить веб-сайт.»

Хорошо: «Переосмыслить маркетинговый веб-сайт, чтобы увеличить коэффициент конвертации с 2,1% на 3,5%, запуск к 1 июня 2026 года.»

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

Вот пример раздела целей для переосмысла веб-сайта:

1. Увеличьте представления формы направления на 40% в течение 90 дней запуска.
2. Уменьшите среднее время загрузки страницы на менее 2 секунд на мобильном.
3. Запустите переосмыслённый сайт к 1 июня 2026 года со всеми 12 основными страницами вживо.
4. Достигните соответствия WCAG 2.1 AA по всем общедоступным страницам.

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

Шаг 2: Перечислите все результаты

Результат — это осязаемый результат, который клиент получит. Будьте конкретны о каждом — количество, размеры, форматы, типы файлов. Неясность здесь — то, где начинается ползание сферы.

Вместо: «Дизайн логотипа»

Напишите: «Основной логотип (полный цвет, монохром, перевёрнутый) в форматах SVG, PNG (3 размера) и EPS. Включает одну первичную метку и один вариант значка.»

Вместо: «Разработка веб-сайта»

Напишите: «12-страничный адаптивный веб-сайт, построенный на WordPress, включая: домой, о, услуги (4 страницы), указатель блога, единое блог, контакт, политика конфиденциальности и условия использования. Включает адаптивные макеты мобильных для всех страниц.»

Золотое правило: если вы не можете указать на это как файл, макет или артефакт, это не результат. «Стратегия» не является результатом. «Документ бизнес-стратегии (PDF, 15–20 страниц)» является.

Шаг 3: Установите временную шкалу и вехи

Разбейте проект на фазы. Типичная структура выглядит так:

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

Добавьте буфер. Каждый проект имеет неизвестные. Постройте в 10–15% дополнительного времени для вещей, которые вы не можете предсказать. Если проект 10 недель, планируйте на 11.

Шаг 4: Определите бюджет

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

Для проектов с фиксированной ценой разбейте бюджет по фазе и привяжите платежи к вехам:

• Фаза открытия: $2,500 (должны при подписании SOW)
• Фаза дизайна: $5,000 (должны при одобрении дизайна)
• Фаза разработки: $7,500 (должны при доставке сайта-сценария)
• QA и запуск: $2,500 (должны при запуске)

Укажите, что включено, и что вызывает дополнительные затраты. Например: «Фаза дизайна включает до 2 раундов пересмотра за результат. Дополнительные пересмотры выставляются по $150/ч.» Это одно предложение сохранило больше отношений агентства-клиента, чем какой-либо пункт контракта.

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

Шаг 5: Укажите предположения и исключения

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

Пример предположений:

• Клиент предоставит весь письменный контент к 15 апреля 2026 года.
• Существующая среда хостинга поддерживает PHP 8.2 и MySQL 8.0.
• Клиент имеет доступ администратора ко всем сторонним учётам (DNS, аналитика, CMS).
• Обратная связь будет консолидирована в одну точку контакта.

Исключения — это то, что НЕ включено. Этот раздел имеет решающее значение — он рисует границу вашей ответственности.

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

Принцип прост: если это не явно включено в результаты, это исключено. Укажите это ясно, чтобы не было неясности.

Шаг 6: Добавьте критерии приёма

Определите, как каждый результат будет просмотрен и одобрен:

• Раунды обзора: Сколько включено на результат (обычно 2).
• Окно обратной связи: Сколько времени клиент имеет, чтобы предоставить обратную связь (обычно 3–5 рабочих дней).
• Поздняя обратная связь: Что происходит, если обратная связь не прибывает вовремя — временная шкала смещается соответственно.
• Способ одобрения: Письменная подпись через электронную почту или инструмент управления проектом. Словесное одобрение не считается.
• Изменения после одобрения: Как только результат одобрен, изменения становятся заказами изменений с отдельным ценообразованием и временными шкалами. Используйте шаблон заказа изменений, чтобы обрабатывать эти чистым.

Критерии приёма защищают обе стороны. Клиент знает ровно как процесс обзора работает. Вы знаете, что «одобрено» означает одобрено — не «одобрено, но фактически у нас есть больше изменений.»

Шаг 7: Получите подпись

SOW, никем не подписанный, — это просто список пожеланий. Обе стороны подписывают документ перед началом каких-либо работ.

Включить:

• Полное имя и заголовок подписающего с каждой стороны
• Дата подписи
• Утверждение, подтверждающее, что обе стороны согласны с условиями, изложенными в SOW

Цифровые подписи через инструменты, такие как DocuSign или HelloSign, совершенно действительны. Что имеет значение, так это чёткий, документированный момент, когда обе стороны сказали «да, это то, что мы делаем.»

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

Распространённые ошибки, чтобы избежать

• Быть слишком нечётким. «Работа дизайна» означает всё для кого-либо. Укажите ровно что вы проектируете, сколько вариаций и в каком формате.
• Отсутствующие исключения. Если вы не перечислите, что находится, всё находится — по крайней мере в памяти клиента.
• Нет процесса изменения. Как вы обрабатываете запросы вне сферы? Определите это авансом. Простое предложение вроде «запросы вне сферы будут обрабатываться через заказы изменений» сохраняет недели переговоров позже.
• Пропуск подписи. Без подписей, SOW — это предложение. Получите его подписанным перед началом работы.
• Один размер подходит всем. Проект в $2,000 и проект в $50,000 не нуждаются в одинаковой глубине SOW. Масштабируйте документ к контракту. Маленький проект может потребовать одностраничный SOW. Корпоративный контракт может потребовать десять страниц с приложениями.

Когда использовать полный объём работы вместо этого

Некоторые проекты нуждаются в большем, чем объём работы. Рассмотрите полный объём работы, когда:

• Бюджет проекта превышает $25,000 или временная шкала больше 3 месяцев.
• Вы работаете с корпоративными клиентами, которые требуют юридических условий и пунктов ответственности.
• Контракт включает передачу интеллектуальной собственности или конфиденциальную информацию.
• Несколько фаз будут выставлены отдельно с отдельными вратами одобрения.
• Субподрядчики или третьи стороны участвуют в доставке.

Объём работы включает всё в SOW плюс юридическую защиту, пункты расторжения и подробное управление. Используйте шаблон объёма работы для этих ситуаций.

Получите шаблон

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

Или управляйте сфетой, временем и счётами в одном месте с Workify. Посмотрите, как управление сфетой вписывается в полный цикл прибыльности →