Enlace a la versión doblada al español
Además aquí está la transcripción completa, traducida y revisada para el Canal Cardano Castellano
Transcripción completa
Doblaje al español de “Behind the Blockchain Part V: Navigating Obstacles and Embracing Challenges”
Publicado en el canal de Youtube de IOHK el 20 de Octubre 2024
La esencia de este tipo de corrientes de trabajo en innovación, esa investigación e ingeniería se entrelazan muy estrechamente, compartimos resultados de los que estamos seguros. El artículo aún no está escrito para la conferencia académica, pero tampoco es necesario en ese momento. Obtenemos mucho de este intercambio de ideas.
Uno de los valores que tenemos actualmente en la corriente de innovación es que podemos lidiar con el fracaso también, ya que estamos bastante al comienzo del proceso, lo que significa que si uno de los resultados fuera que “no puede funcionar”, es genial, porque es mejor saber que no puede funcionar después de unos meses en Innovación en lugar de intentar encontrar algo durante años.
Todavía recuerdo cuando PERAS comenzó a ganar tracción. Fue como, ya sabes, estábamos discutiendo sobre cadenas de socios y puentes y de repente estos tiempos de finalización o liquidación volvieron a aparecer sobre nuestra mesa. Y, como de costumbre, simplemente, intentamos comprender la cuestión, la necesidad, los requisitos que recibimos, tratamos de reunir un equipo y luego comienza el verdadero trabajo de investigación, ¿verdad? Es como un cielo abierto hasta cierto punto; tenemos algunas restricciones que modelamos, pero en ese momento es una pregunta de investigación y no sabes, sabes, dónde terminarás al final. Así que hay mucha variación allí, lo cual también hace que sea difícil establecer una línea de tiempo. Algunas preguntas de investigación pueden responderse en solo un par de días y algunos resultados famosos tardaron años en establecerse.
Necesitas una idea, como para un cambio en el protocolo o un protocolo completamente nuevo, y una vez que tienes la idea, tienes que pensar si es seguro, y si piensas que es seguro, ¿podés probarlo? Así que es un proceso largo de intentar ver cómo es el panorama,
Es interesante que mencionaste la palabra “variación”, porque la variación es donde está el valor. Si estás produciendo coches, o incluso los coches hoy en día, o cepillos de dientes, todos son iguales y quieres reducir la variación. Pero si estás construyendo un ecosistema y un protocolo completamente nuevo y quieres hacerlo de una manera segura e innovadora y proporcionar valor, la variación es donde está el valor. Así que creo que no deberíamos ser tímidos al mencionar el hecho de que sí, es difícil, por lo tanto, tiene mucha variación, pero también mucho valor, porque si fuera fácil…
Creo que es exactamente ahí donde necesitamos un muy buen proceso, así que tenemos que afrontar esa variación, pero aun así tenemos que poder hacer un progreso razonable. Y con PERAS, una vez que tuvimos una solución intermedia en la que teníamos gran confianza en que funcionaría, organizamos un taller entre investigación e ingeniería para transmitir las primeras ideas.
Recuerdo el primer taller que tuvimos, como de costumbre, bajo la lluvia, no recuerdo que fuera un día soleado. Incluso corrí en el parque. Fue en Edimburgo, y en Escocia el clima cambia cada 10 minutos, así que cada día es soleado, pero también llueve. Todos nuestros talleres en Edimburgo son en noviembre, sí. Este fue en noviembre también, pero realmente recuerdo vívidamente este en el que la idea cobró forma y tuvimos esta larga discusión sobre cómo sería el proceso, si podría ser viable. Incluso recuerdo que ahí comenzamos a escribir las primeras líneas de código del prototipo, y fue donde comenzó esta corriente de innovación, donde tuvimos esta colaboración, y el artículo ni siquiera estaba escrito. Eran solo un montón de documentos de Google y teníamos todas estas ideas flotando, aún no era perfecto.
Esto es, en cierto modo, la esencia de este tipo de corrientes de trabajo en innovación, donde investigación e ingeniería se entrelazan muy estrechamente, compartimos resultados de los que estamos seguros. El artículo aún no está escrito para la conferencia académica, pero tampoco es necesario en ese momento, ¿verdad? Obtenemos mucho de este intercambio de ideas.
Así que básicamente, sí, comenzamos con el primer taller en octubre. Oficialmente, creo que comenzamos el trabajo en la corriente de innovación a principios de enero, mediados de enero o mediados de febrero, probablemente mediados de febrero.
Así que no realmente, diría que tuvimos una discusión en octubre, luego algunos ajustes, tratando de encontrar a las personas adecuadas. Recuerdo comenzar a discutir con Sandro y el resto del equipo, tuvimos una discusión sobre formalización, intentando hacer algunos experimentos pequeños a principios de diciembre. El primer informe que presenté a los interesados fue realmente a mediados de diciembre. Encontrar al equipo de prototipos, reunir a los ingenieros, tomó aproximadamente un mes y medio, y luego comenzamos a avanzar a toda velocidad a principios de febrero. Ahí fue donde el equipo se unió y tuvimos los primeros resultados a finales de febrero con el prototipo y la simulación completa. Recuerdo que fue aproximadamente en esa época cuando hubo una nueva versión del protocolo que ocurrió en marzo, porque había una cuestión relacionada con los certificados, los bloques y los votos, que serían demasiado pesados para mover junto con los bloques.
En realidad fue una historia divertida. En algún momento, hubo una razón que nos hizo pensar que era necesario hacer algo de una manera específica, y a veces pasa en la investigación que tomas una decisión, luego otras decisiones, pero después notas que una de las decisiones iniciales te das cuenta de que ahora puedes hacerlo de manera diferente. Así es como descubrimos una simplificación para el protocolo que facilitó mucho su implementación.
Podríamos llamar a esto un refinamiento en una etapa temprana, ¿verdad? Quiero decir, simplificó el protocolo tanto en teoría como en práctica.
Porque recuerdo que la primera versión era realmente más complicada, y además, más pesada porque había más cosas que mover. Luego, creo que una buena marca fue el taller que tuvimos en abril; fue algo donde creo que muchas cosas encajaron juntas. Fue un gran taller, con muchos resultados, y allí finalizamos los informes técnicos, abordando muchas preguntas, y al final eso no fue demasiado. Creo que fue donde la eficiencia realmente se manifestó.
Cuando hablamos de innovación, me gusta pensar en esta especie de proceso de alta variabilidad al inicio, que es la investigación pura, donde hay muchas ideas y oscilaciones armónicas que pueden variar. Luego, tienes la innovación que llega en algún momento y dice: “Bien, vamos a amortiguar estas oscilaciones”, tratando de reducir las armónicas hasta llegar a algo mucho más regular. A veces no podés, hasta ahora, no hemos tenido ninguna señal de alerta, así que sabemos que, al menos para Peras, podemos continuar. En última instancia, queremos obtener algo que sea regular y muy fluido, como una sinusoide, que pueda ser implementado por cualquier dispositivo. Este es solo el comienzo.
Creo que Peras es un buen ejemplo de una corriente de innovación exitosa porque hemos tenido algunos ajustes y revisiones de detalles, pero, como mencionaste, no hubo ninguna señal de alerta que indicara que tuviéramos que detenernos porque no funcionaría en la implementación debido a ello, desafortunadamente no hay forma de darle la vuelta y tenemos que retroceder para pensar en una idea totalmente diferente. Esto ha sido muy exitoso en ese sentido.Aún así, creo que uno de los valores actuales de nuestra corriente de innovación es que también podemos lidiar con el fracaso, ya que estamos en una etapa bastante temprana del proceso. Esto significa que, si el resultado fuera que no se puede hacer, es genial, porque es mejor saberlo después de unos meses en innovación en lugar de pasar años buscando una solución.
En otras ciencias, esto también se valora mucho: documentar el fracaso para que nadie más intente algo similar o para que otros puedan ver lo que intentaste hacer, y tal vez alguien encuentre una razón por la cual tu enfoque no funcionó, o bien, una modificación que lo haga viable. Ser transparente e informar sobre cosas que no funcionan es igualmente importante.
Creo que es una de las razones por las que intentamos trabajar de esta manera. Trabajar de esta forma es una mejora porque, primero, minimiza el impacto del fracaso, y segundo, estamos intentando hacerlo de forma aislada del equipo de producción, es decir, de quienes implementarán la solución. Esto significa que, ya sea que tenga éxito o fracase, no los afecta directamente en su trabajo diario. Impactará su trabajo futuro si tenemos éxito porque tendrán algo nuevo para implementar, pero si no tiene éxito, no hay disrupción en ese trabajo. Estamos trabajando en aislamiento. Estuve a punto de decir en total aislamiento, pero no es el caso, porque obviamente estamos hablando con las personas que son los posibles implementadores de la solución. Sin embargo, estamos lo suficientemente aislados como para que lo que hacemos no impacte en sus tareas diarias, no afecta lo que tienen que hacer a diario, ya que no deberían fijarse en lo que hace la Innovación para decidir qué deben hacer en su trabajo diario. Esta clara distinción es una mejora importante.
Creo yo; se trata del impacto del cambio y de la capacidad de adaptarse al cambio desde el principio del proceso. Peras quizás cambió dos o tres veces ya.
Dá la impresión de que fue muy fácil hacer estos cambios más al inicio.
Personalmente, me ha interesado durante varios años. Y no estoy hablando de Jira o del ágil que conocemos, que es un proceso muy rígido, sino más bien de fallar rápido. Creo que mucha gente enfrenta lo ágil contra la formalidad o ágil enl rigor, diciendo “cuando haces ágil, puedes hacer lo que quieras”. No es así en realidad; tiene que ser muy riguroso, porque necesitas saber cuándo fallas lo antes posible.
Exacto, es saber cuándo tenés que ajustar tu rumbo, y muy temprano.
Es un proceso muy orientado a la experimentación. También es algo que intentamos hacer de forma diferente en comparación con cómo trabajábamos antes. Tratamos de hacer experimentos para comprobar cosas, queremos hacer X, queremos verificar si , doy el ejemplo del tiempo, ver si podemos mover votos lo suficientemente rápido. Entonces hacemos un experimento para probarlo, y este nos da resultados, sí o no, y tenemos más respuestas y preguntas. Antes, en mi experiencia, no éramos tan buenos en esto.
Por lo que necesitamos un buen proceso, uno que se refine.
Quizás Hydra fue un buen ejemplo, porque también trabajamos en eso juntos, ¿verdad, Sandro? La forma en que la implementación del trabajo de investigación se realizaba era diferente.
Escribíamos un artículo de investigación en algún momento, y luego, después de unos meses, pasábamos a otros proyectos, y luego comenzaba la implementación.
Es difícil volver a algo que pensabas que estaba terminado, y luego tienes que releerlo y ver qué pensabas en ese momento para responder las preguntas que pueda tener el equipo de ingeniería. En contraste con lo que hacemos ahora, era mucho más difícil porque estamos todos en el mismo tema constantemente, y cuando hay una pregunta, diez segundos para escribir una respuesta, lo que hace todo mucho más fácil.
Recuerdo que también estuve involucrado en Hydra hace unos tres años y medio, y fue interesante tomar ese artículo y trabajar con él. Creo que uno de los principales problemas fue que nos desviamos del protocolo descrito en el artículo, y significó que, uno o dos años después, cuando queríamos formalizar una especificación, tuvimos que hacer ingeniería inversa de todo el trabajo de implementación con un documento de investigación del que nos habíamos desviado. Sin embargo, en Peras, mi esperanza es que una vez que tengamos la especificación CIP, que sea lo más fiel posible al artículo de investigación, porque el artículo se creó como parte del mismo proceso. Esto no significa que la especificación y el protocolo no cambiarán, porque lo harán, pero tendremos las herramientas para reflexionar también sobre la investigación. Esa es la retroalimentación que me gustaría lograr.