archivo

Archivos Mensuales: febrero 2012

En el desarrollo de software tratamos con personas: compañeros del equipo de proyecto, jefes, otros compañeros, clientes, la competencia, etc… Siempre he considerado que quienes mejor consiguen tratar con ellas y descifrarlas tienen mucho ganado en este negocio.

Y lo considero así, porque no tratamos con n personas, sino que de ellas un número significativo no tiene una sola cara, o dos, sino que son poliédricos.

En muchos casos, ser poliédrico es algo totalmente inofensivo, se trata simplemente de un cambio de interfaz en función del contexto. En otros casos resulta un antipatrón nefasto porque provocas una pérdida de confianza en todos aquellos que descubren que la imagen que tratas de dar no tiene nada que ver con la realidad y sin confianza te quedas aislado y sin la posibilidad de alcanzar objetivos para los que son necesarias las personas que han dejado de creer en ti.

Este antipatrón es peligroso porque muchos poliédricos llegan a serlo sin darse cuenta, poco a poco, para proteger sus intereses empiezan a ofrecer una imagen para unos y otra para otros y lo que en un principio era solo un recurso, se convierte en un hábito y lo que era una táctica para momentos puntuales se convierte en un arte, el de manipular.

Ser coherente hace todo más complicado, sin embargo, genera confianza. Ser poliédrico encuentra atajos y permite conseguir resultados hasta que de pronto se te cae la máscara y nadie cree en ti.

Es curioso, pero cuando nos preguntan tendemos a dar un grado de avance superior al real y no siempre se hace con la intención de dar una imagen optimista del proceso de desarrollo que no se ajusta con la realidad sino porque los que nos dedicamos a esto somos optimistas por naturaleza, por mucho que seamos conscientes de la problemática de cada proyecto concreto y de la incertidumbre que rodea al desarrollo de software.

Como somos de esta forma, corregirnos es difícil, por mucho que nos hayamos comprometidos en infinidad de ocasiones con plazos realmente temerarios. En cualquier caso, no está de más, tomarnos un tiempo y consultar con el equipo el estado real de los trabajos antes de apresurarnos a decir nada.

Sin embargo, el verdadero problema no es dejarse llevar por el optimismo o por nuestras ganas (van de la mano) sino dar estimaciones con ánimo de engañar. Aunque pueda parecer que el resultado en los dos casos es el mismo, no es así, y la comprensión por parte de terceras partes cuando las cosas se hacen con buena fe es mucho mayor que cuando la misma brilla por su ausencia (aunque la tercera parte no sepa realmente si los has hecho queriendo o sin querer) y es que resulta mucho más fácil explicar las cosas desde la verdad que desde la mentira.

Otro problema de las estimaciones, es el remate de los sistemas de información, donde si no se analiza, llegado a cierto punto, lo que cuesta implementar determinadas funcionalidades que no son fundamentales en el sistema, no se termina nunca de darle vueltas al sistema porque tras el desarrollo de una vendrá otra, intercalándose con tareas de mantenimiento evolutivo que sí resultan necesarias.

Ese remate resulta todavía más lento (o interminable), si la calidad integral del desarrollo (hacia fuera y hacia dentro) no ha sido buena.

Hay una cita de Terry Baker que resume en pocas palabras el contenido de este artículo: “Un programa nunca está menos del 90% completo y nunca más del 95% completo”.

La prepotencia no te permite crecer, la humildad sí. La prepotencia te aísla, la humildad te une al grupo. La prepotencia es una muestra de debilidad, tras tu ego no hay nada, la humildad es un síntoma de fortaleza, tras tu ego está todo.

He tenido la oportunidad de conocer a muchísimos desarrolladores de diferentes organizaciones y perfiles y entre ellos a personas muy brillantes. Ahora bien, ninguno es infalible, ninguno lo sabe todo y ninguno es lo suficientemente bueno como para mirar a nadie por encima del hombro.

Cuando uno trabaja en equipo hay que escuchar a todos sus integrantes, a todos, incluso al que ha llegado hace dos días al proyecto. Todos pueden aportar una idea o hacerte reflexionar y mejorar tu planteamiento inicial a través de su confrontación con otro enfoque.

El conocimiento del conjunto es mayor que el individual, ese de por sí debería bastar para que la comunicación sea fluida en el equipo, si a eso le sumas que el personal que se siente integrado en un proyecto está más motivado y a que la comunicación es esencial en cualquier trabajo en equipo, debería ser más suficiente para que te plantees un cambio de actitud y sientas que el grupo, el equipo, hace más fuerte un proyecto, si efectivamente consigues que funcione como un grupo o un equipo, algo que no puedes lograr si te sientes por encima de él.

En el momento en que nuestra atención en el proyecto es mayor que la atención al producto y en el usuario, dejamos como secundario el objetivo para el que estamos trabajando que no es otro que conseguir satisfacer las expectativas del usuario a través de un producto de calidad.

La causa de la desviación de la atención o de las prioridades a veces será provocada por el cliente (no atender a los acuerdos por los que se rige el proyecto y romper por tanto la dinámica de trabajo: ver contratación ágil), por el proveedor (incumplimiento de compromisos, falta de productividad, incremento de las expectativas de beneficios, etc…) o por ambos.

Existen personas expertas en atribuirse méritos que les corresponden a otros (o que por lo menos no le pertenecen en exclusiva) y en no asumir culpas o errores (o compartirla con terceros) propios.

Estos ladrones de cuerpos aprovechan la gestión ineficiente de muchas organizaciones para medrar a sus anchas en las mismas y hay quienes llegan a sobrevivir el tiempo suficiente en ellas como para escalar tan alto que prácticamente les hace ser invulnerables y a la par hacer todavía más ineficientes a las mismas.

Los ladrones de cuerpos no tienden a llevarse bien entre sí, chocan, y eso genera tensiones que también afectan al funcionamiento de la organización. En ocasiones, como en “Los inmortales” se llega a tal punto que solo puede quedar uno, si bien, en otros casos, se opta por la creación de taifas que permite a cada uno, gestionar un área de trabajo o unos determinados tipos de clientes que hacen que los problemas solo aparezcan ante la aparición de conflictos de intereses.

Los ladrones de cuerpos han prosperado en épocas de bonanza económica en la cual los ingresos económicos eran tales que camuflaban la mediocridad y en donde factores como la motivación, la productividad y el cuidado de tu equipo y del cliente eran secundarios ante modelos de gestión orientados a la contabilidad. Total si salía mal un proyecto casi seguro que el cliente iba a poner más dinero, si se perdía un cliente seguro que tras él se encontraba otro, si salía un miembro del equipo entraría otro, tal vez no tan bueno, pero probablemente más barato.

Hoy día el contexto no es tan favorable a los ladrones de cuerpos, hoy en día la importancia de que los equipos funcionen es fundamental y para eso se requiere compromiso y confianza. Pese a esto, seguirán apareciendo y dependerá muy mucho de los gestores, que esta especie invasora entre en peligro de extinción.

Nos podemos encontrar con sistemas de información que funcionalmente cumplan los requisitos marcados por el área usuaria y que incluso tengan una deuda técnica aceptable pero que sin embargo no satisfaga a los usuarios.

¿Por qué? Pues por el hecho de que el sistema se ha centrado en la funcionalidad sin tener en cuenta lo costoso, complicado o improductivo que pueda ser para el usuario. El sistema se ha desarrollado de espaldas a la experiencia del usuario.

Y en este caso, el usuario lleva toda la razón. El sistema de información debe solucionar problemas, no crearlos, el sistema debe en conjunto mejorar la actividad que se informatiza no empeorarla.

Esto es muy frecuente encontrarlo en sistemas desarrollados siguiendo enfoques clásicos o en cascada en donde en la mayoría de los casos, el usuario no se enfrenta al producto hasta que se les entrega.

Los enfoques ágiles o iterativos e incrementales permiten obtener el feedback del usuario desde etapas muy tempranas, de manera que no solo es sistema puede adaptarse mejor al cambio o es capaz de tener los requisitos más prioritarios más trabajados, sino que además ofrece la posibilidad de que en cada iteración la productividad del trabajo que se realiza a través de la misma y la experiencia de usuario vaya mejorando.

Lo primero, como he repetido en diversas ocasiones, agilidad es actitud y eso es una capa o un filtro por encima de cualquier metodología, lo que permite que tengamos la posibilidad de aplicar principios ágiles o al menos seguir una mentalidad ágil en cualquier proyecto (tener la posibilidad no quiere decir que le demos la vuelta al proyecto como a un calcetín, las reglas del juego son las que son, pero aún así, incluso en los procesos más cerrados siempre habrá una rendija a través de la cual podamos aplicar un enfoque o actitud ágil).

Ahora bien, los principios ágiles se llevan bien con enfoques iterativos e incrementales, por eso su instrumentación en metodologías siguen este tipo de ciclo de vida. Sin embargo, la simple aplicación de la misma no quiere decir que el desarrollo sea ágil ya que lo único que hace es fragmentar el proyecto en diferentes entregas. Si el enfoque no es ágil, la aplicación del ciclo de vida iterativo incremental tampoco lo será.