Desarrollo de software. El ritmo lo debe marcar lo que sale y no lo que entra

Si no se acota la cantidad de trabajo que se puede asumir a la capacidad real existente, quiere decir que el ritmo del proceso de desarrollo no lo marca la cantidad de trabajo que podemos sacar sino la cantidad de trabajo que entra y eso a corto, medio y largo plazo resulta perjudicial porque resulta muy complicado volver a encontrar el equilibrio.

¿Qué pasa cuando se satura un servidor o un PC? Que el rendimiento de los procesos abiertos cae en picado, pues exactamente lo mismo pasa cuando saturamos la línea de trabajo.

Por ese motivo insisto que un departamento TIC no debe decir a todo que sí, sino que debe ajustar su servicio a lo que realmente puede admitir y lo que no entre ahí tendrá que esperar. El problema es que como los departamentos TIC no pintan nada, aunque digan que no, habrá alguien más arriba que dirá que sí y empiece a saturar con ese tipo de decisiones a la capacidad de trabajo existente.

El problema no es solo ese, sino que además los departamentos TIC, como consecuencia de la crisis económica, cuentan con menos presupuesto, por lo que con cada recorte se desborda la capacidad, ya que con menos personal se deben seguir prestando los servicios básicos a la organización que además, crecen con el tiempo, al existir un mayor número de sistemas en la organización y ser cada vez más críticos en sus procesos internos y de negocio. Si a esto le sumas esa carga adicional de trabajo, por mucha voluntad que se ponga, la calidad del servicio caerá en picado.

El ritmo lo debe marcar lo que sale, porque las tareas que conseguimos terminar son las que determinan nuestra capacidad real y las que permiten dejar un hueco para que se pueda trabajar sobre otra.

En los proyectos de desarrollo de software pasa lo mismo, si trabajamos sobre demasiadas tareas de forma simultánea el esfuerzo y tiempo necesario para la realización de las mismas será mayor (incluso mucho mayor) que si las mismas estuvieran ajustadas a la capacidad del equipo, además, se corre el riesgo de que muchas de ellas queden abiertas indefinidamente si su prioridad no es muy alta, ya que seguirán entrando nuevas tareas y la presión y la carga de trabajo tiende a hacer que se centre el esfuerzo en ir cerrando todas las tareas que se puedan, que generalmente serán aquellas más simples y/o con mayor prioridad.

Una de las grandes aportaciones de la orientación a sprint (se siga Scrum o no) o de la aplicación de Kanban la tenemos en que se trata de limitar la cantidad de trabajo absorbible a la capacidad real de trabajo que puede admitir el equipo (limitación del WIP: Work in progress).

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: