Клиент требует сократить сроки

Решение

1. Стратегия переговоров с клиентом

Нужно провести переговоры профессионально, не отвергая требование с места в карьер:

Слушание и понимание мотивации

• Попросить у клиента подробнее рассказать про задачу у его знакомого: какие были требования, архитектура, возможности переиспользования кода, опыт команды
• Понять его бюджетные и бизнес-ограничения — может быть, это давление вышестоящего руководства
• Выяснить, критичны ли именно 25 часов или есть гибкость

Обоснование оценки

• Показать детальный breakdown: анализ 5ч, дизайн 8ч, разработка 20ч, тестирование 5ч, финализация 2ч
• Объяснить риски: спешка = баги, утечки безопасности, техдолг, невозможность провести полное тестирование
• Подчеркнуть: наша оценка 40 часов базируется на опыте и включает качество, которое гарантирует долгосрочную стабильность
• Упомянуть, что сравнение с другим проектом некорректно — разный контекст, разные команды, разные требования

Переход к решению проблем

• Не занимать оборонительную позицию «невозможно», а предложить конструктивные варианты
• Показать готовность искать компромисс, но в рамках разумного

2. Варианты ускорения разработки

Вариант 1: Параллелизм и ресурсы (сокращение на 10-15%)

• Добавить ещё одного разработчика на часть фичи → минус 4-6 часов
• Увеличить объём параллельных работ (фронт + бэк одновременно) → минус 2-3 часа
• Стоимость: растёт зарплата, растёт чувство срочности

Вариант 2: Упрощение scope (сокращение на 30-40%)

• Исключить сложный функционал: например, без интеграции с внешней системой, без расширенной аналитики, без поддержки мобильных браузеров
• Использовать готовые UI-компоненты вместо кастомных
• Минимальное покрытие тестами (только smoke-тесты) вместо полного
• Стоимость: качество хуже, будущие доработки дороже, риск переделок

Вариант 3: Переиспользование кода (если применимо)

• Использовать готовые библиотеки, шаблоны, previous projects code
• Минус 5-10 часов на анализ и адаптацию
• Предусловие: код совместим и хорошо документирован

Вариант 4: Двухфазная доставка (промежуточный вариант)

• Phase 1 (25 часов): core функционал, базовое качество
• Phase 2 (15 часов): полировка, оптимизация, доп. фичи
• Преимущество: клиент видит результат быстро, может уже использовать, доп. работа планируется отдельно

3. Компромиссы: готовы vs не готовы

Готовы идти на компромиссы:

• Переработка для команды в разумных пределах (перейти на 44-50 часов в неделю) → минус 3-5 часов
• Упрощение документации до минимума → минус 2 часа
• Сокращение количества code review циклов → минус 1-2 часа
• Использование более простых подходов в архитектуре (если они удовлетворяют требованиям) → минус 2-3 часа
• Максимум: сокращение на 10-15%, что даёт нам 34-36 часов вместо 40

НЕ готовы идти на компромиссы:

• Полностью исключать тестирование — это путь к production-багам
• Игнорировать архитектурные решения, которые обеспечивают масштабируемость
• Скрывать риски и обещать невозможное ради поддержания отношений
• Сокращать security-требования
• Ускорять за счёт качества без согласия стейкхолдеров на внесение известных рисков в docs

Как это оформить:

• Если идём на сокращение: создаём Risk Register и получаем письменное согласие клиента на известные риски
• Если не проходит: предлагаем дальше работать в режиме Phase 1/2, где первая фаза в 25 часов даёт 60-70% функционала

Итог

Задача PM не в том, чтобы просто выполнить, а в том, чтобы управлять ожиданиями и рисками. Конструктивный диалог, данные и варианты — вот что убеждает клиентов лучше, чем просто отказ. А в конце дня, если клиент настаивает на невозможном, это должно быть документировано и согласовано в письменном виде.