Desarrollo de software. La colaboración

Prever contractualmente todo lo que puede pasar en un proyecto de desarrollo de software es muy complejo, acentuándose en proyectos de envergadura y/o de larga duración.

Precisamente ese es uno de los problemas que provoca desgaste en las relaciones cliente/proveedor salvo que las dos partes entiendan que por encima de todo está la colaboración entre las partes.

Sin esa colaboración el proyecto irá mal para ambos, ya que pequeñas victorias relacionadas con aspectos económicos después se terminan difuminando porque si los resultados finales no son los esperados, todos van a perder. Es cierto que es difícil que todos pierdan por igual, pero creo que el objetivo de un proyecto o de una colaboración entre entidades y equipos de trabajo no debe ser tratar de perder menos que el otro.

El objetivo debe ser ganar y ese objetivo se consigue si se establece un objetivo común entre todos los participantes en el proyecto. Es cierto que después habrá otra multitud de intereses tanto a nivel de organizaciones como de las personas que participan, pero si se consigue establecer la cultura de que si el proyecto sale bien lo más probable es que la mayoría de esos otros objetivos también se conseguirán de manera transitiva, las posibilidades de colaboración entre todos se incrementarán.

Y no solo se trata de ganar, se trata también de trabajar en un ambiente más adecuado, con menos desgaste, esto redundará en la calidad del trabajo de las personas y en consecuencia, del proyecto.

Desarrollo de software. Dibújalo, cuéntamelo

El prototipado, el cartón piedra, el mockup en definitiva, es una herramienta muy poderosa. En el desarrollo de software existe desde tiempos inmemoriales y, desde mi punto de vista, no se le da la importancia que se merece.

Parece que resulta más interesante trasladar requisitos, especificaciones o historias de usuario al lenguaje natural que tener testimonios gráficos de lo que se desea obtener.

Y no solo se trata de tener los requisitos acompañados por un prototipo, lo realmente interesante es que el desarrollador lo explique al responsable funcional, product owner o usuarios implicados, de esta forma se puede comprobar, en primera instancia, que el desarrollador ha entendido el comportamiento y en segunda instancia permite ofrecer una perspectiva menos abstracta de la solución a las personas que deben definirla, algo que agradecerán y agradareceremos porque se conseguirá obtener una descripción más real de lo que se pretende obtener, gracias a esa colaboración que se consigue a través de un instrumento intermedio que las diferentes partes entienden.

No se trata de acertar a la primera, algo que sabemos que es complicado, con y sin estas técnicas, sino de tratar que el desarrollo tenga la mayor intención posible, es decir, que nos ahorremos iteraciones que podían haber sido evitadas.

¿Separar usuarios y programadores?

Teniendo en cuenta que el desarrollo de software tiene una naturaleza colaborativa (participan personas y se necesita de todas ellas para sacar el trabajo adelante) se entiende que cuanto menor sea la separación (y no hablo de distancia física) entre las diferentes personas que participan en el proyecto, mayor probabilidad de éxito tendremos.

Por eso soy de la opinión de que los desarrolladores deben tratar con los usuarios en todas las etapas o ciclos de desarrollo de un producto. El feedback no solo se trata de palabras sino también de sensaciones y esto último te lo pierdes si no tratas con las personas que van a usar la aplicación. Por mucho que te lo cuenten no es lo mismo.

Es posible que existan proyectos donde la relación entre las partes sea tan mala que tal vez lo mejor sea utilizar intermediarios, en cualquier caso debería tratarse de una situación transitoria porque normalmente la mejor decisión que se puede tomar en estos casos, si no se consigue reconducir, es llegar a un acuerdo para dar por terminada la relación contractual.

Crear barreras e interfaces artificiales entre personas solo originan distancia y ese incremento de la misma afecta inversamente al conocimiento. Deja que el desarrollador tenga su propia perspectiva, deja que los usuarios interaccionen con los desarrolladores, dejan que compartan opiniones, deja que aprendan juntos.

Recordemos que se trata de ir eliminando esa distancia entre lo que los desarrolladores creen que hay que hacer y lo que los usuarios creen que quieren. Las diferentes versiones del producto irán aproximando esas visiones a la del producto que se espera y, como es lógico, es más efectivo si todas las partes contrastan sus perspectivas.

Colaboración

Una cita de Jerome Bruner dice lo siguiente (traducción libre): «La profundidad se aprecia mejor al mirar desde dos puntos a la vez».

Añádele más puntos y se verá todavía mejor.

En algo tan complejo como es el desarrollo de software en el que existen infinidad de variables que afectan al trabajo del día a día, contar con diferentes puntos de vista ayuda a tomar mejores decisiones.

Incluso opiniones que puedan estar equivocadas te pueden dar la oportunidad de revisar y mejorar tu propia percepción.

Déjate asesorar, confía en la visión de otras personas ya que no se trata de ser el que metió el gol de la victoria sino de conseguir la victoria.

En el momento en que entiendas eso verás como consigues mejores resultados.

Lo plano no funciona

Es compatible tener una equipo de proyecto que comparta una misma visión con el hecho de que las diferentes personas que lo conforman puedan tener distintos puntos de vista sobre cómo se debe afrontar la realización de determinadas tareas o sobre el enfoque que hay que aplicar al proyecto.

Si todo el mundo de tu equipo piensa igual o si teniendo opiniones divergentes no la expresan, tienes un equipo plano y lo plano no funciona. Precisamente lo que enriquece una toma de decisiones son las diferentes percepciones que aportan cada una de las personas persona y en un entorno colaborativo como es el desarrollo de software eso resulta esencial.

Es mucho más complicado tener un equipo plano que no tenerlo. Si es plano, analiza las causas, ya que tal vez no se ha creado el contexto adecuado para que las personas que lo componen puedan expresarse o de tantas veces que se ha hecho caso omiso a sus opiniones han optado, por falta de motivación para hacerlo, por quedarse callados.

De espaldas al cliente y de espaldas al proveedor

El desarrollo de software tiene una naturaleza evolutiva: ir de lo más simple a lo más complejo (tratando de que la solución compleja sea lo más simple posible), adaptándose al cambio ante un entorno lleno de incertidumbre, plasmando en realidad ideas abstractas que deben ir perfilándose.

Conseguir buenos resultados es más probable si se trabaja en un contexto de colaboración, cercanía (que no tiene nada que ver con la distancia) y confianza entre todas las partes involucradas en el proyecto.

Cuando el proveedor solo ve desde el minuto uno la necesidad de convertir el proyecto en beneficios, no por la vía de conseguir un buen producto, sino por la vía de la disminución de la calidad de los resultados, de los alcances, por la realización de sobreestimaciones, etc… no está creando un contexto favorable para la colaboración entre los implicados.

Estas prácticas equivocadas puede que tarden en detectarse en algunos proyectos pero lo normal es que terminen saliendo a la luz y cuando lo hacen se crean situaciones de desgaste que dan lugar a una pérdida de confianza y con ella a un distanciamiento entre las partes y a la creación de muros de defensa. En esos momentos la probabilidad de que el valor del resultado final del proyecto sea acorde con la inversión realizada es prácticamente nulo.

Pero también el cliente puede crear situaciones tan perjudiciales como la anterior. Basta con que empiece a no ser justo, a no asumir responsabilidades, a no poner en el proyecto el interés que éste demanda .

El cliente se siente más fuerte, por regla general, (si bien también existen situaciones de cautividad con respecto al proveedor en donde se produce exactamente todo lo contrario y con una intensidad, en ocasiones, incluso superior), si las personas que el cliente dedican al proyecto en lugar de asumir sus responsabilidades: decisiones equivocadas, demasiadas iteraciones para alcanzar una solución, soluciones demasiado complejas sin haber pasado por etapas intermedias, etc…, deciden que sea el proveedor el que cargue con ellas, volveremos a la situación en la que la confianza entre las partes se resquebraja y se crean muros de defensa.

Desarrollo de software. Equipo de proyecto, comunidad

La siguiente cita de Parker Palmer me hizo reflexionar sobre la esencia de lo que es un equipo de proyecto: «Cuando no dependemos el uno del otro, la comunidad no puede existir».

El desarrollo de software debe ser colaborativo porque el conocimiento está repartido por todo el equipo y porque la visión del conjunto mejora la suma de las visiones individuales.

No todo el mundo se adapta a trabajar de esta forma porque muchos desarrolladores tienen una visión orientada al cumplimiento: «estas son mis tareas, las termino, cumplo y a otra cosa», el desarrollador puede ser excepcional y lo mismo encaja en tareas donde trabaje solo pero si no es así deberías plantearte si efectivamente quieres a personas así en proyectos en donde sea necesario su cooperación y colaboración con otros. Es cuestión de crear equipo, sí, pero también de crear una cultura.

Precisamente la principal culpable de que prolifere la figura del cumplidor es la propia organización cuando no entiende de la importancia del trabajo en equipo, de manera que en su funcionamiento general y más específicamente en los diferentes proyectos lo que hace es reunir/juntar a una serie de personas en lugar de hacer que las mismas funcionen bajo un esquema de colaboración y cooperación.

Scrum, ¿proceso o framework?

¿Qué es Scrum?, ¿un proceso o un marco de trabajo?, una cosa es lo que piense y otra lo que se hace realmente.

La agilidad es colaboración entre personas y capacidad de adaptación al contexto y al cambio, esto implica que en esencia y de partida no te debes «casar» con ninguna estrategia, metodología o práctica de desarrollo ya que debes seleccionar aquella que mejor se adapte a las condiciones y contexto del proyecto y cambiarla parcial o totalmente si hiciera falta por la propia evolución del proyecto (por la propia necesidad de adaptación al cambio).

Querer aplicar Scrum sí o sí no es ágil en esencia. Aplicarlo en contextos donde sí sea una estrategia favorable pero limitarte por la ortodoxia de las prácticas tampoco es ser ágil. Lo que es ágil es tener la mente abierta a elegir las prácticas que más pueden convenir al proyecto, adaptar aquellas otras que lo requieran y descartar las que no procedan.

La ortodoxia por encima de todo convertirá a Scrum en un proceso y precisamente no es eso lo que queremos. Por eso siempre insisto a las personas que se están iniciando en el agilismo en que no se limiten exclusivamente a leer o asistir a conferencias y cursos (que por otra parte serán interesantísimos y serán atajos para comprender conceptos y comportamientos que llevan tiempo y experiencia aprender y sobre todo asimilar) sino que experimenten desde las bases del Manifiesto Ágil.

Agilidad, diálogo, consensos y decisiones

Algunos de los fundamentos de la agilidad son la comunicación, la colaboración y la confianza.

Esto requiere un esfuerzo por parte de todos, esfuerzo que es menor conforme las diferentes personas y equipos que participan en el proyecto tienen más experiencia aplicando este enfoque, aunque pueden existir factores externos que modulen negativamente estas circunstancias.

Los proyectos están llenos de ruido y si no se gestionan adecuadamente o, simplemente, no te dejan gestionarlo, se puede pasar que un contexto adecuado de interrelaciones que funciona bien a otro en que las relaciones no son tan fluidas y se va perdiendo paulatinamente la confianza.

Pero no solo el ruido puede afectar. Como decía antes se requiere un esfuerzo por parte de todos porque no hay quien no tenga días malos, no hay quien no se equivoque y también un esfuerzo para entender el proyecto como algo más general que tus propios intereses. Esto último requiere experiencia, madurez y conocimiento ya que es necesario darse cuenta que para que las cosas salgan bien hay que encontrar el equilibrio entre lo que se quiere y lo que se puede.

También requiere una cierta actitud porque como decía Descartes: «No hay nada más equitativamente repartido en el mundo que la razón; todos creen tener suficiente». Si piensas que eres infalible y que tu opinión vale más que la del resto, se romperá ese equilibrio que tratamos de conseguir. A veces tendrás que tomar decisiones y tendrás la última palabra, pero eso no quita que no debas tener en consideración otros puntos de vista y alternativas que puedan ayudar a que los trabajos salgan adelante.

DevOps VII

Esas medidas más concretas, que mencionaba en el artículo de ayer, irán orientadas principalmente:

– A reducir la incertidumbre: Definición de políticas por parte del Departamento de Sistemas, consensuadas con el Departamento de Desarrollo que pueden ir orientadas a definir un «catálogo de sistemas base», es decir: estos son los servidores de aplicaciones con tal versiones, estos los de bases de datos, este el gestor documental, etc…, una serie de condiciones con respecto a la entrega de las versiones (instalación en entornos previos lo más parecidos posibles al de producción y verificación de su correcto funcionamiento), etc…, y la participación de personal de Sistemas en el proyecto, con más intensidad en la fase en la que se defina el entorno tecnológico, etc…

– A mejorar la coordinación: Que ambos departamentos tengan información actualizada sobre las operaciones, eventos y entregas que puedan afectar al otro, consensuar soluciones o prioridades en el caso de que se prevean períodos de importante carga de trabajo, establecer estrategias para gestionar el WIP (Work in Progress) como puede ser la aplicación de Kanban que pueden resultar de utilidad para detectar cuellos de botella o para realizar ajustes en los equipos de trabajo, etc…

– A reducir las actividades mecánicas en el proceso de entrega e instalación de manera que tanto desarrollo como sistemas puedan dedicarse a las actividades realmente importantes: ¿para qué realizar instalaciones o ejecutar scripts a mano si se puede automatizar?. Esto al principio choca, porque para muchos supone un cambio de paradigma, sin embargo, si se establecen una serie de medidas para reducir la incertidumbre y se demuestra que el modelo funciona y es el adecuado para un conjunto de sistemas (aunque se empiecen con determinados sistemas piloto), terminará por asentarse porque es productivo, disminuye errores humanos y lo que decía antes, se puede invertir más tiempo en otro tipo de actividades donde se requiere un mayor esfuerzo intelectual.

Todo ello sin olvidar que los más importante, al final, son las personas.