archivo

Archivos Mensuales: enero 2013

Un error muy frecuente es no prever un nivel de servicio en la garantía. Esto es muy problemático principalmente en los enfoques en cascada donde todo se juega a una carta, ya que por mucho testing que se haga, sabemos que habrá incidencias que lleguen a producción, muchas de las cuales no se detectarán hasta que el producto se esté utilizando de manera efectiva, algo que no ocurre necesariamente tras el paso a producción.

Al proveedor hay que entenderle ya que tras cerrarse el objeto de contrato necesita volver a asignar tareas facturables a los componentes del equipo de proyecto. También hay que entender al cliente que querrá que esas incidencias se corrijan en un tiempo razonable, ya que algunas de ellas podrían afectar a las funcionalidades más críticas del sistema.

Lo que suele pasar es que el proveedor se hará cargo de sus responsabilidades contractuales (no sin protestar o sin poner trabas en algún caso) pero los tiempos de respuesta no serán, generalmente, buenos, porque dedicará pocas personas a este trabajo, las cuales a su vez estarán asignadas a otro proyecto o proyectos.

No se trata de saltar al vacío, no se trata de perder la cabeza. A veces hay que arriesgar porque no siempre contamos a priori con todas las respuestas.

La adaptación al cambio tiene riesgos porque sueles introducirte en terreno desconocido, tienes que tomar decisiones para pasar de una situación que controlas o que has empezado a controlar a otra totalmente nueva.

Se asociar error a riesgo y es algo comprensible, pero también nos equivocamos muchas veces por esperar demasiado o por mantener una posición dentro de nuestra zona de seguridad. Y probablemente si lo ponemos en la balanza tengamos más o menos nivelados nuestros errores por actuar como por no hacerlo.

Ya lo dice Peter Drucker: “Las personas que no toman riesgos suelen hacer sobre dos grandes errores al año. Las personas que hacen correr riesgos suelen hacer sobre dos grandes errores al año”.

La diferencia entre arriesgar o no es que en el primer caso lo haces con intención y en el segundo eres sujeto pasivo esperando a que el problema pase o que se encargue otro de él.

Este antipatrón surge cuando no se consigue poner remedio a esa sensación de bloqueo que tenemos cuando nos encontramos ante nosotros con una carga de trabajo de gran magnitud y/o ante un problema de gran complejidad, sabiendo además que nuestros recursos son limitados y que nos espera mucho esfuerzo, tiempo y hacer las cosas muy bien para superarlo.

Esa montaña se nos hace todavía más grande de lo que es y no por el hecho de evitarla va a terminar desapareciendo, es más, resulta probable que el problema siga creciendo a la par de que dispongamos menos tiempo o medios para hacerle frente.

Esa sensación nos las encontramos con frecuencia en los proyectos de desarrollo de software y la única manera de que no se termine convirtiendo en antipatrón y nos traiga todos sus inconvenientes, es empezar a trabajar en la solución, ya que de esa forma, poco a poco, el muro se hará más pequeño.

Es curioso, lo sabemos y sin embargo seguimos sintiéndonos bloqueados por esa situación, no obstante de la misma forma que otras veces hemos encontrado el camino (con más o menos éxito), lo volveremos a encontrar si dejamos de mirar hacia el obstáculo y de autocompadecernos.

El concepto de espíritu de Dunkerque surge como consecuencia del esfuerzo realizado en mayo de 1940 por ciudadanos británicos en conjunción con sus fuerzas armadas para la evacuación del grueso de las tropas aliadas en la 2ª Guerra Mundial, como consecuencia del empuje de las fuerzas alemanas y el riesgo de quedar arrasadas ante la imposibilidad de defensa u otras vías de escape.

Se considera que el esfuerzo y el riesgo de unos pocos, implicados directamente o no en la guerra, permitió salvar a muchos.

Por tanto, ese concepto se utiliza para representar un espíritu de unión ante una situación adversa o complicada.

¿Cómo puede considerarse algo así un antipatrón y cómo se relaciona con el desarrollo de software?.

Existen proyectos que se consiguen salvar o que llegan a tener éxito gracias al esfuerzo de unas cuantas personas, generalmente las que están en el día a día, pese a que las condiciones de partida se encontraban próximas a un Death March Project y/o el conjunto de toma de decisiones hacían todo mucho más difícil.

Este antipatrón surge cuando tras la realización de ese esfuerzo (con ese espíritu de Dunkerque), esa mala negociación inicial, esa mala venta o esas decisiones tomadas de forma negligente quedan ocultas o minimizadas, con el riesgo de que en el siguiente proyecto pueda volver a pasar lo mismo, si el responsable o los responsables no han aprendido nada de lo sucedido.

Además, cómo no ha pasado nada, el mérito del equipo no será tenido en cuenta de manera adecuada, pudiendo pasar, como sucede muchas veces que el mérito se lo lleve quién o quiénes provocaron la situación de partida o han provocado resistencias en el proyecto.

No es cuestión de quién se lleve las medallas, sino de ser justo. Probablemente si el equipo siente que no ha existido justicia será mucho más complicado que el espíritu de Dunkerque vuelva a aparecer.

Te preguntarás, ¿qué se hace entonces?, ¿se deja fracasar el proyecto para que esos problemas salgan a la luz? No. El equipo de proyecto ha actuado como debe, sacando adelante un proyecto en unas condiciones muy complicadas. Es un problema de carácter organizativo ya que los responsables o jefes de quiénes han provocado esta situación, no han llegado a darse cuenta del problema, ya sea porque no han dedicado la suficiente atención, lo han seguido desde demasiado lejos o han realizado una gestión basada en números. O peor aún, siendo conscientes de la situación, no han hecho nada.

¿Y si vuelve a ocurrir?, ¿qué hacemos? Yo no soy partidario de bajar los brazos, mi opinión es que el equipo debe seguir trabajando de la mejor manera posible, si no lo hace, se convierte en cómplice y creo que eso no sería justo con el equipo. Si bien, entiendo perfectamente que la motivación y como consecuencia, la productividad baje, porque somos humanos y estas cosas nos afectan.

Una buena actitud para un gestor es contribuir a la creación de un ambiente en el que las decisiones se tomen por consenso, entre otras cosas porque de esta manera, se tienen en cuenta más puntos de vista, más opiniones, más experiencias, lo que hace que la probabilidad de acierto sea mayor y que las personas estén más comprometidas, porque se sienten parte y responsables de la solución.

Es importante tener en cuenta que actuando de esta manera no se reparte la responsabilidad, ya que la misma sigue siendo de la persona que tiene la última palabra (y que cobra por ello). La excepción la tendríamos en órganos colegiados donde la decisión se hace bien por consensos o por mayorías.

Este buena práctica se convierte en antipatrón en el momento que se producen alguna de las siguientes circunstancias:

– Se quiere hacer copartícipe de la responsabilidad a otras personas por si la decisión que se toma no ha sido la más adecuada. Es decir, la búsqueda del consenso se hace como mecanismo de defensa, pensando en uno mismo y no pensando en los beneficios reales que tiene para el proyecto. Esto termina degenerando, generalmente, en que solo se termina recurriendo al consenso en situaciones que pueden ser conflictivas en el caso de que salgan mal y pasando de él en el resto de los casos.

– Cuando incluso con la mejor de las intenciones, se trata de someter a consenso decisiones de carácter operativo, provocando un bloqueo en el día a día del proyecto, invirtiendo esfuerzo innecesario por parte de terceras personas que pudiera ser mejor aprovechado en las tareas u objetivos que tienen encomendado.

– Cuando teniendo que tomar una decisión en ese momento, no se toma (siendo esta la peor solución), por no haberse conseguido un consenso entre las personas implicadas.

Si una organización o un proyecto sobrevive por la extraordinaria capacidad de algunos individuos, nos encontramos ante una situación poco sostenible: En el momento en que esas personas se vayan, bajen el nivel o dejen de funcionar sus estrategias, todas las debilidades quedan expuestas y como no tienes mecanismos de defensa, se va a tardar en reaccionar, a veces tanto que lo mismo ya no hay solución o las pérdidas económicas son enormes.

Para Peter Drucker: “Ninguna institución puede sobrevivir si necesita genios o superhombres para su gestión. Deben organizarse de tal manera que puedan ser gestionadas adecuadamente por seres humanos medios”.

Claro que el talento es importante y decisivo y que cuanto más talento tengas mejor. No se trata de evitarlo, sino de diversificar los pilares que sostienen a la organización. Se trata de minimizar el impacto en el caso de que esas personas decisivas dejen, por el motivo que sea, de serlo.

Este antipatrón surge como consecuencia de múltiples cambios en una aplicación que se llevan a cabo de forma simultánea en el mismo, de manera que es posible que se haya aplicado la misma solución en diferentes partes del código, de manera que tendremos clases y/o métodos con un comportamiento parecido aunque tengan codificación diferente.

También es posible que se haya llegado a él, no por el hecho de no poder controlar la programación de personas distintas en diversas funcionalidades de la aplicación, sino por la mala práctica de ir copiando secciones de código, realizando las modificaciones oportunas, achacándolo a las prisas y a la presión por la entrega y/o por terceros.

Como consecuencia tenemos un código más complejo, con más deuda técnica y, por tanto, con un mayor esfuerzo de evolución y mantenimiento (hay que tener en cuenta que es posible que con estas prácticas, para hacer un cambio sea necesario hacer modificaciones en tantos puntos como ese código haya sido replicado).