Заказ сайта, сервиса или приложения редко срывается из-за одной ошибки. Чаще проект трещит по швам там, где перед стартом махнули рукой: не описали результат, не проверили команду, не закрепили права, не спросили про поддержку. До договора всё это решается дешевле.
С какой цели начинается заказ цифрового проекта
Перед заказом цифрового проекта надо зафиксировать бизнес-задачу, будущих пользователей и измеримый результат. Если цель звучит как «сделать красиво» или «обновить сайт», подрядчик получит простор для догадок, а заказчик — спорный результат.
На практике разговор часто начинается с дизайна. Цвета, экраны, примеры конкурентов, «хотим примерно так». А ведь сначала надо понять, зачем проект вообще появится на свет. Интернет-магазину нужны заказы и удобная корзина. Сервису записи — меньше звонков администратору и понятный календарь. Корпоративному сайту — заявки от тех, кто уже созрел для переговоров. Разные цели дают разные решения, даже если внешне проекты похожи.
Команда экспертов обычно начинает с короткой диагностики. Не с вдохновляющей презентации, а с неприятных вопросов: кто будет пользоваться продуктом, где сейчас теряются заявки, какие данные надо передавать в отдел продаж, кто будет менять тексты через месяц после запуска. В этих вопросах нет блеска, зато там лежит будущий бюджет.
| Что уточнить до старта | Зачем это нужно | Плохой сигнал |
|---|---|---|
| Цель проекта | Помогает выбрать состав работ | «Нам просто нужен новый сайт» |
| Аудитория | Влияет на сценарии и тексты | «Для всех клиентов сразу» |
| Метрики | Показывают, достигнут ли результат | «Поймём после запуска» |
| Ответственные со стороны заказчика | Сокращает задержки по согласованиям | «Будут отвечать разные люди» |
Есть простой тест. Если через десять минут нельзя объяснить, почему проект нужен именно сейчас, какие процессы он меняет и кто будет оценивать результат, заказ рано отдавать в работу. Не потому что подрядчик плох. Просто пустоты в задаче он заполнит своим опытом, а не вашей реальностью.
Как оценить подрядчика до подписания договора
Подрядчика проверяют по релевантным работам, составу команды, вопросам на старте, прозрачности сметы и готовности обсуждать риски. Портфолио без объяснения задачи, роли исполнителя и результата почти ничего не доказывает.
Красивые экраны обманывают особенно легко. На них не видно сорванных сроков, слабой административной панели, тяжёлой загрузки страниц и конфликтов вокруг правок. Поэтому смотреть надо не только на картинку. Попросите разобрать один прошлый проект: с какой задачей пришёл клиент, что изменилось в процессе, какие решения отбросили, кто отвечал за аналитику, дизайн, разработку и тестирование.
Хороший признак — подрядчик не обещает всё сразу. Он уточняет ограничения, просит доступ к текущей статистике, задаёт вопросы о продажах, складе, юридических текстах, интеграциях. Поисковая оптимизация (SEO), реклама, личный кабинет, оплата, обмен с системой учёта — каждое слово тянет за собой работу, сроки и деньги. Если всё это умещается в одну строку сметы, впереди почти наверняка появятся доплаты.
- Попросите показать не только главные страницы, но и внутренние состояния: ошибки форм, пустую корзину, письмо пользователю, экран после оплаты.
- Уточните, кто именно будет вести проект после продажи: менеджер, аналитик, дизайнер, разработчик или один человек на все роли.
- Проверьте, как подрядчик описывает этапы: исследование, прототип, дизайн, разработка, тестирование, запуск, поддержка.
- Спросите про спорные ситуации: что происходит, если заказчик меняет задачу, а подрядчик не укладывается в срок.
Кстати, настораживает не высокая цена сама по себе. Опаснее цена, которую невозможно разложить на части. Когда смета показывает трудозатраты и границы работ, с ней уже есть о чём говорить. Когда в документе одна крупная сумма и бодрое обещание «сделаем всё», разговор держится на доверии, а доверие в проекте без документов быстро кончается.
Какие документы и права надо закрепить заранее
До начала работ надо закрепить техническое задание, состав этапов, порядок согласований, стоимость изменений, сроки, права на результат и условия доступа к материалам. Устные договорённости в цифровых проектах исчезают первыми, как только начинается спор.
Договор не спасает слабую задачу, но даёт опору, когда проект становится сложнее. В нём должны быть не только сумма и дата запуска. Нужны приложения: описание работ, список страниц или функций, требования к передаче исходников, порядок приёмки, условия поддержки. Без этих деталей каждая правка превращается в отдельные переговоры.
Отдельная тема — права. Дизайн-макеты, программный код, тексты, фотографии, домен, хостинг, доступы к аналитике и рекламным кабинетам должны принадлежать заказчику либо передаваться ему в понятном объёме. Иначе через год может выясниться, что сайт есть, а перенести его нельзя; реклама работает, а доступ только у бывшего подрядчика; шрифты куплены на чужой аккаунт.
| Пункт договора | Что проверить |
|---|---|
| Техническое задание | Функции, страницы, интеграции, ограничения, языковые версии |
| Приёмка | Срок проверки этапа, формат замечаний, число итераций |
| Права | Передача макетов, кода, текстов, графики, доступов |
| Изменения | Как оцениваются новые задачи после утверждения объёма |
| Поддержка | Срок реакции, перечень работ, цена часа или пакета |
Бывает, заказчик стесняется просить детализацию, будто недоверие испортит отношения. На деле всё наоборот. Внятные документы берегут обе стороны: подрядчик не получает бесконечный поток «ещё маленьких правок», заказчик не платит за то, что считал включённым с первого дня.
Что проверить в бюджете, сроках и запуске
Бюджет цифрового проекта надо проверять по составу работ, резерву на изменения, стоимости поддержки и расходам после запуска. Сроки надо оценивать не только по работе подрядчика, но и по скорости согласований, подготовке контента и доступам.
Самая частая иллюзия — считать запуск финишем. Ночью перед релизом обычно всплывают тексты, юридические страницы, письма, редиректы, счётчики, формы, уведомления, тестовые платежи. Каждая мелочь по отдельности кажется небольшой. Вместе они занимают дни, а иногда недели.
Бюджет тоже живёт шире сметы на разработку. Нужны домен, хостинг, лицензии, платные сервисы, фотографии, иллюстрации, настройка аналитики, иногда поисковая оптимизация на старте. Если проект связан с заявками, понадобится передача данных в систему продаж или хотя бы понятная таблица для менеджеров. Иначе красивый интерфейс будет собирать обращения в пустоту.
- Соберите все доступы до старта: домен, хостинг, почта, аналитика, рекламные кабинеты, прежняя административная панель.
- Назначьте одного ответственного за согласования, иначе каждое решение разойдётся на несколько версий.
- Подготовьте контент заранее: тексты, цены, фотографии, юридические данные, контакты, реквизиты.
- Заложите резерв бюджета на новые идеи, которые появятся после прототипа и первых тестов.
- Попросите план запуска: кто переносит сайт, кто проверяет формы, кто следит за ошибками в первые дни.
Сроки стоит считать через календарь людей, а не через надежду. Если директор согласует макет раз в две недели, проект не закончится за месяц даже при сильной команде. Если тексты пишет отдел продаж между встречами, страницы будут ждать. Здесь нет драмы, только арифметика.
Перед оплатой первого счёта полезно устроить короткую проверку здравого смысла. Понятна ли цель? Видно ли, кто делает работу? Зафиксированы ли права? Есть ли план запуска и поддержки? Если на эти вопросы даны ясные ответы, проект входит в работу без лишней лотереи.
Цифровой проект редко бывает без сюрпризов. Но неприятные сюрпризы почти всегда имеют предысторию: не заданный вопрос, пустой пункт договора, забытый доступ, смета без расшифровки. Чем раньше эти места найдены, тем меньше ночных писем, срочных доплат и раздражения после запуска.