Что лучше: отправка багги или вообще не отправка этой функции?

Это немного философский вопрос. Я добавляю небольшую функцию к своему программному обеспечению, которое, как я полагаю, будет использоваться большинством пользователей, но только в 10% случаев, когда они используют программное обеспечение. Другими словами, программное обеспечение было прекрасным без него в течение 3 месяцев, но 4 или 5 пользователей попросили его, и я согласен, что он должен быть там.

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

Что делать? Является ли функция, что 90% действительно "лучше, чем ничего"? Я знаю, что у меня появятся сообщения об ошибках, которые я не смогу исправить: что я скажу клиентам об этих? Должен ли я жить с неотвеченными запросами функций или ответами без ответа?

Ответ 1

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

Как насчет наличия "закрытой беты" с "4 или 5 пользователями", которые предложили эту функцию в первую очередь?

Ответ 2

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

Ответ 3

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

Ответ 4

Перфекционисты могут ответить "не делай этого".

Деловые люди могут ответить "сделай это".

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

Есть ли способ получить бета-версию для 4-5 человек, которые запросили эту функцию? Затем, как только вы получите их отзывы, может быть ясно, какое решение принять.

Ответ 5

Четко документируйте неудобство и отправьте его.
Убедитесь, что пользователь, вероятно, увидит и поймет вашу документацию о неудобстве.

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

Просто потому, что вы не можете исправить это сейчас, не означает, что вы не сможете в будущем. Вещи меняются.

Ответ 6

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

Ответ 7

Корабль рано, корабль часто, постоянный рефакторинг.

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

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

Ответ 8

Я думаю, это зависит от ваших стандартов. Для меня код с ошибкой не готов к производству и поэтому его нельзя отгружать. У вас есть бета-версия с известным списком проблем, чтобы пользователи знали, чего ожидать при определенных условиях? Они получают выгоду от использования новых функций, но также знают, что они не идеальны (используйте их собственный риск). Это может привести к тому, что эти 4 или 5 клиентов обратились к этой функции с удовольствием на некоторое время, что дает вам больше времени для исправления ошибок (если возможно) и последующего выпуска в производство для масс.

Просто некоторые мысли в зависимости от вашей ситуации.

Ответ 9

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

Ответ 10

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

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

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

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

Ответ 11

Если спрос на функцию NOW, а не на функцию, которая работает. Возможно, вам придется отправить.

В этой ситуации:

Убедитесь, что вы документируете ошибку (-ы) и последствия (как для пользователя и другие разработчики).
Обязательно добавьте ошибку (-ы) в свою базы данных отслеживания ошибок.
Если вы пишете модульные тесты (надеюсь, так) убедитесь, что тесты написаны которые выделяют ошибки, перед вами корабль. Это будет означать, что когда вы приходят, чтобы исправить ошибки в будущем, вы знаете, где и что они, без необходимости запоминать.
Запланируйте работу по исправлению ошибок КАК МОЖНО СКОРЕЕ. Вы исправляете ошибки до написав новый код, не так ли?

Ответ 12

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

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

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

Ответ 13

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

Ответ 14

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

Это сводится к очень реальному выбору путей: является ли ошибка чем-то, что не работает должным образом, что не является частью предполагаемого поведения и дизайна? Или это ошибка только в том случае, если она не работает в соответствии с предполагаемым поведением?

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

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

Ответ 15

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

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