archivo

Archivo de la etiqueta: expectativas

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

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

Caso particular del antipatrón “Trampas evitables” y consecuencia en muchas ocasiones de “Al servicio de Pareto“.

A veces por exceso de optimismo y otras por presiones del área usuaria, del cliente o de tus jefes, se tiende a mencionar la fatídica frase del: “Esto está casi”, cuando realmente no es esa la realidad.

No olvidemos que la curva de progreso en el proyecto es pronunciada al principio pero que el final se tuerce mucho porque es necesario alinear todos los detalles para poder hacer una entrega en condiciones y sabemos lo complicado que resulta (hablo de hacer una entrega con garantías no de entregar por entregar).

En el momento en que pronuncias “Esto está casi”, estás generando una expectativa (y mucho peso). Cuidado con eso, ya que es absolutamente necesario hacer una buena gestión de las mismas, de lo contrario se pierde confianza y credibilidad, que son piezas fundamentales en las relaciones entre los diferentes implicados que participan en el proyecto.

No digo que no se deba ser transparente, al contrario, si no lo eres te estás equivocando, lo que sí estoy comentando es que hay que ser prudente y medir bien qué se dice, a quién se dice y en qué momento.

Este antipatrón surge en aquellos casos en los que los desarrolladores (o el equipo de desarrollo) dan por correctas determinadas funcionalidades sin haber pasado el suficiente número de casos de prueba que permitan testearlas teniendo en cuenta diversas casuísticas en los juegos de datos, en la interacción con terceros sistemas o en la propia operativa del usuario.

El testing de fogueo es una de las causas que provocan que un mayor número de defectos se detecten más tarde de lo que debieran, como por ejemplo en la integración con otros módulos, con otros sistemas o incluso en producción.

Aplicando testing de fogueo se obtiene una imagen del estado del proceso de desarrollo que no se corresponde con la realidad, por eso insisto mucho en que las funcionalidades tienen que estar bien probadas porque de lo contrario se crean expectativas en cuanto al avance de los trabajos que pueden provocar que, cuando nos demos cuenta de los problemas, sea demasiado tarde para reaccionar.

No se debe confundir con el antipatrón: “No probado pero finalizado, ya que este tipo de prácticas no son necesariamente provocadas por la necesidad de cumplir unos plazos más o menos complicados, sino que vienen “de serie” con los desarrolladores.

Ya lo decía Doug Linder: “Un buen programador es aquel que siempre mira a ambos lados antes de cruzar una calle que tiene un único sentido“.

La regla del 80-20 o principio de Pareto es peligrosa si nos dejamos contagiar por el optimismo que nos trae un progreso rápido en el desarrollo del producto.

No debemos olvidar que el avance es rápido porque no es necesario que se cierren todos los detalles y porque tareas problemáticas o que no terminan de salirnos se terminan dejando para más adelante.

Cuando crees que ya tienes casi todo y te olvidas de que todavía te queda mucho trabajo por hacer, corres el riesgo de caer en este antipatrón.

¿Cuándo surge? En el momento en que se pierde la tensión por parte del equipo (o del área usuaria) y/o cuando se decide dedicar menos esfuerzo al proyecto (porque, al fin y al cabo, está casi listo).

La consecuencia suele hacer mucho daño, porque ese 20% de ejecución restante se termina eternizando, requiriendo mucho más esfuerzo y afectando a las relaciones entre desarrolladores y usuarios, ya que la frustración será cada vez más evidente y las expectativas de cliente y proveedor cada vez estarán más lejos.