Со стороны это выглядит странно: гиганты тратят месяцы на то, что один инженер может «накидать» за выходные. Критики винят «слабых инженеров», «раздутый Agile» или ленивых программистов. Защитники говорят «это масштаб». Истина менее эмоциональна и более математична: по мере накопления фич число их взаимных зависимосте и пересеченмй лавинообразно растет. Любая новая фича требует проверки огромной сети зависимостей, граничных условий и различных политик (типа GDPR). Этот нарастающий «налог на взаимодействие» и делает инженеринг больших продуктов медленнее — но одновременно приносит и большие деньги.
Популряные версии — Почему они промахиваются
- Неэффективные инженеры. Реальность: найм не идеален, но в экономике не сходились бы цифры, если бы тысячи инженеров не окупались. Они окупаются, потому что маржинальные фичи добавляют выручку.
- Виноват процесс (Agile как зло). Процессы могут мешать, но даже с простым процессом сложность от взаимодействий никуда не исчезает.
- Лень. Мотивация важна, но системное замедление вызвано устройством продукта, а не моральными качествами людей.
- Координационные издержки. Координация важна, но чаще это следствие сложности взаимодействий фич.
- Масштаб трафика. Нагрузка реальна, но её проще укротить, чем масштаб фич. В зрелых продуктах именно масштаб фич определяет сроки поставки.
Настоящая причина: Комбинаторный взрыв взаимодействия фич
Каждая новая фича потенциально влияет на все предыдущие. При десятках или сотнях фич вы проверяете тысячи возможных взаимодействий. Даже отличная архитектура не отменяет эту математику — она лишь снижает боль.
Простой пример: добавить «Экспорт в Excel».
- UI: Куда поставить кнопку, не захламляя интерфейс и не ломая паттерны?
- Доступ: Кому разрешен экспорт? Что с полями только для админов?
- Конфиденциальность: Входят ли персональные данные?
- Производительность: Стримить или буферизовать, чтобы избежать таймаутов и всплесков памяти?
- Комплаенс: Ограничивают ли локализация данных (GDPR) состав выгрузки?
- Наблюдаемость: Как логировать экспорт, не утекут ли чувствительный данные?
Теперь умножьте это на каждую фичу, под каждую платформу и каждый регион.
Что такое «Балансировка фич» на практике
Поставка в больших продуктах — это бесконечное «уравновешивание» новых и старых фич, чтобы продукт оставался целостным. Типовые конфликты:
- Дизайн: Две фичи требуют одно и то же место в UI или разные паттерны взаимодействия.
- Концепция: Новая модель рушит подходы в других модулях (например, «удалить данные» vs «расширить общие данные»).
- Производительность: Дорогая операция начинает срабатывать тысячи раз в секунду из-за нового триггера.
- Комплаенс и юр-риски: Регламенты хранения, доступности и экспортируемости распространяются на сервисы и страны.
- Организация кода: Границы владения, версионирование и зависимости усложняют изменения.
- Безопасность и права: Проверки ролей/атрибутов разрастаются вместе с фичами и типами пользователей.
- Релизы и поддержка: Дежурства, планы отката и плейбуки поддержки должны эволюционировать под каждое изменение.
«Зловещие‑фичи»: множетели сложности
Есть фичи, которые взаимодействуют почти со всем. Эти «зловещие‑фичи» навсегда поднимают уровень сложности:
- Новые типы пользователей/ролей: Каждая фича должна отвечать «доступно ли этой роли — и как именно?».
- Хранение данных: Изоляция и хранение по регионам затрагивают каждый сервис и API.
- Локализация и доступность: Изменения лэйаута и поддержка ассистивных технологий — на каждом экране.
- Оффлайн/синхронизация: Разрешение конфликтов и свежесть данных пронизывают весь стек.
Зачем их реализовывать? Они привлекают крупных enterprise‑клиентов и новые рынки. Выгода реальна — сложность принимают осознанно (но не всегда и не на всех уровнях).
Почему продукты продолжают добавлять фичи: малые приросты — огромные деньги
В зрелых продуктах маленькие фичи дают целые процентные пункты выручки. 1% на многомиллиардном направлении окупает целые команды. Стартапы гонятся за product market fit; большие компании оптимизируют маржу. Поэтому инвестируют в кажущиеся мелкие, но прибыльные фичи — даже если каждая увеличивает когнитивную нагрузку.
Почему просто не делать меньше фич?
Лидеры пытаются. Многие инициативы режут до релиза, когда становится ясно: дальнейшая сложность дороже выгоды. Со стороны это выглядит как «месяцы впустую». Изнутри — здравое управление: дисциплина «затраты–выгода» с учетом налога на взаимодействия.
Стартапы vs Big Tech: почему скорости отличаются?
- Стартапы: Скорость дает маленький набор фич и мало ограничителей. Не копируйте enterprise‑процессы раньше времени; откладывайте зловещие‑фичи, пока нет жесткой необходимости.
- Масштабирование: С ростом выручки мотивация добавлять маржинальные фичи взлетает. Ваша скорость будет стремиться к скорости Big Tech, если активно не управлять сложностью.
Как дольше оставаться быстрыми: практические приемы для команд
- Введите бюджет фич: Ограничьте параллельные инициативы; меняйте новые фичи на удаление старых.
- Оценивайте «налог на взаимодействия»: В планах явно перечисляйте затронутые фичи, роли, регионы, системы.
- Используйте фича флаги: Снижайте «радиус поражения», поэтапно раскатывайте, делайте откаты простыми.
- Проектируйте модель прав на ранних этапах: Единый источник истины для ролей, областей действия и политик.
- Избегайте случайных зловещих‑фич: Например откладывайте новые типы пользователей до четкого ROI.
- Прокладывайте «золотой путь»: Платформенные команды дают «благословленные» библиотеки, паттерны и пайплайны для снижения вариативности.
- Легализуйте удаление фич: Сделайте удаление низкополезных фич OKR’ом с коммуникацией и миграциями для клиентов.
- Запускайте «анализ сложности»: Предрелизные проверки взаимодействий (безопасность, приватность, производительность, поддержка).
- Инвестируйте в наблюдаемость: Логи, трассировка и SLO снижают ментальную нагрузку и риски изменений.
- Измеряйте поток, а не только выход: Lead time, доля неудачных изменений, MTTR и операционную стоимость изменения.
Ключевые выводы
- Замедление — не про некомпетентность, а про нарастающие взаимодействия фич.
- «Зловещие‑фичи» (новые роли, окружения, правила данных/регионов) — постоянные множители сложности.
- Маржинальные фичи приносят значимую выручку, оправдывая инвестиции несмотря на рост когнитивной нагрузки.
- Ускорение держится на бюджете фич, агрессивном удалении старых, а также продуманной модели прав, наблюдаемости и простых откатов с первого дня.
Если вы строите масштабируемый продукт, смиритесь с математикой: «налог на взаимодействия» не устранить, но им можно управлять. В этом и заключается ремесло и ценность инжиниринга.
