Что будешь делать если клиент при Fix Price хочет несколько новых фич но сроки сдвигать нельзя?

Стратегия управления запросами на новые фичи при фиксированной цене и сроках

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

Пошаговый план действий

1. Немедленный анализ и документирование запроса

    *   Я организую срочную встречу с клиентом и ключевыми членами команды (техлидом, аналитиком). Цель — не отказ, а **глубокое понимание**.
    *   Мы детально записываем каждую новую **фичу** в формате **User Story** или требования. Критически важно выяснить **бизнес-цель** и **ценность** каждой из них для клиента.
    *   Фиксируем все в письменном виде (например, в форме **Change Request** - CR).

```markdown
### Change Request #CR-2024-05-27
*   **Запрос от:** Клиент "X"
*   **Дата:** 27.05.2024
*   **Приоритет (со слов клиента):** Высокий
*   **Описание фичи:** "Добавить экспорт отчета в PDF"
*   **Бизнес-цель:** Сотрудники клиента тратят 2 часа в день на ручное форматирование. Автоматизация сэкономит 10 чел./часов в неделю.
*   **Предполагаемая сложность:** Высокая (требует интеграции новой библиотеки).
```

2. Оценка влияния на проект (Impact Analysis)

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

1. Подготовка альтернативных сценариев и проведение переговоров

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

    > **Вариант A (Приоритизация и замещение):** "Мы *не можем* добавить все фичи в текущие сроки, но *можем* вместе выбрать 1-2 наиболее критичные. Чтобы это сделать, нам нужно **исключить из текущего Scope** функционал сопоставимой сложности. Давайте посмотрим на бэклог и решим, чем мы готовы пожертвовать."

    > **Вариант B (Отложенная реализация - Phase 2):** "Мы включаем эти фичи в **техническое задание на следующий этап (Phase 2)** проекта. Это позволит нам завершить текущий этап в срок и в бюджете, а затем сразу приступить к доработкам. Я подготовлю коммерческое предложение."

    > **Вариант C (Увеличение бюджета с сохранением сроков):** "Для реализации всех запрошенных фич в текущие сроки нам потребуется **экстренно привлечь дополнительных разработчиков или специалистов (например, тестировщиков)**. Это повлечет за собой **пересмотр бюджета** в сторону увеличения. Готовы ли мы обсуждать этот путь?"

    > **Вариант D (Упрощение - "Минимально жизнеспособная фича" - MVP):** "Мы реализуем не полную, а **упрощенную версию** этой функциональности, которая закроет 80% ваших потребностей. Например, экспорт не в идеально оформленный PDF, а в CSV, который можно быстро преобразовать. Это уложится в сроки."

1. Принятие решения и обновление документации

    *   После совместного с клиентом выбора пути, я **официально документирую** решение:
        *   Если выбран вариант A — вношу изменения в **Backlog** и **Scope Statement**, подписываем **дополнительное соглашение** к контракту.
        *   Все изменения в требованиях обязательно отражаются в **Jira/Confluence** или аналогичной системе.
    *   Коммуницирую решение и его причины всей команде, чтобы сохранить **фокус** и мотивацию.

Ключевые принципы, которые лежат в основе этого подхода:

• "Нет" — не ответ. Ответ — это структурированное предложение решений с понятными последствиями.
• Прозрачность и данные. Все переговоры веду на основе оценок команды, а не предположений. Это снимает субъективность.
• Фокус на ценности. Я постоянно направляю диалог с клиентом на обсуждение бизнес-ценности, а не просто технических "хотелок". Это помогает совместно принимать взвешенные решения.
• Проактивность. Лучшая тактика — заранее, на этапе подписания контракта, включить в него четкий процесс управления изменениями (Change Management Process), чтобы в подобных ситуациях все стороны знали "правила игры".

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