¿Cuál es la causa de que "repentinamente" le entre prisa a stakeholders y/o project managers?, ¿hay alguna forma de que podamos desarrollar software más rápido?, ¿cómo podemos acelerar?, ¿qué significa "prisa"?

Todos los proyectos están sujetos a restricciones, de tiempo, de alcance, de personal, de presupuesto... no existe proyecto con recursos ilimitados. El rol de project manager se encarga de informar periódicamente a todo el equipo de cuáles son las restricciones, así como de los posibles cambios que pueda haber en ellas. Los desarrolladores deben de preguntar sobre las restricciones si las desconocen o si tienen dudas. Si estas programando y desconoces cuáles son los límites del proyecto en cuanto a fechas de entrega, presupuesto, tecnologías, etc, pregunta lo antes posible, porque esas restricciones existen. Uno de los motivos habituales por los que la prisa aparece de manera repentina, es porque las limitaciones que constriñen el proyecto no se habían comunicado ni preguntado. Como en la mayoría de los casos, se trata de un problema de comunicación. Típicamente sucede que las personas que programan conocen bien las tareas técnicas de bajo nivel, pero no tienen una visión global de alto nivel del proyecto, desconocen el impacto en el negocio. Probablemente no se ha hecho el ejercicio de ponerse en el pellejo de los demás, de los que ponen el dinero o lo gestionan. Lo inverso no va a ocurrir, es decir, que los stakeholders se pongan en el pellejo de las personas que programan es muy poco probable, porque no saben programar. Cuando se da el caso de que "saben programar" porque trabajaron apagando fuegos o haciendo ñapas, es incluso peor, pues esperan que todo el mundo las haga. El interés por comprender a los demás debe formar parte del carácter de cualquiera que esté escribiendo código, así como el hábito de comunicarse permanente y eficazmente. Cuando el ritmo del proyecto no es el que algunas personas esperaban o los hitos no se están cumpliendo, entonces da la impresión de que surge una prisa repentina y todos quieren correr como locos.

Otro motivo por el que puede surgir la prisa en un proyecto es porque el rol de project manager piensa que presionando a los técnicos, estos van a ser capaces de avanzar más rápido. Puede llegar a comunicar fechas de entrega que no son reales, sino que están adelantadas días o semanas, constriñendo más de lo necesario. A menudo la intención es la de tener un colchón de seguridad para garantizar el cumplimiento de la verdadera fecha de entrega, basada en la creencia de que presionando más a los técnicos se van a esforzar más y a terminar antes. Esto es un grave error en la gestión, se agarra antes a un mentiroso que a un cojo, y como consecuencia se pierde la confianza. Luego el equipo técnico también va a mentir cuando tenga que dar estimaciones (las va a inflar para protegerse). Lo más efectivo para trabajar en equipo, es tratar a todo el mundo como personas maduras, responsables y trabajadoras, transmitiéndoles información veraz y actualizada constantemente. Hay que confiar en los demás para que hagan un buen trabajo. Si tratamos a las personas como inmaduras o irresponsables, estas acabaran por comportarse como tales.

Hay más escenarios protagonizados por las prisas, otro es, el del proyecto que empieza tarde y por tanto va con prisas desde el día uno. Estos son los proyectos en los que evito trabajar. Una de mis labores actuales en Lean Mind es buscar nuevos proyectos y clientes, lo cual implica discernir para descartar proyectos (entre otras cosas). Aquellos que nos llegan como muy urgentes, son candidatos a ser rechazados, siempre y cuando nos lo podamos permitir (que por suerte estamos pudiendo). No nos corresponde a nosotros responsabilizarnos de malas decisiones de personas con las que nunca hemos trabajado. Si el proyecto debiera haberse iniciado hace 12 meses, pero se ha ido dejando hasta que alguien le ha visto las orejas al lobo, no somos nosotros quienes tienen que sufrir las consecuencias. Por aquellos que ya son clientes con los que llevamos tiempo trabajando, sí nos esforzamos en ofrecer soluciones. Por los que aún no son clientes, lo evitamos, porque es una muy mala forma de empezar una relación. Para evitar la insatisfacción de los clientes y el estrés del personal, es mejor rechazar amablemente este tipo de proyectos.

Bien, asumiendo que por el motivo que sea vamos a trabajar con prisa, ¿cómo podemos avanzar más rápido? La estrategia más común y a la vez más errónea, es intentar programar más rápido. Intentar escribir más líneas de código por hora. Pocas veces resuelve las necesidades actuales, y cuando lo hace es en detrimento de la sostenibilidad del proyecto en el medio y largo plazo. En el mejor caso es "pan para hoy y hambre para mañana". El cuello de botella de los proyectos no está el teclado, en el número de líneas de código que generamos, sino en el manejo de la complejidad accidental y en los malentendidos causados por una comunicación deficiente o insuficiente. La forma eficaz de ir más rápido es tomar mejores decisiones y simplificar el diseño de las soluciones. ¿Te suena la palabra "lean"? Lo que debemos buscar son soluciones con el menor código posible, con el más simple. El truco está en diseñar soluciones sencillas, con menos funcionalidades y florituras de las que nos gustaría, pero garantizando el correcto funcionamiento de aquellas que verdaderamente marcan la diferencia en el producto. No se puede tener todo; velocidad, calidad y todas las funcionalidades que hemos soñado a la vez. Para minimizar el "time to market", tenemos que acostumbrarnos a poner en producción productos "incompletos", pero que funcionan muy bien. Por algún lado hay que ceder, es una cuestión de estrategia que requiere pensar siempre en el medio y largo plazo, además del corto. Un producto que se pone rápido en producción no puede ser el orgullo de los stakeholders, sino que tiene que saber a poco para ellos, y a mucho para los usuarios. Con cada release del producto iremos aumentando sus prestaciones y contentando a stakeholders, pero sobre todo iremos aprendiendo del feedback real de los usuarios y construyendo el producto que de verdad necesitan y demandan. Con mucha frecuencia la idea de solución que tenemos en mente acaba distando mucho de lo que realmente necesitan los usuarios. Al final se trata de servirles bien, no de satisfacer los antojos arbitrarios de personas que ni siquiera van a utilizar la herramienta.

Una buena toma de requisitos es fundamental para conocer bien el problema y averiguar qué posibles soluciones son más adecuadas y más rápidas de implementar. Las habilidades no técnicas también juegan un papel fundamental, tanto la capacidad de comunicarse de manera eficaz, como la empatía y la asertividad para decir lo que haya que decir, aunque sea incómodo hacerlo. Cuando se pide un requisito que sabemos que es totalmente inalcanzable en fecha, o bien que es muy ambiguo, es fundamental que nos expresemos de manera asertiva. Se trata de explicar la realidad, evitar malentendidos y gestionar las expectativas. Cuando algo no se entiende o hay cualquier impedimento, tenemos que levantar la mano y avisarlo. No le hacemos ningún favor a nadie con paños calientes, ni tratando de restarle importancia a problemas graves o directamente tapándolos para no decirle a la gente lo que no quiere escuchar. Si comunicamos las dificultades desde la empatía, poniéndonos en el lugar de los demás, es factible encontrar acuerdos y trabajar como equipo.

Para explorar el problema tenemos un sinfín de técnicas que nos pueden ayudar, desde Design Thinking hasta Specification by Example, dentro de la cual está BDD (Behavour Driven Development). Personalmente me da muy buenos resultados utilizar ejemplos reales del sistema para comprender el problema y diseñar la solución. BDD es una técnica fabulosa de definición de requisitos. En realidad, cualquier técnica que reúna a todo el equipo, incluidos stakeholders, y les haga pensar en el sistema con un grado de detalle muy fino, va a ser beneficiosa y va a ahorrarnos mucho tiempo. Esto será lo que nos haga avanzar más rápido, pensar bien antes de programar, en lugar de querer escribir código muy rápido implementando la primera idea que se le ha ocurrido a alguien.

Hace poco participé en un proyecto en el que se nos pedía diseñar un mecanismo de caché. El proyecto iba con cierto retraso. Se nos comentó por encima que hacía falta una caché y se nos entregó una documento de "especificación" de requisitos con una descripción muy abstracta y genérica, que básicamente describía a grandes rasgos lo que hace una memoria caché. Con ese documento podríamos haber implementado cien sistemas distintos de caché y probablemente pocos de ellos hubieran resuelto el problema específico, puesto que la información de que disponíamos no era suficiente para comprenderlo. Podríamos haber implementado un sistema ultraflexible, escalable, configurable y seguro, en el que haber estado trabajando semanas o incluso meses. Podríamos haberlo hecho escribiendo código a toda velocidad, dejando así un legado imposible de mantener. En vez de eso propusimos varias sesiones de trabajo en la especificación de requisitos. Empezamos a dibujar diagramas juntos, a entender las casuísticas más importantes, así como los casos límite, basándonos en ejemplos de uso del sistema. Los propios expertos en el dominio se dieron cuenta, al bajar el nivel de detalle del análisis, de que tenían muchas dudas sobre cómo debía ser utilizada la caché. Así empezamos a de finir las restricciones del sistema de caché, para implementar algo útil a la vez que minimalista, a tiempo y en forma. Después de dos sesiones de análisis en grupo, de dos horas cada una, acompañadas de sesiones de análisis individuales, se concluyó que para la primera versión del software sería suficiente con un simple wrapper de memcached, que tardaríamos en implementar menos de una semana sin hacer ñapas.

La forma de "desarrollar con prisa", es visibilizar las restricciones del proyecto desde el principio, y definirlas cuando no se hayan puesto de manifiesto de manera explícita, porque en realidad, siempre las hay. Cuanta más prisa haya, más y mejor tenemos que pensar. Hay que priorizar y saber distinguir lo urgente de lo importante. Se trata de utilizar mejores estrategias y mejores tácticas, escribiendo código sostenible. Un código escrito con prisa solamente va a darnos más quebraderos de cabeza.