Feature Creep (распухание фич)

Фичи продают. Нравится нам это или нет, но встречают по одёжке, в смысле по коробке и по маркетинговым материалам. Если заявленных фич будет меньше, чем у ближайшего конкурента, провалятся продажи.

Если деньги компании приносят продажи, то прямая корреляция тут очевидна: парни, нам нужно больше фич, остальные идеи и опасения засуньте себе в беклог.

Даже если кому-то очевидно, что больше фич означает превращение продукта в слабо-связный и непредсказуемый комбайн, этот голос разума легко и почти всегда теряется перед теми, кто будет продавать и зарабатывать компании деньги. Кто платит/кормит, тот и музыку заказывает.

С инженерной точки зрения распухание количества фич, возможностей и функций несет очевидные (инженеру) проблемы. Объем взаимосвязей и усложнение логики нарастает лавинообразно (иногда экспоненциально), задачи тестирования и интеграции плодятся в комбинаторной прогрессии (вам предстоит тестировать все варианты всех вариантов), распухает сам софт чисто количественно в весе пакетов, всё это устаревает и превращается в легаси, о котором кто-то должен помнить и разбираться — иначе в качестве исследовательской задачи вам предстоит разбираться «кто, нахера это писал, и как оно должно дальше жить».

Механизма убирания фич и уменьшения задач обычно не предусмотрено в принципе. Единожды что-то заявив и реализовав, вам предстоит поддерживать сие в коммерческом продукте вечно — хотя бы потому что гипотетически есть ненулевое количество пользователей (даже выдуманных), которым именно эта фича будет нужна. Сходимость здесь явно не в пользу разработчика.

Даже в древние времена моей работы в/на Microsoft, а это больше десятилетия назад, почти единственным способом для девелопера как-то продвинуть себя по карьерной лестнице было именно запилить фичу в продукт. Неважно, какую. Даже если она дублирует уже существующую фукциональность. Потому что фичи продают, см выше. Что ты готов зарефакторить, улучшить, переделать, итд — никого не волнует, если твоя фамилия не Синофски или Руссинович. Даже чаще всего вредно: ты накидываешь работы тестированию, ты тратишь время, ты меняешь функциональность итп — радости скорее всего не будет.

Мы получили PowerShell, потому что нельзя трогать CMD. Мы получили 7 (или уже 8?) механизмов межпроцессного взаимодействия, и около 10 способов хранения данных в файлах/ресурсах (это про потоки). Мы получили 6 или более конкурирующих подсистем рендеринга и рисования UX. Мы получили пачку неконсистентных подходов внутри системы и ее внутренних собственных функций, при том работающих одновременно (если копаться в системных настройках Win11, вы легко увидите их все, в зависимости от глубины копания). Шесть версий движков браузера.

Таким образом мы получили продуктах то, что имеем.
Чем удобряли, то и выросло.

Кто будет исправлять ошибки — никто, нет такой целевой функции, нам за это не платят. Давай лучше в очередной раз докрутим фич на многострадальный Edge (пользователям явно не хватает фичей в том браузере, который они всеми силами стараются не использовать), впихнем на уровне системы highly controversial кривой движок внешнего искусственного интеллекта, а следом пачку несовместимостей, чтобы с удачной Windows 7 пользователей наконец выжать. Мы же лучше знаем, что надо рынку.

Картиночка устарела и уже местами нерелевантна, но смысл тот же.

Про фокус продукта и use-кейсы (как фичи фильтровать и выставлять приоритеты) пока писать не буду, разберемся пока с текущим вопросом.

Что следует понять: фичи не дешевы. Речь не о их разработке.

• Новые фичи плодят технические вопросы ЗНАЧИТЕЛЬНО важнее и серьёзнее тех, которые связаны непосредственно с их разработкой. Это тестирование, поддержка, интеграция, обновления.
• Новые фичи размывают scope продукта. Вместо нишевого продукта вы двигаетесь в сторону «комбайна для всех», и ни для кого в частности. Нишевому продукту занимать нишу всегда проще. Узкоспециализированный тулкит под конкретный рынок всегда выиграет у безликого гугло-яндекса, просто потому что он способен решить задачи пользователя точнее, быстрее и предсказуемее.
• Новые фичи и факт их появления заденут старую аудиторию, которой придется с ними смириться, приспосабливаться, учиться. Возможно, аудитория или её сегмент выиграет, плюсов больше минусов. Возможно, что нет. Добавить фичу для 5% новой аудитории, при этом потерять 15% старой — так себе идея.
• Все фичи, новые или старые, кому-то придется поддерживать в актуальном состоянии. Причем рост нагрузки не линейный, грабли количественно перемножаются. Есть риск получить ситуацию, когда когда-то мощная и заводная команда разработки теперь тратит 80% своего времени на разгребание кодбазы и поддержку продукта на плаву. И «вернуть как было» вы уже не сможете, теми же силами.

Поэтому прорывные и креативные фантазии менеджмента по части «развития» придется приземлять.

Вы не сможете бороться с явлением глобально, волшебной ложки нет у меня для вас. Чтобы не скатиться в overengineering и overbloat, в своем продукте можете попробовать следующее.

Опциональные фичи, core-продукт

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

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

Оценивать негативное влияние во времени и деньгах

Это сложно. Как минимум, потому что практика всегда может оказаться грустнее вашей теоретической оценки. А цифр нет, можно только угадывать. «Мы опасаемся, что станет хуже», но вот насколько? На одной чаше весов расширение аудитории и рост продаж, на другой — вялые отговорки разработки.

Здесь надо привлекать экспертов, своих или внешних, оценивать, прикидывать, думать. Внутренней интуицией хороший инженер может обычно сходу прикинуть риски «каковы шансы, что мы с этим огребёмся?», но ощущаемая позиция потребует проработки. «Они там всегда ворчат, им там всегда плохо, вот лишь бы не напрягаться» + «вы же инженеры, вот и предложите решение».

Different Products

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

Сторонняя разработка

Возвращаясь к описанным проблемам Microsoft, как решается вопрос в конкурирующей не-монолитной экосистеме опенсорца? Множеством кривых поделий из продуктов в стеке. Плюсы в том, что с какого-то момента для решения произвольной задачи есть возможности: взять ОС, накрутить стек, накрутить приложения, взять того кто в этом шарит, что-то привернуть своё бизнесовое — а потом постараться с этим кадавром взлететь.

Путь перспективный, но вынужден отметить: вы просто перекладываете интеграционный головняк на клиента, у которого встаёт исследовательская задача «как же оно, бдь, вообще должно заработать». Без гарантий, за что опенсорц и не любят. Ну и монетизируется подобный путь так себе. Но дает какую-то ситуационную гибкость; тот же российский 1С с экосистемой говнописателей и несовместимых между собой конфигураций — вполне наглядный пример.

Идти на поводу у менеджмента не всегда нужно. Вот только инженерные проблемы обычно слышат только тогда, когда всё уже покрылось тазом и никуда больше не поедет. Вот этот риск следует прорабатывать заранее.