William Grosso. La atención y los errores

Comenta William Grosso que: “El código que aburre al programador es probable que contenga errores”. Esta reflexión es extensible a cualquier trabajo que no nos parezca lo suficientemente motivante como para centrar nuestro enfoque en él.

Cuando desviamos la atención de la tarea que estamos realizando se incrementan drásticamente las probabilidades de que cometamos errores.

La atención se desvía cuando encontramos una situación u otra tarea que nos parece más interesante y/o porque hay algo que nos preocupa o inquieta.

Cuanto más interesante (por el motivo que sea) nos parece una tarea más capacidad tenemos de mantener nuestro enfoque en la misma y menos errores tendremos como consecuencia de despistes, además de manera inconsciente le daremos más vueltas (productivas) a nuestro trabajo con el objeto de eliminar (o por lo menos reducir) posibles incidencias porque estaremos más implicados en que el resultado final sea lo más óptimo posible.

No siempre vamos a tener la oportunidad de que nos llegue trabajo interesante o motivante. En este caso si las tareas no lo son implícitamente tendremos que ser nosotros los que pongamos ese interés o esa motivación y si nos ponemos a buscar encontraremos motivos para ello y si aún así no lo conseguimos tendremos que tirar de profesionalidad para intentar que el trabajo salga de la mejor forma posible y mantener el enfoque en el mismo todo lo que se pueda.

Bertrand Meyer. Madurar las soluciones

El producto resultante de un proyecto de desarrollo de software requiere de un período de maduración que comienza con el inicio del mismo a través de los ajustes que se realizan en las diferentes iteraciones y a través del conocimiento adquirido dentro y al final de las mismas (no solo se trata de aprender del feedback, se puede aprender también mientras se analiza una historia de usuario y nos apoyamos en estrategias tales como prototipado, pantallazos, etc…).

La solución no se tiene clara desde el principio, nadie la tiene ni usuarios ni desarrolladores (cada uno dentro de su ámbito de actuación) y lo más probable es que la visión que ambas partes tengan del producto en ese momento difieran sensiblemente.

El conocimiento inicial es limitado y esto eleva la probabilidad de que cometamos errores.

Es cierto que por algo tendremos que empezar y eso ya supone una apuesta pero eso es diferente a jugar todas tus cartas a una solución y tirar con ella hasta el final que es lo que sucede en los ciclos de vida clásicos. En estos casos también se madura la solución pero más a nivel técnico que funcional lo que da lugar a los problemas habituales en la aceptación del producto o tras su puesta en producción y es el desajuste entre lo que el usuario recibe y las expectativas que tenía puestas en el mismo.

En el proceso de maduración tendremos probablemente que desechar decisiones que tomamos en etapas anteriores precisamente por el hecho de no haber acertado o por existir otras soluciones más efectivas y válidas. Tirar y volver a hacer tiene un coste pero más caro resulta ir hasta el final con una solución no satisfactoria.

Lo importante es hacer un producto cada vez mejor aunque no consigamos un avance lineal en el proyecto.

Bertrand Meyer realizó la siguiente cita: “Las malas ideas y las más complicadas (que a menudo son las mismas) a menudo aparecen las primeras, se necesita tiempo para que aparezcan las simples y elegantes”.

Roy Miller. El enfoque evolutivo en el desarrollo de software

Comenta Roy Miller (consultor y autor experto en metodologías ágiles) que: “Todo lo que necesitamos saber es el primer paso que tenemos que dar para dirigirnos hacia donde pensamos que queremos dirigirnos en ese momento”.

Este tipo de reflexiones se realizan principalmente para llamar la atención sobre un aspecto concreto y en este caso lo que trata probablemente de hacer Roy Miller es que dediquemos unos minutos a pensar por un lado en la incertidumbre característica de todo proyecto de desarrollo de software y por otro en su enfoque evolutivo en el cual vamos construyendo poco a poco el producto objetivo que lo mismo difiere de manera sensible de la idea que del mismo tenían inicialmente los usuarios y el propio equipo de desarrollo.

Siguiendo un enfoque evolutivo sí que resulta relevante cuál es el siguiente paso que tenemos que dar ya que nos permitirá llegar a la siguiente etapa y allí ya veremos pero no por ello, y estoy seguro que Roy Miller piensa de manera parecida, debemos obviar otro tipo de información que puede resultar de utilidad como por ejemplo los riesgos del proyecto y su situación (que llevamos hecho, qué tareas estarían pendientes de realizar, cuál es el presupuesto restante, qué problemas nos estamos encontrando en el proyecto, cuáles están originando resistencia al desarrollo, etc…).

No se trata de control sino de ser consciente de cómo estamos algo importante para evolucionar porque el siguiente paso importa pero también desde dónde se da.

Mary Poppendieck. Tom Poppendieck. Iteración y alternativas

Existe una infinidad de caminos que pueden dar lugar al producto final. Solo algunos de ellos permitirán conseguir uno que tenga éxito.

Recorrer cada camino tiene un coste y cada uno de ellos tiene un coste diferente.

Por tanto lo ideal es encontrar el camino que permitiéndote conseguir un producto final de éxito tenga el menor coste posible.

Eso es un ideal pero no olvidemos que lo realmente importante es el valor del producto y en consecuencia su capacidad de amortizar la inversión.

Como desarrolladores tenemos la obligación de tener la mente abierta, de pensar que existen más soluciones que la que tenemos en la cabeza y que la más adecuada lo mismo te la proporciona quien menos te lo esperas. En un proyecto no gana quien consigue llevar más soluciones al producto final sino quienes tienen toman la decisión de sumar para que el proyecto tenga éxito. No se trata de una carrera de egos sino de un trabajo en equipo.

En un desarrollo iterativo incremental, el resultado de la iteración muestra una solución concreta que puede ser buena o mala, que puede ser mejorable o no, pero es la que es. En base a la misma se puede tomar la decisión de seguir evolucionando el producto o realizar modificaciones sobre la misma. No hay nada que deba ser inamovible si nuestro objetivo es el valor del producto final (dentro de las restricciones con las que tengamos que convivir en el proyecto).

Mary y Tom Poppendieck realizan la siguiente reflexión sobre este tema: ” Ua iteración debería ser considerada como una demostración de una posible solución y no ser considerada como la única solución”.

Kent Beck. El coste de no estar en producción

Llegar a producción da miedo. El área usuaria siempre tendrá el “síndrome de la última versión” y, por tanto, querrá incluir toda la funcionalidad que puedan y pondrán los umbrales de aceptación muy altos.

A los desarrolladores también les entra el pánico porque por muchas pruebas que se hayan realizado al producto es en producción donde se pasa el examen final, todo lo anterior son exámenes parciales que si bien hay que superarlos no tienen más trascendencia (y no con ello quiero quitale importancia) que crisis puntuales en el proceso de desarrollo.

Si hay presión en el desarrollo, no es comparable con la que se recibe si el producto llega a producción y es un desastre.

Esta situación puede eternizar el paso a producción en muchos proyectos de desarrollo de software.

Ante esto hay que reflexionar (usuarios y desarrolladores) sobre las características del sistema de información que vamos a poner en producción, si se trata del software de una central nuclear o un software crítico que puede poner en riesgo vidas humanas, la salud de las personas, el medio ambiente o la continuidad de la organización se puede entender que toda precaución es poca, pero fuera de ese círculo (que es la inmensa mayoría de los sistemas que se desarrollan) hay que evaluar el coste real que implica retrasar sistemáticamente un paso a producción por el intento de alcanzar una perfección que nunca se va a conseguir.

Ya lo dice Kent Beck: “No estar en producción es gastar dinero sin hacer dinero”.

Craig Zerouni. Excepciones

Comenta Craig Zerouni que: “Si tienes muchas casos especiales, estás haciendo algo mal”. Y efectivamente, pienso que es así, cuando las excepciones se convierten en norma es que algo está fallando: tal vez el enfoque del problema, los procesos, la metodología, la estrategia, la suma de todos ellos y/o se está añadiendo al producto una complejidad innecesaria.

Está claro que hay que resolver el problema y que si eso implica aplicar soluciones que se salen de la ortodoxia, se hace. Ahora bien, no es sostenible aplicar este tipo de alternativas en el tiempo, porque el problema de fondo sigue ahí y no siempre será posible sortear su resistencia.

También es importante que analicemos si nuestras decisiones son fruto de la necesidad o son consecuencia de cómo creemos que debemos hacer las cosas. Ambos conceptos son distintos, en el primer caso se justifica la excepción, en el segundo no necesariamente, es más, es una de las principales causas que provocan las excepciones que no es otra cosa que nuestra oposición a los procesos o normas que rigen el desarrollo del proyecto, lo que nos lleva a buscar el camino más fácil (y no necesariamente el mejor) de obviar las reglas existentes sin analizar si es posible encontrar una solución compatible con ellas.

El camino pasa por la flexibilidad dentro de una serie de procesos mínimos (que se pueden ajustar a la naturaleza y criticidad del proyecto y del producto) que permitan armonizar los desarrollos dentro de una organización, con la mentalidad abierta a admitir excepciones cuando haya circunstancias que lo justifiquen y siempre con la intención de una mejora continua de los mismos.

Peter Drucker. La importancia de conocer los objetivos

Una situación muy común en las organizaciones o a menor escala en los departamentos de las mismas consiste en no tener definidos cuáles son sus objetivos. Esto provoca que el funcionamiento de los mismos esté a la deriva porque realmente no saben a dónde quieren ir y aprovechan, eso que abominan, que es estar apagando continuamente fuegos para evitar tratar este asunto incómodo.

¿Incómodo? Sí, porque definir objetivos implica tener una referencia y eso puede quitar muchas caretas.

Hay una situación todavía peor que no tener objetivos y es pensar que los hay. El ejercicio es muy sencillo, pide a varias personas de tu departamento o de tu organización que pongan en orden de prioridad cuáles entienden ellos que son los objetivos… Suerte.

Me parece muy interesante la siguiente cita de Peter Drucker: “La gestión por objetivos funciona… si conoces los objetivos. El 90% de las veces, no los sabes”.

Jaron Lanier. No sabemos hacer software

Jaron Lanier es un desarrollador americano, pionero en el campo de la realidad virtual, autor y músico.

Hay una reflexión suya en la que refleja una realidad que no es otra que la complejidad de desarrollar software: “No creo que la humanidad sepa cómo hacer que software todavía. Permítanme decir que con valentía que no creo que la humanidad haya descubierto el truco de cómo hacer software. No sabemos lo que deberíamos hacer juntos para conseguirlo, y tampoco el procedimiento a seguir”.

Más allá de reflejar lo complicado que es esto, no estoy de acuerdo en que no se sepa, tenemos a nuestro favor nuestro conocimiento y experiencia, que vienen a ofrecernos todo un abanico de posibilidades, lo que no tenemos es la capacidad para resolver los infinitos problemas que se pueden producir en todos los proyectos de desarrollo de software, ni la capacidad de acertar siempre.

Lo que no conocemos, efectivamente, es ese truco, ni creo que se llegue a descubrir, porque se trata de una actividad intelectual, evolutiva, fruto de la interacción y comunicación entre personas, que se desarrolla sobre contextos distintos y cambiantes.

Peter Drucker. Lo que no se dice

Me parece muy sabia la siguiente reflexión de Peter Drucker: “El aspecto más importante de la comunicación es escuchar lo que no se dice”. Y no se refiere a lenguaje no verbal, sino a interpretar realmente lo que nos están comentando porque no debemos olvidar que somos personas, estamos llenos de emociones, también de miedos y no siempre trasladamos la realidad de una situación o de un problema a palabras bien porque no queremos, no sabemos o no podemos.

El objetivo de las relaciones entre las personas en un ámbito profesional y colaborativo debe ser la transparencia, pero no deja de ser un fin, no digo una quimera, pero sí algo que es más complicado de lo que parece porque hay que ser muy valiente para no guardarte nada y exponerlo todo. Además de valentía se requiere confiar en la otra parte y la confianza cuesta mucho construirla y consolidarla.

Pero hay que intentarlo. En un contexto como el del desarrollo de software en el que la comunicación y la interacción entre las personas es esencial, es la base para establecer una relación de confianza entre todas las partes, algo que resulta fundamental para que el proyecto se desarrolle sobre un contexto propicia (independientemente de que después las cosas salgan mejor o peor).

Poco a poco, mientras tanto tocará interpretar lo que se dice pero también lo que no.

Charles Eames. Reconocer la necesidad y las expectativas

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