Como parte de una revisión de todas las descripciones de trabajo, mi empresa ha decidido incluir lo siguiente como resultado clave:

desarrollo del sitio web completado a tiempo, dentro de las especificaciones y sin errores

Dado que las especificaciones cambian regularmente, no existe un proceso formal de control de cambios y los entornos son, digamos, un poco impredecibles, ¿qué tan realista y razonable es este KPI?

"Sin errores" es demasiado subjetivo . La "Solicitud de función no cumplida" de un hombre es el "Error" de otro hombre. Algo como "Debería cumplir sustancialmente con las especificaciones de diseño" sería más apropiado. Nunca he visto lo que describe en una descripción de trabajo. Lo he visto por contrato , pero no por empleados.

Tomaré una posición opuesta a la mayoría de las respuestas y diré que es absolutamente razonable y realista.

¿Se completará todo el desarrollo a tiempo? Por supuesto que no, no siempre.

¿Se completará todo el desarrollo dentro de las especificaciones? Le gustaría esperar que sí, pero a veces eso simplemente no será posible y tendrá que marcar una desviación de una especificación imposible o contradictoria.

¿Y todo el desarrollo estará libre de errores? Nunca .

Pero para eso sirve un KPI. Es algo que se puede medir y mediante el cual puede realizar un seguimiento del rendimiento y el progreso.

Si las especificaciones cambian regularmente, no hay un proceso formal de control de cambios y los entornos son impredecibles, entonces será un desafío mantener esta cifra cerca de "libre de errores". Pero ese desafío es su trabajo , y es un trabajo que esperamos que haga bastante bien, y aún mejor el próximo año, a medida que adquiera más práctica para administrar el sabor particular del caos de su empresa.

Pregunta contador: lo KPI haría que proponer para un programador? Es una pregunta difícil. Mucho de lo que hacemos es difícil de medir.

Si se trata de una descripción del trabajo, entonces no me preocuparía demasiado, ya que trabajar hacia un código libre de errores es parte del trabajo típico de un programador (incluso si nunca podemos lograrlo).

Sin embargo, como KPI es demasiado amplio, pero no culpe a la persona que lo sugirió si no son programadores. Simplemente explique que esa declaración establece una meta que podría ser indeseable para la organización. Es decir, "sin errores" es un estándar extremadamente alto para el software que realmente costaría una fortuna. Explique que un proyecto de software bien ejecutado requiere la toma de decisiones sobre si vale la pena gastar un valioso tiempo de desarrollador en cada defecto.

Aquí hay un ejemplo que hace bien el punto.
Un programador descubre que nuestro software tiene un error del "año 3000" y dejará de funcionar después del 31 de diciembre de 1999. Tardará entre 6 y 8 meses en solucionar el problema. Basado en el KPI se alienta a asumir este proyecto a pesar de no tener un valor real para la empresa.

Bien, ese ejemplo es un poco extremo, pero en cualquier proyecto de software habrá literalmente docenas de pequeños defectos descubiertos que de manera similar no generan el ROI requerido para solucionarlos. Si el KPI tenía la intención de implicar que el programador nunca introdujo el defecto en primer lugar, ¿parece razonable que CUALQUIER empleado cumpla con el estándar de nunca cometer un error en el desempeño de su trabajo?

No

No solo no es apropiado, es ridículo

Las pruebas solo pueden probar la existencia de errores, no su ausencia, por lo que cada programa escrito en virtud de este compromiso debería incluir una prueba rigurosa de corrección ... y una cobertura de prueba del 100%

"Tenga cuidado con los errores en el código anterior; solo he demostrado que es correcto, no lo he probado". - D. Knuth

Por supuesto, el trabajo y la responsabilidad de cada programador es escribir código libre de errores. Esa es una expectativa perfectamente razonable. ¿Cómo puedes ser un programador profesional si liberas código que no funciona? ¿Cómo puede considerarse un programador profesional si libera código que no sabe que funciona?

Si contrata a un pintor, espera que haga bien su trabajo. Esperas que el resultado de su trabajo esté libre de errores. Si hay errores, espera que él se haga responsable de esos errores y los repare de forma gratuita. Además, si los errores le cuestan dinero, espera que le reembolse el dinero. ¿Por qué tienes estas expectativas? Porque el pintor es un profesional.

Los programadores adoran culpar a todos los demás por sus errores. "Mi programa tiene errores debido a los requisitos, o por el horario, o porque la Luna está en la octava casa" Pero realmente no hay nadie más a quien culpar. Si el programa tiene errores, que los puso allí.

Nuestra profesión nunca será una profesión hasta que los programadores se den cuenta de que el dinero se detiene con ellos. Eso que son responsables de la calidad de sus programas.

¿Sabes por qué las empresas crearon departamentos de control de calidad de software? ¡Porque los programadores no estaban haciendo su trabajo! Los programadores estaban lanzando tanta basura que las compañías tuvieron que formar departamentos completamente nuevos para controlarlos.

¿Cuánto dura la lista de errores? ¿Es profesional tener miles de errores en la base de datos de errores? Claramente no lo es. Es un reflejo de mal comportamiento, mala disciplina y, francamente, deshonor.

Nunca seremos una profesión hasta que nos demos cuenta de que es nuestro trabajo asegurarnos de que el control de calidad no encuentre nada.

Lamentablemente, esto suena como una forma de "cubrir todas las bases", y claramente no es recomendable y es probable que solo genere desilusión en los desarrolladores.

Sin embargo, dicho esto, esto realmente solo importa una vez que vea lo que hacen con ese texto durante el período de revisión. Por lo tanto, no reaccione de forma exagerada demasiado rápido: aún puede haber cordura al final del túnel.

"Libre de errores" como en "¿perfecto?" Como en "escrito por Dios y los ángeles, ¿no los humanos?" (Estamos hablando de errores de lógica de programa y quizás de lógica de hardware)

No puedo decir con sinceridad ni una sola línea de código sin errores. ¡Eso es porque nosotros los humanos, bueno, no podemos probar ninguna hipótesis negativa!

Lo mejor que puedo decir es que la probabilidad de un error es un número entre 0 y 1. Alcanzo ese número por medio de principios de desarrollo y prueba de software bien o mal definidos y bien o mal entendidos; por un recuento de las líneas de software fuente en cuestión; mediante la comprensión de qué tan bien o mal candidato, pobre perro callejero, aplica esos principios al producir esas líneas de código; y más.

Y puedo expresar esa comprensión solo como una probabilidad. Entonces, el término "sin errores lógicos" significa casi nada.

Si vi un anuncio para un ingeniero de software que produjo un código "sin errores", lo solicitaría de inmediato o lo ejecutaría de inmediato: la compañía no ha pensado mucho en cómo desarrolla, prueba y entrega su software . Será una gran oportunidad o una pesadilla interminable.

Sin embargo, de cualquier software, puedo decir fácilmente, y debo decir, que espero un código que no tenga errores ajenos a esas cosas sucias, turbias y lógicas: código que compila y enlaza sin errores ni advertencias; eso es "html válido" o "css válido"; JavaScript (digamos) que no genera mensajes de error inexplicables o fallas del navegador. Esa parte la puedo medir directamente y marcar en blanco y negro en un gráfico.

Esa parte es fácil como el pastel. Cualquiera puede hacer eso .

Hola, buena suerte en tu búsqueda :-)

¿Estoy siendo estúpido o "error" no significa "mensaje fatal del compilador equivalente a un código no compilable"?

Según esa definición, es un requisito muy razonable ...