Google Analytics

martes, 14 de febrero de 2017

#ShowMeTheCode

El sábado pasado, JeroGonzalo y yo madrugamos para
ir a comer a Valladolid asistir al #ShowMeTheCode organizado por CyLicon Valley en Valladolid.
CyLicon Valley es uno de los grupos locales más activos de España y merece la pena un viaje de dos horas en coche para asistir a sus eventos. En este caso un evento que se basaba en que enseñases código de producción al resto.
Bueno, al final comer sí que comimos, también :-)

¿Por qué asistir?

¿Por qué deberías asistir al #ShowMeTheCode? pues si la comida posterior no te parece razón suficiente, aquí van algunas más:
  • Durante el evento podrás ver múltiples proyectos y tecnologías. Eso te permitirá, en un espacio de tiempo reducido, conocer otras opciones que a lo mejor no habías visto antes. En el mejor de los casos incluso podrás conocer proyectos que no conocías y que te pueden resultar de utilidad en tu día a día.
  • Verás a qué problemas se enfrentan otras personas y, más importante aún, cómo los han resuelto. Por norma general muchos nos enfrentamos a los mismos problemas todos los días y ver qué soluciones han adoptado otros equipos puede ayudarnos.
Creo que estas son unas buenas razones para asistir al evento, pero si de verdad quieres disfrutar la experiencia completa, te animo a que te subas al escenario a contar algo.

Pierde el miedo a participar

Cuando se propuso el evento hubieron los típicos comentarios como - pero ¿qué código voy a enseñar yo? - o cosas como - pero si mi código es muy malo - como suele ser habitual.
Partamos de un punto básico, yo soy el primero que tiene miedo a enseñar su propio código, pero os voy a dar unas cuantas razones de por qué ir a este evento y mejor aún, por qué participar como ponente.
  • Todo el mundo tiene algo que contar. De verdad, aunque creas que no haces nada que sea interesante para el resto, eso es falso. Hay mucha gente que no trabaja en lo mismo que tú y que puede que encuentre útiles tus soluciones. Nunca habrán usado esa tecnología o simplemente no se han enfrentado a ese problema.
  • Todo el mundo tiene cadáveres en el armario. Generalmente tendemos a pensar que los demás hacen las cosas siempre bien, que no tienen deuda técnica y que sus soluciones son mejores que las nuestras. Pues, creeme, no es así, todo el mundo ha cometido errores en algún momento.
  • Todos los proyectos tienen un contexto. Los proyectos evolucionan y pasan por diferentes etapas, en algunos momentos nos basta con una solución de andar por casa y otras necesitamos el cojo-sistema que soporte trillones de requests por segundo. Cuenta tu contexto y verás que la gente te entiende e incluso aprender de tu experiencia.

La experiencia en Runnics

Por si te sirve de ejemplo, te voy a contar lo que hice yo.
Cuando estábamos en Runnics nos tuvimos que enfrentar a un problema, que era el de servir las páginas de zapatillas y los resultados de búsqueda en tiempos inferiores a los 900ms. A priori parece un problema complejo, pero tiene soluciones muy sencillas en realidad.
Como nuestro catálogo era inferior a los 1000 productos y la presión en memoria no superaba los 80MB en el peor caso lo que hicimos fue crear un mapa en memoria. Un simple ConcurrentHashMap de Java, más simple que un clavo. Después ya tenía su lógica de filtros y tareas de actualización y demás, pero todo muy DIY de andar por casa ... y ¿sabes lo mejor?, funcionaba y muy bien por cierto.
Muy muy simple como verás. Así que te lo digo una vez más ... pierde el miedo a participar :-)

Cosas a mejorar

El evento estuvo genial y por lo tanto hay muy pocas cosas que mejorar. Quizás como ya ha dicho otra gente, lo que haría es reducir el número de ponentes y hacer más ediciones, para que no se haga muy largo o la gente se quede sin tiempo en la exposición.

viernes, 17 de junio de 2016

#informáticaSoluciónYA

Hoy he recibido una mención en Twitter de Paco Mesa en la que, creo, solicitaba mi opinión respecto al "reciente" movimiento #informáticaSoluciónYA. Bien, mi posición en este tema es de NO apoyo. Espero que fuese mi opinión lo que quería y no mi apoyo :-)




También se supone que me debería importar la política de contratación de la Administración Pública si hacemos caso a la imagen de ese tweet, pero como es un mundo que nunca me ha gustado pues también dejo a la propia Administración sus temas de recursos humanos. Si son buenos o malos es materia de otro post.

Sería fácil para mi quedarme en esa posición y no decir por qué o qué experiencias me llevan a no apoyar un mundo en el que sólo las personas con una determinada titulación pueden desarrollar software. Pero a mi me gusta meterme en líos por muy políticamente correcto que sea siempre, así que aquí va mi planteamiento.

Lo que dice la teoría


El personal más cualificado que puedes contratar, será un Ingeniero Superior en Ingeniería Informática, que para eso se ha pegado estudiando 5 años como mínimo y se habrá ventilado más de 100 exámenes a lo largo de su carrera. Y si tiene un par de masters mejor que mejor. Además estarán formados por personas muy capaces con una larga experiencia laboral.

Por otro lado si necesitas a alguien un poco menos preparado porque el problema no es tan complejo, puedes contratar a un Ingeniero Técnico que también tiene una pila de exámenes a su espalda y "muchas horas de vuelo". Y si no te quieres rascar mucho el bolsillo pues tienes a gente de Formación Profesional que son los "pica-teclas", al menos así los llamaban en mi época universitaria (antes de insultarme lee todo el artículo).

Pero siempre siempre siempre tiene que ser una de estas tres posibilidades, porque son las personas formadas, que realizarán el mejor trabajo posible y asegurarán el éxito, que para eso se quiere legislar y dar atribuciones.



¡Claro que sí Maya! trae a Willy que juntos construiremos el próximo Facebook -ironic mode off-.

Lo que he comprobado en la práctica


Cuando era más joven y estaba en la Universidad, ciertamente pensaba un poco de esa manera, pero después llegó esa experiencia ineludible que es la VidaReal(TM) y me abofeteó como me merecía. Muchas gracias Señora Vida, lo necesitaba.

Durante mi, todavía corta, experiencia laboral me he tropezado con bastantes personas y muchos compañeros y compañeras. Verás, no he encontrado ningún patrón que me haga pensar que sus titulaciones eran importantes. He trabajado con Ingenieros Superiores mediocres y con gente de Formación Profesional tan jodidamente brillantes que pueden trabajar prácticamente donde quieran. Aún mejor, uno de mis jefes era un Ingeniero de Telecomunicaciones, pero cualquier Ingeniero Superior en Informática (incluso con décadas de experiencia) habría palidecido a su lado en lo que a desarrollo de software se refiere.

Os explicaré varios puntos que he aprendido u observado por mi mismo:

  • En la Universidad la gente no necesariamente adquiere conocimiento, pueden limitarse a pasar exámenes, por lo que pensar que todo el mundo que sale posee unos determinados conocimientos es en el mejor de los casos muy optimista.
  • Los profesores, esos profesionales con años de experiencia, realmente lo son. Tienen muchos años de experiencia, como profesores, pero en gran cantidad de casos rara vez se han enfrentado a un proyecto de desarrollo de software real.
  • Gran parte del conocimiento necesario para ser desarrollador de software en la actualidad, está disponible de forma gratuita en Internet, incluyendo las clases de universidades como Stanford o el MIT. Por lo que cualquiera con las ganas necesarias puede adquirir ese conocimiento, incluso un filólogo (ver la imagen que acompaña al tweet).
  • El desarrollo de software está cambiando radicalmente y el rol de esa persona que toma el puesto de arquitecto y que no tiene ni idea de como es el código fuente o cómo funciona las cosas a bajo nivel ... lo siento mucho chavales, está desapareciendo.

Lo que yo miro al contratar


Entonces, si no me importa la titulación de una persona o no le doy un peso determinante, ¿qué cosas valoro en un desarrollador de software?

  • Su experiencia previa, obviamente, más allá de lo que haya estudiado. Si estudió Químicas, pero tiene 5 años de experiencia desarrollando proyectos de software con una buena valoración de sus compañeros, quién soy yo para decir que no es capaz de desarrollar software.
  • Sus publicaciones, blogs, código subido a GitHub o similar. El código, su calidad y sobretodo cómo ha evolucionado con el tiempo es una de las cosas más importantes para mi, al fin y al cabo el software se basa en un montón de código fuente ejecutándose en una máquina.
  • Su capacidad de adaptación, es imprescindible porque siempre aparecen nuevas tecnologías y el mercado evoluciona continuamente. Te sorprendería saber cuantas veces he escuchado cosas como, "yo ya estudié todo lo que tenía que estudiar en la Universidad" :-(
  • Por último la actitud. Me da igual que seas ingeniero, en mi entorno todo el mundo está continuamente aprendiendo y se molesta en mejorar su profesión con actos no con títulos universitarios.

Si mi experiencia hubiese sido diferente a lo mejor apoyaría un movimiento de defensa de las atribuciones profesionales para el desarrollo de software. Pero, ¿sabes qué?, lo que he aprendido es que ahora mismo eso sería más dañino que beneficioso.

sábado, 2 de abril de 2016

Las mujeres y las carreras técnicas

Disclaimer: Este es un artículo de opinion, antes de reaccionar, responder o lo que quieras hacer con él, léelo todo y léelo bien. Además no es un artículo que quiera dar respuestas, es un artículo que quiere lanzar preguntas y fomentar el dialogo.

Esta semana, el mundo de la arquitectura ha sufrido un fuerte revés, la muerte de Zaha Hadid a los 65 años de edad. Yo no soy arquitecto y no puedo opinar de forma técnica sobre su obra. Para mi era una de las grandes, algunas de sus obras son de mis favoritas, tan sólo como ser humano, como persona que observa la belleza de sus diseños. Pero lo que realmente quería hacer hoy, es aprovechar para relacionar la carrera de esta gran arquitecta con una pregunta importante. ¿Por qué esta escasez de mujeres en las "profesiones técnicas"?
Quizás no sepas quien es Zaha Hadid, pero lo puedes buscar en la Wikipedia, o dónde prefieras. Por ponernos en situación, fue la primera mujer en ser considerada "startchitect", la primera mujer a la que se galardonó con el premio Pritzker y sobretodo, probablemente, la primera arquitecta en ser respetada por sus colegas de profesión a nivel internacional ... al menos en la medida de lo posible, porque probablemente tendría muchas historias (desagradables) que contar y que su ascenso no fue un camino de rosas.
Yo provengo del desarrollo de software, un mundo en el que creemos que la escasez de mujeres es endémico de nuestra profesión, pero nada más lejos de la realidad. Volvamos a la arquitectura, ¿sabías qué tras el galardón a Hadid en los Pritzker del 2004, sólo lo ha recibido otra mujer en toda su historia? Sí, así es, en 2010 lo ganó Kazuyo Sejima (y fue en combinación con su compañero Ryue Nishizawa). No es que el Pritzker tenga 200 años de historia, tan sólo existe desde 1979, pero 2 mujeres en esa lista parece poco.

Los grandes estudios

Cuántas mujeres esperas en unos premios de este tipo, es una pregunta complicada para mi que no estoy tan relacionado con esta profesión. Para ello lo primero que voy a hacer es buscar arquitectas en los grandes estudios y nada mejor que empezar por uno de mis favoritos, Sir Norman Foster. Hummm, no hay mujeres en los socios ejecutivos senior, a ver ... nope, tampoco las hay en los socios seniors ... déjame seguir buscando, ah sí, aquí está, Annamaria Anderloni es la primera mujer que aparece en el estudio Foster + Partners y es una arquitecta de interiores socia del estudio, "por detrás" de 25 hombres.
Vamos a probar con otro de los grandes, Renzo Piano. Un poco mejor, entre los once partners figuran dos mujeres, Elisabetta Trezzani y Emanuela Baglietto, no es una proporción impresionante pero ya es mejor.

Las escuelas de arquitectura

Con lo anterior no quiero decir que estos estudios sean machistas, es más, quiero pensar que no lo son. Quizás les pasa lo mismo que a la carrera de Ingeniería Informática, ya desde la Universidad hay una gran escasez de mujeres.
Con una sencilla búsqueda en Google tal que women in architecture schools, y algo de rebuscar porque no está a simple vista. La Association of Collegiate Schools of Architecture presenta algunas estadísticas que parecen "serias", vamos a darlas por válidas, para Estados Unidos y Canada al menos.
Un 43% de las matriculaciones en carreras de arquitectura corresponde a mujeres. Es un valor que ha ido aumentando año tras año, por lo que quiero pensar que la tendencia en los grandes estudios cambiará. El problema, no es sólo que existan menos matriculaciones de mujeres, sino que el abandono de estas es mayor que en el caso de los hombres, por lo que la cifra final de arquitectas que se licencian baja bastante.

¿Por qué tan pocas matriculaciones y tanto abandono?

No sé como responder esta pregunta, quiero pensar que vivimos en un mundo mejor, pero si soy sincero conmigo mismo no es igual estudiar una carrera técnica para un hombre y para una mujer.
A mi siempre me ha gustado la ciencia, sobretodo la cienca aplicada, por lo que me encanta la ingeniería. Nunca nadie me ha mirado raro porque haya decidido estudiar Ingeniería Informática, o no mucho al menos ... pero sería un mentiroso si dijese que nunca he escuchado comentarios innecesarios sobre mis compañeras de estudios en su momento y de profesión ahora. Comentarios que no en todos los casos provienen de hombres, también otras mujeres tiran piedras contra su "propio tejado", lo cual es aún más extraño.
Nos tendríamos que hacer una serie de preguntas muy importantes, entre las que destaca una, ¿tienen la misma facilidad para estudiar o desarrollar una carrera técnica las mujeres que los hombres?

¿Conclusión?

Después de reflexionar, haciendo un poco de test de tripas, diría que la respuesta sincera a esa pregunta es que sí, pero no. Oportunidades propiamente dichas espero que sí, pero es muy probable (por no expresarlo de otra manera) que la sociedad tenga un sesgo importante a que los ingenieros sean hombres y las mujeres deban elegir otras carreras. Es triste, pero después de reflexionar creo que es cierto.
Así que, lo mejor que podemos hacer los hombres que trabajamos en carreras técnicas es apoyar a nuestras compañeras y demostrar que si una niña quiere ser ingeniera mecánica, arquitecta o la próxima gran estrella de la programación lo puede ser. Puede ser princesa e ingeniera a la vez e incluso puede ser sólo ingeniera, puede ser lo que ella quiera.

jueves, 31 de marzo de 2016

El cliente siempre tiene la razón ... hasta que va contra tu margen

Hoy leí un artículo de Chase Clemons en el blog de la gente de Basecamp, Signal vs Noise. Básicamente se trata de un buen ejemplo de atención al cliente y me ha parecido genial, pero quería hacer algunas puntualizaciones y ampliar un poco el tema.


Por si no te has leído el artículo que se enlaza, cosa que quizás deberías hacer, básicamente se trata de una carta de disculpas en la que la empresa de cafés a la que Chase ha hecho una compra, para una clienta de Basecamp, se disculpa por no haber cumplido con un pedido. Han tenido que lidiar incluso contra huracanes, pero aún así Clarke va a ir personalmente a entregar el café a la clienta de Chase.
Y digo yo, chapó. No tengo ni idea del coste del pedido, ni de la distancia que Clarke va a recorrer o el tiempo que va a usar. Chapó también por Chase que va a repetir con esta empresa, yo también lo haría Chase. ¿Pero y qué pasa si tu margen de venta no es suficiente? ¿Tu recurrencia lo compensa? ¿Cuál es el coste de adquisición de clientes que puedes soportar?
Y me hago estas preguntas con algo de conocimiento de causa, porque esta discusión ya la hemos tenido en Runnics múltiples veces, ¿hasta dónde podemos llegar por un cliente?. Pongamos un caso práctico.
Nota: Como marketplace no tenemos stock propio, detalle muy importante a la hora de evaluar tus opciones. Ya te digo que si quieres tener stock propio tu margen tiene que ser bastante bueno.
Digamos que el pedido medio en Runnics ronda los 91€ y que la comisión media antes de eliminar los gastos de la pasarela de pago son de aproximadamente un 8%. Esto es que ganamos 7,28€ por pedido de media, vamos a dejarlo en 6€ tras el palo de las pasarelas. Y te digo que imagines por no decirte que esas son las cifras reales, que para eso soy uno de los desarrolladores del sistema.
Ahora hagamos la segunda parte del supuesto, a un cliente no le llega el pedido en el día que se esperaba, por las causas que sean. No me creerías si te contase todas las incidencias que pueden ocurrir con un pedido. Pero vamos al grano ... ostis, ¿qué hacemos ahora?

Opción A: Somos la empresa super mega cojonuda:

No te preocupes, yo mismo iré a la tienda del barrio a buscar tu zapatilla para llevártela personalmente a casa. Déjame pensar ... la tienda local me va a cobrar por una zapatilla, para la que mi cliente ha pagado 91€, unos 120€ (sí también es una cifra bastante próxima a la realidad, incluso optimista). Coste total de hacer eso 29€ de más sobre lo que pago el cliente, más mi tiempo y todo suponiendo que no ocurra el peor caso posible, la zapatilla del envío finalmente se entrega al cliente y perdemos esa mercancía de la que el proveedor no nos devolverá un céntimo, obviamente. Vale, pues el coste de atención al cliente varía entre unos muy optimistas 29€, porque no cuento con mi coste por hora, hasta unos 211€ si al final no he recuperado la zapatilla original.
Resultado, tengo que vender entre 6 y 35 zapatillas para recuperarme, ya te digo yo que ni con la mejor recurrencia del mundo ese cliente ha sido rentable.
Incluso podríamos hablar de la gestión del descontento ... difícil de medir, pero si no es un super mega influencer con un millón de seguidores que no puede esperar una semana a recibir su artículo o la devolución del dinero, sigue sin ser rentable, al menos en nuestro negocio.

Opción B: Nos preocupamos por el cliente hasta no ganar dinero:

Hay una opción intermedia para la que partiremos de la base que recuperamos el dinero del pedido original, pero como ya hemos dicho, en la vida real eso podría no ocurrir.
Buscamos una oferta con otro proveedor que envía en 24H y que tiene un precio superior o con el mismo proveedor pagamos el envío express, para que al día siguiente nuestro cliente tenga sus zapatillas. En este caso lo más normal es que te comas tu margen o llegues incluso a perder hasta 8€ por pedido.
No es tan drástico como el caso anterior y si tu recurrencia es buena es un coste de adquisición de cliente que te podrías permitir. En nuestro caso lo hemos hecho alguna vez con casos graves en los que las zapatillas no le van a llegar al cliente o hemos cometido un error como intermediario.

Opción C: Removeremos cielo y tierra pero queremos nuestra comisión:

Los dos casos anteriores son ideales de la muerte, pero en la mayoría de nuestros casos los cliente pueden esperar unos días más, en los que generalmente se resuelve la entrega del pedido. Pero resulta que a veces no se resuelve ... pues se cancela el pedido y se hace la devolución integra del importe de compra. Nadie pierde dinero.
A lo mejor te parece sorprendente, pero muchos clientes se quedan contentos así, porque son humanos y entienden que tú como una pequeña startup que intenta hacer las cosas lo mejor posible no puedes hacer magia. El coste de esto es el mínimo posible que es el tiempo de la operativa de atención al cliente, pero no siempre es una salida posible por la actitud del cliente.

Opción D: Whatever:

Podrías pensar, es que hay muchas más opciones y muchos puntos intermedios que no has comentado. Pues sí, los hay por eso los dejo para tu imaginación que ya bastante me he extendido.

Conclusión

En mi idea original, en mi mundo ideal, la atención al cliente de Highland Coffees es la que quiero tener yo. Cuando el mundo real me ha abofeteado, he recapacitado y aprendido que tengo que tener en cuenta múltiples factores a la hora de tomar decisiones en la resolución de problemas con el cliente.
  • Margen: Si tienes un margen del 200% puedes hacer maravillas, desde una atención al cliente mega personalizada hasta enviar un segundo pedido, pero si es un 5% a lo mejor tienes que reducir un poco más las expectativas.
  • Recurrencia: A lo mejor tu margen es del 15% pero tu recurrencia es semanal o mensual, oye pues no está mal, voy a intentar hacer un Highland Coffees porque me puede resultar rentable a un año vista. ¿Tienes un margen del 6-8% y una recurrencia anual en el mejor caso? bienvenido a nuestro mundo amigo.
  • Gestión del descontento: Ojo con lo que haces, intenta saber quien te ha comprado. Si Taylor Swift y sus 73,9 millones de seguidores te han hecho un pedido y no le ha llegado ... trátala bien. !Pero qué mal, eso es tener clientes preferentes! no no, eso es tener dos dedos de frente y no ir metiendo los dedos en el enchufe. Ahora, incluso Taylor comprende que no siempre puedes tener la atención de Highland Coffees en tu negocio, si también es humana.
Por supuesto esta es sólo mi visión de desarrollador de software, no de experto en la materia, así que si crees que hay algo más que aportar, corregir o mejorar, comenta, crea tu propio blog o lo que quieras :-)

domingo, 2 de agosto de 2015

AngularJS tips: ng-if versus ng-show

El hombre es el único animal que tropieza dos veces con la misma piedra, y en mi caso lo puedo hacer incluso 5 ó 6 veces, por eso quiero escribir esta entrada acerca del uso de las directivas ng-if y ng-show (y por extensión de ng-hide) de AngularJS.

El problema


Pero primero lo primero, veamos que hacen estas dos directivas en un breve ejemplo de código.



Si ejecutas este código en tu navegador verás que tan sólo aparece un input en pantalla y que el resto de código HTML no se muestra. Esto se debe al uso de las directivas ng-if y ng-show que tienen precisamente esa finalidad, ocultar elementos mientras la evaluación de sus condiciones no se cumplan. En este caso cuando escribimos la palabra "test" en el input, ambos elementos se harán visibles instantáneamente.

Pero en este código hay más de lo que parece. Si te fijas en el bloque script al final del body, verás que hay una función asociada al evento onclick de los elementos ocultos. Y si haces click en cada uno de los divs comprobarás como, en la mayoría de los casos, sólo funciona para el bloque asociado a la directiva ng-show.

El uso correcto de cada directiva


¿Y a qué se debe esto? Te preguntarás si no has trabajado un poco con AngularJS.

Pues muy sencillo, lo que hace Angular cuando aplicas la directiva ng-show es ocultar el elemento haciendo uso de una propiedad CSS, por lo que el elemento sigue existiendo en el DOM aunque no lo veamos. Pero en el caso de ng-if elimina el elemento del DOM hasta que se vuelve a cumplir la condición.

Si como es mi caso, haces uso de alguna librería que no está gestionada con Angular, debes tener cuidado con cual de ambas directivas debes utilizar. Recuerda, con ng-show ocultarás el elemento pero seguirá estando disponible en el DOM si quieres hacer algo con él (como hacer el bind de una función), pero con ng-if el elemento no estará presente en el DOM si necesitas hacer alguna operación con él.