¿Qué es mejor: enviar una característica con errores o no enviar la característica en absoluto?

Question

esta es una cuestión filosófica. Estoy agregando una pequeña función a mi software, que supongo que será utilizada por la mayoría de los usuarios, pero solo tal vez el 10% de las veces que utilicen el software. En otras palabras, el software ha estado bien sin él durante 3 meses, pero 4 o 5 usuarios lo han solicitado, y acepto que debería estar allí.

El problema es que, debido a las limitaciones de la plataforma con la que estoy trabajando (y posiblemente limitaciones de mi cerebro), "lo mejor que puedo hacer" todavía tiene algunos errores no críticos pero notables - digamos que la característica como codificado es utilizable pero "un poco inestable" en algunos casos.

¿Qué hacer? ¿Hay una característica que es 90% realmente "mejor que nada"? Sé que obtendré algunos informes de errores que no podré solucionar: ¿qué le digo a los clientes sobre ellos? ¿Debo vivir con solicitudes de funciones sin respuesta o informes de errores sin respuesta?

Answer 1

Siempre habrá solicitudes de funciones sin respuesta e informes de errores. Enviarlo, pero incluya un archivo Léame con "problemas conocidos" y soluciones cuando sea posible.

Answer 2

Documente con precisión el wonkiness y envíelo.
Asegúrese de que el usuario vea y comprenda su documentación de la wonkiness.

Incluso podría discutir la decisión con los usuarios que han solicitado la función: hacer una investigación de mercado.

El hecho de que no pueda arreglarlo ahora, no significa que no podrá hacerlo en el futuro. Las cosas cambian.

Answer 3

Etiquete lo que tiene ahora como una "versión beta" y envíelo a las personas que lo solicitaron. Obtenga sus comentarios sobre qué tan bien funciona, solucione todo aquello de lo que se queje, y luego debería estar listo para implementarlo en grupos más grandes de usuarios.

Answer 4

Asegúrese de que la gente sepa, que usted sabe, que hay problemas. Que hay errores. Y bríndeles una manera fácil de enviar comentarios.

¿Qué tal tener una "beta cerrada" con los "4 o 5 usuarios" que sugirieron la función en primer lugar?

Answer 5

Tiene que pensar en esto desde la perspectiva de su usuario, lo que causará menos frustración. El código de Buggy suele ser más frustrante que las características que faltan.

Answer 6

Si no se rompe nada, ¿por qué no enviarlo? Parece que tienes una buena relación con tus clientes, por lo que aquellos que quieran la función estarán encantados de obtenerla aunque no sea todo el camino hasta allí, y a los que no la quieran no les importará. Además, obtendrás muchos comentarios para mejorarlo en la próxima versión.

Answer 7

Envíe temprano, envíe con frecuencia, refactorización constante.

Lo que quiero decir es que no dejes que te impida el envío, pero no te rindas para solucionar los problemas.

La incapacidad de resolver wonkiness es un signo de problemas en su base de código. Dedique más tiempo a refactorizar que a agregar funciones.

Answer 8

Los perfeccionistas pueden responder "no hacerlo".

Las personas de negocios pueden responder "hacerlo".

Supongo que el equilibrio depende de usted. Me inclinaría por poner la función allí si los errores no son críticos. La mayoría de los usuarios no ven su software de la misma manera que usted. Eres un artesano/artista, lo que significa que eres más crítico que las personas comunes.

¿Hay alguna manera de que pueda obtener una versión beta para las 4-5 personas que solicitaron la función? Luego, una vez que obtenga su opinión, puede estar claro qué decisión tomar.

Answer 9

Supongo que depende de sus estándares. Para mí, el código buggy no está listo para producción y por lo tanto no debería enviarse. ¿Podría tener una versión beta con una lista de problemas conocidos para que los usuarios sepan qué esperar bajo ciertas condiciones? Obtienen el beneficio de usar las nuevas funciones pero también saben que no es perfecto (use ese riesgo). Esto puede mantener contentos a los 4 o 5 clientes que solicitaron la función por un tiempo, lo que le da más tiempo para corregir los errores (si es posible) y luego lanzarlos a la producción para las masas.

Solo algunas ideas dependiendo de su situación.

Answer 10

Depende. Sobre los errores, su severidad y cuánto esfuerzo crees que tomará repararlos. En la fecha límite y cuánto cree que puede estirarlo. Sobre el resto del código y cuánto puede hacer el cliente con él.

Answer 11

No esperaría que los codificadores entreguen problemas conocidos en la prueba y mucho menos para liberarlos a un cliente.

Eso sí, creo en la tolerancia cero a los errores. Curiosamente, me parece que, por lo general, los desarrolladores/probadores son los más interesados ​​en eliminar todos los errores: a menudo es el gerente de proyecto y/o el cliente el que está dispuesto a aceptar errores.

Si debe liberar el código, entonces documente cada característica/error que conoce y comprométase a corregir cada uno.

¿Por qué no publica más información sobre las limitaciones de la plataforma en la que está trabajando, y tal vez algunas de las personas inteligentes aquí pueden ayudarlo a obtener su lista de errores?

Answer 12

La pregunta importante que debe responder es si su función resolverá una necesidad comercial real dado el diseño que se le ocurrió. Luego, solo se trata de hacer que la implementación coincida con el diseño, lo que hace que los "errores" no sean errores al definirlos como no parte del comportamiento previsto de la función (que debe ser cubierto por el diseño).

Esto se reduce a una elección muy real de rutas: ¿es un error algo que no funciona correctamente, que no formaba parte del diseño y el comportamiento previstos? ¿O es un error solo si no funciona de acuerdo con el comportamiento previsto?

Soy un firme creyente en este último; los errores son las cosas que no funcionan de la manera en que estaban destinados a funcionar. La implementación debe capturar el diseño, que debe capturar la necesidad del negocio. Si la implementación se utiliza para abordar una necesidad empresarial diferente que no fue cubierta por el diseño, es el diseño el que tiene la culpa, no la implementación; por lo tanto, no es un error.

La actitud anterior es de lejos la más común entre los programadores en mi experiencia. También es la forma en que el usuario ve problemas de software. Desde una perspectiva de desarrollo de software, sin embargo, no es una buena idea adoptar esta vista, ya que lo lleva a corregir errores que no son errores, sino defectos de diseño, en lugar de rediseñar la solución a las necesidades del negocio.

Answer 13

Si la demanda es para una característica AHORA, en lugar de una función que funciona. Puede que tenga que enviar.

En esta situación, sin embargo:

• Asegúrese de documentar el error (s) y consecuencias (tanto para el usuario y otros desarrolladores).
• Asegúrese de agregar la (s) falla (s) a su base de datos de seguimiento de errores .
• Si escribe pruebas unitarias (espero que sí), asegúrese de que las pruebas estén escritas que resaltan los errores, antes de enviar . Esto significa que cuando venga a reparar los errores en el futuro, , sepa dónde y qué son, sin tener que recordar.
• Programe el trabajo para solucionar los errores CUANTO ANTES. Repara errores antes de escribiendo un nuevo código, ¿no?

Answer 14

Si los errores pueden causar la muerte o pueden perder los archivos de los usuarios, entonces no los envíe.

Si los errores pueden hacer que la aplicación se cuelgue, envíela con una advertencia (un archivo Léame o lo que sea). Si los bloqueos pueden hacer que la aplicación corrompa los archivos de los usuarios que estaban en el medio de la edición con esta aplicación exacta, muestre una advertencia cada vez que inicien la aplicación, y recuérdeles primero hacer una copia de seguridad de sus archivos.

Si los errores pueden provocar BSOD, tenga mucho cuidado con la persona a la que se lo envía.

Answer 15

Viniendo de alguien que tiene que instalar un software defectuoso para sus usuarios, no lo envíe con esa característica habilitada.

No importa si lo documenta, los usuarios finales se olvidarán de ese error la primera vez que lo hagan, y ese error será crítico para ellos al no poder hacer su trabajo.