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

14

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

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

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

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

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

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

Mixxiphoid
источник
@ downvoter, хочешь объяснить?
Mixxiphoid
6
Если вы беспокоитесь о восприятии клиентов, возможно, опишите их как «обновления», а не как «патчи»? :)
Крис Тейлор
Хотя это и не является прямым ответом, если вы можете сохранить развертывание исправлений как можно более незаметным и автоматическим (например, загружать обновления в фоновом режиме, запускать службу обновлений для применения во время простоя), то вы можете уменьшить беспокойство конечного пользователя, не делая обновления очевидными. Например: сколько обновлений Google Chrome вы получили за последний месяц или около того? (Ответ: много ). Они могут выпустить 5 патчей для Chrome в день, и никто не будет поднимать бровь. Автоматические обновления Windows (если они включены) являются еще одним примером.
Джейсон С
«Время обновления клиентского программного обеспечения составляет менее 30 секунд, поэтому я не ожидаю каких-либо проблем, связанных со временем. Хотя они действительно должны быть отключены». А как насчет того, чтобы клиент сам тестировал патч? Я не знаю, с каким типом программного обеспечения вы работаете, но если он кому-то близок к критически важному, они захотят протестировать обновление, прежде чем использовать его в производственной среде. Хотя установка исправления может быть быстрой и простой, это тестирование потребует много времени и усилий со стороны заказчика.
CVn
@ MichaelKjörling Проблема в том, что в этот период критически важные функции не работали, поэтому не имело значения, было ли сначала обновлено производственную среду или тестовую среду. Это просто нужно работать как можно скорее.
Mixxiphoid

Ответы:

24

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

введите описание изображения здесь

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

Роберт Харви
источник
3
Возможно, это должен быть другой вопрос, но в любом случае: мы знали, что проводим тестирование через наших клиентов, но не могли остановить это в то время, мы оказались в ловушке цикла. Что мы можем сделать, чтобы выйти?
Mixxiphoid
3
Роберт, я видел эту диаграмму много раз раньше. Вероятно, было правильно, когда разработка программного обеспечения проводилась по чистой модели водопада, но поскольку программное обеспечение можно разрабатывать и развертывать небольшими циклами, оно становится все более и более неправильным. Чтобы быть точным - для небольшого количества ошибок и программного обеспечения тенденция все еще верна, для многих ошибок это определенно неправильно.
Док Браун
2
@DocBrown: график все еще правильный. Более короткие циклы разработки означают меньшую стоимость за цикл, что согласуется с графиком. Но это еще не значит, что вам следует проводить альфа-тестирование программного обеспечения на своих клиентах, если только нет четкого понимания и согласия, что это является частью процесса.
Роберт Харви
Что ж, стоимость дефектов уменьшается, чем раньше ошибка найдена и исправлена. И вероятность того, что ошибка найдена, резко возрастает, чем раньше вы получаете свое программное обеспечение на улице. Это, конечно, не означает, что нужно внедрять непроверенное программное обеспечение в производство. Я рекомендую, например, эту статью agileelements.wordpress.com/2008/04/22/cost-of-software-defects
Док Браун,
1
Все, что нужно, - это немного саморефлексии, чтобы увидеть, что сам принцип является здравым, даже если числа или форма кривой - просто догадки. У нас даже есть имя для этого на языке программирования: Fail Fast.
Роберт Харви
10

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

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

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

разъем
источник
Итак, суть в том, должны ли мы стараться исправлять только тех клиентов, которые действительно нуждаются в этом, и других на более позднем этапе «массового» улучшения нашего имиджа?
Mixxiphoid
5
Патч для отдельных клиентов звучит так, как будто это может быть проблемой, особенно если есть большая клиентская база. Развертывание исправлений по регулярному графику (ежемесячно, раз в два месяца и т. Д.) И продвижение исправлений клиентам может стать хорошим способом повысить интерес к «тому, что будет дальше» со стороны вашего продукта, а также решить проблемы. которые сглаживаются. Конечно, правильная документация и уведомления имеют решающее значение для связи с конечным пользователем с примечаниями к исправлению.
Джек
Это действительно многое проясняет для меня. Похоже, мы должны приложить некоторые усилия для использования наших патчей для улучшения нашего имиджа. До сих пор я был уверен, что это невозможно. Всегда видел патчи как неизбежное зло.
Mixxiphoid
зависит от того, когда в цикле выпуска тоже. Если патчи близки друг к другу в первые дни после выпуска, это производит впечатление, отличное от того, когда они (все еще) сближаются несколько месяцев спустя.
jwenting
7

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

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

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

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

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

Ури Агасси
источник
2
+1, как частый клиент программного обеспечения, я хочу парней с частыми обновлениями и хорошими способами их развертывания. Продукты, которые застаиваются, являются настоящим красным флагом здесь - по крайней мере, это означает, что поставщик не вкладывает средства в продукт. Или инвестировать в vNEXT, чтобы они снова и снова платили за вас.
Уайетт Барнетт
Из вашего последнего абзаца я понимаю, что мы всегда должны быть честными и прозрачными в общении с клиентом. Есть ли ситуации, в которых мы не должны (пока) информировать клиента об определенных вещах?
Mixxiphoid
1
Конечно, быть честным с клиентом не означает оставлять линию открытой, поскольку вы созываете паническое собрание, чтобы смягчить последствия только что обнаруженной катастрофы. Вам следует сообщить информацию после того, как вы оценили ситуацию, разработали стратегию для ее исправления и можете честно сказать, что все под контролем. Вы можете приукрашивать правду, но откровенная ложь может преследовать вас позже ...
Ури Агасси
2

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

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

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

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

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

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

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

Encaitar
источник
+1, это ключевой момент - чем быстрее вы сможете исправить ошибку (и развернуть), тем лучше - до тех пор, пока пользователь / клиент не приложит никаких дополнительных усилий при развертывании. Когда клиенту необходимо выполнить развертывание вручную или обновления просто прервут его рабочий процесс, важно найти правильную частоту для развертываний. Такие сайты, как Facebook, будут развертывать несколько патчей в день, и большинство людей даже не заметят.
Док Браун
так что, думаю, нам повезло с этой стороны. Наши обновления стоят нам (помимо стресса, кодирования и всего) всего 1 или 2 часа. Чтобы вернуться к работе, клиенту потребуется 1 минута. Я рассмотрю подход «пакет обновления», он действительно может пригодиться тем, кому патч не нужен напрямую.
Mixxiphoid
Нашел эту ссылку для Facebook: blogs.wsj.com/cio/2013/04/17/… , так что, кажется, два выпуска, а не несколько, в день. Все еще впечатляет, я думаю.
Док Браун
Я «слышал» этот амазонский push-код каждые 17 секунд. Но я помещаю это в комментарий, потому что я не могу вспомнить, кто сказал мне, и Google не показывает это. :-)
Encaitar
@Encaitar: Да, архитектура Amazon имеет сотни взаимодействующих сервисов. Поэтому я не удивлен, если они нажимают что-то слишком часто, но я очень сомневаюсь, что каждое нажатие напрямую влияет на более чем один компонент. То, что вы видите на одном сайте, не обязательно имеет общую версию. Это больше похоже на то, что сеть городских дорог обновляется каждые 17 секунд, потому что ваши экипажи рисуют в общей сложности 5 тысяч свежих строк в день :-)
Стив Джессоп