archivo

Archivo de la etiqueta: expectativas

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.

En mis artículos utilizo mucho los términos sistemas de información, producto, etc… en referencia al software que estamos desarrollando en un proyecto.

Hay quienes piensan que la terminología más adecuada debería ser solución porque es precisamente eso lo que estamos intentando hacer: resolver una problemática de un cliente (interno o externo).

Es muy importante tener en cuenta ese aspecto: el cliente realiza una inversión para tratar de mejorar la calidad y cantidad de los resultados de alguna de sus áreas de negocio, para tener una visión global de la información y extraer conocimiento de ella, etc…

A alto nivel su expectativa es mejorar y nuestro objetivo debe ser dar una solución a esa expectativa.

Esta sencilla ecuación se rompe en el momento en el que el proveedor centra su objetivo en el beneficio y no en las expectativas del cliente, pasando a ser el proyecto su solución y no de quién la está pagando. Esto es muy común y hace mucho daño al negocio y a nuestra profesión porque la calidad final del resultado se resiente y la imagen de todos (porque se nos mete a todos en el mismo saco) queda muy deteriorada.

No me invento nada, en esta época de crisis, muchas organizaciones en lugar de invertir en TIC para tratar de conseguir ventajas competitivas, huyen porque no creen en un retorno de la inversión.

Las empresas trabajan para ganar dinero, hasta ahí de acuerdo, pero esa aspiración legítima no debe justificar que el cliente sea el sacrificado.

En muchas ocasiones el cliente, ya sea, por falta de implicación, por no haber elegido el momento más adecuado para realizar el proyecto, por la aparición de otras prioridades que deben atender, etc…, es culpable de que los resultados no sean los esperados, pero en otros muchos casos sí que cumple, sí que trata de poner los medios para que el proyecto vaya adelante y sin embargo no es tratado justamente por el proveedor.

Hace un par de días publiqué un artículo en el que indicaba que las especificaciones contractuales, por regla general (y con las matizaciones que hice), suponen un freno o una resistencia al objetivo de tratar de conseguir el mayor valor posible con la inversión realizada.

En este artículo voy a tratar de exponer que una situación diferente (que no necesariamente contraria), que no otra es la pérdida de una visión global de lo que se pretende conseguir, también supone un riesgo importante.

¿Por qué? La clave se centra igualmente en el valor. El valor de cada historia de usuario desarrollada junto a las expectativas de lo que se pretende conseguir en el proyecto, siempre y cuando estas se adapten a la propia evolución de los trabajos y de la propia organización, es lo que permite conseguir el equilibrio.

Esa pérdida de visión de sus propias expectativas por parte de un product owner, cuando se empeña, por ejemplo, en refinar sobremanera funcionalidades que, siendo importantes, ya funcionan de manera adecuada, provoca que se sobrevaloren historias de usuario que puestas en contexto tienen un valor muy
inferior porque existen otras necesidades en el sistema que pueden que no tengan todavía un funcionamiento aceptable o ni siquiera se han abordado.

Pero la búsqueda de la perfección no es el único problema, también lo tenemos cuando el product owner se centra en aspectos relacionados con lo que le puede gustar o dominar más, dejando de lado, otros más ásperos, complejos o que requieran un consenso que no resulta siempre facil de conseguir pero que también resultan necesarios para tener un sistema de mayor valor.

La visión del proyecto y expectativas no son fijas pero existen o deben existir para poder dar el valor adecuado a cada historia de usuario en la que se trabaja y para ir orientando la línea de desarrollo del producto hacia lo que se pretende conseguir, de lo contrario es posible que no se centren los esfuerzos y la inversión en lo realmente importante.

En ocasiones se tienen expectativas demasiado altas de lo que una aplicación puede conseguir.

Se cree que, invirtiendo el dinero suficiente (que generalmente será menos del que realmente se necesita) se conseguirá tener una aplicación que, de un plumazo, te resuelva todos los problemas: que consiga integrar toda la información y que además, ésta sea de calidad, que resuelva los problemas organizativos y que permita incrementar la productividad en términos exponenciales.

El error se encuentra en varios puntos:

– El software lo hace inteligente las personas y para ello se tiene que acertar en las especificaciones de lo que se tiene que hacer. Todos sabemos que eso es complicado y que se requiere, generalmente, un enfoque iterativo incremental para conseguir, a través del feedback, ir acercándonos progresivamente a una solución deseable.

El recorrido puede ser más o menos largo y en medio pueden existir problemas, tales como un desgaste en las relaciones entre desarrolladores y responsables funcionales, que el presupuesto se agote, que el responsable funcional cambie y con él el enfoque que se le estaba dando al sistema, que cambien las prioridades de la organización, etc…

– La calidad de los datos es el resultado del trabajo que hacen las personas con la aplicación. Puedes desarrollar validadores, implementar mil restricciones, que al final siempre quedará todo en manos de los usuarios. Por tanto, se trata de un problema de carácter organizativo que el software puede ayudar a controlar/gestionar pero no se podrá ir mucho más lejos de ahí.

Hacer el software muy restrictivo, en ocasiones, no se ajusta a la realidad de funcionamiento de la organización, que requiere, precisamente, una mayor flexibilidad, a la vez que hace más complejo el software. Cuántas veces nos hemos encontrado, por ejemplo, con aplicaciones con infinidad de perfiles que hacen su administración y mantenimiento más engorroso, cuando en realidad, todo se hubiera resuelto con muchos menos.

– Si la organización no funciona, si cada departamento quiere funcionar de manera autónoma, sin una visión global, ¿qué se pretende que solucione el software?. Esta situación empeora cuando ese comportamiento lo tenemos en organizaciones con múltiples sedes dispersas geográficamente.

Si las personas no hacen un esfuerzo por solucionar este problema, ¿se pretende que sea una aplicación la que lo resuelva?.

No es posible dar una respuesta generalista ya que depende realmente de lo que impliquen esos plazos.

Si existe una imposición legal, la necesidad de informatizar o cambiar determinados aspectos de un proceso ya informatizado para poder responder o adelantarse a la competencia sí que tiene una gran relevancia los plazos, en caso contrario, los plazos, incluso siendo importantes deberían modularse también a las necesidades del producto (¿conviene, tal vez, esperar algo más de tiempo y poner en marcha un producto más maduro?) y a las contingencias que hayan podido ocurrir en el proyecto.

La gran ventaja que ofrecen las metodologías ágiles es que en cada iteración ofrecen una nueva versión del producto susceptible, en potencia, de pasarse a producción si así se decidiese. Hay que tener en cuenta que en determinados productos, se pueden tardar varias iteraciones en tener un núcleo mínimo que pueda ser totalmente funcional para ser utilizado en un entorno real, lo cual no quita que, ya sea en un entorno de demostración o incluso en producción, se pueda trabajar o prácticar sobre la versión con el objeto de obtener feedback lo más pronto posible.

Al plazo general del proyecto, se suman los plazos individuales de las iteraciones. Con el objeto de tener un ritmo sostenido de desarrollo, es fundamental que los sprints terminen en la fecha indicada, aunque haya algún compromiso que no se haya podido terminar por completo.

El problema de los plazos generales del proyecto lo tenemos en lo complicado que resulta alinearlo con la expectativa de lo que se pretende tener en el mismo y eso trasciende al hecho o no de tener versiones funcionales cada cierto tiempo, es decir, puede darse el caso de que no te sirva de mucho poner en marcha una versión dentro del plazo si la misma no se corresponde con las expectativas que había para ese momento del tiempo.

Pero tampoco se pueden pedir imposibles y si realmente los quieres, sufrirá la calidad del producto porque velocidades de desarrollo sostenidas en el tiempo muy por encima de lo que se puede producen ese efecto.

Cuando se trabajan con ese tipo de plazos es fundamental gestionar de manera adecuada las expectativas del área usuaria, ya que es muy posible que tenga que haber modificaciones del alcance y en más de una ocasión.

Es mucho mejor esa situación que el hecho de que el usuario o nosotros nos mintamos, mucho mejor entregar unos mínimos con calidad que un producto inestable, mucho mejor tratar de cumplir esos plazos que retrasarnos.

El desarrollo de un producto que satisfaga las expectativas del usuario requiere poner en contraste de manera sistemática las distintas versiones que se van obteniendo en cada iteración, pasen o no a producción, con las ideas que tiene el usuario, las cuales evolucionan de la mano del sistema.

Esto es así porque las ideas no se aclaran hasta que son tangibles, por muy buenas ideas que se tengan y/o muy claro se tenga cuál debería ser el resultado final. En otros contextos como son, por ejemplo, las obras de arte, los mismos artistas que son, además, sus propios usuarios (independientemente de que la creación la adquiera un tercero), necesitan trabajar sobre la solución y en muy contadas ocasiones, todo sale a la primera.

Pensar que la solución no se obtiene a la primera no es una actitud derrotista o una bajada de brazos sino de ver el proyecto desde una perspectiva más realista.

Las ideas son solo hipótesis que cobran forma cuando se materializan en producto. Cuanto más se tarde en corregir las desviaciones entre el producto y las expectativas del usuario más costoso resulta volver a encontrar el camino, por eso el feedback no solo es necesario sino que cuanto antes empiece a aplicarse mejores resultados se obtendrán a la par de un mejor aprovechamiento de los recursos disponibles.

No olvidemos, sin embargo, que se debe desarrollar con intención, el feedback no es un salvoconducto para la programación por permutación o para probar hipótesis que no han sido lo suficientemente reflexionadas. Si se actúa de esa manera se desvirtúan los beneficios del feedback, pasando de un enfoque evolutivo a otro basado en el prueba y error, que no niego que en alguna ocasión para funcionalidades que no se tienen claras pueda ser de utilidad, pero que no debe ser la práctica habitual en un desarrollo de software en el que se trata de adquirir el mayor valor posible con respecto al esfuerzo invertido.

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