Preparándose para el Éxito: Guía de un Ingeniero de Frontend para la Diligencia Técnica

Muy bien. Antes de sumergirnos en el mundo de la due diligence tecnológica, permíteme compartir un poco sobre quién soy y mi experiencia en el ámbito de la ingeniería frontend. Y no te preocupes, planeo mantener las cosas ligeras. Un agradable cambio de ritmo de las charlas más técnicas a las que podrías estar acostumbrado durante el Día de React en Berlín. Así que empecemos. Mi nombre es Armin. A lo largo de los años, he trabajado en varios proyectos, utilizando React extensivamente, y he visto de primera mano cómo las decisiones que tomamos como ingenieros frontend pueden dar forma a la trayectoria de un producto, equipo, o incluso de toda la empresa. Así que pasemos a la imagen más grande aquí. ¿Qué nos impulsa en Tech Miners y cómo sienta las bases para nuestra charla de hoy? En Tech Miners, nuestro papel no es solo evaluar, sino guiar y elevar. Nuestro enfoque único de la due diligence tecnológica es data-driven, profundizando en procesos, personas y tecnología. Hemos ayudado a innumerables empresas a prepararse para hitos significativos, desde rondas de inversión hasta salidas. Pero toda esta charla sobre la due diligence tecnológica podría hacerte preguntarte, ¿qué es realmente? Así que vamos a desmitificar eso. Nuestra presentación de hoy está estructurada en dos segmentos principales. Primero, nos familiarizaremos con los aspectos esenciales de la due diligence tecnológica, qué es y por qué es tan importante en nuestro papel, en nuestro campo. Después de eso, profundizaremos en algunas ideas prácticas sobre cómo podemos prepararnos de manera efectiva

Así que la due diligence tecnológica no es solo una casilla para marcar. Es un examen exhaustivo que puede influir en la dirección futura de un producto o de toda la empresa. Por supuesto, por otro lado, también es bastante crítico para los inversores, los stakeholders y los posibles compradores entender la robustez técnica, la scalability, y la prueba de futuro de la tecnología que sustenta la empresa que realmente les interesa. Un robusto, digamos, TechDD implica varios pasos clave, desde comenzar con una sesión de inicio para definir los alcances y objetivos, hasta el análisis exhaustivo de la architecture técnica y la base de código. El proceso se suele extender durante unas pocas semanas para asegurar un análisis en profundidad sin interrumpir significativamente las operaciones diarias de la empresa. Las áreas que se explorarán durante un TechDD son el equipo técnico, la cultura del equipo, de los cuales estamos aquí, la scalability del producto, la pila tecnológica, por supuesto, qué frameworks están usando, lenguajes, elección de herramientas. Los activos tecnológicos, que es básicamente donde obtenemos acceso a los data, obtenemos la mayor cantidad de data posible que podemos, y procesamos para extraer algunos insights. Gestión del producto, hoja de ruta de desarrollo del producto, quizás también incluso un análisis competitivo. Y por último, la sección legal y de PI, que podría ser bastante crítica para empresas quizás en el sector de la ciberseguridad o del seguro, digamos.

El resultado de un TechDD es un informe detallado que proporciona insights sobre la salud técnica de una empresa. Identifica fortalezas, debilidades, oportunidades de mejora, y riesgos potenciales. Los hallazgos son casi el elemento más importante de cualquier informe de TechDD. En este contexto, un hallazgo se refiere a una pieza de información significativa que se ha descubierto durante el proceso de TechDD. Cada hallazgo es impulsado por data y a menudo está respaldado por ayudas visuales como gráficos para una mejor comprensión. Miran diferentes cosas, como cuán serio es un problema, o si podría resolverse fácilmente. Este enfoque, por supuesto, nos ayuda a clasificar qué problemas son importantes y cuáles no, y a detectar cualquier preocupación importante o señales de alerta. Las señales de alerta en la due diligence tecnológica son esencialmente una combinación de problemas o hallazgos que señalan problemas potencialmente graves con la estrategia tecnológica de una empresa o su implementación. Las señales de alerta no son solo algunas alertas simples. Se evalúan en función de cuán fácilmente se pueden solucionar, la cantidad de esfuerzo y recursos necesarios para abordar el problema, y la duración estimada para resolver el problema. Aunque no es, diría yo, aunque no es relativamente frecuente que cualquier empresa que se someta a un TechDD tenga una señal de alerta, tener una señal de alerta es algo de lo que definitivamente hay que preocuparse, porque podrían afectar significativamente las operaciones tecnológicas de una empresa, y por extensión, su éxito empresarial. Ahora que hemos entendido el concepto de TechDD, te preguntarás, ¿dónde encajo yo, como ingeniero de software, en esta imagen?

Vale. Y si encuentras eso, ¿cómo respondes? ¿Intentas mejorar la situación con los clientes? Quiero decir, como mencioné, la diligencia debida es altamente relativa a la empresa, ¿verdad? No es solo que obtenemos acceso a data y los analizamos. También hay muchas entrevistas, como has visto en las diapositivas del proceso. Los SDAs tendrán, tienen entrevistas en persona con ingenieros de software senior, líderes técnicos, gerentes. Así que no es solo data lo que tenemos, pero si ven algo en los data y en la base de código, definitivamente lo discutirán en las entrevistas. Y si aún no están convencidos, por supuesto algo está mal. Sí. Y mencionaste que depende mucho de la empresa, pero ¿existe alguna práctica acordada para hacer esto y cuánto difieren? Diría que no realmente, porque es un mercado de nicho, ¿verdad? Quiero decir, no esperas, depende de dónde estés trabajando, cuál es tu mercado, pero no es un mercado realmente grande y por lo tanto tampoco hay muchos grandes jugadores ahí fuera. Pero intentamos hacer lo mejor, intentamos ser los mejores, al menos en Europa. Eso es bueno, siempre apunta a ser el mejor. Y tal vez podamos pasar a algunos ejemplos prácticos. Seguro. Como, ¿tenemos una guía sobre dónde colocar la documentation, qué debería permanecer en el repositorio y qué debería ir a alguna wiki de la empresa? Diría que es lo que mejor funcione para tu equipo y, de nuevo, los data deben ser accesibles y disponibles cuando los necesites. Creo que solo con estos dos puntos, todo debería estar bien. No importa realmente qué herramientas estés usando. Por supuesto, si es una, si es una herramienta que tiene, como, no sé, una gran curva de aprendizaje y todos tus equipos no pueden seguir el ritmo, eso es un problema. Pero en general, sí.

Sobre mantenerse al día con las cosas, como deberías impulsar las cosas técnicas de TV dentro de la empresa, debería ser como un gerente de ingeniería para asegurarse de que todo se sigue o debería ser los desarrolladores individuales? ¿Y cómo educas al resto de tu empresa sobre las best practices relacionadas con eso? También puedes leer la pregunta, porque no entendí tu pregunta. ¿Podrías elaborar más sobre eso? Sí. Entonces creo que muchos de nosotros nos preguntamos, ¿quién debería impulsar esto en la empresa? ¿Debería ser un esfuerzo de base de los ingenieros? ¿Quieres decir, la persona que es el primer punto de contacto en el proceso de diligencia debida técnica? Por lo general, son los CTOs. ¿Y el CTO debería asegurarse a largo plazo de que su empresa esté preparada para eso? En realidad, depende. Como si esperan recaudar algunos fondos en su futuro. Quiero decir, basado en su situación, como mencioné, de nuevo, todo es muy relativo aquí. Por eso los chicos super experimentados viven cada TD técnico con mucho background y estando en la industria durante, ya sabes, 10 o 20 años. Pero sí, en realidad, esa es la razón. Así que es altamente relativo. Pero de nuevo, si esperan algo así, podrían estar preparados. ¿Y cuál es la mejor manera de obtener más experiencia allí? ¿Si quieres avanzar en ese camino?

Sí, de nuevo, si puedes buscar esas herramientas, hay muchas de ellas ahí fuera, puedes comparar y elegir la que se adapte a tu situación y que más se ajuste a tu empresa. Pero las cosas más famosas ahí fuera por ejemplo, dependabot tal vez es un, es un, es un bot que puedes integrar en tus flujos de trabajo de GitHub. Y simplemente verificará si tienes alguna dependencia desactualizada y simplemente creará un PR automatizado para que puedas revisarlo y fusionarlo. Haciendo las cosas mucho más fáciles, no necesitas siempre revisar todo. Y en cualquier lugar te dirá si por ejemplo, esta actualización tiene alguna corrección de alguna vulnerabilidad crítica de security o no, así que muchas buenas entradas allí. Podemos incluir otras herramientas como Sonar tal vez en tu, si ya estás al tanto de eso, en tus pipelines de desarrollo, también tiene toneladas de características, una de ellas podría ser el monitoreo. Vale, y terminemos con una última pregunta. Especialmente en la UE, la privacidad de los data es cada vez más y más importante. Y dijiste que en realidad analizas los data de las empresas en las que estás interesado. Entonces, ¿qué pueden compartir las empresas contigo? ¿Y cómo te aseguras de que esos data se utilicen solo para tu proceso? De nuevo, me gustaría mencionar que. Quiero decir, si una empresa por ejemplo, imagina un caso en el que tienes una empresa y quieres recaudar algunos fondos, recaudar fondos no es fácil, ¿verdad? Y si encuentras un VC y el VC quiere que te sometas a un Tech TD, y luego te encuentra, definitivamente te someterás a Tech TD. Así que es como, de alguna manera, la mayoría de las veces, es para lo mejor someterse

Eso suena súper interesante, pero necesitamos cerrar aquí. Pero si tienes más preguntas, puedes ir a la sesión de preguntas y respuestas con el ponente ahora. Así que por favor, vuelve de nuevo.