Мы в Beeline Cloud недавно писали о ретрософте, который живет и поддерживается вот уже не первое десятилетие. Сила этих программ кроется в отказе от лишнего.

Во многом они выжили благодаря своей простоте: сохранили ядро, ключевую функциональность и лояльных пользователей. Поговорим о тех, кто все же не смог устоять. Разберем на примерах, как неконтролируемый feature creep превращает продукты в монструозных «франкенштейнов», от которых бегут пользователи.

Куда «ползет» функциональность — а главное, зачем?

На сегодняшний день не существует единого, общепринятого определения термина feature creep («ползучее расширение функциональности»). Так, группа китайских ученых из Хайнаньского педагогического и Ляонинского университетов в своей работе, посвященной оптимальным стратегиям обмена информацией, определила feature creep как «феномен, при котором рост числа функций ведёт к снижению удобства и эффективности использования продукта».

Ещё раньше, в 2005 году, профессор Дэвид Вудс, специалист по системам безопасности критических инфраструктур, вместе с коллегами из Университета штата Огайо предложил куда более лаконичное определение ползучему расширению функциональности: «это — процесс, порождающий сложность».

В то же время представления о концепции feature creep различаются не только среди учёных, но и среди практиков: независимых разработчиков, системных администраторов, юзабилистов и геймдизайнеров. Пять лет назад студенты из Университета Сёдертёрна в своей выпускной работе опросили специалистов игровой индустрии — художников, 3D-дизайнеров и других участников команд разработки. И хотя финальная выборка оказалась относительно небольшой, даже в этом случае мнения респондентов различались.

Одни определяли feature creep как ситуацию, когда разработчик выходит за рамки изначального замысла и добавляет новые функции по собственной инициативе. Другие — как процесс бесконечных доработок уже существующих элементов: «Я бы сказал, это феномен, когда люди меняют завершённые вещи. Проект почти готов к релизу, начинается паника, рождается масса новых идей и кажется, что всё нужно переделать».

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

Откуда что взялось

Принято считать, что концепцию feature creep — хотя сам термин тогда ещё не использовался — описал еще Фредерик Брукс в книге «Мифический человеко-месяц» (1975). Он ввёл понятие «синдром второй системы» — ситуации, когда команда разработчиков, добившись успеха с первым простым продуктом, сталкивается с резким «раздуванием» функциональности на следующей его итерации.

По словам Брукса, именно «вторая система» становится опасной, ведь в нее пытаются включить все крутые функции, отложенные про запас на черный день. В итоге получается сложное, перегруженное и потенциально ненадежное решение.

Вариация термина — function creep, появилась в австралийских газетах 1980-х годов и примерно тогда же проникла в канадскую прессу [PDF, стр.34]. Термин использовали в контексте общественных дискуссий вокруг внедрения уникальных налоговых номеров и других инициатив, которые публика воспринимала как инструменты государственного надзора. Можно предположить, что выбор глагола creep не был случайным: он ассоциировался с медленным, скрытным движением — как у рептилий или насекомых (на худой конец, как у мыша из мема, который, как известно, «кродеться»), что усиливало негативный оттенок и вызывало ощущение «ползущей» угрозы.

А вот одно из первых появлений каноничной версии термина — feature creep — зафиксировали в сети Usenet в апреле 1990 года. В тематической ветке, где пользователи обсуждали прошедшую выставку MacWorld Expo, посвященную Macintosh, один из участников дискуссии оставил следующий комментарий:

«По-настоящему интересных и заметных продуктов становится все меньше и меньше <...>. Все играют в игру, кто добавит больше функций (feature creep)». Пользователи оценили хлесткий термин, и в скором времени он был использован повторно — правда, уже в другой ветке про файловый менеджер Finder.

В 1999 году feature creep закрепился в лексиконе, попав в авторитетный словарь хакерского сленга Jargon File. Его определение было лаконичным и…тавтологическим: «feature creep — результат "ползучего улучшизма" (creeping featurism)». Под ним понималось навязчивое стремление разработчиков нагружать продукт новыми функциями в попытке не отстать от конкурентов.

Почему «расползается» проект

Одна из причин чрезмерного «раздувания» функциональности — желание команды разработчиков угодить всем пользователям и одним махом закрыть множество юзкейсов. Брайан де Хааф, CEO компании-разработчика Aha!, в этой связи отмечает, что руководителям и продакт-менеджерам, конечно, стоит учитывать запросы аудитории и стейкхолдеров, но обязательно с поправкой на собственное видение проекта. «Соблазнительно отвечать "Да" на каждый запрос, — говорит он, — но это создает опасный прецедент и порождает менталитет "Ну, еще одна функция не повредит"».

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

Впрочем, суть не в пользовательском фидбеке как таковом. Настоящий feature creep проявляется тогда, когда разработчики ломают отлаженные процессы, пытаясь их «улучшить». Яркий пример — решение Heroku заменить привычную команду heroku console на более громоздкую heroku run rails console. Однако сообщество не оценило нововведение, назвав его неудобным. Реакция была настолько резкой, что один энтузиаст даже выпустил инструмент, который возвращает все «как было».

Стоит отметить, что feature creep часто маскируется под естественный рост. Даже если новая функциональность органично вписывается в концепцию, она может делать продукт громоздким. Есть мнение, что нечто подобное сегодня происходит с CSS-фреймворком Tailwind. Как пишет в своем блоге веб-разработчик из Техаса Брайс Рей, стремление оставаться релевантным и популярным делает фреймворк особенно уязвимым к ползучему расширению функциональности. «Чем больше возможностей добавляется в Tailwind, тем сложнее он становится, — отмечает Рей. — Переломный момент еще не наступил, но команде, развивающей фреймворк, необходимо быть начеку».

Почему это правда «крипово»

В первую очередь feature creep тормозит процесс разработки приложения или сервиса. Команда теряет из виду основную ценность продукта, и изначально понятный проект превращается в «монстра». Классический пример — разработка Windows Vista, которая растянулась на пять лет с постоянными переносами релиза. Но в итоге многие нововведения, такие как навязчивая система безопасности UAC (User Account Control), чаще раздражали пользователей. Критики отмечали явный перекос в сторону безопасности в ущерб юзабилити. Кроме того, для решения существующих проблем разработчики были вынуждены тратить время на патчи и реализацию еще большего числа функций вроде технологии ReadyBoost [она позволила использовать флеш-память для кеширования, пока жесткий диск занимался своими делами]. 

Другой хрестоматийный пример — игра Star Citizen, анонсированная в 2012 году. По-своему это уже легендарный долгострой в геймдеве, как минимум из-за своих амбиций. Одно время разработчики планировали добавить возможность считывать мимику игрока, чтобы его аватар мог отображать реальные эмоции. В 2018 году эту инновацию прямо называли типичным feature creep’ом, отодвигающим и без того далекий релиз.

Еще одна проблема «фичекрипа» состоит в том, что, в сущности, это — сизифов труд: команды тратят усилия на запуск функциональности, которую мало кто будет использовать. В 2019 году американская компания Pendo, которая развивает SaaS-платформу для оценки поведения пользователей, проанализировала обезличенные данные 615 компаний-клиентов за трехмесячный период. Специалисты пришли к выводу, что 80% возможностей программного обеспечения используются или редко, или никогда.

Эта тенденция не зависит от размера компании и наблюдается годами. Еще в 2002-м канадская ученая в области информатики Джоанна Макгренер в своей работе показала [PDF, стр.57], что из 256 «базовых функций» Microsoft Word только 57 (21,5%) используются более, чем половиной респондентов. При этом почти 16% функций полностью игнорируются пользователями.

Чрезмерное «наползание» функциональности может также оттолкнуть лояльных пользователей, которые были верны проекту с первого дня и ценили его простоту, легкость и узкую специализацию. Так, независимый разработчик в своей «исповеди» на Reddit с горечью заметил, что помогает начинающим предпринимателям запускать SaaS-продукты, а те «убивают» их на ранних стадиях, пытаясь нагрузить избыточной функциональностью. Через подобное проходят и крупные сервисы. За 11 лет Spotify от ориентированного исключительно на прослушивание музыки приложения стал маркетплейсом с аудиокнигами и афишей эвентов. Распространенное мнение в сообществе: «Я просто хочу слушать музыку — ценю возможность прочитать слова песни, но мне не нужно, чтобы под ними мне продавали мерч музыканта».

Feature creep не знает границ и незаметно губит как корпоративные продукты, так и пет-проекты. Показательна история из американской компании Nominum, рассказанная бывшим сотрудником. В компании была традиция — кто-то один регулярно ездил в ближайшую кофейню, где делал заказ для всего офиса. Инженер написал простого чат-бота, который запоминал любимые напитки коллег и считал, кто кому сколько должен за кофе. Со временем функциональность начала бесконтрольно расти — например, появилась возможность перераспределить долг между несколькими людьми — в итоге бот стал приносить больше проблем, чем пользы, и вносить путаницу в, казалось бы, простейшую бытовую задачу, которая решается блокнотом и ручкой. Хотя это был всего лишь нишевый проект, который развивался забавы ради, его путь наглядно демонстрирует опасности ползучего расширения функциональности, с которыми рискуют столкнуться коммерческие приложения и сервисы (хотя им feature creep обходится намного дороже).

Beeline Cloud — secure cloud provider. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.

О чем еще мы пишем в нашем блоге:

• Научный «дипфейк»? Как галлюцинации нейросетей просачиваются в науку

• Как мир вернулся в «классический веб»: падение эпохи мобильных приложений

• Вакансия Шредингера? Зачем появляются «ненастоящие» объявления о работе