Когда можно отправлять товар с известной ошибкой?

Когда можно отправлять товар с известной ошибкой?

Я предполагаю, что вы говорите об «известной» ошибке (в противном случае вопрос не имеет смысла). Ну, ответ зависит от этих факторов:

1) Кто пользователь и как он / она примет ошибку в случае ее обнаружения?

2) Каково потенциальное воздействие (повреждение) ошибки?

3) Можно ли отложить поставку программного обеспечения, чтобы исправить ошибку?

4) Самое главное: что вы ожидаете от своего программного обеспечения? Пора торговать? Качество? Хотите узнать, используют ли ваши клиенты программное обеспечение достаточно долго, чтобы найти ошибку?

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

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

Так что посмотрите на это с точки зрения затрат / выгод.

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

Таким образом, если у вас есть 2-недельный период тестирования перед выпуском, и обнаружена небольшая ошибка, вопрос состоит в том, чтобы ... исправить эту ошибку, стоящую за 2 дополнительные недели, которые команда может теперь потратить, чтобы повторно протестировать приложение и установку (часто забывают о шаге в создании программного обеспечения)? Сколько стоит репутация или продажи, если программное обеспечение запаздывает? Люди собираются злиться? Они могут быть очень рады жить с незначительной ошибкой, если основные функции могут быть доставлены вовремя.

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

Негативное влияние - это и время, и усилия на работу с клиентами, сообщающими об ошибке, и такие вещи, как ущерб репутации.

Ошибки бывают разной степени тяжести. В любой софтверной компании, в которой я работал, мы классифицировали ошибки в порядке Приоритета от P0 до P4.

P0 Это программное обеспечение не работает / дает сбой и может нанести ущерб бизнесу клиентов. P1 Он работает не так, как задумано, и постоянно падает в основной функциональности. P2 Иногда происходит сбой, и часть побочной функциональности может не работать. P3 Некоторые элементы программного обеспечения не работают так, как задумано / ожидается. P4 Косметическая проблема.

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

Я бы сказал, что все в порядке, если у вашего программного обеспечения есть проблемы с P3 / P4, я бы добавил это в примечания к выпуску и отметил, что над ними ведется работа.

Я бы никогда не выпустил программное обеспечение с проблемой P0, P1 или P2, о которой я знал.

Это называется « Известная проблема ». Google, Microsoft, Apple и т. Д. Поставляют продукты с ошибками, как известными, так и неизвестными. Попробуйте свести их к минимуму, но не ждите совершенства. Корабль быстро, грузим часто.

Вы не можете отправить программное обеспечение без ошибок. Совет, который я могу дать, заключается в том, что лучше всегда говорить своему клиенту: «Эта версия не может делать то и это, но мы собираемся это исправить», чем ситуация, когда клиент говорит ВАМ, что у вас есть ошибка.

когда это «фича»! ;)

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

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

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

Очевидно, что лучше всего избегать доставки с ошибками.

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

Одна из вещей в мире программирования , который дает людям уверенность в проекте , были ли они релиз запланирован и является ли график имеет .

Вот почему Ubuntu выпускает релизы каждые полгода, даже если есть открытые выпуски.

Я бы сказал, что хорошее эмпирическое правило гласит: «Является ли эта ошибка бестселлером?»

Если ошибка приводит к сбою «сценария счастливого пути», то абсолютно не поставляется с этой ошибкой.

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

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

С точки зрения потребителей ... Никогда. Я хочу сказать, что если вы знаете, что в программном обеспечении есть серьезная ошибка, вы никогда не должны его отправлять. Однако силы природы (бизнеса) преодолевают это, если производственный цикл программного обеспечения сейчас находится на стадии, когда это может нанести ущерб бизнес-модели, и они представляют собой незначительные ошибки, которые не будут: (i) ставить под угрозу безопасность программного обеспечения (ii) влиять на удобство использования

Как говорили люди, это очень широкий вопрос. На самом деле это подводит меня к интересной перспективе: так называемые «ошибки», о которых вы заявляете, - это только ошибки, обнаруженные вашими тестерами. Там может быть бесконечно больше лазеек. Просто напомнил интересную историю, которую я услышал от одного уважаемого профессора на одном семинаре для выпускников: когда люди в одной из скандинавских стран использовали машину для голосования типа «распознаваемый от руки», некоторые люди взламывали всю систему, написав вредоносный код SQL (который система взяла как нормальный ввод).

Есть то, что называется FMEA (режим отказа и анализ эффектов), очень полезно решить, когда известная ошибка важна или нет на основе:

1. Вхождение
2. Строгость
3. обнаружение

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

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

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