Desarrollo de software. Expectativas y sorpresas

No hay mejor formar de gestionar las expectativas del área funcional o del cliente que evitando las sorpresas. Es como jugar a las cartas conociendo las del resto de jugadores y eso debería ser un proyecto de desarrollo de software, un conjunto de personas, equipos y organizaciones que trabajan con respecto a los demás de forma transparente (y esto es perfectamente compatible con los intereses particulares o de empresa que puedan existir).

En los proyectos en los que trabajo tengo como objetivo minimizar las sorpresas, gestionando de esta forma las expectativas del área usuaria desde el mismo momento en que puede haber un cambio en las mismas. Casi nunca gusta que acortes alcances pero te aseguro que es mucho mejor negociar en esas circunstancias que cuando, sin margen de reacción, no cumples los compromisos con el usuario.

La confianza es fundamental en el desarrollo de software y más en proyectos con la intensidad que requieren los enfoques iterativos incrementales, por ese motivo es absolutamente necesario gestionar las expectativas, modularlas a la realidad del proyecto.

Ocultar el estado real del proyecto o de un sprint no sirve para nada porque al final, más pronto o más tarde se termina descubriendo el pastel, tal vez todo salga a la luz después de haber terminado los trabajos, pero esa huida hacia adelante termina pasando factura si quieres volver a seguir trabajando con ese cliente.

Eso que se llama respeto

No lo da un cargo. No lo da una apariencia porque se construye día a día. Lo da una actitud.

El respeto se parece mucho a la confianza, si bien, es algo menos frágil. Para conseguir respeto necesitas tiempo, para perderlo mucho menos. También suelen ir de la mano ya que sueles respetar a quien confías y confiar en quien respetas.

El respeto tiene mucho que ver con la objetividad (también con la implicación), primero contigo mismo, ¿exiges a los demás lo que te exiges a ti?, ¿crees realmente que si las cosas no van bien no tiene nada que ver contigo?, ¿tratas con respeto a quiénes quieres que te respeten?, después con los demás, ¿creas situaciones de injusticia por dar un trato desigual a diferentes personas por la relación personal que mantienen contigo? (ten en cuenta que estamos hablando en el terreno profesional y no en el personal o familiar), ¿escuchas en la misma proporción que te escuchan?, ¿estás dispuesto a ir a las trincheras cuando hay problemas?…

El respeto no se compra, se gana, no se provoca, surge.

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.

Transparencia y confianza

Se puede tener técnicos fantásticos en el proyecto con una productividad tremenda y unos responsables funcionales muy competentes y conscientes del trabajo que tienen que realizar que si después no existe una armonía entre las partes la probabilidad de éxito será inversamente proporcional al tamaño del muro que se cree entre ellos.

No todo es técnica, no todo es competencia. Somos personas, lo emocional es muy importante y la confianza entre las partes es esencial.

Por ese motivo es fundamental gestionar de manera continua las expectativas, tener informada a las partes implicadas de la situación real del desarrollo y que exista una política de puertas abiertas, por ejemplo, que los responsables funcionales tengan acceso libre al burndown y al entorno de desarrollo para que puedan ver día a día, sin intermediarios, cómo va el desarrollo y qué desviaciones se pueden ir produciendo (estos son solo algunas prácticas, evidentemente la confianza, la transparencia y las puertas abiertas van más allá de eso).

Construir y mantener la confianza no es responsabilidad exclusiva del proveedor, sino que es una responsabilidad compartida por ambas partes. Ese equilibrio resulta muy complicado de conseguir por eso, personalmente considero muy valiosas las personas que tienen claro que es necesario para que todas las partes alcancen sus objetivos y que tienen la capacidad de conseguir la estabilidad necesaria incluso en situaciones donde resulta muy complicado conseguirla.

Confianza, error, aprendizaje

Si quieres acabar con la productividad de un desarrollador o de un equipo de trabajo solo tienes que socavar su confianza y/o crear un contexto en el que se tema cometer cualquier error.

¿Se trabaja mejor con presión? A corto plazo puede valer (otra cosa es analizar el coste que tendrá después ese esfuerzo de más que se tiene que echar), más allá es un lastre porque no olvidemos que somos personas y cuando estamos sometidos mucho tiempo a una nivel de exigencia muy alto terminamos por obtener peores resultados.

También se tiende a arriesgar menos y a ir por caminos más seguros independientemente de que sea algo que convenga o no realmente al proyecto, tal vez de esa forma nadie pueda reprocharnos un error ya que al fin y al cabo hemos tirado de manual pero también de esa forma estamos limitando nuestra capacidad de aprendizaje.

Eso de ser correcto aunque no se obtengan resultados es una de las características del cumplidor y se debe huir de la creación de un contexto que haga que proliferen ese tipo de figuras. Personalmente prefiero un desarrollador se equivoque y aprenda del error que un desarrollador que no se manche las manos ya que en el primer caso existe posibilidad de evolución y en el segundo solo tendremos a alguien que quedará bien en las fotos.

No se trata de premiar el error sino de entenderlo y de dar confianza a la persona que lo ha cometido. Es cierto que la confianza no puede ser infinita y si nos equivocamos mucho más que acertamos es posible que independientemente de todo lo que estemos aprendiendo nos pidan responsabilidades y eso debemos aceptarlo como algo normal, como parte de nuestro negocio y lo que puede ser un fracaso profesional hoy mañana puede haber sido el detonante de un éxito mayor.

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.

Miyamoto Musashi. Confianza

La confianza nos hace superar los obstáculos más complicados o nos hace crearlos de la nada. La confianza no se toma en pastillas ni debe depender de lo que los demás nos digan. Somos nosotros los que le damos contenido, nadie más.

Pero sabes como yo que el entorno influye, tu pasado y tus vivencias. Por eso, piensa muy bien cómo vas a tratar a los demás porque muy probablemente afectes de forma positiva o negativa a su confianza.

Si trabajas con personas, si gestionas su trabajo o bien colaboras con ellas, no deberías minar su confianza, por su bien y por el del proyecto. No se trata de estar dando palmaditas en la espalda, sino de ser justo, valorar lo que está bien y analizar lo que está mal, sin estridencias en un sentido o en otro, modulándolas de manera adecuada. No es fácil.

Hay una cita de Miyamoto Musashi que habla por sí sola: «Todos los hombres son iguales excepto por la creencia que tengan en sí mismos, independientemente de lo que puedan pensar los demás».

Desarrollo de software. Cuando tu palabra vale algo

Recuerdo cuando un responsable funcional nos comentaba que no estaba conforme con la solución que habíamos aplicado a una historia de usuario. Y tenía razón, pensábamos que la tecnología permitía hacer lo que él quería pero cuando llegó el momento de hacerlo nos dimos cuenta que no y que buscar otra solución no daba tiempo dentro del marco del sprint.

El responsable funcional insistía en que había que buscar una solución y esto estaba generando una presión importante en el equipo que era conveniente tratar, con el objeto de que no se perdiera el enfoque en el resto de tareas que había que terminar. Hablé con él y llegamos al acuerdo de que se le iba a proporcionar una alternativa en la siguiente iteración, quedó conforme porque me comprometí a ello.

Y el mérito no es mío, el mérito es de todas las personas que trabajan conmigo y que han conseguido ganarse su confianza, sin ellos mis palabras estarían vacías. Con un ambiente así, se trabaja de otra manera.

Esto es consigue gestionando adecuadamente las expectativas, cumpliendo compromisos y siendo transparente. Puede parecer fácil, pero generalmente poca gente cumple sus compromisos y, todavía menos, es transparente.

Cuando se cumple compromisos es más factible que se te perdonen errores que te impiden precisamente cumplir con todas las tareas comprometidas en un sprint. Si eso se repitiera en el tiempo, por mucho interés y esfuerzo que se ponga, la confianza empezaría a disminuir.

William Edwards Deming. La ventaja de las relaciones a largo plazo

Si se ha conseguido consolidar una relación a largo plazo entre un cliente y un proveedor es que se ha conseguido forjar una confianza como consecuencia de un trabajo bien hecho y que ha sido productivo para ambas partes.

No quiere decir que todo haya sido fácil, seguro que han existido sus crisis, unas veces propiciadas por acciones de uno y otras por las del otro y que se habrán solucionado por el esfuerzo de ambas partes.

Hoy día no se mira tan a largo plazo, no se observan los beneficios que puede aportar una relación de confianza entre un cliente y un proveedor. Se mira más el beneficio a corto plazo, cuanto más explosivo mejor.

En el mundo del desarrollo de software ha sido y es así, muchas organizaciones o gestores en el momento en que un proyecto no va bien económicamente se olvidan pronto de tratar de mantener una relación duradera, ya que el fuego llega a los zapatos y tratan de salvar la situación como sea. En estas situaciones y en muchos casos, aunque se ha crea que se ha ganado, se ha perdido.

También es cierto que muchas relaciones se rompen porque el cliente tensa la cuerda en demasiadas ocasiones y no es posible mantener una relación comercial si una de las partes no obtiene beneficios de manera sistemática.

Deming considera que: «El resultado de una relación a largo plazo es mejor y de mejor calidad y los gastos cada vez más bajos».

La calidad se incrementa y los costos se reducen como consecuencia del conocimiento mutuo y de la confianza, ya que se acierta más, se reducen trámites y controles y se eliminan barreras. Cuando uno quiere mantener una relación se esfuerza más en conseguir las cosas.

Nicolás Maquiavelo. La importancia de la buena voluntad

Decía Nicolás Maquiavelo que: «no puede haber grandes dificultades cuando abunda la buena voluntad».

En el desarrollo de software es esencial la buena voluntad de las partes para tratar de conseguir buenos resultados, es cierto que después, podrán ser mejores o peores, pero en ese contexto el trabajo es mucho más fácil porque independientemente de los objetivos individuales de cada persona o de cada equipo, habrá un objetivo general que todos querrán alcanzar.

Con buena voluntad aumenta la empatía, se empieza a cimentar la confianza, se eliminan trabas a la comunicación y mejora la interacción entre las personas, algo fundamental para llevar adelante un proyecto de desarrollo de software en el que lo más importante para conseguir los objetivos son las personas.

En el momento en que las personas dejan de colaborar, empiezan a poner resistencias, a crear muros, a no cumplir con sus compromisos, la dificultad crece exponencialmente. Esto hace daño dentro de un equipo pero se convierte en insufrible cuando los equipos se enfrentan (por ejemplo desarrolladores y área usuaria) porque todo se ralentiza, se convierte en más burocrático, se multiplican las explicaciones, se incrementa o aparece el síndrome de la última versión, cada parte radicaliza sus posturas, los desarrolladores querrán salir cuanto antes del proyecto y el área usuaria si entiende que no se han alcanzado los objetivos no querrán que salgan nunca (un error, desde mi punto de vista por ambas partes, que deberían tratar de dar una salida lo más digna posible al proyecto).

La buena voluntad puede ser un estado inicial pero no es un estado permanente, todos son responsables de mantenerla independientemente de que haya (que los habrá) momentos de crisis.