archivo

Archivo de la etiqueta: capacidad

Mientras el producto no esté en producción y, por tanto, no empiecen a llegar incidencias con diferente grado de prioridad y en cualquier momento, puede resultar relativamente sencillo mantener un determinado nivel de predecibilidad en los sprints, de manera que salvo errores importantes en las estimaciones se ejecutarán la mayor parte de las historias de usuario o incluso todas ellas.

Sin embargo, en el momento en que empiezan a llegar incidencias, la cosa cambia. Si no tienes capacidad de “reserva” para afrontarlas tocará tomar determinadas decisiones y para ello nos podemos hacer una serie de preguntas:

– ¿Dejo las incidencias para el siguiente sprint?.

Dependerá de la urgencia de las mismas y de lo que queda para que finalice el sprint, habrá veces en que se pueda aplazar al siguiente sprint, otras en las que incluso se dejará para más adelante y otras donde la criticidad haga que tengas que ponerte con ellas nada más conocer de su existencia.

– ¿Anulo el sprint e inicio uno nuevo en el que ya tenga en cuenta estas incidencias que han llegado?.

En este caso dependerá del número de incidencias y de su complejidad (además, como es lógico de su criticidad). Si vamos a tener que dedicar gran parte de la capacidad a trabajar en ellas, mantener el sprint definido deja de tener sentido. ¿Es la solución definir un nuevo sprint? Sí, pero en situaciones de inestabilidad, tal vez lo mejor sea que tengamos más peso de Kanban que de Scrum.

– ¿Cambio alcance del sprint de manera que sustituyo la realización de determinadas historias de usuario a cambio de las incidencias?.

Puede ser bastante práctico pero dependerá de las incidencias que lleguen porque si terminan desvirtuando el sprint, tal vez lo mejor sea cambiar de enfoque.

– ¿Introduzco las incidencias como parte del alcance del sprint, retrasando la finalización del mismo?.

La respuesta es similar a la anterior y dependerá también del contexto y situación del proyecto, de las incidencias y de lo que pueda aportar a la productividad de los equipos y a la efectividad de los trabajos mantener inamovibles la fecha de finalización de lo sprints.

Lo que quiero que saquéis como conclusión es que no es posible formular una solución que valga para todo. Tenéis que analizar qué os conviene más y siempre con una mentalidad abierta, más allá de la ortodoxia de la aplicación de una determinada estrategia o metodología.

No obstante, puede ser interesante, aún no siendo tampoco una solución universal, dejar siempre capacidad libre del equipo para atender a estas incidencias, de manera que no sea necesario mover el alcance del sprint salvo situaciones de saturación. Esa capacidad variaría en función de la estabilidad del producto y de las implantaciones (y de su importancia) que se estén realizando en ese momento.

¿Y si no se usa esa capacidad? Esa capacidad sobrante se puede utilizar para muchas cosas, desde tareas propias de infraestructura, programación por pares, realizar actividades opcionales sobre determinadas historias de usuario, etc…

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).

He comentado muchas veces que tener nuestra atención repartida en múltiples proyectos termina siendo contraproducente para los proyectos, porque no se les dedica ni el tiempo ni la energía que necesitan, y para nosotros mismos que terminamos desgastados y frustrados al ser conscientes de que independientemente de nuestros aciertos y errores, los resultados podrían haber sido mejores si hubiéramos estado más encima en el día a día.

Lo queramos o no, terminaremos cayendo en el overtime, no solo por el hecho de echar más horas, sino porque los problemas nos los llevamos a casa. Y conforme esta situación se extienda en el tiempo, menos será nuestra energía y productividad, a la par de que nos sentiremos menos motivados por el hecho de que parece que hemos caído en un bucle del que no podemos salir.

Quienes tienen responsabilidad de gestión tienen que tratar de determinar cuál es límite de cada persona, con el objeto no de llegar a él, sino de tratar que no se supere (son dos actitudes diferentes ante un mismo problema).

Yo he cometido el error y así lo atestigua más de un artículo en los primeros tiempos de este blog, de apoyar el hecho de que las tareas potenciales asignadas a una persona sean superiores al 100% para tratar de evitar situaciones en las cuales no hayan posibles tareas a asignar.

La realidad viene a demostrar que aunque esa situación se pueda dar, lo normal es que la carga se sitúe por encima de ese 100% y se caigan en los problemas indicados anteriormente.

Es fundamental que la carga de trabajo se adapte a nuestra capacidad, más allá de eso, los resultados no son buenos, de ahí que resulte fundamental la gestión del WIP (Work in progress).

Yamamoto Tsunetomo en el Hagakure dejó evidencia de lo importante que resulta adecuar la atención a nuestra capacidad: “Es necesario saber concentrarse en una sola cosa, todos los oficios deben ser realizados con concentración”.

Hay muchos gestores de proyectos que asignan tareas (cuando no proyectos completos) a personas que en esos momentos no reúnen la capacitación necesaria para llevarlas a cabo. A veces esas personas se sobreponen a la adversidad y son capaces de sacar dignamente el trabajo adelante, pero por regla general no será así.

Si un proyecto de desarrollo de software tiene incertidumbre de manera inherente, estamos añadiendo todavía más riesgos al mismo ya que estamos asignado tareas y responsabilidades a personas que a día de hoy no tienen los conocimientos y experiencia necesarios para enfrentarse a ellas.

Esto ha hecho mucho daño al desarrollo de software presentando a personas como “el experto en…” (sin serlo) y después abandonándolas a su suerte en el proyecto.

Lo peor de todo es que cuando los gestores hacen esa asignación son conscientes de lo que están haciendo y de las consecuencias que eso traerá consigo. Al final echarán las culpas a los técnicos cuando el principal culpable es, sin dudas, el gestor. Quiero aclarar que a veces el gestor también será una víctima, cuando se le encarga un proyecto en el que no se le da margen de maniobra en la elección del personal.

El problema parte de la base de ignorar que se trabaja con personas, no con robots (o ganado), y que cada una de ellas tiene su singularidad y unas circunstancias que hacen que su rendimiento sea más efectivo en unas tareas que en otras, teniendo en cuenta, además, que van evolucionando de manera que con el paso del tiempo pueden realizar tareas más complejas o de más responsabilidad, haberse especializado en áreas concretas, etc…

También es necesario tener en cuenta cómo funciona esa persona en equipo y en qué tipos de equipos pueden rendir mejor.

Obtener el mayor rendimiento de cada persona implica conocerla bien y eso requiere trabajar con ella de cerca durante el tiempo suficiente, eso requiere que el gestor de proyectos se implique y no vea los trabajos desde la distancia (cosa que ocurre demasiado a menudo, en unos casos por tener una cartera de proyectos importante y en otros casos porque es más cómodo estar fuera de la línea de fuego).

Uno de los aspectos en los que he cambiado de opinión está relacionado con la carga de trabajo que debe tener asignada ya sea un equipo o una persona. Justificaba y en mi blog hay artículos hablando de ello que cada persona tuviera tareas que en potencia superasen el 100% de su capacidad de manera que siempre (o casi siempre) hubiera la posibilidad de estar trabajando en tareas aunque uno de los proyectos o líneas de trabajo sufriera un parón.

Desde el punto de vista empresarial la situación ideal es aquella en la que la mayor parte de las horas laborables sean facturables o a través de ellas se generen oportunidades de negocio.

Sin embargo esta situación ideal llevada al mundo real presenta inconvenientes que, por supuesto, los ven solo quienes tienen una visión a ese nivel de detalle o se preocupan por analizar qué mecanismos permiten obtener la máxima productividad de las personas o de los equipos.

Es curioso, en propia persona sufría y sufro esa capacidad potencial de trabajo superior al 100%, veía y notaba sus consecuencias y, sin embargo, lo justificaba. ¿El motivo? Lo terminé considerando como algo normal y a partir de ahí trataba de dar una explicación a ese hecho.

También me pasaba con el enfoque de desarrollo clásico y les pasa a muchos que no terminan de considerar los enfoques ágiles como una alternativa.

Siempre suelo poner los mismos ejemplo. ¿Trabaja mejor tu ordenador cuándo lo tienes saturado de procesos abiertos?, ¿funciona mejor tu conexión a Internet cuando tienes prácticamente ocupado de manera continua tu ancho de banda?, ¿verdad que no?, ¿lo mismo nos pasa a nosotros?. Llega a un punto donde la saturación de trabajo bloquea a todo lo demás y el avance en esas tareas será más lento y probablemente con unos resultados de menor calidad y con una finalización de las mismas mucho más tarde de lo que sería deseable.

La saturación no es positiva, tampoco lo es la situación contraria, de ahí que el objetivo deba ser limitar la cantidad de trabajo y adaptarla a la capacidad que esa persona o equipo pueda asimilar en ese momento. El “ese momento” es importante porque la capacidad no tiene por qué ser siempre la misma y eso es inherente a las personas.

Esto no es fácil, habrá veces que nos quedemos cortos o que nos pasemos, sin embargo lo realmente importante es intentar poco a poco que la desviación con respecto a la situación ideal sea la menor posible.

Lo que hay que evitar es que la práctica general sea saturar a personas o equipos, ¿que de esta forma no se llega al límite de la capacidad potencial? Os pongo el siguiente ejemplo: cuando hacéis palomitas en el microondas siempre hay maíz que no se termina de abrir, ¿qué pasa si dejáis más tiempo el microondas para que esas pepitas terminen por abrirse? pues que se te habrán quemado las palomitas y la mayoría de las pepitas pendientes de abrirse (que no serán muchas) seguirán sin hacerlo. En este caso, la estrategia más productiva no es calentar las palomitas al 120% sino hacerlo dentro de unos márgenes apropiados aunque no se consiga que el 100% del maíz se abra.

Cuando un proyecto entra en una espiral en la que el equipo de proyecto tiene que enfrentarse continuamente a una horda de problemas que dificulta, sin duda, su avance y el cumplimiento en los compromisos en las diferentes iteraciones es que algo se ha hecho mal o que la situación de partida no era buena o, tal vez, ambas cosas.

También es cierto que si el equipo no se deja vencer por esta situación, va respondiendo, va ganando la batalla aunque parezca que nunca termina y se cumplen buena parte de los compromisos, es que algo se está haciendo bien.

La verdadera naturaleza de un equipo de proyecto, como en la vida, sale en los momentos malos, ahí es donde no solo vale la capacidad técnica o los conocimientos, sino la intención y las ganas de luchar por tratar de cumplir unos objetivos. Cuando el desgaste, la presión y los nervios te van haciendo más pequeño, solo te quedan dos opciones, dejarte vencer o tratar de enfrentarte a la situación, ahí es donde te haces grande y en donde demostrarás que no solo puedes ganar cuando el viento sopla a favor.

Si los problemas no dejan de aparecer, llegado el momento adecuado (porque una solución aplicada en mal momento por muy buena intención que lleve, puede empeorarlo), es necesario actuar.

Muchos de esos problemas (más de lo que se piensan) son el resultado de someter a los equipos a una carga de trabajo superior a la que pueden admitir, lo que provoca que cualquier contingencia se convierta prácticamente en un obstáculo insalvable. Si a eso le sumamos otros riesgos como un entorno tecnológico inestable, un código con mala deuda técnica, la participación de diferentes equipos que tienen que sincronizar desarrollos, etc…, la aparición de problemas, uno tras otro, será inevitable, mientras pasan los días y es necesario cumplir lo pactado.

Hablo de solución y debería hacerlo en plural porque generalmente e independientemente de que haya algún problema principal hay otros secundarios que por si mismos o por alimentar a terceros, también deben ser tratados.

Insisto muchas veces en la necesidad de reconocer nuestros errores y nuestras limitaciones, para poder seguir creciendo personal y profesionalmente.

En el desarrollo de software es algo esencial porque trabajas en un contexto cambiante y en el que te va a resultar complicado conseguir buenos resultados en todos los proyectos. en el éxito y en el fracaso tienes que ser crítico contigo mismo porque seguro que hay margen de mejora, siempre lo hay.

No reconocer los errores o nuestro amplio margen de mejora puede ser una actitud ante los problemas que pueden surgir en el trabajo, como una autodefensa: “si no reconozco que hago algo mal o que no se me da bien hacer esto otro, es posible que nadie me lo diga y con el tiempo todo se olvide”.

Sin embargo, hay veces que no se actúa así de manera consciente, tal como lo demostraron Justin Kruger y David Dunning tras una serie de experimentos llegando a la conclusión de que personas con escaso conocimiento tienden a pensar de manera ilusoria que su habilidad es mucho mayor que la media y a considerarse más inteligentes que otras personas más preparadas, debido a que su propia falta de competencia les hace más complicado reconocer los errores y medir el nivel de competencia de los demás (a esto se le ha denominado efecto Dunning-Kruger).

Por el lado contrario, las personas más competentes tienden a subestimar su propia capacidad.

El efecto Dunning-Kruger no es permanente, ya que conforme las personas van mejorando sus habilidades se van dando cuenta no solo del conocimiento que no tenían, sino del que todavía necesitan adquirir.