Episode Transcript
[00:00:00] Speaker A: Cada decisión de ingeniería, cada decisión de incluso de lo que se escribe en el programa, es una decisión de compras, es una decisión de costos. Un diseño que tiene una armonía, un diseño que tiene, digamos, una cierta belleza, suele generalmente tener una relación con la calidad del producto.
[00:00:18] Speaker B: Los intereses son más altos, el riesgo sube, pues ya tienes que ir con bastante más cuidado ahora que en 2021 o 2020, que era todo sí, pero.
[00:00:28] Speaker A: Nosotros sabemos que va a volver. Todo cambia, todo su ciclo es un.
[00:00:33] Speaker B: Ciclo, hay historia de su intentar sobrevivir como la parte más baja y cuando llegue la parte un poco más más suave, pues intentar aprovechar para poder levantar un capital que sea más barato y tenerlo todo planificado.
[00:00:44] Speaker A: Parte tiene que tener su responsabilidad y no cambiar la cultura demasiado.
[00:00:51] Speaker B: Tener en cuenta por una empresa pequeña que que dispone de unos recursos que antes no disponía, pero que tiene que tener cuidado con su presupuesto, que es probablemente una de las cosas más importantes al principio. Hola a todos y bienvenidos a un nuevo episodio de Finops más que costes. Hoy tenemos un invitado muy especial, saliendo un poco del tema de compañías grandes y demás. Tenemos hoy a Ariel Tunik, CTO de Doctech. ¿Qué tal, Ariel?
[00:01:19] Speaker A: Muy bien, muy bien. Gracias por la oportunidad de hablar con ustedes.
[00:01:23] Speaker B: Muchas gracias.
Y bueno, como no, a nuestro presentador, Damián. ¿Damián, cómo andas?
[00:01:29] Speaker C: Gracias, encantado de estar aquí en otro episodio.
[00:01:34] Speaker B: Muy bien, muy bien. Pues hoy hoy creo que tenemos una charla bastante interesante también para un ecosistema que al final es quizá uno de los que más se benefició de la aparición de la nube en un primer momento, que fueron las startups, de poder tener esa agilidad, de poder desplegar todo muy rápido, tener casi unos servicios que eran impensables para cualquier empresa pequeña al alcance de su mano, pero que sin embargo tiene que tener cierto cuidado, quizá más cuidado porque tienen menos margen de error ÿousand que son los costes que al final les apremian más por el tema de eso, al final está todo más más pequeño, el margen es más corto, el riesgo es más alto, todo hay que tener mucho cuidado. Entonces Ariel es una persona que está trabajando ahora en ese mundo y vamos a ver un poco qué nos puede contar un poco del finops en startups. Así que Ariel, cuéntanos un poco cómo ves tú el finops desde tu perspectiva ahora como CTO, una empresa, una empresa pequeña, y cómo te está afectando en tu día a día.
[00:02:46] Speaker A: Sí, bueno, empezar un poco con, digamos, un poco de historia de mi parte, o como lo veo yo a esta historia. Yo tengo algo así como 20 y pico años de experiencia en todo lo que sea software, IT, empresas grandes, enterprises grandes, Ÿousand y todo el movimiento de los Data Centers al Cloud también, todo eso, lo que es la cultura de Phoenix o lo que o empezaría de la cultura, lo que empezó lo que era DevOps, que yo pienso que tiene una relación con eso.
Ÿousand al principio, nosotros como programadores, como líderes de la tecnología de una empresa, nos preocupamos bastante menos de los costos. Teníamos una parte de la empresa que es la parte de finanzas, la parte de IT, que le decíamos bueno, necesitamos un servidor, o cuando llegamos a la nube necesitamos ÿ un institut o algo así. Y básicamente no teníamos ninguna relación con ese departamento fuera de eso, o fuera cuando ellos reconocían un costo alto.
Y que es algo parecido a lo que pasaba con el DevOps.
Antes estaba la parte de operaciones. Nosotros como programadores hacíamos nuestro programa, le pasábamos ÿ a la parte de operaciones bueno, encárguese de que esto llegue al servidor. Y empezó la cultura, o lo que se llama el DevOps. Para cambiar un poco la cultura y para que la parte de programación, la parte de ingeniería esté más relacionada con la parte de operaciones.
Según mi parte de ver, la cultura cambió, pero no todo lo prometido. Estaba prometido más o menos que los programadores se hagan cargo también de la parte de operaciones. Eso no pasó últimamente, todavía se le manda parte del trabajo de la infraestructura a la gente de DevOps. Pero sí, la parte de ingeniería tiene que saber Ÿ cómo va a ser su programa instalado en la nube, cuáles son los resources que van a ser usados. Y yo pienso que algo parecido está pasando en lo de Phoenix.
La parte de tecnología, la parte de ingeniería tiene que tener, no se hace cargo de todo lo que sea la parte de costos y finanzas, pero ÿousand cada decisión de ingeniería, cada decisión de, incluso de lo que se escribe en el programa, es una decisión de compras, es una decisión de costos. O sea que hay que estar muy hay que saber bien lo que uno va ahora a producir, cuáles son los servicios que van a ser usados en la nube. O sea que hay que tener ÿ eventualmente una buena comunicación, una buena visibilidad. Ahora, en la parte de lo que sea tarta pequeña, yo soy CTO startup pequeño, -12 personas en un, lo que se llama un nicho de tecnología, la parte marítima, o sea que no tenemos, no somos un startup cyber que puede traer de las venture capitals mucho, mucho capital, sino capital que bastante más reducido. O sea, como dijiste, el margen de errores más pequeño.
Entonces, lo que tratamos de hacer de nuestra parte es crear una empresa con un adn que sea centralizado también en la parte de Philox, cambiar el el adn en una empresa cuando es grande es posible, pero es muy complicado. O sea que uno trata de ya desde que la cultura Philop sea parte de la cultura de la empresa.
¿A qué me refiero? Prácticamente cuando uno empieza un nuevo feature, o sea de que tenemos que que hacerlo como parte del producto, entonces el programador, el arquitecto que es responsable de ese feature, es responsable de la parte de functional requirements, non functional, pero también de los costos. O sea que cuando uno, un programador, un arquitecto presenta el diseño, presenta el diseño, cómo va a hacer el functional requirement, el non functional requirement, como parte de eso es, tiene que presentar cuál es los costos que una, que ese feature va a utilizar. Eso no es para nada fácil, no es para nada fácil porque aparte de los costos directos que uno puede más o menos manejar, a veces no sabe cuáles son los costos indirectos.
O sea que es algo muy complejo, es algo que hay que manejarlo, pero es algo que tenemos como empresa, parte de la cultura. O sea que uno tiene esa responsabilidad de que los costos sean más o menos los que se programó y si no, hay que ver qué se hace. Pero yo pienso que lo más importante es que esa parte de la responsabilidad, yo como programador soy responsable de los costos de lo que voy a programar, de lo que voy a diseñar.
También querría decir que yo pienso que hay un diseño que tiene una armonía, un diseño que tiene, digamos, una cierta belleza Zweitausendein, suele generalmente tener una relación con la calidad del producto y yo pienso lo mismo con relación de los costos. Cuando uno tiene un diseño que está en relación de costos, bien utilizado, eso también a veces o generalmente tiene relación con un buen diseño del sistema. O sea que eso es también parte de cómo nosotros lo vemos y cómo nosotros lo manejamos a toda esta parte del Finops y costos en el de nuestra empresa.
[00:09:55] Speaker B: Sí, al final es un poco, aparte de que al final un producto tiene que ser eficiente en todas sus partes, tanto en tema de uso de recursos como el tema de su arquitectura y demás. Entonces al final meter el coste como una métrica más de de eficiencia es algo que en otros casos como bueno, se ha dejado un poco de lado, porque lo principal era entregar el producto que fuera eficiente en tema de peticiones por minuto procesadas, lo que fuera, el ratio que quisiera y no tanto como que cuánto está gastando, salvo que sea una cosa, vamos a decir, ingente, tipo inteligencia artificial o procesado de datos de big data, algo de ese estilo. Entonces lo que comentas para ÿousand para una startup que al final sigue gastando recursos en menor medida, es algo bastante importante.
[00:10:49] Speaker A: Así es también lo que sería cada emprendedor, cada gente que fue parte de startup conoce mucho lo que es el Runway. Uno tiene un capital, un capital que alcanza hasta cierta fecha y nuestra responsabilidad que ese Runway sea bien utilizado ÿousand o sea que la parte de los costes sea bien utilizado para que si el Runway le facilite al CEO, a la gente de business, utilizar lo mejor posible y generar el mejor business para la empresa. O sea que eso es algo muy, muy, muy importante. Toda la parte de también como cultura, toda la parte de visibilidad al máximo, que sería visibilidad al máximo sería primero que nada darle la posibilidad a toda la gente de la empresa, incluso una empresa pequeña, tener visibilidad de lo que estamos pagando en la nube, lo que estamos pagando, los diferentes servicios. ¿Uno hace ÿousand utiliza diferentes servicios, no? Follow, aws, azul, gcp, pero otros como por ejemplo Mongodb, atlas, cuál es el gasto por servicio, darle la posibilidad de a cada una de la empresa entrar y preguntar y fijarse cuánto uno paga, cuál es el costo incluso. Y también muy importante, tratar lo antes posible, incluso antes que la empresa tenga revenue, cuál sería el darle la posibilidad de ver la ganancia con respecto al costo del producto, lo que se llama algo así como cloud efficiency rate, tratar de llegar lo antes posible, entender cuál sería el futuro revenue de la empresa, si los costos de la nube son tal y tal.
O sea que toda parte de visibilidad y transparencia en la empresa sea lo máximo posible.
También como parte de cultura, cuando uno hace lo que se llama code review, como dijimos antes, cualquier decisión de diseño o incluso ahora llegamos a una situación que muchas decisiones como programador o muchas líneas de código Ÿousand tienen efecto en lo que al final uno pagaría. Por ejemplo, si uno trabaja como nosotros en Serverless, o sea que mucho con lambda, que uno paga generalmente por el cuánto tiempo tarda esa función, esa parte ser ejecutada. Si uno hace decisiones o tiene una línea de código que es sincronia, o sea que espera para que otro programa termine, la ejecución va a ser más larga y por eso el código, el costo va a ser más. O si uno tiene muchas líneas de logs en el código, eso al final llegan al Cloudwatch ÿousand aws, más líneas de código, más storage, más costos. O sea que hay que ser muy como parte de lo que se llama code review, incluso como parte de la cultura, fijarse en eso.
[00:14:56] Speaker C: La verdad que estoy asombrado para una empresa así tan chiquita, se ven que tienen procesos muy buenos como y parte de eso también de la visibilidad y todos esos procesos también que ya donde están prácticamente pensando en un proyecto, ahí tienen sus, todo eso del coste que hablaste, o sea, tener el proceso de pensar en el coste y también la visibilidad, o sea, eso para mí parece estar en un muy buen lugar, especialmente para una empresa, como dijeron, de Ÿousand, de 12 personas.
[00:15:34] Speaker A: Sí me gustaría más tener más capital y no tener necesidad de que estarme en eso, pero no, no nos queda otra. Así tiene que, así es. ¿Si no podemos, digamos, vivir como compañía.
[00:15:51] Speaker C: Pues llegando a pensar en el cos unit, qué van a tener en un futuro? También creo que interesante saber si cada uno cuando dio una arquitectura llegaron todavía a ese nivel que, por ejemplo, cuando dan mesa visibilidad, si pueden ver lo que planaron al principio y cuánto están gastando en ese momento.
[00:16:15] Speaker A: Sí, sí, eso es interesante. Nosotros vemos como parte del diseño con parte del Design Review, entonces presentamos el futuro costo como lo vemos y para eso usamos herramientas como el de Cost Calculator de AWS y cosas así. Es muy complejo, muy complejo también porque uno más o menos trata de.
Primero, primero que nada, cada servicio de la nube es diferente y los algunos expostores y otros por tiempo utilizado es totalmente diferente. Y también uno trata más o menos de estimar la cantidad de datos que uno va a recibir. Por ejemplo, si es un streaming, si es algo así, tratando de estimar más o menos lo que va a recibir, uno no puede saber. Y está como lo que se habló antes, la parte de costo indirecto, que es por ejemplo, el costo Ÿousand, VPN, costo de logs, costo. Tuvimos un toda la parte de anomalías. Por ejemplo, tuvimos un caso de que empezamos lo que se llama stream processing para hacer processing en tiempo real.
Fuimos bastante justos en entender cuánto pagaremos por eso, pero llegamos a producción y de repente recibió en el SLEC una anomaly muy alta que no entendíamos de dónde venía.
Eventualmente vino de un servicio que se llama Guard Duty, que se fija y analiza cada acción que se hizo en la nube y se fija de dónde llegó esa acción. Y el flip, por ejemplo, que es para script processing, escribe mucho y lee mucho del street y de repente, o sea, el wall duty que no es directo, subió el costo muy alto.
Por suerte teníamos esas alertas de anomalías que pudimos pararlas a tiempo. Si no nos hubiera costado mucho, quizás tendríamos que haber apagado el el stream processing, que eso fuera, que es un servicio que le damos a nuestros clientes así que es complejo y es importante tener la visibilidad, importante tener las alertas, especialmente yo pienso para un startup pequeño.
[00:18:58] Speaker B: Al final ahí juegas lo que hemos dicho, que juegas con menos presupuesto, el tema de presupuestar bien, hacer los presupuestos, las alertas de costes para que veas que no zweitausendein, que no se gasta más. Si hay x procesos, pues tener un budget concreto, que alguien lo vigile y que dé margen, pero que también esté controlado dentro de unos estándares. Y me llamó la atención lo que habéis dicho, o sea, lo que has dicho del tema de las líneas de código, porque yo me acuerdo que leí un artículo que luego puse en la newsletter que era million dollars lines of code.
[00:19:34] Speaker A: Sí, también.
[00:19:35] Speaker B: Que creo que era el CTO de Cloud zero, muy bueno porque era un cambio de una instancia en un terraform valía pues 1000, yo que sé, $1000 al mes, que si lo multiplicas pues ya son 12000 al año, que es ese tema, lo que tú dices de un loop en, por ejemplo, en una lambda que tarde, pues en lugar de tardar nada, tarda 1 s más, pues 1 s por reproducción, por demás, lo rápido que que escala un coste es bastante imponente. Entonces tener eso como métrica es algo que es muy importante. Y creo que también lo que has dicho del coste de los productos, es decir, creo que en la industria del software a veces por cómo es, o yo creo que cómo es en general, cómo se genera el dinero, cómo se levanta capital, cómo se crean las empresas, se tiende a como a ignorar completamente el coste del producto, el coste por usuario no está presente. En cambio, por ejemplo, una empresa de, yo que sé, de logística o de alimentación, su margen, por ejemplo, vamos a poner una empresa de alimentación, su margen es un, un 2, %, un 3 % como mucho, tiene que saber perfectamente al mínimo detalle lo que le cuesta hacer, pues vender unas galletas o una está, no puede perder ni un igual, juega al céntimo. Entonces eso en el software o en este tipo de empresas tiende a ignorarse. ¿Es decir, hay veces que es un poco qué me cuesta? ¿Pues no sé, mientras yo esté generando tal, ya, pero qué te está costando? ¿Sabes? Así es, porque como hay márgenes más altos, también es una industria con márgenes más altos, pero bueno, los márgenes son altos, hasta que no generes beneficio, el margen es cero.
¿Claro, también se vive mucho en, y eso no sé cómo lo ve, me gustaría saber cómo tu visión de, porque claro, una startup no mucho está pensada, se ve que va a perder dinero hasta x punto, no? ¿Entonces, cómo veis vosotros el tema de los costes en esos estados? No sé si has estado tú en esos estados de decir, ÿousand vale, ahora mismo estamos perdiendo dinero, ganaremos dinero en tal punto, llegaremos a break even, demás. ¿Cómo se tú crees que se valora lo suficiente el coste de cloud en esos estados donde estás levantando capital y te estás gastando mucho dinero de otras personas que luego igual vas a echar de menos?
[00:22:07] Speaker A: Sí, bueno, eso todo el ecosistema un poco cambió ÿ hace unos años no importa cuánto uno gaste, lo importante es conseguir usuarios.
Muchas empresas, no voy a dar nombre ahora, pero crecieron así exponencialmente en usuarios, gastando muchísimo dinero y eventualmente cuando llegó la crisis empezaron a decir no, ahora tenemos que generar capital con nosotros y entonces fue muy complejo.
Nosotros desde personalmente y por quisiera decir también que hay compañías que quizás eso es lo correcto al conseguir usuarios y después ver cómo general y para eso por supuesto uno necesita un capital importante, como que backup, como sea, para generar esa cantidad de usuarios.
¿Nosotros no tenemos el celof, nosotros no tenemos que ser generar o tratar de llegar al break even lo antes posible, o sea que para eso, como dijimos antes, uno necesita esa esa esa visión y esa observability de lo que cuesta generar el producto y cuesta la operación del producto, o sea que y cuánto? Incluso uno cuando está al principio de startup es complejo saber cuál es el precio de su propio producto o definir cuál sería el precio del propio producto y para eso es muy importante saber cuánto cuesta, cuál es el costo del producto. ¿Entonces eso es muy importante y querría decir también que incluso en un startup pequeño como el nuestro, cuando viene miousand, mi CEO y pregunta mira, tenés acá servicios de flink, servicios de iot core, servicio de street, una cantidad de servicios, me pregunta Ariel, cuál tenemos nosotros en nuestra pieza? ¿Tenemos tres productos, cuál, qué producto utiliza?
¿Qué servicio? O incluso eso es complejo, incluso startup pequeña, así que hay que tratar de manejarlo lo antes posible.
En esto no no estamos tan avanzados. Toda esa parte del tagging es algo que yo personalmente no he llegado a una decisión si es correcto o no correcto, porque según mi experiencia, si uno tiene que hacer tagging manual, digamos, o uno le da al programador mira que tenés que hacer esto porque va a servir para esto y esto es muy difícil, quizás es lo correcto.
Estoy buscando alguna forma de hacerlo de forma automáticamente como parte por ejemplo de relación entre el repositorio, del repositorio del kit del git o ÿousand parte del DevOps todavía no logramos una buena solución, pero eso también uno tiene que darle el viso desde cómo se utilizan los recursos en la nube al CEO o la parte de finanza lo antes posible.
No es fácil, ni siquiera en un startup pequeño. Así que en un Enterprise grande, Zweitausendein es mucho más difícil. O sea que no sé si respondí directamente a tu pregunta, pero me fui a distintas, distintas partes de eso.
[00:26:28] Speaker B: Sí, era un poco ese tema de, bueno, lo que no había caído también era que ese panorama con el tema de los tipos de interés, con el cambio de las políticas monetarias, que ya él ÿ vamos a decir, el grifo se cerró un poco de tener tipos de interés cero, que el dinero fuera más, se moviera un poco más, ya al final el capital cuesta más, cuesta más levantar, los intereses son más altos, el riesgo sube. Entonces ya tienes que ir con bastante más cuidado ahora que en 2021 o en 2020, que era todo, pues sí.
[00:27:05] Speaker A: Pero ÿ, pero nosotros sabemos que va a volver. Todo cambia, todo es una onda, es un ciclo. Servimos los ciclos de cambiar los tres.
[00:27:17] Speaker B: Cambiar con el tiempo la historia, intentar sobrevivir como la parte más baja y cuando llegue la parte un poco más suave, pues intentar aprovechar para poder levantar un capital que sea más barato y tenerlo todo planificado.
[00:27:33] Speaker A: Y en la parte más baja generar oportunidades. Si uno genera una empresa que es sana en la parte de philop, sana en la parte de DevOps, sana la parte de la cultura, cuando viene la cresta de la ola, uno va a ser más, va a tener más oportunidades como vista. Eso es lo que pienso.
[00:27:52] Speaker C: Bueno, a lo mejor cuando encuentres la manera de hacer el tagging perfecto, te invitamos otra vez y nos contás cómo lo hiciste.
[00:28:01] Speaker A: Sí, estamos tratando también lo que me falta. No sé si ustedes conocen, yo soy muy fanático de lo que sería static code analysis, o sea que análisis static del código, que es algo que se usa mucho, por ejemplo, para encontrar en el código falencias de seguridad, por ejemplo. Yo pienso que eso es algo que tiene que usarse también en la parte de Philox. O sea que si uno ven el código en forma estática, zweitausendein que hay algo que puede ser un issue en la parte de phenops también sería como parte del proceso de DevOps o con parte del unit test o con parte de eso, generar una alarma o no pasar al próximo, lo que sería la parte del deployment, si uno no pasa bien esa parte.
[00:28:59] Speaker B: Si no creo recordar, creo que hay empresas tipo infracost y luego hay otra startup también que lo hace, que es parecido todo eso.
Infracost está muy en ese shift left. Luego hay otra que es que no me acuerdo del nombre y que también lo hacía, que creo que hablé con el CEO pero no me acuerdo ahora mismo y luego si eso te lo padre lo pongo. Pero hay bastante en ese tema porque al final ellos sí que es verdad que es complejo. Al final, por ejemplo, todo lo que tenga que ver con infraestructura es complicado, el tema de analizar terraforms y ya si te metes en cosas como transformations o cosas más específicas se complica. Temas kubernetes se sigue complicando más porque no acabas de saber ÿ no es directo la infraestructura es como indirecto porque es una cosa que va dentro de una infraestructura que luego va de otra manera, pero sí que es algo que estoy seguro que irá por esos por esos términos y no sé si empresas como tipo eso, Infracoast o Weave se centrarán y entonces estoy seguro que habrá progreso en esa parte. Pero sí, es una de las más. Yo también lo he visto y el tema de seguridad además con todo el tema de la IA para procesado de texto, ese tipo de cosas que puede como cerrarse un poco. El scope funciona porque lo que tú dices al final un sonar lint o demás te escanea el código y te veo una directriz, pero claro, no es lo mismo con un coste que es como más difícil de calcular, pero pienso.
[00:30:42] Speaker A: Que va a llegar también a esas herramientas porque todo el ecosistema está muy mucha gente está empezando a entrar en el ecosistema del Fino y es muy interesante lo que está pasando en todo este ecosistema. Muchas empresas nuevas, muchas la cultura cambiando, así que para mí es muy interesante.
[00:31:07] Speaker C: Bueno, yo creo que la verdad fue muy interesante y llegamos a la parte en que nosotros te preguntamos una punta que la verdad que le preguntamos a todos.
Espero que estés preparado y bueno vamos a empezar.
¿La primera es si pudieras crear una herramienta de feel off mágica, cuál sería?
[00:31:30] Speaker A: Yo pienso que sería relacionado lo que lo que lo que hablamos antes, o sea que uno con una análisis del código que va a ser deploy, saber si la utilización optimal del producto del feature y analizar antes de que llegue a la nube los productos directos e indirectos, los costos directos indirectos de ese feature. Eso es lo que querría Zweitausendein lograr.
[00:32:08] Speaker B: No piden mucho, no eres el que más pide de los que hemos tenido, no eres el que más pide.
[00:32:15] Speaker A: Y quizás contestarle de forma automática a mi CEO de lo que me preguntan, eso también trataría de lograr eso.
[00:32:25] Speaker C: Genial. ¿Bueno, la próxima es cuál es el mayor malentendido sobre shinops?
[00:32:32] Speaker A: Sí, esa es una una buena pregunta y quizás yo no sé, algo que yo no mal entiendo y esa sería de mi forma de verla quizás todo esto movimiento de Finox se habla mucho de la comunicación y la coparticipación entre el finance y engineering Zweitausendein.
Yo pienso que hay que aprender de lo que fue DevOps, que finalmente cada parte tiene su responsabilidad y la comunicación tiene que ser no tan profunda, sino más, podríamos decir, no tan profunda para que no genere confusión en cada lado. Cada uno, cada parte tiene que tener su responsabilidad y no cambiar la cultura demasiado, sino dejándole responsabilidad a cada uno. No sé si fue claro, no, pero yo pienso que hay que aprender del cambio del DevOps e interpretarlo así también en el Philops. O sea que está la responsabilidad Ÿousand y él hay que haber coparticipación y transmisión entre cada dos, pero finalmente quedarse cada uno con su responsabilidad.
Si lo veo. No sé si fui claro en esto.
[00:34:08] Speaker B: Ahora está muy ahora muy claro.
[00:34:13] Speaker C: ¿Y bueno, la última es cuál es tu referencia en este mundo de Phenops?
[00:34:18] Speaker A: ¿[Sos/Eos] a referencia?
¿A qué te referís?
Referencia de dónde puede decir Víctor que están leyendo.
[00:34:32] Speaker B: Claro, el tema de una compañía.
[00:34:36] Speaker A: Primero que nada, como dijimos antes de la charla, no sabía que iba a hablar con con ti Víctor. Y yo soy leo mucho tus posts en LinkedIn, toda la parte que sea podcast, o sea de inox, todos los podcast de la organización. Estoy incluso del principio escuchándolo a todos los podcast.
Y sí, estoy tratando todo posible de donde educarme y los cursos de finops y eso. Hay mucho material y mucho material interesante, mucha gente interesante, así que de ahí trato de estudiar y eso.
[00:35:30] Speaker C: Bueno, me parece perfecto. La verdad que muchas gracias por estar acá con nosotros y compartir tu viaje, tu journey a The Phenops y cómo lo hacen en su empresa. Para mí me pareció muy interesante.
[00:35:46] Speaker B: Ha sido la verdad es que muy es muy, muy interesante ver cómo una empresa pequeña puede empezar a aplicarlo desde un primer momento y cómo quizá por las circunstancias al final económicas y por el tipo de diferentes tipos de empresas ÿousand se ve un poco el cambio ya de bueno, esto no es despegar aquí corriendo lo que sea que funcione y da igual lo que cueste, sino desde un principio que el coste sea una métrica a tener en cuenta por una empresa pequeña que dispone de unos recursos que antes no disponía, pero que tiene que tener cuidado con su presupuesto, que es probablemente una de las cosas más importantes al principio. Y eso es muy, muy, muy interesante. En tema de otras perspectivas de empresas grandes, que al final se preocupan más de otras cosas que no es esto. Así que ha estado muy, muy, muy bien.
[00:36:40] Speaker A: Muchísimas gracias, la verdad, por esta oportunidad de hablar con ustedes. Así que lo disfruté mucho.
[00:36:47] Speaker B: Me alegro, me alegro de leer. Ese es el objetivo. Espero que también los oyentes en este caso, lo disfruten. Así que nada, muchas gracias de nuevo por venir a leer y nos vemos en el próximo episodio. Saludos.
[00:37:01] Speaker A: Gracias.
