Muchas veces, los equipos discuten sobre nuevos cambios y proyectos en los que van a participar en un futuro próximo. Que si tiene poca cobertura por tests, que si hay mucha lógica en los controllers, que si el government de datos, que si la tecnología o framework no es el adecuado… Da la sensación de que sólo tenemos entre manos un reto tecnológico, pero nada más lejos de la realidad.

Durante el ciclo de vida de un proyecto, da igual si usamos Java, Scala o Php, Cassandra o Postgresql, son elecciones que seguramente cambiarán a lo largo de la vida del proyecto. No hay que preocuparse en exceso por ello, es la evolución tecnológica de un proyecto a lo largo del tiempo. Es más, suponiendo que lo hemos desarrollando realmente bien, estos cambios de tecnología serán ágiles y sencillos de hacer.

El principal problema con el que nos podemos encontrar son las personas y el conocimiento que atesoran durante el tiempo. No se trata del conocimiento relacionado con la implementación, hablamos del conocimiento sobre las reglas de negocio aplicadas.

Imaginemos que queremos crear un nuevo sistema centralizado que cubra las necesidades de diferentes productos, ya existentes en el mercado. Imaginemos también que el mantenimiento recae sobre varios equipos distribuidos en diferentes puntos del planeta.

istock_international-business

Con éstos datos ya tenemos un conjunto de variables que añaden cierta complejidad al proyecto. Existen diferentes productos con sus respectivas reglas de negocio (conocidas únicamente por sus creadores y descendientes). Queremos crear un sistema centralizado que debe tener en cuenta las reglas de negocio de todos los productos. Queremos realizar la implementación y mantenimiento con equipos descentralizados en diferentes países, con sus respectivas culturas y formas de trabajar.

Pensemos en el momento en el que se incorpora un nuevo integrante al equipo, ¿cómo se le transmite el conocimiento de negocio?

Hasta ahora, en muchas ocasiones, son los más veteranos del proyecto los que tienen el conocimiento, esas reglas de negocio no escritas que sólo viven en su cabeza y en un código difícil de entender, y son ellos los que transmiten el conocimiento, como un legado transmitido de padres a hijos.

Podríamos pensar que la solución pasa por guardar el conocimiento documentándolo todo, esa misma documentación que precariamente se escribe previo al desarrollo, y que aún antes de poner en producción ya está obsoleta.

Muchos pensarán que la solución pasa por revisar código, el código nunca miente… ¿o si?. Las reglas conocidas, normalmente son las que se encuentran en la punta del iceberg, si además las reglas son antiguas en el tiempo, la parte que no se ve es bastante abundante. Todos sabemos lo que le pasó al titanic cuando chocó con un iceberg ¿verdad?. Pues eso, mas vale que no nos encontremos con muchos icebergs en nuestro camino, porque normalmente la cosa no termina bien.hundimiento-titanic-2016.png

Está claro que añadir complejidad a un proyecto no soluciona problemas competitivos, incorporar decenas de personas tampoco, modificarlo todo constantemente tampoco es una solución que nos haga ser más ágiles. ¿Entonces, qué debemos hacer para seguir a flote?.

Lo que el usuario te da, el usuario te lo quita. El mercado se encargará de poner en su sitio a cualquier producto en sus diferentes etapas, y es por este motivo que no podemos dejar  de analizar a nuestros usuarios para entregar valor de forma constante. Podemos adaptarnos cuanto queramos, podemos cambiar todo lo que necesitemos, pero no debemos perder el rumbo, nos debemos a nuestros usuarios finales y todo lo que hagamos debe ser por y para ellos.

Aspectos como la competencia e intereses económicos puede hacernos perder el rumbo con bastante facilidad, aunque ¡cuidado!, los ingresos hacen que nos mantengamos a flote y la competencia provoca que tengamos que estar alerta.

Hablemos, analicemos, descubramos el negocio juntos e implementemos esas reglas de forma inteligente, modelando el dominio e implementando especificaciones ejecutables orientadas a nuestro usuario final.

Pero de eso… en general ni se habla ni se discute.