Facebook quiere ser tu mejor amigo y tu psicoterapéuta

Facebook South ParkLeo con estupor en Wired que en el laboratorio de modificación conductual de Facebook, más conocido cómo Facebook Artificial Intelligence Research (FAIR) están trabajando en un asistente que te avise si estás intentado publicar una foto embarazosa en tu muro —quizá borracho con amigotes y compañías de dudosa reputación—.

Creo que tengo unos pocos amigos abstemios. Pero con la mayoría me he tomado un vino, cuando no varios, y no me sorprendería verles borrachos en una fotografía, por consiguiente, no comprendo en qué afecta eso a su reputación, cuando hasta Jesucristo era bien conocido por convertir el agua en vino siempre que le apetecía.

No entiendo el neuroticismo moral de las redes sociales. Por una parte comparto la postura oficial de Mark Zuckerberg sobre que si te preocupa que algo se publique en Facebook entonces es que no deberías estar haciéndolo. Pero, por otra parte, Facebook manipula los contenidos para que todo el mundo parezca políticamente correcto. Es por esto que Facebook es tan mortalmente aburrido, pues, como escribió Risto Mejide, si consigues decir algo, lo que sea, sin ofender absolutamente a nadie entonces es que lo que has dicho carece por completo de contenido.

Supongo que lo próximo será un analizador de texto que al comentar algo estilo “esa gilipollez que has dicho es una mierda como una casa de doce pisos” te sugiera: “¿quiso usted decir ‘esa proposición tuya se fundamenta en hipótesis poco sólidas’?”. Y entonces ¿qué tenemos? ¿la misma mierda con distinto nombre?

Sumemos esto a la paradoja estadística de que nuestros amigos tienen siempre (en media) más amigos que nosotros. Entonces tendremos una sociocosa en la que, si nos ponemos a compararnos, no podemos sentirnos de otra manera que desgraciados por la vida (aparentemente) color de rosa que tiene todo el mundo excepto nosotros.

La dinámica de Facebook es como la del Cuento del Traje Invisible del Rey Desnudo. Aquí vamos unos y otros en pelota; no, diré más: vamos en pelota picada y, sin embargo, nos paseamos por la calle fingiendo que vestimos de seda igual que todo el mundo.

Post Relacionado:
Un nuevo concepto de privacidad.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Usos sociales de la tecnología | Deja un comentario

El A,B,C,D antes de invertir (o que te inviertan)

Hace unos días hablaba con un joven amigo (de un tiempo a esta parte casi todos los nuevos amigos son más jóvenes que yo) quien me preguntaba sobre lo esencial antes de casarse con un inversor. La verdad es que lo primero que le pregunté es si podía hacerlo sin inversores. Cuando me persuadió de que no, entablamos la conversación del torero principiante con el maestro:

“Maestro, pa sé torero ¿qué es lo que hace farta?”.
“Hijo, pa sé torero, las cuatro bes: Bista, Balór, Belocidá y Buevos”.

Análogamente, si vas a invertir, o buscas inversión, opino que hay cuatro detalles legales esenciales a los que prestar atención:

A. Los derechos de liquidación preferente.
B. Los derechos de suscripción preferente y las cláusulas antidilución.
C. Los lock-ups de venta.
D. El derecho a sentarse en el consejo de administración.

Derechos de liquidación preferente

Casi todos los contratos de inversión bien redactados contienen una cláusula que dice que en el caso de que se produzca un evento de liquidez el inversor tendrá derecho a recuperar al menos el dinero que invirtió antes de que ningún otro socio con participaciones cobre. A veces el derecho es sobre un múltiplo de la inversión (2x o 3x). Mi opinión al respecto es que es razonable ofrecerle al inversor que, si bien no va a ganar ningún dinero con la inversión, al menos se hará lo posible para que no pierda. Lo que sí me parece también razonable es que junto con la liquidación preferente se incluya un ratchet para los minoritarios.

Una posible alternativa a liquidación preferente es un pacto de compraventa forzosa por parte de los socios emprendedores a los inversores, el cual, si existe, opino que debería funcionar en los dos sentidos: al cabo de (digamos) 5 años los emprendedores tienen la obligación de comprar las participaciones a los inversores por un precio mínimo garantizado, pero los inversores también tienen la obligación de vender por un precio máximo de manera que los emprendedores puedan deshacerse de un inversor que ya no hace ninguna otra cosa en la empresa que exigir dividendos.

Algunos inversores pueden exigir un derecho de rescate consistente en un porcentaje de la ganancia obtenida durante un plazo por quien adquirió sus participaciones. Personalmente creo que esto no es justo, además de constituir una fuente de problemas el que no te puedas desprender de un inversor ni siquiera tras firmarle una liquidación que no es tal.

Suscripción preferente y dilución

En España el derecho de asunción preferente en la creación de nuevas participaciones está garantizado en el artículo 93 de la Ley de Sociedades de Capital. De modo que, a menos que exista un acuerdo de exclusión del derecho de preferencia, los socios actuales siempre tienen derecho a acudir a las ampliaciones de capital para mantener su porcentaje de participación.

En EE.UU. los pro-rata rights no son por defecto y prácticamente todos los inversores los especifican explícitamente en el acuerdo de inversión. Muchos de ellos, además, exigen que si el business angel de la ronda seed no acude a la ampliación con una cantidad considerable de dinero (entre 300.000$ y 1.000.000$) entonces pierde sus derechos de suscripción. Yo encuentro esto injusto y no lo aceptaría ni como business angel ni como emprendedor. O el inversor puede pedir también algún tipo de “super pro-rata rights” que le garanticen que en la siguiente ronda podrá invertir al menos un múltiplo de lo que invirtió en la anterior.

El derecho de suscripción preferente es muy importante para el inversor por dos motivos:

1º) Porque, dado que sólo un pequeño porcentaje de las inversiones dan algún beneficio, es importante poder seguir invirtiendo en las pocas operaciones que van realmente bien.

2º) Porque el grado de control en la sociedad puede perderse como consecuencia de una disminución en el porcentaje de participación. Yo le recomiendo a cualquier aspirante a business angel que en ningún caso acepte una participación inferior al 5% en una start up con una cláusula anti-dilución por debajo de dicho porcentaje. Esto es debido a que, por ley, los socios con un 5% o más tienen derechos que los más minoritarios no tienen, en particular el derecho a exigir auditorías detalladas de todas las cuentas de la sociedad.

Para el emprendedor es importante que el inversor renuncie a sus derechos de suscripción preferente si se dan determinadas condiciones. El objetivo de esta renuncia es impedir que el inversor vete o retarde la entrada de nuevos inversores, bien porque no tiene dinero para acudir a la ampliación, bien porque la empresa está obteniendo unos resultados tan satisfactorios que no quiere arriesgarse con ninguna inversión extra para intentar hacer crecer el negocio.

La dilución se produce mayoritariamente cuando se emiten nuevas participaciones cuya valoración es inferior a aquella por la que el inversor compró con anterioridad. Normalmente el inversor se protege de la dilución mediante el derecho a emitir nuevas participaciones que compensen la dilución causada por la ampliación de capital.

Las aceleradoras de start ups también suelen incluir cláusulas anti-dilución en sus préstamos participativos que les garanticen un porcentaje mínimo del capital social post money en la start up.

Lock-ups de venta

Los lock-ups que impiden vender las acciones o participaciones durante determinados intervalos de tiempo son una de las cláusulas más traidoras que se pueden firmar, y, en mi caso, una causa por la que he dejado de ganar bastante dinero en varias ocasiones. Sucede que el periodo de tiempo en el que una start up mantiene una alta valoración normalmente es muy efímero. Los lock-ups se aplican habitualmente a los emprendedores con la finalidad de evitar que encuentren una oportunidad de vender y se larguen dejándolo todo empantanado. Eso es razonable. Lo que no es razonable es que los lock-ups prohíban vender al emprendedor precisamente en el momento en que éste obtendría una mayor cantidad de efectivo por sus participaciones.

Derecho a sentarse en el consejo

A mi nunca me han gustado los consejos de administración. He intentado evitarlos siempre que he podido, y he declinado participar en ellos tanto como me ha sido posible. Y eso ha sido un error debido a que los emprendedores jóvenes carecen de experiencia en la administración de sociedades o su ciega ambición les induce con facilidad a tomar decisiones estúpidas y hasta delictivas.

Comprendo que para el emprendedor los consejos son la pesadilla trimestral, y la reunión sobre la que procastinar más activamente durante la mayor cantidad de tiempo posible. En ese caso opino que lo mejor es delegar el máximo de trabajo burocrático en un socio fundador dedicado a gestionar a los inversores mientras que el otro permanece centrado tanto en el día a día como en la visión estratégica del negocio.

Es muy conveniente a efectos prácticos que el consejero delegado disponga de poderes tan amplios como sea posible. El consejo debe cumplir una misión consultiva pero no ejecutiva. Si el consejo no confía plenamente en el consejero delegado entonces lo mejor es buscar otro consejero delegado o simplemente disolver la empresa.

Para terminar, una causa frecuente de cabreo entre los emprendedores es cuando los inversores deciden reemplazarles por otro gestor al frente del consejo (esto le pasó hasta a Steve Jobs). A mi personalmente me hubiera encantado que en el pasado alguien me relevase de ciertas funciones, aunque comprendo también que un consejero delegado paracaidista impuesto por los inversores puede ser el principio del fin de la empresa.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Análisis Financiero del Software Libre, Emprendizaje | 1 comentario

Cómo atribuimos veracidad a la información que recibimos

Vivimos permanentemente infoxicados. Incluso aunque no queramos, recibimos a diario tal volumen de información que a duras penas ni siquiera podemos prestar atención a una fracción minúscula de ella.

Para gestionar este caudal de la vida en streaming el cerebro emplea algunos atajos de los cuales a menudo no somos conscientes pero que influyen enormemente en la opinión que nos formamos sobre las cosas.

En este post repaso 13 sesgos cognitivos bien conocidos en psicología que nos dificultan entender y valorar adecuadamente la información que recibimos a diario.

1. Creer es ver

En su artículo How Mental Systems Believe Daniel T. Gilbert argumenta en favor de la tesis de Spinoza afirmando que para poder comprender una idea primero debemos creer en ella. Cuando nos encontramos con una proposición inmediatamente intentamos creerla. El proceso de creer se desarrolla buscando indicios que soporten la veracidad. La cantidad y calidad de los indicios no es relevante. Lo importante es la coherencia interna de la historia. En el momento en que la historia se vuelve incoherente dejamos de creer en ella, pero no antes. Los experimentos indican también que las personas exhaustas y desesperadas tienden a creer cualquier cosa que se les diga por increíble que sea.

2. Efecto Halo

Efecto Halo es un término acuñado por Edward L. Thorndike quien demostró epíricamente que existe un sesgo cognitivo por el cual la percepción de un rasgo particular es influenciada por la percepción de rasgos anteriores en una secuencia de interpretaciones. Traducido al lenguaje coloquial esto significa que la primera impresión que nos llevamos de una persona condiciona las opiniones posteriores que nos formamos de ella. Como la primera impresión es la del atributo más notorio, este atributo eclipsa la percepción de los demás. Más genéricamente, el Efecto Halo causa que el orden en que aprehendemos los diferentes aspectos de una idea condiciona nuestra evaluación final sobre la misma.

3. Alineación Ideológica

En su best-seller The Wisdom of Crowds James Surowiecki presenta una serie de experimentos destinados a medir la capacidad de los grupos de individuos para evaluar situaciones y tomar decisiones. Una de las pruebas consiste en estimar cuántas canicas hay en un tarro tarea en la cual los humanos son especialmente inexactos individualmente pero muchísimo mejores cuando se toma la media de estimaciones de múltiples individuos. Lo relevante de este experimento para el tema que nos ocupa es que el conocimiento de lo que han estimado previamente otros individuos altera las estimaciones individuales posteriores reduciendo en la práctica el tamaño de la muestra y deteriorando la calidad de los resultados. Similarmente a cómo sucede con el Efecto Halo, los primeros en verter opiniones sobre un tema cualquiera llevan ventaja a la hora de persuadir a los demás sobre la veracidad de sus ideas.

4. Atribución de Credibilidad (Framing Effect)

Al hilo del Efecto Halo, otra herramienta que el cerebro utiliza para hacer juicios rápidos es la atribución de credibilidad en función de la fuente. La credibilidad se gana y depende principalmente de cuatro factores: la relación con la persona, su currículum, su transparencia y su carácter. Esto hace la credibilidad algo terriblemente esquivo. Los padres tienden a creer cualquier cosa que les dicen sus hijos. Los inexpertos tienden a creer cualquier cosa que afirma un presunto gurú (que a la postre no lo es tanto). La transparencia se presupone. Y la asociación subjetiva entre el carácter y la credibilidad real es espuria.

5. Métricas Relativas (Contrast Effect)

El cerebro es mayormente incapaz de trabajar con medidas absolutas. No se puede conseguir que una persona entienda la magnitud de una situación a menos que pueda relacionarla con otra y esta segunda, a su vez, con una tercera más simple que implique no tener que contar hasta más de diez.

Con respecto a las métricas relativas son especialmente importantes las anclas (anchors) y el efecto anclaje (anchoring effect) un fenómeno bien estudiado y conocido en psicología por el cual la primera cifra que se recibe como estimación del valor de una variable desconocida influye en todas las estimaciones posteriores. Para comprar algo primero pedimos un precio, luego el resto de los precios nos parecen caros o baratos en función del primero. Si el primer precio era elevado entonces el producto nos parecerá una buena opción de compra cuando recibamos otros más bajos. Pero si el primer precio era bajo entonces todos los demás nos parecerán caros.

6. Fobia a la Ambigüedad

Se trata de un efecto descrito por primera vez por Daniel Ellsberg. Ante dos o más opciones la gente en general preferirá aquella sobre la que disponga de más información aunque sea realmente menos probable que otras.

7. Sensibilidad Sensorial

Cada persona tiene un patrón diferente de sensibilidad sensorial. Según el género, a los hombres, en general, es mejor mostrarles algo con un dibujo mientras que con las mujeres es más eficaz decírselo con palabras. La tendencia es hacia el predominio de la imagen y la infografía sobre el texto porque el ojo es una máquina extraordinariamente eficaz de detección de patrones y relaciones.

8. Heurística Substitutiva

La heurística substitutiva es una idea procedente del libro Cómo plantear y resolver problemas de George Pólya. Si no podemos responder a una pregunta directamente entonces buscamos otra pregunta más sencilla que sí podamos responder y que esté relacionada con la primera. El ejemplo más fácil es cómo se forma la intención de voto. Los ciudadanos no piensan razonadamente por qué deberían (o no) votar a un determinado candidato. Lo que hacen es formularse preguntas más concretas ¿subirá los impuestos? ¿recortará las libertades civiles? Luego de forma constructiva se elabora una respuesta holística a la pregunta original en base a respuestas parciales. El inverso de este mecanismo es probablemente la técnica de persuasión manipuladora más abusada por los políticos haciendo múltiples promesas sobre cosas que aisladamente no son cruciales pero que la gente suma para decantarse por un partido u otro.

9. Preprocesamiento emocional

Todas las personas sienten antes de pensar. Esto es debido a que la parte del cerebro que procesa las emociones es más simple y primitiva que el neocórtex y, por consiguiente, funciona a mayor velocidad. A esto yo lo llamo el efecto “susto en el cine”: sabes que el monstruo va a salir, oyes los acordes tenebrosos, sabes que el monstruo es de mentira, y, aún así, pegas un brinco de la butaca al techo cuando finalmente aparece porque la parte racional de tu cerebro tarda más tiempo en enterarse de lo que está pasando que la parte emocional. Esto no sería muy relevante si en todos los casos las emociones sólo precediesen al raciocinio en pocos milisegundos como sucede en el cine. Pero la emoción puede bloquear el juicio crítico durante mucho tiempo y de formas insospechadas. Un ejemplo de mood-congruent memory bias lo expone Daniel Kahneman con las siguientes preguntas:

“¿Cúan feliz eres estos días?”
“¿Cúantas citas románticas tuviste el último mes?”

Según un estudio, no existe correlación entre las respuestas a ambas preguntas. Pero si se formulan en orden inverso:

“¿Cúantas citas románticas tuviste el último mes?”
“¿Cúan feliz eres estos días?”

Entonces ¡sí existe una fuerte corrrelación! La explicación es que el estado emocional que induce la primera pregunta condiciona la respuesta a la segunda. La consecuencia es que el órden en el que se emite la información influye en la evaluación final de la misma. Esto es bien sabido por los expertos en comunicación y es por lo cual se recomienda empezar siempre cualquier discurso por su parte amistosa y positiva.

10. La falacia de la conjunción

La falacia de la conjunción es otro hallazgo de Tversky y Kanheman. El experimento original es como sigue:

Linda es una mujer soltera de 31 años, locuaz y brillante. Se licenció en filosofía. Como estudiante mostró un gran interés por las causas de discriminación y justicia social. También participó en manifestaciones anti-nucleares.

¿Qué es más probable?

a) Linda es una cajera en un banco.
b) Linda es una cajera feminista de un banco.

Los estudios de Tversky y Kanheman muestran que la mayoría de la gente elige la opción b) aunque es estadísticamente menos probable que la a).

La consecuencia de este sesgo cognitivo es que se puede aumentar la percepción de veracidad de una historia añadiéndole detalles que la hagan más coherente internamente aunque dichos detalles reduzcan, de hecho, la probabilidad real de que la historia sea cierta.

11. La ilusión del cluster

Los experimentos de psicología muestran que para estimar la frecuencia de un suceso las personas tratan de recordar ocurrencias recientes. Si les resulta fácil recordarlas entonces atribuyen una alta frecuencia al suceso. Esto influye de dos maneras: 1ª) las personsa tienden a desdeñar la relevancia estadística de aquello que no sucede en su entorno próximo, y 2ª) es posible crear una sensación de frecuencia elevada repitiendo machaconamente noticias similares aunque el porcentaje real de casos en los que se produce el suceso sea bajo.

12. Estereotipos

El término estereotipo fue utilizado por primera vez en el contexto de la psicología moderna por Walter Lippmann en su libro Public Opinion publicado en 1922. El estereotipo es la creencia de que una persona será de una determinada manera o se comportará de una determinada forma porque presuntamente pertenece a una clase social.

13. Ilusión de familiaridad

Este efecto lo definieron por primera vez Hasher, Goldstein, y Toppino en 1977. Las personas tienden a tomar por ciertas las afirmaciones que han escuchado con anterioridad incluso si no se acuerdan conscientemente de cuándo ni dónde las han escuchado. Este efecto es especialmente pernicioso cuando se combina con la amnesia infantil (la incapacidad de preservar recuerdos de la infancia especialmente antes de los cuatro años). El mayor peligro es que los niños no se acuerdan de cómo han aprendido algo y, por consiguiente, les resulta extraordinariamente complicado desaprenderlo debido al conservadurismo bayesiano descrito por Ward Edwards en 1968.

Posts relacionados:
Nobodies are the new somebodies.
Cómo Internet modifica nuestras capacidades intelectuales y sociales.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Mitos, arquetipos y filosofía | 2 comentarios

Cosas que necesitas saber sobre el despliegue en La Nube

En un momento de la historia apareció La Nube ¡Rayos! ¿Por qué los informáticos no pueden llamar a las cosas por su nombre? ¿Por qué no pueden llamarlo “lavandería compartida”: ese sitio donde todos vamos a lavar nuestros trapos sucios en un maquinorcio que no nos cabe en la casa?

Muchas veces alguien me ha pedido que interprete lo que le está diciendo el informático, veamos si en esta ocasión soy capaz de interpretar un poco eso de La Nube.

En resumen, son cinco los pilares que debes establecer:

1. Despliegue Software
2. Infraestructura Hardware
3. Conectividad
4. Políticas de protección y recuperación
5. Monitorización

En función de cómo sientes las bases de lo anterior, cinco indicadores variarán:

1. Seguridad
2. Escalabilidad
3. Disponibilidad
4. Latencia
5. Mantenibilidad

Despliegue de Software I: Fase Prototipo

Antes de elegir una infraestructura hardware necesitas saber qué es lo que vas a querer desplegar. Necesitas una lista de todos los componentes, e, importante, la versión exacta de cada uno. No es suficiente con especificar “Python, Django y Postgres”. Si no especificas las versiones pronto tendrás que reinstalar algo o te encontrarás con un buen lio de compatibilidad.

Puedes empezar de forma fácil instalando con Bitnami. A mi me gusta tener el mayor grado de control sobre lo que instalo, compilando yo mismo desde fuentes y esas cosas… pero para empezar rápidamente Bitnami es a mi juicio la mejor opción.

Para el software y librerías privados se necesita un sistema de gestión de dependencias y un repositorio de control de versiones.

Para gestionar las dependencias en Java casi todo el mundo usaba Maven y últimamente la moda es migrar a Gradle. En Python manda pip.

El paradigma de control de versiones ha cambiado de Subversion a Git.
La diferencia fundamental es que Subversion es un repositorio centralizado diseñado para que los programadores no se pisen los cambios entre ellos desincentivando que trabajen en paralelo sobre el mismo módulo de código. Mientras que Git es un sistema distribuido que fomenta crear ramas (branches) y luego fusionar el trabajo (merge). Git se inventó porque los equipos de desarrollo grandes y geográficamente distribuidos llegaron a los límites prácticos de Subversion.
Pero para un equipo pequeño a mi el modelo de Git Flow me ha causado más quebraderos de cabeza que beneficios porque es más difícil que los programadores entiendan y sigan Git Flow que Subversion y porque los merges a veces causan desastres en el código que no son nada aparentes a primera vista. No obstante, la inercia de Git es tan grande que ni siquiera voy a recomendar ninguna otra cosa. El repositorio Git se puede montar en un servidor propio o en un SaaS como Github o Bitbucket.

Ni en broma pongas un sistema en producción sin un sistema de gestión de dependencias y otro de control de versiones. Y no hagas un merge seguido de una release sin cerciorarte de que no se ha perdido nada en el código.

Despliegue de Software II: Fase Mínimo Producto Viable

Una vez que tienes una “demo jugable” en un portátil hay que compartirla con todos los desarrolladores (ya sean plantilla o subcontratistas).
Todos los desarrolladores deben trabajar exactamente con el mismo entorno, porque de lo contrario se produce el efecto “en mi PC funciona” (pero en el servidor de producción no).
Mi forma favorita de sincronizar a los desarrolladores es crear una máquina virtual con Vagrant para VirtualBox o VMWare.
Vagrant permite especificar cómo se instala una máquina desde cero en un paquete distribuible que ocupa menos de diez megas.
Para que la máquina se instale cien por cien de forma desatendida (incluso con Vagrant) todavía se necesitan un buen puñado de scripts bash que no son nada fáciles de escribir.
No pongas un sistema en producción sin un procedimiento 100% automatizado y repetible para reinstalar cada máquina y desplegar en ella el software necesario.

Despliegue de Software III: Ampliación de capacidad

Cuando se supera la decena de máquinas es conveniente empezar a utilizar un sistema como Puppet que permita gestionar de forma centralizada lo que tiene instalado cada máquina. Puppet sirve para reemplazar a los script bash de instalación hechos a mano, pero, además, permite gestionar qué está instalado en cada máquina desde un Puppet Master. Puppet intenta reducir la dificultad de los scripts bash de instalación, pero lo hace cambiando bash por otro sistema propietario de definición de paquetes que a mi no me acaba de convencer.

Tanto Vagrant como Puppet están pensados para distribuir el software base, no el aplicativo en sí mismo (aunque también se puede usar para eso). Para la distribución de aplicativos en un pool de máquinas mi herramienta favorita es Docker. Docker hace uso de una funcionalidad en el kernel de Linux que permite aislar los recursos de un proceso de todos los demás. Es una especie de máquina virtual ultraligera. La idea es que cada pieza necesaria sea un contenedor Docker y que, disponiendo de varias máquinas, se le pueda decir a Docker: mira aquí tengo estos paquetes por un lado, y estas máquinas por otro, coge los paquetes y haz esta explotación de la máquinas.

El problema inadvertido que tienen estas herramientas es que crear una nueva máquina virtual se vuelve tan sencillo que fácilmente se produce una proliferación de ellas y a más máquinas virtuales mayor coste de mantenimiento. Crea un protocolo que dificulte la creación de una máquina virtual lo suficiente como para evitar acabar teniendo más de las necesarias.

Infraestructura Hardware

Hay cuatro opciones: servidores dedicados, servidores virtuales, cloud privado y cloud público. Y dentro de cada opción puedes elegir administrarlo tú o pagar un servicio de administración. Lo óptimo depende de cual sea el volumen de datos y los tiempos de respuesta que requeridos, pero adelantaré un consejo: antes de elegir una plataforma con cualquier tipo de virtualización haz un benchmark pues es la única manera de estar seguro de lo que tienes realmente por debajo.

Las reglas del dedo gordo son las siguientes:

1. Si tienes un pequeño negocio online, con menos de 100 pedidos o menos de 10.000 visitas al día entonces contrata un servidor virtual administrado con LAMP o Django.

2. Si los tiempos de respuesta de tu aplicación a cada transacción deben ser muy breves, o si necesitas recibir gran cantidad de datos entrantes, entonces contrata un cloud privado estilo Stackops o Stackscale.

3. Si necesitas escalabilidad y puedes repercutir tus costes variables a los clientes, entonces contrata un servicio público como Amazon, Rackspace o HP Cloud.

4. Si el volumen de datos es grande y, al mismo tiempo, los tiempos de respuesta deben ser cortos y/o tu tráfico crece antes que tus ingresos, entonces monta un sistema híbrido de cloud privado con apoyo adicional de cloud público y gestiónalo todo con una herramienta tipo ECmanaged.

Comparativa de clouds públicos

Mi experiencia con los servicios cloud públicos es que los factores críticos son las latencias de acceso a disco y el ancho de banda de subida. La siguiente tabla es cómo puntúa UnixBench con una única copia de los tests corriendo en paralelo sobre una máquina con dos CPUs en varios servicios en comparación con un VM Vagrant en mi portatil con dos procesadores i5 asignados, 3Gb de RAM y un disco duro del 7.200 rpm. Aunque he intentado escoger las máquinas virtuales que más se parecen en el pliego de contratación, instancias con dos CPUs y 4Gb de RAM, hay que tener en cuenta que es una comparación de churras con merinas.

Proveedor Puntuación Global Velocidad Disco Download/Upload
Vagrant en local 135 102Mb/s
Amazon EC2 m1.large 346 40Mb/s 360 / 826 Mbps
Google CE n1-standard-1 2145 104Mb/s 789 / 62 Mbps
Azure Medium 714 14Mb/s 380 / 37 Mbps
Rackspace Cloud 373 210Mb/s 897 / 51 Mbps

Globalmente Google es el servicio cloud que mejor puntúa en UnixBench y, además, obtiene una buena puntuación tanto en CPU como en I/O a disco y
ancho de banda. Rackspace parece contar con un cache SSD, el cual puede hacerlo el más rápido en lectura pero no tanto en ejecución de bases de datos. Otros benchmarks como SPEC pueden arrojar resultados diferentes en el posicionamiento de los clouds públicos y, según este otro, las instancias de 512Mb de Rackspace son mucho mejores que las micro de Amazon para ejecutar PHP.

Otra métrica interesante es comparar los resultados de UnixBench con su coste (a mayor puntuación, menor coste).

UnixBench Scores by Cost

Y finalmente observar cómo están convergiendo los precios en todas las plataformas IaaS:

Average base IaaS prices over time

Conectividad

La calidad de la conectividad depende de dos parámetros, la latencia (de red) y el ancho de banda.

La latencia es una función de la cantidad de nodos de red que los paquetes tengan que cruzar desde el cliente hasta el servidor y, en menor medida, de la longuitud del cable por el que la información viaja casi a la velocidad de la luz. Por consiguiente, la mejor forma de reducir la latencia es simplemente colocar los servidores lo más próximos posibles a donde se encuentren los clientes.

El ancho de banda lo proporciona el proveedor. Para optimizarlo se puede montar una red de entrega de contenidos. La optimización de ancho de banda para dispositivos móviles y para aplicaciones de video streaming presenta dificultades adicionales más allá del ámbito de este artículo.

Políticas de protección y recuperación

Sobre los backups ya he escrito en otro artículo titulado Cómo prevenir y recuperarse de una pérdida de datos.

En cuanto a la seguridad, cinco cosas básicas:

1. Si tienes un servidor al cual se puede acceder con un par usuario/contraseña de estilo pedrito/manzanita99 eso es en la práctica lo mismo que tenerlo abierto para que el hacker más torpe del mundo entre y haga lo que quiera.

2. Los servicios de administración deben ser accesibles sólo mediante una VPN desde determinadas direcciones IP.

3. La máquina que ejecute la base de datos sólo debe ser accesible desde la red interna y sólo a través de determinados puertos desde el servidor web.

4. Ningún servidor es seguro si no ha pasado una auditoría de seguridad, las cuales suelen ser bastante costosas.

5. La mayoría de las brechas de seguridad son bien ataques perpetrados desde dentro bien robos de contraseñas que los administradores dejaron expuestas imprudentemente.

Monitorización

La monitorización de un sistema en producción debe incluir:

1. La disponibilidad de la máquina.
2. Los recursos disponibles en la máquina.
3. Los logs del servidor web.
4. La realización (o no) de transacciones.

La monitorización más básica consiste simplementen en verificar cada pocos minutos que el servidor está operativo. Que el DNS resuelve el dominio en la IP del servidor y que éste responde a peticiones HTTP por el puerto 80 en un tiempo razonable. Esto puede conseguirse con un simple wget contra unas pocas páginas diseñadas para indicar el pulso vital del sistema.

Para monitorizar los recursos lo más común es Cacti o Nagios.

Los logs deben analizarse para dos funciones completamente diferentes: la analítica con una herramienta tipo AWStats y la alerta de excepciones con otra herramienta tipo Sentry. Los logs del servidor web deben alertar inmediatamente cuando se esté produciendo un ataque por denegación de servicio o cuando se produzca una excepción inesperada (Error 500).

La monitorización de transacciones es la parte que requiere un mayor trabajo a medida. Si dejan de producirse transacciones de compra durante un tiempo es posible que la pasarela de pagos esté caída. Si, por el contrario, las ventas se disparan inesperadamente puede que los precios estén mal y la web ande regalando chollos a los visitantes, y más difíciles aún son de detectar las compras fraudulentas lo cual suele requerir de productos especializados bastante caros.

Administradores de Sistemas

Por último, se necesita un buen administrador de sistemas para gestionar todo lo anterior, ahora está de moda que los programadores hagan devops. En mi opinión eso está bien para sistemas pequeños y medianos, pero un programador tiene competencias diferentes de un administrador de sistemas y de un especialista en seguridad. En Madrid, nosotros trabajamos con Adminia hasta 2013 y la experiencia en general era buena.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Computación en la Nube | Deja un comentario

Por qué hay que enseñar a los niños a programar (entre otras cosas)

Creo que hay pocas experiencias más frustrantes que soportar que te enseñen cuando eres niño. Para empezar, quiero diferenciar claramente la enseñanza del aprendizaje pues cuando hablamos de la educación normalmente nos referimos a la enseñanaza, la cual, hoy en día, más parece que dificulta el aprendizaje antes que facilitarlo.

Opino que la raíz del problema consiste en destilar una serie de conocimientos y luego darle a los niños su ración de teoría y procedimientos sin ninguna explicación de cómo fueron descubiertos ni de cual es su propósito. Hasta que, perdidos entre tantos ejercicios, operan sin conocer los fundamentos.

Voy a enumerar algunas de las cosas que un programador sabe (sin darse cuenta de ellas). Estos son los fundamentos que un niño debería aprender de la programación (y que probablemente no le enseñen en el curso de informática del colegio).

Sobre la gestión de la complejidad

• Un programador sabe que nunca debe ponerse a hacer ninguna cosa sin una especificación de requisitos y un diseño. A priori, cada acción debe de servir para un propósito mayor definido con anterioridad.

• [Un programador sabe que] la única forma de resolver un problema grande y complejo es dividirlo en partes que se puedan resolver independientemente (divide y vencerás).

• Algunos problemas se pueden resolver aplicando repetidamente la misma operación sobre un conjunto de datos (por ejemplo una ordenación por burbuja).

• Un sistema grande y complejo que no ha evolucionado a partir de otro más pequeño y simple, no funciona y, además, es imposible arreglarlo para que funcione.

• En cualquier proceso de intercambio de información, los datos deben estar siempre en la forma en que le conviene al receptor y no en la forma en que conviene al emisor.

• Todo está conectado con todo, la pantalla muestra sólo una ínfima porción del código. La tarea en curso son las cien líneas de código que se ven; pero hay otras cien mil líneas con interacciones con ellas y que no se ven.

• La complejidad del sistema de control es proporcional, y del mismo orden de magnitud, que el sistema controlado.

• Si has escrito más de 100 líneas de código y no sabes muy bien hacia dónde te diriges entonces es el momento de refactorizar el código y reconsiderar las estrategia de resolución del problema que estás aplicando.

• La complejidad se puede re-expresar u ocultar pero no se puede reducir. Lo único que se puede inventar son formas más fáciles de lidiar con la misma complejidad, no con menos complejidad.

• El mundo se describe con objetos, funciones y algoritmos. Los algoritmos explican cómo las funciones toman un objeto como entrada y producen otro como salida.

• Los objetos pueden tener un estado interno, aunque, en general, cuantas menos mutaciones pueda sufrir dicho estado mejor. Idealmente todos los objetos deberían ser inmutables (el estado interno de un objeto no puede ser modificado una vez establecido). Esta es la forma más segura de evitar que dos procesos concurrentes modifiquen simultáneamente el estado del mismo objeto dejándolo inconsistente.

Sobre la detección y corrección de errores

• Después de diseñar y escribir un programa hay que depurarlo. Se tarda más tiempo en depurar el programa que en escribirlo, durante la depuración es cuando se produce el verdadero aprendizaje acerca del problema que está siendo resuelto.

• Si se carece de una herramienta de depuración que te permita saber lo que está pasando dentro del sistema cuando no funciona correctamente entonces nunca conseguirás que funcione bien.

• El coste de corregir un error aumenta exponencialmente con cada etapa en la que la construcción del sistema avanza sin que sea detectado.

• La correción de errores siempre es prioritaria sobre la introducción de nuevas funcionalidades.

• Las funcionalidades de alto nivel sólo pueden implementarse sobre librerías base extraordinariamente sólidas y bien testeadas.

• Cualquier error, incluso el más aparentemente pequeño e inocente, puede hacer fallar todo el sistema.

• Cualquier protocolo de comunicación digno de tal nombre incluye siempre un mecanismo de detección y autocorrección de errores.

• Independientemente de la cantidad de control de errores que se realice, el sistema siempre encontrará una manera de irse a la porra de forma totalmente inesperada.

Sobre la sostenibilidad

• La mantenibilidad de un programa depende de su complejidad ciclomática (en el mundo offline el equivalente es que la mantenibilidad de un sistema depende de su carga burocrática).

• No basta con escribir código que funcione, además debe de estar escrito para que otros programadores lo entiendan (más sobre esto en porqué la mitad de la población no se entiende con la otra mitad).

• No existe el “código autodocumentado”. El código más legible explica (en el mejor de los casos) lo que hace y cómo lo hace, pero no explica por qué lo hace de esa manera ni qué problemas surgen al hacerlo de otra manera.

• Las partes deben conectarse entre ellas sólo mediante interfaces bien definidos. Los detalles internos de cada parte deben estar encapsulados y ocultos a las otras partes.

Sobre el rendimiento

• El tiempo de ejecución depende de la clase de complejidad, no del tiempo individual que tomen cada una de las operaciones, el cual casi siempre puede reducirse introduciendo mejoras técnicas.

• La geometría del dispositivo físico utilizado es crucial para la elección del algoritmo óptimo (en el mundo offline esto quiere decir que la geografía y la orografía son muy relevantes para la toma de decisiones).

• El pico de carga que deberá soportar el sistema es 100 veces mayor del máximo previsto.

• Los sistemas que pueden procesar mayor carga de trabajo son aquellos en los que procesos operando en paralelo se comunican de forma asíncrona.

• Para eliminar los cuellos de botella y evitar el agotamiento de recursos, es necesario aplicar optimizaciones globales además de optimizaciones locales.

• Existe un número óptimo de tareas que un sistema puede realizar simultáneamente. Si el sistema opera en modo monotarea entonces demasiados recursos estarán ociosos la mayor parte del tiempo. Pero si hace demasiadas cosas a la vez entonces pasará más tiempo cambiando de contexto que haciendo nada útil realmente.

• La solución más simple es en el 90% de los casos la que funciona mejor.

Sobre la organización de equipos

• La estructura de un sistema es isomorfa a la estructura del equipo que lo creó.

• Las personas de mayor valor intelectual no deben realizar tareas de mantenimiento (véase garbage collectors).

• Ningún programador profesional trabaja sin un sistema de control de versiones que le permita deshacer fácilmente los últimos cambios.

• Los sprints con objetivos a corto plazo cada dos semanas que se van sumando producen a la postre mejores resultados que las planificaciones trimestrales.

Sobre la seguridad

• Es más fácil atacar que defenderse.

• La mayoría de los virus no pretenden destruir el sistema sino realizar actividades parasitarias a su costa sin ser detectados.

• Es más fácil impedir una infección viral que eliminarla.

• Cuando el sistema está demasiado contaminado lo mejor es reinstalarlo por completo.

• Para cualquier información existe siempre una copia de respaldo (política de contención de daños para el peor suceso imaginable) además, se conoce el tiempo que llevará la restauración en caso de desastre.

• La historia de todo lo sucedido debe encontrarse siempre en los logs de la aplicación. Los logs deben tener un formato que permita explotar su información con fines estadísticos.

Sobre la fiabilidad

• El sistema sólo es tan fiable como lo sea su parte más débil.

• Los sistemas auténticamente fiables son altamente redundantes y carecen de un Talón de Aquiles (single point of failure) que pueda hacer caer todo el sistema.

• Cuando se produce un error crítico el sistema debe emitir inmediatamente una alerta. Las alertas más severas desencadenan normalmente una parada temporal del sistema a la espera de que el administrador compruebe qué está sucediendo.

• Cada vez que añades una funcionalidad añades también un puñado de errores. Los mejores sistemas no son aquellos que hacen muchas cosas mal, sino los que hacen unas pocas cosas extraordinariamente bien.

• La probabilidad de encontrar nuevos fallos es directamente proporcional a la cantidad de fallos encontrados recientemente.

• Cuando el sistema está sobrecargado y funciona con lentitud una buena solución temporal suele ser reiniciarlo.

• La ejecución parcial es malísima. Las transacciones deben bien ejecutarse, bien no ejecutarse; pero no deben ejecutarse a medias (en el mundo offline el equivalente es que los contratos no deben cumplirse a medias).

• Cuando la misma información debe almacenarse en dos sitios por cuestiones de rendimiento, entonces debe existir un proceso de consolidación capaz de restaurar la información correcta en el caso de que las copias diverjan y tengan datos diferentes o desactualizados.

Posts relacionados:
Cómo Internet modifica nuestras capacidades intelectuales y sociales.
Poner PCs aumenta el fracaso escolar.
Las TIC tienen impacto negativo en el rendimiento escolar.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Software Libre & Educación | Deja un comentario

Decálogo sobre la Verdad

1. La verdad no puede ser dada, ha de ser descubierta.
2. La posesión de cosas materiales dificulta el descubrimiento de la verdad.
3. La verdad no puede superar a los prejuicios, ni siquiera tras una cantidad abrumadora de pruebas.
4. La gente cree buscando casos que refuercen una afirmación, no buscando contraejemplos para refutarla.
5. Como corolario de lo anterior, se puede mentir ocultando sólo el 1% de la información relevante.
6. La verdad tiene un valor relativo en función del bien o mal que puede causar.
7. La verdad tiene un precio demasiado alto como para que la mayoría de la gente esté dispuesta a pagar por ella.
8. Cuanto más te pide una persona que le digas la verdad menos deberías hacerlo.
9. No existe la verdad absoluta, ni siquiera la muerte y los impuestos. Para los segundos se inventaron los paraísos fiscales, otros creen que Elvis sigue vivo.
10. La verdad cambia con el tiempo, la auténtica verdad sólo brilla al final, cuando se ha ido todo el mundo.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Mitos, arquetipos y filosofía | 1 comentario

Síndrome de Estocolmo Digital

Voy a contar algo que todo el mundo sabe pero de lo que pocos se han dado cuenta: la informática la inventó un sádico, y es para usuarios masoquistas.

Este no es un post serio. Es para pasar el rato mientras me tomo un café. No vaya nadie a sentirse ofendido por tanta hipérbole, topicazos y despropósitos vertidos a continuación.

Entre los catorce y los dieciseis años un adolescente se da cuenta de que no tiene empatía, de que no le gustan las reuniones sociales con los zoquetes de sus compañeros, de que no le interesa el fútbol y, a veces, ni las mujeres. Entonces decide hacerse informático en la esperanza de que le enviarán, como a Steve Jobs en su juventud, al sótano de Atari donde nadie le hable. Piensa en ser un protagonista de IT Crowd con sus gadgets en el inframundo y que le dejen en paz. Pasa 6 años de su vida 4, creo, ahora, con lo de Bolonia, sufriendo el martirio chino de unos exámenes de los cuales no entiende ni las preguntas hasta que buen día recibe por sorpresa un título y piensa: “he terminado la carrera, luego soy Dios”. Entonces prepara su currículum pensando que le llamarán de la NASA inmediatamente para pedirle que diseñe el software de la próxima misión tripulada a Marte, pero ¡recórcholis! la única oferta que recibe es de Videoflautas Entertaiment Inc. para ofrecerle un puesto en soporte técnico de su videojuego Pokemon III. Y así pasa los próximos dos años de su vida explicándole a los usuarios que a menos que tengan una tarjeta gráfica Nvidia multi-GPU el puto videojuego no funciona en alta resolución. Para entonces, el ex-adolescente no sólo odia a sus ex-compañeros del instituto sino que para él todos los usuarios en su conjunto son como los Morlocks. A veces no le falta razón en su diagnóstico (se sabe que en Apple usan secretamente chimpancés para probar sus interfaces de usuario en experimentos ilegales con animales). Ansioso de resarcimiento contra esa subespecie humana a la que le aprobaron las integrales en el bachillerato a cambio de prometer que estudiarían letras, resabiado contra los que estaban de cañas y porros mientras él intentaba aprobar Álgebra II, envidioso del MBA ese que gana el triple que él con un cerebro que si fuese dinamita no le alcanzaría para volarse la punta de la nariz, y harto de la rubia que folla más que el coño de la Bernarda, el sufrido programador encuentra por fin el instrumento perfecto para su venganza: el aplicativo. El aplicativo es como un teclado sin letras que proporciona descargas eléctricas aleatorias al usuario. Nada proporciona mayor placer al programador que observar cómo los usuarios intentan futilmente averiguar para qué sirve cada tecla entre calambrazo y calambrazo. Algunos usuarios incluso se presentan un día en el sótano llorando porque necesitan no sé qué informe para mediodía pero la exportación a Excel no funciona. “¿Hola? ¿En qué momento no te enteraste de que me hice programador porque no tengo empatía? Ergo ¿Qué mierdas me estás contando sobre que necesitas Dios sabe cual informe antes de las doce?”. Si le preguntas al informático cómo se atan los cordones de los zapatos te responderá con el polinomio de Jones que describe el nudo. Y hasta aquí todo normal (sólo un pobre chico marginal buscando algo de afecto) excepto porque el usuario empieza a desarrollar Síndrome de Estocolmo, y, en vez de ver al informático como su captor, empieza a percibirlo como su salvador. El informático disfraza su patético complejo de inferioridad en forma de perfeccionismo. Siempre está hablando de hacerlo todo bien, niquelado y muy Agile. El informático siempre tiene una solución (en la siguiente versión) y siempre está mejorando algo. Además, no existe ninguna otra profesión en el mundo que disponga de un vocabulario tan amplio para describir la fatalidad: error, incidencia, pete, casque, cuelgue, tueste… te pueden decir que se ha caído el servidor ¿de dónde se cayó? ¿quién lo estará recogiendo? o incluso que a la aplicación se le ha pirado el panchito o que los chanquetes del turno de noche la liaron con los backups. Nada de esto nunca responsabilidad del informático quien es en todo caso el héroe salvador del desastre que él mismo causó. El Agile Management (mananeo agilista en español) contribuye a la espiral sadística. Se considera que el acercamiento correcto es siempre buscar soluciones y no responsables. Esto fomenta una cultura de colaboración y no de competición. Con el resultado de que a la postre les trae sin cuidado si se olvidaron una lata vacía de anchoas dentro del servidor cuando lo abrieron para reemplazar el disco duro y ahora todo el CPD huele como la cubierta del Pequod. He visto tantas cosas que si me dijeran que el software se ha conectado con la tostadora de mi casa y ha carbonizado el pan me lo creería (la Internet de las Cosas es lo que tiene). Llega un momento en que el usuario empieza sentir simpatía por el programador, así es como el programador obtiene el amor perdido: haciendo prisioneros. En ese punto el usuario empieza a creer que él mismo es el responsable de sus problemas. Ya no ve al programador como ese ser en camiseta de Star Wars que se alimenta sólo de chocolatinas y bebidas hipercafeinadas mezcladas con paracetamol (el cerebro gasta mucho azúcar) y llega un momento en que capaces son los usuarios hasta de invitarle a una caña para agradecerle tanto esfuerzo en sacar trabajo adelante.

Posts relacionados:
Porqué la gente odia a los programadores.
Cheat Sheet de marrones en un proyecto

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Mitos, arquetipos y filosofía | Deja un comentario

El nuevo hype de la inteligencia artificial

La inteligencia artificial es una de esas cosas que se ponen de moda más o menos cada lustro, como la realidad aumentada o la internet de las cosas. Esta vez ha salido en Wired lo que implica que ahora mismo existe un ejército de emprendedores que no tienen ni idea de que va realmente la inteligencia artificial pero ya están intentando emular el caso de IBM con su sistema de diagnóstico médico basado en Watson, cogiendo cualquier idea y añadiéndole el mojo “inteligencia artificial” lo mismo que hasta ahora se le añadía “movilidad”.

No todo será humo no obstante. Es probable que las infraestructuras cloud de lenguajes basados en bases de datos de conocimiento sean la próxima gran cosa. La clave está en convertir la inteligencia artificial en una utility.

Las dos plataformas que llevan la delantera son Watson y Wolfram Language, esta última me impresiona y creo que si no fuese tan privativa rápidamente se popularizaría. Aunque por supuesto hay que esperar a ver qué próximo movimiento hacen Google y Amazon en Inteligencia Artificial aplicada al procesamiento de texto. Sobre todo, no hay que perder de vista la capacidad de Google para entrenar a su inteligencia artificial. Cada vez que un usuario busca algo y hace click en un enlace le está diciendo a Google cual cree que es la respuesta más correcta a su pregunta original.

Muy resumidamente, Watson es un base de datos de 4Tb de texto de diferentes fuentes que se explota con tres ontologías (DBpedia, WordNet, y Yago) y un centenar de algoritmos diferentes que trabajan en paralelo.

Watson obtuvo sus resultados más espectaculares en dignóstico médico de muchas enfermedades incluído el cancer. IBM también anunció que colaborará con Repsol para buscar petróleo con Watson, y también que lo aplicaría al estudio de problemas sociodemográficos en África.

El software de IBM DeepQA está basado en UIMA (liberado por IBM a través de Apache en 2007) y en Hadoop. La estrategia consiste en aplicar diferentes algoritmos para tratar de hallar la respuesta a una pregunta y luego combinar los resultados para hallar el más probablemente correcto. La estrategia comercial de IBM es, por ahora, licenciar el software y vender hardware con procesadores POWER7 para ejecutarlo u ofrecer infraestructura en la nube por cantidades millonarias a grandes empresas. Esta estrategia sólo es sostenible en el corto-medio plazo y será reemplazada por un acercamiento basado en hardware commodity 100% distribuido lo mismo que la estrategia de Altavista basada en grandes servidores fue superada por los clones de Google. Existen varios catalizadores tecnológicos que indican que estamos a las puertas de un gran avance en inteligencia artificial. Watson necesitó almacenar toda su base de datos en RAM para responder con suficiente rapidez a las preguntas de la competición televisada Jeopardy para la que fue inicialmente diseñado. La simulación de redes de neuronas (un componente esencial en sistemas como Watson) era demasiado costosa antes de que se idease como implementarlas con GPUs y Geoff Hinton introdujese el deep learning.

Asistiremos también a enfoques híbridos hombre-máquina. Tras perder contra Deep Blue en el 97, Kasparov se dio cuenta de que podría ganar a la máquina si él también tenía acceso a la misma base de datos de movimientos previos que Deep Blue y recibir recomendaciones que seguir o modificar de vez en cuando según su propio criterio. Yo estoy convencido de que los militares estadounidenses aplican inteligencia artificial al análisis de informes sobre operaciones militares como el Kabul War Diary. En este caso, la forma de la redacción está claramente pensada para que se pueda procesar y entender automáticamente con facilidad. Esto mismo sucede con los traductores. Si metes un artículo como este en Google Translator obtendrás una traducción buena al 80% pero nunca la traducción que haría un humano. Para algunas frases el traductor puede llegar a poner en el otro idioma incluso justo lo contrario. Pero se puede redactar en español de una forma que Google pueda traducirlo correctamente, si sabes de antemano cuales son las limitaciones del traductor automático. Lo mismo que eliminamos las vocales e inventamos los emoticonos para comunicarnos por SMS, no sería raro que empezásemos a modificar nuestro lenguaje natural dejando de utilizar las expresiones que confunden a las máquinas.

Por supuesto, no todo en inteligencia artificial es comprensión lectora y búsqueda de respuestas. La propia Google parece estar públicamente más interesada en cosas como coches que se conducen solos que en su core business (aunque yo creo que eso son sólo señuelos de relaciones públicas por ahora). El reconocimiento de imágenes también ha experimentado un avance espectacular con sistemas que pueden reconocer no sólo una forma o una cara igual de bien que un humano como DeepFace, sino también incluso determinar lo que está pasando en un video. El reconocimiento de voz merecería asimismo un post entero aparte.

Post relacionado: Wolfram|Alpha vs. IBM Jeopardy.

Artículo relacionado: A New Era in Semantic Web History (Nova Spivack)

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Computación en la Nube, Disrupción, Minería de Datos, ¿Dónde estamos? ¿Hacia dónde vamos? | Deja un comentario

Transitividad

Hace algunos días leía a Alfredo Romeo lamentarse de la ingratitud de algunas personas. Siendo una de esas personas que conozco más preocupadas por su comunidad que por si mismas, es un estado mental que no me sorprende en él. Cuando necesites ayuda nunca acudas a aquellos quienes ayudaste, acude a los que te ayudaron en el pasado. En hebreo bíblico tsadaq (צדק) «justicia» es prácticamente lo mismo que el rabínico tsedaqah «caridad». Los antiguos consideraban la caridad como una forma de justica.

El mundo funciona (o debería funcionar) por un sistema transitivo. Cualquiera que haya tenido la suerte de haber sido instruído en lo básico de la teoría de conjuntos sabe que existen tres tipos de relaciones: reflexivas, recíprocas y transitivas.

La reflexividad nos daña haciéndonos pensar que la misión en la vida es definir cuales son nuestras metas y objetivos y luchar por ellos. A pesar de las repetidas advertencias de todos los sesudos gurús mucha gente sigue negándose a entender que la vida no tiene nada que ver con esta carrera hacia ninguna parte sino que la fórmula mágica consiste en hacer por los demás más de lo que uno hace por sí mismo.

Por otra parte, vivimos en la era de la obsesión por la reciprocidad, por la igualdad, por la compensación. Lo cual no es sino otra forma de reflexividad pero a través de otra persona, en una dinámica de la que esperamos recibir, como mínimo, lo mismo que aportamos, si no más.

El progreso social y personal se basa en una cadena transitiva de favores. El sistema en muchas partes del mundo es tan disfuncional porque una minoría bloquea la cadena transitiva y la justicia no fluye entre las personas porque ha sido secuestrada por una mafia de cobardes abusones.

Los orientales entendieron mejor este concepto y lo llamaron karma. Al final todo lo que haces en la vida vuelve a ti, pero sólo indirectamente.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Mitos, arquetipos y filosofía | Deja un comentario

Cómo gestionar equipos remotos y multiculturales

El jueves estuve en un meetup de mi coach agile favorito Ángel Medinilla. Fue inspirador, pero no voy a hablar de su presentación ni de sus libros sino de mis lios. En esta ocasión de mis penas y desventuras con los equipos remotos y multiculturales.

Lo primero déjame decirte algo: los equipos remotos multiculturales apestan. Sí; la multiculturalidad es un valor. Y sí, trabajar desde casa ayuda a conciliar la vida laboral con la familiar. Pero desde el punto de vista de un directivo es una pesadilla.

Conciliación.

Discrepo con el planteamiento radical de Marissa Meyer sobre que si lo importante son los equipos entonces hay que abolir el teletrabajo hasta el punto de llevarse a un neonato de 10 días a la oficina. Discrepo no porque me parezca ineficaz en términos empresariales (a fin de cuentas la misión de las empresas no es pagarte para que te quedes en casa) pero si hablamos de conciliación también debemos hacerlo en serio. Jornadas presenciales de diez horas de lunes a viernes más dos horas de transporte diario de casa a la oficina no dejan ningún espacio para otra conciliación que ese mal chiste llamado “tiempo de calidad”.

La cantidad de horas en la oficina también debería depender de la infraestructura de transportes. En España, para gente que viva en una capital de provincia con buena red de transporte público es razonable una jornada presencial de lunes a viernes. En el Reino Unido o en el Área de la Bahía, mi opinión es que lo mejor es no hacer ir a la gente a la oficina más de tres días por semana.

Multiculturalidad.

Pero vayamos al grano. Lo primero que yo recomendaría es que no te metas a gestionar un equipo de otro país si no conoces la cultura de ese país. Puedes contratar un intermediario pero entonces te arriesgas a que sea el intermediario quien se aproveche de ti. De los supermanagers superexpertos en supermulticulturalidad tampoco te fies, la mayoría no saben casi nada de coaching ni se han enterado de que en realidad son los psicoterapéutas de una guardería con niños de todos los colores.

Existen cuatro grupos étnicos principales que te puedes encontrar: latinos (incluyendo españoles e italianos), centroeuropeos, hindúes y chinos. En raras ocasiones, hay también otras minorías como coreanos, japoneses, urálicos o africanos. Y dentro de cada grupo hay diferencias, no hay que olvidar que tanto europeos como chinos se pasaron siglos matándose entre ellos.

Los temas principales a los que debes prestar atención son:

1. Cómo se establece la jerarquía. En europa existe una tendencia hacia colaborar antes que comandar. La moda es eliminar, al menos en teoría, las jerarquías. Los hindúes todavía tienen imbuído en en mayor medida su antiguo sistema de castas. No es casualidad que el actual CEO de Microsoft Satya Nadella sea hindú.

2. Cómo conectan las personas entre ellas. Las personas conectan por pequeños detalles. No conectan por ser del mismo pais, o de la misma religión, conectan porque les gusta el curry o la salsa barbacoa. Yo he estado en fiestas de buenrollismo de creación de equipo donde la mitad de la fiesta no se hablaba con la otra mitad porque eran incapaces de encontrar pequeños puntos en común sobre los que empezar a construir una relación interpersonal. A los latinos les cuesta menos que a los demás hablar de temas personales. Hindues y chinos son los más centrados en la familia (las religiones antiguas orientales veneran a los ancestros) pero de diferente modo que los latinos. Los cónyuges pueden jugar un papel importante, en muchas ocasiones es más fácil conseguir que conecten las esposas entre ellas que los miembros del equipo directamente.

3. Cual es el protocolo de qué va antes de qué. Los latinos, en general, primero se van a comer y hacen el negocio durante el postre. Los centroeuropeos no paran a comer.

4. Cómo se dice “si”, “no” y “a lo mejor” en cada idioma. En general, “no” es una expresión terminal muy violenta que la mayoría de las culturas prefieren evitar pronunciar directamente. Los centroeuropeos son los más proclives a un “si” o un “no” directo y tajante. Con los chinos “a lo mejor” significa “no”.

5. Cómo se manejan los plazos. Si un centroeuropeo te dice que tendrá algo el viernes a las dos, significa el viernes a las dos. Para un latino significa el lunes a las dos. Para un chino puede que ni siquiera sepa cuándo va a empezar la tarea.

6. Cómo se maneja la discriminación. En las empresas modernas no suele haber discriminación. Pero pueden surgir reinos étnicos de taifas. La discriminación de género no es normalmente problema entre los centroeuropeos. Pero puede haber serias exclusiones para las mujeres entre los hindúes. El respeto por la diversidad debe de estar incluído en la política de recursos humanos.

Comunicación y Herramientas

No se debe subcontratar ningún proyecto remoto sin disponer de las herramientas adecuadas para comunicarse y coordinarse.
Esto implica, como mínimo, voz IP multiconferencia, una aplicativo web de gestión de proyectos e incidencias, un repositorio de documentación y un sistema de control de versiones si lo que se está haciendo es código. Sin las herramientas tecnológicas adecuadas el fracaso de un proyecto remoto está garantizado.

Toma de decisiones

Según su grado de madurez, una empresa puede tener diferentes protocolos de toma de decisiones.

1. Comunicar. Se puede comunicar a los empleados lo que se va a hacer. Yo no encuentro ninguna razón para que este deba de ser el protocolo en ninguna institución que no sea militar. Si valoras mínimamente el capital intelectual de tu empresa querrás, al menos, conocer la opinión de tus empleados.

2. Vender. Además de comunicar, puedes tratar de venderle la idea tus empleados para que ellos también crean que es la decisión correcta.

3. Pedir opinión. Puedes decicir algo a priori y pedir opiniones para hacer pequeños cambios.

4. Pedir consejo. Antes de tomar una decisión puedes pedir consejo.

5. Consensuar. Tratar de llegar a un acuerdo con todas las personas que colaboran contigo.

6. Aconsejar. Dar consejo a los subordinados y dejarles que hagan lo que mejor les parezca.

7. Delegar. Otorgar plenos poderes y responsabilidad y ocuparse sólo de vigilar los resultados y gestionar las crisis.

Estos protocolos se ven afectados por la configuración geográfica que tenga el equipo. Normalmente, por ejemplo, cuesta un horror que los programadores sean conscientes de la cantidad de horas de soporte que acarrean algunos defectos software que a ellos les parecen nimios. Esto es así porque ellos no están con la gente del helpdesk.

En los equipos distribuidos geográficamente tiende a haber más violencia. Porque el email favorece tormentas con mucha mayor facilidad que las reuniones cara a cara. Y porque la incertidumbre de lo que estará pasando al otro lado del charco causa miedo.

Costes por hora y productividad

Cuando se subcontrata un proyecto es fundamental considerar tanto el coste por hora como la productividad. Como regla del dedo gordo cada hora presencial de un programador en Europa o en EE.UU. equivale a cuatro horas en remoto subcontratadas en India o China. Es por esto que tantas empresas siguen gastándose cantidades obscenas de dinero en salarios para programadores en Londres o en San Francisco.

Orientación al cliente

Es mucho más difícil para los euipos remotos orientarse al ciente final. Es necesario compartir no sólo información técnica sino también información de marketing y comercial que les permita entender qué están fabricando, para quién y para qué.

El valor añadido de la diversidad

Por último, la política de gestión debe reconocer el valor añadido de la diversidad. No se trata de asimilar como borgs a los extranjeros simplemente porque son mano de obra más barata. Diferentes modos de pensar producen diferenntes ideas, que a veces son difíciles de digerir a priori pero no por ello menos valiosas.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Organizando la Comunidad. Modelos de Desarrollo | Deja un comentario