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

El desarrollo de software debe buscar la satisfacción de las expectativas del cliente. De lo que nos aproximemos a ese hito, será lo cerca o lejos que estaremos del cumplimiento de los objetivos.

Hablo de objetivos relacionados con la calidad del producto. La calidad técnica, es importante, muy importante, pero para el usuario está en un segundo plano, respecto a si el producto hace lo que espera y le permite trabajar de manera productiva.

Por ese motivo se dice que la calidad tiene dos puntos de vista, el del usuario y el del desarrollador. Es cierto que existe esa dualidad pero también que no se debe entender la una sin la otra.

Un producto software siempre es susceptible de ser evolucionado. Habrá un motivo para ello y el resultado debería ser un incremento del valor del mismo siendo proporcional al esfuerzo (coste) invertido para conseguirlo. De aquí surge otro objetivo: conseguir el mayor valor posible invirtiendo el menor esfuerzo posible.

Si conseguimos ganar valor, ahorrando esfuerzos, tendremos la posibilidad de seguir evolucionando el producto para así conseguir generar más valor. Es algo que debemos tener siempre presente, pero que no debe llegar a obsesionarnos porque llegado a un punto puede dar lugar a situaciones en las que se ponga muchos reparos a especular en el desarrollo, algo que a veces es inevitable porque el usuario no siempre tiene claro lo que quiere y necesita ver ejecutada su especificación para valorar si su idea es buena o si por el contrario necesita ajustes.

Tener presente ese rendimiento de la inversión obliga a tener en cuenta la calidad técnica en los desarrollos (y por ahí es donde se puede y se debe trabajar este asunto con el cliente), rematar las tareas, cumplir los compromisos, reducir la tasa de errores y desarrollar con intención.

Con la intención se pretende minimizar el número de iteraciones. Es cierto que intención y especulación son dos términos que no se llevan bien, pero no son incompatibles, de hecho no se utilizaría el término intención si se tuviera la certeza de que todas las decisiones que se toman son correctas. Se trata, por tanto, de trabajar con el usuario, para incrementar la probabilidad de éxito: historias de usuario con prototipado de pantallas tomando como referencia versiones ya liberadas del producto, de las funcionalidades más prioritarias seleccionar aquellas que se tenga más clara su operativa de uso, etc…

Es importante diferenciar entre reconocer la necesidad y crearla. Lo primero es positivo, lo segundo solo es interesante si tu misión es vender productos o servicios.

En el desarrollo de software menos suele significar más e incrementar la complejidad de un sistema por incorporarle necesidades que no son reales no da buenos resultados.

Reconocer la necesidad es tener la capacidad de interpretar las expectativas del usuario. Es muy complicado conseguirlo a la primera, requiere su tiempo, se necesita conocer al usuario, a su negocio, realizar varias iteraciones y a partir de ahí empezar a crecer.

Una conocida cita de Charles Eames dice lo siguiente: “El reconocimiento de la necesidad es la primera condición para el diseño”.

La clave, por tanto, es la intención. Una cosa es que el universo de expectativas tarde en conocerse (e interpretarse) y otra es que desde un primer momento no intentemos hacerlo lo mejor posible con la información que tengamos. Si no se tiene suficiente información para acometer un desarrollo, aunque sea una primera iteración, lo mejor es esperar a adquirir algo más de conocimiento para empezar a reconocer cuáles son esas necesidades.

Os recomiendo la lectura del artículo: “Preparando el primer sprint“.

Una de las labores más complicadas de un gestor de proyectos en aquellos casos en los que existen múltiples equipos de trabajo que pueden pertenecer incluso a proveedores diferentes (tampoco resulta sencillo hasta en aquellos casos en los que existe un solo equipo formado por pocos desarrolladores) es que todos comprendan cuáles son los objetivos y las restricciones que existen para alcanzarlos.

Resulta especialmente complicado sobre todo en aquellos equipos que están desarrollando funcionalidades o herramientas complementarias al núcleo el sistema, en primer lugar porque la atención del gestor estará más orientada a la línea principal de desarrollo del producto así como a eliminar o paliar las posibles resistencias que puedan existir en cualquiera de las distintas líneas y en segundo lugar porque, por el mismo motivo, se encontrarán a distancia del product owner y de los directores usuarios y contemplarán desde más lejos sus expectativas y su presión.

Hay proyectos donde el trabajo de estos equipos secundarios es igualmente secundario pero en otros casos el resultado de su trabajo puede ser esencial para el funcionamiento y/o para la puesta en marcha del sistema. Tanto en un caso como en otro (aunque por supuesto mucho más en el segundo) es necesario que esos equipos mantengan el enfoque y la tensión en el proyecto, de la misma forma que lo hacen aquellos equipos que están peleando con las partes más críticas del sistema.

Como decía, esto no es fácil, ya que resultaría fundamental que el product owner y los directores usuarios les expresasen directamente y de forma constante (continua) sus expectativas y eso es algo que resulta complicado en proyectos con una cierta envergadura. Ahora bien, si no es posible llegar a eso cualquier aproximación ya supone un avance. Si el equipo no termina de asimilar la situación, el gestor de proyectos debe actuar y en estos casos es mejor un falso positivo (pensar que el equipo no es consciente de la situación e insistir) que creer que se ha asimilado y no actuar.

Cuantas más personas se suban al barco más posibilidades hay de sacar el proyecto adelante, sin olvidar que hay que procurar que quien suba no vuelva a bajar (de ahí la importancia de las actividades necesarias para que los equipos y los desarrolladores mantengan el enfoque en el proyecto).