Польза feature request или как перестать платить за то, чем вы не пользуетесь

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

90% потребителей корпоративных решений используют только 5% от их возможностей 

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

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

В результате возникает не просто избыточная функциональность, а набор функций, которые нужны лишь 1-5% пользователей. Например, решение американского гиганта VMware представляет собой огромный конструктор из возможностей, большая часть из которых не используется рядовыми потребителями. А около 90% пользователей достаточно лишь 5% возможностей платформы.

Закон Паркинсона плюс закон Мура

Закон Паркинсона гласит, что любая деятельность занимает все отведенное на нее время. Также и программное обеспечение корпоративного уровня может наращивать объем функций, пока они не задействуют все предоставленные ресурсы. 

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

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

Что плохого в избыточной функциональности

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

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

Решение проблемы — YAGNI и запросы на добавление новых функций

«Реализуйте только те функции, которые действительно вам нужны, а не те, которые понадобятся в будущем.»

Рон Джеффрис, соавтор Extreme Programming и Agile-манифеста

В ответ на существование проблемы с реализацией избыточной функциональности появилась концепция YAGNI. Аббревиатура расшифровывается как You ain’t gonna need it или «Вам это не понадобится». В основе принципа YAGNI — отказ от избыточной функциональности при разработке ПО как одна из основных ценностей продукта. Разработчик добавляет в продукт только те функции, в которых есть реальная необходимость.

Простой способ понять, какая функциональность будет актуальна для потребителей, — обрабатывать их запросы на добавление новых функций.

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

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