logo

midulive


Transcribed podcasts: 746
Time transcribed: 15d 5h 20m 39s

This graph shows how many times the word ______ has been mentioned throughout the history of the program.

A ver qué opináis de este vídeo, ¿vale?
Y os voy a dar mi opinión al respecto.
Este vídeo.
Ojo, ¿eh?
Ojo con este vídeo.
Dicen, no hay página que se tarde seis meses.
Ni Uber, ni Talabat, ni Zomato.
No hay app ni web.
Un equipo dedicado trabajando solo en un proyecto
y puedes construir casi cualquier cosa
de cuatro a ocho semanas.
De verdad, no estoy bromeando.
Estoy hablando de página web y aplicación.
Tienes un equipo de tres o cuatro ingenieros,
buenos desarrolladores, buen frontend, diseñadores.
Y en un máximo de tres meses
puedes crear la plataforma más compleja del mundo
y más rápido.
Así que, ¿qué os parece esto?
¿Qué os parece?
Dice Danny Delson, factos.
Factos, ¿sí?
¿Creéis que esto es factos?
¿Factos?
¿Creéis que es verdad?
Esto lo dice, no sé quién es.
Entonces, dice, claro, ¿qué pasa?
Yo es que esto me lo han pasado.
Me lo han pasado en Instagram.
Aquí no habla de un MVP.
No habla de un MVP.
Aquí habla de un Uber.
Dice, aquí, fijaos que dice,
no hay una página web en el mundo
que necesite seis meses para desarrollarse.
¿Sabes?
Dice, no hay una página web en el mundo
que necesite seis meses en desarrollarse.
Dice, no Uber, no Talabat.
Que no sé qué es Talabat, tío.
Talabat.
Primera vez que lo escucho, ¿eh?
Talabat.
A Food Delivery, ¿esto qué es?
De la India.
De la India, vale.
No Talabat.
No Zomato.
Tampoco sé qué es Zomato.
Me suena a Tomato, pero no es Tomato, obviamente.
No sé qué es esto, pero tiene buena pinta.
No Tomato, ¿vale?
No.
Si tienes un equipo dedicado,
trabajando solo en un proyecto,
puedes hacer que construyan casi cualquier cosa
en cuatro o ocho semanas.
Cuatro o ocho semanas, ¿eh?
Cuatro o ocho semanas.
Depende de los recursos disponibles, dicen por aquí.
Odio cuando generalizan así.
Me parece muy buena lectura esa,
porque la verdad es que a mí, o sea,
en cuatro semanas no he encontrado
ni al equipo necesario.
Qué buena esa, JMC.
Qué buena, qué buena es esa,
porque estoy súper de acuerdo con eso, ¿eh?
Equipo de venta de personas.
La verdad es que no estando por un número,
muchas veces, a ver,
por más gente que tú vayas añadiendo,
al final no desarrolla mucho más rápido.
Llega un momento de que por más gente
que tú metas a un proyecto,
la cosa no va más rápida.
Debe hablar de un MVP,
pero es que no parece que hable de un MVP,
porque podría hablar de un MVP
y no parece que hable de un MVP.
Porque yo diría,
sacar un MVP de Uber y tal,
en cuatro o ocho...
Pero claro, dice,
no hay página web que no puedas hacer
en cuatro o seis semanas.
Me parece un poco, ¿sabes?
Que no escuche tu jefe.
Solo el diseño.
A ver, yo la verdad,
dice casi cualquier página.
Un equipo de Midus.
Mira, da igual, ¿eh?
Da igual.
Mira, os voy a decir,
yo me imagino que muchos de vosotros
conocéis Pareto.
No sé si sabéis lo que es
el principio de Pareto.
Es un principio muy importante
en el mundo de ingeniería,
pero bueno,
es también utilizado
en cualquier cosa.
Conocéis el Pareto, ¿no?
El 80-20, efectivamente, ¿no?
O sea, el principio de Pareto,
conocido la regla del 80-20,
la ley de los pocos,
de los pocos vitales,
como queráis entenderlo.
El 80-20, ¿no?
El principio de Pareto
es un fenómeno estadístico,
básicamente,
en el que dice,
hablaba de la población, ¿no?
Pero básicamente dices
que en el 80%,
por ejemplo,
el 20% de la población
tiene,
se reparte el 80% de la riqueza
y el 20% restante
de la población
tiene el 80%.
O sea,
básicamente habla de eso, ¿no?
De los 20-80, 80-20.
Y esto es como cualquier cosa.
O sea,
el 20% de propietarios
poseen el 80% de las tierras
y el 80% restante
poseen el 20, ¿vale?
Básicamente,
eso es como todo.
Y el 1% tiene el 80, ya, ya.
La verdad es que Pareto
no es una regla exacta,
no es una ciencia exacta,
pero en el mundo de la programación
sí que es verdad
que seguro que os ha pasado
muchas veces
de que estáis hablando de,
por ejemplo,
ostras,
tienes una tarea
en la que tú tienes este sentimiento
de que avanzas muy rápido.
Y, por ejemplo,
puedes pensar incluso
en una aplicación muy grande
como puede ser Uber.
Puedes pensar
que Uber,
tú desarrollar Uber,
el 80,
desarrollar el 80% de Uber
puede llevarte
el 20% del tiempo.
Pero desarrollar
el 20% restante,
que es lo que marca
la diferencia,
es lo que te lleva
el 80% del tiempo.
¿Entendéis?
Eso es un poquito
la trampa que hay.
Porque muchas veces
tienes la perspectiva
de qué rápido voy,
no sé qué,
pero es porque al principio
cuando estás en un Greenfield,
porque al principio
vas como mucho más rápido.
Entonces,
yo creo que en esto
esto es bastante
y le suele pasar
a gente especialmente
que no tiene experiencia,
¿no?
En el mundo del desarrollo,
a lo mejor tiene experiencia
en negocios o lo que sea,
pero no eres capaz
de encontrar
ese síbil
un poco en el desarrollo.
Dedicas el 80% del tiempo
en hacer el 20%
de las funcionalidades.
Efectivamente.
El MVP sale,
claro,
por eso muchas veces
los MVPs,
que es a lo mejor
lo que tiene
el 80%
de lo importante,
lo haces en un 20%
del tiempo,
pero luego
es lo que te cuesta
realmente ahí
y hay que picar piedra.
Yo la verdad,
sinceramente,
con lo que ha dicho aquí
lo que comenta este hombre,
me encanta
porque pone aquí
dislike button.
Pues mira,
like.
Podcast clowns,
I guess you are not a developer.
Esto es por la razón
que el 98%
de las startups fallan.
Estoy bastante de acuerdo
con esto,
estoy bastante de acuerdo
con esto
porque muchas veces
el problema que tienen
las startups
es infravalorar
el esfuerzo
que hay detrás
de las cosas.
Y esto,
a ver,
que levante la mano,
que levante la mano
quien no la ha pasado
alguna vez,
que ya sea
un product owner,
manager,
quien sea,
infravalora
el esfuerzo
que tiene una tarea.
MVP,
most valued player,
no,
hombre,
un MVP
no es solo eso.
Un MVP puede...
Obvio,
con un sueldo
de un año
yo lo hago solito,
jaja.
Hombre,
tú solito,
me gustaría ver,
me gustaría ver.
Un MVP es un
minimum viable
viable product,
o sea,
el producto mínimo
viable.
Eso es un MVP
cuando hablamos
de desarrollo
de aplicaciones
y webs,
¿vale?
Quiere decir
la funcionalidad básica
con la que ya puede
hacerse funcionar
la aplicación.
Y eso
le ha pasado
a todas.
No tanto una demo,
que es algo distinto,
porque una demo
sería una demostración
de lo que puede hacer.
Un MVP
sería una primera
versión funcional.
Por ejemplo,
mira,
imaginemos Airbnb.
Airbnb,
un MVP
podría ser,
podría ser,
un MVP,
¿vale?
Podría ser
que en lugar
de poner cualquier lugar,
solo pudieses
utilizar Barcelona.
Imaginad
que solo,
solo podéis,
pues,
solo podéis reservar
Barcelona.
Pues,
bueno,
pero ya podría reservar
en Barcelona.
Y además,
llegada y salida,
vale,
sí que puede funcionar,
llegada y salida,
pero a lo mejor
de viajeros
solo,
no hay ni siquiera esto.
¿Por qué?
Porque solo,
es para dos,
es para parejas,
solo para dos personas,
¿vale?
Y además,
pues,
una vez que buscas,
pues,
no tienes el mapa,
pero sí que salen las fotos,
¿no?
Y una vez que tienes las fotos,
pues,
bueno,
sí que puedes reservar,
pero no tienes,
a lo mejor,
pues,
no conoces al anfitrión.
Funcionar,
funcionaría,
pero estaría más limitado.
Entonces,
no sería tanto como una demo,
porque una demo es más
el hecho de demostrar algo,
pero no te garantiza
que puedas terminar el funnel completo,
porque una demo al final
incluso puede ser hasta un vídeo,
o puede ser algo
que parece que funciona,
pero no funciona.
Sería más bien
una versión recortada
de funcionalidades,
de algo,
pero que sí que funciona.
Eso sería el tema.
Comprendido,
es Barcelona para dos parejas.
Efectivamente,
Barcelona para dos parejas.
Bueno,
pues eso.
Yo hago muchos MVPs,
entonces.
Bueno,
muchos hacemos MVPs muchas veces,
así en la vida.
Ya hemos hablado de lo de
web developers,
pero que no te tienes que preocupar,
básicamente.
Un MVP tampoco tiene pruebas de estrés.
Claro,
es que un MVP,
está muy bien un MVP,
porque muchas veces
así te das cuenta
si realmente tiene encaje
tu producto,
si hay interés,
y ahí,
a partir de ahí,
ves si hay que escalarlo,
si tienes problemas de escalabilidad,
todo este tipo de cosas,
¿no?
Miru,
siempre he querido saber
cómo hacen la trazabilidad
de los vehículos
y tiempo que tardan
en llegar a un destino,
así como Uber.
El tema de trazabilidad,
todos tienen un GPS
y tienen conexión a internet.
Y el GPS lo que hace
es ir enviando constantemente
la localización.
Y el tiempo que tarda
en llegar a un destino,
esto incluso pueden utilizar
una API ni siquiera suya.
Pueden utilizar APIs
como por ejemplo
Google Maps y tal,
donde tienes el origen
y el destino
y ya te dice el tiempo.
Punto.
Ya lo tendrías.
O sea,
no hay,
quiero decir,
que seguramente
tienen servicios propios
pero que no tienen
la necesidad.
En un MVP seguramente
utilizarían la API de Google
totalmente.
¿Vale?
Pues eso,
no me gustan este tipo
de mensajes.
Esto de tardaría
tres meses,
seis meses y tal.
La verdad es que
aunque no lo parezca,
aunque no lo parezca,
hay mucho,
mucho,
mucho,
mucho más trabajo detrás
a la hora de crear
productos.
Yo creo que se infravalora
mucho
y ahora con inteligencia
artificial más.
Igual que se infravalora
JavaScript,
pues yo creo
que se infravalora
mucho el trabajo
real que tiene
el desarrollar
una aplicación
o una web.
Me parece que
un montón,
un montón.
Así que no sé,
a mí este tipo de cosas,
sobre todo gurús de negocios
que hablen de desarrollo,
que Uber
lo pueda desarrollar
de cuatro a ocho semanas,
incluso no en BP,
incluso no en BP
poco me parece,
sinceramente,
sinceramente.
Office
MB
MB
MB
M.
M.
M.
M.
M.