Являются ли патчи плохим знаком для клиента? [закрыто]

В офисе мы только что вышли из длительного периода, когда мы выпускали патчи слишком часто. В конце этого периода мы делали в среднем почти три патча в неделю.

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

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

Итак, мой вопрос более подробно: часто ли обновления получают «отрицательное» сообщение для получателя?

Конечно, я мог бы спросить клиентов, но я не нахожусь в таком положении и не хочу «разбудить спящих собак».

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

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

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

Я чувствую, что выпуск нескольких патчей в непосредственной близости плохо сказывается на компании. Это всегда заставляет меня чувствовать, что они не проверили достаточно заранее, что разработчики некомпетентны, или руководство не знает, что они делают.

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

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

Все больше и больше компаний следуют по стопам Chrome и получают все более частые релизы для клиентов.

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

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

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

Что касается того, чтобы не разговаривать со своими клиентами «пусть спящие собаки лгут», я считаю, что это неправильная стратегия - клиенты не слепые и не дураки. Я считаю, что хорошее общение с вашими клиентами может только заверить их, что они являются вашим приоритетом, и что вы восприимчивы к их критике. Если вы выпускали плохие релизы пару раз, и вы не слышали, чтобы они жаловались - вам определенно следует беспокоиться - дело не в том, что они не заметили, скорее, они просто заняты поиском замены для вас ...

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

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

Я также видел, как люди выступают за размещение исправлений в репозиториях или на веб-сайтах, где клиенты могут загрузить и установить те, которые они хотят. Это может создать проблемы со знанием того, какие исправления есть у клиентов, поэтому, когда они обращаются с проблемой, вы должны точно определить, какой код они выполняют, но с осторожностью, что можно отследить. Затем вы можете заставить людей обновиться до одного из более крупных «пакетов», когда он выпущен, и в него входит множество патчей.

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

Google Chrome решает проблему путем автоматического обновления очень часто, они также требуют от вас циклического запуска программы (перезапустите Chrome или, в случае необходимости, выйдите из системы). Теперь они сделали эту обычную практику для браузеров, и люди даже не думают об этом больше. Но не каждый может быть Google.

SaaS-приложения обходят всю проблему, выполняя обновления в фоновом режиме.

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