En primer lugar, la gestión de proyectos es una cosa y la gestión de la calidad del producto es otra. La mayoría de las veces, tiene comentarios de las personas que compran el software, especialmente cuando no están satisfechos. A veces es demasiado tarde para realizar cambios en el software cuando ya está en el mercado.

En segundo lugar, puede incluir círculos de calidad a lo largo del desarrollo de su software para obtener comentarios de clientes potenciales. Así evitas sorpresas que llegan demasiado tarde. Una cosa es desarrollar un producto y otra cosa es venderlo.

Tercero. tienes que establecer objetivos claros, medibles y alcanzables en el desarrollo de tu producto. Metas que son fáciles de verificar regularmente. En administración de empresas lo llamamos "control de calidad".

Finalmente, es importante saber desde el principio quién es séptico con el éxito del producto y por qué. A veces, algunos miembros de un equipo prefieren sacar provecho del proceso que declararlo muerto desde el principio. ¿Cómo está seguro de tener éxito en la gestión de productos? Se trata de las necesidades de los clientes. Nadie está obligado a comprar su producto.

TL;DR

Si bien la calidad se puede medir objetivamente, definir los elementos de calidad específicos del dominio para su organización no es algo en lo que pueda confiar en una definición de diccionario estándar.

De hecho, la mayoría de los problemas que ha identificado no son problemas de calidad intrínseca en absoluto. Parecen más problemas de organización . Veremos algunos de ellos con más detalle y luego seguiremos con algunas prácticas de desarrollo y administración de proyectos que pueden ayudar.

Sus ejemplos, analizados

1. No se han lanzado nuevas características importantes en los últimos tiempos.

   El desarrollo continuo de funciones no es un signo de calidad. Cuando un producto es "lo suficientemente bueno" para venderlo en el mercado y se ajusta a su propósito, la característica suele ser una señal de que la empresa carece de visión de mercado o de comentarios de los clientes. Por ejemplo, la gente no quería Clippy o Microsoft Bob; a menudo solo querían menos errores, pantallas azules y virus.

2. Diferente UX a través de subproductos

   Este es un problema de proceso , no un problema de calidad per se. ¿Quién está impulsando la necesidad de un UX unificador? Si los clientes no lo exigen y su proceso no incluye la integración entre equipos, entonces se trata de un problema de apariencia y no de calidad real.

3. Algunos módulos de software apenas se mantienen después de los cambios de propiedad

   Esto es 100% un problema organizacional. Sin la propiedad colectiva del código, una cultura de refactorización continua o un gobierno de TI que imponga la propiedad de los componentes o procesos, el código brownfield casi siempre se convierte en un código heredado no querido. Su liderazgo necesita asignar la propiedad de los componentes a lo largo del ciclo de vida del producto, porque la esperanza y el deseo no son estrategias reales.

4. El equipo de arquitectos no es responsable de la calidad.

   ¿Deberían serlo? La arquitectura es (a menudo, pero no siempre) responsable del diseño de alto nivel. Son los equipos de ingeniería y control de calidad (o, mejor aún, equipos completamente multifuncionales) los que realmente implementan las soluciones y las incorporan y prueban la calidad.

   Una vez más, la calidad significa lo que su organización decida que significa. Defínalo, acuerdelo en toda la organización y luego pruebe continuamente las métricas de calidad que todos hayan acordado colectivamente. Sin ese acuerdo y pruebas, la "calidad" es solo una palabra de moda.

5. Los desarrolladores de software comenzaron a abandonar el proyecto.

   Churn ocurre en todos los proyectos. Sin embargo, los rápidos vuelos de talento a menudo indican una cultura laboral tóxica, proyectos sin salida, marchas de la muerte, recortes presupuestarios y otros antipatrones organizacionales bien conocidos. Si bien el equipo ciertamente puede realizar una retrospectiva para identificar problemas potenciales, el liderazgo empresarial en última instancia tiene la responsabilidad de solucionar los problemas de cultura y procesos que conducen a la pérdida de talento clave.

6. Parece demasiada coordinación entre equipos para nuevas iniciativas

   La "parálisis por análisis" es un antipatrón conocido. Las grandes iniciativas, especialmente para proyectos brownfield, siempre requieren más colaboración que los pequeños proyectos greenfield. Si bien el ritmo del cambio a menudo se ralentiza o se detiene a medida que los proyectos se hacen más grandes, el problema más grande puede ser que necesite un marco que vaya más allá de un solo equipo y funcione en varios equipos. Nexus, LeSS y SAFe son ejemplos del mundo ágil.

7. A menudo se utilizan soluciones alternativas para cumplir con los requisitos del cliente

   Si bien esto puede representar algún tipo de deuda tecnológica, no es inherentemente un problema de control de calidad. Si bien la deuda tecnológica puede retrasar el desarrollo o representar un truco rápido y sucio de calidad inferior a la ideal, la mera existencia de soluciones no necesariamente indica una calidad de producto insuficiente.

Cómo mejorar la calidad

Hay varios enfoques que puede tomar para mejorar la calidad del software, pero todos generalmente implican integrar la calidad en sus procesos organizacionales y de desarrollo. Algunos ejemplos incluyen:

1. Practicar el desarrollo basado en pruebas o basado en el comportamiento.
2. Integrar prácticas modernas de integración continua en su proceso de desarrollo.
3. Asegurar que el equipo y la organización se tomen el tiempo de forma rutinaria para inspeccionar y adaptar sus valores y prácticas, y hacer de la mejora continua una prioridad.
4. Seguimiento constante de la deuda técnica y asignación rutinaria de recursos para pagar esa deuda.
5. “Detener la línea” para abordar problemas importantes de control de calidad.
6. Asegurarse de que el software funcional y la "idoneidad para el propósito" sean más importantes para la organización que simplemente cumplir con las especificaciones.
7. Tomarse el tiempo para refactorizar y rediseñar cualquier aspecto del sistema que sea difícil de ampliar o mantener.
8. Adoptar un enfoque metódico para el cambio. Escribir pruebas antes del código, o seguir el método Mikado para implementar rediseños, son solo dos ejemplos relevantes.
9. Asegurarse de que su software esté siempre en un estado potencialmente enviable.
10. Aprovechar la alternancia de funciones y otras prácticas de entrega continua.

Muchos de estos realmente caen en el campo de las prácticas de desarrollo, en lugar de la gestión de proyectos per se. En ese frente, sus mejores apuestas son realmente:

• comunicación efectiva (con el equipo, con las partes interesadas y con los clientes),
• bucles de retroalimentación muy estrechos, y
• un enfoque implacable en la mejora continua tanto de su proceso como del producto.

No hay bala de plata. Al final, debe definir qué significa la calidad para usted, decidir cómo la medirá y luego inspeccionar y adaptar sus controles de calidad y sus resultados reales a lo largo del ciclo de vida del proyecto.

Podría decir algo sobre cada uno de sus puntos, pero me referiré a uno. Si aborda este, entonces lo resolverá todo (eventualmente).

“Los desarrolladores de software comenzaron a abandonar el proyecto”

¿Pregunta porque? Pregúntales ¿por qué? Pregunte a las personas que se quedan ¿por qué?

Realice retrospectivas regulares, descubra por qué, haga que los desarrolladores encuentren y solucionen los problemas. Bríndeles todo el apoyo que necesiten/quieran. Tenga cuidado de no volcarlo sobre ellos, y tenga cuidado de no seguir controlándolos, si quieren arreglarlo.

No culpes. No castigues. Si te dicen que ellos/alguien se equivocaron, entonces no reacciones: esta es información nueva, no lo habrías sabido si no te lo hubieran dicho. Pregunte qué podemos hacer para evitar que esto vuelva a suceder (sin culpa). Pregúnteles qué harían para mejorar las cosas. Ejecutar experimentos, iteraciones cortas. Mejora un paso a la vez. No intente arreglarlo todo de una sola vez (quebrará antes de terminar).

Además, el tamaño de su equipo es demasiado grande ("No se han lanzado nuevas funciones importantes en los últimos tiempos", "Más de 50 personas"). Sin embargo, no debe expulsarlos de la empresa. Encuentra otro trabajo independiente para ellos (otro proyecto). Obtenga una garantía por escrito de la junta directiva de que no habrá despidos debido a la mejora del proceso. El primer despido destruirá la cooperación.

“añadir recursos humanos a un proyecto de software tardío lo hace más tardío”. — Fred Brooks en su libro de 1975 The Mythical Man-Month. Quitarlos puede hacerlo antes. Pero no te centres en este aspecto. Concéntrese en por qué se van (las personas pueden irse mientras tanto, y necesita descubrir cómo reducir el tamaño sin destruir la motivación. Puede mover a parte del equipo a pruebas, otros roles de soporte o mejora de procesos. Luego eventualmente en otros proyectos.

La primera pregunta es: ¿qué objetivos de calidad tienes? Los objetivos típicos se enumeran aquí .

Si identifica un número limitado de objetivos, puede ponerlos en su Definición de Hecho (DoD) en formas como: "Cada compromiso debe mantener o mejorar (modularidad/seguridad/lo que sea)"

La siguiente pregunta es entonces: ¿cómo garantizar y hacer cumplir? ¿Usas métricas de código? ¿Hacer revisiones de código? ¿Y alguien realmente usa el Departamento de Defensa? :-)