archivo

Archivo de la etiqueta: confianza

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.

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.

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.

En un proyecto de desarrollo de software se manejan multitud de variables y una gran cantidad de tareas que son realizadas por personas de los diferentes equipos de trabajo que intervienen en el proyecto, algunos de ellos de departamentos distintos o incluso de organizaciones distintas (cuando se trabaja con un cliente externo, en una unión temporal de empresas o con alguna subcontratación).

Para que todo vaya bien no solo es necesaria la colaboración sino también la sincronización con que se realizan las tareas porque, de no ser así, las desviaciones provocadas por un equipo impactarán directamente en otros, teniendo en cuenta que el que pierde siempre con todo esto es el proyecto y a la larga, si el proyecto sale mal, todos salen perdiendo.

Este espíritu de colaboración, esa intención de conseguir que toda la “maquinaria” funcione de manera adecuada solo es posible si se ha conseguido forjar una relación de confianza (después influirán otros factores, como la capacitación del personal, del impacto de los errores, etc…).

Al principio cuesta un poco (sobre todo en aquellos casos donde los equipos no se conocen) pero sirve como contramedida el hecho de que se parte de cero y todavía no han existido fricciones (otra cosa es que se parta con equipos que se conocen del pasado, que no terminaron de funcionar y que erosionaron su confianza, en estos casos habría que plantearse si la situación es reconducible o no).

Sin embargo, conforme se avanza en el proyecto y algo no va como a los responsables de algunos de los equipos quiere (o a sus jefes) o bien, se decide cambiar de prioridades, la confianza empieza a resquebrajarse, a una velocidad vertiginosa en comparación con lo que costó construirla y mantenerla.

Ya lo decía Séneca: “Una era construye ciudades. Una hora las destruye”.

Partamos de la base que en un juego con tantos intereses es muy complicado, por no decir imposible, mantener un equilibrio. El objetivo no es que siempre sea todo un camino de rosas, sino que cuando haya problemas, que los habrá, se atajen pronto, antes de que la pérdida de confianza sea prácticamente irreversible.

En un proyecto de desarrollo de software la transparencia es sinónimo de liberación. Es cierto que se siente presión porque los responsables funcionales conocen la realidad del proyecto y no aquella que se le quiera, en un momento dado, vender, pero una vez que se asimila esta forma de trabajar, poder mirar a los ojos a los usuarios y que ellos confíen en tu trabajo crea un clima en el que, si bien no se asegura el éxito, sí que resulta mucho más efectivo.

No es cuestión de metodología, esto no va de eso, es cuestión de una actitud con respecto al proyecto y a los usuarios. Es cierto que ciertos enfoques como el ágil favorecen y a la vez necesitan este tipo de contextos pero en cualquier circunstancia es perfectamente aplicable.

Hacer visible los trabajos, hacer visibles los problemas, reconocer errores, de eso va esto, manteniendo una comunicación fluida con los usuarios y permitiendo que ellos mismos, sin necesidad de tu intervención, puedan obtener parte de esa información cuando ellos quieran. No se trata de microgestión, sino de abrir ventanas y que cuando quieran se asomen, la frecuencia con que lo hagan es cosa suya, si bien, no está de más, si notamos que no lo hacen las veces que debieran, recordarles que tienen esa posibilidad.

Un proyecto requiere la colaboración continua entre equipos y personas, sin confianza todo es más difícil, por lo que es necesario poner todos los medios que sean posibles para crearla y mantenerla (que es lo más complicado), la transparencia es una buena base para ello.

Gestionar las expectativas es fundamental en nuestra profesión y es algo que no solemos hacer bien y que es causa de pérdidas de confianza, desgaste y de minusvaloración del trabajo realizado (nosotros mismos lo hacemos pequeño cuando intentamos “vender” algo más grande de lo que realmente es).

¿Por qué fallamos en esto? Los motivos pueden ser muy diferentes: no terminamos de ver (o no queremos ver) el problema y por lo tanto no lo transmitimos o lo hacemos demasiado tarde, tenemos miedo de la reacción de la otra parte o simplemente no le damos importancia a las expectativas que pueda tener el usuario (algo muy peligroso porque un proyecto surge de unas necesidades y de la expectativa de darles una solución).

No es sencillo transmitir al área usuaria que no se va a poder cumplir lo que se tenía pensado inicialmente y lo que hasta este momento parecía que se iba a poder conseguir, ¿por qué no es sencillo? pues porque se pedirán explicaciones (y es natural que así sea porque le estamos cambiando la imagen mental que tenían del proyecto) y las mismas no siempre se van a entender, seas sincero o no (mejor sincero).

¿Qué hacer? Lo importante es explicar qué ha llevado a esta modificación en las expectativas y qué ventajas supone hacer un ajuste a las mismas, ¿ventajas? perseguir quimeras en el proyecto no solo supone engañarnos a nosotros mismos sino que además supone inflingirnos un castigo en forma de esfuerzo desbocado que se traducirá probablemente en unos resultados deficientes.

Esto no es un alegato al incumplimiento de las planificaciones sino de intentar exponer mi punto de vista sobre una realidad: es muy complicado acertar en los plazos y presupuestos del proyecto para el alcance que se defina, es posible que ese alcance cambie o que funcionalidades que se esperan más simples sean más complejas y, además, a lo largo del proyecto pueden ocurrir infinidad de circunstancias que impidan un desarrollo lineal del mismo.

Teniendo en cuenta esa realidad gestionar las expectativas de manera adecuada resulta fundamental para alcanzar los objetivos marcados en el proyecto. ¿Cómo cumplir objetivos si se ajustan las expectativas? Generalmente las expectativas incluyen funcionalidades no imprescindibles o con mayor complejidad de la necesaria, ahí es donde podemos trabajar para seguir manteniendo el pulso al cumplimiento de objetivos.

A veces el ajuste no será suficiente y se requiere un mayor aporte presupuestario y/o un mayor plazo para la ejecución del proyecto. ¿Qué pasa cuándo no se puede o cuándo no se llega a un acuerdo? Problemas para todos (cliente y proveedor), mi recomendación es que lo mejor es intentar llegar a un acuerdo satisfactorio y eso pasará también porque las partes asuman su responsabilidad en que se haya llegado a esa situación (que no necesariamente tiene que deberse a un mal desempeño en el proyecto sino que puede darse el caso de que el problema partiera con la estimación inicial de presupuesto (principalmente) y plazos).

No es fácil vender, no es fácil crear una relación de confianza entre con un cliente que sea capaz de aguantar el paso del tiempo.

Pasan muchas cosas, suele haber desgaste, es cierto que el proveedor se equivoca muchas veces, como también se equivoca muchas veces el cliente.

Pese a todo, lo que no cabe duda es que una relación consolidada y duradera entre un cliente y un proveedor es beneficiosa para ambas partes, en primer lugar porque si se ha llegado a ese punto es porque ambas partes se han entendido y si ha sido así es porque en el cómputo general (habrá momentos mejores y peores) todos han ganado y en segundo lugar porque la confianza simplifica mucho la gestión y permite tomar decisiones que proporcionan una ventaja competitiva que por su riesgo en otros casos no se tomarían.

Por ejemplo, si deseas reducir tu almacén pero te cuesta mucho dinero parar la producción por falta de materia prima, tienes puedes confiar en que un proveedor que te suministre lo que necesitas cuando lo necesitas. Si no confías en que ninguno te pueda prestar ese servicio, tendrás que hacer las cosas con mayor anticipación y asumir el coste que conlleva almacenar toda esa materia prima.

Confianza es la palabra clave y eso se consigue minimizando los fallos y produciendo un beneficio al cliente. Es cierto, tal y como decía la principio, que es difícil vender, que es difícil consolidar, pero también lo es que la clave es conseguir satisfacción del cliente.

¿Qué a veces el cliente se porta mal? Sí, pero también es cierto que muchas veces no importa si el cliente es bueno o malo, solo se mira el beneficio, el corto plazo, ¿qué no queda satisfecho con el trabajo? No importa, hay muchos peces.

El problema es que ya no hay tantos peces.