Este material ha sido preparado por nuestro socio, Equio .
Al comprar un producto de TI para resolver varios problemas corporativos, los clientes comerciales a menudo piensan en su costo, funcionalidad, conveniencia, capacidades de integración, etc. Estos no son problemas tan obvios, como la calidad y el nivel de soporte técnico, que ya están pensando en segundo lugar.
Pero la calidad del producto final depende en gran medida de cómo el desarrollador organizó el proceso de prueba, identificación y corrección de errores, entre los desarrolladores conocidos como "errores" (del inglés bug - un error, cualquier insecto, virus, jerga que generalmente significa un error en el programa). Esta pregunta la plantean muy pocos clientes comerciales individuales.
Queremos informarle sobre cómo los desarrolladores identifican y corrigen errores, son adecuados para las pruebas. Un enfoque se basa en la Política Zero Bug.
Spoiler! Le diremos en qué dedican tiempo los desarrolladores y por qué no corrigen todos los errores. 
Siete niñeras
Hay una broma muy conocida dedicada al anuncio de la nueva versión "Rendimiento optimizado de la aplicación, corrección de errores, nuevas añadidas". De hecho, corregir errores y agregar nuevos es un proceso eterno, los errores antiguos se corrigen, pero surgen no menos nuevos.
Esto es especialmente notable cuando un gran número de desarrolladores o incluso varios equipos de proyecto trabajan en un producto de software, en una sola base de código. Es muy difícil sincronizar sus esfuerzos y obtener el código de salida completamente libre de errores. Por ejemplo, un equipo guardó los cambios en la rama maestra, es decir, en la versión principal del código en el repositorio (repositorio). A su vez, el otro equipo se enfrenta a una gran cantidad de conflictos y está tratando de solucionarlos. Como resultado, todo esto se lanza al mercado, es decir, a la versión final del producto, adecuado para usuarios comunes, y aquí aparece una increíble cantidad de errores. Y esto está plagado de pérdida de dinero, clientes y, lo más importante, una amenaza para la reputación del desarrollador.
Entonces, ¿qué hacer en esta situación? Puede utilizar todas sus fuerzas y recursos para corregir errores, pero ¿cómo puede participar en el desarrollo de productos, mejorar los existentes y agregar nuevas funciones?
Fuera de la vista, acumular
Una gran empresa de TI acaba de tener un problema similar. Gracias a la recomendación de uno de los especialistas que trabajaban en la empresa, se decidió aplicar el enfoque de
Política de cero errores . Desafortunadamente, todavía se ha escrito poco sobre él en ruso.
Su esencia es la siguiente. Cuando los evaluadores o los usuarios encuentran algún error en el producto e informan a los desarrolladores al respecto, este último decide si este error se solucionará o no afectará el rendimiento del producto y, por lo tanto, su corrección puede retrasarse o excluirse por completo. de la cartera de pedidos (lista de tareas). A este error se le asigna el estado No se solucionará, después de lo cual desaparece para siempre del campo de visión de los desarrolladores. En algunos casos, los errores con este estado se colocan al final del trabajo atrasado. Esto significa que los desarrolladores "tendrán en sus manos" para solucionarlos solo cuando se resuelvan todas las demás tareas.
Pero volvamos a la compañía de TI ya mencionada. Sus empleados analizaron la lista completa de errores detectados y resolvieron los problemas encontrados. Se decidió que casi la mitad de los errores se solucionarían en un futuro próximo, y a más de la mitad se le asignó el estado No se solucionará. Todo este trabajo tomó alrededor de dos meses, después de lo cual la compañía decidió adoptar la
Política Zero Bug de manera continua. Hasta la fecha, esta empresa no tiene más de 10 tareas abiertas en la cartera de pedidos. Esto le permite centrarse en la implementación de nuevas características.
Expertos en errores
¿Cómo se ordenan los errores? ¿Quién toma la decisión de que un error es crítico y necesita ser corregido, y por el otro, puede continuar viviendo en paz o posponer su corrección hasta más tarde?
Le diremos cómo se organiza este proceso utilizando el concepto de gestión flexible de proyectos (Agile). Todos saben que Agile incluye varias técnicas. Tomaremos uno de ellos como ejemplo, SCRUM, ya que se usa con mayor frecuencia en el mundo del desarrollo de software.
El propietario del producto o el propietario del producto Scrum es uno de los miembros clave del equipo del proyecto. Es él quien representa los intereses de los usuarios finales y hace todo lo posible para maximizar el valor del producto. También es responsable desde el principio hasta el final de la acumulación de productos. Todo el equipo de desarrollo participa en la clasificación de errores, pero la última palabra es siempre para el propietario del producto. Determina qué error se solucionará y cuál se marcará como No se solucionará.
De hecho, todo es dinero. Por ejemplo, si corregir un error no generaría ningún beneficio financiero para la empresa, pero al mismo tiempo llevaría mucho tiempo y recursos, sería mejor que a ese error se le asigne el estado de No solucionar y posponga la reparación hasta tiempos mejores. De hecho, el "propietario del producto" es responsable de priorizar y del estado de los errores encontrados.
En otras palabras, todos tienen "esqueletos en el armario". Pero si no tienen ningún efecto sobre el rendimiento del producto, no impiden las acciones del usuario ni obstaculizan los procesos de integración, pueden ignorarse por completo.
Criterio de selección
Dichos errores "menores" se encuentran en los productos de cualquier desarrollador.
Por ejemplo, en la interfaz de administración del sistema de administración de contenido es imposible ingresar un título demasiado largo para una sección, artículo, etc. Los desarrolladores deciden no corregir este error. Después de todo, la corrección lleva tiempo, recursos, y solo puede tomar y reducir el nombre a un cierto número de caracteres. Es suficiente simplemente advertir al usuario que los nombres de más de 30 caracteres no son compatibles.
El botón está un poco en el color incorrecto, los elementos de la interfaz se encuentran dos píxeles a la izquierda de lo que se requiere; todos estos son errores que no afectan ni la usabilidad ni el rendimiento de la aplicación. Por lo tanto, potencialmente se pueden atribuir a Won't Fix.
Los errores críticos son principalmente aquellos que son manejados por muchos clientes que lideran o pueden conducir al hecho de que los clientes pierden dinero debido a fallas en los programadores. Todo esto define al Propietario del producto, que está obligado a conocer el producto como el dorso de su mano, y no solo a comprender su funcionalidad, sino también a comprender cómo lo usan los clientes comerciales, qué escenarios de aplicación existen en una empresa en particular.
Mente colectiva
La Política de cero errores a menudo se asocia con un Acuerdo de nivel de servicio (SLA). Por lo general, los desarrolladores tienen varias líneas de soporte técnico.
El primero recibe un mensaje de error del usuario y recopila todos los datos necesarios para su reproducción y análisis, y luego transfiere toda esta información a la segunda línea. Los especialistas de la segunda línea reproducen este error en estaciones de trabajo o servidores en los que está instalada la misma versión del producto que el usuario. Si el error se reproduce, como afirma el usuario, entonces la información sobre él cae en el sprint activo, es decir, una lista de tareas para desarrolladores.
La primera y segunda líneas de soporte técnico, así como los desarrolladores, tienen SLA. Cuanto más crítico es el error, más estrictos son los estándares de SLA para solucionarlo. También hay un SLA general para la resolución de problemas: desde el contacto con el cliente hasta obtener el código corregido en producción. La segunda línea de soporte técnico toma la decisión sobre si asignar un estado de error a No se solucionará o no. Sin embargo, su veredicto no es definitivo. En primer lugar, sus empleados se guían por los principios y las reglas del sprint actual. Además, hay una colección de expectativas de los desarrolladores, de los clientes, del departamento de desarrollo de negocios.
Si surge una situación controvertida cuando se tienen en cuenta todos estos factores, la última palabra estará precisamente detrás de la segunda línea de soporte y, por supuesto, del propietario del producto.
Satisfecho significa productivo
¿Por qué necesita todo esto una empresa de desarrollo? Una razón es la mayor motivación de los desarrolladores. Arreglar errores es un trabajo rutinario y desagradable, que no a todos les gusta hacer. Implementar nuevas funciones es mucho más interesante que corregir los errores de sus colegas. Esto aumenta la productividad y la productividad. Finalmente, de esta manera, sin sacrificar la calidad, se puede ahorrar seriamente en el mantenimiento de los probadores, dejando a uno o dos especialistas en la empresa en lugar de un departamento completo.
¿Por qué los usuarios y los clientes comerciales necesitan esto? El negocio se está desarrollando, se enfrenta constantemente a nuevos desafíos que deben abordarse con la ayuda de productos de TI. Y si los desarrolladores pasan la mayor parte del tiempo eliminando errores insignificantes, en lugar de mejorar la funcionalidad de sus creaciones, corren el riesgo de quedarse muy atrás de la competencia. Las empresas elegirán a los que están avanzando, manteniendo la barra de calidad en un alto nivel.
Eso es todo. Puede encontrar más información sobre la
compañía "Equio" en su sitio web oficial.
Y en
el sitio web de Otus puede familiarizarse con nuestros cursos y asistir a los
seminarios web gratuitos que le interesen.