Bienvenido a un episodio con Henoc Díaz, antes CTO y ahora Sr. Software Engineer en Apli, una SaaS de reclutamiento y retención de talento Latinoamericana que opera en más de 6 países.
Comparte
Si solo tienes un minuto, lo más importante que pueden aprender operadores, inversionistas y fundadores de Apli es lo siguiente:
Artemio: Hola ¿Qué tal? Bienvenidos a todos a una edición más de Cuando el Río Suena, el podcast que está hecho para todas las personas que están construyendo algo donde antes no había nada, o mejor dicho, en palabras más sencillas, para todos aquellos que se encuentran en esta carrera tan emocionante que es construir un negocio saludable de Internet.
El día de hoy me acompaña mi socio Rodrigo Salmerón ¿Cómo estás Ro?
Rodrigo: ¿Qué tal? Muy bien.
Artemio: Primer capítulo en el que traigo gorra, quiero hacer énfasis para que vayan a verla, es una muy linda. Siempre por alguna razón, creía que por temas de formalidad, no podía permitirme tener una gorra, pero rompí esa regla con un gorrito, no una gorra perse, cuando estaba yo en Mérida y dije “Ya no más ¿Cómo es posible que lleve 100 capítulos y todavía tenga pena de cosas?.
El día de hoy nos acompaña, no te preguntamos desde dónde estás conectado, pero nos acompaña Henoc Díaz de Apli, ¿Cómo estás?
Henoc: Hola ¿Qué tal? ¿Cómo están? Estoy en Toluca, Estado de México, yo soy originario de acá, viví un tiempo en Ciudad de México, pero pandemia y ya saben, pasan cosas.
Artemio: Buenísimo, muy cerca de Metepec y casa de un equipo de fútbol americano, los borregos, que da miedo la verdad, ojalá nunca tengan que jugar contra ellos si están en ese deporte porque son bastante bravos.
Artemio: Henoc, cuando te invitamos, tú tenías el puesto de CTO en Apli, nos contactas la semana pasada para decirnos que pasas a hacer Sr Software Engineer, pero de igual forma creemos que tenemos muchas preguntas que pueden darle muchísimo valor, no solo a los emprendedores que nos escuchan, sino también a los perfiles que son más técnicos, así que para arrancar todos en la misma página, ¿Podrías contarnos cuál es el pitch de elevador de Apli? ¿Qué es lo que hacen ahí?
Henoc: Claro, Apli se fundó hace seis, siete años si no mal recuerdo, originalmente estaba en una vertical completamente distinta de marketplace, una cosa rara, pero desde hace algunos cuatro o cinco años hicimos un pivot y lo que hacemos ahora es construir las soluciones de software, particularmente software service, enfocados en el segmento enterprise, este software service o nuestros productos, están enfocados principalmente en optimizar los procesos de selección y retención del talento de nuestras grandes corporaciones. Puntualmente, utilizamos de cara hacia los candidatos o hacia los colaboradores de las compañías, interfaces conversacionales que últimamente están mucho más de moda con el tema de Chat GPT. Desde hace algunos años, a través de estos chatbots, los candidatos pueden ser perfilados para la vacante, pueden saber más de la compañía, llevar su proceso de selección y que sea viable a través de los chatbots porque hay ciertas entrevistas que tienen que suceder en el mundo físico, como pruebas de manejo y pruebas médicas, pero en la medida de lo posible, todo el proceso se lleva a través de fases conversacionales, las cuales son Messenger, WhatsApp y estamos por lanzar en nuestro propio chat basado web para que no tengamos esta dependencia hacia Meta como compañía.
Lo que estamos haciendo, es que buscamos consolidarnos como esta súper app para el tema de gestión de talento en todo este espectro, desde la selección hacia también la gestión del talento que ya se cuenta con temas de onboarding, de training, capacitación y encuestas.
Operamos ya en varios países como Latinoámerica, México, Colombia, Perú y otros países de Latinoamérica y con algunos clientes en Estados Unidos, estamos un poquito extendidos ya.
Artemio: No sé por qué yo tenía la impresión de que se enfocan únicamente en talento técnico, pero es verdad que ningún lado de su sitio web dice que solo desarrolladores o cosas como de este tipo. ¿O sí?
Henoc: No, bueno sí tenemos por ahí algunos clientes que sí buscan programadores, pero realmente está más enfocado en personal imperativo, personal de gestión de empresa, temas de ventas, cosas por el estilo, entonces realmente no es tanto hacia perfiles tech, sino es hacia otros perfiles que tienen un alto índice de rotación y también son contrataciones masivas de una gran mayoría de casos.
Rodrigo: Entiendo, ya con eso tenemos una buena radiografía de cómo funciona Apli y ahora, normalmente hacemos esta pregunta hacia los líderes operativos o fundadores pero esto también va a ser muy interesante para quien nos escucha, tanto para los perfiles técnicos que participan no en puestos directivos, como para las personas que tienen perfiles directivos y quieren saber cómo describen su día a día las personas que no están en los perfiles directivos. Entonces la pregunta es ¿cómo es tu posición como Sr Software Engineer en Apli? ¿Cómo luce el día a día en tu vida ahora que cambiaste ya de rol? No sé, si ya acabaste la transición pero nos encantaría que nos hablaras desde ese punto de vista ahora que estás a mitad del camino.
Henoc: Sí, justo a medio camino, de hecho te puedo dar como las respuestas a las 3 etapas. Cuando yo entré, era un equipo chiquito, de 5 personas, después de un año me convirtió en CTO y con el mismo equipo chiquito, entonces que incluso mi evolución de CTO fue bastante gradual, como que al principio eran bastantes contribuciones individuales, pero ya al final eran más la gestión de los proveedores, temas estratégicos, temas de people management como one of ones, hablar con el y la CEO, con personas de producto, tenía un ingeniero o software engineer manager a mi cargo, entonces igual era llevar temas con él, de cómo iban en los equipos; al ser un equipo pequeño, también me tocaba, muy esporádicamente hacer head contributions, incluso ya al final. Mi tiempo se dividía en temas de puro management, temas estratégicos y también temas de supervisión de la parte técnica como a alto nivel de más arquitectura, temas de seguridad e infraestructura y ese tipo de cosas.
Ahora, puesto que estamos en esta transición o hace un par de semanas que estamos en esa transición, lo que estamos haciendo es hacer un especie de inventario de cuáles son mis actividades o cuáles eran mis actividades como CTO para que eventualmente contratemos a más personas, para que estas responsabilidades se vayan pasando; adicional a eso también, como estuve desde el inicio en muchas cuentas que controlo yo, eso también hacer un mapeo de todas esas cosas de las cuales yo soy el administrador para que pase a otras personas.
La parte más importante es hacer la transición o el hand of de las personas a las cuales se han dejado, porque al final es gracias a esas personas que pues la compañía de opera, no solo soy yo, para esas personas lo que estamos haciendo son archivos con un perfil cierto modo, cuáles son sus intereses, perspectivas de más personas, en qué proyecto han estado, en cuáles áreas han estado, cómo han crecido, es cómo un archivo de esta persona moderno, en Notion, muy padre y ordenado.
Es tener sesiones con esta persona que va a llevar el equipo de ingeniería, para ver qué puntos se deja la compañía, cuáles son los problemas que tenemos ahora, cuáles son los problemas que veo hacia el futuro, un poco todo este tema de la transición hacia mi rol ya como software engineer y también un poco inspirado en cómo veo a mis compañeras y compañeros que también son seniors dentro del equipo y lo que se va a su tiempo.
Sigo viendo temas de one to one, pero ya en modo de mentoring, de ayudar a las personas a crecer a sus skills técnicos en cómo llevar su carrera y más, es lo mismo que es como manager, pero sin la formalidad de ser manager.
Artemio: Entre compas.
Henoc: Exacto entre compas y es más informal, también es un poco eso.
De ahí en fuera temas mucho más técnicos, como el tema de el diseño de propuestas que tienen que pasar la revisión con otras personas del equipo, revisiones también de código, revisiones de propuestas que son hechas por otras personas dentro del equipo de ingeniería, implementación de los proyectos. Adicional a eso tenemos un programa de On call. También unas cuantas semanas nos toca estar en esta rotación de On call, que solo son durante las horas de negocio entre las 9:00 y 6:00 de la mañana.
Artemio: ¿Qué es on call? ¿De qué me hablas? ¿Cómo se come esto? Nunca había escuchado ese término.
Henoc: Claro, la parte de On call va enfocada a que alguien esté pendiente de que toda la infraestructura, toda la parte de seguridad, toda la parte de visibilidad de las bases, plataforma que implemente como basada en cloud, hay muchas cosas que hay que estar al pendiente, generalmente el rol se trata de que estén alertas y atentos a las alarmas que llegan a poderse generar de la infraestructura, por ejemplo, si de repente tenemos un volumen de peticiones que normalmente no estamos preparados para manejar, pues que los vayan a atender, si hay picos en las bases de datos que también los revisen, entonces es tener a alguien cuya prioridad esa semana no es construir producto, no es arreglar cosas sino estar pendiente de lo que ya funciona, siga funcionando, si algo se rompe, que siga funcionando. Realmente es un programa, si preventivo, porque también tenemos ciertas tareas que van orientadas a mejorar el proceso de gestión de la infraestructura pero también reactivo, pero de igual forma rápido. Entonces tenemos esta cosa perdure duty, cuando algo se rompe, pequeño o grande, llama por teléfono, nos manda un mensaje, nos escribe por slack, nos busca por todos lados, entonces el tiempo de reacción hacia uno se siente mucho mejor, eso es a grandes rasgos, la parte de esta rotación de on call.
Artemio: Tengo un par de preguntas, mencionas muy buenas prácticas en cuanto a desarrollo que se asoman justo por todo lo que nos cuentas. Hay un par que me llaman la atención y que me encantaría como ondar un poco en ellas.
Henoc: Claro.
Artemio: La primera es la revisión de código. ¿Esto lo hacen antes de mandar algo a producción?, es decir, ¿Un desarrollador hace un código, después lo revisa él, me imagino después lo revisa el pier y después se manda producción? Cuéntanos un poquito cómo manejan esa parte ustedes y la otra… ¿Sabes qué? Arráncate porque se me fue la onda entonces igual y me acuerdo en lo que nos compartes.
Henoc: Sí, esa parte de revisión de código, detrás de todo esto hay un ciclo de desarrollo de software seguro, en general, son buenas prácticas, pero aparte de que consideramos que son buenas prácticas y que en el equipo optemos por este tipo de prácticas también contamos con la certificación de ISO 27001, entonces eso ya es una obligación, ya no es un “Quiere seguir unas prácticas” no, ya estamos obligados y justo un poco lo que va hacia esta parte de revisión de código es un poco el enfoque no solo de temas de performance, no sólo de temas de que el código sea mantenible, como este tipo de cosas, temas de seguridad, entonces, un poco cómo sucede este proceso es, la programadora o el programador lo desarrolla en su computadora, ve que funciona, escribe los test que hagan falta, sube su código al control de versiones que en nuestro caso utilizamos givehop y de ahí depende del proyecto y depende de la metodología que se está utilizando. Si están utilizando el tema de staying y producción o se está utilizando directamente producción tiene que haber SPR, apuntando hacia una de las dos ramas en la producción y ahí el equipo empieza a revisar la parte de código, pero esa es como la parte, de cierto modo final, antes de eso, antes de hacer una contribución generalmente tiende a ser parte de un proyecto más grande, ese proyecto, tiene que estar previamente planeado, previamente revisado, para que la parte de revisar la pequeña contribución, sea más enfocada hacia el código, hacia la mantenibilidad, la seguridad de implementación, pero toda la revisión del problema más grande ya debió haber sucedido.
Artemio: La segunda, sí me acordé. Al momento de que se levanta un bug, un problema, algo bloqueante que tiene que resolverse ¿Quién lo resuelve? ¿Quien hizo el código en un inicio? ¿Lo hace un equipo de soporte? ¿Cómo funciona cuando cuando se rompe algo?
Henoc: Acá la cultura que tenemos es más que el equipo es dueño de la solución.
Artemio: Genial. Son de los míos.
Henoc: No es la persona que lo consiguió, porque eso nos va a generar en el futuro un problema de si sólo está persona está resolviendo todo lo que tiene que ver esta funcionalidad, el día que esta persona ya no esté, nadie va a saber qué se tiene que resolver.
Artemio: Ya, entiendo.
Henoc: Es más como “el equipo que es dueño de esa parte del sistema, son los que tienen que atender”.
Artemio: Como la escuadra a cargo del problema de negocio que atiende la escuadra ¿no?
Rodrigo: Nos estamos un poco alejando guión, pero creo que es importante porque es la oportunidad que nos brinda tu cambio de rol. ¿Cuál dirías Henoc que es la parte más complicada de todo este proceso, digamos de migración, de rol? Porque mencionaste cosas muy importantes, tú conoces a todas las personas de tu equipo como nadie, porque tu tienes esa conexión directa con todo mundo que estás manejando y ceder esa conexión, porque no solamente sea el equipo, no sabes nada más el know how, sino que cedes la dinámica personal, pero sí por lo menos todos esos tags, los one to one, los insights que tienes de cada uno hace, muy diciendo “este es el que responde más rápido para este tipo de cosas.” “Ese es el que es muy bueno haciendo esto, pero cuando le mandas problemas de este tipo, puede ser que se tarde más”, ese tipo de keys de manager que al final es lo que hace al gran manager. El gran manager es el que tiene un gran conocimiento de los específicos de cada uno de los miembros de su equipo, ahora nos comentas que los que estamos migrando a una base de datos muy específica, todos estos trades todo esto de forma que se puedan heredar, pero ¿cuál dirías tú qué es la parte más complicada? no donde más has batallado perse, ni la más laboriosa, sino dónde piensas “aquí sí se hace algo mal, el impacto puede ser mayor”.
Henoc: Al final creo que cualquier persona que llegue a manejar el equipo o la persona que ya va llegando el equipo y es lo que también platicábamos con el equipo cuando les avisamos a esta transición y este cambio de rol, etcétera, creo que al final la parte más difícil, es el apego hacia el equipo, porque les conozco y también es otra sesión de ahora, como un peer de ellos y tener esta confianza, confiar, porque tenemos que hacer las cosas un poco a ciegas, con la persona que llega, te va a traer metodologías y distintas maneras de trabajar, pero que al final están bien. Entonces yo creo que la parte más difícil es creo que a nivel personal, como es incertidumbre y el futuro, porque es más la parte de “ya traería yo una manera de trabajar, traía yo una manera de dinámica con el equipo” y como ese tipo de cosas, ahora no sé qué va a pasar y esta persona obviamente busca iniciar con la misma dinámica para no hacer cambios abruptos, eso está súper padre, pero aún así sigue habiendo cierta incertidumbre hacia el futuro; no sé si haya algo que si se hace mal se puede romper porque no estoy seguro que se vaya a hacer mal, posiblemente sea una manera distinta de hacerlo pero con un alcance distinto y hasta nos beneficie ¿no? Entonces creo que la parte más que difícil es el nivel personal, ya sea este cambio de rol y está sensación a la industria de dejar al equipo, pero al mismo tiempo no lo estoy dejando porque se dio con ellos, solo que ahora con un rol distinto.
Artemio: Bien lo decía el CTO de Cobre, José Donato “Cuando se trata de tecnología muy difícilmente el problema es uno técnico, casi siempre deriva de las personas, sus relaciones y las burocracias que se inventan entre ellas.”
Artemio: Leímos por ahí en tu LinkedIn que comenzaste a programar desde la era de myspace, fue tu primer coqueteo con todo este ecosistema, mucho ha cambiado desde entonces, en materia de que las cosas se han acelerado, de que los frameworks hoy son otros, el lenguaje sexy también es otro, los estándares incluso ya son otros. ¿Qué consejos podrías darle a otros programadores, y tal vez líderes de programación, para no quedarse atrás en materia de tendencias, lenguajes, frameworks? Sé que todo comienza, por siempre querer aprender más y no quedarse atrás, haciéndote un ejemplo, vivo de esto, tal vez viendo en retrospectiva ¿Qué trades o qué cosas de tu persona crees que otra gente podría replicar para no quedarse atrás?
Henoc: La parte que decías de aprender, pero más fundamentalmente la parte de ser curiosos y ser dubitativos, al grado de ser realmente pensar ¿Esta es la manera la mejor manera o hay otra manera de hacerlo? Y creo que esa cuestión, ese cuestionamiento, siempre te va a llevar a tener que buscar alternativas, se conecta con la parte de curiosidad en el sentido de ir a buscar líderes de opinión o ir a buscarnos newsletter o ir a buscar fuentes de información que te ayudan a encontrar alternativas de cómo hacer las cosas, de tener a distintas opiniones y distintos puntos de vista para entonces forjar tu propio punto de vista y tu propia solución para el problema que tienes en frente.
Creo que en términos generales, es la curiosidad y de cuestionar, digo tampoco cuestionar absolutamente todo y a todo encontrarle un porqué, debe de haber un límite claro; pero sí como esta parte de curiosidad y como más accionable, por ejemplos, algo que no he dejado de hacer en los últimos 10, 11 años es seguir Hacker News , por ejemplo, es una manera normal o natural de mantener la curiosidad porque no tienes que forzar, no necesitas un problema en frente para ser el curioso, no solo por resolver, sino que simplemente ver qué hay de nuevo aunque no lo vayas a usar, te lleva o te conectas y te empiezas a hacer una red de información y opinión, porque Hacker News nuevamente me lleva seguir ciertas personas en Twitter y esas personas me llevan a recomendación libros de sugerencias de otras personas y de otros libros; armar esta red de conocimiento o de fuente de conocimiento es algo que te va a mantener a la vanguardia, porque al final todas las tecnologías que usamos son sólo herramientas, son temporales, por ejemplo, lo que pensabas de myspace, igual las redes sociales cambiaron, por ejemplo Facebook está también por cambiar. Entonces todo tiene como un final y nos tenemos que adaptar.
Creo que aparte de curiosidad, la parte de adaptabilidad, no casarse con algo, no sólo en tecnología, sino plataformas, metodologías.
Artemio: Claro, en todo. Creo que un gran ejercicio que pueden hacer todos los fundadores que están acá y de hecho cualquier persona en cualquier rol de una startup es preguntarse ¿Con qué servicio o con qué acercamiento podrían ustedes matar a la actual startup en la que están trabajando? Y por rudo que esto pueda parecer, o por pesimistas, es un ejercicio súper sano, porque de verdad encuentras muchísimas debilidades en lo que estás haciendo y particularmente después puedes encontrar muchas oportunidades, esto es algo que a mí me pasa, personalmente, con nuestro estudio, que hacemos productos digitales aquí en Acueducto, a mí siempre me ha molestado o no molestado, pero una barrera que encuentro ahí muy alta, que es la técnica para poder hacer software, es una que me inquieta mucho, particularmente porque yo no vengo de un perfil técnico, vengo con un perfil como de know code curioso, es decir, juguetee mucho con Wordpress cuando iba en la preparatoria y como que ahí empecé un online business y una cosa llevó a la otra y hoy estamos acá, particularmente esta jaqueca que es el poder llevar una idea de cero a uno, he pensado que quien quite esa barrera, ¡Invento sagrado que va a ser!, esto es muy interesante porque herramientas como Notion hacen que la lógica de software sea mucho más accesible para las personas sin necesariamente tener que estar haciendo coding, o ahora como todo el tema de los modelos de lenguaje, de inteligencia artificial, este tema de Chat GPT que incluso te puede arrojar código y aunque pues todavía luego te arroja código bobo o no tan complejo por así decirlo, o desactualizado incluso para lo que hoy es la punta de lanza, por pura lógica y progreso, sabes dónde va a estar esa tecnología en 10 años y dices como “Güey, es que este tipo de cosas son las que pueden tumbar una empresa de desarrollo de software y hacer una compañía, que entonces tenía 25 colaboradores, ser una de 3 personas con mucha idea”
Yo creo que es picarle a eso, es en cuanto ves que esté el Chat GPT, pues ve y chatea con esa cosa y ve de qué se trata, o lee un paper de la experiencia de alguien; justo eso que mencionas de Hacker News o de estar involucrado en comunidades de gente que también está construyendo cosas, yo creo que ahí le diste en el clavo porque no hay nada que te mantenga tan en la conversación de lo que está pasando, pues que alguien más lo agarre y lo aplique, y en 3 días ponga ahí un post muy clickbaitero de “Miren, cómo 100,000 USD en 12 horas con Notion” o lo que sea.
Henoc: De la pregunta que mencionabas, siempre va a haber una manera mejor de hacer las cosas, con el paso del tiempo y vemos hacia atrás, en la historia siempre como humanos estamos buscando hacer mejor las cosas por naturaleza, en toda la historia que tenemos, si vemos hacia atrás sólo hemos hecho las cosas de cierto modo, menos óptimas o algo por el estilo y comprobando, buscamos optimizar todo, siempre hacia adelante, en lo que estamos haciendo ahora, siempre habrá una mejor manera de hacer lo que estamos haciendo.
Artemio: 100% y eso es un principio de ingeniería, con el menor input tratar de sacar el mayor output, también es un principio de microeconomía, con los menores recursos posibles, tratar de sacar el mayor provecho. Realmente creo yo que esa es la fuerza que empuja el progreso constante en nuestra sociedad, esta hambre constante que tenemos por estar más cómodos, incluso a nivel fundamental humano.
Hay una historia clásica de Robinson Crusoe, este güey que se queda varado en una isla y nada más está él y unos aborígenes que se lo quieren comer, leones y fieras de la naturaleza, su tendencia es, primero es buscar un lugar dónde dormir, pero conforme va avanzando, se hace una mesa dónde comer, una silla, una hamaca, comienza a tener un taller de herramientas y poco a poco va optimizando su vida, según su entorno; entonces esto habla de que también a nivel fundamental humano, si tuviéramos que partir una vez más desde cero, ahí está en nuestra naturaleza el querer hacer la vida más fácil.
Artemio: Vámonos al corte de este programa, le recuerdo toda la gente que nos está escuchando, que en cuandoelriosuena.com ustedes pueden suscribirse a la newsletter de este programa y recibir una notificación cada que tengamos un capítulo nuevo disponible para ustedes, todos los lunes de manera religiosa. Yo creo que me guardo el resto de los anuncios para el final del programa, así que vámonos.
Rodrigo: ¿Qué tal? Estamos de vuelta en esta edición de Cuando el Río Suena, con nuestro invitado Henoc Díaz de Apli. Esta es una pregunta que hemos hecho a todos los perfiles técnicos que han pisado este podcast, casi todos se ríen después de que la hacemos, pero no por eso deja de ser una pregunta importante, sobre todo porque ya tenemos varias respuestas que cuando las cruzamos todas llegamos a varias conclusiones ahí, unas por repetición y otras por diferencia. Cuéntanos la guía fundamental, según tu experiencia en ¿Cuál es tu forma de hacerlo para que las estimaciones no sean una pesadilla en un equipo de desarrollo?
Henoc: Bueno, me voy a ir al club de las personas que se ríen después de la pregunta, porque yo creo que es la pregunta del millón de dólares.
Una manera de reducir el dolor que se sufre al hacer estimaciones es tener proceso, pero no un proceso de ceremonias de todos levantan la mano, sino más bien un proceso que te lleve a entender realmente el contexto y los posibles, aunque tengo como pre problemas, el problema que quiere resolver. Va mucho de la mano con el negocio también, si tienes un proyecto que quieres hacer, primero empieza por definir realmente cuál es tu problema, qué es lo que quieres solucionar, qué es lo que quieres hacer, que eso esté alineado con las personas de producto o con negocio en general, que esté como en alto nivel, que esté bastante claro, de ahí justo está el famoso software development lifecycle, donde pasas por la parte de arquitectura, en la parte de arquitectura creo que es una parte importante porque ahí es donde a alto nivel, después de que ya tienes este problema definido, dices “Okay, esto es lo que tenemos que hacer”, tal vez estos sets points, este nuevo servicio, este nuevo lo que sea, técnicamente hablando, pero ahora ya puramente técnico, revisar con el equipo o con tu peers qué opinan de esto, qué problemas le podrían ver, etcétera; ya que es “Bueno, vamos con esto, ya que todos acordamos avanzar con esto”, bajarlo todavía más a cuáles son detalles más puntuales, no a nivel de “Tengo que cambiar esta línea de código”, tampoco tan abajo, pero si en “Vamos a necesitar implementar este end point, pero este end point, detrás de end point, tal vez haya una arquitectura de las hexagonales, hay capas dentro de tu desarrollo dentro de tu software” Es decir, qué cosas tienes que hacer en esas capas, como agregar nuevo servicio o agregar método, lo que sea, con ello ya vas desmenuzando y aterrizando un poco las tareas. Hasta este punto es cuando dices “OK, ya va a tomar esto, equis tiempo y haces la estimación” pero, no solo te enfoques en la parte de “Ah, es este end point, este método” sino cuáles son estos pre problemas que podrían surgir o que podrías tener para implementarlos, como, por ejemplo, “Ok, si necesitamos un one point, pero se va a comunicar con un servicio, ya existe la cuenta en dónde la vamos a tener o no existe, necesito credenciales o qué necesito”, empezar a identificar otros problemas, no el problema principal porque así pasa, si no realmente ¿Qué otras cosas alrededor de tu problema principal te podrías encontrar?.
Algo que justo está pasando en esa transición que estoy teniendo, es la parte de testing que si no la haces, esto no es importante, pero la parte de testing muchas veces tiende a tomar más tiempo que en la solución del problema en sí, y es algo que tendemos a subestimar.
Muchas veces las estimaciones son simplemente “Ah, pues es una API, ¿Cuánto puede tomar? o este nuevo servicio, ¿Cuánto puede tomar?, seguramente los test van a estar fáciles”, tendemos a obviar muchas cosas alrededor de lo que queremos implementar y en mi opinión eso es lo que termina como pegando a que subestimas lo que te va a tomar por no haber volteado alrededor del problema, es decir, “Ah, esto no lo tengo que solucionar, y esto ¿cuánto tiempo le va a agregar a la estimación?” sin embargo, creo que llegas a eso llegando a un proceso que poco a poco vas bajando el nivel de la especificación, creo que eso ayuda.
Aparte creo que otros beneficios de este proceso ya no es solo la parte de estimación, tiene también que el hecho de ponerlo por escrito y el hecho de platicarlo con otras personas y que esas personas te den sus puntos de vista, te ayudan a ir calibrando el entendimiento de lo que tienes que hacer, si está bien, si está mal, si es mucho tiempo, si es poco tiempo, distintos puntos en cuanto a experiencia y aparte de eso, algo que sucede mucho en las startups o al menos no sé si en todas, pero en Apli nos llegó a pasar, todo el tema este de documentación, si yo volteo a 5 años para atrás, hay otras cosas digo ¿Por qué decimos esto así?, ¿Por qué no nos tomamos cierto tiempo para documentarlo?. También te ayuda a reducir el tiempo de implementación, porque ya todo está mucho más claro, mucho más aterrizado y el tiempo de los calls reviews también porque ya hubo un consenso para el equipo, ya saben de la arquitectura que están solucionando, ya hiciste muchos pasos antes que te ayudan a reducir objeciones sobre el final.
Hablando de estimaciones, acá nos llega a pasar muchas veces de que no nos va a tomar más de 2 días por alguna cosa, pero por no llevar este proceso, cuando llegamos a la parte de calls reviews es de “¿Por qué no lo hacemos así? o ¿Por qué no le damos la vuelta por acá?” entonces se retrasaba todo el proceso de calls reviews por hacerlo al revés, por llegar a las solución y después de que tenemos la solución juzgar a la solución o pensarnos si no hay una manera diferente de hacer las cosas, creo que es hacer un poco las cosas de manera rápida, bajando el nivel de abstracción, pero también de este alto nivel de producto e irlo bajando hacia la parte más técnica y hasta ese punto de decir “Nos va a tomar tanto tiempo”. Eso te puede ayudar bastante con la parte de ser más precisos porque al final las buenas cosas toman tiempo, hay 2 maneras de partir, ¿Cuánto tiempo tengo? o ¿Qué es lo que necesito?, después de qué es lo que necesito, ¿Cuánto tiempo va a tomar?
Artemio: Asignar el tiempo.
Henoc: Y creo que muchas veces tendemos a hacer una mezcla rara.
Rodrigo: Esta forma de combatir la incertidumbre de la estimación que nos cuentas, yo creo que es la que de las respuestas que hemos recibido aquí, en el podcast, la que más se parece a cómo trabajamos nosotros internamente en el estudio, al principio estábamos negado rotundamente a ¿Pero cómo le vamos a poner más capas de complejidad a este proceso que ya es complejo?, que ya tiene un montón de requerimientos, que ya tiene un montón de procesos de encima y el hecho de que ahora por cada ticket digamos que levantamos ya sea un incremento o un bug, un pequeño fix, incluso algo de soporte inmediato, que tenemos que resolver en la próxima media hora porque el sistema está abajo, entre más tiempo nos tomamos de redactar bien el problema, vamos, tenemos ahí varias varios trucos, por ejemplo, “Yo siendo este usuario, queriendo conseguir esto” creo luego suena como las historias para niños porque es un tipo de redacción, luego yo me siento ahí muy bobo, redactándolo así, pero claro, la persona siente que lo lee, entiende exactamente lo mismo que yo y la que sigue exactamente igual y el QA lo mismo, quien hace el code review igual; en nuestro caso que convivimos con clientes también luego un cliente le llama la atención a algo que ve transcurrir por el backload, y al abrirlo entiende perfectamente lo que está pasando.
Entonces logramos también eficientar la comunicación que tiene que haber entre miembros del equipo y reducirlo a, pues casi siempre al ticket. Eso creo que es fenomenal tanto para la estimada como mencionas, para la comunicación entre el equipo, para cómo aprovechamos mejor el tiempo y los recursos que tiene cada quien, a mí me encantaría aplaudir que esta es la tuya, igual, aplausos, producción aquí, metan aplausos, por favor.
Henoc: Incluso si tienes un tiempo estimado alto, pero tienes documentado el por qué, es decir “Ah ok, si tiene sentido que vaya a tomar tanto.” Por lo tanto, si no se ve tan difícil de una manera superficial, es decir “Ah, mira, esto lo tenemos que hacer, no nada más es la agrego botones, detrás de eso hay todo un proceso de conectar con x cosa, y esa es la razón por la cual está tomando tanto tiempo”.
Artemio: Claro, sí. Me imaginé ahí perfecto a uno de nuestros clientes que tenía como mucho expertiz en Excel, era de “¿Cómo? si solo estamos jalando este punto de data y lo vamos a poner ahí” y era “O sea sí, pero no sabes todo lo que implica hermano, esto es un requerimiento un poco más complejo de lo que tú crees.” Es ahí donde nos sirven mucho todo este tipo de documentación y pues también nosotros que tenemos que ahí manejar muy bien las expectativas de nuestros clientes.
Artemio: Hablando de optimizar el proceso de desarrollo ¿Qué piensas de estas herramientas que han estado muy hot este año, a partir de toda la movida que traen con Open AI. Hablo de herramientas como Copilot, de Github o Ghostwriter que son estos asistentes de programación asistidos con inteligencia artificial. ¿Te has echado un clavado en ellos?, ¿Todavía no has escuchado de ellos? ¿Tienes una opinión formada? Cuéntanos.
Henoc: Tengo sentimientos encontrados,creo Copilot me parece que salió a mediados de 2021, si no me equivoco yo le escuché como hasta principios de 2022, yo creo que de que lo escuché a principios de año, era bastante escéptico de esas herramientas, no las había probado, decía “Está bien como para hacer posibles códigos pequeños” Lo veía, como sí una, hasta incluso que podría terminar siendo contraproducente en algunos puntos, pero este año puesto el CEO de Apli empezó a empujar y empujar, empujar para que usáremos este tipo de herramientas.
Artemio: Justo me siento tremendamente identificado.
Henoc: Pues estoy en esta transición es cuando dije “Vamos a ver qué onda”
Creo que todavía no están, obviamente en el punto de hacer muchas cosas por ti, como que todavía había dado parte de tener que pensar la solución a otro nivel, incluso pensar en qué le vas a decir que haga, que tenga estructura en la parte de comunicación y como ese tipo de cosas es súper necesaria, pero justo lo que me ha estado trayendo mucho beneficio “Es que hay ciertas cosas que, por ejemplo, si tienes un error, automáticamente abajo te dice “Okay, también seguramente quieres checar esta cosa, entonces la recomendación de esa otra cosa, como que te va leyendo un poco la mente por ponerlo muy a ese nivel, con forme le vas dando ciertos impulsos.
También me pasó que estaba revisando un PR y estábamos en una llamada revisándolo y quería transmitir la idea de cómo posiblemente una optimización lo que estaba proponiendo, escribí una línea de código y me completó toda la lógica que traía en mi cabeza, era un caso aislado y algo muy puntual, pero ese tipo de pequeñas cosas son las que en vez de pasar dos minutos escribiendo eso escribí algo cinco segundos y el resto lo hizo y justo era la idea que quería proyectar. Para ese tipo de cosas pequeñas, pequeñas entre comillas, siento que es un gran referente. Tengo sentimientos, era escéptico, pero ahora creo que cada vez voy a empujando.
Mi gran miedo a filosófico, que apenas platicada con el head of data science, se supone que todo esto se alimenta de este core flow y como ese tipo de fuentes de información ¿Qué va a pasar cuando realmente eso ya no exista? porque ya no va a hacerlo, ya no los vamos a consumir y ahora es solo Chat GPT ¿Qué va a pasar dentro de esta caja, donde ya no tiene información de fuera? Eso es una pregunta para simplemente fin de año y así como vamos pues…
Artemio: Y para otro podcast, que tiene que ver con ¿Cómo alinean a esa inteligencia artificial? ¿Cuáles son todos los puntos de data que recolecta?
Rodrigo: También es esta cover flow, en un par de años ¿Cómo le pregunto al chat para que nos dé la respuesta que yo quiero?
Artemio: Sí está cañón.
Henoc: Al final Chat GPT una súper herramienta, la he usado para temas de documentos, ideas, muchas veces, no sé si a ustedes les pasa, pero a mi para empezar o cuando quiero iniciar algo y no sé cómo escribirlo pues le aviento un promt al aire a Chat GPT.
Artemio: Sí está cañón, yo para cocinar, para entrenar al perro, para consejos de viajes de turista, intenté hacer una APP con esa madre, no lo logré, pero sí llegué a meter código.
Rodrigo: Te queremos preguntar, esto casi siempre nos arroja cosas muy bonitas cuando nuestros invitados en una carrera larga, como es tu caso. ¿Cuál consideras que es un error que cometiste en tu en tu carrera? No personal en tu carrera, sino como un error operativo que que nunca volverías a cometer, digamos, un tip que le pasarías a alguien novato que acaba de arrancar una carrera también en desarrollo, que consideres así como muy valioso para ti.
Henoc: Por la parte management, hay algo incluso hasta el final de mis días como manager me ha costado mucho trabajo y es la parte de no delegar efectivamente o no delegar en lo absoluto, en retrospectiva, creo que fue mucho, porque aún cuando la CTO de Apli, como que al inicio era mucho de contribuciones individuales, yo lo hacía ahí, me costó, me cuesta mucho trabajo el soltar esa parte, pero eso es un error porque, dos cosas: una, si lo haces, tienes una vida mental mucho más tranquila porque tienes muchas cosas menos que hacer, pero la más importante razón por la cual creo que es un error porque, si no lo haces, estás impidiendo en cierta medida que las otras personas crezcan, que las otras personas tengan problemas que les van a ayudar a crecer, que tú tal vez ya los dominas, que para ti son fáciles porque ya los tienes practicados o por la experiencia que tienes, etcétera, y sí, los vas a hacer más rápido, el problema es que estas personas, que tu chamba es hacerlas crecer y que tengan un impacto en la compañía les estás quitando esas oportunidades. Incluso tanto para seniors, como para software engineers, como para managers, hay ciertos problemas que no tienes que hacer tu, no todos son tus problemas, tal vez no es algo difícil, pero dáselo a alguien, ayúdalo a que pueda resolverlo, tal vez si notas que es demasiado frustrante para ella o para él, pues ya empiezas a echar un poco nada más la mano y darle un poco la solución de problema, pero no los quites. Esta parte de delegar es súper importante, yo creo que lo que más llegó a afectar en retrospectiva, es la parte de delegar.
Rodrigo: Claro, ahí también construyendo un poco sobre eso, si el miembro del equipo al que no le quieres dar esa tarea, consideras que no se la das porque no la puedo hacer, hay otro problema con el que te estás enfrentando, que también es importante visibilizarlo y se visibiliza cuando sí les entregas estas cosas que tú podrías resolver en dos minutos.
Henoc: Es un tema de confianza, al final tiene que ser confianza y justo lo que dices, pueden perder la confianza en ti si ellos sienten que no crees en ellos para resolver problemas complicados o complejos.
Artemio: 100% y algo que nos pasó aquí, adentro del estudio, fue que tenemos un perfil que creció extremadamente rápido de junior a senior y empezó a manejar equipos, casualmente también fue el primer empleado de la empresa, su curva de aprendizaje ha sido muy grande pero también es como una chica súper pilas que agarra la onda y se clava y pues como este tipo de perfiles de alto rendimiento, recuerdo, ya que llegó el momento de hacerla manager, no tenía ni idea de cómo iba a ejecutar la tarea porque había sido un contribuyente individual, súper eficiente y mega clavado pero pues justo ahora iba a estar a prueba con otra parte de ella, que era la social, la de liderazgo, la de persuasión. Pero creo que yo le dije que above everything de lo que se acordara era de que ahora tenía este gran superpoder que era poder hacer una lista de cosas y decirle a alguien ten y ve a hacerlas, cuando te das cuenta que es el superpoder que te da el ser manager, o el ser líder, o el tener gente a tu cargo, particularmente cuando te das cuenta todo el espacio que eso libera en tu agenda para poder ocuparte en otras cosas y que, aún así, todo avance, cuando coordinas eso y lo extrapolas, no solo una persona, sino tal vez tres, cinco, diez, todo lo que podemos construir como equipo, realmente te das cuenta uno que es un superpoder que muy poca gente tiene, pero que tiene muchísimos beneficios, tiene muchos estreses por supuesto, y por eso no cualquiera puede estar en una posición de liderazgo, pero sí creo que es algo que a la larga todo mundo quiere y no sabe, son como de ese tipo de cosas que no sabías que necesitabas hasta que ya gozas de ese beneficio.
Artemio: Última pregunta del programa, esta es una pregunta que le hacemos a todos los invitados que vienen a este espacio y es la siguiente, ante los retos que se enfrenta Apli y tu como su antes CTO pero ahora Senior Software Engineer en los próximos años ¿Hay algo que te quite el sueño, dónde estás viendo como los retos más importantes / relevantes para el perfil que estás desarrollando y para el como contexto global específico de la empresa? ¿Qué es esa cosa que te pone a pensar que dices como uff, esto es algo importante y hay que prestarle atención, tiempo y energía?
Henoc: Va a sonar muy trendy por todo lo que está pasando, es la responsabilidad que tenemos de utilizar estas herramientas de maximizarlas, pero no necesariamente al menos en el corto plazo, de hacer lo que dicen, si no es como el cómo podemos posicionar Chat GPT, Copilot, o la herramienta que sea, porque cada día salen cientos de nuevas aplicaciones basadas en esos idiomas de lenguaje, pero así como ingenieros, tenemos que escoger cuál es el lenguaje ideal, por qué lo estamos escogiendo y por qué esta tecnología; creo que tenemos la misma responsabilidad ahora hacia estas herramientas, en cómo nos pueden ayudar en el negocio, cómo pueden ayudar al equipo a ser muy eficiente, pero no llevarlas tanto al extremo porque incluso podría ser contraproducente.
Una de las cosas que veía de estas herramientas en un estudio que vi por ahí es cómo algunos percibían que “OK, sí, escribes código más rápido, pero pasas más tiempo revisando que el código esté bien” entonces ir entendiendo qué significa cada una cosas. Me emociona esta parte, me quita el sueño de manera positiva, porque cómo apalancarnos bien de estas herramientas y cómo usarlas bien sin llevarlas al extremo sin que terminen siendo contraproducentes para los negocios.
Artemio: 100%. Yo creo que ahí se empieza por identificar muy bien el problema que queremos resolver y no solo utilizar AI, o crypto, o inserta aquí la tecnología que esté trendy en este instante, just for the sake of it, siempre hay que tener un buen trasfondo atrás. Creo que sí vale la pena particularmente con inteligencia artificial, que todos los CEOs, CTOs, COOs, quien sea, que haga un análisis interno de dónde cabe esta tecnología en su empresa y que empiecen en este instante, realmente es muy temprano, a pesar de todo el hype que hay alrededor.
Pero bueno, ahí lo tienen, un capítulo más a la bolsa. Si llegaste hasta este punto, queremos agradecerte Rodrigo y yo con el corazón en mano y queremos pedirte también que si conoces a alguien que trabaja en una startup de tecnología o que incluso está en una posición de liderazgo, en una de ellas, te queremos pedir que por favor le compartas este espacio a esa persona. De igual forma que debemos decirles que ya está abierto el registro para nuestra conferencia anual Latam Startup, esta se va a llevar a cabo en el tercer trimestre del año. Estamos preparando cosas que a mí personalmente me emocionan mucho, en este punto, ya sabemos, que tienes una empresa remota, ya sabemos dónde te estás atorando en los departamentos de producto, de desarrollo, de diseño, cómo son cohesivos esos departamentos, sabemos también que estás buscando herramientas de marketing que te permitan escalar y llegar a todas las personas de tu target. Sabemos también que hay muchos entrepreneurs allá afuera, tenemos un montón de insights, de dónde se están trabando las empresas de tecnología en el continente y estamos haciendo nuestro mejor esfuerzo por invitar a la gente más chingona de nuestra red a que comparta las mejores prácticas y lecciones que tienen de las startups más exitosas del continente, así que vayan a latamstartup.club, lo repito, latamstartup.club, regístrense es completamente gratis, pueden ver las conferencias del año pasado y nada nos vemos el próximo lunes. Muchas gracias Henoc por venir acá.
Henoc: A ustedes, muchas por invitación.
Artemio: Nambre, es un gustazo tenerte y gracias también a todo el equipo de producción que hace esto que cada vez es más grande, qué emocionante, nos vemos a la próxima.
Escucha otro episodio
Solo usamos cookies para brindarte la mejor experiencia en nuestro sitio, pero puedes revisar nuestra política de cookies e inhibirlas si prefieres. Si sigues navegando por el sitio asumiremos que estás de acuerdo con ellas.
