Subscribe
Share
Share
Embed
Un@ invitad@ espectacular, una pregunta y una conversación llevada hasta el final para matar la pregunta. Recorremos el globo para encontrar las mentes más brillantes en temas como innovación, emprendimiento, liderazgo, growth, ciberseguridad, agilidad, experiencia del cliente y muchoooo más. Con cada invitad@ hacemos una inmersión profunda en una pregunta y luego la editamos a menos de 18 minutos de perfección. Si disfrutas este podcast y te gustaría escuchar más... por favor déjame saber qué invitad@s, qué temas, y qué preguntas te gustaría que matemos dejando un mensaje aquí en Spotify o en cualquiera de mis redes sociales @robbiejfrye
Hello, hello, hello y bienvenidos a
Matamos Preguntas.
Un invitado o invitada increíble, una
pregunta y una conversación llevada hasta
el final para responder la pregunta.
Sin decir más, aquí tienes tu host, el
gringo loco, Robbie J.
Fry.
Hola, hola, hola, ¿cómo estás?
Y bienvenidos a Matamos Preguntas.
Mi invitado es otro señor de la empresa
espectacular Global 66.
Se llama Mauricio Oneto, ex Amazon y Chief
Experience Officer en Global 66.
Y la pregunta que matamos es...
cómo se ve un mindset de gestión de
proyectos en un mundo digital.
Pero antes de arrancar, ayúdame a
multiplicar el impacto de Matamos
Preguntas, regalando una reseña en Spotify
o en tu player favorito.
Y cuenta al mundo que...
¡Amas Matamos Preguntas!
Y lo más importante, quiero celebrar las
empresas que hacen posible...
este podcast.
Listo, Mauricio.
Siempre puedes ganar más plátano, más
tiempo.
Mil gracias por su tiempo.
Gracias a Tommy si están escuchando.
Gracias por el contacto.
Gracias a la gente, a Tommy, para
recomendar a Mauricio para podcast.
Bienvenido.
Gracias, Rubi.
Gracias por la bienvenida y gracias por la
invitación.
Encantado de estar en tu podcast.
Te escucho harto y encantado de estar
desde otro lado ahora.
Castingos, ¿quién es Mauricio?
Cuéntanos sobre vos para la gente tiene
contextos.
¿Dónde trabajas, qué has hecho en tu vida,
en quién eres por ti?
Claro que sí.
Mi nombre, como ya sabes, es Mauricio.
Soy super techie y super computing en
todo, digamos, en mi estudio, en mis
aficiones y también en mi carrera
profesional.
Trabajado siempre en el ruido financiero,
pero siempre en roles tecnológicos.
Y hoy día mi rol es...
Chief Experience Officer.
Cuando partimos GlobalSafeSale los
primeros años, mi rol era CTO, era el
Chief Technology Officer y estaba a cargo
de los equipos de tecnología.
Y después hice un switch a este nuevo rol
de Chief Experience Officer.
Mauricio, parceiro, mira, tengo una
pregunta genial para ti porque tiene que
ver con la gente y la tecnología.
La pregunta que quiero matar es, ¿cómo se
ve un mindset de gestión de...
proyectos en el mundo digital, por favor.
Mira, te lo voy a responder a partir de
una anécdota.
Cuando estábamos como en nuestro año 4,
quizás, o tres y medio, un muy buen amigo
mío que se llama Cristóbal Muñoz, que es
nuestro gel de producto hoy día, me
preguntó, ¿Global 66 es una startup de
producto o es una empresa de proyecto?
esa pregunta causó muchas conversaciones,
hay muchas reflexiones.
Y yo resumo la respuesta a esa pregunta de
la siguiente manera.
Global 66 es una empresa de productos.
Nosotros creamos productos digitales y
resolvemos problemas de las personas y de
las empresas a través de productos
digitales.
Tenemos cuentas en múltiples monedas,
tenemos nuestras tarjetas, tenemos el INDE
Codro, tenemos muchos productos digitales.
Y los productos...
digitales son complejos de implementar.
Y las cosas complejas requieren cierta
estructura de gestión de proyectos.
Entonces, creo que no son cosas
excluyentes.
Global 66 es una startup de productos y
tenemos una estructura de gestión de
proyectos para implementar esos productos.
Está bien, no son cosas excluyentes.
Nosotros cuando partimos Global 66, hace
ya cinco años, partimos inmediatamente con
metodologías CRAM y bien así by the book.
Teníamos varias células con 5 o 6 personas
en cada célula, sprints de 3 semanas y así
es como íbamos iterando nuestro group.
Y construimos los fundamentos tecnológicos
de Global 66 así, con Scrum y con varias
células.
Al segundo o tercer año ya teníamos unas 6
células operando.
Y funcionó bien, funcionó bien.
Y super by the book, super en este mindset
de tener sprint corto, de entregar valor
rápido, de equivocarse barato.
superan este mindset así bien de Scrum.
Con el pasar del tiempo, empezamos a
embarcarnos en iniciativas mucho más
complejas.
Lanzar una tarjeta, por ejemplo,
conectarnos a la red Interbancaria Chile.
Y así nos fuimos embarcando en iniciativas
mucho más grandes.
Entonces, cuando tú tienes una iniciativa
tan grande, es poco el valor que puedes
entregar en las primeras tres semanas.
Incluso en las primeras seis semanas.
Entonces dijimos, oye, espera, ¿y qué tal
si estas iniciativas más grandes las
abordamos con gestión de proyecto más
clásica?
Así con un equipo dedicado, con una
cartagán, con un líder de proyecto.
Y decir eso es como un crimen desde el
2024.
Es como, ¿cómo?
No eres ágil, eres old -fashioned, vives
en los 90.
Es como un crimen decir algo así.
Y mucha gente nos dijo, tan loco, o sea,
tuvimos muchas conversaciones.
Pero si Global se dice, es una empresa tan
moderna, o sea, miren todo lo que hemos
logrado, porque queremos hacer algo que
suena tan de los 90.
Y fue controversial, pero lo hicimos.
Nosotros dividimos nuestro equipo
tecnológico y dijimos, mira, hagamos algo.
Dos tercios de nuestro equipo tecnológico
van a seguir trabajando en células ágiles,
Scrum, Sprint cada tres semanas.
Y un tercio va a trabajar en modo
proyecto.
Y los proyectos van a ser bien old
-fashioned, si con cartagán, milestones de
entrega, reuniones de status.
Y fíjate que funcionó muy bien.
Muy bien, porque Globaz 66 estamos
haciendo tantas cosas al mismo tiempo que
ya se empieza a dar como una cosa natural.
Entonces, nosotros decimos, a ver, mira,
este cookie viene y queremos hacer 10
cosas.
Aquí está la lista de las 10.
Mira, estas tres son muy grandes.
Trabajémosla en modo proyecto, la toman
los equipos del proyecto.
Y estas otras siete son cosas más pequeñas
en que podemos entregar valores en sprints
cortos.
Entonces, estas otras siete.
trabajémosla en el equipo de células.
Y esa fórmula, que fue tan controversial,
funcionó perfecto.
Y hoy día lo hacemos así.
Entonces, tenemos los equipos trabajando
en dos modos y es súper natural decidir
qué cosas van en un track y qué cosas van
en el otro.
Diego, tenemos dos tipos de proyectos en
Amazon.
Por las estoy inventando o paraphrasing,
pero es...
Uno es que cuando la gente piensa que
cuando abres una puerta...
ya están destruidas y no puedes volver por
la puerta.
Pero es una mentira.
Si algo no funciona, vuélvete.
Tú puedes amar 20 puertas al mismo tiempo
y volverte por la puerta.
Pero hay otros proyectos que no.
Que cuando tú pasas por la puerta, la
puerta chao.
Tú ya has cruzado algo y no puedes
volverte.
Y dices, la problema es diferenciar qué
proyecto cuando es tan grande y tan
importante que no puedes regresar en qué
es.
En cuanto es uno gigante, es decir, un
equipo gigante, es decir, cómo tomar
tiempo, pero uno no, hágale.
Hazlo, inventen como rápido.
So, cuéntame qué proyecto usted decidió.
Vamos a las noventas, este va a ser algo
estilo viejo, pero con una forma nueva.
En cuál es un proyecto que vale la pena
hacer spritz.
En cuándo sabes.
Te voy a contar cómo lo hacemos.
Yo trabajé en Amazon dos años en
tecnología también, en un equipo de
FinTech.
Y cuando partí en Amazon estaba muy...
Yo fíjate, te voy a contar algo, estaba
muy curioso porque también escuchaba todos
estos podcasts y los principios de
liderazgo de Amazon y estaba muy curioso
sobre cuán realista es su implementación
en Amazon.
Y es muy real.
O sea, lo comprobé, digamos, desde primera
mano, incluyendo este, two -way door
decision versus one -way door decision.
Te voy a contar cómo lo hacemos en global.
Las cosas que requieren una arquitectura
tecnológica compleja y que tienen...
de la
y quiere enviar dinero a tu cuenta en el
Santander, en Chile o en el Panamá o en
cualquier otro.
Eso nosotros lo tratamos como proyecto,
así en los 90s, como decías tú.
¿Y por qué?
Porque primero requiere una arquitectura
tecnológica relevante.
O sea, hay que hacer una fase de diseño,
hay que hacer una fase de implementación y
una fase de prueba.
Y en segundo lugar, el outcome de eso es
poco probable que varíe.
Ya teníamos súper claro el producto.
que queríamos implementar y la experiencia
de cliente que queríamos lograr y cómo
hacerlo.
Entonces, dado que hay poca espacio que
bivotee el resultado y que como viene
straightforward el proceso y que es
complejo, lo manejamos como un proyecto.
Lo hicimos en los equipos de proyecto y
resultó muy bien.
Y en la otra punta todos estábamos súper
de acuerdo en que fue bueno hacerlo así.
Otras cosas, como por ejemplo ajustes a
nuestro proceso de onboarding.
cuando los clientes crean una cuenta en
Global 66, cargan la app, pasan por un
proceso de onboarding en que se toman una
selfie y a los 4 minutos ya están
aprobados y listos para operar.
Nosotros queríamos llevar eso de 4 minutos
a 2 minutos.
Y decidimos una serie de mejoras a la
experiencia.
Esas son cosas chiquitas porque es una
lista de 10, 12 cosas en que en 3 semanas
puedes resolver 2 o 3 de ellas.
Entonces, mejoras al flujo onboarding es
un ejemplo de algo que.
tenía todo el sentido llevarlo en el track
de Scrum.
Y así lo hicimos y así resultó bien.
Entonces, al final hay un criterio, ¿ya?
Por buscar algunos más, por ejemplo,
conectarnos a la red interbancaria
colombiana, por ejemplo.
O sea, también es algo que abordamos como
proyecto.
Y en el Scrum tenemos lo que te decía de
un boarding y muchas otras cosas.
Mejoras al proceso de carga de dinero, por
ejemplo.
Mejoras al producto de...
de pagos entre clientes de Global, son
cosas más pequeñas y incrementales que las
hacemos en Mostgram.
Al final, un mensaje que yo quiero dejar,
Roby, es no hay que seguir tendencias, no
hay que incomodarse por querer hacer algo
diferente a lo que la industria está
haciendo.
Al final, tienes que tener como self
-awareness tuyo y de tu equipo y ahí
decidir de manera súper empoderada con tu
equipo qué es lo que quieres hacer.
Y si eso es algo raro,
o algo incómodo, no importa.
Si es lo que mejor resulta para tu equipo
y la mejor forma de impactar a tu cliente,
so be it.
No hay rollo.
Es la forma correcta para tu equipo.
Pero si alguien llegó, chicos, vamos a
armar este equipo y listo listo.
Y vamos a utilizar Waterfall en nueve
meses.
Aquí es tu libro de los 90 de eso.
Claro.
Así como un libro empolvado.
Quitando el polvo.
Como el libro de Indiana Jones.
Allá guardado.
Pero alguien dijo o fue en una
conversación, alguien de ese qué vamos a
hacer, en presentón, comunicó por qué o
solamente fue un decisión de vos o Tommy
que dijeron vamos a hacerlo.
Hay cosas complejas en las que no estamos
aportando valor rápido.
O sea, cuando decidimos conectarnos a la
red interbancaria de Chile o cuando
decidimos hacer una tarjeta.
Ok, Sprint 1, Sprint 2, pero todavía no
hay tarjeta.
Entonces, tiene sentido porque hacer algo
así de grande es ir por capas.
No puedes dividir eso, no puedes lanzar
algunas tarjetas en las primeras tres
semanas.
No es así como funciona.
Hay una arquitectura tecnológica que se
construye desde abajo hacia arriba.
Entonces había acuerdo en el problema.
Y después empezamos todos a reflexionar o
filosofar sobre qué cambios metodológicos
hacer.
Y de ahí empezó a aparecer esta opción.
Y yo te digo, fue controversial.
O sea, no todos estaban de acuerdo en un
inicio.
Y se dio, se dio tensión, así como, oye,
pero ¿cómo vamos a hacer esto?
Es muy raro para una empresa como la
nuestra.
Y hay un concepto que nos gusta mucho a
nosotros y que no inventamos nosotros.
Es el disagree and commit.
Hubo mucho disagree and commit.
Cuando yo trabajaba en Amazon, había un
chiste interno al respecto.
Y el chiste era, la mayoría de las
personas les gusta más el disagree que el
commit.
¡Eso es el asensillo!
Exactamente.
Muchos otros managers decían...
...la mayoría de la gente se olvida de la
segunda parte.
Tienen muy presente tu derecho al
disagreement, pero no tan presente...
...tu responsabilidad del commitment.
Entonces es muy fácil el disagreement sin
commit.
Y te digo, lo vivimos.
O sea, cuando empezamos el malo es equipo.
había muchos ingenieros y gente producto
en los equipos de proyecto.
Y yo te diría que estaban como 50 -50.
O sea, desde este tercio que se fue a
trabajar el nuevo proyecto, una mitad
estaba muy de acuerdo en lo que estábamos
haciendo.
O sea, me parece bien, me encanta que
tengamos esto como time span más de
proyecto.
Bien.
Y la otra mitad era, no estoy de acuerdo,
pero estoy dispuesto a probar y demole, y
se acudían a comir.
Entonces...
Nos encanta ese concepto y sirvió muy bien
porque si no hubiese habido Disagrean
Commit no lo habríamos podido hacer.
O sea, no podemos obligar a alguien a
trabajar con nuestra forma de hacer las
cosas.
Entonces ese Disagrean Commit de Sanitano
nos ayudó mucho y nos permitió facilitar
la decisión y facilitar la prueba.
¿Cómo cambió el manejo del proyecto?
¿Si no estás esperando un entregable cada
semana o sí?
pero es como un mini proyecto dentro de un
proyecto grande.
¿Sigan con Sprints o no siguen con
Sprints?
La reunión que tienes es cada dos semanas
a veces de una semana, solo la gente tiene
mucho tiempo para como trabajar sin
interrupciones.
¿Qué cambia en el manejo del proyecto?
Muchas cosas, o sea, los equipos de
proyecto primero,
son equipos con dedicación exclusiva.
Los equipos ágiles nuestros hacen muchas
cosas en un sprint de tres semanas.
Y trabajan en cosas de mejora continua,
trabajan en algunas iniciativas.
Entonces, en proyectos no ocurre eso.
O sea, el proyecto que está trabajando en
lanzar una tarjeta, ese equipo no trabaja
en nada más que lanzar esa tarjeta.
Entonces, esa es una dedicación exclusiva.
Dos, no trabajan en sprints.
el equipo se reúne, analiza el objetivo,
hace el discovery, hace un diseño técnico
y de ahí plantea milestones.
Entonces, un milestone puede estar a 30
días de otro milestone, que en una
agilidad 30 días es una tendidad.
Pero el proyecto sí es razonable.
O sea, el día 0, nada, el día 30 voy a
tener listo esto, el día 60 esto.
No todos los milestones son así de largos.
También hay milestones de dos semanas, es
normal.
Pero es muy diferente.
O sea, no hay sprints y hay dedicación
exclusiva.
Yo estoy imaginando la primera vez que
alguien que solamente han hecho agile o
agile llegan a la conversación y están,
sí, listo, el próximo mustang, sí, 30
días.
Entonces escuchar y decir 30 días, cómo
van a tener un sabor muy raro.
Dice, 30 días, qué es así?
Ocurrió, ocurrió.
O los productos que tenemos nosotros
requieren, son productos súper...
De ADN es súper global, o sea, nuestra
cuenta son en múltiples monedas.
Por ejemplo, le voy a un ejemplo bien
práctico.
En global, un cliente puede enviarle a
otro cliente dinero hacia cualquier país
en cualquier moneda.
Ya sea, un colombiano le puede enviar
dólares a un chileno.
Y ese envío que atraviesa, digamos, tres
monedas y que atraviesa una frontera
porque entre países diferentes es
instantáneo.
Lograr algo así de complejo.
requiere una tecnología, requiere un
approach tecnológico super innovador, ¿ya?
Y requiere del desarrollo de tecnologías
que son complejas.
Las cosas complejas requieren diseños
técnicos y esta metodología de proyecto
deja espacio a ser un diseño técnico.
Y nos encanta sentarnos en una pizarra,
pensar en alternativas técnicas, entender
el business problem, discutir diferentes
alternativas y son reuniones como de mucha
ingeniería y de mucho debate técnico.
Entonces...
Una metodología más de proyecto deja
espacio a eso, ¿ya?
Versus el Scrum, que no es tan así, porque
el Scrum como que te presiona entregar
valor rápido.
Entonces, OK, tenemos este tremendo
Business Problem.
¿Qué parte de esto podemos resolver y
entregar valor en las primeras tres
semanas?
Entonces, eso, por más que sea la forma,
digamos, de operar desde mucho equipo y
que tiene cosas buenas, también tiene
cosas malas.
Es que que...
te presiona un poquito a salir rápido y
rápido no necesariamente es lo mejor
cuando necesitas como fundamentos técnicos
potentes.
Entonces proyectos deja espacio a tener
diseños técnicos y a tener sesiones de
diseño técnico que son supervaliosas.
Él dijo en el libro, no puedes tener una
escuela de project management porque están
diferentes en todas las empresas, en
cualquier producto es distinto.
Entonces tratar de hacer una escuela o eso
es como hacer project management no
funciona porque alguien tiene que saber de
todo.
Pero saber de todo, de su identidad de la
empresa.
O alguien en global no se van a mover,
incluso a un pizzo van a ser completamente
distintos porque no es igual.
Entonces, ¿cuál es tu definición del rol
de un project manager?
¿En cuál son las formas de verlo, en los
approaches para manejar gestión de
proyectos?
Dona, muy buena pregunta.
Yo, a nivel de mi experiencia, tengo una
opinión bien clara.
Prima mucho más.
los skills blandos que los skills duros.
Ya o sea, cuando yo he trabajado con
project managers me he dado cuenta que las
grandes diferencias en un project manager
exitoso no las hacen ni las
certificaciones, ni la universidad a la
que viene, no las haces.
Los mejores project managers que yo he
visto en mi vida en Global 6C y en otras
experiencias pasadas por lejos son los
que...
de corazón creen en el proyecto y que no
le tienen miedo a nada.
Yo te digo, personas que tienen el
propósito pero impresan al corazón y que
no le tienen miedo a meterse en terrenos
desconocidos son pero los mejores project
managers y son capaces de lanzar cualquier
producto en cualquier contexto a súper
velocidad y con un excelente resultado.
Lo he visto pero estoy clarísimo, digamos,
lo he visto muchas veces y estoy
convencido de que cuando las personas
están así...
empoderada sobre un proyecto y no le
tienen miedo a meterse y creen en el
resultado, puede sacar adelante realmente
cualquier cosa.
Y eso que nace como del corazón es mucho
más potente que cualquier certificación,
que cualquier partón o que cualquier
experiencia para que se haga.
Entonces, por ejemplo, lanzar nuestro link
de cobro.
Tenemos un link de cobro en que cada
cliente tiene un link que se lo puede
enviar a cualquier persona en cualquier
país y esa persona abre ese link, hace un
pago.
y nuestro cliente recibe el pago en su
cuenta de los access.
Es un producto que lanzamos hace ya un
tiempo y que mucha gente está usando para
cobrar clases online, para cobrar de
curso, para cobrar servicios de
freelancer.
Es un producto que ha tenido súper alta
tracción.
Entonces, lanzar algo así, cuando
empezamos a hacer, digamos, cuando
empezamos a armar el proyecto de lanzar el
link de cobro, nos empezamos a dar cuenta
que las.
Cosas que hay que hacer para lanzar un
producto así son súper diversas.
Primero, desarrollar software.
Hay que desarrollar software para lanzar
algo así.
Después hay que armar campañas de
marketing para promocionarlo.
Después hay que resolver un montón de
aspectos operativos.
Después hay que tomarse las definiciones
financieras de cómo se va a contabilizar
todo eso.
Son muchas tareas diversas.
Y a medida que empieza el discovery, yo
creo que hay dos tipos de project managers
en este tipo de situaciones.
algunos que se empiezan a echar para atrás
y te dicen, no pues espérate lo mío es
software, yo hago el software pero que
marketing vea su campaña de marketing que
operaciones vea cómo operar esto entonces
se empiezan como a echar hacia atrás y
otros que empiezan a caminar hacia
adelante y te dicen, ah que interesante
una campaña de marketing ah que
interesante los aspectos operativos y
empiezan a entrar, a entrar, a entrar
entonces esas señales son las que te dicen
que se va a hacer un super project manager
porque a medida que aparecen complejidades
la persona se sumerge en las
complejidades, en lugar de empezar a
retroceder y decir, no, espérate, esto yo
no lo veo, esto lo ve el área de
marketing, el área de operaciones.
Entonces, para mí esa es la señal.
Cuando el project manager empieza como a
adentrarse en las complejidades en lugar
de alejarse, es una muy buena señal de que
va a ser un gran project manager.
¿Tú crees que esto es algo de curiosidad
que ustedes están escuchando de verdad?
Sí, sí, marketing funciona así, yo, ya,
sí, cuéntame más.
Y qué más, sus curiosidades en este
permiten a ellos entender si yo creo en
eso.
Sí, en el cuando ya creen, pueden ver algo
que nadie más pueden ver.
Y allá es la forma de eliminar el miedo o
cuando viene la parte de miedo.
Yo creo que ante estos miedos, que son
naturales, normales, uno se empieza como a
armar en el camino profesional.
O sea, con qué te armas primero con el
propósito.
Yo lo vivo en Global 66, pero de verdad
todos los días.
Yo digo, si de verdad queremos habilitar a
las personas a tener una vida financiera
global, cuando yo creo realmente en ese
propósito, digo, tenemos que lograr
ciertas cosas que son complejas.
Y toca lanzarse nomás.
Al final uno puede manejar sus propios
miedos, pero también te toca lidiar con
los miedos de tu equipo.
Y uno no puede estar en la cabeza de las
personas ni en el corazón de las personas.
Entonces, también hay cosas que yo
desconozco pero en las que estoy dispuesto
a intentarlo.
Pero ¿qué pasa con mi equipo?
Mi equipo también se puede acercar y
decirme, oye, pero este proyecto que vamos
a hacer requiere esto, esto, esto y esto
que no conocemos.
Pero si tú estás convencido tú mismo de
que tu equipo lo puede hacer, cuando ya
estás convencido tú, es súper fácil
convencer a tu propio equipo de eso.
Lo haces, cuando nosotros partimos de la
empresa.
5 años atrás, teníamos un equipo de 6
personas.
Eran 2 desarrolladores front, 2
desarrolladores back, 1 ingeniera de
calidad y yo que oficiaba de Product 1.
Ese era nuestro equipo de ingeniería 5
años atrás.
Y un día nos sentamos 5 personas y con 5
personas construimos la primera versión de
Global 66.
Teníamos solo un producto.
que las remesas, ¿ya?
Pero nuestra primera versión tenía tres
orígenes y 60 destinos, ¿ya?
O sea, igual era un producto.
Entonces, imagínate cómo fue esa
conversación, Robi.
Oye, estamos aquí, los seis, no hay nada,
no hay nada.
La empresa no tiene nombre todavía, no
tenemos una arquitectura tecnológica, no
tenemos procesos definidos, pero
necesitamos construir una plataforma de
servicios financieros globales.
Entonces, imagínate los miedos de todo.
Pero creíamos tanto en el propósito,
estábamos tan conectados entre nosotros,
teníamos tan clara la visión, estábamos
tan seguros de que era un impacto positivo
que podíamos lograr en el mundo, que nos
lanzamos a sernos.
Entonces el propósito nos movilizó y todos
teníamos un montón de temores, era primera
vez que para muchos de nosotros, muchas
cosas técnicas.
Y lo hicimos igual, y lo hicimos igual.
Y los miedos ahí quedaron y el propósito,
digamos...
Usted decía, hizo como un override de
todos los miedos que teníamos.
Y lanzamos la primera versión de Global.
Era una plataforma de tecnología que no
conocíamos, con un montón de lenguaje de
programación, por ejemplo, que no
conocíamos.
Y y dale, y lo hicimos.
Y el propósito ganó, digamos.
El propósito le ganó a los miedos cuando
construimos la primera versión de Global
66.
Super.
Entonces, para terminar...
Si no hay otra historia, ¿qué quieres
contar antes?
¿Lecciones o recomendaciones para la gente
escuchando que son liderando proyectos?
O necesitan buscar una persona para
liderar un proyecto.
Vale, a ver, una es no seguir ninguna
tendencia o no tomar ninguna decisión de
metodología en función a la tendencia o a
lo que esté de moda o a lo que, digamos,
ahorrarte incomodidad.
La mejor metodología es la que mejor
funciona para tu equipo.
Tienes que hacer un discovery de qué es lo
que mejor funciona para tu equipo y para
la naturaleza del proyecto.
No casarte con lo que estemos.
Esa es una.
Dos, el mejor o la mejor project manager
es una persona que es organizada, está
conectada con el propósito y no le tiene
miedo a nada.
Son esos tres skills y nada más que esos
tres.
Y tercero y último te diría, propósito.
El propósito es algo demasiado potente.
O uno cuando imprinde y cuando crea
productos digitales y cuando desarrolla
tecnología, te encuentras con tantos,
tantos obstáculos, problemas técnicos,
relaciones interpersonales, cosas legales,
un sinfín de cosas.
Pero calma, si tienes ese motorcito ahí
como de propósito claro, ese motorcito te
va a llevar por cada uno de esos
obstáculos y los vas a pasar.
El propósito es algo demasiado potente y
te ayuda a navegar todas las complejidades
del emprendimiento.
¿Sabes algo interesante con propósito,
Mauricio?
Es que...
es una palabra completamente de bullshit
hasta que tú encuentres.
Es cuando definitivamente tú dices, oh
shit, esto es que están hablando.
Pero si no tienes gente escuchando, es
like, fuck, otra vez a propósito.
Pero cuando tú encuentras, oh, OK, este es
porque está levantándome en la mañana.
Este es como tu familia, tus días, el
evento que definitivamente puedes tocarlo
un poquito, es tangible.
Ah, esto es que porque ellos están
hablando tanto de eso.
Pero cuando no tienes, es invisible, es
como...
Esfímulo.
Ese es el problema.
Estoy muy de acuerdo y te voy a decir algo
que es muy cliché pero es muy real.
Uno no sabe lo que es el amor hasta que se
enamora.
El propósito es lo mismo.
Los problemas son reales.
O cuando uno logra encontrar el problema
que quiere resolver, el problema es real.
La solución es irreal porque no existe
todavía.
Y la misión de nosotros es construirla y
hacerla una realidad.
Genial.
Olvilamos algo maricio o no?
Agradecerte nuevamente la invitación, a mí
me encanta hablar de estos temas y te
agradezco mucho la invitación a ti y tu
audiencia.
A vos, brutal.
Si te gozaste este podcast y te gustaría
escuchar más, ojalá que sí, por favor,
déjame saber qué invitados, qué temas y
qué preguntas te gustaría que matemos.
Déjame un mensaje aquí, ¿sí?, en Spotify o
en cualquiera de mis redes sociales usando
arroba Robi J Fry.
Muchas gracias por escuchar y siempre
puedes ganar más plata.
pero no más tiempo.
Chau chau chauuuu yu y
¡SUSCRÍBETE!