В одном из крупнейших российских ритейлеров (X5 Group) команда строила внутреннюю developer platform в стиле Heroku — PaaS-прослойку, которая абстрагировала инфраструктуру от разработчиков. Подход "разрабы — караси": минимум инфраструктурных знаний, максимум продуктивности. Стандартный путь, по которому идут многие компании, включая Авито, которые довели свою платформу (PlatO) до коммерческого продукта.
Пришёл новый PM. Привёл своих девопсов и архитекторов. В первый же понедельник после спринта объявил "ребут 2.0" — всё, что было сделано, объявлено pet-проектом и прожиганием бюджета. Новая архитектура — центральный API-сервер на Java. Обоснование — "большие команды к нам не заехали". На вопрос "кто конкретно сказал, что проект плохой?" — PM елозил и не отвечал.
Философия платформы менялась на противоположную: вместо Heroku-like (абстракция для разработчиков) — конструктор, где разработчики считаются инженерами и сами собирают что нужно. При этом обвинение старой команде: "делали не так и слишком сложно".
- Понедельник: объявление о ребуте, обесценивание всей предыдущей работы
- Неделя: команда на дизморали, микроконтроль, ломка процессов через ногу
- Пятница: публичный конфликт с оскорблениями и обвинениями в манипуляции на собрании департамента
- Двухчасовой созвон с топ-руководством: команда объясняет, что так управлять нельзя. PM отвечает: "не согласен"
- Итог: 5 человек уходят из компании, часть перепрыгивает в другие подразделения
Когда руководство выяснило детали, оказалось, что никакого "пиздец-недовольства" текущим решением не было. Был просто следующий эволюционный шаг, который новый PM превратил в revolution вместо evolution.
Ключевой контекст, который всё объясняет: PM продвигал внедрение Avito PlatO — коммерческого продукта на базе dev-платформы Авито. То есть вся история с "ваш проект — говно" была не про техническое улучшение, а про обоснование закупки конкретного внешнего решения.
Отсюда и паттерн поведения:
- Обесценивание текущего решения с первого дня — нужно создать проблему
- "Архитектура на салфетке" от своих людей — нужно показать, что внутренними силами не вывезти
- Невозможность ответить, кто именно недоволен — потому что недовольных не было
- Жёсткая ломка процессов — чем быстрее убить текущую разработку, тем проще продать замену
Классический vendor play изнутри: приходишь как менеджер, убиваешь внутреннюю разработку, обосновываешь закупку внешнего решения. Вопрос мотивации такого PM — легитимный вопрос для службы безопасности.
Оба подхода к dev-платформам валидны:
- Heroku-like / PaaS: абстрагируем инфру, разрабы деплоят через простой интерфейс. Подходит, когда команды-потребители не хотят и не должны разбираться в Kubernetes.
- Конструктор / Platform Engineering: даём инструменты и golden paths, разрабы сами собирают. Подходит для зрелых инженерных команд.
Выбор зависит от уровня команд-потребителей, а не от того, какой подход "правильнее". Для крупного ритейлера, где разработчики — не все DevOps-инженеры, Heroku-like подход часто разумнее. Переход между подходами — это эволюция, а не "всё сломать и переписать на Java".
При этом пилить свой PaaS для ритейлера — действительно спорное решение. Но "спорное" ≠ "неправильное": масштаб крупных компаний часто делает готовые решения неподъёмными по лицензиям, а internal dev platform — это не обязательно "свой Kubernetes", а часто тонкая прослойка из Helm-чартов, CI-шаблонов и абстракций.
Не просто "5 человек". Людей с глубоким пониманием:
- как строить dev-платформы в энтерпрайзе
- какие боли реальные, а какие выдуманные для обоснования закупок
- как устроена инфраструктура компании изнутри
Этот контекст невозможно передать через документацию. Новая команда PM будет делать то же самое, но дольше и дороже. Через год-полтора — либо "ребут 3.0", либо проект тихо загнётся.
Ирония в том, что один из ключевых инженеров ушёл в компанию, которая делает open-source PaaS на Kubernetes (Cozystack от Aenix). Человек, который строил internal dev platform в энтерпрайзе и видел изнутри, как её убивают ради vendor play — теперь строит продукт, который может стать альтернативой и PlatO, и внутренним разработкам. С личной мотивацией сделать лучше.
PM своими руками создал конкурента для решения, которое сам же продвигал.
- "Новая метла" без диагностики — верный способ потерять команду и экспертизу
- Обесценивание работы в первый день — не менеджмент, а деморализация по учебнику
- Vendor play изнутри — когда менеджер приходит продавать конкретный продукт, а не улучшать процессы, это вопрос к службе безопасности
- Люди с контекстом уходят не "в никуда", а к конкурентам — и уносят с собой понимание проблем, которые можно решить лучше
- Evolution > Revolution: переход между архитектурными подходами должен быть эволюционным, с сохранением команды и знаний