Выпуск рано / выпуск часто для коммерческого программного обеспечения? [закрыто]

Question

Есть ли у кого-нибудь опыт / примеры по раннему выпуску / частому выпуску коммерческого программного обеспечения? Это работает?

Я думал о VMware, где у них есть много выпусков ревизий между каждой основной версией. И процесс установки был ужасен, иногда они ломали существующие виртуальные машины, а иногда инструменты VMware в гостевых ОС работали с ошибками / не устанавливались. Это просто ужасно.

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

Есть ли у вас опыт \ пример \ предложения по применению принципа досрочного / частичного выпуска к коммерческому программному обеспечению?

Я хочу применить его к одному.

Answer 1

Кенни прав: это зависит.

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

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

Главный вопрос в том, насколько разрушительным является новый выпуск . Например, если бы MS выпускала новые версии Visual Studio каждые 3 месяца с новой версией .NET, средой выполнения C и т. Д., То мы потратили бы значительную часть нашего времени, просто занимаясь обновлением, что не было бы хорошо. Но если они хотят выпустить новые версии Windows Media Player с каким-то новым виджетом, который меня устраивает - просто сделайте процесс загрузки / установки как можно более плавным.

Answer 2

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

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

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

Answer 3

Обратите внимание на человека за занавеской. :
То, что часто делают релизы - релизы, часто требует, чтобы вы терпели неудачу рано и быстро, а не в конце проекта, когда уже слишком поздно. Это дает вам больше возможностей показать, что вы создаете для конечного потребителя, получить ценную обратную связь и адаптироваться с меньшими затратами. Человек в роли «клиента» должен иметь возможность легко получить последнюю версию; поиграйте с ним и отвечайте конструктивно, как можно чаще.

Если вы создаете что-то критическое, например, то, что контролирует или контролирует электростанцию, вы, вероятно, захотите быть осторожным с этой практикой. Вы не хотите, чтобы люди с факелами получали обратную связь для вашего нового релиза. В таких случаях имеет смысл регулярно развертываться на испытательном стенде, смотреть его в течение X дней (согласно уровню уверенности), а затем переходить в ЖИЗНЬ! Вы можете предоставить своему клиенту доступ к этому испытательному стенду, чтобы поиграть и настроить его индикатор доверия.
Если это некритическое приложение, и у вас был хороший исторический отчет о хороших выпусках, сделайте что-то вроде ClickOnce ... но также убедитесь, что его одинаково легко откатить для клиента.

Answer 4

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

Answer 5

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

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

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

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

Answer 6

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

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