Клиент просит «ещё одну маленькую функцию» в середине проекта?

Проблема: «Маленькая» функция – стоит ли браться?

Вы на полпути к завершению проекта. Клиент или начальник говорит: «Просто добавьте выгрузку в Excel. Два дня, не больше?»

Звучит несложно. Но любой, кто управлял проектами, знает: такие «мелкие» функции часто становятся началом расползания объёма. Худший сценарий: вы соглашаетесь, команда работает сверхурочно, тестирование выявляет проблемы с форматами, правами доступа, а потом ещё и сопровождение. Дедлайн срывается, качество страдает, клиент недоволен.

Отказать – рискуете обидеть клиента или показаться некомпетентным.

Это классическая дилемма PM в небольшой команде. У нас нет процессов и коммерческих отделов, чтобы прикрыть, ни ресурсов на детальный анализ влияния. Но именно из-за того, что мы малы, нужно быстро принимать решения и направлять энергию в нужное русло.

Моё правило: сначала задать четыре вопроса

Когда я руководил проектами в Wangri Shiguang и Shanhe Network, я сталкивался с этим постоянно. В итоге я разработал простой фреймворк – никаких сложных инструментов, достаточно блокнота. Каждый раз, когда поступал запрос в середине спринта, я задавал четыре вопроса:

1. Необходима ли эта функция для текущей цели проекта? Если она часть контракта или документа с требованиями, это не изменение – это пробел, который нужно закрыть. Если она полностью выходит за первоначальные рамки, переходим к следующему вопросу.
2. Как это повлияет на текущий график? Не просто «сколько дней разработки?», а «задержит ли это какой-либо критический этап?» Если да, то что будет сдвинуто?
3. Какова стоимость тестирования и регрессии? Небольшие команды часто учитывают только разработку. Функция экспорта может включать множество полей, разрешений, граничных случаев – тестирование может занять больше времени, чем кодирование.
4. Какова цена отказа? Рассердится ли клиент? Пригрозит ли прекратить дальнейшее сотрудничество? Или это «хорошо бы иметь», что не влияет на основное использование?

Эти четыре вопроса не требуют идеальных ответов, но они быстро выявляют уровень риска.

Гипотетический пример

Предположим, мы создаём CRM для клиента. Основные функции – управление клиентами и журнал взаимодействий. На третьей неделе клиент говорит: «Не могли бы вы добавить функцию экспорта списка клиентов в Excel?»

Звучит просто. Но реальное влияние:

• Нужно согласовать поля для экспорта (в интерфейсе отображаются только некоторые; должны ли в экспорте быть все?)
• Права доступа: не все роли могут экспортировать – нужна проверка ролей
• Объём данных: если тысячи записей, экспорт может потребовать пагинации или асинхронной обработки
• Тестирование: пустые данные, огромные данные, перехват прав – минимум 3-4 дня тестирования

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

Фреймворк решения: принять, согласовать или отказаться

На основе четырёх вопросов я сопоставляю три варианта:

1. Принять

Условие: функция мала и необходима (без неё проект не сдать), есть явный запас по времени, низкая стоимость тестирования. Действие: немедленно скорректировать график, уведомить команду, зафиксировать изменение.

2. Согласовать

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

• Вариант A: принять функцию, но сдвинуть дату сдачи на X дней
• Вариант B: сохранить исходную дату, но убрать или заменить существующую функцию, сохранив общий объём работ
• Вариант C: перенести эту функцию во вторую фазу, завершив текущий объём

Ключевое: не говорите просто «нет». Скажите: «Если мы это добавим, вот чем придётся пожертвовать». Пусть клиент увидит компромисс.

3. Отказаться

Условие: функция не связана с основными целями и несёт высокий риск (например, технический долг или проблемы безопасности), или клиент просто спросил мимоходом, и без неё он не будет расстроен. Действие: вежливо объяснить, почему нет, и предложить обходное решение (например, использовать существующие функции или ручной экспорт).

Практический чек-лист

Чтобы избежать ситуативных решений, я позже составил короткий чек-лист, который согласовывал с командой до начала проекта:

• Выходит ли этот запрос за первоначальные рамки?
• Если принять, какие существующие задачи нужно перепланировать?
• Каково минимальное время на тестирование и регрессию?
• Есть ли обходное решение (например, использовать существующие функции + ручные действия)?
• Насколько обратима эта функция? Можно ли легко убрать её позже, если потребуется?
• Готов ли клиент платить дополнительно за эту функцию?

Последний вопрос критичен. Если клиент готов платить, значит функция действительно важна для него, и это даёт команде буфер. Если нет – скорее всего, это случайное пожелание.

Заключительные мысли

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

Этот фреймворк не идеален, но он даёт вам чёткую позицию перед клиентом, начальником и командой. В следующий раз, когда кто-то попросит «ещё одну маленькую функцию», остановитесь, задайте себе четыре вопроса и уверенно выберите: принять, согласовать или отказаться.

PaxLee