Назвать цену сразу удобно: заказчик быстро получает цифру, разработчик быстрее отправляет предложение. Но без понимания цели, исходного состояния и границ эта цифра будет либо завышенным запасом на неизвестность, либо обещанием, которое позже придётся пересматривать.
Вопросы до оценки — не способ затянуть старт. Это способ не продавать заказчику случайную цифру.
Почему одного описания функции недостаточно
Фраза «нужно подключить доставку» может означать установку готового модуля, карту пунктов выдачи, расчёт по габаритам, разные договоры для регионов, передачу маркировки и синхронизацию статусов. В интерфейсе задача выглядит одинаково, но объём отличается в разы.
То же происходит с импортом товаров, CRM, личным кабинетом и checkout. Цена зависит не от названия функции, а от данных, правил, интеграций и критериев готовности.
О чём я спрашиваю перед оценкой
1. О бизнес-результате
Что должно измениться после разработки: больше заказов, меньше ручной работы, новый способ продажи, снижение ошибок или перенос с устаревшей платформы? Цель помогает отличить обязательную функцию от пожелания.
2. О текущем объекте
Какая версия WordPress и WooCommerce используется, какая тема активна, где находятся кастомизации, какие плагины и интеграции уже работают? Перед доработкой важно прочитать систему, а не оценивать её по скриншоту.
3. О пользователях и сценариях
Кто будет использовать функцию: покупатель, менеджер, оптовый клиент, администратор? Что происходит до и после действия? Какие состояния считаются ошибкой?
4. О данных и внешних сервисах
Откуда поступают товары, цены и остатки, куда уходят заказы, кто отвечает за формат обмена, есть ли документация и тестовая среда? Интеграция всегда зависит как минимум от двух систем.
5. Об ограничениях
Есть ли дата запуска, фиксированный бюджет, сезонный пик, требования безопасности, SEO-ограничения и допустимое время простоя? Одну цель можно достигнуть разными способами, если приоритеты известны.
6. О критериях приёмки
Как мы вместе поймём, что задача выполнена? Формулировка «доставка подключена» слабее, чем перечень проверяемых тарифов, регионов, способов оплаты и статусов заказа.
Как вопросы защищают бюджет
| Без аналитики | После уточнения |
|---|---|
| Оценивается первое решение | сравниваются несколько способов достичь цели |
| Неизвестные спрятаны в общей цене | риски и допущения показаны отдельно |
| Пожелания смешаны с обязательным | scope разделён на запуск и опции |
| Сдача определяется субъективно | есть проверяемые критерии готовности |
| Изменения воспринимаются как «то же самое» | видно, что входит в оценку, а что меняет scope |
Предварительная аналитика снижает вероятность двух неприятных сценариев: подрядчик заметно повышает цену в середине проекта или экономит на невидимых работах, чтобы уложиться в слишком раннее обещание.
Почему я иногда предлагаю платную диагностику
Короткую типовую задачу часто можно оценить после нескольких вопросов. Но если сайт давно дорабатывался разными специалистами, ошибка возникает нерегулярно или нужна сложная интеграция, сама постановка задачи требует работы.
Диагностика может включать чтение кода и настроек, воспроизведение проблемы, изучение API, проверку данных и подготовку вариантов решения. Её результат — не абстрактная консультация, а материал для принятия решения.
- описание текущего состояния и причины проблемы;
- карта затронутых компонентов и рисков;
- варианты реализации с ограничениями;
- рекомендуемый scope и этапы;
- критерии приёмки;
- уточнённая оценка или обоснованный диапазон.
Почему аналитика полезна, даже если разработку выполнит другой
Хороший результат диагностики отделён от конкретного исполнителя. Заказчик получает понятное описание задачи, может сравнить предложения на одинаковой основе и не оплачивает повторное исследование каждому новому специалисту.
Когда возможна фиксированная цена
Fixed Price работает, когда границы и критерии достаточно определены, а неизвестные устранены или явно распределены. Тогда подрядчик может принять на себя риск реализации в согласованном scope.
Если задача исследовательская, зависит от меняющихся требований или неизвестного внешнего API, разумнее сначала провести диагностику, разделить работу на этапы либо использовать почасовую модель с контрольными точками.
Какие ответы ускоряют оценку
- Дайте ссылку на сайт и доступ к тестовой среде, если он нужен для чтения объекта.
- Опишите проблему через конкретный пользовательский сценарий.
- Приложите примеры данных, ошибок и ожидаемого результата.
- Перечислите обязательные интеграции и предоставьте документацию API.
- Назовите желаемый срок и бюджетный ориентир — это помогает выбрать реалистичный вариант.
- Отделите обязательное для запуска от идей на следующий этап.
Цена появляется после понимания ответственности
Оценка — это не угадывание количества часов. Это обещание выполнить определённый объём работы с понятным результатом. Чем точнее сформулированы цель, границы и проверки, тем меньше заказчик платит за неопределённость.
Начнём с правильных вопросов
Опишите задачу своими словами, даже если готового технического задания нет. Я задам вопросы о процессе, прочитаю текущий объект и определю, нужна ли отдельная диагностика. После этого предложу формат, этапы и цену, которую не придётся объяснять неожиданными доплатами в середине проекта.
Хотите обсудить проект?
Напишите задачу — предложим решение, сроки и этапы. Без воды.
