Créditos:
Reconozco abiertamente que me subo por las paredes cada vez que veo esos artículos sobre la cantidad de dinero que se mueve en el negocio de la mHealth. Lo digo porque soy tan obtuso que en lugar de salir a brindar con champagne (y eso que no me gusta), intento rascar más allá de los titulares a ver qué hay, y cuánto más rasco, más me pica. Sí amigos, en el mundo de la movilidad y las apps hay gente amasando auténticas fortunas. Lo que pasa es que hay más bien tirando a poca, y son siempre los mismos.
Y eso es lo que os voy a contar hoy. En fin, que si te gusta el tema de las Apps y la salud, te recomiendo que no sigas leyendo, a lo mejor te vas a llevar una desilusión. La vida puede ser mucho mejor si pulsas aqui.
Traigo noticias, y no te van a gustar (Imagen de tellmewhat)
Según Gartner publicaba en Septiembre de 2013 el negocio de las Apps generará unos ingresos de 26.683 millones de dólares, entre Apps de pago, compras desde las Apps, y publicidad. ¿Cómo se reparten estos ingresos? Pues se reparten mal, muy mal.
Para empezar, según los análisis de App Annie, el 80% de los ingresos en Google Play se generan en la categoría de Juegos mientras que en iTunes, el porcentaje es ligeramente menor. Los juegos se llevan sólo el 75% de los ingresos.
Vamos a empezar a quitar parte del pastel. El 27% de los ingresos se obtienen en Google Play, y el 73% en iTunes según los datos de Distimo. Aplicando estos valores tenemos los siguientes datos:
Pero claro, es que los juegos representan sólo el 17% de las Apps en iTunes y el 14% en Google Play. Eso quiere decir, que estadísticamente:
¿Comor? ¿Me estás diciendo que para ganar 6.500€ tengo que hacer una versión iOS y otra Android? (Imagen de Wiedmaier)
¿Cómo que ganar 6.500€? ¿Qué pasa, que las Apps se hacen gratis ahora o qué? Descuenta lo que hayas tenido que invertir para hacer esas Apps. A ver qué queda. O cuánto debes. Ah, que no sabes cuánto cuesta hacer un App. A lo mejor aquí te puedes hacer una idea aproximada.
«Pero bueno, Guardiola, vamos a ver. Intentas decirnos que esto de las Apps no es un negocio y no vas a ser tú ahora más listo que los analistas internacionales. Que están todo el día diciéndonos la pasta gansa que se va a mover en el negocio de las Apps móviles relacionadas con la salud»
No, si yo no dudo que se mueva dinero. Si lo que dudo es que vayas a moverlo tú. Bueno, vamos a hacer las cuentas de otra manera. Vamos a ir directamente al grano de la salud. Los analistas estimaron que en Apps de mHealth se iban a generar unos ingresos de, atención, 1.300 millones de US$ en 2012. Como veis, la cifra no va muy desencaminada, pero vamos a hacer las divisiones por las Apps de la categoría adecuada. Pero espera, es que la categoría adecuada es la combinación de Medical y de Health & Fitness.
No se han leído el Harrison, pero seguro que consigen más descargas (Imagen de Rev. Voodoo)
Efectivamente. Según esto, en iTunes hay nada más y nada menos que 23.701 Apps de Fitness y Salud, y 19.499 Apps Médicas, dando un total de 43.200 Apps de mHealth. Y en Google Play, otras 31.279. Curiosamente, de todas esas Apps, más del 60% de las descargas corresponden a Apps de ejercicio, entrenamiento y pérdida de peso según datos de IDC Health Insights. El 12% están relacionadas con la mujer (salud de la mujer y embarazo) y otro 12% con referencia médica.
Pero bueno, hagamos las cuentas partiendo de esa cifra.
Parece que la cosa ha mejorado, ¿verdad? Pues la verdad es que no. Lo que no os he dicho porque soy muy cuco, un poco sofista y me gusta que nos demos de bruces con la realidad es que esa cifra de 1.300 millones de $ amigos míos incluye:
En fin.Es difícil valorar qué % responde exactamente a los ingresos que genera un App de mHealth. Pero nos hacemos una idea, ¿verdad? Más bien tirando a poco.
El mercado de la movilidad es duro, salvaje y difícil. Hay demasiada gente intentándolo. Hay mucha gente perdiendo dinero. También hay gente que se está forrando. En 2012, Canalys llegó a la conclusión que 25 publicadores de Apps se llevan el 50% de los ingresos; hablamos de empresas como Electronic Arts, Disney, Rovio, Gameloft… Empresas que entre ellas ingresaban 60 millones de $ en 20 días. ¿Y el resto? ¿Sabes que en sólo en iTunes USA hay registrados más de 251.000 publicadores?
Teorema de Pareto de las Apps: El 50% de los ingresos es generado por el 0,009% de las empresas
En el siglo XIX California vivió la denominada Fiebre del Oro (Gold Rush) Durante 7 años, más de 300.000 mineros se lanzaron a buscar oro por montes y rios. Durante ese tiempo las ciudades crecieron, se desarrollaron nuevas leyes y nuevas técnicas para encontrar el oro, murieron cientos de miles de nativos americanos y se hicieron toda clase de daños medioambientales. Se estima que en 5 años se sacaron 370 toneladas de oro. Lo curioso es que los estudios demuestran que los que realmente se beneficiaron de la Fiebre del Oro fueron los comerciantes, transportistas, constructores, políticos… y los dueños de bares y burdeles, claro.
Nos han rechazado el App, Jebediah, mira que te dije que lo probases en iOS7 (Imagen de Mike Overall)
Pues con las Apps pasa lo mismo. Estos números apestan. Lo mires por donde lo mires. Los números no salen. Hay una última cuenta que quiero hacer, para que la imprimas y lo pienses 2 veces la próxima vez que quieras hacer un App. Vuelvo a los datos del principio. A los de descargas gratis y descargas de pago que decía Gartner.
Esos son los números que tienes que tener en cuenta cuando hagas tu App. ¿Cuántos miles de descargas necesitas para recuperar tu inversión? ¿Y para ganar dinero? Pues ahora tira esa cifra a la basura, porque no has contado con lo que tienes que invertir en posicionar tu App para que la gente se la baje.
Si has llegado hasta aquí, entonces felicidades, porque sabes cómo está el patio. Atado al mástil, has sobrevivido a los cantos de las sirenas que intentaban atraerte a los acantilados de su isla para hacerte naufragar y luego devorarte. Ya sabes lo que hay detrás de esos números tan grandes.
Ahora piensa qué vas a hacer para que la gente se baje tu App, compre tu App, use tu App, recomiende tu App. Piensa en cómo vas a ser diferente, en por qué tu App va a ser la que funcione.
No sé cuál es tu modelo de negocio. No sé si tu App de mHealth te la va a pagar el Estado, o se va a financiar con las cuotas de los asegurados. No sé si la planteas como una inversión en Marketing super segmentado, o quieres crear una base de usuarios para explotarla. No sé si quieres obtener ingresos por descarga o compras en el App, o es una herramienta que complementa un negocio tradicional de venta de dispositivos o consumibles.
No lo sé, pero no importa. Por que la buena noticia es que todos ellos pueden funcionar. La buena noticia es que hay gente que lo está haciendo. Otro día os contaré el caso de:
Y todas ellas están en la categoría de mHealth. Pero eso será otro día. ¿Ya sabías cómo funcionaba esto de las Apps? ¿Has hecho un App de mHealth? ¿Cómo te está yendo?
PS1- Como en todos los post de la categoría Money Talks, ampliamos el repertorio de temazos del rock relacionados con el vil metal. Esta vez, una buena recomendación de la mano de la Steve Miller’s Band
Una imagen vale más que 1.000 Ads
Estoy bastante cabreado, desde el viernes pasado Google ya no me resalta los Ads en los resultados de búsqueda. Sólo me pasa en el Mac de la oficina, pero lo hace en Chrome, Safari y Firefox. En casa de momento no me han aplicado esta «upgrade«. Así que me he instalado la extensión de AdBlockPlus, y he activado la opción de que no me muestren publicidad no intrusiva.
Cómo he podido vivir todo este tiempo sin esto…
Ojalá me dieran un euro cada vez que escucho que «el proyecto está mal vendido«. Junto con «en mi local funciona» es la segunda frase autocomplaciente más habitual del mundo, forma parte del acervo popular de descarga de responsabilidad. Es curioso, porque a las personas más brillantes que conozco nunca se lo oigo decir, pero bueno. Cosas mías.
A mí me encanta escuchar que un proyecto está mal vendido, y como los que me conocéis sabéis que no me callo, siempre respondo con un habitual «¿y tú cómo has ayudado para que estuviera bien vendido?«. ¡Un momento! Guardiola, ¿no estarás insinuando que los técnicos tienen que participar en el proceso de venta? ¡En absoluto! No lo insinúo, lo afirmo categóricamente.
No le preguntes a Kennedy qué puede hacer por tus proyectos, pregúntatelo a ti mismo
No me lo puedo creer. Técnicos involucrándose en el proceso de venta. ¿Pero no habíamos dicho que los técnicos son los que ejecutan y los comerciales los que venden? También habíamos dicho que los comerciales no tienen ni puta idea de lo que venden, y a lo que se dedican es ir a comer y tomar cafés con gente mientras los demás partimos teclados a base de programar. Tranquilos, en este post no voy a revindicar el trabajo del comercial (sólo faltaba)
No, este post vuelve a tratar sobre cosas que son necesarias para uno mismo, y que tengo que hacer aunque no me gusten, sea como sea, porque me acerca a mis objetivos.
En general un proyecto se vende de dos maneras: o porque alguien te llama y te lo da, o porque tienes que competir con otros para conseguirlo. En casos de proyectos TIC, la cosa va más allá. Estamos en un mundo en el que la calidad del software cada vez pesa menos como factor a la hora de la toma de decisión de compra. Especialmente en el Sector Público, donde se ven concursos en los que la oferta económica es el 60% de la puntuación. Casualmente, los responsables de esos organismos se lamentan de la baja calidad del software que reciben, de lo mal pagados que están los profesionales, de lo mal que está el sector TIC… En fin, todo muy coherente.
Lo mejor es no hacer caso a las voces (Imagen de rocksss)
El caso es que acreditar la capacidad técnica parece que se ha convertido en condición necesaria, pero no suficiente; lo que significa que al final hay que hacer una oferta técnica: demostrar que se ha entendido el problema, plantear una solución que tiene sentido, identificar el equipo que lo va a lograr y poner un precio. Así que señores, si los comerciales no tienen ni puta idea de lo que venden, tendrán que ser los técnicos los que se pringuen y aporten la solución técnica. ¿Y por qué querría un técnico ayudar a conseguir un proyecto? Principalmente por dos motivos, a cual más egoísta que el anterior.
Si no tienes claro que el dueño de tu carrera profesional eres tú mismo entonces necesitas urgentemente un choque con la realidad.
Siempre que he hecho entrevistas a candidatos me ha gustado decirles las cosas claras; y una de ellas es que no les puedo garantizar que los proyectos en los que vayan a participar vayan a ser interesantes. Obviamente, el primero siempre tiene que tener ese punto que haga que alguien deje su trabajo para empezar en un sitio nuevo. Pero una vez acabado… (porque sí amigos, los proyectos acaban) pues no se puede saber. En una empresa de software hay de todo, apuesto que hasta en la NASA tienen tanto proyectos virgueros de microprogramar vehículos de exploración en Marte como mantenimientos evolutivos del sistema de nóminas, y nadie quiere caer en el segundo.
Aparta tus sucias zarpas de mi carrera profesional (Otra imagen de gatitos, esta es de pippy & timmy)
Eso quiere decir, que un programador egoísta que se preocupa por sus objetivos personales tiene que tener claro que no puede dejar en manos de un comercial que no tiene ni puta idea la capacidad de acceder a proyectos interesantes.
Cuarta Ley del Programador Egoísta: Si quieres participar en proyectos interesantes, no te quedes esperando a que te caigan del cielo.
Así que la próxima vez que te pidan ayuda para preparar una propuesta, destierra de tu cabeza los pensamientos autocomplacientes como:
Si no te parece suficiente, aquí viene el segundo motivo. Es todavía más duro que el anterior.
Exacto. No hay mayor muestra de inteligencia (emocional o no): si vas a acabar metido en el proyecto más te vale asegurarte que se va a hacer como crees que debe hacerse, porque al final, el que va a estar metido en la trinchera vas a ser tú. Así que por lo menos, encárgate de decirle al Teniente cómo tiene que ser la trinchera, dónde hay que tender las alambradas, cuántos sacos terreros necesitas para protegerte del fuego enemigo, cómo disponer las Vickers para que tengan mejor campo de tiro, y qué vas a hacer si el enemigo usa Gas Mostaza. Si no lo piensas tú, no te preocupes, otro lo pensará por tí.
Oh My God! Aquí pone que vamos a desarrollar un gestor de contenidos a medida en 3 jornadas… ¡Malditos comerciales! ¿Por qué no habrán metido un Joomla?
En general, como norma de vida, nunca pierdas la oportunidad de definir cómo debe ser cualquier puzzle en el que seas una pieza. Al final, todo el mundo opina sobre un proyecto: precisamente de eso trataba el primer título de este post. Opinar está muy bien, pero las personas con objetivos además de opinar actúan.
Quinta Ley del Programador Egoísta: Aprovecha cualquier ocasión que tengas para que los proyectos se vendan como tú crees que deben venderse.
Esta Ley tiene un Corolario:
Corolario a La Quinta Ley del Programador Egoísta: Si pudiste implicarte en la venta de un proyecto, pero miraste hacia otro lado, a nadie le va a importar lo mucho que te quejes luego.
Porque al final, el mundo de los proyectos se basa en que primero se vende y luego se ejecuta; al contrario que el mundo de los productos. Tienes dos alternativas: trabajar para conseguir llegar a tu objetivo de aprender y trabajar en proyectos cojonudos ( y lograrlo, o no), o confíar en que alguien lo va a hacer por ti (y a ver qué pasa). Sólo en una de las dos alternativas puedes llegar a tener control: espero haber dejado claro que a mí la que me funciona es la primera.
«… we are here to help the developers, because inside every freakie there is a presales trying to get out…» (Imagen de eks4003)
Por último, me gustaría recordar a todos los desarrolladores (egoístas o no) que por encima de las leyes de los programadores, hay una Ley Universal de las empresas de servicios.
Ley Universal de las Empresas de Servicios: La venta nunca se para. Las ofertas se presentan se impliquen o no los técnicos que las van a hacer.
Espero que la próxima vez que os pidan ayuda para preparar una oferta seáis un poco más egoísta, penséis en vuestro propio beneficio, y lo hagáis.
Tengo una entrada a medio escribir sobre el tema de monetizar Apps en el proceloso mundo del #mHealth, pero he tenido que dejarla parada. Sí, es que este post se me ha colado en el camino, qué queréis que os diga. Podría inventarme alguna historia sobre que mi perro se comió mi MacBook, pero desde algunos años no tengo perro.
Lo cierto es que el otro día, como dice la entradilla, me invitaron a una reunión del Club Gertech un Club de Debate sobre Tecnología formado por Gerentes y directores del ámbito sanitario. Fue una reunión de lo más interesante, me hubiese gustado participar un poco más, pero también me gustaría que me invitasen a la siguiente, así que fui un buen chico 🙂
El caso que salí del encuentro en plena ebullición de ideas, pero con todo el lío del Encuentro que organizamos desde MediaNet en la UIMP no he tenido tiempo de pensar en ellas ni 5 minutos; como no quiero que se me olvide, me salto mi línea editorial para hablar de ello.
«May you live in interesting times», una maldición china que podría ser gitana (Imagen de kevin dooley)
Me gustó una de las reflexiones finales de D. Joaquín García Guajardo (@quinoguajardo), que apuntaba que si se hiciese el DAFO del mHealth, «las Oportunidades superarían ampliamente a las Amenazas». Así que después de fusilar la frase para el título del post, os cuento un poco.
La primera intervención de la jornada corrió a cargo de Esteban Moro (@estebanmoro) para hablar sobre redes sociales, el big data que alimentan cada minuto decenas de miles de personas y que está ahí, al alcance de cualquiera que le interese cogerlo, procesarlo y darle valor.
Gracias a la información que se obtiene de twitter de manera profesional a través de sus canales oficiales (GNIP y DATA SIFT), a la razón de 1$ cada 10.000 tweets en el caso del segundo, el grupo de Esteban Moro es capaz de analizar y georeferenciar la incidencia de enfermedades como la gripe. ¿Cómo? A través de la inteligencia semántica que puede aplicarse sobre esos 140 caracteres que la gente va por ahí publicando alegremente cuando tiene fiebre o le duele el cuerpo.
Pues vaya ful. Mis 9.871 tweets se podrían comprar por menos de un dollar (Imagen de Images_of_Money)
Si lo piensas, tiene todo el sentido del mundo. ¿Qué es lo que se supone que quiere el sistema sanitario? Por lo que veo en la tele, evitar el colapso de sus diferentes niveles, y si no se puede evitar, por lo menos que se preste la atención de la forma más ordenada posible. En general, si le preguntas a cualquier médico, lo que te dirá es que él en sí mismo es un recurso escaso, cuyo uso debe optimizarse en la atención de aquellos casos importantes, y no malgastarse en casos que no lo necesitan.
A mí utilzar la información que sale de twitter para conocer si hay picos de propagación de la gripe, si va por barrios, si pueden planificarse campañas, o adaptar los recursos a la necesidad real… Por ejemplo, haciendo que se refuercen los médicos de atención primaria en determinados centros, o llevando más dosis de la vacuna a unos que a otros, o empezando las campañas de vacunación antes, o después… Pues no se, a mí me parece que tiene ventajas para todos: para los pacientes, para los profesionales, para los que gestionan, para los que ponen la pasta…
Claro, montar algo así yo imagino que debe ser complicado. Imagino que habría que hacer alguna clase de comité que agrupe a gente de atención primaria, de hospitales, de servicios centrales… Y luego un comité para analizar las recomendaciones del comité. Ya se sabe cómo va esto.
Pues no… Por lo visto el problema no va a ser ese, viene un poco antes: en la viabilidad de obtener y procesar datos de salud obtenidos de una red social. Y claro, yo abro tuiter, veo que la gente dice lo que le da la gana y lo suelta en Internet, así, en abierto. Para que todo el mundo sepa que está acatarrado, le han operado del riñón, o el feto tiene ya 20 semanas y mira, parece que se le ven los huevecillos. Y es que les da igual su privacidad; porque por mucho que nos duela, vivimos en una sociedad que renuncia tranquilamente a su privacidad, no le interesa leerse los términos de servicio de nada, y además, si no renuncia le da igual porque se la quitan.
Who Watches The Watchmen? (Imagen de FlintWeiss)
¿Nadie se ha parado a pensar que si lees twitter con el cliente para móvil, te bajas un tuit de uno que dice que tiene un herpes, te desconectas de internet, sigues viendo ese dato? Osea, que cualquiera de nosotros vamos por ahí con una base de datos con información LOPD nivel 3, puesto que incluye datos relativos a salud de personas que podrían ser identificables. Nos salvamos porque en el ámbito de actuación de la LOPD no intervienen los ficheros mantenidos por personas físicas en el ejercicio de actividades personales o domésticas. ¿Y si una empresa de regalos para recién nacidos se pusiera a navegar por tuiter escribiendo a la gente que dice que su mujer está de parto y el niño ya viene de camino? Me niego a creer que esto se me acabe de ocurrir a mí.
En fin, lo importante es:
Dicho lo cual, queda zanjado el tema de si se pueden aplicar técnicas de análisis y monitorización en redes sociales de datos relativos a la salud para optimizar la atención sanitaria; sí que se puede, así que ahora hay que ponerse a ello.
En cuanto a la presencia en redes sociales y la exposición al trolleo… Bien, la gente ya habla de hospitales y sanidad, y les trollea, estén o no en RRSS. Todo el mundo sabe que al troll no hay que hacerle caso, pasemos de los trolles y centrémonos en las personas que sí están interesesadas en interactúar.
La siguiente ponencia corrió a cargo del Dr. Julio Mayol (@juliomayol) a quién espero convencer para que suba a SlideShare todas esas presentaciones suyas tan interesantes, cargadas de datos y realidades sobre las que cimenta sus ideas y llamadas a la acción.
Trataba sobre las posibilidades que ofrece el smartphone en el mundo de la salud, por su capacidad de cálculo, dispositivos y sensores integrados o integrables, cámara y micrófono, etc. Teniendo en cuenta que prácticamente todo el mundo tiene uno de estos encima, ¿será posible dotar de utilidades al teléfono que aporten valor a la persona y al mismo tiempo ahorren recursos al sistema de salud? Parece que a priori lo raro sería no conseguirlo. En general, desarrollar una línea de Apps puede ser clave para que las personas vayan a los servicios de salud, primaria y especializada, cuando deban, y a ser posible, presentando información adicional que pueda ser aportada al sistema para su uso por todos los actores que interactúan con el paciente.
Qué manía os dado con que la gente no vayamos a los Hospitales (Imagen de San Diego Shooter)
Sin embargo, una de las cosas que más me sorprende en esta clase de debates sobre mHealth es el tema de la regulación. Es indudable que en materia de salud hay que mantener siempre una serie de requisitos. Por ejemplo, si estamos hablando de dosis de medicamentos, las personas tienen que tener la garantía que el App que le dice la dosis de apiretal al niño le está dando la cantidad adecuada. ¿Pero cuál es la forma de conseguirlo? ¿Abrir un proceso regulatorio que puede tardar años? ¿O mostrar al usuario los elementos que le den seguridad y garantías y decida por sí mismo?
Obviamente yo abogo por la segunda. Sobre todo por dos motivos:
Por cierto, escuché un comentario que me puso la carne de gallina; hacía referencia a la obligatoriedad de mantener piezas de recambio de los dispositivos médicos, y si cómo esto se debería aplicar a los smartphones. Sí, a los smartphones, esos cacharros que fabrican para que tires a la basura cada dos años y que detrás de las bombillas, las medias y las impresoras, son el culmen de la obsolescencia programada. En fin.
Bueno, como todos los post que tienen que ver con mHealth, vuelvo al tema del Observatorio. Ese Observatorio que tiene que poner al paciente en el centro de todo el lío; porque el paciente es el que se descarga las Apps. Si no se las descarga, no existen. Y si no existen, el resto de los planes se vienen abajo. Construir un mecanismo de eficiencia, ayuda a la gestión, optimización de recursos, mejora en la atención, ahorro de costes, etc, basado en Apps tiene que tener la orientación total a las necesidades del paciente. Una vez que quede claro por qué la gente se va a descargar y mantener en sus teléfonos tu aplicación ya se puede pensar en qué beneficios va a tener para los doctores y para el sistema.
Adivinad qué ocurre cuando lanzas productos sin pensar en las personas que los van a consumir (Imagen de Nima Badley)
Pero no, este no es el post del Observatorio. Todavía me quedan dos post más para contarlo.
A modo de conclusión, uno de los asistentes comentó que GerTech acumula entre sus socios unos 700 años de experiencia en la gestión sanitaria.
Lo malo del oro es que hay que bajar a picarlo (Imagen de GSofV)
Exacto, ese sitio es una mina de oro. Toda esa información sobre necesidades en el ámbito de la salud y la gestión hospitalaria debería ponerse al alcance de gente con iniciativa, ganas de solucionar problemas, capacidad de obtener financiación y sobre todo, capacidad de aportar valor. Últimamente se les llama emprendedores.
Una de las cosas que más echo en falta en los técnicos es el egoísmo. Se que es una frase fácil de malinterpretar, por eso quiero explicar a qué me refiero.
En general, en el mundo técnico he tenido la suerte de trabajar por norma con personas que se dejan la piel por ayudar a sus compañeros. Siempre he defendido que todos somos muy majos para tomar unas cañas y salir de copas (alguno incluso pagamos una ronda), pero a los compañeros se les conoce bajo presión, cuando las cosas van mal, no funciona nada, empiezan a llover las hostias y entonces se ve quién se arruga y quién tiene lo que tiene que tener.
Da igual que lo llames Scrum o Melé, sigue siendo una metodología ágil (Imagen de John_Scone)
También me parece fundamental, como parte del valor que aporta un profesional a su empresa, la actitud de dejar lo que se está haciendo para echarle una mano a un compañero que necesita ayuda. En MediaNet trabajo con esa clase de personas, igual que antes lo hacía en SATEC.
No entiendo nada, Guardiola, estás hablando de compañerismo y generosidad en un post que trata sobre el gen del programador egoísta; definitivamente se te ha ido la pinza; adiós.
Bueno, es que no me refiero a ese tipo de egoísmo. Me refiero al egoísmo que tiene que ver con hacer cosas que no me gustan, pero que tengo que hacer porque son necesarias para mí mismo. Y del egoísmo que tiene que ver con hacer cosas por las que no me pagan o para las que (creo que) no tengo tiempo, pero que tengo que hacer porque me gustan y si no las hago yo, las harán otros en mi lugar. Me refiero al egoísmo que viene del ego, del yo, de aquello que tengo que hacer sea como sea y cueste lo que cueste porque me acerca a mis objetivos. (Otra vez se repite la frase, acercarse a los objetivos de uno. Es la segunda que vez que la uso en el blog. No será la última.)
El gen del programador egoísta, o mejor dicho, el poco frecuente gen del programador egoísta, se materializa claramente como recesivo en dos situaciones que seguro que todos hemos vivido alguna vez; la primera de ellas la trataré en este post (y la otra la añado a la larga lista de post pendientes)
El gen del programador complaciente se manifiesta dominante frente al egoísta en todo lo que tiene que ver con pruebas e incidencias.
Los proyectos con presupuestos cerrados suelen ir bien hasta la semana antes del paso a producción, da igual que se usen metodologías ágiles o no. Todo va bien, las historias de usuario se completan, se va gestionando el cambio, a los usuarios todo les parece bien, y de repente un día alguien (generalmente el cliente) empieza a hacer pruebas y hay una estampida de incidencias que salen como setas. Por todas partes. Hasta el punto de que empiezan a tambalearse los cimientos, se comprueba con horror que el sistema está cogido con alfileres y no funciona nada.
Pues en mi entorno local funcionaba (Imagen de Drakegoodman)
Cada vez que un desarrollador dice frases como «pues cuando lo probé iba bien» o «en mi local funciona«, Dios mata un gatito. Si dice cosas como «es por un micro-corte de red que hace que se pierda la conexión con la base de datos«, Dios extingue una especie tropical (además de los habituales gatitos).
Si hacemos una encuesta entre 10 personas cualquiera que se ganen la vida desarrollando software, llegaremos a la conclusión de que lo más apropiado es que el aseguramiento de calidad de un sistema lo haga alguien diferente del que lo programó, por varios motivos, entre los que destacan:
Y aunque estoy a favor de que haya departamentos de QA que de manera independiente al desarrollo validen que esté libre de errores (o en su caso los detecten), lo ideal sería que los entregables que reciben estén como los chorros del oro; que se pudiera comer sopitas en ellos.
¿Y por qué no es así? Pues básicamente porque los cuatro motivos de antes se resumen en que el programador es auto-complaciente. Enseguida se convence a sí mismo de que todo está bien hecho, de que ha hecho lo que tenía que hacer, y si algo falla, es por culpa de otro que no hizo su trabajo bien, o no le pasó la información que necesitaba cuando la necesitaba, o que no le explicó detalladamente algo, o que no abrió un puerto en el firewall, o que le cambió una especificación dos días antes de terminarla… He llegado a oir que el error era culpa de la persona que hizo las pruebas, que no prueba bien el sistema y falla. #amazing
A lo que yo digo, vale, ¿y qué? Has hecho un desarrollo que tiene más agujeros que Bob Esponja así que da igual que le hayas echado cientos de hora de tu vida, la mala noticia es que no han sido suficientes porque todavía no has terminado: ahora lo tienes que arreglar.
¿A qué te refieres con eso de Plan de Pruebas, Bob? (Imagen de gspidermac)
La auto-complacencia es uno de los peores defectos que puede tener un profesional, pero se acentúa en el caso del programador. Hay dos situaciones en la que el egoísmo debe ser la clave para sobreponerse ante la auto-complacencia, sobre todo por los devastadores efectos que tiene sobre uno mismo.
Todos los que hemos programado conocemos el problema de la mochila; hay que hacer un algoritmo que permite tomar objetos de un determinado volumen y valor para llenPUES NO. Ese no es el problema de la mochila.
Cuando uno entra a una empresa y empieza a programar, va pasando por proyectos. Algunos serán más largos, otros más cortos; unos serán un reto, otros no tanto, y todos en general formarán parte de su trayectoria profesional. De cualquiera de ellos podrá recibir un día un correo electrónico (o una llamada, según la gravedad) indicándole que tiene que dejar lo que está haciendo porque tiene que resolver una incidencia en uno de los proyectos por los que ha pasado.
Todavía son becarios, y ya tienen sus mochilitas (Imagen de ewar woowar)
El problema de la mochila es una maldición intrínseca de las personas que se dedican al software: cuanto más avanzan en una empresa, mayor es el peso que llevan en su mochila, más posibles incidencias pueden surgir; y por tanto estadísticamente más veces va a tener que dejar de hacer algo, porque la única persona que puede solucionar un problema con garantías suele ser quién lo resolvió la primera vez.
Primera Ley Natural del Programador Egoísta. Las cosas no terminan hasta que terminan. Si quieres salir cum laude de un proyecto encárgate de que todo lo que desarrolles funcione; y cuando falle, arréglalo lo mejor posible para que puedas seguir adelante hacia tus objetivos.
La conclusión es que cuanto más riguroso seas contigo mismo y con tu desarrollo; es decir, cuanto menos auto-complaciente seas, menos peso llevarás en tu mochila.
La segunda derivada de la auto-complacencia en el desarrollo es el temido Síndrome del Proyecto Sísifo. Como todos sabemos, Sísifo era un rey que quería vivir eternamente, engañó a los dioses mientras pudo hasta que le trincaron, momento en el que le condenaron a subir una piedra hasta lo alto de un monte. Lo que pasa es que al llegar a la cima, volvía a caer hasta la base; y así por toda la Eternidad.
Ánimo, otro empujoncito y vaciamos el Jira (Imagen de ChuckSchultz)
En tecnología, llamamos Proyecto Sísifo a ese proyecto en el que salen errores como cucarachas, hasta debajo de las piedras, de forma que se establece un círculo vicioso que es difícil romper: no se sale a producción porque hay errores; al no cumplir los objetivos el cliente dice que ya que estás le haces unos cambios; por la sensación de falta de rigor en el desarrollo e inclumplimiento se termina por perder la capacidad negociadora; con lo que hay que asumir los cambios; por hacerlos deprisa y corriendo para no palmar pasta surgen nuevos errores; y así sucesivamente. Por toda la Eternidad.
Segunda Ley Natural del Programador Egoísta. Si detectas que esto se va a convertir en un Proyecto Sísifo recuerda la Primera Ley Natural del Programador Egoísta.
Que yo sepa, sólo hay 3 maneras de salir del Proyecto Sísifo:
La conclusión es que cuanto más riguroso seas contigo mismo y con tu desarrollo; es decir, cuanto menos auto-complaciente seas, más probabilidades de que el resultado de tu trabajo sea un éxito para tu cliente, para tu empresa, y por tanto, para ti mismo.
Se egoísta: piensa en tí mismo. Ojalá cada vez hubiera más gente convencida de que la auto-complacencia es uno de los mayores enemigos de la realización personal.
Tercera Ley Natural del Programador Egoísta: Si no te das una patada en el culo de vez en cuando, alguien lo hará por ti. Y te va a doler más.
Otro día escribiré sobre otra situación en la que las personas sacrifican aquello que les acerca a su objetivos. Mientras tanto, puedes aprovechar la sección de comentarios para decirme si eres o no un profesional auto-complaciente, si llevas mucho peso en tu mochila o si estás a punto de que la piedra llegue a la cima de la montaña.
Sé que «me tocaba» escribir un post sobre organización y gestión del tiempo; pero no me he podido resistir a hacer una pequeña actualización sobre el tema de las Apps de #mHealth gracias al excelente post de los chicos de Game Oven en el que hablan de las cifras de su juego de éxito, Fingle.
Bien, en este post tan interesante que os he enlazado, se dan algunas cifras que van en la línea de mi anterior post sobre monetización de Apps en mHealth, que (Dios me libre de citarme a mí mismo pero) es este Vamos a ver qué cifras son esas.
– Rigodón, no se cómo decirle a este chico que los caballeros no hablamos de dinero. – Es Passepartout si no le importa, Sr. Fogg (Foto de EssjayNZ)
Los datos que ofrecen sobre ingresos por publicidad son los siguientes:
- Fingle Free revenue: €3.110,- with 132.857 downloads (since December 2012)
- (…) Fingle Free’s average revenue was €17 / day
- About 2.3% of Fingle Free’s downloads convert to revenue. We’ve heard that’s a good number
Bien, lo que esto significa básicamente es que con 132.857 descargas de un juego han ingresado 3.110€, lo que supone que cada descarga genera un eCPM de 0,023€ a un CTR del 2,3% Algo en la línea de lo que habíamos comentado el otro día.
Pero claro, independientemente de que chapeau! por los amigos de Game Oven, a los que desde aquí mando en perfecto castellano un abrazo cargado de admiración, vamos a ver la otra parte de la ecuación. ¿Cuál ha sido la inversión? Podemos hacernos una idea combinando este otro post.
- Length of Development: 5 months
- Budget: €2000,- of our own money
- Fingle was made by 5 people of which two were full time employees of Game Oven and three with whom we set up a royalties contract.
- The two employees at Game Oven have been paid minimum wage for over a year
Hagamos una idea de los costes de desarrollo: 5 personas 5 meses, de las cuales dos cobraban un sueldo mínimo y las otras 3 van a comisión (el post cita una cifra X cada 10,000 descargas de pago) No seré yo el que diga aquí lo que debería costar un equipo de desarrollo de aplicaciones móviles de 5 personas 5 meses formado por profesionales de Experiencia de Usuario, Diseño y Desarrollo iOS, pero seguro que cualquiera os podéis hacer una idea buscando cualquier informe de los que publica Infojobs o Hayes al respecto.
A eso, hay que añadir los costes de promoción del App. Que tampoco son explícitos, pero se cita:
- The coolest thing we did was showing the game on national television for about three minutes, in a morning show mainly for women in their mid-life crisis
- Even with minimal effort, our game hit the newspapers but returned close to zero extra sales!
- Another thing we experimented with were Facebook ads. The problem was that for each $2 unit sold on Fingle, our return from Apple would be about €1, but in order for the ad to show up for the right target audience, we had to put in about €0.70 cents
- Promoter (paid & totally worth it)
- a press release to all western iOS-covering websites, including a presskit. We constructed a huge list of emails and submission forms with the help of Promoter’s index of games-covering website
- two narrative videos and one gameplay video found here, made with the help of filmmaker Gilles van Leeuwen
- a product specific website
- a newsletter to all the people who subscribed on the Fingle website
Todo ese esfuerzo de Marketing es difícil de concretar en una cifra, pero parecen los clásicos de una campaña de comunicación online/offline. Si alguien puede darme una cifra orientativa, se lo agradecería.
Pero lo que no os he comentado (todavía) y es lo verdaderamente importante, es que Fingle es un juego de pago, que al cabo del tiempo ha sido complementado con una versión gratuita con publicidad (y no al revés). Los datos de la versión de pago también están publicados:
Fingle revenue: €76.920,- with 117.611 downloads
Es decir, el App se financia como aplicación de pago, y el artículo deja claro que desde el 12 de Enero que salió la versión de pago hasta Diciembre de 2012 que salió la gratuita, seguramente los costes de desarrollo ya se habían cubierto y estaban en beneficios.
Twisting by the Pool (Imagen de KentonNgo)
A modo de conclusión, y para que no se me malinterprete, el éxito de esta App es que se vende como churros, y se ha conseguido posicionar como un producto por el que la gente paga. Pero no se financia como App gratuita con ingresos por publicidad, porque ese modelo no se sostiene, como quería comentar en el post del otro día; y como espero que haya quedado claro.
Ahm. ¿Significa eso que las Apps de mHealth tienen que ser aplicaciones de pago? Tampoco he dicho eso, especialmente si una App está desarrollada por un organismo público, como puede ser una Consejería de Salud; en cuyo caso habrá que ver exactamente cómo Apple o Google le hacen un ingreso a un número de cuenta corriente. Entro en cortocircuito sólo de imaginarlo.
Hay otros modelos, pero ya os dije que los trataríamos en otro post. No quiero despedirme por hoy sin dos comentarios:
Comentario número 1. Estamos en un post sobre Money Talks, y aquí viene otro temazo relacionado con el vil metal
Comentario número 2. Un dato adicional; «People confessing to have had sex after playing Fingle: 479 and counting» Perdonad que os deje, pero voy a ver si me echo una partidita 😉
Todos los meses reviso las discusiones sobre si es mejor o no hacer Apps nativas, y adivinad qué: exacto. Son discusiones que hacen técnicos para técnicos. En ninguna de esas discusiones he leído nada sobre la forma de obtener ingresos para las Apps.
Desde mi punto de vista, esa es la única cuestión a tener en cuenta a la hora de hacer un App: ¿esperas conseguir dinero con ella? Un momento, ¿he dicho la palabra dinero? No era mi intención, lo prometo, los caballeros nunca hablan de dinero.
Mr. Datta Phuge tampoco habla de dinero (Foto de OddityCentral.com)
Pero es cierto; hacer aplicaciones para el móvil es muy bonito y muy gratificante (es cierto), pero hay que desarrollarlas, y eso cuesta dinero. Lo primero que alguien debería tener claro cuando hace una aplicación para el móvil es si está haciendo una «inversión»; es decir, si espero recibir a cambio más de lo que me costó hacerla, o me conformo con cubrir costes.
Bien, los modelos de monetización de Apps están claros y son los que son. Hagamos un pequeño repaso, y veamos cuáles de ellos tienen cabida en el mundo del mHealth, porque recordemos que este artículo tiene la palabra mHealth en el título.
No compréis v1agra por Internet, que os vais a matar
Hagamos una breve pausa para ver cómo funciona la Publicidad Dentro de las Apps; os anticipo que la conclusión es que desde mi punto de vista un App con publicidad tiene menor valor percibido por parte del usuario, ya que la publicidad en el móvil suele ser molesta e intrusiva (que levante la mano el que quiera ver publicidad en su teléfono) y esto no compensa los ingresos que se consiguen a cambio. Ahora, lo vemos en detalle.
Hay muchas redes de publicidad en el móvil; los fabricantes de sistemas operativos móviles tienen las suyas; son AdMob de Google e iAd Network de Apple, pero hay muchas otras, como TapJoy, AppFlood , o en España MobiTargets Al final lo que un anunciante espera de una red de publicidad es llegar a cuanta más gente mejor, según sus criterios de público destino (al menor precio, claro). Y un desarrollador lo que espera es obtener los mayores ingresos posibles. Como estamos hablando de monetizar Apps, veamos exactamente cómo va el negocio.
Cuando se entra en el modelo de ingresos por publicidad hay que tener en cuenta varios conceptos, que resumo rápidamente:
El CPM que generan los anuncios que colocas en tu aplicación no es un valor fijo, depende de muchos factores; principalmente de lo que los anunciantes están dispuestos a pagar según el público al que llega tu producto, y de cómo los desarrolladores han fijado los espacios publicitarios (recomendaciones a toda página, banners inferiores, etc.) De ahí que leáis alguna vez el concepto de «subastas».
Bien, empecemos a pintar el símbolo del $ por algún sitio. Por ejemplo, en el obsoleto modelo de banners lograr un CTR del 0,6% le reporta al desarrollador un eCPM que oscila 0,01$ y 0,5$. Hay informes e informes que muestran que el CTR medio en iPhone es del 1,7% y un eCPM de 1,07$ mientras que en Android es del 1,1% y un eCPM de 0,88$. Por cierto, que el iPad es el rey del CTR, con un 2,5%
Asumamos un eCPM de 1$ que está muy bien, y supongamos que no te lo corten con una comisión la red de Ads. Pues para lograr recaudar 1.000$ hay que conseguir un bonito millón de impresiones. Covierte millones de impresiones a cientos de miles de descargas, y luego forget about it: recordadme que en otro post estudiemos cuánto va a costar lograr cientos de miles de descargas. Es la pesadilla que se muerde la cola: necesito gastar en publicidad para obtener ingresos por publicidad.
La Pesadilla, del Magic. Tuve una de la primera edición, ¿seré rico?
Resumiendo:
Para que una aplicación se financie con publicidad tiene que lograr cientos de miles de descargas, y un uso recurrente de la misma; y para ello hay que destinar una inversión importante en el marketing del producto. Y todo ello a cambio de ofrecer una experiencia de uso molesta para el usuario.
Moraleja: cuando veas anuncios en los que una red te promete un CPM de 30$ o incluso de 100$ recuerda que «si parece demasiado bueno para ser cierto, posiblemente no sea cierto»
De momento esta entrada se está alargando, así que habrá que continuarla otro día con otros modelos de ingresos. Los temas que tengan que ver con modelos de negocio los etiquetaré como Money Talks.
– «A project is a temporary endeavor undertaken to create a unique product, service or result.»
– «A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.»
– «And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal.»
A Guide to the Project Management Body of Knowledge
A veces viene bien recordar qué es un proyecto, en contraposición a todo lo que no es, y sobre todo, de cómo se lleva a cabo.
La última vez que lo miré, había 18.564 Apps en el canal Medical del App Store, lo que representaba el 2,18% de las más de 850.000 Apps que están disponibles para descargas sólo en el marketplace de Apple. Cada mes, Apple recibe entre 20.000 y 30.000 nuevas Apps para su valoración, casi 1.000 cada día (recordadme que os hable en otro post sobre La Lista Negra de Apple), osea que haciendo la proporción, todos los meses hay unas 500 nuevas Apps de eso que se ha dado en llamar #mHealth En Google Play la cosa va más lenta; aunque el número de Apps en global está equiparado, en el canal Medical hay 7.669 Apps.
Hace ya algunos años, en 2011, un estudio de Juniper Research estimaba que para el 2016 habría 142 millones de descargas de Apps médicas, y a mí en realidad me parece que se han quedado más bien cortos; en Abril de 2013 comScore decía que en US hay 133,7 millones de smartphone, y en los principales países de Europa (entre los que sorprendentemente se considera a España, qué cosas) hay otros 132 millones. Osea, 270 millones de personas con un smarthphone sólo en US y Europa. Me juego bueyes contra pajaritos que en 2016 la cifra de descargas de Apps médicas es absurdamente ridícula.
Bueyes vs Pajaritos, Fight! (Imagen de mikecogh)
Pero no nos liemos. #mHealt. Apps Médicas, subiendo a un ritmo de 500 cada mes a nuestros stores favoritos.
Una preguntilla: ¿alguien se dedica a comprobar el contenido de esas Apps?
¿Estás de coña broma? En Internet nadie comprueba nada, ese es precisamente el valor de Internet, la capacidad de difundir lo que sea a cientos de millones de personas sólo porque te encuentra Google. Y si no lo encuentras en Google no pasa nada, pregunta. En el NewEnglad Center for Investigative Reporting hicieron un estudio a finales de 2012; analizaron 1.500 Apps que había que pagar por descargar y constataron datos tan escalofriantes como que:
En este estudio se citan uno de los casos más terroríficos de lo atrevida que es la ignorancia: AcneApp costaba 1,99$ en iTunes y afirmaba que la luz azulada que generaba, eliminaba las bacterias causantes del Acné si se aplicaba sobre la piel al menos dos minutos al día. No se a vosotros, pero a mí me parece fucking brilliant! La denuncia contra la FDA indicaba que AcneApp tenía sus buenas 11.600 descargas (más de 23.000$, de los que Apple se llevó la tercera parte of course)
Ya te vale, Robin
En un escenario como ese hay dos caminos: el del libre mercado (dejar que sea el propio usuario el que decida lo que se instala en el teléfono y lo que no); o el de la regulación. En esa línea, a finales de 2012 se anunció que la FDA estadounidense lanzaba un proceso de regulación del mercado de las Apps médicas, sin embargo con el tiempo la cosa se ha quedado bastante más light de lo que se preveía. En general, parece que el tema va de que van a estar sujetas a revisión por parte de la FDA aquellas Apps que hagan el mismo trabajo que un dispositivo médico sujeto a revisión por parte de la FDA, o que sean un accesorio del mismo. Los chicos de AcneApp están de suerte, lo pueden volver a intentar.
Por tanto, en ese escenario volvemos al camino del libre mercado; dejar que la cosa se regule por sí misma. Aquellas personas que somos honestas y honradas y no tenemos intención de estafar a nadie necesitamos entonces abrir los ojos garantizar la solvencia del equipo médico que hay detrás de un App; dejar que los usuarios antes de descargarla sepan que los contenidos o la práctica que se genera en esa App no está respaldada por la frikipedia Wikipedia, sino que hay un equipo de profesionales adscritos a un servicio de salud de atención primaria o especialista (con nombre, apellidos, un cv a sus espaldas, y a ser posible un número de colegiado), y qué es exactamente lo que podemos esperar del App.
Quiero desarrollar la línea de Apps sanitarias del Dr. Doom (Foto de Guy Schmidt)
¿Y en España? ¿Qué pasa en España? Menos de lo que debería, como de costumbre. Excepto que la Junta de Andalucía, a través de la Consejería de Salud y Bienestar Social, ha sido pionera en la edición de un catálogo de Prácticas Recomendables, y en la creación de un Distintivo App Saludable que pretende reconocer aquellas Apps que pueden usarse de forma fiable. Las recomendaciones pues en general son las mismas que se podría hacer a cualquier otra App, sea de salud o no, que quiera no sólo ser seria sino parecerlo; pero qué queréis que os diga, ya es un paso importante.
Sin entrar en los detalles, me parece que la JA ha dado un paso que nunca me hubiera imaginado que daría una Administración Pública y menos en materia de tecnología: ha tomado la iniciativa #amazing. No se si los Consejos de Sabios de Europa van a estar moviendo papeles al respecto durante los próximos meses/años, ni si los burócratas de nuestro país van a hacer lo propio cuando los primeros terminen (osea, dentro de meses/años + otros cuantos meses/años) Mientras tanto, ya hay una autoridad «certificadora» que puede servir para que los usuarios puedan distinguir las Apps que tienen su distintivo de las que no lo tienen.
Yo iría mucho más allá; soy un ferviente defensor del concepto de Observatorio de mHealth. Recordadme que en otro post os cuente exactamente en qué consistiría, los beneficios que aportaría a todos los participantes (desde los pacientes a las Administraciones Públicas y todo lo que queda por medio), incluso algunos prototipos aspiracionales; y todo ello por menos de lo que nos cuestan dos o tres de esos asesores puestos a dedo.
En fin. De momento por ahora es suficiente. Espero haber dejado claro por qué creo que es importante contar con un médico a bordo de cualquier proyecto de #appSalud. Este es un tema que me interesa, así que le dedicaré varios post al asunto.
RANDOMIZE USR 0 