Busco nuevos proyectos

Así es, la temporada en eldiario.es llega a su fin, y toca buscar nuevos retos atrayentes y echar una mano en otro lado.

Con un perfil como el mío es fácil pero a la vez difícil. Desde que empecé con mis empresas tengo un pie (muy adentro) en lo técnico y otro (también hasta la rodilla) en el negocio. El otro día lo comentaba con un amiguete: ahora soy lead developer, antes he sido arquitecto de Azure para Produban (Grupo Santander), antes analista en SofCloudIT (Ingram Micro), antes… ¿cómo me puedo definir con una sola etiqueta?

Al final en todos los sitios me he encargado o he ayudado a contratar equipos técnicos, he gestionado proyectos internacionales, mantenido a los equipos focalizados en lo que tocaba hacer en cada momento, he estado pendiente de las innovaciones del entorno para ver como las podíamos aprovechar para hacer nuestro trabajo mejor, he estudiado los requisitos técnicos y de negocio, he diseñado arquitecturas, he buscado clientes, hecho presupuestos… y además siempre hablando de tecnologías variopintas.

Donde creo que más puedo aportar es donde se necesite un nexo de unión entre la tecnología y el negocio dado lo heterogéneo de mi perfil. Aunque ame la tecnología, esta, pierde importancia si no se tienen en cuenta las variables de negocio (tiempos, presupuesto, objetivos, …). Debe ser una herramienta y no un fin. Creo que no hay tanta gente que pueda hablar con un matemático que ejerza de data scientist, con un frontend que habla en javascript dialecto framework X, con un cliente que quiera comprar valor, un inversor que quiera ganar dinero o un CEO que quiera crecer, crecer y crecer.

Lo primero en que me fijo de una nueva posición es en que sea interesante, que el proyecto sea un reto y sobre todo que (aunque no sea conmigo) vaya a tener un futuro y una continuidad. Me gustan las cosas distribuidas, sobre todo los entornos cloud, me gusta pensar en como hacerlas fáciles. Se me da bien encontrar la gente adecuada para cada tarea, así como lidiar con los problemas y mantener a la vez en marcha un montón de cosas, y eso que aprobé raspado malabares en el instituto. Sé delegar (aprendí a la fuerza) y asumo responsabilidades sin estresarme, ya sea porque me las asignen o porque hace falta cuando nadie más toma las riendas. Todo el mundo se alegra de tenerme cerca en los momentos de crisis, por algo será.

Obviamente las condiciones me tienen que encajar, pero en general estudio todas las propuestas y aunque ahora estoy en el centro de Madrid todo es planteable, y no me importaría volver a la Tierruca o a la Terreta, o a cualquier otro lado siempre que sea un sitio agradable.

Con este panorama es complicado preparar un curriculum vitae, porque en general creo que si le paso a alguien mi perfil completo con todas las cosas que he hecho, se puede perder antes de llegar a lo que le interese. Por eso, por el momento he preparado dos, uno para puestos de CTO y otro para los de Team líder que son los que me están planteando ahora, porque por el momento no se me ha ocurrido una forma sencilla y versátil de plasmar toda esa información. ¿Se os ocurre a vosotros algún modo?


EDITO: Gracias a vuestros consejos, he conseguido resumir todo a un “one pager” (de momento sólo en inglés). No es especialmente bonito y por supuesto no tiene el detalle de la información que se puede ver en el perfil completo de Linkedin, pero es un avance. ¡Gracias!


Quiero elegir bien, porque me gustaría encontrar el sitio dónde más pueda aportar y como sé que con sólo dos ojos y dos oídos no se puede controlar todo, os lanzo este anuncio-petición: amiguetes que pasáis por aquí de vez en cuando ¿qué proyectos interesantes conocéis? ¿Dónde creéis que me pueden necesitar? ¿Dónde creéis que podría aportar valor?

Me la suda la tecnología

Todos hemos asistido a interminables debates sobre que tecnología es mejor, sobre que plataforma es mejor, sobre que lenguaje es mejor. Sin embargo, tras muchos años trabajando en una gran cantidad de proyectos de lo más variado y asistir atónito a otras tantas flamewars, he de decirlo: me la suda la tecnología.

Cada proyecto es un mundo, y en todos los casos hay múltiples factores que hacen que una tecnología se amolde mejor que otra. Pero igual que cada problema tiene múltiples soluciones, cada solución se puede implementar con múltiples tecnologías.

Hay técnicos que sólo se fijan en los factores técnicos, pero en cuanto has tenido un pie en negocio sabes que hay mucho más en lo que pensar.

Pongamos por ejemplo un caso sencillo: Ikea decide que va a dar un servicio de diseño de hogares, para lo que crea una bolsa de empresas y diseñadores freelance. La idea es que los diseñadores vayan a las casas de la gente y les ayuden a elegir los muebles y a comprarlos.

Las soluciones son múltiples: Ikea podría darles equipos iguales a cada diseñador; los diseñadores podrían llevar su propio equipo. Alguien en Ikea decide que es mejor la segunda opción. Aparece un nuevo problema y es que los clientes no siempre tienen conexión a Internet: se puede hacer un software que funcione en local y cuando haya conexión haga los pedidos; también los diseñadores podrían tener un pincho 3G para garantizar la conexión y así poder tener una simple web para que hagan los pedidos. Alguien en el departamento de ingeniería le hace ver las dificultades de la primera solución a un directivo y este consigue que se haga una partida para los pinchos, por lo que se quedan con la segunda opción. Por tanto, la solución final será hacer una simple web.

Para hacer una web las opciones son múltiples. Aquí podríamos entrar en una flamewar interminable sobre si PHP, .Net, Ruby on Rails, Node… También sobre si tener servidores propios o usar alguna plataforma cloud; si usar MySql, SqlServer, una base de datos NoSQL o guardar la información en archivos de texto plano. Las distintas opciones considerando todas las posibles combinaciones son muchísimas, y por mucho que nos guste más una tecnología que las otras, ninguno de los argumentos que se suelen usar en las flamewars debería de influir de verdad en la decisión. La verdad es que la tecnología en una solución tan simple como esta os la debería de sudar. A mi me la suda.

¿En qué nos deberíamos fijar si fuésemos el responsable tecnológico de este proyecto en Ikea? Hay que ver inicialmente si Ikea ya tiene otros proyectos y como se han hecho, con qué tecnologías se manejan mejor sus desarrolladores, etc. Si no los tuviese, podríamos mirar al mercado, ver que tipo de técnicos va a ser más fácil contratar por ejemplo, o si se espera que el proyecto evolucione y crezca o si hay previsión de otros proyectos y de que tipo serían… Hay múltiples factores que deberían afectar a la toma de la decisión, y la gran mayoría no vienen marcados por la tecnología sino que vienen marcados por los factores de negocio.

Por tanto, cuando os volváis a ver involucrados en una de esas de si “el este mola más”, dejad de darle vueltas a qué lenguaje es más cool o que plataforma usa la empresa X. Plantearos los factores de negocio en casos concretos y las guerras dejarán de ser tan cruentas y se volverán mucho más objetivas y productivas. Cuando os digan que “mi tecnología mola más” responded con este grito: me la suda la tecnología.

Las cosas que hicimos bien

Este fin de semana tuve la visita de Juan, uno de mis exsocios de GPMESS. También resulta que estos días estoy leyendo “From impossible to inevitable” y en el trabajo, actualmente, me tengo que enfrentar a modelar lo que se hace con los socios y como se venderá después ese trabajo que estamos haciendo. Estas han sido algunas de las coincidencias en el tiempo que me han hecho darme cuenta de que hemos hablado largo y tendido de lo que hicimos mal en GPMESS pero nunca he expuesto aquellas cosas que hicimos bien. Intentaré repasar y justificar aquí una de ellas.

Probablemente el motivo de no haberlo hecho antes es que es muy fácil justificar lo que has hecho mal (nadie se lo cuestiona y además fueron muchas cosas), pero parece un poco hipócrita hablar de lo que se hizo bien tras un fracaso como aquel. Ahora ya ha pasado suficiente tiempo como para que esto no suene como un intento de escurrir el bulto, a nadie le importa ya GPMESS, así que espero que suene como lo que pretende ser: compartir uno más de los aprendizajes que tuvimos, algo que con el paso del tiempo sigo convencido que hicimos realmente bien.

Para que sirva de aval, no es algo que diga yo, son muchos los autores como Aaron y Jason que plantean lo que os voy a contar. Además, varios de los inversores con los que me senté en aquella época me dijeron con unas u otras palabras “Lo habéis hecho bien, esos pasos son precisamente los que hay que dar, sin embargo…”. El pero era siempre el mismo, no habíamos facturado apenas porque habíamos tardado demasiado en los pasos previos y sin un histórico de facturación es muy complicado obtener inversión.

En aquella época por suerte, lógica o intuición, nos preocupábamos de medir todo lo posible e intentábamos tener en boca siempre las métricas piratas: ¡AARRR!

Además evitábamos gastar mucho tiempo y esfuerzo en cosas que no pudiésemos repetir posteriormente. Siempre que nos venían con un “haz un X viral” salíamos corriendo. Buscábamos lo que pudiésemos repetir, lo que pudiésemos multiplicar.

Los primeros usuarios nos costaron 15€, luego 7, luego 3 y finalmente tras muchas pruebas encontramos la forma de conseguir usuarios de nuestro nicho entre 0.7 y 1.2€ en función de la velocidad a los que los quisiéramos. Además sabíamos cuanto duraban con la aplicación instalada, y que al mes nos quedaba un 30% pero que ese 30% de usuarios ya nos eran fieles indefinidamente. Sabíamos que el 67.7% de las notificaciones se abrían, y que el 39.38% se concentraban en las principales ciudades españolas. Además sabíamos que un 15% de los usuarios no nos costaban dinero ya que venían por las recomendaciones de los fieles, que eran nuestros principales prescriptores, y que cuando estábamos bien posicionados en las stores de Android y Apple teníamos otro 20% adicional que nos salía “gratis”.

En una aplicación como la de GPMESS, esto era una de las claves: medir todo y fijándose en las métricas buscar modos repetibles de crecer. Desgraciadamente tardamos mucho en llegar a la optimización que nos permitía dar el siguiente paso y no nos quedaba gasolina para dar el siguiente paso (encontrar un modo de monetizar los usuarios de una forma escalable).

Eso es lo que hicimos, y a día de hoy creo que eso lo hicimos bien. Creo que es algo que todas las empresas de ese tipo deben hacer: probar, probar y probar optimizando los procesos para encontrar el modo más barato y aceptable de conseguir sus objetivos de un modo replicable y escalable. De este modo, cuando tengan todos los procesos optimizados podrán enchufar la manguera de dinero y hacer que la máquina empiece a rodar.

Obviamente, si hubiésemos tenido éxito lo aquí contado sonaría más creíble, pero no me creáis a mi y leed a la gente que sabe mucho de desarrollar negocios, a los que han hecho alzarse empresas como Salesforce o 27signals, analizad negocios que han crecido mucho… luego, solo os quedará unir los puntos y estoy seguro de que comenzaréis a medir y a buscar fórmulas replicables.

Normas para la generación de ideas

Muchas veces nos enfrentamos a la necesidad de generar ideas, ya sea para solucionar un problema que no tenga una solución directa, o para crear o mejorar un producto. Sea cual sea el objetivo hay algunas normas que podemos seguir:

  1. No juzgar: Cuando estás generando ideas, ya sea sólo o en grupo, es muy importante no juzgarlas, por varios motivos. En primer lugar si estás en modo creativo no tiene sentido parar todo el tiempo que requiere una evaluación completa. Además no hay que desmoralizarse (ni a uno mismo ni a nadie). Por tanto, si estás generando ideas nada de “eso es una tontería”.
  2. Todo vale: Digamos que esto es un refuerzo de lo anterior. Hay que poner encima de la mesa absolutamente todo lo que se te pase por la cabeza, ya que aunque estés seguro de que es algo que no vale por el motivo que sea, esa puede llevarte a ti o a otra persona a pensar en la buena buena, así que es importante que sea lo que sea lo plantees.
  3. Desorden: El desorden ayuda mucho a que el cerebro se ponga en modo creativo, así que busca momentos o espacios alternativos para darle vueltas a ese problema.
  4. Usa las manos: Hacer manualidades ayuda a pensar. Puedes garabatear dibujos, hacer papiroflexia, jugar con una goma o tirar una pelotita. En realidad, cualquier cosa que provoque usar otras partes del cerebro ayudará.
  5. Sólo no puedes, con amigos sí: Siempre es mejor hacerlo con más gente. Las ideas de uno pueden retroalimentar las ideas de otro. Además, con perfiles (estudios, experiencias, culturas) distintos se tiende a pensar en cosas distintas.

La próxima vez que tengas que darle vueltas a algo intenta poner todo esto en práctica y todo será mucho más fácil.

De .Net Core, Webjobs y despliegue automático

En otras ocasiones hemos hablado de .Net Core, de los webjobs y aunque nunca he escrito mucho sobre ello tengo interés por automatizarlo todo lo más posible. Para esto último, intentando no sobretrabajar he usado siempre las funcionalidades de Visual Studio Team Services.

El problema que voy a describir, es un problema con una solución tremendamente sencilla una vez que das con ella, pero que al no haber ningún tipo de documentación y no haber nadie por el mundo que haya hecho exactamente eso y lo haya contado, acabas teniendo que ir deduciendo cosas, poniendo parches y testeando multiples variantes hasta que das con el conjunto de pasos buenos que te salvan la vida.

Como sabéis .Net Core ha roto el cascarón de su primera versión hace muy poquito, y aunque mola mucho porque es muy ligero, es multiplataforma, te facilita (o fuerza) a usar ciertos patrones que merecen la pena… A pesar de todas esas cosas también tiene sus pegas, y las principales creo que son sin ninguna duda el tooling y las librerías que permiten la integración con otras partes del entramado Microsoft.

Del mismo modo, el SDK de los webjobs también es relativamente nuevo, y tiene muy pocas funciones y sólo vale para el Framework de .Net (el de toda la vida).

El tercer componente de nuestra ecuación es el más maduro, ya que Visual Studio Team Services viene de TFS que lleva ya dando vueltas mucho tiempo y tiene multiples opciones con las que solventar las cosas cuando no hay un componente específico (a las malas siempre puedes subir tu propio script de PowerShell por ejemplo).

El problema de juntar estos tres elementos es que no hay SDK de webjobs para .Net Core, y que las herramientas de core no permiten añadir un webjob a tu proyecto.

Las estrategias posibles para afrontar este problema son múltiples:

  • Despliegues independientes. Siempre puedes montar despliegues independientes, pero tendrás que gestionar todo por separado y no en todos casos va a ser lo ideal. No tiene porque suponer un incremento en costes porque lo puedes tener rulando todo en el mismo Service Plan para que compartan recursos y esperar a que todo crezca mucho para separa cada cosa por su lado en ejecución. Sin embargo, a mi personalmente, me deja mal sabor de boca el hacer algo forzado porque no sé, cuando en el caso que teníamos entre manos el ideal era llevarlo junto ya que hay cierta dependencia entre proyectos.
  • Montar el webjob con .Net Core sin el SDK. Al final un webjob no deja de ser un programa o script que ejecutas. Puedes montar un ejecutable independiente o una dll que invocarás con el comando dotnet y las librerías de .Net Core para acceder al storage de Azure y hacerte tu propio acceso a datos y tus disparadores y esas cosas. Esto… es una opción pero multiplica el tiempo de desarrollo de cada webjob al menos por tres, te hace picar mucho más código y asumir más responsabilidades de las que deberías. Sí que es cierto que el rendimiento mejoraría, así que puede ser la opción buena en función de lo intensivo que vaya a ser el webjob. En nuestro caso el webjob necesitaba usar unas librerías que sólo existen en .Net Framework y por tanto no era una opción que pudiésemos tomar sin desarrollar un montón de componentes para .Net Core.
  • Hacer tu webapp con .Net Framework. Siempre es una opción, pero la diferencia de rendimiento creo que justifica suficientemente el no tomar esta opción por defecto nunca.
  • Hacer que las dos tecnologías se entiendan y todos los despliegues funcionen bien. Generalmente todo es posible, y aunque no hubiese documentación al respecto, siempre podríamos haber hecho scripts propios e intentar que se lanzasen cuando tocase (que en una pequeña parte es lo que hemos hecho). Aunque llegar al conjunto de pasos más simple posible para no condenar a tu yo del futuro puede llegar a ser complicado. Esta ha sido la opción que tomé para ponerlo todo a andar.

Lo primero de todo es hacer que cuando publicas desde tu Visual Studio a maneja a Azure para hacer alguna prueba puntual montando una nueva webapp se despliegue con ella el webjob para que no haya problemas y todo funcione correctamente.

Para hacer esto solo hay que seguir unos muy muy simples pasos, y aunque todos tienen su lógica y explicación, voy a pasar muy rápido por ellos para no enrollarme:

  1. Lo primero es crearte en tu proyecto de aplicación web una carpeta app_data si no la tienes ya. En ella tendrás que crear otra que se llame jobs y dentro de esta tienes que actuar en función del tipo de webjob que tengas:
    1. Si es un webjob que se ejecuta continuamente esperando a que salte algún trigger desde el storage, tendrás que crear una carpeta que se llame Continuous.
    2. Si el webjob es de ejecución manual y lo vas a lanzar tú cuando te convenga (¿por qué nadie querría hacer esto?), tendrás que crear una carpeta que se llame Triggered.
    3. Si el webjob es de ejecución programada o agendada (scheduled, vamos), tendrás que crear también una carpeta que se llame Triggered, pero posteriormente deberás dar un paso adicional.
  2. En esa carpeta (o carpetas si tienes distintos tipos de webjobs), deberás crear una carpeta por cada webjob con el nombre que quieras ver en Kudu.
  3. En esa carpeta tienes que meter un script que se llame run.cmd (hay otras opciones, pero no nos compliquemos) invocando al ejecutable del webjob como si estuviese en la carpeta aunque no haya nada en ella. Vamos, que hay que poner el nombre del ejecutable en el archivo y si quieres primero una línea con un “@echo off“, y listo
  4. Si el webjob es de ejecución programada (o si queremos usar otras features como hacer un webjob singleton por ejemplo), meteremos en esa carpeta el archivo settings.job correspondiente.
  5. A continuación hay que decirle a quien corresponda que cuando publique ese proyecto incluya esa carpeta. En el archivo project.json tendremos la propiedad de primer nivel (y si no la creamos) “publishOptions“, y en su interior deberíamos tener (y si no lo creamos) una propiedad de tipo array llamada “include“. Ahí deberemos añadir la ruta de lo creado, por ejemplo “app_data/jobs/**/*.*“. De este modo conseguiremos que cuando se publique se copien esas carpetas con el archivo o los dos archivos que hemos creado.
  6. Por último deberemos decirle que hay que compilar el proyecto del webjob y copiar los archivos a la carpeta de publicación en la ruta adecuada “app_data/jobs/…“. Para esto, en el mismo archivo project.json tienes una propiedad de primer nivel llamada “scripts” y en su interior otra de tipo array que se llama “postpublish” (si no existe alguna, sólo tenéis que escribir). Como el proyecto es de .Net Framework, tendremos que invocar al comando msbuild que nos toque en función del tipo de nuestro proyecto (que espero que sea 2015, no me fastidiéis) la ruta del proyecto y la del destino. En mi caso: “\”%ProgramFiles(x86)%\\MSBuild\\14.0\\Bin\\msbuild.exe\” ..\\ProjectFolder\\ProjectName.csproj /property:OutDir=%publish:OutputPath%\\app_data\\jobs\\Continuous\\WebjobName\\

Con esto, ya podremos usar la opción de publicar del Visual Studio y que todo funcione. Cuando se publique el proyecto compilará guardando el resultado en la carpeta del webjob en el destino de la publicación.

Como os decía es una chorrada una vez que das con los pasos adecuados.

Lo siguiente es meterlo en el VSTS, y aunque sé que está en preview os recomiendo usar la plantilla de deploy de .Net Core añadiendo los pasos que necesitéis para desplegar en vuestro servidor (por ejemplo un “Azure App Service Deploy” que coja el paquete del destino de la compilación “$(build.artifactstagingdirectory)\**\*.zip“), o si tenéis montado un sistema de release y validaciones que pase por distintos entornos, simplemente la plantilla en cuestión.

Veréis que os pasa en verde, pero que ni webjob ni nada, y si atendéis a los logs de vuestro build, en concreto al del step Publish, veréis que algo no ha ido del todo bien al ejecutar el script de postpublish que introdujimos, y parece que no encuentra muchos archivos. El problema es que en vuestro sistema están todas las librerías necesarias dónde toca porque el plugin de NuGet que tenéis en Visual Studio lo ha hecho sin molestaros.

La solución es tan sencilla como antes de ese paso meter un componente de NuGet install con la opción de restore seleccionada, para que restaure todas las dependencias que tengan los proyectos de .Net Framework de la solución, así como tenéis el Restore de .Net Core.

Con esto ya tendréis todo funcionando, dos tecnologías distintas conviviendo juntas en amor y compañía 😀

Tened en cuenta que en un tiempo indeterminado llamemosle X la información de este post estará obsoleta. En diciembre de 2016 la comunidad abrió un ticket en uno de los githubs de estos proyectos, y unos se lo han pasado a otros cerrando sus tickets, hasta que alguien ha decidido que lo que había que hacer era primero abrir un ticket para pensar lo que hay que hacer… Parece uno de esas chistosas historias paralelas que contaría la voz en off de “La guía del autoestopista galáctico”, pero es real, podéis buscarlo vosotros mismos xD. Esperemos que ese X no sea demasiado largo, crucemos los dedos en forma de X.

Cualquier duda o pregunta, o si no se entiende algo, o si algo está mal… escribid un comentario o me contactáis por dónde sea. ¡A cuidarse!

3+1 problemas típicos para que las empresas se vuelvan ágiles

En mi paso por las distintas empresas en las que he tenido el placer de trabajar y aprender, y en mi contacto con muchas otras empresas que me ha permitido ver como trabajan, he observado que se repiten ciertos puntos clave respecto al agilismo.

El primero sin duda, no es un problema per se, pero sus bases sí lo son.

En todas las empresas quieren ser ágiles, todas quieren aplicar Scrum, Lean, Kanban, o cualquier otra cosa que suene a agilidad. Todas siempre están empezando, pero ninguna lo está haciendo del todo, ninguna de verdad.

Esto no es un problema en si mismo, pero sí los cimientos en los que se basa. En ninguna de las empresas que he conocido querían ser ágiles para asegurar su supervivencia en un mundo cambiante, ni para ser más eficientes, ni siquiera para ganar más dinero.

En todas esas empresas, lo que he observado es que, se quiere ser ágil simplemente por moda, porque es de lo que habla todo el mundo, porque hoy en día si no eres ágil es porque estás haciendo una mala gestión.

Esto es un problema obviamente. Es importante que los procesos de cambio se asienten en unas buenas bases, pero al menos es un problema que te lleva por el buen camino. Es el menos malo de los problemas.

El resto sí que son grandes problemas que afectan de manera directa al proceso de cambio que requiere pasar de la gestión que se tenga a una gestión ágil:

Burocracia
La burocracia, esa traicionera que nadie reconoce, pero que efectivamente está en muchas muchas empresas.La burocracia mata muchos procesos, el orden excesivo, la sobredosis de normas provocan que no se pueda mover con velocidad de un punto a otro, que no se puedan probar distintas cosas e incorporar a los nuevos procesos aquellas que funcionen.
Desorden
Sí, aunque parezca que se contradice un poco con la anterior, es tan problemático el exceso de orden como su ausencia total. Para ser ágiles hay que tener orden, hay que conocer en todo momento los “recursos” de los que se dispone y sobre todo el más preciado de ellos que es el tiempo de las personas que ejecutan los trabajos. Si no se tiene cierto orden es imposible ser ágil porque nunca se podrá prever que trabajo se va a poder realizar y a que retos se va a poder enfrentar, y la gente que realiza los trabajos no va a saber nunca a que atenerse, que es lo que debería hacer en cada momento sin preguntar a su micromanager cual debe ser el siguiente paso que tienen que dar.
Miedo
Efectivamente el miedo es un gran problema. Generalmente es el miedo de los mandos intermedios. El medio que les impide enfrentarse a sus superiores para llevar a cabo los cambios. El miedo que les hace no asumir que a veces es necesario perder tiempo en tareas no directamente productivas. El miedo que les hace no asumir que optimizando es posible que se tengan que enfrentar a reducciones de presupuesto o a no cumplir con los objetivos erróneos que les hayan puesto los de arriba. Ese miedo les impide lanzarse a liderar el cambio.

Estos 3+1 problemas son los más repetidos en base a mi experiencia en las distintas empresas que he podido ver como funcionan. ¿Y en la tuya? ¿Quieren ser ágiles? ¿Desde hace cuanto? ¿Son ágiles de verdad o tienen algún problema para conseguirlo?