Cuando uno está diseñando una arquitectura software hay una parte siempre difícil: la de la toma de decisiones, el valorar los trade-offs y decidir qué dejas a un lado y por qué apuestas. Todos sabemos que por buena que sea la idea siempre tendrá algún aspecto negativo a considerar: quizás un mayor coste, una mayor complejidad de implementación, o un riesgo alto al apostar por una tecnología no tan probada.

Problemas siempre habrá y alguien se encargará de recordártelos cuando empiecen a dejarse notar. Todos se acordarán de ti cuando se le empiecen a ver las orejas al lobo.

Pero el problema de verdad no está en los diagramas, en los planos y diseños, está justo después de eso. Cuando hay que llevarlo a la práctica, cuando alguien tiene que abrir el Visual Studio y convertir en líneas de código contantes y sonantes eso que para ti eran solo un par de flechitas en un Powerpoint. Ahí hay un verdadero riesgo de fracasar: nadie mantiene las decisiones arquitectónicas, nadie tiene en la cabeza todo el diagrama, y los apaños, o el «yo pensé que podíamos resolverlo de esta otra forma», van tomando cuerpo y reemplazando tu bonito blueprint.

Vas a tener que registrar las decisiones más importantes en los ADR, y revisarlos con frecuencia. Adaptarlos para lograr que sobrevivan al contraste con la realidad, y vigilar el coste de cambiar de rumbo. Ten siempre presente qué decisiones son reversibles y cuáles no.

Pero ante todo, comunica siempre los pros y los contras. Necesitarás que se suban a tu barco, y entiendan por qué se tomaron esas decisiones, para que no empiecen a remolonear cuando la mar pinte fea.

El psicólo David Premack propuso en 11965 que iniciaras las tareas del día o de tu proyecto con las actividades menos preferidas o las que menos te motivan. Ya se sabe por esta frase atribuida a Mark Twain: «Si tu trabajo es comerte un sapo, que sea lo primero que hagas en la mañana. Si tienes que comerte dos sapos, empieza por el más grande».

Lo que dice la teoría es que inicias el ciclo (la mañana, la tarde, la semana) con las tareas más pesadas o desagradables, y para el final de la jornada te «premias» con las que te resulten más interesantes o ligeras.

Te aseguras así de que lo importante, lo difícil, lo que todos dejamos siempre para después está ya hecho. El resto será ya cuesta abajo. Incluso te permite comprobar que, si la tarea era más difícil de lo esperado, tienes todavía margen para reaccionar.

Todos sabemos que no es lo mismo acabar un viernes por la tarde cumpliendo a toda prisa eso que tan poco nos gusta hacer, que terminar con las tareas sencillas y que nos dan un respiro para poder empezar el fin de semana con algo más de resuello. Ea, valor y a por el sapo.

Entre los años 22 y 25 corrieron olas de despidos en muchas empresas. Hasta entonces había dinero barato, las compañías disponían de financiación casi ilimitada y cuando eso se acabó se dieron cuenta de que estaban sobredimensionadas, de que de esa manera nunca iban a tener beneficios.

Es cuando empezaron los recortes, primero por necesidad, pero en algún caso también por moda. El último grito en gestión era Lean Reduction, Lean Staffing. Quitamos un miembro del equipo y al poco todos se adaptan, se reparten el trabajo entre el resto, siguen trabajando y las incidencias se resuelven igual, los desarrollos continúan. Nada parece cambiar así que quitamos a otro miembro de cada equipo. Aparentemente todos los indicadores siguen en verde, los proyectos siguen entregándose.

Musk parecía ser el ejemplo máximo de esto. Cuando compró Twitter, que llevaba años en pérdidas, redujo la plantilla a la mitad. Donde antes había diez personas, solo quedaron cinco o menos. Y nada parece haberse roto en la empresa del pajarito.

En realidad el coste existe. Menos innovación, menos documentación, menos tiempo para pensar. Si dejas de hacer mantenimiento preventivo a tus máquinas, a tus camiones o s tus activos software, durante un tiempo nada pasará, nada se rompe de golpe, pero la deuda se acumula. Podrás pagarla cuando tenga un tamaño que la haga insostenible?

Ya sabemos que el trabajo se expande hasta ocupar el mayor tiempo posible, sin límite alguno. La capacidad humana también puede asumir más trabajo del que parecía posible, pero en algún momento la organización empieza pagar esos intereses y a consumir su propio futuro.

El libro Management 3.0 indica que los sistemas de información, los portales o aplicaciones que tratamos de crear, no son desarrollados como en la industria de la construcción: con unos grandes planos, mucho diseño, y un montón de camiones llegando después a la obra para dejar los materiales. En IT somos más como jardineros podando, regando y retocando aquí y allá.

Se trata más bien de plantar un semilla o un pequeño mato y dejarlo crecer, dejar que vaya tomando forma y orientarlo hacia lo que queremos tener, en lugar de tratar de tener un arbol ya crecido con las dimensiones y forma que queremos. Si le falta la rama de Contabilidad, la diseñamos e injertamos a la fuerza donde queremos. Me temo que así no va a funcionar.

Esto que cuenta el libro me recuerda a la ley de Gall, que dice que todo sistema que funcione proviene, sí o sí, de un sistema más pequeño que ya lo hacía y evolucionó hacia el sistema actual (que es lo mismo que decir que no hay sistema grande que funcione que no provenga de un sistema semilla original que ya haya probado su viabilidad).

Si tienes un nuevo proyecto entre manos, asegúrate de construir primero un germen inicial que tenga éxito comercial y funcional. Luego, vete haciéndolo crecer poco a poco, añadiendo todo eso que le falte (o que no le sobre).

Todos sabemos que muchos contratistas son impredecibles: no empiezan el trabajo el día indicado, tampoco esa semana ni ese mes, trabajan de forma chapucera o tienen malas formas cuando se les menciona que algo no se hizo de forma correcta.

El Libro MBA Personal menciona el ejemplo de una pequeña empresa de reformas de Aaron y Pat en la que su secreto está en la «capacidad de predecir». Todos los trabajos que hacen son de alta calidad, respetan las fechas y son agradables en el trato.

Ni que decir tiene que, como consecuencia, les llueven los pedidos y los clientes hacen cola por sus servicios, lo que es un logro bastante grande en un sector en el que hay mucho intrusismo. Conseguir eso donde abundan los profesionales que se ofertan a un precio muy bajo, si lo comparamos con los de las empresas que tratan de dar calidad, es una señal fuerte de haber hecho las cosas bien.

Lo que funciona en el mercado «blando» de la construcción también es válido para casi cualquier otro sector: trabaja, trabaja bien, cumple con lo que se te ha pedido sin regatear en el tiempo dedicado o los materiales, y con un poco de suerte el boca a boca hará el resto. Solo tienes que ser constante y dejar que el tiempo te caiga encima, poco a poco, y sin desesperar (aunque podemos intuir lo difícil que es esto).

Si tienes que preparar un documento muy extenso con todos los requisitos del proyecto para que te lo firmen, puedes estar dando un paso equivocado.

Puede que lo quieras para defenderte si hubo un malentendido y poder decir, «lo siento, esto es lo que se firmó», pero con eso solo ganarás una batalla, el cliente no podrá reclamar nada pero no estará contento. Simplemente, no va a estar contento contigo y no va a llamarte para el próximo proyectos. Esperaba algo distinto. Lo necesitaba para trabajar, y que haya cometido el error de firmarlo no lo va hacer más contento a la hora de pagar.

No hay nada de malo en recoger lo hablado en un documento, pero ten en cuenta que no lo van a revisar. Seguramente ni a firmar. Nadie quiere ser responsable de que en la página 68, tercer párrafo tenga por error: «el informe no será personalizable», cuando en realidad debe decir que sí deber ser personalizable. Si ha habido un malentendido el malestar seguirá igual.

Si realmente quieres solucionar el problema, enseña tu trabajo cada poco en una demo, envíales un vídeo del comportamiento de la aplicación, un informe de estado de lo que estás haciendo esa semana, pero sobre todo, pónselo en producción al poco tiempo de comenzar.

Haz que lo use, no esperes 6 meses o un año a que el cliente lo vea y se dé cuenta de que eso en los que has estado trabajando durante un montón de tiempo no le sirve para nada.