La agilidad y el alcance III

¿Y que tiene que ver la agilidad en todo esto? En admitir una realidad que no es otra que la necesidad de adaptarse al cambio, a esas nuevas circunstancias que nos vamos encontrando en el proyecto y que nos obligan a tomar decisiones que se ajusten a las mismas.

Para ello las personas y el producto tienen que estar en primer plano.

Las personas tendrán que trabajar juntas, interactuando, comunicándose, para resolver las contigencias y problemas del día a día, siempre pensando en el producto y en tratar de conseguir el mayor valor para el mismo, tratando de mantener el clima más favorable para que el proyecto pueda ir hacia adelante.

Por parte del equipo de desarrollo se tienen que gestionar adecuadamente las expectativas, esto requiere transparencia, honestidad y saber comunicar de manera razonada las posibles desviaciones sobre los compromisos. Por parte del área usuaria, se requiere capacidad de comprensión de las circunstancias que la han provocado. Esa comprensión se irá haciendo más fuerte conforme vaya creciendo la confianza.

En el artículo anterior, hablaba de definir unas condiciones contractuales en las que se comparta el riesgo. Esto no solo es compatible con lo que estoy comentando, sino que es absolutamente necesario. Tiene que haber reglas del juego, conocidas, y sobre ellas ir tomando decisiones, siendo flexibles cuando sea necesario y justo.

La colaboración entre cliente y proveedor siempre debe estar por encima de la negociación contractual, tal y como indica el manifiesto ágil, ya que las condiciones de un proyecto varían de la noche a la mañana y el contrato es estático.

Al final, todo queda en mano de las personas, todo se reduce a eso y salvo que las condiciones iniciales del proyecto sean malas de partida (Death March Project) y/o haya grandes fluctuaciones sobre el enfoque del proyecto y sus objetivos, en ellas queda la mayor parte de la responsabilidad de que el proyecto pueda llegar a algún sitio.

La agilidad y el alcance II

¿Quién expone más con esta estrategia?, ¿el cliente?, ¿el proveedor? De entrada podría pensarse que el cliente porque no cierra un alcance definido, solo lo esboza y puede darse el caso de que se acabe con el presupuesto y no se consigan los objetivos generales que se han marcado.

Es posible que esto suceda, como también es posible que suceda con una visión opuesta, la de la llave en mano, en donde se pretende mantener fijo el alcance, ya que en el momento en que las cuentas no cuadran para el proveedor y supera el umbral de las pérdidas admisibles, querrá empezar a querer recortar ese alcance y/o solicitar más dinero, todo eso en un contexto de desgaste en el que además, la productividad y calidad de los trabajos se verá afectada, impactando a su vez en los costes. Esto que cuento no es ciencia ficción, quiénes hayáis trabajado en este tipo de contratos sabéis de lo que estoy hablando.

La clave está en definir unas condiciones contractuales en las que ambas partes compartan el riesgo, pero para llegar a eso es importante que en el cliente se entienda que con la incertidumbre que es inherente a todo proyecto de desarrollo de software, cualquier estimación inicial terminará siendo papel mojado conforme vayan avanzando los trabajos y que lo realmente importante es ir trabajando de la mano del proveedor (y el proveedor de la mano del cliente) para ir incrementando el valor del producto en cada iteración, de manera coherente a la inversión que se está realizando.

Desarrollo de software. Transparencia y libertad

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.

Desarrollo de software. Las expectativas importan

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).

Pull u orientación a la demanda

¿Qué se necesita?, ¿esto?, es lo que desarrollamos. Cualquier elemento de más es sobreproducción y corremos diferentes riesgos: que no podamos recuperar su inversión, que nos genere costes adicionales: en el caso de la producción de elementos físicos tenemos un ejemplo en los costes de almacenamiento y en el de los elementos lógicos lo tenemos en una mayor deuda técnica, complejidad funcional, etc… (además de haber desviado la atención de otras funcionalidades o tareas más prioritarias).

El concepto es sencillo, ¿lo es su implementación?. Vamos a centrarnos en el mundo de los proyectos de desarrollo de software:

- Requiere que el cliente o área usuaria estén implicados, de manera que se centren en priorizar de manera adecuada lo que necesitan, ajustándose a la capacidad de producción que tiene en cada momento el equipo de desarrollo.

- Requiere que el equipo de desarrollo respete el compromiso al que se ha llegado con el cliente, realizándose ajustes siempre por consenso entre las partes.

¿Cuáles son los riesgos?

- Que no exista una previsión sobre valles de producción, lo que puede dar lugar a que se desarrollen funcionalidades de más (algunas de ellas no prioritarias, otras no necesarias y otras que podrían cambiar por su dependencia con funcionalidades todavía no maduras), con tal de no tener a parte del equipo parado. Si se prevén, es posible hacer una gestión adecuada del equipo, de manera que se pueden dedicar a realizar actividades en otros proyectos (o incluso otras actividades en el mismo proyecto que seleccionadas sin la improvisación de tener que dar trabajo pueden ser beneficiosas: refactorización, mejoras de rendimiento, en la infraestructura de desarrollo, etc…).

- Que no exista una previsión sobre cimas de producción, lo que puede provocar que no se pueda atender a la demanda del cliente.

- Que el alcance de los trabajos sea de gran magnitud, ya que la probabilidad de que se hayan desarrollado funcionalidades que no se necesitan (o que incluso no deban aparecer en la versión del producto que se entrega) es mayor, además es muy posible que sea necesario perfeccionar muchas de ellas a través del feedback y la dependencia que puede existir entre ellas puede provocar el mantenimiento en cadena de varias de ellas.

Esto hace que una estrategia interesante sea reducir los tiempos entre versiones o lo que es lo mismo, las iteraciones no deben ser de gran duración. Esto permite, además, que los problemas que puedan producirse durante el desarrollo del sprint sean más sencillos (por regla general) de tratar.

- El cliente puede tener nuevas necesidades y la cadena de producción (sprint) está ocupada con otras tareas. Tendrá que esperar a que termine la iteración o aplicarse otras medidas en el caso de que no se pueda esperar. El hecho de no alterar los trabajos ya iniciados tiene su ventaja en el hecho de que el equipo está centrado en una serie de actividades, lo que le permite ser más productivo.

En el caso de que el desarrollo quede bloqueado, la aplicación de esta estrategia de trabajo, una vez que está interiorizada por el equipo y por la organización, hará que se centren los esfuerzos en desbaratar ese bloqueo, ya que de lo contrario no se podrá atender a nuevas demandas, ya que la capacidad de trabajo está comprometida en una serie de tareas que todavía no se han completado.

La satisfacción del cliente

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.

El descontento de las estimaciones

Cuando tenemos que pagar, casi siempre nos parecerá demasiado caro lo que nos ofrecen. Por otro lado, el proveedor tratará de no pillarse los dedos y realizará estimaciones con el objeto de minimizar riesgos.

La situación no es sencilla de resolver, de hecho, casi nunca nadie estará satisfecho, teniendo en cuenta de que el proveedor casi siempre termina equivocándose en sus estimaciones y de forma desfavorable para él (otra cuestión es analizar si el motivo del error ha sido el exceso de optimismo, la baja productividad o una información insuficiente y/o inexacta).

Un primer antídoto lo tenemos en el cumplimiento de las expectativas del cliente, ya que éste se quedará con el valor real que le proporciona el producto, por encima de lo que se ha gastado (siempre, como es lógico, dentro de unos márgenes razonables).

Otro antídoto lo tenemos en la confianza, sin confianza, da igual lo que te apliques estimando que la otra parte terminará pensando que te estás cubriendo las espaldas. La confianza en estos casos se obtiene a través de la transparencia y de la capacidad de asumir errores, porque para el proveedor todo se simplifica, todo es muy sencillo, si es el cliente el que siempre termina pagando sus fallos. Lo mismo pasa al revés, cuando el cliente trata de repercutir en el proveedor su indefinición, sus errores en las especificaciones, su falta de colaboración, etc…

Soy partidario del reparto de riesgos, por eso ni creo en la facturación por horas ejecutadas, ni tampoco en la llave en mano, ambos sistemas son injustos.

Soy partidario de definir objetivos globales, crear una visión inicial del producto que se quiere obtener y a partir de ahí, realizar estimaciones basadas en iteraciones de corta duración (se reduce el margen de error) en las que cliente y proveedor, repartan riesgos, y en las que (muy importante) sea el equipo de desarrollo el que estime (ese espacio debe respetarlo el cliente o en su extensión, el área usuaria o el responsable funcional).

Mal endémico. De espalda a los compromisos

Otro mal endémico del desarrollador es el poco respeto que se le da a los compromisos. Se les trata como si fueran papel mojado. Muchas palabras, pocos hechos.

El cumplimiento de compromisos crea confianza y en base a ella se desarrolla mucho mejor y más fácil y en consecuencia se suelen obtener mejores resultados.

Uno de los aportes más significativos de los enfoques ágiles lo tenemos en la importancia que le da a los compromisos porque siempre están presentes y precisamente se adaptan a la capacidad real de trabajo que puede asumir el equipo para tratar de llevarlos a cabo y tratar de ser predecibles a nivel de iteración.

Esa falta de compromiso no solo la vemos con respecto al área usuario o con respecto al cliente, también la puedes encontrar dentro de un mismo equipo de proyecto, cuando en lugar de tratar de atender a una serie de objetivos comunes existen personas que solo atienden a sus propios intereses y necesidades: si no tienes compromiso con quienes pasan horas a tu lado, ¿cómo lo vas a tener con el usuario o con el cliente?.

Si no se presta atención a los compromisos, la gestión de expectativas queda en un segundo plano o desaparece, cobrando una mayor relevancia la gestión defensiva, orientada precisamente a gestionar el desgaste en las relaciones con el cliente y también dentro de tu propia organización, porque en ambas partes te van a pedir explicaciones. Esto provoca que en lugar de invertir esfuerzo en producir se invierte en justificar por qué no se produce…, interesante paradoja.

Mal endémico. Las expectativas se gestionan muy mal

Mentir, ocultar información, transmitir información de manera incorrecta (incluso con la mejor de las intenciones), restarle importancia o tapar un problema porque se piensa que se puede resolver, no comunicar determinados detalles porque se piensa de manera equivocada que carecen de importancia, no informar a tiempo de desviaciones o problemas, aceptar compromisos que no vamos a poder cumplir, decir a todo que sí… y todo un sinfín de situaciones que terminan con un mismo resultado: una nefasta gestión de las expectativas que no hacen otra cosa que complicar situaciones de por sí difíciles o crear problemas reales desde situaciones que no deberían lugar a ellos.

Todo esto puede ser provocado por una o varias de las siguientes situaciones:

- El usuario o el cliente es el enemigo. Desgraciadamente es la cultura que muchos hemos heredado y que también la realidad ha ayudado a forjarse en mucho de nosotros, porque efectivamente hemos sufrido y mucho por usuarios que han querido tapar su negligencia desviándola hacia los desarrolladores. Sin embargo, malas experiencias aparte, no se puede concebir el éxito en un proyecto sin una colaboración efectiva y transparente entre desarrolladores y usuarios, que cree entre ellos un ambiente de confianza (es cierto que sin estos ingredientes también se puede dar un final digno a un proyecto pero es muchísimo menos probable que se consiga).

- Tu organización te exige malas prácticas. A veces los equipos de proyecto están sometidos a directrices por parte de su organización o por parte de responsables de la misma que atentan contra los principios de una relación de confianza con el usuario o el cliente con el objeto de obtener una mayor rentabilidad del proyecto u otros beneficios.

- El universo son mis tareas. El desarrollador se olvida con demasiada frecuencia que se está desarrollando para un tercero (esto es así porque incluso pasa dentro del propio equipo de proyecto, en el que a veces determinadas personas deciden hacer la guerra por su cuenta) y que es fundamental que exista una sincronización entre lo que el usuario está esperando con respecto a lo que estamos haciendo. Y lo que el usuario espera no es solo una serie de funcionalidades sino también un determinado nivel de calidad dentro de una serie de plazos que ellos tienen en la cabeza (y que lo mismo no dependen de ellos sino del mercado, de otros responsables o departamentos dentro de la organización, etc…).

- Exceso de confianza. Incluso siendo conscientes de lo importante que resulta gestionar las expectativas, se tiende a no comentar determinados tipos de problemas al usuario porque se piensa que se pueden resolver de manera sencilla y de esa forma no generar ruido innecesario. Es cierto que hay que huir de la microgestión incluso a la hora proporcionar información porque excesivos datos pueden crear desinformación sobre todo si no están bien estructurados y/o no se entienden pero es fundamental informar de aquellos problemas que pueden tener un impacto sensible en el proyecto aún cuando se especule que su resolución es simple porque, ¿cuántos problemas aparentemente simples se han convertido en auténticos agujeros negros?.

William Edwards Deming. Los clientes no son cosa de usar y tirar

Muchos se plantean la relación con un cliente como una relación esporádica, en la que se trata de obtener el mayor beneficio posible sea como sea, ¿que no termina satisfecho? no pasa nada, es solo un daño colateral, hay muchos más peces en el mar.

Esta ha sido la política que muchas organizaciones o gestores han tenido en época de bonanza y siguen siendo muchos los que la siguen aplicando, como si el número de peces fuera el mismo.

Para Deming: “El beneficio en un negocio proviene de clientes que repiten, de los clientes que presumen de su proyecto o servicio, y que traen a sus amigos con ellos”. Inteligente reflexión, ya que es mucho más productivo pensar en los dividendos de un trabajo bien hecho que convertir cada proyecto en una batalla, porque puede pasar, y pasará, que llegado un momento, nadie quiera combatir contigo.