¿Dónde cae la mejora del proceso de desarrollo en el ciclo de vida del desarrollo del producto?

Parece que hay algunas preguntas horneadas aquí:

• ¿Qué fase o actividad en el ciclo de vida del desarrollo del producto incluye la mejora del proceso?
• ¿Es necesaria la mejora de procesos para alcanzar y mantener los objetivos del producto?
• ¿Por qué no vemos KPI relacionados con la mejora de procesos?

El lugar donde se incluye la mejora de procesos en un ciclo de vida depende del modelo de ciclo de vida. La mejora de procesos es una actividad continua, por lo que es posible que no se incluya explícitamente en algunos modelos basados ​​en fases. Tendría que planificar (en el cronograma y el presupuesto) y administrar cualquier actividad en curso, incluida la mejora de procesos, pero las actividades explícitas de mejora de procesos tocan todas las actividades en el ciclo de vida.

La mejora de procesos probablemente no sea necesaria para lograr un conjunto de objetivos de productos. Sin embargo, es necesario que una organización mantenga una ventaja sobre sus competidores. Si una organización no considera nuevas formas de trabajar, es probable que un competidor que lo haga lo supere. El riesgo de esto depende de muchos factores en el contexto.

No estoy seguro de por qué no suele haber KPI relacionados con la mejora de procesos. Hay una serie de métricas que reflejan el proceso: tiempo de entrega, tiempo de ciclo, rendimiento, efectividad de eliminación de defectos son algunos ejemplos. Cualquiera de estos se puede utilizar como parte de los KPI. Sin embargo, incluso si una organización ve la mejora como un aspecto importante del desarrollo de productos, es posible que no alcance un KPI.

Está haciendo diferentes preguntas sobre la misma declaración, así que asumiré que su pregunta subyacente se reduce a

"¿Por qué mi Product Owner no prioriza (o hace visibles) los esfuerzos del equipo de desarrollo, ya sean técnicos u organizativos?"

Puede haber diferentes razones para eso. Una de las razones más comunes (especialmente si tiene un PO no muy experimentado) es porque piensa que ese no es su trabajo (y algunos pueden argumentar que no lo es, de hecho). Depende del equipo hablar y hacerlo visible.

¿Por qué parece que los equipos de productos generalmente no incluyen explícitamente el proceso de desarrollo como parte de los KPI del producto?

¿Quién define los KPI? Si alguna medición del equipo se define de forma aislada, sin ninguna conversación con el equipo, volvemos (nuevamente) a la cultura de hablar que el equipo necesita. El manifiesto ágil nos recuerda que el software de trabajo es la medida principal del progreso. Los KPI son un medio (y, a menudo, mal utilizado) para lograr un objetivo. El objetivo aquí son los resultados. Concéntrese en entregar software que funcione y mejorar los procesos relacionados con la entrega de software. Esa es la mejor manera de demostrar que las mejoras de ese equipo valen la inversión.

Creo que tiene un buen punto: el trabajo de mejora debe ser parte de los KPI del producto .

Al hacer que la definición del producto incluya la capacidad de entrega, es de esperar que se asegure de que, a medida que el producto mejora, también lo hace la capacidad de ofrecer mejoras futuras.

Sospecho que la razón por la que esto sucede rara vez (según mi experiencia) es que la función de ingeniería en las organizaciones generalmente se considera separada de la función del producto. Es una pena, ya que sería mejor ver todo el proceso de entrega de valor como un todo ("el equipo de producto").

Un enfoque común utilizado hoy en día es hacer que el trabajo de mejora forme parte de los KPI del equipo de desarrollo. Esto tiene la desventaja de que potencialmente puede crear una desalineación: una competencia por el tiempo del equipo entre el trabajo de mejora y el desarrollo del producto.

Permítame explorar un punto de vista radical, que admito que puede no ayudarlo en su entorno organizacional. Primero, su excelente pregunta apunta a otra razón por la que muchos pensadores ágiles consideran que el SDLC es un modelo obsoleto. Todos los proyectos dependen en cierta medida del trabajo anterior, y los que tienen éxito nunca se "cierran" realmente: solo hay una nueva versión principal. Además, los cronogramas y presupuestos clásicos en cascada son irrelevantes en una organización verdaderamente ágil. Por lo tanto, cualquier KPI que refleje el pensamiento en cascada también es irrelevante.

Se supone que los equipos ágiles se organizan a sí mismos, formados por trabajadores motivados en los que se confía para satisfacer al cliente. (En el caso que está describiendo, donde el equipo no interactúa directamente con clientes externos, trataría al Gerente de Producto o un rol similar como el "Cliente", no como el Propietario del Producto). En mi enfoque, recomiendo que los equipos mantengan devolver al menos el 10 % de su capacidad en cada sprint para trabajar en lo que saben que es importante para complacer al Cliente, incluso si el Cliente no lo reconoce: refactorización, corrección de errores heredados, mejora de procesos o herramientas, etc. Hacen esto creando historias de usuario para hacer ese trabajo, por lo que es transparente. Se pueden crear KPI para algunos de estos si es necesario, como "recuento de errores heredados" o "tiempo de trabajo por ticket de corrección de errores".

En resumen, tiene razón en que puede haber KPI que reflejen esas actividades importantes. El problema son los gerentes que afirman ser ágiles pero aún están atrapados en formas ineficientes de administrar programas de software.