Расскажи о случае когда продавал идею своему сотруднику

Как я убедил команду в необходимости переходить на облачные решения

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

Исходная ситуация

Проблемы, которые мы видели:

• Время деплоя составляло 4-6 часов
• Масштабирование требовало закупки нового оборудования (3-4 месяца согласования)
• Отсутствовала автоматизация тестирования
• Техническое обслуживание требовало выделенной команды
• Мы теряли клиентов из-за недоступности сервиса в пиковые периоды

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

Как я строил аргументацию

Шаг 1: Слушал его опасения Не пытался сразу убеждать. Спросил: "Что конкретно тебя беспокоит?" Выслушал про архитектурные вопросы, безопасность данных, сложность DevOps. Это показало мне, что он думает системно.

Шаг 2: Строил стратегию на его сильных сторонах Предложил ему стать техническим лидом этого проекта. Сказал, что его критическое мышление как раз и нужно, чтобы сделать переход безопасным. Это превратило его из скептика в заинтересованного участника.

Шаг 3: Показал данные и риски Подготовил сравнительную таблицу:

• ROI от уменьшения времени деплоя
• Стоимость отдельного DevOps инженера vs. облачные сервисы
• Вероятность падения production (текущая vs. облако)
• Время доступа новых разработчиков на проект

Шаг 4: Предложил пилот вместо полной миграции Это был ключевой момент. Вместо "переходим всё на облако!" предложил: "Давай возьмём самый некритичный микросервис и пилотим на AWS за 2 недели. Если не сработает — ничего не потеряем".

Результат

Он согласился возглавить пилот. За 2 недели мы:

• Выложили сервис на AWS
• Настроили CI/CD
• Автоматизировали тесты
• Получили деплой за 20 минут

Видя результат, он сам стал главным адвокатом полной миграции в команде. Спустя год все наши сервисы работали в облаке, время deply упало с 6 часов до 15 минут, а стоимость инфраструктуры снизилась на 40%.

Что я вынес из этого

Ключевые принципы продажи идеи:

1. Слушай сначала — понимание опасений инженера стоит больше, чем красивая презентация
2. Делай скептика соучастником — дай ему роль в реализации
3. Используй данные — эмоции ненадежны, цифры работают
4. Минимизируй риск — пилот вместо full commitment
5. Показывай победы — маленькие результаты мотивируют лучше любых обещаний

Этот опыт научил меня, что best product managers видят в каждом скептике не преграду, а потенциального союзника.