Lecciones aprendidas

Texto acerca de las lecciones aprendidas en el trabajo final de la carrera.

Este proyecto nos dejó una buena variedad de lecciones aprendidas, no solo en aspectos técnicos sino también en dinámicas de trabajo, comportamiento de grupos y comunidades, y hasta filosofías para la vida.

Desde el punto de vista técnico, el desarrollo de Cubitorium nos permitió ver que la tecnología está mucho más avanzada de lo que las personas están para su adopción. Esto no es un punto negativo sino que nos permite desarrollar soluciones ya novedosas, innovadoras, y con un valor superior a las tradicionales sin necesidad de ser radicales y brindar un cambio de paradigma abrupto que resulte contraproducente.

Ya es al día de hoy posible realizar soluciones completamente descentralizadas, con costos no solo comparables o menores a las soluciones tradicionales, sino que también con una estructura de costos diferente en la cual el responsable de pagar por los mismos deja de ser una entidad única y se convierte en algo solventado por una propia comunidad. 

Lo que permanece un tanto rezagado es la adopción generalizada de estas tecnologías. El mundo se está moviendo demasiado rápido; más rápido de lo que la mayoría de las personas puede seguir y, como subproducto, causa una disparidad en el nivel de las tecnologías y el entendimiento o concepción general de los usuarios de qué cosas son posibles o de qué forma se utilizan. Esto se puede mitigar mediante el uso de guías, pero la única y verdadera forma de afianzarlo es a través de mayor presencia de soluciones de este estilo y con la panacea general: el tiempo.

Por otro lado, hay que ser honestos y decir que si bien es cierto que la tecnología está mucho más avanzada que lo que se esperaría, esto sigue teniendo incompletitudes esenciales. Es muy evidente que la usabilidad de soluciones Web3 es aún mucho más pobre comparada con soluciones Web2: tanto en los tiempos de respuesta, en la experiencia de usuario, en las herramientas disponibles, y en otras situaciones misceláneas. ¿Es producto de lo mencionado anteriormente? ¿Es algo que sigue a esa línea de razonamiento, o muy por el contrario, viene primero y vaticina cual oráculo el devenir?

La misma sintonía nos lleva a otra de las lecciones aprendidas en el marco de este trabajo, que trata acerca de la posición que toman dos actores muy importantes en la vida: la realidad (los hechos), y la innovación (las perturbaciones). Notará el inventor que no puede ir en contra de la realidad; no puede cambiar el cauce del río, sino que debe acomodarse a ella y brindar su solución de valor, su veta para resolver ese problema que busca atacar.

En nuestro caso, esto se presentó como algo más que evidente ante la decisión que tomamos de retirar el esquema de subscripciones y pagos para utilizar la plataforma. La comunidad para la cual se desarrolla esta solución tiene en su naturaleza una concepción contraria sobre el uso de los recursos. Nadie utilizaría una plataforma con esas condiciones, y el proyecto caería en desuso. Por lo tanto, uno no puede quedarse y gruñir en soledad repitiendo que "la gente no entiende lo que hacemos", sino que debe darse cuenta de que es uno mismo el que va en contra del todo.

También es cierto que de esas posiciones nacen los seres e ideas más brillantes, más disruptivos y revolucionarios. Por eso mismo no hay que perder esa esencia. Sin embargo, es uno quien debe entender que las soluciones o servicios que brinda son para más personas, personas que conservan una interpretación más o menos común de la realidad y se rigen por ella. Quien falle en entender esto, es quien más chances tenga de condenarse al fracaso.

Al lograr entender esto, fue posible para nosotros delegar de forma correcta. Los miembros del equipo pudieron entender, tanto implícita como explícitamente, las distintas aptitudes, deseos, fortalezas y debilidades de cada miembro integrante. De esta forma, la delegación fue sumamente efectiva: cada uno se encargaría de realizar las tareas prevalentes en su ser. ¿La clave? Tener un equipo diverso, con aptitudes que cubran la totalidad de las necesarias para un desarrollo de software. Con estas simples ideas en orden en los cimientos de la construcción del equipo y de la idea, el desarrollo se convierte en algo prácticamente trivial; en un flujo natural que no necesitó ser forzado nunca. Uno pensaría que llover es un milagro, si no entendiera que es un proceso natural que sucede sin esfuerzo una vez que los componentes necesarios están en orden.

A notar que esto nunca se conversó entre los integrantes: fue siempre tácito. No es impresionante, más bien, es la única forma en la que podría haber sido.

Dicho esto, Cubitorium deja una enseñanza que es: el problema no es la tecnología, no son las metodologías, no son las capacitaciones, las habilidades, ni la gente. El verdadero problema que al solucionarse resuelve todo lo demás es entender la naturaleza de las cosas y el maravilloso hecho de que uno es ni más ni menos que un componente más dentro de ese sistema extremadamente complejo, en busca de un objetivo en común.