Что будешь делать если заказчик не принимает проект?

Действия при отказе заказчика принять проект

Это критическая ситуация, которая требует системного подхода. Я сталкивался с такими случаями и вывел чёткий алгоритм действий.

Фаза 1: Диагностика

Первое, что нужно сделать — понять истинную причину отказа. Здесь важна активная коммуникация:

• Провожу встречу с заказчиком — устную, не письменно. Спрашиваю конкретные вопросы: какие требования не выполнены, какие функции отсутствуют, что не соответствует ожиданиям
• Просю доказательства — не просто мнение, а конкретные примеры. "Система медленная" — это неточно. "Поиск по 10000 товаров занимает 5 секунд, требуется менее 1 секунды" — это диагностируемо
• Уточняю требования — часто оказывается, что заказчик ошибался в оригинальных требованиях, и мы их выполнили правильно

Фаза 2: Анализ расхождений

Я создаю документ "Расхождений анализ":

Требование (из TOR):        "Система должна обрабатывать 100 заказов в день"
Реализация:                 Система обрабатывает 50 заказов в день
Причина расхождения:        В TOR не указана система оплаты, которая добавила задержку в 5 сек на запрос
Вина:                       Совместная (недочет TOR + недопланирование)
Решение:                    Оптимизация запросов к БД, кэширование, асинхронная обработка
Оценка стоимости:           +20 часов разработки

Для каждого расхождения я определяю:

• Кто виноват (проектант, разработчик, заказчик, непредвиденные факторы)
• Критичность (блокирует использование или косметический дефект)
• Стоимость исправления

Фаза 3: Переговоры

Если вина на нашей стороне:

• Я беру ответственность на себя: "Мы не додумали эту функцию, исправляем"
• Выделяю ресурсы для исправления (это наша проблема)
• Предлагаю timeline исправления
• Предоставляю компенсацию: скидка на доработки, бесплатный месяц поддержки, расширенные права доступа

Если вина на заказчике (неправильные требования):

• Показываю документ, который он подписал: "Требование № 5 гласит: 'Система должна отправлять SMS', мы отправляем SMS. Но вы теперь хотите WhatsApp'"
• Предлагаю три варианта:
  1. Принять проект как есть (соответствует договору)
  2. Доработать за дополнительные деньги
  3. Переделать требования и перегоревить сроки и стоимость

Если виноваты обе стороны:

• Делю ответственность пропорционально
• Предлагаю справедливое разделение стоимости доработок: часть берёт компания, часть — заказчик

Фаза 4: Подготовка плана действий

Я подготавливаю детальный план исправления:

1. Список доработок с оценками
2. Новая дорожная карта с датами
3. Тестовая программа — как мы будем проверять, что всё исправлено
4. Аддендум к контракту — изменение требований, стоимости, сроков
5. Риск-план — что если что-то пойдёт не так

Фаза 5: Исправление

• Ежедневный мониторинг — я следу за прогрессом, сообщаю заказчику о статусе
• Тестирование вместе — не просто сдаю код, а демонстрирую исправления заказчику
• Быстрые итерации — лучше 10 небольших обновлений чем одно большое
• Поддержка 24/7 — если что-то сломалось, мы срочно исправляем

Пример из жизни: Платёжная система

Заказчик отказался принимать CRM для страховой компании. Причины:

• "Интеграция с 1C работает неправильно"
• "Интерфейс не интуитивен"
• "Отсутствуют отчёты по комиссиям агентов"

Мой анализ показал:

• Проблема 1C: заказчик неправильно настроил параметры подключения (его вина 80%)
• Интерфейс: мы следовали дизайн-системе, но не провели юзер-тестирование (наша вина 60%)
• Отчёты: их не было в оригинальном TOR, но их попросили потом (заказчика вина 100%)

Решение:

• Помогли пересочетать 1C (наша поддержка)
• Провели 2 дня юзер-тестирования, переделали интерфейс на основе фидбека (3 дня разработки)
• Отчёты по комиссиям добавили за дополнительную оплату ($5000)

Результат: Проект был принят, заказчик расширил контракт на дополнительный функционал.

Долгосрочный подход

• Документирование всех требований и решений
• Регулярные демо — не ждём конца проекта, показываем результаты еженедельно
• Feedback loop — активно собираю мнение заказчика в процессе
• Rapport — личные отношения с ключевыми лицами в организации заказчика

Что я НЕ делаю

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

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