Ни одно облачное решение, если только оно не разработано на заказ, не может полностью удовлетворить все запросы потребителя. Поэтому многие хотя бы раз отправляли производителю ПО feature request, или, по‑русски, запрос на добавление дополнительной функциональности. Возможно, вы тоже были в этой роли. Производитель может включить такой запрос в дорожную карту развития продукта. Или отправить его в корзину. В этом материале расскажем, чем отличается работа с feature request у создателей решений, в основе которых лежат скопированные open source продукты и Enterprise, и какой подход мы используем при обновлении нашей платформы для построения виртуальных ЦОДов vStack.

Зачем производителям брать в работу запрос на добавление функций от потребителей

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

Заодно включение пользовательских запросов в план развития помогает повысить удовлетворенность и лояльность пользователей. Клиенты видят, что компания учитывает их предложения, получают нужные им возможности и готовы и дальше пользоваться продуктом и рекомендуют его другим.

Казалось бы, если все так хорошо, что может пойти не так?

Разные подходы к работе с запросами функциональности у клонов OpenSource-продуктов, Enterprise и у нас

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

Подход владельцев решений-клонов OpenSource-продуктов

В клонах существующих OpenSource-продуктов нет смысла принимать feature request от пользователей. Обращу внимание, что мы говорим именно о клонированных продуктах, а не о любом ПО на основе открытого кода.

К слову, таких решений стало намного больше после ухода зарубежных компаний с российского рынка в 2022 году. Продукты, представляющие из себя полные клоны opensource-продуктов, росли как грибы после дождя. Некоторые из них практически не содержат собственного кода или содержат его в несущественных объемах, что никак не влияет на функциональные возможности. Если компания создает полный клон opensource-продукта, меняя лишь название и шрифты, это значит, у нее не будет возможности полностью управлять полученным «продуктом». Мы регулярно слышим на конференциях одни и те же вопросы: «Как отличить платформу, которая является полным клоном opensource, от самостоятельной разработки?». Это говорит о том, что многие уже не только столкнулись с проблемами такого рода, но и успели их осознать, равно как и понять неоднозначные возможности в распознавании таких псевдо-продуктов.

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

Ради справедливости нужно упомянуть, что у такого ПО есть свои плюсы. В первую очередь это скорость его создания. После внезапного ухода зарубежных игроков российским компаниям понадобилась срочная замена ПО на отечественные аналоги. И возможность быстро создать альтернативу — существенный плюс. 

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

Первый вариант неоднозначен тем, что:

• оригинальному продукту эти изменения могут быть не нужны или даже вовсе вредны;

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

• де-факто это означает «отдать результат длительных вложений в публичную плоскость». 

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

Почему «кровавый энтерпрайз» редко учитывает запросы клиентов

Отправили запрос на добавление функциональности в крупную компанию? 

Скорее всего, ответом была тишина или предваряющая ее стандартная отписка в духе «Мы получили ваш запрос». Почему так происходит? На самом деле возможность запрашивать дополнительную функциональность зависит от политики компании и ее программного продукта. Если работа с запросами потребителей соответствует целям, ресурсам и приоритетам компании, у отправителя запроса есть шанс. Однако вероятность такого сценария стремится к нулю, так как большинство крупных enterprise-разработчиков нацелены на стабильность и надежность, а не на новые функции. И это логично, в противном случае они не были бы гигантами рынка. 

Во многих Enterprise-компаниях процессы принятия в разработку новой функциональности настолько формализованы и централизованы, что даже у заявок крупных клиентов мало шансов попасть в дорожную карту. Любые потребительские запросы на добавление функций здесь будут каплей в море. Нередко такие продукты уже и так перегружены избыточным количеством функций в реализации одних и тех же задач. Производитель добавляет в них не просто максимальное, а зачастую избыточное количество возможностей, нацеленных на решение одной и той же задачи. При этом клиент будет использовать не более 10% из них, а платить нужно будет за весь набор возможностей и опций. С каждым обновлением разработчик будет добавлять новые, не всегда нужные функции, которые будут только утяжелять продукт, делать его более ресурсоемким и дорогим. 

А сами то что?

Настало время рассказать, как мы выстроили работу с клиентскими запросами на нашей платформе vStack. Мы (пока) не гиганты рынка и не являемся клоном OpenSource-продукта. 

Платформа разработана российскими специалистами и развивается самостоятельно, с учетом пожеланий реальных потребителей. vStack — полностью наша собственная разработка, которую создавали как замену (но не копию!) платформы американской компании VMware. У VMware есть множество возможностей, однако в реальности 90% потребителей используют лишь около 5% из них. Мы решили пойти другим путем и отказаться от добавления избыточной функциональности. Если клиенту не хватает каких-то возможностей, он может отправить нам персональный запрос на их разработку.

Один из клиентов vStack — международный гиперскейлер Serverspace, регулярно отправляет нам запросы на добавление тех или иных функций. До 2019 года компания выстраивала инфраструктуру на базе решения для виртуализации VMware. Однако обслуживание платформы требовало больших вложений. А когда компании Serverspace требовались функции, которых не было у решения VMware, получить их было невозможно. Поэтому облачный провайдер обратился к нам и, по сути, повлиял на развитие vStack. Большая часть изменений на платформе в 2020-2022 годах появилась в результате обработки запросов от команды Serverspace. Впрочем, другие клиенты вовсе не обязаны платить за эти обновления. Каждая компания может выбрать любой нужный ей набор функций и не платить за все остальное.

Какие проблемы создает отсутствие работы с feature request 

«Требования к новой системе не будут известны, пока ей не начнут пользоваться».

Уоттс Хамфри, инженер, «отец качества программного обеспечения»

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

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

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