Pull u orientación a la demanda

¿Qué se necesita?, ¿esto?, es lo que desarrollamos. Cualquier elemento de más es sobreproducción y corremos diferentes riesgos: que no podamos recuperar su inversión, que nos genere costes adicionales: en el caso de la producción de elementos físicos tenemos un ejemplo en los costes de almacenamiento y en el de los elementos lógicos lo tenemos en una mayor deuda técnica, complejidad funcional, etc… (además de haber desviado la atención de otras funcionalidades o tareas más prioritarias).

El concepto es sencillo, ¿lo es su implementación?. Vamos a centrarnos en el mundo de los proyectos de desarrollo de software:

– Requiere que el cliente o área usuaria estén implicados, de manera que se centren en priorizar de manera adecuada lo que necesitan, ajustándose a la capacidad de producción que tiene en cada momento el equipo de desarrollo.

– Requiere que el equipo de desarrollo respete el compromiso al que se ha llegado con el cliente, realizándose ajustes siempre por consenso entre las partes.

¿Cuáles son los riesgos?

– Que no exista una previsión sobre valles de producción, lo que puede dar lugar a que se desarrollen funcionalidades de más (algunas de ellas no prioritarias, otras no necesarias y otras que podrían cambiar por su dependencia con funcionalidades todavía no maduras), con tal de no tener a parte del equipo parado. Si se prevén, es posible hacer una gestión adecuada del equipo, de manera que se pueden dedicar a realizar actividades en otros proyectos (o incluso otras actividades en el mismo proyecto que seleccionadas sin la improvisación de tener que dar trabajo pueden ser beneficiosas: refactorización, mejoras de rendimiento, en la infraestructura de desarrollo, etc…).

– Que no exista una previsión sobre cimas de producción, lo que puede provocar que no se pueda atender a la demanda del cliente.

– Que el alcance de los trabajos sea de gran magnitud, ya que la probabilidad de que se hayan desarrollado funcionalidades que no se necesitan (o que incluso no deban aparecer en la versión del producto que se entrega) es mayor, además es muy posible que sea necesario perfeccionar muchas de ellas a través del feedback y la dependencia que puede existir entre ellas puede provocar el mantenimiento en cadena de varias de ellas.

Esto hace que una estrategia interesante sea reducir los tiempos entre versiones o lo que es lo mismo, las iteraciones no deben ser de gran duración. Esto permite, además, que los problemas que puedan producirse durante el desarrollo del sprint sean más sencillos (por regla general) de tratar.

– El cliente puede tener nuevas necesidades y la cadena de producción (sprint) está ocupada con otras tareas. Tendrá que esperar a que termine la iteración o aplicarse otras medidas en el caso de que no se pueda esperar. El hecho de no alterar los trabajos ya iniciados tiene su ventaja en el hecho de que el equipo está centrado en una serie de actividades, lo que le permite ser más productivo.

En el caso de que el desarrollo quede bloqueado, la aplicación de esta estrategia de trabajo, una vez que está interiorizada por el equipo y por la organización, hará que se centren los esfuerzos en desbaratar ese bloqueo, ya que de lo contrario no se podrá atender a nuevas demandas, ya que la capacidad de trabajo está comprometida en una serie de tareas que todavía no se han completado.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: