С каким заказчиком было тяжело работать

Сложный заказчик: анализ случая и стратегии работы

В моей практике наиболее сложным был заказчик из крупного финансового сектора, который пришел к нам с проектом разработки CRM-системы для управления премиальными клиентами. Сложность заключалась не в технических требованиях, а в сочетании перфекционизма, частых изменений приоритетов и ограниченной вовлеченности ключевых стейкхолдеров.

Анализ проблемных зон:

1. Неопределенность требований на старте:

    *   Заказчик предоставил только общее видение: "нужна современная CRM, как у ведущих банков".
    *   Отсутствовала детализация процессов, интеграций с legacy-системами и четких критериев приемки.

1. Критически низкая доступность Subject Matter Experts (SME):

    *   Бизнес-аналитики и конечные пользователи со стороны заказчика были перегружены операционной работой.
    *   Сессии по уточнению требований постоянно переносились или проводились с их заместителями без права принятия решений.

1. Паттерн "последних правок":

    *   После согласования спринта и демонстрации готового функционала ключевой стейкхолдер (руководитель департамента) регулярно вносил фундаментальные правки, не учитывая сделанную работу. Классический пример:

```javascript
// Было согласовано и реализовано:
function calculateLoyaltyBonus(clientTier, annualSpend) {
    if (clientTier === 'platinum') return annualSpend * 0.1;
    if (clientTier === 'gold') return annualSpend * 0.05;
    return annualSpend * 0.02;
}
```

    *   После демо поступал запрос: "А давайте добавим еще 5 уровней клиентов, и чтобы бонус зависел от сезонности и региона". Это сбрасывало оценку и план работ.

Примененные стратегии и решения:

Чтобы переломить ситуацию, мы инициировали серьезный пересмотр процессов взаимодействия:

1. Внедрение двойного гейта для изменений:

    *   Все новые пожелания и правки фиксировались не напрямую в бэклог, а в отдельный реестр **Change Request (CR)**.
    *   Каждый CR оценивался командой на предмет влияния на сроки и бюджет. Решение о реализации принималось на еженедельном **Change Control Board (CCB)**, куда входили с обеих стороны: я (PM), техлид, главный архитектор заказчика и его финансовый представитель. Это резко снизило количество "хотелок".

1. Жесткая формализация процесса утверждения требований:

    *   Мы перешли от голословных утверждений к подписанию **протоколов совещаний (MOM)** и **спецификаций требований (SRS)**.
    *   Был внедрен **процесс "заморозки" требований** на время спринта (2 недели). Любые изменения внутри итерации становились предметом отдельного мини-CR с быстрой оценкой.

1. Смена фокуса с "фичи-дривена" на "ценностно-дривенный" подход:

    *   Вместо обсуждения кнопок и полей мы начали каждую сессию с вопроса: "Какую бизнес-проблему это решает?" и "Как мы измерим успех этой функции?".
    *   Мы визуализировали **рост технического долга** из-за постоянных изменений и его будущее влияние на стоимость владения системой. Это помогло достучаться до финансового контролера заказчика.

1. Инвестиции в коммуникацию и прозрачность:

    *   Помимо стандартных отчетов, мы внедрили **публичный дашборд проекта** (на базе Jira/Confluence), доступный всем стейкхолдерам.
    *   Мы проводили короткие (15 мин.) ежедневные стендапы не только внутри команды, но и **расширенный стендап для заказчика** три раза в неделю, куда приглашались все желающие. Это снизило уровень недоверия и слухов.

Итог: Проект был успешно сдан с 4-месячным сдвигом от первоначально оптимистичного плана, но в рамках скорректированного бюджета. Главным уроком стало понимание, что со сложным заказчиком нельзя работать "как обычно". Необходимо проактивно выстраивать и постоянно адаптировать процессные рамки (governance), делая ставку на максимальную формализацию, прозрачность и совместное принятие решений. Ключевая компетенция PM в такой ситуации — не столько менеджмент задач, сколько менеджмент ожиданий и изменений.