ver todos los episodios

109

cómo evitar que tu equipo entregue código espagueti

Kushki - Andrés Martínez

Andrés Martínez Kushki Cómo evitar que tu equipo entregue código espagueti

Operador

Bienvenido a un episodio con Andrés Martínez, CTO de Kushki, una de las startups de paytech con crecimiento más agresivo de LATAM.

Comparte

Insights

Si solo tienes un minuto, lo más importante que pueden aprender operadores, inversionistas y fundadores de Kushki es lo siguiente:

  • Sin una visión clara para tus desarrolladores, terminarás con código spaguetti
  • Es más complejo lidiar con las regulaciones y burocracia que con la solución tecnológica
  • Tener más desarrolladores significa más coordinación, no siempre más velocidad
  • Las pruebas automáticas en el código son una gran herramienta de educación y onboarding para los desarrolladores del futuro

Artemio: Hola ¿Qué tal? Bienvenidos 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.

Y esta vez, no como el capítulo anterior, sí me está acompañando conectado desde Japón mi socio Rodrigo Salmerón ¿Cómo estás, Ro?

Rodrigo: ¿Qué tal? Ya mejor, sin dificultades técnicas, entrando como tiene que ser.

Artemio: Ahora sí ya tecleamos todas las dificultades técnicas que teníamos.

Tenemos del otro lado de la llamada a Andrés Martínez, quién es el CTO de Kushki ¿Cómo estás, Andrés?

Andrés: Genial, genial. Primero quiero agradecerles por la invitación, realmente es un honor estar aquí con ustedes.

Artemio: ¡Nambre! Es un honor tenerte por acá y la verdad nos emociona mucho la charla que vamos a tener y a ver en qué deviene esta conversación.

Cuéntanos el pitch de elevador de Kushki

Artemio: Para poner a todos en la misma página, Andrés ¿Podrías contarnos cuál es el pitch de elevador de lo que hacen ahí en Kushki?

Andrés: Claro, por supuesto. Mira, Kushki es una paytech que búsqueda conectar a Latinoamérica con pagos, esto quiere decir que básicamente somos un adquirente regional no bancario, que nacimos desde cero y hemos construido todas nuestras estructuras en la nube. Actualmente tenemos presencia en muchos países como Colombia, Ecuador, Chile, Perú, México y lo que nosotros buscamos es crear una API única que reduzca la complejidad de interconexión en toda la región, que puedas mediante una simple API manejar todas tus cobros en toda Latinoamérica.

Artemio: Okay, perfecto, justo tuvimos aquí en el programa a el CEO de Billpocket, que es una de las empresas que adquirieron o que hicieron un merge y justo fue ahí donde ustedes aparecen en nuestro mapa, dijimos: “Okay, creo que deberíamos tener a alguien de su equipo de liderazgo en este en este programa”

Andrés: Sí, genial, Billpocket es la segunda adquisición que ocurrió en Kushki, en el 2019 adquirimos una en Chile que llama Cubeau. El adquirir otras compañías o tener estas integraciones con otras compañías realmente hemos aprendido muy, muy enriquecedor, llegan personas con excelentes perfiles, con experiencias locales que nos ha permitido aún más acelerar el crecimiento. Por ejemplo, en México, nuestro último semestre crecimos un 200%, algo que obviamente no sería posible sin Billpocket y su gran equipo de trabajo.

Rodrigo: Wow, 200% es un número importante.

Artemio: Eso sí, es comprar un buen asset.

¿Cómo es tu posición como CTO?, ¿cómo luce el día a día en tu vida?

Rodrigo: Oye Andrés y ya sobre sobre tu labor ahí en Billpocket, cuéntanos un poco ¿Cómo es tu posición como CTO? Sabemos que las posiciones cambian muchísimo dependiendo de la etapa en la que se encuentra el startup, pero en la etapa en la que se encuentran ahora igual alguien y en la más reciente también ¿Cómo luce tu día a día ahí en Kushki?

Andrés: Sí Rodrigo, lo que tu indicas totalmente estas son las posiciones que más varían con el tiempo a las tareas tienes en el año uno, año dos, comparado el año seis se vuelven otros mundos y es como tener otro cargo completamente diferente. Algo que me encanta de esto es que realmente no tienes un set de tareas específicos de tu día, realmente es, el trabajo depende de la temporada del año en la que estás, depende de los resultados que estamos obteniendo, depende de los proyectos que estamos ejecutando en ese momento, de los OQRs que tengas en ese momento que hayas definido para ese periodo de tiempo. Mira, yo tengo días que me encanta que sean super técnicos, donde hablo de tiempos de respuesta con el equipo, hablo de rendimiento, hablo de tecnología, hablo con la gente de datos, hay otras veces en donde tenemos momentos súper orientados a temas de auditoría, súper temas regulatorios, ahí conversamos de documentación, respaldos, de cómo estamos implementando las normativas, de cómo podemos mejorar esos cumplimientos de las planificaciones para las pruebas de tolerancia a fallos y documentación en general.

Hay otras temporadas, por ejemplo, donde hablamos ahora de métricas, hablamos de costos, hablamos de temas operativos, más de flujos de trabajo, más temas de seguridad. Realmente son tan diversos que el lunes puedes empezar un lunes lleno de reuniones a solo sincronizando con todo el equipo y posterior un jueves en donde pases solo conversando de temas de datos por toda la empresa. Realmente es muy, muy enriquecedor.

Artemio: Si suena a que andas de un lado para otro, de videollamada en videollamada, de chat en chat, pero bueno, al final del día eso siempre es en lo que desemboca un rol de liderazgo. Hay todo un grupo de personas que están trabajando en un mismo objetivo y es tu labor precisamente ver cómo ayudarlos a ser mejores, ver si sí se están concentrando en las cosas que son las relevantes para particularmente tu departamento y al final el día, hacer este enchufe de ese departamento con el big picture de lo que quiere lograr a nivel estratégico la empresa.

¿Qué hacen para cuidar a sus enterprise partners como Rappi?, ¿podrías darnos un recorrido de la experiencia que viven sus clientes?

Artemio: Aquí queremos preguntarte, Andrés, vemos que ustedes tienen estos partners enterprise, justo en su sitio web presumen varios logos, entre ellos el de Rappi, ser la plataforma de pago de Rappi habla de un montón de transacciones al día y queríamos preguntarte, más bien queríamos ver si nos puedes dar un pequeño recorrido de ¿Cuál es la experiencia que vive un cliente enterprise con ustedes?, ¿Cómo dista esto de los servicios que ya tienen preestablecidos? Y sí, un poco ¿Qué podría esperar un corporativo que decide confiarle a ustedes esta parte de, ya sea de los pagos o de cualquier servicio, que ustedes abonen sobre este?

Andrés: Yo creo que una empresa tiene, digamos, un par de puntos que son muy medulares en en cuanto a su infraestructura o de tu plataforma en general, tienes toda tu plataforma, tu core de negocio que construyes tú, que haces tu valor que ofreces al mercado. El segundo es tu proveedor de infraestructura, que es quien básicamente te da la infraestructura para soportar tus servicios. Hoy en día, empresas que usen un approach 100% en premise, que están administrando sus servidores físicos, son bajos, así que actualmente la gente va por ,digamos, estructuras híbridas o va por 100% cloud.

El tercero es de los pagos, al final de cuentas, todo mundo necesita que sus pagos sean realmente ejecutados en los tiempos y tengan buenas tasas de aceptación y que tus clientes no se vayan. Muchos sistemas, realmente, hacen los pagos en línea, es decir, tú de ese momento estás pagando con tu tarjeta y no puedes decirle a la persona: “Oye, ven el día de mañana a hacer el pago porque la plataforma no funcionó en el último paso del check out”

Pausa breve, muy importante, luego cuando empiezas a crecer y tu empresa dice: “Oye, yo no solo opero en este x país de la región, sino que empiezo a expandirme, empiezas a aprender que los pagos en Colombia no funcionan igual que en Ecuador, no funcionan igual que Chile, no funcionan igual que en México, entonces ahí necesitas ese aliado como Kushki que te puede decir: “Oye, mira, en este país, las condiciones son así, las tasas de aceptación funciona así, las reglas de seguridad para que no tengas con recargos funcionan así” Y te da esa esa flexibilidad de guía de cómo poder trabajar de mejor manera en ese país.

De nuevo, cada vez que tú tienes que agregar una nueva forma de pago y vas con un proveedor 100% local es: “Oye, tengo que volver a hacer toda otra conexión y luego tengo que empezar a hacer switch para poder enviar los pagos en base al país y es más complejidad, más carga técnica” y es: “ Hacer un switch de pagos, no es tu labor ¿Verdad? Tu core de negocios es lo que estás buscando”

Tener aliados estratégicos como Kushki acelera mucho su desarrollo.

Es bueno tener a alguien que está todo el tiempo pensando en: “Oye ¿Cómo puedo dar la mejor experiencia de pagos posible?” La mejor experiencia de pagos posible la haces con una plataforma que tenga buena disponibilidad, tenga buenos tiempos de respuesta, que el soporte operativo sea bueno porque siempre vas a tener algún tema, algún incidente por ahí, necesitas que ese gestador de pagos te conteste en tiempos y formas para poder saber cómo reaccionar con tus clientes y no afectar a tu servicio.

En sí, realmente el mundo de los pagos es súper complejo, normalmente tu pensarías que sólo es una tarjeta que se carga en un campo y todo es magia por detrás pero probablemente hay un montón de procesos operativos hay un montón de retos que tienes que tener como empresa. Es importante tener estos partners como Kushki que logran cubrir esto.

Rodrigo: Oye Andrés, en materia del servicio que ustedes brindan ¿Hay alguna diferencia en, por ejemplo, si yo mañana hago mi propiedad y es un MarketPlace y tenemos 300 transacciones al mes e íntegro Kushky como mi motor de pagos, contra alguien como Rappi, que me imagino que pueden tener, no sé si 50 transacciones por segundo o una cosa así como muy salvaje?, ¿Hay alguna diferencia en el servicio que ustedes pueden ofrecer para un cliente que es así enterprise? Digamos, además de costos y el tier que se contrata, todas estas cosas que me imagino que seguro que hay facilidades o cambian los números cuando son un montón de transacciones, pero ¿Hay algo más?, ¿Se adaptan a estas plataformas de alguna forma hay?, ¿Tienen equipos dedicados del lado de tecnología?, ¿Hay algún cambio en ese sentido?

Andrés: Sí, mira, nosotros tenemos un valor que me encanta, que es el éxito de nuestros clientes es nuestro deleite, como me escucharon hace un momento, yo hablo de que el API para los clientes es única y es una conexión genérica para toda la región, pero para que eso pueda ser así para los clientes es porque nosotros detrás estamos haciendo un montón de trabajo para tratar de entender localmente cómo funciona cada país.

Por ejemplo, si hablamos de transferencias interbancarias en Colombia versus México, son dos mundos completamente diferentes, son dos flujos completamente diferentes y lo que nosotros hacemos es entender localmente cómo funciona el sistema de pago de cada país, luego lo homogeneizamos y lo tenemos en el app. Para ti no tiene que ser un dolor de cabeza entender cómo funcionan las transferencias de Colombia o cómo funciona el STP de México, o cualquier servicio en cualquiera de los países.

Nosotros tenemos equipos que entienden eso, que hacen más capas de robustez sobre: “Oye, ¿cómo encontramos?, ¿cómo reprocesamos?, ¿cómo mejoramos esa tasa de aceptación para nuestros clientes? y ¿cómo lo hacemos súper sencillo para ti?” Para ti tiene que ser tres, cuatro o cinco end points y ya está hecho la operación. Para nosotros detrás hay colas, hay procesos, hay flujos alternos y ¿todo construido para qué? Para quitar esos dolores de cabeza a las empresas.

Artemio: Perfecto, entonces por lo que entiendo, el mismo motor de pago que sirve al emprendedor que está arrancando en su día uno y que decide agarrar un link de pago de sus servicios, al motor de pago que está usando Rappi son realmente la misma tecnología y lo único que cambia son estos end points o esta conexión que hace cada quien con su empresa en cuestión ¿Si es así?

Andrés: Sí así, no tenemos un tema de: “Oye, los clientes chiquitos vamos a darle los servicios pequeños para que tengan los peores tiempos de respuesta” Nosotros nos enfocamos realmente que nuestros clientes tengan mejor servicio posible al igual.

Artemio: Entiendo perfecto, es que esta pregunta nace del par de startups que hemos ayudado nosotros como estudio de productos digitales que sí tienen algunos clientes, o bueno, varias de ellas tienen clientes enterprise que tienen este molde de software que después adecuan según el cliente y las necesidades específicas que tiene. Pero qué interesante y qué poderoso que todos tengan acceso a esta misma solución, habla de esta modernización de los servicios y de poner tal vez un poco un piso más parejo en materia de la sociedad, como: “Son los mismos lugares de los que estamos sacando información todos”, “Son los mismos servicios en línea con los que estamos arrancando todos nuestros negocios”, “Todos ya tenemos acceso a pasarelas de pago súper poderosas” y esto poco a poco va poniendo un piso más parejo, por lo menos en materia de construcción de negocios.

¿Cuáles son 3 características de un ingeniero de alto rendimiento?

Artemio: Pero bueno, Andrés, eres CTO, empleas a muchísimos desarrolladores ahí en Kushky ¿A cuántos?, ¿Podemos saber cuántos desarrolladores hay actualmente en su equipo?

Andrés: Si sumas entre developers, arquitectos, debugs y demás sobrepasamos los 150 personas.

Artemio: Okay, venga. Son un equipo enorme de desarrolladores. En el proceso de construir este equipo y en toda tu experiencia, Andrés ¿Cuáles dirías que son tres características de un ingeniero, de un coder, de un desarrollador de alto rendimiento?, ¿Qué patrones has visto que comparten aquellos que verdaderamente son espectaculares en su posición?

Andrés: Hay algo que me ha encantado de Kushki es que a lo largo de los años la gente ha ido creciendo, yo recuerdo que ahorita tenemos gente en arquitectura que empezó como developer junior, que era incluso su primer trabajo, teníamos personas que han querido crecer más en el management y developers news subiendo es hoy son jefe de ingeniería, líderes técnicos, que se ha movido más en línea de producto, y es bonito ver que la gente crece y se desenvuelve dentro de la empresa pero yo creo que en general a esas personas que siempre han crecido dentro de la empresa y que están creciendo dentro de la empresa tienes siempre tres cosas: Responsabilidad, empoderamiento, colaboración.

Responsabilidad porque tienen que estar muy consciente de lo que manejamos, manejar pagos no es sencillo, aquí no puedes: “Ups, se me fue un cero y cobre 1,000 en vez de 100” no puedes tener caídas de plataforma.

Tienes que ser empoderado del producto, básicamente yo creo que a lo largo de mi carrera he sido una persona muy empoderada y mi equipo he buscado que siempre tenga ese empoderamiento. Cuando tú sientes a la plataforma como tuyo y cuando haces tu proyecto que estás construyendo actualmente sea el mayor proyecto de tu carrera, creo que puedes construir cosas que que antes y hermosas.

La colaboración, cuando ya empiezas a crecer, recuerdo cuando éramos cinco personas en una mesa de trabajo blanca, no teníamos tanta colaboración porque éramos cinco, yo podía organizar a todo el mundo tranquilamente y todo funcionaba, incluso podía hacerlo hasta cuando éramos 15, 17, 18 developers, recuerdo que tenía ahí esas sustracciones de cómo lograr estar haciendo ese management a cada persona, pero al final es: “Oye, vamos a dejar de ser 20 y vamos a tener que ser más de 100, ya no es posible que Andrés Martínez esté tras cada persona” Necesito ahora la colaboración, necesitas que la gente de tu equipo entienda que tienen que trabajar muy bien en equipo, que sea: “Tienes que apoyar al nuevo porque el nuevo no tiene el experiencia que tú tienes en nuestra plataforma, o tal vez conoces el lenguaje que estamos utilizando, o algún framework tal vez” necesitas que haya mucha colaboración y eso lo que te permite es tener un equipo cohesivo.

Recuerdo con mucho cariño a todas las gentes que fueron mis jefes o que colaboraron conmigo, mi guiaron cuando eran mis primeros años developer y esa colaboración, ese sentimiento de feedback que permite madurar el equipo y generar esa confianza que necesitas. Colaboración llega a ser el tercer valor importante.

Artemio: Fundamentales estas tres cosas para construir buenos perfiles dentro de una empresa.

¿Hacia dónde están mirando en el futuro? ¿cuál es la siguiente frontera de innovación de las pasarelas de pago en LATAM?

Rodrigo: Oye Andrés, otra cosa que nos llamaba mucho la atención y que queríamos preguntarte también es ¿Dónde están mirando hacia hacia el futuro?, ¿Dónde es que están poniendo su atención? nos preguntamos, dedica un gran porcentaje de su tiempo, seguramente que está enfocado en mejorar el servicio actual, en integrar países que no tienen integrados, probablemente están viendo dónde hacer una nueva adquisición para entrar a un nuevo mercado de forma más agresiva, o cómo mejorar pequeños procesos en el pago, pero nos preguntábamos ¿Dónde está la siguiente frontera de innovación en en las pasarelas de pago en Latinoamérica?, ¿Cuál es el paso que sigue?, cuando sueñan qué es lo lo siguiente que van a hacer ¿Cómo una startup de paytech, justo como decías, ¿Qué es lo que les emociona en ese sentido?

Andrés: Yo recuerdo con mucha emoción cada boom que hemos tenido, uno de los booms tuvimos es cuando dejamos de ser esa pequeña empresa de los primeros años que teníamos un volumen bajo y nos emocionábamos por cada 50,000 o 100,000 o 1,000,000 de transacciones y pensábamos ya a ver unos volúmenes súper impresionantes y veíamos que toda la plataforma funcionaba super bien, crecía y se escalaba y los microservicios eran lo que esperábamos que fueran.

Después nuestra siguiente frontera fue nuestra adquiriencia, esta adquiriencia nos tomó más de un año de trabajo y muchas canas que hemos tenido y que hemos sacado algunos, instalar enlaces, trabajar con nuevos proveedores, trabajar con ciertas partes del flujo que son un poco más complejas de los pagos, realmente son temas retadores.

Yo creo que en este punto, la siguiente frontera no está completamente definida, sino que seguimos creciendo por todas partes, en algún punto veremos esa meta que tendrá que cumplirse dentro del próximo 2024 - 2025.

Hay tantos temas ahorita en el ecosistema de pagos, hay temas tan generales como básicamente web 3.0, web 3.0 es algo que todo mundo quiere construir, no todos tenemos claro, hay cosas que todavía se están definiendo, cosas que no están definidas, cosas que no terminan de madurar. Se habla de open banking o se habla de pagos real time, realmente son tantas cosas que están creciendo en el mundo de los pagos porque todavía no se consolida al 100% que realmente sí crecemos en todo, el punto es ver en qué país y qué cosa está madura, porque como te digo, si hablas de crypto , la realidad de crypto en México versus la realidad de Argentina o países de Centroamérica es muy diferente. Lo que puedo decir es básicamente tenemos roadmaps en cada país con objetivos diferentes en cada país y todas se están desarrollado.

Artemio: Claro y es particularmente lo que haga sentido, fíjate que yo no esperaba esta respuesta como una posible frontera, como el todo el tema web 3.0 crypto, pero por supuesto que sí, tiene que ver con transacciones, pagos, en fin, esta gran ledger de registros de la que podemos apalancarnos que no está viviendo un gran momento en este instante, pero que sin duda es una tecnología emocionante para construir sobre ella.

Intermedio

Artemio: Vámonos al intermedio de este programa, le recuerdo a toda la gente que nos está escuchando que en cuandoelriosuena.com, ustedes pueden suscribirse a la newsletter de este programa para recibir una notificación cada que tengamos un capítulo nuevo. Vayan a cuandoelriosuena.com y regístrese.

Regresamos.

¿Cómo está conformado el equipo de desarrollo de Kushki? y ¿cómo se divide el trabajo?

Rodrigo: ¿Qué tal? Bienvenidos de vuelta a un capítulo más de Cuando El Río Suena con nuestro invitado de esta ocasión, Andrés Martínez, que es CTO de Kushki.

Andrés, retomando la conversación que estamos teniendo, queríamos preguntarte también, ya nos contaste cuántas personas son ahí en Kushki, son muchas, y nos llama la atención ¿Cómo se divide el trabajo?, ¿Cómo está conformado el equipo de desarrollo?, ¿Se dividen por funcionalidades, se dividen por países?, ¿Cómo distribuyen la carga de trabajo ahí con tu equipo?

Andrés: Mira a lo largo de los años, igual hemos cambiado y hemos madurado, cuando obviamente empezábamos y pocos microservicios trabajamos realmente en un solo equipo en esos temas, después fuimos creciendo, creciendo y empezamos a separnos en dominios, esa es la primera regla que digamos tienes cuando empiezas a tener demasiados microservicios y complejidad cognitiva en cuanto a eso.

Va separando líneas, algunas líneas son más grandes, luego hay estos conceptos que son líneas de trabajo, son tribus dependiendo de la metodología que utilizas, y al final de tienes que construir líneas, o tribus, o cualquier nombre que queramos darles, suficientemente pequeñas para que puedan tener ese dominio cognitivo de lo que están trabajando para que no tengan que otra vez capacitarse cada vez que tienen un nuevo proyecto dentro de su propia línea, porque al final más capacitación es más tiempo, es más retrasos y es menos productividad, tienes que tener esos tamaños.

Hay un par de autores de psicología que incluso hablan de los tamaños de los equipos y cuenta de: “¿Qué pasa cuando hablas de 5 personas, o 10, personas o 20 personas?” y te cuentan de: “Cuando son cinco personas es fácil ser como una familia, no es que seamos una familia, pero tenemos ese nivel de cercanía” Supongo que tu Rodrigo y Artemio tienen esa cercanía y ese nivel de confianza para trabajar juntos, pero cuando ya son 20 personas, ya esa cercanía que ustedes los tienen es difícil detenerla y cuando llegas a un equipo de 120, 125 trabajando en los mismos temas es: “Es más complejo tener, hay esta barrera de las 125 personas”

Mi consejo en ese tema es: “Oye, cuando haces una tribu o una línea de trabajo no puede haber más de 125, porque dejan de ser comunidad” Obviamente cuando estás en la parte más micro es “Oye, recuerdan la famosa regla de las dos pizzas, donde básicamente menos de 10 personas en un solo releve, en un solo proyecto pequeño, un solo feature es un selected approach” Todo el mundo espera que el desempeño junto con el número de personas sea una recta, no es cierto, en donde: “Oye, tengo 20 developers, tengo que hacer el doble de lo que sea con 10 ya” pero hay muchas reglas al respecto de eso, los 20 están trabajando en un solo proyecto, los 20 están haciendo commit, reparando los mismos bugs, no vas a tener esa misma linealidad, tienes que empezar a reestructurar, reestructurar, partir, partir.

Yo creo que también es una evolución, no puedes nacer en el día uno y querer hacer 20 líneas de trabajo o 5 líneas de trabajo cuando tu equipo es de 7 personas. A lo largo de los años hemos aprendido que “Este es el momento en el cual tenemos que dividir esta línea.” Vas evolucionado, vas partiendo y va siguiendo estas premisas de cuánta gente trabajar y cuántos líneas, en base también el volumen del producto que estás construyendo. Básicamente es un camino y cada vez que vez que llega el momento tienes que estar listo para estructurar, repartir la gente, capacitar en lo que necesites y el negocio mismo te va empujando eso.

Rodrigo: Es súper interesante esto porque cuando recién empezamos nosotros a incursionarnos en el desarrollo porque, llevamos haciendo diseño de interfaces un buen rato, pero desarrollo un poco menos. No logramos entender muy bien por qué si cada quien estaba en su computadora en su casa, si trabajando en el mismo proyecto, pero no necesariamente en el mismo pedacito del mismo proyecto porque no íbamos a avanzar mucho más rápido con más desarrolladores. Nos costó mucho trabajo bajarlo, después nos dimos cuenta que es lo análogo a que haya un montón de gente metiendo la mano en el mismo cuadro, intentando todos pintar una línea distinta en un cuadro, si tú quieres pintar una recta y alguien está pintando en horizontal, se estorban en algún momento y hay que coordinar no solamente que no estén dos personas moviendo el mismo componente al mismo tiempo, sino que no estén moviendo un componente que afecte a otro, que afecta a otro, que afecta a otro y que entonces eso puede hacer que la cosa sea complicadísima.

Hay muchos niveles y muchas formas en las que desarrolladores se pueden estorbar y pisar entre ellos si no se coordinan bien, esto lo consideramos nosotros un arte después de habernos metido esta experiencia y ahora con mucha prudencia alocamos los recursos de desarrollo por eso que nos cuentas me recuerda mucho a esta experiencia del aprendizaje duro, de ver que sí es verdad que no meter más personas al equipo lo hace más rápido, sin duda, no un desarrollador más quiere decir nunca el doble de trabajo, siempre es un arte lograr acomodar al equipo para que trabajen de la forma más eficiente posible.

Andrés: Sí, claro, al final coordinar es un esfuerzo y es un esfuerzo que no se ve, al finales es: -“Sacaste este proyecto que es de este tamaño ¿Por qué necesitaste tanto esfuerzo?”

-“Tuvimos gusta ordenar mucho”

-“Pero la coordinación no es producto en sí, es una tarea interna para que la gente pueda trabajar” Si es que no requieres muchísima coordinación en el proyecto es que algo está mal, estás trabajando con demasiada gente, tal vez el approach de tecnología no es el apropiado.

Por ejemplo, nosotros tenemos solo una consola, recuerdo que llegamos a un punto en donde son demasiados equipos trabajando en el mismo API, tuvimos que pasar a buscar frannels, era sí o sí, y aún así, con esas separaciones igual necesitas coordinación, pero tú sientes ese bajón de: “Aquí era una coordinación gigante, en donde todo el mundo tenía que hablarse para poder cambiarla un cuadro como tú dices. En cambio con esas separaciones: “Aseguramos un par de firmas y la coordinación bajó al 10%” Realmente es muy interesante.

A veces lo aprendes a la mala de que: “No podemos lanzar 50 programadores y esperar que todo salga en dos días” a veces es distinto el escenario de todos, a veces es:

-“El proyecto está atrasado ¿qué hacemos?”

-”Mandemos más gente”

La solución no es esa.

Artemio: Claro, 100%, y particularmente cuando se trata de temas de desarrollo siempre tiene que haber primero una resistencia a contratar gente, porque justo como dices, siempre la lógica es: “Métele, métele más personas y claro que sale más rápido” pero tiene que haber primero este ejercicio de pensar: “Bueno no, a ver ¿Cómo podemos sacar este problema adelante?”

¿Cuáles son los mayores retos técnicos de un agregador de pagos?

Artemio: ¿Cuáles son los mayores retos técnicos de un agregador de pagos?, ¿Es la conexión con el banco que los respalda en el país en cuestión?, ¿Es un tema de con el cliente?, ¿Tiene más que ver con las validaciones legales que hacen?,¿Dónde necesitan ahí de las mentes más sagaces o de la organización más nítida de la comunicación al momento de echar a andar un producto con tantos microservicios como este?

Andrés: Cuando hablas de pagos hay muchos, muchos temas que son complejos. Como tu sabes el mundo de pagos es ampliamente regulado, no puedes lanzarte a ningún país de la región y decir “Yo quiero hacer pagos sin cumplir las certificaciones internacionales, sin entender las regulaciones locales” Básicamente tu necesitas que todo se cumpla, el equipo legal es el que tiene un montón de temas que tienen que ser desarrollados antes de que podamos abrir una operación en cada país. La gente de operaciones tienen igual montón de temas igual de ¿Cómo facturamos?, ¿Cómo operamos?, ¿Cómo liquidamos la demanda apropiada?, ¿Cómo damos un servicio que esté sobre la media o por lo menos del nivel de lo que esperas en ese país?

Los tiempos de operaciones de Colombia son diferentes a las demandas operativas de Ecuador, Chile… cada país tiene sus diferentes niveles y tu al ser internacional tienes que apuntar al menor de los tiempos, al mejor de los servicios y hacerlo en todos los países en la medida de lo posible.

Tienes un montón de retos legales, de retos operativos y de ahí vienen nuestros retos tecnológicos. Yo suelo decir que al final los retos tecnológicos son los sencillos, no porque sea más sencillo, sino porque realmente yo sé que tecnológicamente ya hemos hecho muchas conexiones, hemos conectado a muchos países, tenemos conexiones de adherencia directa contra las marcas. Yo sé que los retos tecnológicos los vamos a poder afrontar, pero a veces un reto, un tema operativo, un tema legal puede tranquilamente tardarse 6-9 meses, entonces por más seamos súper rápidos en codificar y podamos cerrar una conexión en un mes, probarla y lista para producción, eso no significa que la plataforma va a estar procesando en ese tiempo.

Artemio: Dios Santo.

Andrés: Realmente replica el país, al final, es un tema súper complejo, es entender cómo funciona las regulaciones del país completas, cumplir todas las regulaciones del país y luego los retos que tenemos tecnológicamente. Como te digo, adquirir esa experiencia fue un tema de más de un año de trabajo entre decidir en clases, construir las tramas, hacer certificaciones y luego todo el tema de “No sé qué tal es México en burocracia, nunca he hecho un trámite personal” En algunos países de Latinoamérica es complicado, no voy a decir nombres, pero en algunos países los sistemas gubernamentales no son tan ágiles como en otros no.

Rodrigo: Sí, aquí es de esos lugares donde luego suele ser complicado también.

Andrés y mira que nos habíamos encontrado, ya nos lo habían comentado personas, también CTOs de otros agregadores de pago, luego trabajar con los bancos para poder integrarlos en la plataforma era un punto muy complicado, pero sí claro, ahora que lo mencionas, me puedo imaginar también entrar a un nuevo país es un nuevo mundo, por eso tiene tanto sentido hacer estas estas adquisiciones cuando ya digamos que adquieres el expertise y no solamente el pedazo de mercado, sino todo el conocimiento sobre cómo funcionan las cosas localmente, que puede ser lo más complicado de adquirir para alguien que viene de afuera.

Artemio: Tal vez hasta las licencias, que después son estas que te pueden trabar 6-9 meses en no tener un permiso o lo que sea para poder hacer lo que quieres hacer.

Yo en zapatos de un fundador que lo está deteniendo la burocracia durante un semestre me saco los ojos, me disparo al pie, no sé qué haría porque no hay mucho que puedes hacer, dependes enteramente de la burocracia de un país, que como dices Andrés, en Latinoamérica, particularmente hablando de México que es nuestra experiencia, es muy tardado todo, todo es muy tardado, creo que hasta ahí la voy a dejar para para no ponerme más violento mejor.

Cuéntanos 3 consejos que se puedan implementar en una organización para mejorar la calidad del código

Rodrigo: Oye Andrés, otra cosa que queríamos tocar contigo, la calidad del código sabemos que es un tema medio abstracto y medio maleable también porque no necesariamente queremos que todo que no exista un solo bug en todo el producto porque entonces también quiere decir que estás invirtiendo una cantidad de tiempo en eso que es una locura, no se puede avanzar, etcétera. Indudablemente si el código está lleno de problemas, va a ser un producto lleno de problemas y eso tampoco es deseable. Te queríamos preguntar si nos compartías tres consejos que se puedan implementar en una organización para mejorar la calidad del código y la calidad del producto que se entrega.

Andrés: Sí, claro, yo creo que el primero es el empoderamiento que tiene que tener, lo mencioné hace un tiempo atrás, pero lo vuelvo a sacar. Yo creo que cuando tú eres empoderado, y recuerdo las primeras líneas de código que armaba en Kushki, todo el tiempo me decía a mí mismo “Este va a ser el producto más grande que voy a hacer y va a ser el producto más eficiente que jamás he construido, va a tener el mejor tipo de respuesta posible, va a tener la menor cantidad de fallas humanas posibles y va a ser el proyecto del que más orgulloso voy a estar en mi vida profesional” Y ese cariño que yo le tengo a la plataforma Kushki siempre traté de transmitirla a mi equipo, esas personas que tenían ese empeoramiento tenían ese cariño a lo que constituían, yo veía realmente que había una mayor calidad de su código, porque está ahí dale y dale, haz pruebas solitarias o pruebas unitarias hasta que tengas la tranquilidad de que eso no se va a romper nunca y lo envías esa producción. Para mi todavía es bonito todavía saber que muchas de las líneas de código que escribí hace cuatro, cinco o seis años atrás todavía por ahí están corriendo, todavía tiene sus pruebas y todavía funcionan bien. Me genera esa satisfacción.

El empoderamiento es súper importante si quieres realmente que haya calidad porque tu puedes tener todos los procesos automáticos que quieras, la mayor calidad de código en cuanto a plataforma, pero si es que la gente no lo construye con pasión y con cariño a la plataforma se van a saltar las pruebas, van a encontrar alguna forma de romper las automatizaciones, pero al final, si lo hacen con responsabilidad, lo van a hacer bien.

La segunda creo que es tener una visión súper clara, cuando en mis primeros años de desarrollador salía mucho de que no había una visión muy clara, no entendía la visión de que estamos construyendo. Yo creo que cuando no tienes una visión de qué estás construyendo, terminas con un montón de códigos espaguetis y montón de ideas por aquí, por allá, tratando de solo cumplir lo que dice la la tarjeta, es darle una visión apropiada a tu equipo, ¿Qué tienen que saber?, ¿Qué estamos construyendo aquí?, ¿Cuál es el objetivo?, ¿Hacia dónde va la plataforma en el próximo año?, ¿Hacía dónde van nuestros servicios? Esa visión hace que de cierta manera el código tenga un sentido y sepan qué se construye y en dónde, porqué hay un micro servicio A con microservicios B y porqué se conecto esa manera.

El tercero digamos que es “Automatiza en cuánto puedas” Esa parte la aprendí un poco a la fuerza porque realmente es que las tareas repetitivas a medida que tu equipo crece, tu tienes un equipo de 10 personas y tienes tres tareas, luego tu equipo crece a 60 personas o solo hablemos de 15 personas, esas tres tareas se vuelve nueve tareas y te quitan montón de tiempo. Dejar siempre esos temas de automatizar para después, para después, para después, al final se van haciendo unas bolas de nieve gigante.

Todo lo que sientas que es la tarea repetitiva, tediosa innecesariamente y que le quita tiempo al equipo es “Ve un espacio en donde sea un cachito y automatizarlo” Eso va a hacer que tu gente se pueda enfocar más en lo que está construyendo, sea más hábil y diligente en lo que construye en su código.

Artemio: Qué poderosas son particularmente las primeras dos que mencionas, tal vez la primera la más poderosa, siendo la de empoderar al equipo o darles este peso del ownership del producto, porque algo que yo sí he notado es que en medida en que tú alguien le das la excusa o la oportunidad perfecta para hacer el mejor trabajo de su vida, como bien mencionaste ahorita y también hace un rato, pueden suceder cosas fenomenales, pero tiene que ser de la persona el proyecto, tiene que sentir que las riendas están en sus manos, tiene que sentir que la aportación que él hace la está haciendo desde su persona, desde su intelecto y desde su energía, porque de otra forma no siente que es un trabajo propio, pero en medida en que uno puede empoderar así a su equipo y delegarle tareas que son importantes para la organización, es realmente así como se construyen muchas de las grandes empresas que hoy en día lideran mercados.

Sabemos que testear tu propio código puede ser un sin sentido, pero también saber hacerlo puede reducir mucha carga y vueltas en QA. ¿Qué consejo nos puedes compartir para hacer mejor esta labor?

Artemio: Andrés, también queríamos preguntarte, sabemos que después testear tu propio código puede no tener sentido porque tú ya sabes cómo funciona la cosa que estás desarrollando y si bien puede haber ahí un bug, tú pues medio le vas a acomodar y picar para que pase tu propia prueba personal y ya mandarlo a un QA que sea mucho más agresivo con la prueba que está haciendo con la funcionalidad en cuestión, pero de igual forma hacer este mismo análisis de tu mismo tratar de romper tu código puede reducir mucha carga de trabajo y vueltas precisamente al equipo de QA ¿Qué consejo nos podrías dar para ser mejor esta labor de tu revisar tu propio código o cuál es tu postura ante esta práctica?

Andrés: Cuando empezamos Kushki sabíamos que desde el día uno teníamos que hacer pruebas unitarias, yo creo que la respuesta es “Cuando construyas pruebas unitarias no hagas una prueba unitaria para que el código sea 100%), pruebas para el 100% nunca puede ser tu objetivo, tu objetivo es: “¿Cómo hago que un developer que va a venir ocho años después hacer una modificación mi código no rompa una funcionalidad?” Cuando haces tus pruebas unitarias, realmente los aspectos tienen que estar súper bien construidos, es algo que en las calls reviews siempre mucho énfasis cuando todavía hacía revisión de control. Yo en los calls reviews hacia input, output de archivos de salida, después, cuando empezamos a hacer unas pruebas un poco más completas, hacíamos incluso chequeos de cómo los registros se guardaban en la base de datos, en tus pruebas unitarias es básicamente probar todo lo que puedas probar, todo lo que creas que se pueda llegar a romper, todos los escenarios que se puedan, probar de manera automatizada, y mira que al final de cuentas estás haciendo eso no para que tu vengas a editarlo en seis meses, lo estás construyendo para que alguien que no tiene idea de cómo programaste ese código en tres años pueda venir y tenga la tranquilidad de que no va a romper ninguna funcionalidad al re escribir o actualizar tu código.

Artemio: Okay, muy bien. Rodrigo ¿Quieres tirarte la última?

Rodrigo: Sí, sí, sí, me hecho yo la última.

Me pareció interesante Andrés, el testing tiene tanta carga como para que no se rompan las cosas, pero también hay una carga educativa en el testing. Para que sepan los desarrolladores nuevos cuando llegan qué tipo de cosas no pueden hacer, aunque ellos consideran que en ese momento fue una buena solución porque entonces va a tronar las pruebas y pueden poner atención. Funciona también para incluso como técnica de un onboarding, es como legado de los primeros programadores de un producto a los que vienen después.

Andrés: Sí, yo creo que esa parte de la cultura es algo que lo construyes y tienes que tenerlo largo plazo. Cuando estás en tu pequeña startup y tú amas tu producto, lo vives tan de cerca y el tiempo va creciendo, nuestro legado para los siguientes programadores es tratar de dejar esa cultura y ese amor que le teníamos a las cosas, las cosas buenas que hacíamos. Al final, las tecnologías cambian, las líneas de código se van deprecando, se actualizan por nuevas líneas de código, los servicios se van rompiendo y más servicios pequeños, la gente va moviéndose dentro de empresa o a otras empresas, al final lo que queda es esa cultura, esa cultura que dice: “¿Por qué estamos aquí?, estamos construyendo código para ganar un sueldo, estamos haciendo código porque estamos construyendo y dejando una especie de legado, de algo más grande que nosotros mismos” Si es que la gente entiende y logras transmitir esa cultura… que también evolucionarán porque esa era mi pasión de hace de siete años y esa es la parte de la cultura que yo estaba dejando.

Al final la cultura va evolucionando, el tiempo va evolucionando y tú solo tratas de que quede la parte positiva que puedas.

Artemio: Dale, me quedo con el “No estamos construyendo código por un salario, sino por este legado, por esta misión, por esta visión por esto que estamos construyendo juntos”

Ante los retos que se enfrenta Kushki y tú como su CTO en los próximos años, ¿qué te quita el sueño?

Artemio: Creo que es una gran forma de dar pie a la última pregunta del programa. Esta es una pregunta que le hacemos a todas las personas que han venido a este espacio. Fundadores, operadores, inversionistas de empresas de tecnología han respondido a ella y nos interesa saber qué es lo que pasa por tu cabeza, Andrés. Ante los retos que se enfrenta Kushki y tú como su CTO en los próximos años, ¿qué te quita el sueño?, ¿Dónde están esos retos que van a necesitar de un equipo impecable, de tu energía y de tu intelecto?

Andrés: Me encanta esta pregunta porque cuando la mencionas me hace pensar un poco en mi esposa, yo tengo 10 años de casado y mi esposa le encanta decir que se casó con una de las personas más ansiosas que he conocido en su vida, soy súper ansioso. Recuerdo que cuando construía los códigos era “Ya quiero que esto esté funcionando el día de mañana” pero obviamente era un proyecto de más de un año de trabajo que tenemos que hacer, pero yo tenía esa ansiedad de: “No, vamos a hacer rápido las tramas contra las marcas para ver cómo funciona y vamos a conectar todo para poder ver exactamente cómo fluyen las conexiones” Al final yo creo que la gente ansiosa queremos ver esos grandes frutos de esos grandes proyectos, cada vez que tenemos un mega proyecto gigante que ya no son proyectos de dos meses, si no son proyectos de seis, nueve o un año, tienes esa esa ansiedad que te dice: “Quiero ver ya los resultados porque va a quedar hermoso cuando eso esté funcionando”

Lo que me quita ahorita el sueño es los proyectos que estamos ahorita construyendo, que espero que se terminen inicios del próximo año, eso es lo que me quita el sueño a corto plazo.

Yo sé que cerrando estos proyectos que estamos viviendo en este año, no voy a dar mucho detalle, que debía salir a inicios del próximo año, será un nuevo hito para nosotros y después yo sé que hay tantas cosas en el mundo de pagos, tantos temas que todavía están pendientes… mira, hay temas de consolidar con diferentes países, hay nuevas tecnologías, todavía no sabemos si se va o no a adentrar en el mercado, si va a tomar sentido para nuestros clientes, hay tecnologías como el AI que vienen con el boom de “Vamos a cambiar el mundo”, esas cosas me quitan el sueño porque realmente como me encanta la tecnología y me encanta saber hacia dónde nos vamos y sobre todo, me encanta transformar esa tecnología en productos reales y cosas que den valor a la vida de las personas.

Me quita el sueño que estoy acabando en este año, en enero y yo sé que en enero algo me va a quitar el sueño entre mejorar nuestro equipo o tal vez algo de AI, tal vez los nuevos proyectos que tengan terminar de construirse para el 2024. Lo que puedo decir básicamente es: Cuando tienes pasión por lo que estás haciendo, cuando sientes que estás dando valor al mundo con lo que estás construyendo, siempre tienes algo que te quita el sueño, tienes que acostumbrarte a vivir con con problemas de sueño.

Artemio: Fenomenal, me encanta. Creo que genuinamente el aportar valor a la sociedad con tecnología es personalmente creo que de las formas más éticas de construir riqueza, incluso cuando se habla de construir un negocio, o de hacer algo que impacte a la sociedad, muchísimos de los problemas que existen hoy en la sociedad pueden ser solucionados con tecnología y el encontrar a más personas en el ecosistema que tienen esta perspectiva de siempre estoy construyendo algo y me emociona lo que viene este constante camino del héroe de: “Estoy en mi vida común y corriente, me meto en un reto, me voy, me meto esta aventura, aprendo cosas nuevas, vuelvo a la nueva normalidad y viene una nueva más” realmente ese tipo de perfiles son los que terminan por construir el futuro y en gran medida las organizaciones que nos ayudan a resolver tantos problemas que existen hoy en día.

Muchísimas gracias Andrés por venir a este capítulo, apreciamos mucho tu tiempo sabiendo lo apretada que es la agenda de los invitados que vienen en este espacio. También muchas gracias a Rodrigo, quien tiene la mención honorífica por conectarse a las 3:00 de la mañana desde Japón.

Rodrigo: Un placer, un placer.

Artemio: Y muchas gracias también al equipo de producción que hace esto posible, Ana Isabel, Blanch, a Belmont, les mandamos un saludote y un besote donde sea que estén en este momento.

A ti qué estás escuchando te recuerdo que cuandoelriosuena.com puedes suscribirte a la newsletter de este programa y recibir una notificación cada que tengamos un capítulo nuevo. Déjanos tu correo ahí, déjanos avisarte cada que tengamos un capítulo como este y si conoces algún fundador, operador o inversionista de una empresa tecnológica, por favor comparte este espacio con esa persona.

Nos vemos a la próxima.

Cuando el río suena.

Si crees que a alguien le seria útil este contenido, compártelo con esa persona.

Escucha otro episodio

los mejores recursos para negocios digitales

Nunca dejamos de aprender sobre nuestro ecosistema, cuenta con que compartiremos lo más valioso contigo.

Conoce las lecciones más valiosas después de +130 episodios publicados de nuestro podcast. Lee sobre la Minimum Viable Startup.

suscribirme
switch languageenglish

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.