La Pastilla Roja | Usos sociales de la tecnología

Proyectos neuróticos

Publicado el 19 de abril de 2017 por Sergio Montoro

Desde prácticamente el inicio de mi carrera profesional, pienso que las empresas de informática son centros para desarraigados sociales. Acogen a todos los nerds a quienes la sociedad rechaza y les proporcionan una razón para vivir (cambiando el mundo). No es esta una característica diferencial de las empresas de informática, para nada, pues también un equipo de fútbol de primera división o una unidad militar (donde todo el mundo tiene un arma) presentan grandes desafíos de gestión.
Existen diversas técnicas para evaluar las actitudes y relaciones de poder en las organizaciones, la más popular probablemente sea el Eneagrama. Pero lo que voy a comentar aquí sucintamente son los trastornos psicológicos más comunes entre los informáticos y sus jefes, y cómo se manifiestan en los proyectos; no por ser más importantes que ningún otro, sino solo porque me resultan más familiares.

Trastorno de Déficit de Atención o Trastorno de Función Ejecutiva

Este afecta con mayor frecuencia al CEO, ya que muchos de ellos de pequeños eran niños hiperactivos . El déficit de atención se manifiesta en que el CEO salta de una idea a otra cada día sin llegar a profundizar lo suficiente en ninguna. El trastorno de función ejecutiva consiste en que el CEO deja de hacer unas tareas esenciales en favor de otras que le gustan más y como consecuencia bloquea el progreso de los subordinados. Estos pueden ser trastornos psicológicos, pero también son a menudo una confusión sobre la función del CEO. En teoría, el CEO debe principalmente: 1) elaborar una visión, misión y valores; 2) reclutar al equipo gerencial adecuado; 3) asegurarse de que hay caja; 4) representar públicamente a la empresa. Y todo esto es cierto. Excepto que algunos CEO se dedican solo a las partes divertidas: tener nuevas ideas, hablar con empleados potenciales superestelares, comer con los inversores y salir en la prensa. Pero desdeñan la miríada de cosas aburridísimas que hay que llevar a cabo para cerrar un proyecto con éxito: revisar todos los detalles de la contabilidad, poner orden entre los mandos intermedios y, en definitiva, supervisar que los empleados produzcan los entregables en el plazo y calidad deseados. Fijar prioridades es una de las funciones más importantes de los jefes, sin embargo, la moda actual de usar Agile y Kanban en equipos (teóricamente) auto-organizados a veces genera un estilo de gestión en el que se están constantemente cambiando cosas sin terminar nunca nada.

Narcisismo

El orgullo es el pecado capital más frecuente entre los programadores. Se podría añadir, además, que aunque no sea el primero de la lista de Los Siete, probablemente sea aquel por el que Dios ha castigado más veces y con mayor dureza a la Humanidad. Puede que su engreimiento sea debido a que –según las métricas que se escojan– los ingenieros son más inteligentes que el promedio. Pero la falta de humildad no ayuda en nada al trabajo en equipo. El caso más común, que no es exactamente narcisismo patológico sino más bien pura inexperiencia, es el de programadores jóvenes quienes han aprendido a escribir código rápidamente pero no son conscientes de todos los entresijos y trampas que presenta un software grande y complejo. Estos programadores tienden a desarrollar soluciones sobrediseñadas, excesivamente abstractas y necesitadas de más recursos hardware de los que serían estrictamente necesarios. En los casos verdaderamente graves se trata de individuos que nunca reconocen cuando se han equivocado aunque siempre andan prestos a decir dónde se ha equivocado cualquier otra persona.

Indicios de que una aplicación esta sobrediseñada

todos los interfaces están separados de su implementación aunque en el 90% de los casos existe una relación 1 a 1 entre cada interfaz y su implementación.
todo el comportamiento se realiza mediante inyección de dependencias
existen clases que pasan los datos de un lado para otro sin realizar sobre ellos ninguna transformación relevante.
es prácticamente imposible encontrar el fragmento de código donde la aplicación graba realmente en la base de datos.
toda la pila de aplicativo no arranca, o lo hace muy lentamente, en una maquina con menos de 8Gb de memoria.

Baja Autoestima

Algunos jefes piensan que los empleados más convenientes son aquellos quienes tienen alta la moral y baja la autoestima pues así trabajan mucho pero exigen poco dinero a cambio. Puede que esto sea cierto, no lo sé, pero sí sé que la falta de autoestima es perjudicial para los proyectos, especialmente cuando se da entre algún mando. No todos los jefes son líderes fuertes y decididos. De hecho la moda actual es en favor del jefe “facilitador” que elimina obstáculos y crea consenso. Cerca del jefe con baja autoestima suele encontrarse un narcisista del grupo anterior para quien “consenso” es igual a un grupo de gente haciendo lo que él dice. Entonces el jefe que no confía en su propio criterio lo delega extraoficialmente en este otro miembro quien, en el papel de presunto gurú, realmente toma las decisiones. El “facilitador”, además, puede ser del tipo pasivo-agresivo y por el Síndrome de Procusto dedicarse a eliminar sistemáticamente a todo el que sobresalga hasta que el equipo entero queda formado por gente mediocre que se escuda constantemente en el consenso para no lograr nunca nada notorio. Además, las personas con baja autoestima no se sienten orgullosas de su trabajo y, por consiguiente, producen entregables chapuceros y de mala calidad que reflejan el mal concepto que tienen de si mismas.

Complejo de inferioridad/superioridad

Aunque los complejos de inferioridad/superioridad están relacionados con la autoestima y el narcisismo, los he separado arbitrariamente en esta catalogación para poner de relieve un tipo de comportamiento distinto de los anteriormente descritos. Se trata del comportamiento de las personas orientadas a demostrar alguna cosa. En principio, estas personas parecen motivadas por el logro, pero solo si el logro es visible externamente. En realidad su objetivo es demostrar que están por encima de los demás. Estas personas pueden conseguir muchas cosas porque para demostrar algo la mayoría de las veces hay que hacerlo realmente. Pero carecen de escrúpulos a la hora de atribuirse méritos que no les corresponden. Siempre son capaces de atribuir su falta de éxito a un factor externo o a la ausencia de oportunidades. Hablan del resto del equipo como si fuesen inferiores. Pueden comportarse de forma bastante agresiva en las relaciones. Y al final del día algunos sufren, y con razón, el Síndrome del Impostor. Por último, si fallan en su intento de obtener suficientes medallas, entonces se posicionan como autoridad moral superior cuestionando la ética de aquellos quienes les deniegan el reconocimiento que creen que se merecen.

Psicopatías

El psicópata es un personaje muy bien estudiado en psicología. Se caracteriza por su insensibilidad con los sentimientos de las personas y con las normas sociales. En contra de lo que ha difundido la cinematografía, no todos los psicópatas son intrínsecamente dañinos. Algunos tienen buenas intenciones, pero para ellos la vida es como un juego de ajedrez en el cual es perfectamente aceptable sacrificar peones para capturar una posición ventajosa, lo cual estaría bien de no ser porque sus peones son gente de verdad. Algunos psicópatas son parásitos especializados en manipular a los demás y aprovecharse de los frutos del trabajo de terceros, pero no todos los psicópatas son parasitarios, algunos son muy inteligentes y competentes. También pueden causar problemas debido a su tendencia a la promiscuidad, incluyendo relaciones con personas del entorno laboral. El tipo más peligroso es el psicópata-sádico que goza experimentando con las emociones de los demás como si fuesen ratas de laboratorio.

Ansiedad y stress

Los medicamentos con receta más consumidos en el mundo desarrollado son los ansiolíticos. Mucha gente tiene una gran imaginación que les traiciona haciéndoles imaginar toda clase de escenarios horribles resultado de cosas que fueron mal en el proyecto. El nivel de ansiedad es una función de las expectativas propias, los riesgos y las consecuencias indeseables imaginarias o reales. La ansiedad se desencadena normalmente cuando la persona cree que no podrán alcanzar sus objetivos, y, por consiguiente, sufrirá un castigo, o cuando ya ha hecho algo mal y teme ser descubierta y castigada por ello. En los proyectos, este stress se expresa en forma de reacciones abruptas, correos con copia a toda la cadena de mando hasta el CEO, procastinación a la hora de abordar determinados temas y a la postre problemas físicos como migrañas, insomnio o infartos.

Trastorno obsesivo

Suele aparecer en forma del hombre-metodología que vive obsesionado con los procedimientos y enloquece cuando alguien se los salta. Desarrollar software en equipo requiere un elevado grado de disciplina grupal. Y a la gente le gusta la sensación de orden. Aunque incluso las cosas buenas en exceso son malas. Un exceso de orden puede frenar la creatividad y retrasar el proyecto con montones de tareas burocráticas que poco o ningún valor añaden al producto.

Histeria

Los psicólogos ya no reconocen hoy en día la histeria como una patología. Se considera un concepto del siglo XIX con origen en la represión sexual de la época. No obstante, todos hemos trabajado alguna vez con esa persona que te manda un email y te llama para preguntarte si lo has leído según lo ves aparecer en tu Bandeja de Entrada. Y luego te llama otra vez cada 15 minutos para preguntarte si has hecho lo que te pide. Y el resto del tiempo esta de un humor de perros.

Paranoia

La paranoia (gerencial) consiste en la creencia de que el entorno es permanentemente peligroso. El caso es que en muchas ocasiones en efecto lo es y es por eso que multitud de jefes son paranoicos. La paranoia se manifiesta en los mandos intermedios que nunca aprueban ninguna iniciativa sin estar completamente seguros de que tendrá el respaldo de su superior. Nunca envían un email ni responden a ellos. El proyecto parece pertenecer a la era soviética: nadie intercambia información con nadie y los empleados se espían unos a otros.

Adicciones

En este grupo los más habituales son el cocainómano y el alcohólico, que con frecuencia combinan el abuso de ambas substancias. Se les reconoce usualmente por horas con picos de actividad febril seguidas de otras en las que parece que sufran narcolepsia. Una persona que escribe código bajo los efectos alguna substancia es muy peligrosa porque gran parte del trabajo en software no es visible externamente y, por consiguiente, se puede tardar bastante tiempo en descubrir que su trabajo es como los renglones torcidos de Dios. El caso más legendario de los que yo he vivido en primera persona fue el de uno que se bebió una botella de licor antes de aplicar unas políticas de seguridad en un servidor de producción con el resultado de que cuando terminó ni él mismo podía conectarse como root a la máquina.

Asperger

Dicen que muchos nerds padecen Asperger, que ahora mismo ya no se considera una patología en si misma sino que se engloba en el espectro de trastornos autistas. Algunos programadores que he conocido ciertamente tienen dificultades para leer las emociones de los demás. Y es necesario relacionarse con ellos en unos términos muy concretos que ellos fijan a priori. Jefes con Asperger nunca he conseguido identificar personalmente ninguno.

Otros

El catálogo de trastornos psicológicos es, por supuesto, muchísimo más extenso que los descritos anteriormente. Hay casos de depresión, personalidad bipolar, esquizofrenia, etc. suficientemente severos como para dejar a una persona inoperante a efectos laborales.

Remedios sintomáticos

La mala noticia respecto del elenco anterior es que resulta bastante complicado hacer nada al respecto. Puede que el CEO se comporte como un niño pequeño, pero no se le pueden poner límites como a los niños pequeños. En los procesos de reclutamiento no se tiene en cuenta la personalidad del candidato. Pocos jefes podrían decir cuál es el signo zodiacal de sus subordinados así que mucho menos tener en cuenta la historia de su infancia para predecir cómo se comportaran. La psicología organizacional básicamente lo que hizo fue trasladar el problema a los empleados poniendo de moda la Inteligencia Emocional, que básicamente establece que es responsabilidad exclusiva del empleado mantener relaciones mentalmente sanas y políticamente correctas con los otros empleados. Y, bueno, lo estimulante de intentar algo es que, hagas lo que hagas, siempre descubrirás un puñado de gente detrás de ti con una sonrisa y un puñal escondido en la espalda esperando a ver dónde te la pegas.

Los remedios factibles suelen ser pues sólo sintomáticos :

• Ponerle al CEO una secretaria ejecutiva que le organice bien la agenda y le mantenga centrado.
• Informar a los recién llegados de que la veteranía es un rango.
• Animar a los jefes más débiles a confiar en sus propias capacidades y asumir riesgos.
• Dar visibilidad a todos los miembros del equipo para que ninguno quede eclipsado.
• Recomendar a las personas que antepongan sus victorias privadas a las victorias públicas.
• Permitir horarios razonables compatibles con la vida personal.
• Permitir e incluso premiar un grado razonable de fracaso e incumplimiento de objetivos, pues si siempre se cumplen todos los objetivos entonces es que el equipo está trabajando por debajo de su verdadero potencial.
• Aplicar el máximo grado posible de transparencia informativa.
• Si el presupuesto lo permite, facilitar un coach a los empleados que puedan necesitarlo, o si no hay presupuesto, recomendarles que ellos mismos busquen uno si n están alcanzando resultados al nivel de sus expectativas o se sienten descontentos con la dinámica diaria en el trabajo.

Post relacionados:
Tipos de presidentes ejecutivos
El mando intermedio
El juego competitivo de suma cero de los mandos intermedios

Publicado en Entorno laboral | 1 comentario

Técnicas de venta por dominio del cliente en software y consultoría

Publicado el 20 de febrero de 2017 por Sergio Montoro

En el mercado informático se conoce comunmente como venta por dominio del cliente al conjunto de prácticas destinadas a imponer unilateralmente a los clientes las condiciones de compra. Los casos más flagrantes, que suelen darse por parte de monopolios u oligopolios, están explícitamente prohibidos por la ley, así como otras prácticas abusivas como los pactos de precios entre proveedores o apalancar la venta de un producto en otro que el cliente necesita comprar. Comentaré, por consiguiente, las tácticas más sutiles, que sí están permitidas por la ley, sobre todo en software B2B, que es lo que conozco. El recíproco, las prácticas abusivas con los proveedores de tecnología, también se da y le dedicaré una sección adicional.

El origen de una posición dominante

Un proveedor alcanza una posición dominante respecto del cliente básicamente por dos motivos: bien por una imperfección de mercado que el proveedor es capaz de explotar, bien por una habilidad especial del proveedor para colocar al cliente en una posición de dependencia.

Las imperfecciones de mercado se basan en controlar el acceso a un recurso escaso. En software esos recursos escasos son cinco:

1. la ventana de atención de los clientes
2. la tecnología o propiedad intelectual
3. la mano de obra de programadores cualificados
4. los canales de distribución
5. la confianza

Quienquiera que controle uno o más de estos recursos está en una posición ventajosa para exigirle más dinero al cliente a cambio de lo que quiere.

La evolución del equilibrio de poder cliente vs. proveedor en desarrollo de software

Durante el siglo XX la venta por dominio en el mercado del software se basó principalmente en el control de la tecnología, la propiedad intelectual y los canales de distribución. La necesidad de soluciones técnicas superaba a la oferta y los clientes no tenían muchas opciones de proveedores. Los clientes de mayor poder adquisitivo usaban analistas como Gartner, Ovum o Metagroup para asesorarse sobre productos. La mano de obra se obtenía incorporándola directamente en nómina según iba saliendo en cuentagotas de las universidades. Microsoft dominaba de forma absoluta el canal OEM de software pre-instalado en los PCs. Y entre Oracle, IBM y HP se repartían lo mejor del mercado de soluciones empresariales.

Tras el fin de la primera burbuja de Internet hacia 2004 la situación empezó a cambiar. Aparecieron los microprocesadores de 64bits, se abarató drásticamente la memoria y el espacio en disco. El Software Libre traspasó mucho poder de manos de los fabricantes a manos de los clientes e intermediarios. Aparecieron empresas de integración de sistemas como setas. Los vendedores de productos de infraestructura se encontraron compitiendo contra virus estilo MySQL. El mercado de trabajo se inundó de personas procedentes de otras ramas profesionales que se reciclaron atraídas por los buenos sueldos. Se globalizó la oferta y la demanda gracias a la computación en la nube. Y proliferaron los dispositivos conectados a Internet sobre diferentes sistemas operativos y tecnologías.

Las tácticas para mantener una posición dominante

Para mantener su cuenta de resultados, los proveedores tuvieron que reaccionar ante estos cambios de mercado. Era muy difícil prevenir que los técnicos se descargasen software de SourceForge, lo probasen y luego sugirieran a sus jefes cambiar lo que tenían por esa maravilla gratuita que se habían descargado. Entonces lo que había que hacer era mantener el control sobre los mandos intermedios y superiores que toman las decisiones. Esto se intentó en primer lugar mediante el FUD (Fear Unceirtainity and Doubt). Tratando de sembrar sistemáticamente la duda y la desconfianza hacia cualquier nueva tecnología o modelo de negocio disruptivo como el Software Libre. Cuando el FUD se volvió ineficaz, los grandes proveedores empezaron a abrazar el Software Libre. Donaron dinero y proyectos a la Fundación Apache, patrocinaron ferias y, en general, se subieron al carro del Open Source.

En paralelo, se inició una carrera por el control de los clientes. Los comerciales, acostumbrados a que les comprasen más que a vender, tuvieron que cambiar de mentalidad, y desde la dirección comercial se diseñó una nueva estrategia que ya no se basaba tanto en la posesión de propiedad intelectual única sino en el control de acceso a las cuentas. Lo primero que se hizo fue persuadir a los ejecutivos de que la informática era un área estratégica (nunca he visto a un consultor vender nada que no sea «estratégico»). Se les infundió el convencimiento de que debían acometer proyectos de transformación estratégica, y, además, que no podían confiar en los mismos fabricantes de software que habían abusado de ellos en el pasado. En ese momento se produjo un punto de inflexión en el cual el poder sobre el cliente pasó de los fabricantes de software a las grandes consultoras. Estas se especializaron no sólo cómo expertas en tecnología sino también como referentes de conocimiento de negocio en el sector de actividad del cliente. Debido al “efecto Lemming”, los clientes empezaron a subcontratar la consultoría estratégica a las mismas consultoras estratégicas que sus competidores, y, por consiguiente, acabaron teniendo todos la misma estrategia, lo cual les conducía a descuartizarse entre ellos en competencia directa. Las consultoras técnicas y de negocio (a veces las mismas que las estratégicas) persuadieron a los clientes de que los fabricantes de software y los integradores no eran de fiar y que las consultoras de negocio eran las más indicadas para erigirse en valedoras de los intereses del cliente. Cuando empezó este proceso los clientes tenían (y siguen teniendo) problemas con la gestión de los proyectos informáticos. De modo que compraron la idea de las metodologías Agile basadas en crear eficiencias a base de apretar a los proveedores. Y todo esto habría estado muy bien (para el cliente) de no ser porque todo lo que se ahorraba en gastos a proveedores se gastaba en pagos al gestor del proyecto quien acababa obteniendo el mejor márgen a base de ocultar al cliente lo que realmente estaba comprando y su precio en el mercado. Esto funcionó (y sigue funcionando) de maravilla para las grandes consultoras. Con el paso del tiempo, las consultoras refinaron las técnicas para extender sus tentáculos; enviando hordas de jóvenes licenciados que se recolocaban de la consultora en el cliente y, por tanto, eran afines a comprar productos de su anterior empleador. Con montones de fines de semana pagados, viajes, y todo tipo de incentivos para mantener cautiva la atención del cliente debido a que, de forma razonable, un cliente sólo puede evaluar entre tres y cinco ofertas para cada proyecto. Entonces lo fundamental es estar en la short-list y cuando la esa short-list es entre tres y cinco, cada aspirante tiene entre un 20% y un 30% de probabilidades de ganar el proyecto, lo cual no está nada mal.

La respuesta de los fabricantes de software fue apostar por plataformas para tratar de adueñarse de toda la informática del cliente. IBM tuvo una oportunidad fantástica tras comprar Lotus, pero acabó perdiendo la ofimática frente a Microsoft, quien tampoco consiguió conquistar el mercado de software y servidores empresariales que ahora mismo se reparte entre IBM, Oracle, HP, SAP, Microsoft y todo el ecosistema Linux. Google ha tratado de crear el API de tu vida para estar en todas las aplicaciones web y en el caso de Apple la estrategia se basa en el control férreo del canal de distribución a través de App Store.

Respecto del control de la mano de obra, lo único que puedo decir es que actualmente es un sin Dios. Las “cárnicas” (consultoras con un modelo de negocio basado en trabajadores indiferenciados a quienes pagan lo mínimo posible) pueden proporcionar masa laboral para proyectos que la requieren en abundancia, pero todo el mundo anda como loco intentando captar y retener a profesionales de alta cualificación. Las «cárnicas» típicamente viven de los «acuerdos marco» mediante los cuales el cliente expresa su intención de comprar un determinado volumen de recursos a cambio de un fuerte descuento, aunque, como veremos un poco más adelante, esto también puede ser muy peligroso para el proveedor.

Resumidamente, los diez pilares de la venta por dominio descrita son:

1. Buscar clientes que tengan dinero y estén asustados por perder un mercado.
2. Acaparar la atención de quienes toman las decisiones de compra.
3. Colocar a personas en puestos clave en los clientes.
4. Adquirir capacidad de despliegue de recursos mediante una amplia red de subcontratistas.
5. Infundir miedo e incertidumbre sobre otras opciones.
6. Autoproclamarse cómo el experto en un determinado sector.
7. Vender la idea de que una buena externalización de la gestión creará eficiencias económicas en el proyecto.
8. Negociar acuerdos que apalanquen la posición del proveedor en el cliente.
9. Mantener al cliente en la oscuridad sobre la cadena de suministro.
10. Instalar plataformas de las que el cliente no pueda deshacerse fácilmente.

Las tácticas de los clientes para zafarse del dominio de los proveedores de informática

Naturalmente, los clientes no son tontos y no se dejan atrapar fácilmente. La defensa más común en los clientes es ocupar una posición central entre los proveedores mediante una estrategia de divide y vencerás. Esta consiste en enfrentar a los proveedores entre ellos y amenazarles constantemente con cambiar de uno a otro si no ofertan mejores condiciones.

Otra barrera defensiva de los clientes son los acuerdos marco, estos pueden ser una peligrosísima trampa para los proveedores. Cuando se anuncian, parecen a priori una buena noticia para el proveedor: ¡el cliente quiere comprometerse a comprar más durante un tiempo! Excepto porque un acuerdo marco bien redactado no compromete al cliente a nada. Normalmente, el proveedor debe aceptar proveer una determinada cantidad de productos y servicios a un precio máximo. El proveedor se compromete a que: a) tendrá estos recursos y b) los proporcionará al precio pactado. Pero el cliente no se compromete a comprarlos. El cliente tampoco se compromete a aceptar el precio sin intentar renegociarlo a la baja. Y el plazo de preaviso para la cancelación absoluta unilateralmente por parte del cliente (que no de el proveedor) suele ser de un mes. En la dinámica típica el cliente le va pidiendo más recursos al proveedor mientras los necesita. Es más, amenaza al proveedor con cancelar el acuerdo si no provee los recursos. El proveedor se va cargando paulatinamente de mano de obra que no puede recolocar en ninguna otra parte. Y el día que el cliente ya no necesita más los recursos, o se queda sin dinero para pagarlos, pues el proveedor se los come simplemente con patatas. Las técnicas para afinar esta táctica pueden llegar a ser sorprendentemente sofisticadas. Por ejemplo, alargar los plazos de pago al proveedor y luego ofrecerle un descuento de pagarés pero sólo si el proveedor aporta «por seguridad» una copia de su contabilidad y sus últimas declaraciones de impuestos mediante las cuales el cliente averigua cual es el margen bruto del proveedor, información que puede usar para renegociar los precios cuando quiera.

La negociación de los acuerdos marcos puede llegar a ser durísima y desgastar mucho la relación cliente/proveedor y es por eso que suelen llevarla a cabo los departamentos de compras del cliente y no los departamentos a los cuales van destinados los entregables. El cliente pretende reducir precios, alargar los plazos de plazos de pago, poder cambiar los recursos cuando quiera, no comprometerse más allá de un mes en nada y penalizar al proveedor por cualquier incumplimiento. El proveedor pretende exactamente lo contrario. Además es un juego de suma cero que ofrece pocas opciones alternativas a la negociación encarnizada con miras en el corto plazo.

Adicionalmente, si consigue saber quienes son, el cliente puede tratar de desintermediar la relación con los subcontratistas. O aprender a gestionar él mismo sus propios proyectos.

Por último, si el cliente es un grupo de empresas, puede usar la capacidad de compra combinada del grupo para regatear con el proveedor quizá diciéndole, por ejemplo, que no firmará un nuevo contrato de compra en Argentina si no obtiene un descuento en su contrato actual en España.

La situación de equilibrio

Esta dinámica entre clientes y proveedores suele llegar a la siguiente situación del equilibrio: en el cliente se asienta un puñado de proveedores que «coopiten» entre ellos. Las grandes consultoras controlan el acceso a la línea ejecutiva del cliente pero su posición es inestable con frecuente rotación de personal destacado en la cuenta. A veces las grandes consultoras colocan también a alguno de sus «brazos cárnicos» pero normalmente la ejecución corre a cargo de empresas especialistas en desarrollo, diseño gráfico, sistemas, seguridad, etc. Las empresas pequeñas no suelen tener capacidad para agredir a otras empresas pequeñas ni tampoco para conquistar la dirección estratégica del proyecto. Y las empresas grandes no tienen tanta capacidad operativa como pretenden sino que dependen de las subcontratas. El cliente puede amenazar con cancelar los contratos, pero cambiar de proveedor también tiene un coste, no sólo económico, sino también de imagen, porque para los empleados de un cliente es muy inconveniente reconocer que se equivocaron de proveedor y es necesario cambiarlo.

En el punto de equilibrio, el cliente no gana nada cambiando de proveedor, ni tampoco aumentando su número. Y los proveedores carecen de capacidad para conquistar la quota de sus competidores dentro del cliente. La cual tampoco es una situación inamovible, pues, como han demostrado sistemáticamente Oracle e IBM, los proveedores pueden comprarse (fagocitarse) unos a otros para reducir la competencia.

Post relacionados:
Efectos laterales: ¿qué compran los clientes realmente?.
El ciclo de vida del cliente B2B.
La importancia de no pifiarla nunca.
Tácticas de venta guerrillera en tecnología.
La guerra de maniobra del Software Libre frente al Privativo.

Publicado en Mercado y Oportunidades de Negocio, Modelos de Negocio | 1 comentario

5 cosas que pueden arruinarte el día en un proyecto (y cómo evitarlas)

Publicado el 12 de febrero de 2017 por Sergio Montoro

Hace unas semanas me encontraba en medio de un brote de optimismo. Muy contento con los resultados, había invitado a nuestro equipo y a los empleados del cliente a una barra libre de tapas. Entre plato y plato, el jefe de producto me dijo: “Vosotros los consultores externos siempre veis el vaso medio lleno. Porque estais acostumbrados a que os lancen en paracaídas sólo en proyectos que van mal o necesitan desesperadamente recursos. Entonces pensais: ‘Bueno, en peores plazas he toreado’. Pero a los que llevamos quince años aquí nos gustaría que todo fuese perfecto y ese deseo hace que la percepción sea la de vivir permanentemente dentro de un túnel sin salida”.

En esta ocasión, lo que nos traíamos entre manos salió bien, pero el software es una artesanía muy compleja cuyos proyectos nunca están exentos de incidentes descorazonadores. Para comentar cómo enfrentarse a lo que típicamente resulta frustrante en un projecto de desarrollo de software, voy a basarme en un artículo de 2004 escrito por Michael «Rands» Lopp titulado Qué hacer cuando estás jodido. Del cual daré, naturalmente, mi propia interpretación.

Causa #1: falta documentación importante

Al inicio de un proyecto todo el mundo anda preocupado por definir bien qué es lo que hay que hacer. Esto es importante porque las especificaciones se usan para hacer las estimaciones de tiempo y las estimaciones de tiempo se usan para hacer los presupuestos. Además de que a los programadores no les gusta tener que rehacer en el último minuto cosas que ya habían hecho presuntamente de acuerdo con los requisitos.

Lo que sucede es que al principio del proyecto hay muchas incógnitas que no se pueden despejar. La solución para este problema propuesta por Agile fue, básicamente, negar que existe y aceptar una dinámica de cambios contínuos en el proyecto. Ya he sido bastante crítico con Agile en el pasado debido en parte a esta premisa de negar la mayor porque opino que ninguna metodología ágil puede salvar a un proyecto de unas malas especificaciones puesto que si empiezas sin saber lo que hay que hacer es seguro que tendrás que repetirlo y tener que hacer las cosas dos (o más veces) es malo.

Estoy de acuerdo en que no es necesario que todo esté escrito en piedra antes de empezar. Pero sí es necesario que esté escrito al terminar. Es decir, lo importante sobre la documentación no es tanto su calidad cuando empieza el proyecto sino su calidad cuando termina. Mas lo que suele suceder es que durante el proceso de desarrollo se introducen tantos cambios que la especificación de requisitos original deja de ser en absoluto una imagen fiel de lo que realmente se ha producido.

El problema tiene a menudo bastante que ver con las herramientas, o mejor dicho la falta de ellas, para elaborar especificaciones. Frecuentemente vienen escritas en Word y PowerPoint. Con suerte, almacenadas en un repositorio SharePoint. Pero no pocas veces simplemente en un directorio compartido.

La pega de Word y PowerPoint es que lo aguantan todo, incluída la indisciplina más absoluta para mantener actualizados los documentos. Durante los proyectos ágiles es frecuente que los usuarios pidan cambios mediante un ticket de soporte o simplemente mandando «un correito». Esto es fácil para el usuario porque le ahorra el esfuerzo mental de buscar y actualizar la especificación. Pero a la postre el comportamiento del software acaba especificado en mensajes almacenados en Outlook.

La dispersión de las especificaciones en emails es terriblemente mala, porque a la hora de facturar un proyecto hay tres tipos de entregables: 1) los entregables que estaban en la especificación y se entregaron tal cual figura en los documentos, 2) los entregables que estaban en la especificación original y no se entregaron porque a posteriori se descubrió que no tenía sentido fabricarlos y 3) los entregables que no estaban en la especificación original y se entregaron porque hubo peticiones de cambio. Si, como propone Agile, sólo se factura al cliente por horas/hombre (time & materials) entonces da igual lo que se produzca porque el cliente sólo paga por horas de programador y no por entregables. Pero los clientes se queman de pagar horas sin fin. Y a la postre lo que estaba en la especifición y se entregó, se paga; lo que estaba en la especifición y no se entregó, no se paga; y todo lo que hubo que hacer porque se descubrió por el camino el cliente discute si tiene que pagarlo o no.

Causa #2: falta (o sobra) alguna herramienta

Hemos progresado muchísimo en los últimos 20 años con respecto a la automatización del desarrollo de software. Los programadores son muy buenos automatizando y optimizando procesos. La pega es que los programadores sólo pueden optimizar aquello que forma parte de sus competencias, es decir, el proceso de desarrollo en sí mismo, pero en un proyecto el tiempo de desarrollo casi nunca supera el 30% del tiempo total requerido. Por ejemplo, existen fantásticas herramientas para el diseño de pruebas unitarias, estilo JUnit para las librerías o Selenium para el front-end. Pero la validación de los escenarios de uso sigue siendo mayormente un proceso manual. Entonces sucede que se necesita más tiempo para probar el software que para desarrollarlo.

En ocasiones el problema es el contrario. Alguien compró un cacharro que teóricamente es buenísimo para incrementar la productividad pero que en la práctica sólo es buenísimo para quitarle las ganas de vivir a quienes tienen que usarlo a diario.

Causa #3: mala gestión o ausencia de gestión

Tras lustros en contacto con centenares de organizaciones, intento hacer memoria de aquellas en las que los técnicos estuviesen satisfechos con la forma en la que se estaba gestionando el proyecto, y no se me ocurre ninguna. He conocido empresas donde los programadores junior admiraban los conocimientos de sus compañeros senior, los senior las capacidades naturales de los junior y ambos seguían fanáticamente a algún líder visionario. Pero jamás ninguno de ellos estaba contento con la forma de gestionar el proyecto. La razón es un conflicto de intereses entre los objetivos de los programadores, normalmente orientados a divertirse y alcanzar logros técnicos, y los objetivos de los responsables de negocio cuya misión encomendada es generar la máxima cantidad de dinero con el mínimo de esfuerzo e inversión. No existe ninguna solución a este conflicto. Es por eso que gurus como Richard Stallman recomiendan buscar un trabajo digno y programar sólo durante los ratos libres.

Este desencuentro inevitable entre programadores y accionstas/propietarios puede verse agravado por la incompetencia, ambición, miedo o cualquier neurosis de los gerentes hasta dar lugar al auténtico Jefe Minglanillas.

Tal y cómo está el mercado laboral de informática ahora mismo, yo creo que es innecesario aguantar a un mal jefe, ya que suele ser fácil encontrar otro trabajo. No obstante, también es injusto tener que renunciar a un trabajo cuando quien debería dimitir es el de arriba.

Como ya he apuntado, las dos causas más comunes de trastornos gerenciales son la ambición y el miedo. La ambición de trepar en la carrera profesional y el miedo a fracasar en ella, perder las stock-options enfrentarse a una demanda de divorcio y toda la serie de terrores nocturnos imaginarios que sufren algunos gerentes cuando se empiezan a incumplir los objetivos.

Por detrás de la ambición y el miedo, lo más común son los trastornos histéricos u obsesivos. La histeria la manifiestan las personas que están todo el tiempo acosando a los programadores. Los obsesivos son aquellos que enloquecen en el mismo momento en que alguien se salta algún procedimiento por absurdo que sea. Los histéricos y los obsesivos cumplen funciones en el proyecto generando tensión creativa y vigilando que se cumplan las normas, por ejemplo, en materia de la necesaria seguridad y confidencialidad. Lo que pasa es que los programadores son generalmente gente tranquila que no se adapta bien a trabajar bajo presión. Sí, ya sé que con esta última frase probablemente he indignado instantáneamente algún programador cuya mente ahora mismo está gritando «¿Que no tenemos presión en el proyecto!». Pues si existe presión, pero la presión que sufre diariamente un informático típico es muy inferior a la media de presión en otros trabajos excepto quizá ser poeta o catador de vinos.

En algunos casos el jefe directamente no existe. Esto no es necesariamente mortal, ya que históricamente soldados sin general ganaron muchas batallas (generales sin soldados ninguna) y a fin de cuentas se supone que los equipos ágiles son auto-organizados. Cuando no hay jefe, los problemas aparecen si se necesitan recursos ajenos al equipo o si se producen disputas entre los miembros. En estos casos, lo mejor suele ser que el propio equipo elija un líder que actúe como interlocutor y árbitro.

Causa #4: el clima laboral apesta

Esto puede ser consecuencia de una mala gestión, pero no siempre. Una empresa, cualquier empresa, por bien gestionada que esté, puede entrar en crisis por razones externas.

La crisis afecta al estado de ánimo de los trabajadores y ello causa que el día a día de la dinámica social se vuelva muy desagradable.

He de decir que en no pocas ocasiones he visto a los departamentos de recursos humanos desayudar con el clima. No es raro que los programadores se burlen de las evaluaciones de rendimiento. Y el propio mobiliario y disposición de los puestos de trabajo en las modernas oficinas abiertas es totalmente deshumanizante. Dicen que en algunas start ups y en algunas empresas de Área de la Bahía el entorno no es tan gris. Ciertamente yo he conocido varias start up ubicadas en lofts muy bien decorados. No tengo suficiente vivencia como para opinar en general sobre Silicon Valley, pero mi visita al Campus de Google en 2009 fue decepcionante.

Observando lugares de trabajo, he conseguido reducir a cuatro los factores predictivos de la preocupación de la empresa por sus empleados:

El estado de conservación de la sillas
El tamaño y calidad de la cocina/comedor
El tamaño y calidad de los lavabos
La disponibilidad de agua y café

Si encuentro en una planta sillas destartaladas que los empleados van robándose unos a otros ya sé que nadie se preocupa demasiado por los factores higiénicos del trabajo. También he visitado empresas boyantes en rascacielos londinenses cuyos lavabos eran peores que las letrinas del ejército.

Creo que lo mejor en estos casos es una correcta acción sindical. No se trata de pedir que pongan mesas de billar ni máquinas de pin-ball, sino de pedir un entorno idóneo y agradable para las largas horas que hay que pasar en la oficina.

Otra causa de mal clima laboral, es la precariedad en la contratación. Sueldos bajos, temporalidad innecesaria, abuso de consultores mercenarios (o todo lo contrario, ausencia absoluta de ellos).

Causa #5: los plazos previstos no se están cumpliendo

Esto puede no ser tan malo como suele parecer a primera vista. Para empezar, en un proyecto informático la cantidad de trabajo terminado aumenta exponencialmente conforme se acerca la fecha de entrega. Es decir, es posible estar en la mitad del plazo y haber completado sólo el 20% del proyecto y, aún así, lograrlo.

Los proyectos suelen retrasarse por cambios e imprevistos, los gestores experimentados lo saben y por eso idean todo tipo de trucos para que las fechas de entrega se puedan deslizar sin que parezca que hubo un retraso. Por ejemplo, contra las avalanchas de cambios al final del proyecto es posible crear dos fechas de entrega: la fecha oficial de puesta en producción y otra misteriosa fecha “post-go-live” que es cuando realmente estará operativo el sistema. Si el proyecto va retrasado lo que se hace es un triaje de cambios solicitados y funcionalidades pendientes. Pongamos por caso que se dividen en prioridades P1, P2, P3 y P4. Entonces los P1 y P2 entran en la fecha de puesta en producción y los P3 y P4 son post-go-live. Es decir, puede que no sea posible mover la fecha de entrega pero casi siempre es posible reducir el número de funcionalidades o la calidad del software entregado.

Lo importante es que no haya sorpresas. En las start ups y en las empresas o proyectos que dependen de rondas de inversión los plazos pueden ser cruciales y muy ajustados. Pero normalmente en las empresas medianas y grandes importa muchísimo más la predictibilidad que la eficiencia.

Posts relacionados:
Cómo sobrevivir a las estimaciones de software.
Lo que sucede cuando un software se convierte en un agujero negro.
1-2-3 de por qué fallan los proyectos informáticos (Versión Cerø).

Publicado en Casos Prácticos, Entorno laboral, Organizando la Comunidad. Modelos de Desarrollo | 1 comentario

AdTech: seguimiento online y publicidad basada en el comportamiento

Publicado el 4 de febrero de 2017 por Sergio Montoro

Online Spying Supongo que a estas alturas, todos sabemos, o como mínimo sospechamos, que los anunciantes saben quiénes somos, dónde vivimos, si tendremos un hijo en los próximos tres meses, dónde nos fuimos de vacaciones el mes pasado, qué marca de ropa interior usamos o si estamos teniendo problemas de salud. En este artículo repaso lo que se sabe acerca de cómo averiguan todo esto y qué se puede hacer para limitar la información que se proporciona a empresas interesadas en saber acerca de nosotros, ya sean proveedores de productos de consumo, bancos, aseguradoras o agencias del gobierno.

Debido a su desconocimiento de los entresijos, los usuarios están en desventaja respecto de los anunciantes. Por cuestiones de conveniencia para los anunciantes y debido a su lobby, la protección normativa frente a los daños que puede causar el uso abusivo de datos ha sido reemplazada por un «consentimiento informado», excepto que no es posible tal cosa como que el usuario entienda bien a qué está dando su consentimiento cuando cede sus datos a una de las empresas voraces de información comercial.

Quería escribir sobre las técnicas estadísticas que usan los anunciantes, pero haciéndolo me di cuenta de que no se pueden entender sin conocer cómo se recopilan los datos en que se basan. De modo que me ha quedado un prólogo bastante largo para un texto estructurado en 3 partes:

1ª) Cómo se identifica y se sigue a los consumidores online y offline.
2ª) Qué se puede hacer para protegerse contra el seguimiento.
3ª) Los fundamentos estadísticos de la publicidad contextual.

Como es habitual en La Pastilla Roja, el texto va de lo menos técnico a lo más técnico para que cada cual pueda leer hasta donde quiera. Por cuestión de espacio, me he dejado en el tintero las herramientas para anunciantes que quizá sean el tema de una segunda parte de éste artículo.

1. Cómo se identifica y se sigue a los consumidores

En los primeros tiempos de la Web 1.0 lo que se usaba para recopilar estadísticas de uso eran los logs del servidor web. Los logs no requerían instrumertar las páginas web visitadas y no en vano Google compró Urchin en 2005 justo cuando Urchin acababa de lanzar su versión SaaS.

Hoy en día, no obstante, existen decenas de métodos diferentes mediante los cuales los anunciantes identifican, etiquetan y siguen a los internautas. Casi siempre estos métodos se usan de forma combinada para enriquecer la información disponible de cada persona.

Podemos enumerar entre los principales:

Cookies
Super Cookies
Identificadores de dispositivo móvil
Beacons
Audio Beacons
Almacenamiento local HTML 5
Geolocalización y redes WiFi
Fingerprinting
Metadatos JPEG
Adobe Flash, Applets Java y controles ActiveX
Plug-ins, toolbars y spyware
Etags
Información recopilada por Google
Whatsapp y Facebook
Telemetría de Windows 10
Inspección profunda de paquetes
Información obtenida fuera de Internet
Brechas de seguridad

Cookies

Las cookies son el medio más antiguo y todavía el más usado para seguir a los usuarios. Una cookie es ni más ni menos que un fichero de texto que un sitio web graba en el disco del ordenador del usuario. Las cookies, en principio, sirven a un propósito bienintencionado. El protocolo de comunicación HTTP que usan las páginas web es «sin estados». Esto significa que entre una petición y la siguiente el servidor no tiene, a priori, ninguna forma de saber si el ordenador y el usuario que realizaron la segunda petición son los mismos que realizaron la primera. El inconveniente de este comportamiento es que en muchas ocasiones hace falta mantener vinculadas un serie de peticiones, por ejemplo, para mantener vivo un carrito de la compra. El navegador web puede, entonces, ir guardando los artículos seleccionados en una cookie y enviarla al servidor para completar el proceso de compra. Las cookies ordinarias sólo son accesibles para el dominio que las creó. Es decir, si amazon.com crea una cookie entonces esa cookie sólo podrá ser leída por Amazon. Además, las cookies se envían de nuevo en cada petición HTTP.

Super Cookies

Un tipo de cookie prácticamente desconocida es la super cookie HSTS. Resulta que los navegadores web modernos tienen una funcionalidad llamada HTTP Strict Transport Security (HSTS). Esta funcionalidad sirve para indicar que un sitio web debe ser accedido sólo a través de HTTPS. El servidor puede redireccionar de HTTP a HTTPS. El problema es que si esto se hace en cada petición entonces hay que redireccionar cada vez que el cliente pide una nueva página al mismo servidor y esto es un proceso lento. Entonces lo que hace el servidor es indicarle al cliente que después de la primera, todas las peticiones que se sigan deberán ser por HTTPS aunque el cliente haya escrito http:// en la barra de direcciones. Para lograr esto, el servidor coloca una supercookie en el cliente que contiene un identificador único y que no se puede ver ni borrar desde el interfaz de usuario. El identificador único de HSTS puede entonces ser usado por el servidor para saber si está viendo al mismo cliente por segunda vez.

Identificadores de dispositivo móvil

Las apps de los móviles no soportan cookies, pero tienen un identificador único de dispositivo que se envía al servidor y pueden realizar almacenamiento local. Por ejemplo, iOS Identifiers for Advertisers (“IDFA”) o Android Advertising ID. Por consiguiente, la trazabilidad de los móviles es equivalente a la de los ordenadores y aún mayor como veremos más adelante.

Beacons

Los beacons o web-beacons son imágenes que se insertan en una página para hacer una llamada oculta a otra página que recaba estadísticas. Normalmente los beacons son invisibles para el usuario, pero pueden ser también imágenes visibles. Por ejemplo, el propietario de un sitio web puede poner un botón estilo [Ver en Amazon] el cual informará a Amazon de que un usuario ha visitado una determinada página. El sitio web de un tercero no puede leer las cookies de Amazon, y Amazon no puede leer las cookies de terceros. Pero un sitio web sí puede leer sus propias cookies y enviárselas a Amazon. Y cómo las cookies de Amazon siempre se envían a Amazon en cada petición, existe una forma sencilla de casar las cookies si ambas partes, el sitio web y Amazon, están de acuerdo.

Audio Beacons

Los audio beacons, también conocidos como ultrasonic‍ cross-device tracking‍ (uXDT‍) consisten en emitir ultrasonidos imperceptibles para el oído humano pero que sí son captados por otro dispositivo electrónico. Se usan principalmente para vincular dispositivos. A fecha de mayo de 2017 existen identificadas más de 200 aplicaciones para Android que usan ultrasonidos. Se pueden usar, por ejemplo para detectar cuando una persona entra en una tienda colocando un dispositivo emisor al cual el móvil del usuario responde mediante una app preinstalada.

Almacenamiento local HTML 5

A partir de HTML 5, las aplicaciones pueden hacer uso de un tipo de almacenamiento local atributo-valor, pensado para aplicaciones a las que les resulta conveniente almacenar una cantidad considerable de datos en el navegador web. El almacenamiento local se puede usar con los mismos fines de seguimiento que las cookies si el navegador cliente tiene JavaScript activado.

Geolocalización y Redes WiFi

Otra de las novedades de HTML 5 fue la geolocalización del navegador cliente. Esta requiere consentimiento del usuario, aunque se puede autorizar a un sitio permanentemente o autorizar a todos los sitios siempre. La geolocalización utiliza diversas técnicas: la dirección IP, la red WiFi, datos GPS (si es un dispositivo móvil). El navegador envía estos datos al proveedor de geolocalización (que por defecto suele ser Google Location Services) quien devuelve una ubicación estimada del dispositivo aunque sin garantía de que sea exacta.

Incluso sin la geolocalización activada, el sitio web visitado puede conocer dirección IP de la red WiFi utilizada. Por ejemplo, supongamos que en una casa se comparte un dispositivo para navegar por Internet. Entonces, en principio, no se puede saber quién lo está usando en cada momento. Pero si el dispositivo aparece cada mañana en un Starbucks y cada tarde en una estación de tren, y los contenidos visualizados en ambos casos son diferentes, entonces es posible inferir que uno de los miembros de la casa usa el dispositivo por las mañanas y el otro por la tarde. O también, si hay dos dispositivos que siempre aparecen juntos por pares en las mismas redes WiFi de una estación de tren o un aeropuerto entonces es casi seguro que ambos pertenecen al mismo usuario.

Información sobre el navegador (fingerprinting)

Una de las cosas que se envía en las cabeceras HTTP es información sobre el navegador web que está siendo utilizado por el usuario. Esta información es bastante detallada, incluye no sólo la marca y versión exacta, sino también la resolución de pantalla y los plug-ins instalados. Las diferencias en la configuración del navegador pueden usarse para caracterizar y distinguir usuarios. Algunos ejemplos de la información que puede obtener un sitio web de nuestro propio navegador pueden comprobarse visitando noc.to, panopticlick.eff.org, amiunique.org.

Además de la información sobre el navegador, se puede utilizar una técnica adicional conocida como canvas fingerprinting descrita públicamente por primera vez en el artículo The Web Never Forgets publicado en 2014 y que se basa en un exploit de HTML 5 y el uso que hace de la GPU.

En mi caso concreto, todos los sitios con demos de fingerprinting fueron capaces de identificar unívocamente mi navegador, principalmente debido a que uso una versión beta de Firefox, varios plug-ins poco comunes y, sorprendentemente, porque mi nivel de contramedidas para eludir la publicidad es inusualmente alto.
Es decir, la propia configuración diseñada para defenderme le acaba diciendo al anunciante quién soy, igual o acaso incluso mejor que una cookie.

Lo mejor para evitar el fingerprinting es usar Tor aunque deshabilitar la ejecución de JavaScript también priva a los sitios de la mayor parte de la información necesaria para identificar sin lugar a dudas a un navegador.

Información puesta por la cámara en las imágenes (metadatos JPEG)

Metadatos JPEG

Las imágenes JPEG tomadas con una cámara digital contienen una gran cantidad de información relativa a dónde y cuándo se tomó la fotografía y con qué dispositivo. Esta información se puede utilizar para obtener un fingerprint que identifica la huella de la cámara de forma similar a cómo se identifica la huella del navegador, pero como se puede apreciar en el ejemplo hay muchísimo más.

Flash, Applets Java y controles ActiveX

Los sitios web que usan Flash pueden mantener sus propias cookies y almacenamiento local diferentes de las cookies y el almacenamiento local HTML 5. Esta información puede limpiarse desde el administrador de Flash en el Panel de Control de Windows. También es posible indicarle a Flash que los sitios web no pueden guardar información en el navegador cliente.

Tanto Java como ActiveX en Internet Explorer son tecnologías que también pueden usarse para almacenar información de seguimiento. Aunque teóricamente los applets y los ActiveX pueden correr dentro de un sandbox de seguridad, en el pasado hubo tantos problemas con virus y programas malintencionados que se colaban a través de Java y ActiveX que los fabricantes de navegadores acabaron desactivando el soporte por defecto para Java y ActiveX.

Plug-ins, toolbars y spyware

La forma más extrema en la que un agente externo puede obtener información de un navegador cliente es mediante la instalación de una extensión en el navegador que espíe al usuario. En este caso el espionaje puede ir mucho más allá de los sitios visitados e incluir una inspección de todos los archivos que el usuario tenga en su disco duro.

Historial de navegación, búsquedas, archivos temporales, etags

En principio, el historial de navegación no está disponible para los sitios que se visitan. Pero esto es sólo asumiendo que no se haya instalado un plug-in espía que envíe esta información. El historial, por tanto, sólo es útil normalmente con fines forenses pero no con fines publicitarios. Todos los navegadores permiten limpiar el historial, al menos en teoría, porque en la práctica aunque parezca que se haya borrado por completo, todos los navegadores dejan trazas en el disco duro que son fastidiosamente difíciles de eliminar.

Los archivos temporales (cache) en principio tampoco es accesible por los sitios web visitados y no existen (o yo no conozco) casos en que se hayan usado para seguir a los usuarios. No obstante, como el historial, los archivos temporales no desaparecen por completo cuando el usuario los borra desde el navegador y, por consiguiente, si se tiene acceso a la máquina, son otra fuente de información forense acerca de la actividad del usuario.

Sin embargo, si existe una característica del cache de los navegadores que puede usarse para seguir a los usuarios: los Etags. Estos son una funcionalidad opcional del protocolo HTTP. El uso para el que fueron creados es mejorar la eficiencia de los caches. En la cabecera de la respuesta a cada petición HTTP el servidor puede incluir un etag. Se trata de un valor arbitrario calculado por el servidor que debe cambiar cuando cambia el recurso (la página web) solicitado. Antes de descargar nuevamente un recurso cacheado, el cliente envía su etag al servidor. Si el etag del cliente y el del servidor coinciden entonces el cliente puede suponer que su versión cacheada coincide con la última versión en el servidor y, por consiguiente, no es necesario descargar nuevamente el recurso. Entonces para trazar a un usuario lo único que necesita hacer el servidor es asignar el mismo etag a todas las páginas la primera vez que lo ve y luego devolver el mismo etag que recibe (u otro etag nuevo que el servidor pueda asociar con el anterior). Eludir los etags es casi imposible porque para ello habría que desactivar el cache de los navegadores, aunque es posible deshacerse de ellos periódicamente simplemente vaciando el cache. Su inevitabilidad ha causado que varias empresas que los usaban hayan sido objeto de sendas demandas civiles tras las cuales la legalidad de los etags está, como mínimo, severamente en entredicho.

Big G

Google guarda un historial con todas las búsquedas realizadas tanto en el buscador principal como en YouTube. Si se tiene activada la geolocalización, Google también guarda un historial de todos los sitios donde hayamos estado. Si no se ha indicado a Google que no guarde el historial de búsquedas y localizaciones, una visita a myactivity.google.com puede ser aterradora. Afortunadamente, es posible prohibir a Google a que se acuerde de nuestras búsquedas y ubicaciones o, al menos, que parezca que se ha olvidado de ellas, porque yo personalmente no estoy para nada seguro ni de que no las guarde ni de que las borre cuando se le indica que lo haga.

Ejemplo de historial de localizaciones en Google.

Además del buscador, Google cuenta con otras cuatro grandes bazas para el seguimiento: GMail, Google Analytics, Google Location Services, y su servidor de DNS 8.8.8.8

Con GMail porque legalmente pueden leerse los correos y ceder datos contenidos en ellos, si, en un documento legal de 2013 se establece que “a person has no legitimate expectation of privacy in information he voluntarily turns over to third parties”. Aunque muy recientemente la Unión Europea ha presentado una nueva iniciativa para prohibirle a Google que se lea los correos con fines publicitarios.

Con Google Analytics porque aunque el navegador cliente no le diga a Google quien es el visitante, el servidor donde está instalado Google Analytics sí lo hace cuando reconoce al visitante.

Con Google Location Services porque el navegador envía datos a Google cuando un sitio hace una petición de geolocalización.

Y con el servidor de DNS 8.8.8.8 (si se usa) porque el DNS puede acordarse de qué IP cliente le pidió que convirtiese la URL de un sitio en la dirección IP del sitio. Una forma de ver los DNS a través de los que estamos accediendo a Internet es consultar la página web www.dnsleaktest.com.

Whatsapp y Facebook

Un caso que merece atención especial es el de la interacción de Whatsapp con Facebook. En general, Whatsapp es considerado inseguro y muchas empresas prohíben expresamente su uso para comunicaciones de negocio.

Whatsapp empezó como una empresa bastante preocupada por la privacidad. Su modelo de negocio no se basaba en la publicidad sino en cobrar a los usuarios una pequeña cantidad anual y a otros incumbentes, como los bancos, por enviar el equivalente a un SMS al usuario. Eso fué así hasta que Facebook compró Whatsapp por 19.000 millones de dólares. Que se sepa, Whatsapp no analiza las conversaciones de los usuarios como hace GMail. Ni tampoco guarda un histórico. Como mucho, las almacena durante un máximo de 30 días si el destinatario no se encuentra disponible. No obstante, con el último cambio en la política de privacidad, se autorizaba a Whatsapp a compatir con Facebook todos los números de teléfono en el agenda del usuario. El número de teléfono es un dato muy relevante para los anunciantes porque permite asociar al internauta con un cliente que ya exista en la base de datos interna del comprador de la información. Otros usos son la sugerencia de amigos nuevos en Facebook basándose en los números de teléfono, lo cual podría inducir a sugerencias de personas que no deberían aparecer en la lista de amigos potenciales por cuestiones de privacidad.

Una forma de inspeccionar la información que Facebook está recabando sobre nosotros mientras lo utilizamos es instalar el plug-in Data Selfie para Chrome (cuyo código fuente está disponible en GitHub). Data Selfie envía de forma anónima los datos al servicio Apply Magic Sauce de IBM Watson el cual devuelve el perfil de personalidad del internauta inferido de sus datos de navegación.

Predicción de personalidad elaborada por Apply Magic Sauce

Telemetría de Windows 10

Desde que se lanzó la actualización gratuita (y casi forzosa) a Windows 10, Microsoft ha sido sospechosa de convertir a los usuarios en mercancia. Según se intuye leyendo la licencia de Windows 10, y Microsoft no lo ha desmentido, esta versión del S.O. puede enviar a Microsoft información sobre todas las páginas web visitadas por el usuario, y, además, no existe ninguna forma de impedirlo. Si se usa Windows 7 u 8 y se tiene instalado alguno de los parches KB3068708, KB3022345, KB3075249 o KB3080149 y se participa en el Programa de Mejora de la Experiencia de Usuario, entonces también se envía informacion de telemetría a Microsoft. En principio, toda esta información es anónima, es decir, Microsoft recolecta, por ejemplo, cuánto tiempo tardó una aplicación en abrirse y cuánto tiempo estuvo usándola, pero no mantiene vinculada esa información al usuario que la generó. Una opción para evitar que Windows envíe datos a Microsoft es instalar un firewall de terceros para cortar las comunicaciones entre el ordenador personal y Microsoft. En lo que se refiere a la privacidad, lo más peligroso de Windows 10 parece ser el asistente virtual Cortana, ya que el navegador Edge envía a Cortana la lista de todas las páginas visitadas, aunque esta funcionalidad sí se puede deshabilitar.

Inspección profunda de paquetes de los ISP

Un incumbente en una posición muy privilegiada para obtener datos de los usuarios sin que se enteren son los ISPs (Internet Service Providers). A fin de cuentas, todo el tráfico entrante y saliente de un usuario pasa necesariamente por su ISP quien puede usar técnicas de inspección profunda de paquetes. Si el tráfico está (bien) encriptado, el ISP no puede saber lo que contiene pero como mínimo puede inspeccionar todas las URLs solicitadas por el usuario. Dos compañías Phorm y NebuAd fueron especialmente notorias en el pasado por sus alianzas con ISPs para recabar datos mediante inspección profunda de paquetes pero debido a las advertencias de los reguladores legales tuvieron que cesar dicha actividad.

Información obtenida fuera de Internet

Por detrás de la información que se genera mientras el usuario navega por Internet, la segunda fuente de datos valiosos para los anunciantes es la información que proviene de las tarjetas de crédito y fidelización. En principio, está prohibido facilitar información a los bancos y aseguradoras que sirva para determinar nuestra calificación de riesgo y haya sido obtenida sin conocimiento y consentimiento del interesado. Pero los bancos y minoristas aún pueden obtener y manejar grandes cantidades de datos. American Express, en concreto, goza de una pequeña ventaja, ya que el usuario debe conectarse a la web de American para comprobar su saldo y puntos en lugar de consultar los extractos bancarios, lo cual da la oportunidad a American de colocar una cookie propia con la que seguir al usuario. La empresa Acxiom, por ejemplo, proporciona un servicio a las tiendas mediante el cual solo con el nombre que figura en la tarjeta de crédito y un código postal facilitado voluntariamente por el comprador, se puede obtener la dirección postal del propietario de la tarjeta de crédito sin necesidad de pedírsela directamente.

Las compañías como Equifax y Experian solicitan a los empleadores detalles salariales como parte del proceso de evaluación de riesgos de empleados.

También se recopila información de directorios y registros públicos, publicaciones estatales, encuestas, subastas, etc. En 2016 incluso se decretó una normativa europea que obliga a las compañías aéreas a ceder datos personales sobre sus pasajeros con fines de seguridad.

Por último, los dispositivos domóticos como el Alexa de Amazon pueden proporcionar una gran cantidad de información sobre los usuarios según ya explicábamos en otro artículo de 2016.

Información ligada a eventos

Los anunciantes saben que no solo es preciso llegar a la persona adecuada con el mensaje adecuado sino también hacerlo en el momento oportuno. Por ello se recopila también información que proporcione pistas acerca de los hábitos de las personas y de lo que harán en un futuro próximo. Por supuesto Google lo puede intuir desde siempre mirando el historial de búsquedas que almacena para cada usuario. Pero otras compañías como Equifax venden bases de datos de personas que serán padres en un futuro próximo incluyendo su calificación crediticia.

Brechas de seguridad

Un última fuente de datos muy valiosos para los anunciantes y los defraudadores son las brechas de seguridad. En 2013 en Yahoo! Se vieron comprometidas 1.000 millones de cuentas de correo y luego otros 500 millones de nuevo en 2014. De portal de contactos Ashley Madison fueron robados en 2015 25Gb incluyendo datos de 32 millones de usuarios que fueron hechos públicos. Y eso solo son dos ejemplos conocidos, pero es imposible saber cuántos robos ha habido que no hayan sido detectados ni denunciados.

Trackers

La información recogida mediante las técnicas anteriormente enumeradas es recopilada por los trackers que son pequeños fragmentos de código HTML y JavaScript que los sitios insertan en sus páginas web.
Existen muchísimos trackers, según un estudio de TRUSTe, hay cerca de
1.300 empresas monitorizando las 100 webs con mayor tráfico de Internet.
Wall Street Journal también publicó una tabla con la cantidad de trackers en las webs más populares que muestra que en una web típica hay varias decenas de trackers.
Los navegadores tienen una opción «Do not track» que indica a los sitios web que el usuario no quiere que le sigan online. Pero esta opción es mayormente inútil porque los sitios web no tienen obligación de respetarla, sino que lo hacen solo si quieren por respeto a las preferencias del usuario.

2. Qué se puede hacer para protegerse contra el seguimiento

En fácil intuir lo complicado que resulta protegerse contra el arsenal de técnicas de seguimiento descritas. Lo más eficaz es usar el navegador Tor, que incluye de serie medidas anti-fingerprinting, deshabilitar JavaScript y almacenamiento HTML 5 y prohibir todas las cookies. Esto provocará que dejen de funcionar casi todos los sitios web que habitualmente visitamos, incluídos los periódicos, la web del banco y cualquier pago online. Por consiguiente, no es una opción práctica.

Usando Firefox, podemos tomar las siguientes medidas, que son parecidas para Internet Explorer, Chrome y Safari.

1. Limpiar y deshabilitar las cookies. Excepto para los sitios de confianza. Firefox proporciona una lista blanca de sitios de los cuales se aceptan cookies.
2. Instalar el plug-in NoScript para impedir selectivamente la ejecución de JavaScript. En cada página autorizar solamente la ejecución de scripts que procedan del sitio visitado o, como mucho, de Fuentes externas de confianza como las Content Delivery Network (CDN) de algunas librerías JavaScript comunes.
3. Instalar el plug-in AdBlock o Ghostery para impedir las llamadas a web beacons. Con Ghostery hay que tener cuidado porque, a menos que se le indique lo contrario, la propia Ghostery recopila información estadística sobre los sitios bloqueados y se la vende a los anunciantes. Además, a mi Ghostery me ralentiza visiblemente el navegador y tiene tendencia poner la CPU al 100%, mal asunto cuando estoy de viaje y quiero ahorrar batería. Ghostery tampoco permite personalizar los filtros. De modo que yo recomendaría AdBlock. No confundir AdBlock con AdBlock Plus, ya que este último es sospechoso de cobrar a los anunciantes por incluirles en su lista blanca.
4. Instalar el plug-in Stop Fingerprinting para limitar la información útil para fingerprinting que se envía a los sitios visitados.
5. En las opciones de seguridad, deshabilitar Bloquear contenido peligroso y engañoso, ya que lo que hace esta opción es enviar las URLs visitadas a un servicio de Mozilla que califica si son potencialmente dañinas.
6. Desactivar la geolocalización. Para ello, en la barra de direcciones de Firefox introducir about:config buscar la clave geo.enabled y ponerla en false.
7. Usar el modo Private Browsing de Firefox (Incognito Mode en Google Chrome on InPrivate Browsing en Internet Explorer). En este modo las cookies no se guardan una vez cerrada la sesión y Además la sesión privada no se comunica con las otras sesiones, de modo que aunque se tenga una session abierta con Facebook o Gmail esta no podrá acceder a lo que se esté navegando en privado.
8. Limpiar períódicamente el cache del navegador y la lista de super cookies con CCleaner.
9. Deshabilitar el seguimiento de actividad de Google y nunca navegar con una sesion abierta en GMail o YouTube. Usar otro buscador como DuckDuckGo o PrivateLee.
10. Si se usa Windows 10, no crear una cuenta con Microsoft durante la instalación. O borrarla después de crearla. También deshabilitar Cortana. Instalar un firewall adicional como ZoneAlarm o TinyWall probablemente no merece la pena, pero es una opción para los usuarios más paranóicos y si el PC viene con software Norton o Kapersky, probablemente ya tiene instalado un firewall que se puede configurar. Existe también software de propósito específico como Destroy Windows 10 Spying que deshabilita el keylogger e impide el envío de datos a URLs de Microsoft.
11. Para ocultar la dirección IP propia lo mejor es usar un servicio de VPN como TUVPN.
12. Usar una cuenta de correo especial sólo para registrarse en los sitios web, desde la que no se envíe ni se reciba ningún mensaje. No vincular esta cuenta a ninguna información personal.

3. Técnicas de publicidad personalizada

En ingles al conjunto de técnicas utilizadas para mostrar anuncios basados en el historial de navegación de un usuario se lo conoce como online behavioural advertising (OBA) o behavioural targeting (BT). No he conseguido encontrar ninguna traducción al español que me guste entre «publicidad comportamental en línea», «publicidad conductual en línea», «publicidad en línea basada en el comportamiento», «publicidad selectiva basada en el comportamiento», etc. De modo que en lo sucesivo me voy a referir a ella simplemente como publicidad personalizada. Pues me parece más acertado aludir a su finalidad en lugar de a su método.

La publicidad personalizada hace uso tanto del perfil como de la actividad reciente del usuario. La publicidad de toda la vida ha hecho uso del perfil, ya que incluso en televisión se sabe aproximadamente qué porcentaje de televidentes serán hombres o mujeres, adultos o niños, etc. Para la mayoría de los productos de consumo masivo, afinar el perfil de la audiencia por encima de un determinado umbral no mejora espectacularmente los resultados ya que usualmente hay varios perfiles de comprador. Lo que sí mejora la eficacia es saber qué tiene en mente cada persona cuando está viendo un anuncio.

La finalidad de la publicidad personalizada es mejorar la tasa de conversión, es decir, el ratio entre usuarios que ven un anuncio y los que realmente acaban comprando el producto anunciado o, al menos, son influidos para tomar una decisión de compra posterior.

Podemos postular que la tasa de conversión estará relacionada con la relevancia. Esto es verificable empíricamente y de hecho está más que comprobado que la publicidad personalizada consigue ratios de conversión entre un 30% y un 300% superiores a la publicidad insensible al comportamiento del usuario. Entonces lo que se necesita para mejorar la eficacia de la publicidad es una buena métrica de relevancia.

En términos generales, habrá un conjunto de productos P₁, P₂, P₃ … P_n y un conjunto de usuarios U₁, U₂, U₃ … U_m caracterizados por una serie de atributos A₁, A₂, A₃ … A_k. La función de relevancia 𝒇: (P,U) → ℝ devolverá un valor real para cada par de producto y usuario. Y dado un usuario el problema consiste en encontrar el producto P que proporciona el valor máximo para esta función.

La forma de la función de relevancia es, en general, desconocida, aunque hablaremos más adelante sobre qué hace a un mensaje más o menos relevante para un receptor. Además puede haber atributos del usuario que son desconocidos. Por consiguiente, lo que se usa para casar usuarios con productos es inferencia estadística.

Segmentación

La segmentación es la técnica más utilizada para la clasificación de clientes potenciales. Prácticamente todos los proveedores de información comercial y plataformas de anuncios siguen vendiendo segmentos que son más o menos configurables por el comprador de la publicidad.

La segmentación no siempre se hace como la gente tiende a imaginar. Por ejemplo, podría suponerse que el segmento óptimo para unas zapatillas de correr son aquellos internautas que visiten con frecuencia páginas y noticias sobre maratones. Pero también es posible suponer que alguien que visita páginas sobre dietas está gordo y necesitará unas zapatillas para adelgazar corriendo. Personalmente, creo que el uso más infame que he visto de estas hipótesis negativas es la publicidad de pruebas de embarazo dirigida a adolescentes accidentalmente embarazadas.

Los segmentos se forman tomando uno o más atributos. Un segmento obvio es el género masculino o femenino. También se puede segmentar, por ejemplo, según el código postal, ya que las personas que viven en la misma calle tienden a estar en el mismo rango de edad y a tener un perfil familiar y nivel de ingresos parecidos.

En la publicidad personalizada de lo que se trata es de inferir a qué segmentos pertenece un usuario a partir de qué páginas visita o incluso descubrir nuevos segmentos.

Extracción automática de segmentos y anuncios relevantes para ellos

Veamos un poco una posible forma en la que podría funcionar la segmentación automatizada tomada de ^[1].

Supongamos que tenemos el anterior conjunto de usuarios U₁, U₂, U₃ … U_m y asimismo un conjunto de páginas Web W₁, W₂, W₃ … W_l. Cada página web podría pertenecer a una o más categorías C₁, C₂, C₃ … y las categorías se podrían asignar manualmente o se pueden inferir contando la frecuencia de cada palabra en la página o mediante técnicas aún más sofisticadas. Pero por ahora no nos detendremos en la categorización.

Primero construiremos una matriz M ∈ ℝ^m×l en la que cada elemento m_ij = (log(#veces que el usuario i ha hecho clic en la URL j) + 1) × log(l / #de usuarios que hicieron clic en la URL j). Cada fila de la matriz representa entonces a un usuario.

Por otra parte tendremos un conjunto de anuncios de productos P₁, P₂, P₃ … P_n

Si no tenemos inicialmente ninguna pista sobre la relación entre el comportamiento de los usuarios y los anuncios que ven, empezaremos mostrando anuncios de forma aleatoria e iremos contando en qué anuncios ha hecho clic cada usuario.

Seguidamente definiremos una métrica de similitud entre usuarios, que solo como ejemplo, podría ser la distancia euclídea entre los vectores que representan a cada usuario en la matriz.

Con todos estos elementos podemos determinar cómo de presuntamente similar es el usuario Fulanito al usuario Menganito y, dado que sabemos en qué anuncios ha hecho clic cada uno de los usuarios, presuponer que los usuarios similares mostrarán tendencia a hacer clic en los mismos anuncios.

Para medir los resultados primero definiremos una función

𝜹: (U_m,P_n) → {0, 1}
tal que
𝜹(U_m,P_n) = 1 si el usuario U_m ha hecho clic en el anuncio P_n
y 𝜹(U_m,P_n) = 0 si el usuario no ha hecho clic.

Con esta función si v_n es la cantidad total de usuarios que han visto el anuncio P_n definiremos el click through rate como

CTR(P_n) = 1/v_n ∑ 𝜹(U_m,P_n)

Que en palabras sencillas equivale a decir que si el anuncio ha sido mostrado 6 veces y 3 usuarios hicieron clic en él entonces el CTR es ½.

Si la segmentación ha sido eficaz, lo que se observará es un incremento en el click through rate de los anuncios tras dirigirlos específicamente a los usuarios que forman parte del target más probable.

No obstante, el CTR por sí sólo no es suficiente. Supongamos que hemos hallado un segmento S_r para el cual el CTR de un anuncio P_n es mayor. Lo cual escribiremos como CTR(P_n|S_r) > CTR(P_n). Esto sólo pone de manifiesto que existe un segmento de usuarios S_r que está más interesado en el anuncio P_n que la media del resto de los usuarios. Pero no implica que se hayan hallado todos los segmentos significativos de usuarios. Estadísticamente diríamos que el CTR es una medida de la precisión pero no de la exhaustividad (recall).

Para poder calcular el Valor-F, podríamos definir la exhaustividad (REC) como la suma de todos los valores de 𝜹 para todos los usuarios del segmento S_r que han visto el anuncio P_n dividida de la suma de los valores de 𝜹 para todos los usuarios que han visto el anuncio.

Y el Valor-F que pondera la precisión y la exhaustividad será entonces el habitual

F = 2 · Precisión · Exhaustividad / (Precisión + Exhaustividad)
que en nuestro caso particular para un anuncio P_n y un segmento S_r se convertirá en

Intuitivamente, es razonable suponer que los clics en un anuncio tenderán a provenir de los usuarios de determinados segmentos. Pero podría también suceder que la distribución de clics fuese uniformes a través de todos los segmentos, en cuyo caso la segmentación no serviría para nada. Una últimamétrica fundamental que necesitamos es pues la entropía, con la que será posible comparar la eficacia de diferentes segmentaciones. Sea v_r la cantidad de usuarios del segmento S_r que han visto el anuncio P_n. Entonces la probabilidad de que un usuario U del segmento S_r haga clic en el anuncio P_n es

𝛒(S_r|P_n) = 1/v_r ∑ 𝜹(U_m,P_n)

Con esta probabilidad podemos usar la definición matemática de entropía

E(P_n) = – ∑_r 𝛒(S_r|P_n) · log 𝛒((S_r|P_n))

A mayor entropía más uniformemente distribuidos están los clics en un anuncio a través de todos los segmentos.

Por supuesto, este es un modelo muy simplificado. Un modelo real tendrá en cuenta no sólo las páginas visitadas sino también el tiempo empleado en cada página, lo reciente que sea la última visita, la frecuencia con la que se visita la misma página, la cantidad de otras páginas vistas en el mismo sitio web, etc. No siempre lo relacionado con lo más recientemente visitado es lo que se anuncia al usuario. Algunos anunciantes eligen diferir la publicidad para que no sea evidente al usuario que está siendo seguido online.

El problema de la segmentación basada en CTR es que hace clic en un anuncio es un evento muy poco frecuente que puede rondar por algo como el 0,1% de las páginas vistas. Por ello veremos a continuación cómo se puede seguir extrayendo información relevante para la personalización aunque poco o ningún usuario hayan hecho clic en un anuncio determinado.

Personalización basada en interacciones sociales

Evidentemente, los likes en Facebook y Twitter pueden considerarse equivalents a una página vista con puntuación positiva sobre las preferencias de usuario. Pero de las redes sociales se puede extraer mucha más información. En primer lugar, debido a un fenómeno conocido por los sociólogos como homofilia, los amigos presentan normalmente similitudes en muchos rasgos: edad, lugar de residencia, intereses, … es decir, para que sepan de ti no hace falta que le cuentes a Facebook nada de lo que haces pues tan sólo viendo lo que hacen tus amigos es posible inferir que tú harás cosas parecidas.

Fuente: Large-Scale Behavioral targeting with a Social Twist (Kun Liu & Lei Tang)

Teoría de la relevancia

No voy a extenderme más sobre las técnicas estadísticas para la personalización de publicidad, pero antes de ir terminando, me gustaría hacer una brevísima parada en la teoría de la relevancia de Wilson y Sperber según la cual un receptor de un mensaje lo procesará mentalmente hasta que le encuentre un significado y entonces dejará de prestarle atención. Además, el estímulo publicitario debe de cumplir dos requisitos: 1º) el estímulo debe de ser lo bastante fuerte como para motivar el esfuerzo de entenderlo, y 2º) el estímulo debe ser compatible con las capacidades y preferencias del destinatario. Simplemente quiero detenerme aquí para recordar que ninguna técnica de optimización estadística salvará al anunciante de un mal mensaje.

Retargeting

El retargeting es el equivalente online a que una persona entre en una tienda atraída por su escaparate pero salga finalmente sin comprar nada. Posiblemente, el visitante sí estaba interesado, pero no encontró exactamente lo que buscaba, o en el ultimo momento abandonó su carrito de la compra –la última vez que trabajé en un sitio de e-commerce en retail había algo así como un 40% de carritos abandonado por gente que había agregado algo a la cesta pero no llegó a completar el pago–. Dado que los anuncios se diseñan para generar tráfico, es posible que el usuario hiciese clic en él por parecerle muy relevante pero luego el contenido no tanto. Esto en la jerga se conoce como tasa de rebote que es el porcentaje de usuarios que abandonan el sitio web tras visitar una sola página por breve tiempo (menos de 1 minuto). Con los «rebotados» es posible que haya poco que hacer, pero es factible recabar más información sobre los usuarios que sí navegaron por el sitio. Con estos últimos lo que se hace es pasar a la plataforma de anuncios más información sobre sus preferencias de manera que en el futuro se les presente otro anuncio más acorde con lo que se ha averiguado acerca de ellos. Esto se consigue colocándole al usuario una cookie de retargeting que se comparte con la plataforma de gestión de anuncios.

Técnicas de manipulación social y control de las flame wars

Publicado el 11 de enero de 2017 por Sergio Montoro

En la jerga informática una flame war se produce cuando un grupo de usuarios se enzarzan en una discusión acalorada e improductiva a través de un medio de comunicación digital. Las flame wars son tan antiguas como la propia Internet, según Wikipedia, la edición de 1983 del Diccionario del Hacker ya contenía una definición del flaming. Muchos psicólogos creen que las flame wars son un suceso seguro tarde o temprano cuando un grupo de gente no habla cara a cara. Pero las flame wars provocan enfados intensos en algunos usuarios y, lo que es peor (para el proveedor) bajas masivas en el servicio.

En este post voy a repasar cómo el flaming ha evolucionado según han ido apareciendo nuevas herramientas y, asimismo, qué técnicas para prevenirlo se emplean en la actualidad.

Fundamentos y tipos de flaming

La inevitabilidad del flaming se fundamenta en tres factores:

1º) Un fenómeno conocido cómo la Tragedia de los Comunes, que se produce cuando un grupo de personas comparten un recurso pero existen incentivos individuales para abusar del recurso. En el caso de la flame wars el recurso compartido es la atención del resto de los usuarios que los individuos tratan de acaparar generando escándalo.

2º) Es sabido que la persona que escribe tiende a dar por sentado que se entenderá el tono del mensaje que ha escrito. Mientras que la persona que lee tiende a interpretar el mensaje según su propio estado de ánimo. Entonces los malentendidos son frecuentes. Tan frecuentes, de hecho, que por eso hubo que inventar los emoticonos para aclarar con nuevos signos de puntuación la emoción contenida en el mensaje.

3º) No es necesario que todos los usuarios malinterpreten el mensaje o estén enfadados. Basta con que uno de ellos sea un sociópata que eche la colilla al monte para que se produzca un incendio. En un grupo suficientemente numeroso de personas siempre habrá al menos una deseosa de iniciar una gresca y al menos otra deseosa de continuarla.

Además de por ansia de atención, deficiente interpretación y trastornos mentales; yo añadiría, y esto es sólo una opinión personal, que el flaming se puede iniciar por la cantidad de tiempo que transcurre entre que reaccionamos emocionalmente a algo y conseguimos pensar acerca de ello racionalmente. Sucede que la parte más primitiva de nuestro cerebro, que genera las emociones primarias, funciona a mayor velocidad que el neocórtex. La diferencia, según tengo entendido, es de unos pocos milisegundos. Pero suficiente para provocar que las personas sienten antes de pensar. A veces esta emoción inicial nubla el buen juicio y es a partir de ese momento que empieza la escalada de violencia verbal.

Y más aún, algunos de los documentos filtrados por E. Snowden, pusieron de manifiesto que los gobiernos británicos y estadounidense atacan a sus enemigos con técnicas de desinformación que comentaré más adelante.

Según los psicólogos, existen básicamente cuatro tipos de hostilidad online: el desprecio, el despecho, el asalto y el linchamiento. El desprecio directo es típicamente una forma de agresión masculina, y el despecho a través de rumores es típicamente femenino. El asalto se produce cuando un grupo se organiza para atacar un objetivo, como por ejemplo hacen los hackers de Anonymous. El linchamiento se produce cuando el grupo etiqueta a un transgresor y apoya cualquier barbaridad de una cruzada organizada contra él. Esta distinción está bien, pero a mi me parece que en esencia todos los tipos son lo mismo: quedarse sin argumentos razonables durante una conversación y recurrir al insulto como medio para continuar la disputa.

Primera generación de herramientas de social media

Los primeros medios donde apareció el flaming fueron las listas de correo y los foros. En ellos es frecuente que se produzcan flame wars. Lo primero que se instauró para poner coto a las flame wars fueron las reglas de netiqueta. El problema con la netiqueta es que, al no ser forzosamente obligatoria, los que más la deberían cumplir son precisamente los que menos uso hacen de ella. A lo largo de los años se experimentó con diversas técnicas para prevenir el flaming en las listas de correo como, por ejemplo, limitar la cantidad de mensajes que cada usuario puede publicar por unidad de tiempo de modo que tenga que esperar cada vez más antes de responder. Sin embargo, lo más eficaz, según los propietarios de las listas, es contactar directamente y privadamente con el troll y pedirle que pare. Privar al troll de su objetivo principal, la audiencia, es la mejor forma de que cese en su actitud. El problema es la cantidad de tiempo y esfuerzo que se requiere para contactar uno por uno a todos los incumbentes y pedirles que haya paz. El resultado es que a día de hoy las listas de correo y los foros siguen siendo vulnerables al flaming y en parte por eso están en desuso.

Segunda generación de herramientas de social media

Tras las listas de correo y los foros, surgieron los weblogs y los wikis. En los weblogs es más fácil prevenir el flaming porque existe un “amo del calabozo” propietario del weblog que puede aprobar o rechazar comentarios antes de que se publiquen, los cuales, además, suelen estar separados del artículo principal, de forma poco visible. En los wikis lo que sucede es que, gracias al control de revisiones, deshacer cambios es mucho más fácil que hacerlos. Entonces, aunque Wikipedia ha sufrido innumerables intentos de manipulación y tergiversación hasta el punto de tener que restringir la edición de algunas páginas, a la postre ha conseguido sobrevivir como una fuente creible de información gracias a la constante supervisión grupal de la veracidad de los contenidos.

Tercera generación de herramientas de social media

El primer medio que popularizó una novedad significativa en el control del flaming fue Slashdot (en versión española Menéame). En Slashdot cada vez que un usuario comparte un contenido el resto le votan y adquiere “karma” (positivo o negativo). Las noticias más votadas aparecen primero y la credibilidad de un usuario depende de su buen karma. Además se introdujo un grupo de moderadores (usuarios con gran karma) y un grupo de meta-moderadores (moderadores de los moderadores). Esto funcionó bastante bien, y aunque tanto en Slashdot cómo en Menéame todavía pueden encontrarse verdaderos regueros de comentarios mierdosos, su visibilidad es enormemente reducida y normalmente no molestan. El siguiente refinamiento sobre Slashdot fue StackExchange. En StackExchange existen reglas bastante sofisticadas para regular el karma. Las ganancias y pérdidas son asimétricas. Se ganan diez puntos de karma cuando se recibe un voto favorable de otro usuario, pero sólo se pierde un punto de karma por cada punto desfavorable. Además, cuando se vota en contra de otro usuario se resta un punto también a tu propio karma. Es decir, al votar en contra de otro votas también en contra de ti mismo. El efecto de esto es que sólo los usuario con buen karma para gastar pueden hundir la reputación de otros. También se pueden ofrecer botines por publicar respuestas excepcionalmente buenas. Y existe un extenso conjunto de diferentes medallas (badges) que se pueden ganar además de la cifra numérica de karma. El problema de los sitios como Slashdot y StackExchange (a mi juicio) es que cuesta mucho tiempo y esfuerzo ganar el karma. Una persona puede haber ganado la Medalla Fields, sin embargo, cuando se registre en MathOverflow (uno de los sitios de StackExchange) no tendrá ningún karma, y además, tendrá que pasarse cientos de horas en MathOverflow para poder obtener una cantidad significativa de karma. Entonces más que un grupo de expertos, lo que se genera es un grupo de usuarios fanáticos yonkis del karma cuya especialidad no es inventar nada sino investigar lo que otros han inventado para responder a las preguntas de los que no tienen ni idea.

Cuarta generación de herramientas de social media

Una importante limitación de Slashdot y StackExchange es el poder de las élites. En este tipo de redes el 10% de los usuarios genera el 90% de los contenidos. Había de alguna forma que democratizar la participación pero sin que se llenase la conversación de basura. A mi me gusta bromear argumentando que Facebook es la democratización de la prensa rosa. Antaño la gente compraba masivamente la revista Hola, pero sólo unos poquísimos podían salir en las páginas de Hola. La misión que Facebook se marcó fué que cualquiera pudiese salir en Hola, pero evitando que la participación masiva lo convirtiese en un folletín de prensa amarilla lleno de polémica.

Creo que lo primero que hay que tener en cuenta sobre Facebook es que, aparentemente, no está interesado en manipular la opinión pública, sino que su objetivo es recopilar información de los usuarios para vendérsela a los anunciantes y generar tráfico manteniendo a la audiencia enganchada. Lo que los investigadores de Facebook descubrieron en un polémico estudio secreto es que la lealtad de un usuario a un sitio depende del estado emocional que el sitio le genere, y, además, las emociones son contagiosas entre usuarios. Por consiguiente, para que los usuarios vuelvan es menester que no se enfaden y para que no se enfaden no deben poder leer nada ofensivo. La vida perenne dentro de lo políticamente correcto la genera Facebook de varias maneras. Lo primero que hicieron en Facebook fue desestimar el karma y los votos negativos estilo Slashdot porque se descubrió que la popularidad comparativa afectaba emocionalmente a muchos usuarios, especialmente a las féminas adolescentes. Es por eso que no existe el botón de No me gusta 👎 En segundo lugar, Facebook otorga al propietario de cada muro el poder de eliminar comentarios, borrar de la lista de amigos o prohibir la publicación a cualquier indeseable. Es decir, el propietario de la conversación es siempre el que la inició y no se permiten comentarios críticos. Adicionalmente, no se pueden ocultar a los amigos los clicks en Me gusta de páginas públicas. Eso desincentiva a la gente a aumentar la popularidad de nada que esté socialmente mal visto. El algoritmo de recomendaciones introduce un importante sesgo de confirmación sugiriendo al usuario sólo cosas relacionadas con aquello a lo que dijo «Me gusta». Si te preocupa el cambio climático y usas Facebook acabarás creyendo que el futuro de la Humanidad depende de que salvemos a las ballenas, y si tienes un perro y usas Facebook acabarás pensando que los derechos de los animales están por encima de los derechos humanos. Da igual cómo empieces, Facebook lo único que hará será reforzar y radicalizar más y más cualquier idea semilla que le introduzcas para que te quedes a vivir en tu zona de confort. El mecanismo psicológico detrás de este refuerzo es que para entender algo primero necesitamos creer en ello. Por ejemplo, nadie entendió que la Tierra podría girar alrededor del Sol, y no al revés, hasta que alguien creyó que tal órbita era realmente posible. Por último, y por si todo lo anterior fuese poco, cada día crece la cantidad de cuentas de Facebook y Twitter que tienen una segunda cuenta de respaldo en previsión de que les cierren la primera por censura. Y de Tumblr ya ni hablemos, pues en Tumblr una cuenta dura viva menos que un caramelo en la puerta de un colegio.

Cómo se manipula y sabotea la opinión pública

Existen varias decenas de técnicas bien conocidas para manipular y sabotear la opinión pública. Las 25 Reglas de la Desinformación de Michael Sweeney o Desinformación: Cómo funciona de Brandon Smith son un par de buenos ejemplos recopilatorios de las tácticas entre las cuales, a mi juicio, algunas de las principales son:

1. Divide y vencerás. Se trata de enfrentar a unos grupos opositores contra otros. Esto se puede conseguir acentuándo sus diferencias para menguar su fuerza combinada contra un adversario común. Pero también de formas más sutiles. Por ejemplo, proponiendo soluciones exageradas y fuera de lugar.

2. Ruptura de consenso. Consiste en publicar un argumento aparentemente sólido con una cuenta falsa. Luego, con otras cuentas falsas, demostrar que se trata de un argumento totalmente falaz.

3. Dilución del asunto. Se consigue publicando sistemáticamente contenidos no relacionados con el tema que se desea evitar.

4. Exigencia de pruebas irrefutables. En las conversaciones, usar la presución de inocencia para exigir pruebas absolutamente irrefutables de todo. Por muchos indicios que haya y muy verosimil que sea la historia, tacharla de falsa invalidando las pruebas y alegando que se trata sólo de una conspiración malintencionada.

5. Desacreditación de la fuente. Si la fuente es un blogger independiente, argumentar que su opinión no tiene ningún periodístico y que sólo se trata de un charlatán tratando de ganarse el favor de algunos poderosos. Si la fuente es un gran medio de comunicación, argumentar que todos los periodista y el editor están en la nómina de alguien quien decide lo que se publica o no. Si el autor no ostenta un posdoctorado, decir que su opinión no vale nada, si lo ostenta decir que nunca ha salido de la universidad y no conoce el mundo real.

Creo también que vale la pena mencionar, como contraejemplo, el fracaso estrepitoso de las técnicas basadas en descalificar personalmente al adversario. No funcionaron contra Winston Churchill, no funcionaron contra Vladimir Putin, no funcionaron contra Donald Trump y en España no funcionaron contra Mariano Rajoy. El estudio del odio exacerbado de los progres contra Donald Trump creo que merecería un libro entero. Primero por lo contrproducente de la estrategia y segundo por la sorprendente forma en la cual, después de haber denostado a Trump de todas las formas imaginables, los atacantes se han empezado a victimizar como si los seguidores de Trump hubiesen organizado una caza de brujas en la red contra sus detractores.

Post relacionados:
Propaganda 2.0.

Publicado en Usos sociales de la tecnología | 3 comentarios

Cómo sobrevivir a las estimaciones de software

Publicado el 9 de enero de 2017 por Sergio Montoro

Una de las preguntas mas peliagudas que un desarrollador tiene que responder semanalmente es “¿cuanto vas a tardar en hacer esto?” Que es muy probablemente lo que le preguntó el papa Julio II a Miguel Ángel cuando le encargó decorar la bóveda de la Capilla Sixtina.
Existen diversas técnicas formales de estimación, las que funcionan están basadas en apuntar cuánto se tardó realmente en realizar una tarea similar en el pasado y estimar que se tardará mas o menos lo mismo en completar la nueva tarea. Para el desarrollo en territorio desconocido existen también varios métodos especulativos incluidos algunos tan divertidos como el planning poker donde los programadores realmente apuestan cuánto van a tardar.

Dilbert Software Estimation

No repasaré los métodos cuantitativos, que dan de si como para un libro entero de ingeniería de software. Aunque cualquiera que trabaje en un proyecto de software debería como mínimo conocer cuatro cosas:

1) los fundamentos del modelo COCOMO y el Software-Engineering-Economics de Boehm.
2) cómo funcionan las historias de usuario y los product backlogs en Agile, sobre lo que hay una breve introducción aqui y más extensamente en el libro de Mike Cohn.
3) qué es PERT y CPM.
4) cuales son las tecnicas de optimización global.

Otro libro recomendable es Software Estimation: Demystifying the Black Art.

Me voy a centrar en las estimaciones que no queda más remedio que sacar de un sombrero.

La primera pregunta que hay que hacer en respuesta a la pregunta “¿Cuánto vas a tardar en hacer esto?” es “¿Para qué quieres saberlo?”.

Normalmente se quiere saber porque el tiempo esta asociado al consumo de recursos o a una fecha de compromiso con el cliente. Pero no es lo mismo una cosa que la otra. Quizá el consumo de recursos sea flexible porque se puede pedir más dinero a los inversores pero la fecha de compromiso con el cliente no sea nada flexible porque hay que contratar una campaña de publicidad en televisión, anunciando la nueva web, cuya programación no se puede cambiar de ninguna manera una vez acordada con la cadena emisora. O puede que la fecha sea necesaria porque hay que asignar recursos en otro departamento que está a la espera de recibir el nuevo software.

Es decir, lo primero que hay que hacer es determinar el ámbito del problema y la precisión que debe tener la estimación.

Lo siguiente que hay que hacer es una lista de pre-requisitos para que la estimación sea válida. Por ejemplo, puede que la resolución implique revisar un código antiguo que nadie conoce bien y que quizá no se pueda modificar alegremente, o puede que solucionar un defecto en el diseño de la base de datos requiera unos privilegios de administración otorgados por un tercero que puede tardar un tiempo indeterminado en despachar un ticket de soporte. En general, la causa mas común de retrasos en equipos Agile es que se esté esperando a algo que debe ser proporcionado por una fuente externa que no es Agile, entonces el equipo se convierte en un grupo de personas esperando “eficientemente” a que alguien más haga algo. Es importante que el cliente entienda y acepte los pre-requisitos.

Una vez acotado el ámbito del problema y la precisión requerida y acordados los pre-requisitos, lo siguiente es decir: “No sé cuánto tardaremos, pero lo sabré dentro de X horas/dias”. Explicando que se necesita tiempo para evaluar detenidamente la información disponible antes de poder hacer una estimación. Si el cliente insiste en este punto en obtener una estimación una respuesta posible es: “La media entre dos horas y dos meses, dependiendo de lo que nos encontremos durante el análisis detallado del problema”.

No obstante lo anterior, si el responsable de la planificación de proyecto no esta presente en la reunión, hay sólo tres respuestas que un programador debe dar a cualquier petición de estimación:

a) “Es imposible hacer eso”.
b) “Es extraordinariamente difícil y peligroso hacer eso”.
c) “Eso debemos hablarlo con el jefe de proyecto”.

A veces hay que educar a los usuarios porque no conocen el proceso de desarrollo. A veces no entienden que aunque una madre haga un niño en nueve meses, dos madres no pueden hacer un niño en cuatro meses y medio. Otras veces no entienden que sólo es posible fijar dos de los tres lados de triangulo coste/calidad/tiempo. Y en otras tienen problemas para priorizar por el método MoSCoW (Must have, Should have, Could have, Won’t have). Si este es el caso, es muy conveniente hacerle saber al cliente que un software grandioso es aquel que hace unas pocas extraordinariamente bien y no aquel software que sirve para todo pero no es bueno para nada.

En el caso de que no quede ningún otro remedio que responder, puede ser útil aplicar el Principio de Scotty que consiste básicamente en estimar a ojo de buen cubero, añadir un 50% de tiempo a la estimación y reportar la cifra inflada. Aunque una nota de aviso sobre esto: funciona para dar estimaciones al cliente final, pero no para hacer estimaciones internamente en el equipo de desarrollo. Esto es debido a que si se permite que los desarrolladores estimen unilateralmente cuando terminarán el software, entonces nunca lo terminarán porque, por su propia naturaleza, un software nunca esta terminado.

Si se ha fallado en las estimaciones previas la credibilidad estará en entredicho. En tal caso lo mejor es suponer que las siguientes estimaciones se desviarán en la misma medida en que se desviaron las anteriores. De hecho, esta capacidad de extrapolación es presuntamente una de las ventajas de Agile. Si se estimó que una tarea al inicio del proyecto tardaría dos dias y tardó realmente cuatro entonces es posible conjeturar desde casi el principio que todo el proyecto tardará el doble de tiempo del inicialmente estimado. Si el proyecto pinta mal entonces «más vale ponerse una vez (muy) colorado que ciento amarillo». En un proyecto que requiere reingeniería hay que resistir a muerte y cueste lo que cueste las presiones para dar fechas optimistas. Esto no siempre es fácil porque lo habitual es hacer rodar la cabeza del responsable de desarrollo que incumplió sistemáticamente los plazos y substituirlo por otro que promete que si puede cumplirlos. Y luego decapitar a este segundo también y a todos sus sucesores hasta que el proyecto se completa o se cancela.

Por ultimo, si no se tiene realmente ninguna idea y hay forzosamente que responder, entonces decir «dos semanas», que es lo que dura como mínimo un sprint y lo que se tarda en hacer circular el curriculum actualizado.

Publicado en Casos Prácticos | 1 comentario

Estado del arte de la genómica computacional

Publicado el 31 de diciembre de 2016 por Sergio Montoro

Codigo Genético La bioinformática es el área de la computación que tiene mayor potencial para transformar el estado de la Humanidad a corto-medio plazo. Es escasamente comentada por los medios de comunicación, probablemente debido a la inexistencia de productos de consumo masivo con fuertes inversiones en campañas de publicidad y relaciones públicas.

Cuando se habla de bioinformática se piensa casi siempre en la secuenciación de ADN. Pero los desafíos científicos de la bioinformática no se limitan a la manipulación del código genético, sino que abarcan otras áreas como la predicción de estructura y alineamiento estructural de proteínas, el modelado de procesos evolutivos y, en general, la explicación de todos los procesos biológicos.

En este artículo voy a comentar sólo la genómica computacional, es decir, el estado del arte de la tecnología para tratamiento informatizado del código genético usando técnicas algorítmicas, estadísticas, y «Big Data». Pero el desafío científico es mucho más amplio e incluye:

• Cómo leer rápidamente, con exactitud y a bajo coste el ADN de un organismo vivo.
• Cómo almacenar las secuencias de ADN leídas.
• Cómo comparar nuevas secuencias con secuencias ya conocidas para establecer relaciones evolutivas entre ellas o encontrar mutaciones patógenas.
• Cómo explicar la síntesis de proteínas, crecimiento de tejidos, formación de órganos, coordinación entre órganosy otros procesos vitales con un lenguaje de alto nivel que nos permita describir organismos vivos.
• Cómo crear cadenas de ADN y cromosomas ensamblando genes que cumplan una determinada función.
• Cómo insertar el ADN generado en una célula capáz de producir la función especificada.
• Cómo alterar los genes ya presentes en un organismo vivo para corregir errores y curar enfermedades.

Es frecuente asociar la genómica computacional con el diagnóstico y tratamiento de trastornos de salud cuyo origen es genético, pero la genómica computacional es aplicable a muchas más cosas además de la medicina. Quienes están invirtiendo activamente en la recopilación y explotación de información genética tienen en mente un uso comercial mucho mayor. Actualmente aún es relativamente caro secuenciar ADN, pero llegará un día no muy lejano en el que las empresas paguen por tener nuestra información genética con el fin de usarla para personalizar su oferta, no sólo en forma de medicamentos a la medida del paciente, sino en base a cualquier cosa que el ADN pueda revelar acerca de las preferencias y necesidades de cada persona.

Como en ocasiones anteriores, he estructurado el texto desde lo menos técnico a lo más técnico. Necesito empezar explicando un poco el contexto de qué es el ADN y cómo funciona antes de poder comentar los métodos computacionales. Finalmente explicaré el hardware y otras tecnologías que se usan modernamente para la implementación.

Composición y estructura del ADN

Desde el punto de vista de el tratamiento de información, las cadenas de ADN son básicamente un lenguaje que explica cómo se sintetizan proteínas a partir de veinte aminoácidos constituyentes. El orden en el que se concatenan los aminoácidos determina la estructura de la proteína (que puede llegar a ser bastante compleja) y la estructura determina su función. Las proteínas sintetizadas forman células, las células forman tejidos, los tejidos forman órganos y los órganos cooperan para hacer funcionar el cuerpo humano.

Secuencia AT-CG Las cadenas de ADN se forman con cuatro nucleótidos: dos purinas, adenina (A) y guanina (G) ; y dos pirimidinas, citosina (C) y tiamina (T). En adelante nos referiremos a estos nucleótidos simplemente como A G C T. Los nucleótidos se enlazan siempre en los mismos pares purina-pirimidina A-T y C-G dentro de la conocida estructura de doble hélice. Cada triplete de nucleótidos forma un codón. Un codón codifica un aminoácido. Hay 64 codones posibles, pero sólo 20 aminoácidos. Un aminoácido puede ser codificado por 1,2,3,4 o 6 codones distintos. También existe un codón de inicio y tres codones de terminación. Por ejemplo, la secuencia que da nombre a la película GATTACA podría interpretarse como GAT TAC A en cuyo caso codificaría ácido aspártico seguido de tirosina más una A extra; o como G ATT ACA y entonces sería una G seguida de isoleucina y treonina.

Animaciones de biología invisible, Drew Berry

Las secuencias de codones forman exones e intrones que intercalados forman un gen. Durante mucho tiempo el dogma central de la genómica fué que un gen codifica una proteína aunque no es exactamente así. Los intrones pueden dotar al gen de empalmes alternativos que le sirven para generar diferentes proteínas relacionadas. Durante el proceso de transcripción, se eliminan los intrones y se empalman los exones del gen antes de empezar el proceso de síntesis protéica. Se estima que los humanos tienen unos 19.000 genes codificadores de proteinas, además, cada gen puede codificar variantes de la misma proteina por lo que se estima que en los humanos pueden existir hasta 100.000 proteínas diferentes.

Un grupo de genes capaces de ejercer una regulación de su propia expresión por medio de los sustratos con los que interactúan las proteínas codificadas forma una unidad genética denominada operón. Cada operón tiene tres partes: el factor promotor, el operador y el gen regulador en cuyos detalles no entraremos aquí.

Además del orden de la secuencia de nucleótidos, los hallazgos científicos recientes confirman que la forma en la que está plegado el ADN también es relevante para su funcionalidad. El genoma humano completo tiene unos 3.000 millones de pares de nucleótidos repartidos en 23 cromosomas. Puesto en línea mediría aproximadamente dos metros. Sin embargo, cabe dentro de los 10 micrometros del núcleo de cada célula porque está retorcido en nucleosomas. De la expresión de los genes que no depende de la secuencia sino de su plegamiento y otros factores se ocupa una rama llamada epigenética.

Hasta aquí lo que tenemos es una maquinaria de producción de proteínas y autoreplicación. Pero el ADN no puede ser sólo una superestructura molecular autoreplicante y generadora de proteínas. Tiene que ser algo más. El ADN debe poseer las cinco características de todo lenguaje: alfabeto, gramática, significado, intención y redundancia y corrección de errores.

Por poner sólo uno de los innumerables ejemplos que podríamos encontrar. Durante la reproducción los espermatozoides encuentran el óvulo debido a que éste emite calcio. Los espermatozoides pueden detectar el gradiente de calcio y nadar en la dirección en que aumenta la concentración. Este comportamiento tan complejo de una sola célula no puede explicarse sólo en términos de síntesis protéica. Tiene que existir algo más en el ADN que controle cómo nadan los espermatozoides.

Técnicas de secuenciación de ADN

Como síntesis del análisis anterior sobre la composición y estructura del ADN podemos decir que en los humanos encontramos tres mil millones de bits (nucleótidos) agrupados en palabras de 3 bits (codones) que componen subrutinas (genes) contenidas en módulos (operones). Pero por ahora nadie sabe cómo proporcionar una explicación de alto nivel a cómo interpretar este galimatías.

El primer desafío es secuenciar el ADN. No se conoce ninguna técnica para leer un cromosoma de principio a fin. Lo que se hace actualmente se conoce como secuenciación por perdigonada seguida de un ensamblado de secuencias. Esta técnica consiste en cortar múltiples copias del ADN a secuenciar en múltiples fragmentos de una longuitud variable entre 600 y 800 nucleótidos. Luego averiguar cómo encjan unos fragmentos con otros casando el final de un fragmento con el principio de todos los otros maximizando el grado de solapamiento de nucleótidos.

Secuencia original	AGCATGCTGCAGTCATGCTTAGGCTA
Primera perdigonada	AGCATGCTGCAGTCATGCT——- ——————-TAGGCTA
Segunda perdigonada	AGCATG——————– ——CTGCAGTCATGCTTAGGCTA
Secuencia reconstruida	AGCATGCTGCAGTCATGCTTAGGCTA

Para complicar aún más el proceso, ningún secuenciador de ADN proporciona lecturas correctas con un 100% de probabilidad. Cada nucleótido es leído sólo con un porcentaje de probabilidad. Aunque con los secuenciadores más modernos y múltiples lecturas con consenso la probabilidad llega al 99,9%.

Similitud de secuencias de ADN

La variación genética entre humanos se estima que es entre el 0,1% y el 0,4% de los nucleótidos. Es decir, entre el ADN de dos humanos cualesquiera difiere, más o menos, en uno de cada mil nucleótidos. Cuando se secuenció el genoma humano por primera vez no se hizo con el ADN de un sólo individuo sino con el de cinco individuos. Estudios posteriores con 1.000 individuos de 26 poblaciones diferentes han mostrado que existen entre 4,1 y 5 millones de diferencias con el genoma de referencia. Debido a que, como ya hemos expuesto, dos codones diferentes pueden codificar el mismo aminoácido, muchas de estas variaciones son irrelevantes. Pero otras pueden causar graves enfermedades sólo por la variación de un nucleótido que imposibilita la síntesis de una proteína esencial para algún proceso vital.

Según las cifras que hemos indicado, los algoritmos de detección de disfunciones de origen genético deben buscar en unos tres millones de diferencias repartidos entre tres mil millones de pares.

Lo primero que se necesita pues es una métrica de similitud de secuencias. En genómica la similitud de secuencias de nucleótidos se mide comparando alineamientos. Para poder realizar un alineamiento de dos secuencias primero deben tener la misma longitud pues de otro modo no es posible hablar de los nucleótidos en la posición 1, 2 etc. Si dos secuencias no tienen la misma longuitud entonces se pueden insertar espacios al principio, al final o en medio de cada secuencia. Los espacios se conocen en la jerga genómica como “indels” (inner insertion or deletion) Por ejemplo, supongamos que empezamos con las secuencias GACTCT y GAGGC. Un posible alineamiento para ellas es:

GAC_TCT
GA_G_C_

Entonces una posible métrica es considerar el número de posiciones con el mismo nucleótido y restarle las posiciones con nucleótidos diferentes o con un espacio. En este caso las secuencias alineadas coinciden en los nucleótidos 1,2,6; difieren en la posición 3 y tienen espacios en 4,5,7. Por consiguiente, la puntuación para este alineamiento será 3-1-3 = -1. Tres coincidencias menos una no-coincidencia menos tres espacios. Con esta métrica, nuestra definición de lo que es el mejor alineamiento A posible de dos secuencias S₁ y S₂ será:

A ∋ A = MAX (#coincidencias – #nocoincidencias – #espacios)

Por supuesto esta sencilla métrica no es la única válida. Lo que se deseará es emplear una métrica que devuelva la máxima similutud para secuencias de nucleótidos que tengan la misma función biológica aunque las secuencias no sean idénticas nucleótido por nucleótido. Es posible otorgar diferente peso a las no-coincidencias y a los espacios. También es común el uso de mutaciones puntuales aceptadas, es decir, substituciones en nucleótidos que se sabe que no afectan significativamente a la función de la proteína descrita por un gen. Pero por ahora no entraremos en las matrices de substitución y nos centraremos en los algoritmos de alineamiento de secuencias.

Alineamiento de secuencias de ADN

Los algoritmos más populares para alineamiento de secuencias son el Needleman-Wunsch para alineamiento global, el Smith–Waterman y el Altschul-Erickson para el alineamiento local y BLAST o FASTA para búsquedas heurísticas. El Needleman-Wunsch sirve para comparar si dos genes tienen probablemnente la misma función. Las variantes de Smith–Waterman se emplean para buscar subsecuencias y para averiguar si el final de una secuencia encaja con el principio de otra tal y como requiere el ensamblado de fragmentos en la secuenciación por perdigonada. BLAST y FASTA se usan para buscar rápidamente en una base de datos secuencias potencialmente similares a una dada y con los resultados preliminares devueltos por la búsqueda heurística de BLAST se ejecuta Needleman-Wunsch para encontrar la secuencia conocida más similar.

Veamos porqué se necesitan algoritmos eficientes para encontrar el mejor alineamiento de dos secuencias. Sea r la diferencia de longuitud entre las dos secuencias S₁ y S₂. Por principios de combinatoria, el número de secuencias diferentes que es posible generar a partir de S₁ (de longitud n) con r espacios es :

C(n+r,n)

Dado que k! = 1×2×3×…k incluso para cadenas muy cortas, pongamos por ejemplo de 10 nucleótidos con 5 espacios, las variantes serían: (10+5)! ÷ 10! 5! = 3.003

Ahora hay que alinear la secuencia S₂ con S₁. Se puede comprobar que el número total de alineamientos posibles es:

∑ C(n+r,n) C(n,r)

Es decir ¡el numero de alineamientos posibles entre dos secuencias crece vertiginosamente rápido a medida que aumenta la longuitud de las mismas!

Afortunadamente, no es necesario generar y puntuar todos los alineamientos para encontrar el óptimo. El truco consiste en componer una matriz con las secuencias en los ejes de abcisas y ordenadas. Con dicha disposición de las secuencias, es posible demostrar que cada alineamiento posible se corresponde con un camino entre la esquina superior izquierda ✲ y la inferior derecha ✲. Para trazar estos caminos se puede recorrer la diagonal si los nucleótidos de la abcisa y la ordenada coinciden y si no coinciden se debe hacer un desplazamiento vertical u horizontal, lo cual equivale a insertar un espacio en una u otra secuencia. Cuando se puede recorrer la diagonal se suma 1 al camino que se está recorriendo y cuando hay que moverse verticalmente u horizontalmente se resta 1. El alineamiento (o alineamientos) óptimo según la métrica que hemos descrito anteriormente es aquel que tiene la diagonal más larga. En el caso del camino azúl de la matriz mostrada su puntuación será -1+1-1+1-1+1+1+1+1+1+1+1=6.

No voy a detallar aquí el algoritmo de programación dinámica basado en explorar el vecindario de cada nodo ┼ para trazar el camino y seguidamente reconstruir el alineamiento a partir del camino. Lo importante es que dicho algoritmo se puede ejecutar en un tiempo proporcional a 12×m×n, Siendo m y n la longuitud de las secuencias. Es decir, para dos secuencias de igual longuitud n la complejidad del algoritmo para alinearlas globalmente es O(n²) lo cual sigue siendo computacionalmente costoso pero es un tiempo polinómico en lugar de la horrenda expresión factorial.

El alineamiento global se usa para comparar genes. Incluso entre diferentes especies. Si identificamos un gen de ratón con una determinada función biológica (recordemos que un gen codifica una proteína) entonces podemos buscar un gen parecido en los humanos y si lo encontramos probablemente tendrá una función biológica en los humanos muy similar a la que tiene en los ratones.

Otro problema de alineamiento relacionado es que dadas dos secuencias S₁ y S₂ de longuitudes m y n, se desea encontrar dos subsecuencias de longitudes p y q tales que el valor de su alineamiento sea máximo. El algoritmo de Smith–Waterman para el alineamiento local es una variante del método de buscar la diagonal más larga excepto que permite empezar y terminar por nodos diferentes del superior izquierdo y el inferior derecho, y en un momento dado se puede descartar un conjunto de nodos ya explorados porque su puntuación sea negativa.

Respecto del ensamblado de secuencias cortas (entre 500 y 800 nucleótidos) para secuenciar genomas enteros con millones de pares de bases, buscar el mejor encaje entre el final de una secuencia y el principio de otra tomada de un conjunto de candidatas, es un problema muy similar a buscar un alineamiento global entre el final de una secuencia y el principio de otra excepto porque en este caso podemos esperar que el alineamiento, en el caso de existir, tenga muy pocas no coincidencias (debido a que las dos subsecuencias son trozos de la misma secuencia original) excepto porque se producen esporádicamente errores en la lectura de los nucleótidos. Con los secuenciadores modernos, la tasa de errores no supera el 0,1%, por consiguiente, el algoritmo deberá aplicar alguna técnica de corrección de errores y luego penalizar mucho las no-coincidencias.

Por último, puede presentarse el problema de encontrar el mejor alineamiento múltiple para una colección s de secuencias de longuitud n. La complejidad de este problema es O(n^s) y, de hecho, se sabe que es un problema NP-Completo, por consiguiente, no existe ninguna solución que se pueda encontrar en tiempo polinómico. Sin embargo, el alineamiento de múltiples secuencias puede proporcionar información que es imposible de obtener con el alineamiento de sólo dos secuencias. Sucede que en regiones de ADN con funciones similares las partes de mayor importancia evolucionan con mayor lentitud que las partes menos relevantes biológicamente. Entonces es posible tomar, por ejemplo, secuencias de diferentes mamíferos, perros, gatos, ratones, humanos, etc. e identificar qué subsecuencias cambian (o no cambian) en operones que se sabe que cumplen funciones biológicas parecidas. Recíprocamente, si se tiene una secuencia que no se sabe para qué sirve pero puede alinearse de forma múltiple con otras secuencias de una colección que sí se sabe para qué sirven, entonces es posible concluir que la secuencia desconocida pertenece probablemente a la colección con la que tiene un buen alineamiento múltiple.

Una colección de secuencias relacionadas mediante un alineamiento múltiple se conoce como un perfil. Cuando se quiere saber si una nueva secuencia se ajusta a un determinado perfil, lo que se puede hacer es comparar el nucleótido en cada posición con los nucleótidos en la misma posición en el perfil, teniendo en cuenta que el perfil da una probabilidad para nucleótido A,T,C,G en la posición n. No obstante, existen otros métodos para determinar si una secuencia tiene un determinado perfil, en particular, los modelos de Markov que veremos a continuación.

Modelos de Markov

Resumidamente, un modelo de Markov consiste en un conjunto de estados y una probabilidad de transición de un estado a otro. Para el ADN tomaremos cuatro estados: A,T,C,G. A cada transición de un estado a otro A→A, A→T, A→C, A→G, T→A, T→T, etc. se le asigna una probabilidad. En este caso, si las transiciones de estado fuesen completamente aleatorias, la probabilidad de transición desde cada estado al siguiente sería ¼. Una secuencia de transiciones de estado contruida siguiendo las probabilidades de transición de un estado a otro se denomina una cadena de Markov. El generador puede representarse como un grafo dirigido con una probabilidad asociada a cada una de las aristas.

Grafo dirigido completo

Esto tiene varias aplicaciones en genómica. Sucede, por ejemplo, que las regiones CpG (un nucleótido C seguido de otro G) son raras excepto para indicar el comienzo de un gen, con una longitud de la región CpG desde cien a unos pocos miles de pares de bases.

Probabilidades de transición
en regiones CpG.

	A	C	G	T
A	.180	.274	.426	.120
C	.171	.368	.274	.188
G	.161	.339	.375	.125
T	.079	.355	.384	.182

Probabilidades de transición
en regiones no CpG.

	A	C	G	T
A	.300	.205	.285	.210
C	.322	.298	.078	.302
G	.248	.246	.298	.208
T	.177	.239	.292	.292

Fuente: Hidden Markov Model for CpG islands

Con estos datos es posible comparar la probabilidad de que una secuencia sea una región CpG versus una región no CpG. Para ello basta con multiplicar las probabilidades de transición. Por ejemplo, dada la secuencia CGACGT en cada modelo habría que multiplicar: C→G × G→A × A→C × C→G × G→T. Entonces la probabilidad de que CGACGT haya sido generada por el modelo CpG es 0,274 × 0,161 × 0,274 × 0,274 × 0,125 = 0,000414 y para el modelo no CpG es 0,078 × 0,248 × 0,300 × 0,078 × 0,208 = 0,000094. Es decir, es cuatro veces más probable que la secuencia CGACGT pertenezca a una región CpG que a una región no CpG.

Llegados a este punto, es fácil intuir que dada una secuencia querremos hallar el Modelo de Markov Oculto que la generó. Es decir, la Cadena de Markov que con una mayor probabilidad generará la secuencia que ya tenemos. Esto se hace con el algoritmo de Viterbi, otro algoritmo de programación dinámica cuyos detalles no comentaré aquí.

En resumen, la clave del Modelo de Markov es que la probabilidad de encontrar cada estado se calcula exclusivamente en base al estado inmediatamente anterior. Aquí lo hemos ilustrado con nucleótidos, pero también puede usarse un modelo de Markov con codones en cuyo caso tendríamos sesenta y cuatro estados en lugar de cuatro y la probabilidad de encontrar un codón dependería del codón inmediatamente anterior.

Filogenética y evolución del genoma

La filogenética computacional es el área de la genómica computacional que se ocupa de estudiar la relación entre especies o taxones (grupos de organismos emparentados). Supongamos que tenemos cinco especies: A,B,D,E y F. El primer desafío es definir qué caracteriza a una especie. Esto se hace, en principio, mediante la observación externa. Y a continuación habrá que determinar qué variaciones en el ADN causan la biodiversidad. Esta labor de caracterización de las especies no es nada sencilla, pero, por el momento, vamos a suponer que, tras una árdua labor, ya la tenemos hecha para nuestras cinco especies. Además presumiremos la existencia de algún tipo de reloj molecular que marca el ritmo de la evolución. Con estas hipótesis una posible forma (muy simplificada) de modelar la evolución es mediante árboles ultramétricos. En un árbol ultramétrico, cada nodo interno tiene exactamente dos sucesores y un número estrictamente decreciente desde la raíz.

Este árbol expresa que las especies A y B surgieron a partir de la C (posiblemente extinta) hace 3 unidades de tiempo. Y la la D y la G surgieron de la H hace 5 unidades de tiempo. En la práctica, los números en los nodos internos del árbol se obtienen normalmente por alineamiento de secuencias, es decir, se asume que el grado de variación entre especies está correlacionado con el tiempo.

Para la búsqueda de un árbol filogenético que requiera el menor número de eventos evolutivos (reconstrucción filogenética) pueden emplearse diversos métodos: máxima parsimonia, máxima verosimilitud, inferencia bayesiana (IB) y matriz de distancias son los más comunes que por brevedad no describiremos aquí. El lector interesado puede encontrar más detalles sobre filogenética y modelos de Markov en el texto clásico Biological Sequence Analysis.

Búsquedas en bases de datos de secuencias

Debido a que el alineamiento de secuencias es computacionalmente costoso (proporcional al producto de la longitud de las secuencias), se necesita alguna técnica heurística para buscar una secuencia recientemente obtenida en una base de datos de secuencias conocidas. Especialmente si existe un elevado número de usuarios buscando concurrentemente alineamientos en una base de datos.

La primera herramienta que se popularizó para buscar secuencias relacionadas fue BLAST (Basic Local Alignment Search Tool). La idea de la primera versión de BLAST fué que si dos secuenciias son similares –en el sentido en el que hemos definido la similutud por la existencia de un alineamiento con una buena puntuación en la métrica anterior– entonces existirán subcadenas de nucleótidos idénticas entre las dos secuencias. Por ejemplo:

AACTACTATAAGAA
AACTCCAATAGGAA

La hipótesis de BLAST es que si en dos secuencias no es posible encontrar una cierta cantidad de subcadenas idénticas de suficiente longitud, entonces es poco probable que exista ningún buen alineamiento entre las secuencias. BLAST sólo proporciona resultados probabilísticos porque es fácil construir ejemplos de secuencias que no cumplen la condición de BLAST y que en cambio se pueden alinear bien insertando espacios y usando matrices de substitución. Por “suficiente longuitud” de las subcadenas idénticas se entiende aquella que hace poco probable que la coincidencia sea casual. Como hay 4 bases A,T,C,G entonces la probabilidad de que dos nucleótidos cualesquiera sean iguales por casualidad es del 25%. Por eso, para el ADN, se suelen tomar subcadenas de longuitud a partir de 11. O al menos así era en las primeras versiones de BLAST, porque comparando los candidatos que devolvía BLAST con los mejores alineamientos locales hallados mediante Smith-Waterman se comprobó que una opción mejor era acortar las subcadenas con la condición adicional del que se pudieran encontrar muchas de ellas próximas las unas a las otras. No voy a detallar aquí las razones estadísticas por las cuales BLAST selecciona secuencias candidatas a ser similares a una secuencia dada, dejémoslo en que para la secuencia buscada BLAST proporciona una lista de resultados ordenados por puntuación P y, además de P, BLAST proporciona otro valor llamado E que indica la probabilidad de encontrar la misma o mayor cantidad de resultados con puntuación P para la secuencia buscada si la base de datos estuviese compuesta de secuencias puramente aleatorias.

Bases de datos de ADN y proteinas

Cuando se secuencia una nueva cadena de ADN, se compara mediante alineamiento con otras secuencias conocidas y se añaden anotaciones que señalan la localización de los genes y el resto de regiones que controlan lo que hacen los genes: dónde empiezan y terminan intrones y exones, secuencias reguladoras, repeticiones, función biológica, expresión etc. Existen herramientas para anotar automáticamente que suelen usarse en combinación con anotaciones realizadas manualmente.

El resultado de la secuenciación, alineamiento y anotación se almacena en una base de datos. Existen bastantes bases de datos públicas y privadas. Sólo en Wikipedia puede encontrarse una lista con 180 bases de datos de ADN y proteínas. La más popular es la International Nucleotide Sequence Database (INSD) que agrupa la japonesa DNA Data Bank of Japan, la norteamericana GenBank y la europea EMBL-EBI. Existen también bases de datos específicas de genes que causan enfermedades y bases de datos de expresión genética.

Software disponible

Hitóricamente, el lenguaje de referencia para aplicaciones de bioinformática era Perl, aunque con el paso de los años han ido apareciendo herramientas en otros lenguajes como Java, R y Python. EMBOSS, posiblemente la herramienta más popular para realizar alineamiento de secuencias está escrito principalmente en C. Incluso hay una distro de Ubuntu llamada Bio-Linux que contiene más de 250 programas libres para bioinformática.

Lo típico es usar una base de datos de secuencias basada en BLAST como la del EMBL-EBI, un analizador-ensambldor como EMBOSS o Staden, un programa de predicción de estructura protéica como THREADER o un programa de modelado molecular estilo RasMol.

Incluso Google ofrece su plataforma cloud con fines específicos de genómica computacional.

En general, la caja de herramientas del bioinformático contendrá más o menos lo siguiente:

• Análisis de secuencias, mutaciones, regiones, etc.
• Cálculo de similitud y homología de secuencias, ancestros, etc.
• Análisis estructural 2D/3D de proteínas.
• Análisis de función de proteínas (a partir de su estructura).

En Wikipedia se puede encontrar una lista de software Open Source para bioinformática. También existen listados de proveedores de software y servicios de genómica computacional y listados de las principales empesas de bioinformática.

Hardware de propósito específico

El tratamiento informatizado de la información genética es un desafío complejo que tiende a alcanzar los límites del hardware actual, tanto en uso de CPU como en consumo de memoria y capacidad de almacenamiento. Prácticamente desde que se inventaron las FPGA (Field Programmable Gate Array) hace treinta años, se sabe que pueden usarse en lugar de CPUs para acelerar la ejecución de algoritmos de alineamiento de secuencias. La clave es que el algoritmo de Smith-Waterman se puede paralelizar parcialmente y, además, sólo requiere aritmética de 24 bits. Entender cómo se consigue acelerar la ejecución mediante el paralelismo requeriría entrar en los detalles del algoritmo, cosa que no hemos hecho, por consiguiente el lector interesado puede referirse a artículos como éste.

La empresaa pionera en hardware específico para el alineamiento de secuencias es Timelogic, fundada en 1981 y adquirida en 2003 por Active Motif. Luego se sumaron otras como SGI y, porsupuesto, los fabricantes de hardware de toda la vida con las mismas máquinas pero con una etiqueta nueva que pone «cluster de bioinformática».

Retos actuales

Es dificil enumerar los retos en un área como la genómica computacional donde todavía está prácticamente todo por hacer. Actualmente es posible secuenciar ADN de forma económicamente viable pero en el ensamblado de las lecturas cortas producidas por los secuenciadores como Illumina todavía existen problemas abiertos relacionados con las repeticiones y la fase.

Analizar el amplísimo rango de fenotipos con la limitada base de la información disponible sobre el genoma humano es otro desafío.

El entendimiento de cómo funcionan las secciones reguladoras es aún escasísimo.

Y existen innumerables problemas técnicos que no tienen que ver con el tratamiento informatizado sino con el hecho de que el ADN funciona a nivel molecular y, por consiguiente, es demasiado pequeño cómo para poderlo manipular directamente.

Todo ello no menoscaba el potencial de la bioinformática, pues simplemente estamos en los albores de un salto cuántico hacia adelante en nuestro entendimiento sobre cómo funciona la vida.

Publicado en Genómica, Tecnologías Emergentes | Deja un comentario

El Quejido Nacional

Publicado el 6 de diciembre de 2016 por Sergio Montoro

Queja Fué en una inspiradora charla de José María Gasalla organizada por un ex-presidente de EO-Madrid donde escuché la expresión del “quejido nacional” para referirse a esa gente (o así lo interpreté yo) que es demasiado perezosa como para ser feliz.

Gracias a mi profesión, he tenido la suerte de conocer a muchas personas capaces y exitosas. Les he visto protagonizar eventos estelares y también pasar las de Caín. Les he visto llorar de desesperación, les he visto hacer cosas que no puedo poner por escrito, pero nunca, ni una sola vez, a ninguno de ellos, le oí lamentarse de su (mala) suerte o de la dureza de su entorno.

Este es un artículo de opinión. Normalmente evito opinar en público, porque las opiniones son como los culos: todo el mundo tiene uno. Haré una excepción puntual con el quejido, por si alguien se aburre con el café y no le apetece uno de mis artículos técnicamente espesos.

El origen del quejido

El origen del quejido es gente que crece dando por sentado que el estado de ~~bienestar~~ beneficencia que les rodea es el orden natural y espontáneo de las cosas. Es gente que piensa que no hay basura en las calles porque nadie la tira o que el césped de los parques está despejado en invierno porque las hojas otoñales se evaporan. Mariano Rajoy, dos veces presidente de España, dijo una vez en un mítin que “esto no es como el agua que cae del cielo sin que se sepa exactamente por qué”. En los países desarrollados hay tantas cosas que caen del cielo que la gente ya no sabe ni de dónde vienen.

Entonces se producen dos fenómenos: primero, la privación –aunque sea momentánea– de los privilegios artificiales provoca una indignación inmediata; y segundo –aún peor– se piensa que aquellos que carecen de los privilegios debe ser porque algo muy malo habrán hecho para merecer semejante infortunio.

Atajos mentales

Hace ya algunos años, pedí la baja voluntaria de un buen empleo para dedicarme a otras aspiraciones vitales. Se trataba de un buen puesto, de esos con buena paga, una mesa frente a la ventana y una plaza de aparcamiento reservada. Antes de irme le sugerí a la persona más próxima a mi en competencias que quizá debiera postularse para el cargo. “No me lo han ofrecido” me espetó con seridad. Casi me parto de la risa en ese mismo momento “¿Ofrecérselo?” (pensé). Sencillamente era más fácil quejarse de lo que no estaba haciendo su jefe que currarse el ascenso ¿verdad?

Por bien fundamentadas razones, el cerebro siempre intenta hacerlo todo con el mínimo esfuerzo. O debería intentarlo porque también hay gente empeñada en hacerlo siempre todo del modo más difícil. Pero las razones para hacerlo todo de la forma más difícil serían otra larga historia. En la mayoria de los casos prevalece la pereza. Entonces es más fácil pedir (exigir) que hacer.

La imputación de responsabilidad, o abuso, a un tercero puede proporcionarnos un alivo temporal a una situación de stress, pero constituye una práctica muy peligrosa debido a que por efectos neuroplásticos las sinapsis que se activan juntas tienden a unirse. Entonces la queja crea un hábito y ya no sabemos hacer ninguna otra cosa que quejarnos. Peor aún, la repetición del mantra quejica crea un sesgo de confirmación por el cual acabamos creyendo ciegamente en nuestras opiniones negativas a medida que nos obsesionamos más y más con ellas hasta que acabamos pensando que el Universo conspira contra nosotros, esta Teoría del Universo Contra Ti la explica de una forma muy divertida Emilio Duró.

La quejumbrera crónica tampoco es nada buena para hacer amigos, ya que es poco probable que las mismas personas a quienes se critica estén muy predispuestas a ayudar. La queja nos desposee de empatía al negarnos a especular sobre por qué algunas personas nos defraudaron. La queja indignada nos impide perdonar y entender, y a la postre el quejica acaba rodeado sólo de personas que son realmente tan deplorables como él piensa, porque la gente mentalmente saludable se harta de tanta negatividad y se aleja.

La queja sistemática nos ancla en el pasado y en las razones por las que no podemos hacer algo. Nadie triunfa mirando atrás y exigiéndole a los demás que hagan (o dejen de hacer) algo.

En definitiva, la queja es lo peor, tan mala que hay hasta gente que escribe artículos en blogs quejándose de los que se quejan.

Post relacionado: Cómo evitar arruinarlo todo con violencia verbal.

Publicado en Mitos, arquetipos y filosofía, Off-topic | Deja un comentario

Cosas a tener en cuenta a la hora de incorporar a un socio director

Publicado el 5 de diciembre de 2016 por Sergio Montoro

Por gusto o necesidad, un cambio que prácticamente todos los emprendedores de éxito tienen que abordar en algún momento es la incorporación de un socio director. Puede que sea por el deseo de tener una ocupación vital diferente de ejercer un determinado cargo ejecutivo, porque lo impongan los inversores o porque la jubilación forzosa haga perentorio un plan de sucesión.
Reemplazar a un socio fundador en el puesto de director general no es fácil, la historia de las empresas está plagada de errores garrafales en la elección de un capitán general. Hace algunas semanas hablaba con un viejo amigo emprendedor en la situación de buscar a alguien que ocupe su cargo, lo que sigue es la transcripción de la conversación sobre nuestras ideas y peripecias reclutando a un sucesor.

Esencialmente el desafío tiene tres partes: 1ª) cómo encontrar al candidato adecuado, 2ª) qué funciones otorgarle, 3ª) cómo motivarle y retribuirle.

Fuentes de candidatos

El proceso de encontrar y contratar a un director general es largo. Normalmente no debería asignarse un plazo inferior a un año para la misión. Existen básicamente tres posibilidades: 1ª) promocionar alguien de la plantilla, 2ª) contratar a alguien de la plantilla de otra empresa y 3ª) apostar por un candidato experimentado pero independiente.

De estas tres opciones, la tercera es la que yo personalmente elegiría en el caso de ser posible. La razón principal es que las habilidades necesarias para medrar entre los directores de división y los miembros del consejo son, en general, diferentes de las necesarias para liderar una empresa. Los directores de división ascienden generando eficiencias en los procesos. Los miembros del consejo se mantienen en el cargo porque representan los intereses de algunos accionistas. Los ejecutivos y consejeros no necesitan ser líderes visionarios ni carismáticos para trepar. Es posible que bajo el mando de un ejecutivo de larga carrera en la casa la empresa aumente espectacularmente su beneficio, porque es gente que conoce detalles operativos del negocio que el fundador no tuvo tiempo de analizar o nunca quiso tener en cuenta. Pero rara vez estos ejecutivos asalariados consiguen crear en la empresa una dinámica de conquista de nuevos mercados y oportunidades. En algunas ocasiones el jaleo interno que existe en la empresa justo antes de que dimita el fundador-director es tan grande que sólo alguien que conozca bien los entresijos y cuente con apoyos puede conseguir poner un poco de orden.

No menos prudente hay que ser con los «paracaidistas». Especialmente con aquellos que alardean de sus excelentes contactos en el sector (que casi nunca son tan buenos) y con los que no tienen ningún pudor en mentir de forma descarada en su currículum apuntándose sin rubor méritos que jamás obtuvieron y competencias que no tienen.

En el caso de ser posible, mi candidato favorito sería un “entrepreneur in residence”, un emprendedor que dejó de serlo porque vendió su empresa, porque quebró o porque tenía otras aspiraciones vitales.

A veces los candidatos provienen de empresas de consultoría externa y empezaron como asesores del consejo haciendo PowerPoints. Algunos de estos consultores pueden llegar a ser muy brillantes. Aunque hay que tener en cuenta que el trabajo de consultoria es diferente del ejecutivo, por eso probablemente Peter Drucker jamás dirigió una empresa.

Por último, es posible recurrir a un head hunter, a lo cual yo personalmente sólo recurriría en el caso de que no pudiese escoger ninguna de las opciones anteriores. Las razones son que un director general requiere una confianza que es imposible de crear en sólo unas pocas semanas o meses. Nunca hay que cambiar a los viejos amigos por nuevos amigos. Esto se puede comprobar en muchísimos ejemplos de organizaciones donde se eligió al candidato de más antiguedad aunque menos competente en lugar de al candidato más competente pero con menos lazos históricos. Los políticos llevan esto al extremo reclutando en ocasiones a sus compañeros del colegio para cargos de alto funcionario. La otra razón para no delegar el proceso en un head hunter es que el head hunter (diga lo que diga) tiene su propia agenda y sus propios intereses, que son básicamente colocar al candidato más rentable (para él) en el menor tiempo posible.

Esquema retributivo

Cuando se negocia la retribución con alguien que no es emprendedor vocacional, prácticamente todos los candidatos quieren lo mismo: un gran salario y participaciones en la empresa, además de lo cual a veces piden otras cosas adicionales como coche de empresa, un despacho de no menos de X metros cuadrados, volar en business, etc.

A mi personalmente me parece injusto que una persona tenga todas las ventajas de un asalariado y todas las ventajas de un emprendedor, sin ninguna de las desventajas de ambos. La solución de compromiso suele se casi siempre un plan de opciones sobre acciones (stock options). El candidato vendrá y pedirá, de saque, tener al menos el 20% de la empresa. Esto nunca hay que otorgárselo por las buenas pues en caso de hacerlo ¿por qué habría el nuevo socio de trabajar nunca más en la compañía? A partir del primer día podría simplemente sentarse a esperar que su 20% de participación le reporte beneficios mientras él juega al golf y otros trabajan.

Lo habitual suele ser un plan de opciones sobre acciones a cinco años. Si el objetivo es que el socio director acabe con un 20% de la empresa, entonces se le otorgará un derecho de compra del 4% anual mas o menos con la siguientes condiciones:

1ª) Se hará una valoración de la empresa en el momento de la incorporación del socio de la cual saldrá un precio por acción. El nuevo socio adquirirá un derecho anual de compra de acciones con un precio relacionado con el que tuvieran las acciones en el momento de la incorporación del socio a la empresa.

2ª) Cada doce meses el socio podrá comprar el porcentaje anual de acciones por el precio pactado. Desde la fecha de entrada en vigor del derecho hasta su ejecución, el socio tendrá un plazo de seis meses para desembolsar el precio de las acciones. En caso de no comprar las acciones durante esos seis meses perderá el derecho de adquirirlas.

3ª) El socio tendrá un periodo de “lock-up” mínimo de un año desde la adquisición de cada lote durante el cual no podrá venderle a nadie las acciones recién adquiridas (excepto a la propia empresa de mutuo acuerdo).

4ª) Transcurrido el lock-up, el socio podrá vender sus acciones libremente pero estará obligado a vendérselas a los otros socios o a la empresa en el caso de que estos presenten una oferta igual a la de un tercero.

5ª) Si el socio causa baja voluntaria en la empresa entonces perderá todos los derechos de adquisición de más acciones.

6ª) Si el socio es despedido podrá conservar los derechos de adquisición del siguiente lote anual de acciones.

7ª) (Opcional) Los socios fundadores tendrán derecho de arrastre, en el caso de que decidan vender la empresa a un tercero, el socio director contratado podrá ser obligado a vender también sus acciones a ese tercero. Esta cláusula se suele acompañar de otra que establece que la venta nunca podrá forzarse por menos de cierta cantidad por acción o que, si se fuerza, el vendedor recibirá una compensación adicional por otra vía (ratchet).

8ª) El adquiriente se compromete a no usar las acciones como garantía real de ninguna operación crediticia personal. Esta cláusula es cuestionable desde el punto de via jurídico además de ser difícil de ejecutar en la práctica, pero yo la he visto por escrito en contratos.

9ª) El cónyuge, caso de existir, renunciará a los derechos sobre las acciones en caso de divorcio. Esta es otra cláusula cuestionable. Su razón de ser es impedir que de la noche a la mañana se presente un esposo/a divorciada en el consejo de administración. Pero existe un principio de derecho que establece que uno no puede renunciar a aquello que no conoce. Por consiguiente, aunque el cónyuge hubiera renunciado a sus derechos sobre las acciones podría alegar que en el momento de la renuncia desconocía el valor que las mismas podían llegar a tener y que en el caso de haberlo sabido no habría renunciado.

10ª) Si la empresa realiza una ampliación de capital entonces todos los socios podrán entrar en ella de forma que mantengan su porcentaje de participación, pero deberán pagar las nuevas acciones al precio actual y no al precio que tengan garantizado para sus opciones. En el caso de que no acudan a la ampliación de capital sufrirán una dilución de su participación. En ningún caso los socios podrán vetar una ampliación de capital.

11ª) Los dividendos se repartirán según decida el consejo de administración. Normalmente de forma proporcional a la participación de cada socio, aunque es ocasiones es posible aprobar una retribución adicional para socios que trabajan versus socios que sólo participan financieramente.

12ª) Cuanto más detallado sea el plan de salida y más opciones contemple, mejor. Una de las cosas que suele omitir el pacto de socios es, precisamente, cómo se cambiará el pacto de socios. Muchas empresas se crean para venderlas, otras pueden ser adquiridas por sus directivos o por un inversor externo en una compra apalancada. Unas pocas salen a bolsa. Sea cual sea el desenlace, si está previsto de antemano mejor que mejor.

Por último, en España, es menester tener en cuenta el umbral mínimo del 5% de participación para tener algún poder real en un consejo de administración. Es decir, cualquiera que aspire a poder pedir cuentas a sus socios nunca debe quedarse por debajo del 5% de participación.

Psicología de la relación con el socio

Todos los socios buscan en último término algo. Algunos están orientados al logro. Otros quieren comprarse una casa más grande para que su mujer acceda a intentar tener un tercer bebé que esta vez sea varón. Otros quieren impresionar a sus viejos amigos del colegio con un gran despacho. O demostrarle al mundo que las faldas pueden más que los pantalones. O mudarse a Bali y vivir de rentas. Cada socio quiere algo. Entender esta motivación es crucial para evitar disfuncionalidades en la dirección de la empresa. Para esto es necesario conocer no sólo al socio sino a todo su sistema familiar y social.

Publicado en Emprendizaje | Deja un comentario

Cómo seleccionar una plataforma de desarrollo para un proyecto web II

Publicado el 30 de septiembre de 2016 por Sergio Montoro

Este artículo es una actualización de otro anterior publicado en 2013 sobre Java/Tomcat, PHP/Zend, Python/Django y C#/IIS.

Desde 2013 dos plataformas, Play y Node.js, han aumentado con fuerza su popularidad entre los desarrolladores debido a las siguientes tendencias en el diseño de aplicaciones web.

1ª) Crecimiento de la base de usuarios de los lenguajes utilizados. JavaScript en el caso de Node.js y Scala en el caso de Play. Sumado a una tendencia generalizada hacia un estilo de programación más funcional.

2ª) Obsesión por las llamadas no bloqueantes. El «problema» de diseño de la mayoría de los servidores web es que usan un hilo de ejecución (thread) por conexión. Esto en la práctica limita el número de conexiones concurrentes por máquina a algo entre 200 y 400 antes de que la sobrecarga debida al cambio de contexto entre hilos empiece a perjudicar el rendimiento del servidor. El maximizar la cantidad de conexiones concurrentes sin degradar el rendimiento siempre ha sido un desafío técnico en los sitios web pero la necesidad se ha vuelto mucho más acuciante desde que se pusieron de moda las páginas web que cargan contenidos dinámicamente de forma constante mediante llamadas AJAX o requieren de actualizaciones frecuentes de datos desde el servidor. En Java, desde la especificación de servlets versión 3.0 (creo) es posible crear servlets asíncronos pero es bastante complicado. Además, JDBC es un API síncrono lo cual dificulta el desarrollo de servlets asíncronos.

3ª) Renderizado en el cliente. Otra moda encabezada por toolkits como Angular JS y React JS es pedir datos en formato JSON al servidor y renderizar la página en el cliente mediante JavaScript en lugar de pedir una página ya renderizada. Si bien se puede argüir que trasladar el trabajo de renderización al cliente reduce la carga en el servidor, yo personalmente estoy en contra de hacer sitios web que sólo muestren algo decente si JavaScript está activado en el navegador. Para renderizar en el cliente la verdad es que no entiendo muy bien por qué los fabricantes de navegadores nunca soportaron XSLT decentemente. Supongo que XSLT es simplemente demasiado complejo para el programador promedio y por eso nunca dejó de ser una tecnología de nicho.

4ª) Escalabilidad horizontal. Es decir, la capacidad para poner con facilidad un servidor web al lado operando en paralelo. La mayor dificultad para esto es cómo traspasar el estado de un servidor a otro en el caso de que el balanceador de carga mande a la misma sesión del cliente de un servidor a otro. La solución, tanto de Node.js como de Play, es simplemente crear servidores sin estado. O dicho de otra forma, trasladar el problema de mantener el estado del cliente a otra parte que no sea el servidor web. Lo cual es una solución o simplemente mover el problema de un lado a otro según sea la implementación. Aunque tanto Node.js como Play traen servidores web propios, ambos están diseñados (desde mi punto de vista) para ser utilizados con un proxy inverso (normalmente Nginx).

5ª) APIs REST y microservicios.

Node.js

Node.js es una plataforma basada en el ejecutor de JavaScript Chrome V8 de Google. Creada en 2009, su popularidad se ha disparado en los últimos tres años. Antes de escribir sobre Node.js he de avisar que yo no tengo una opinión imparcial. Creo que no se debería usar JavaScript en el lado del servidor y Node.js me retrotrae psicológicamente a la era de Netscape Enterprise Server veinte años atrás. Dicho lo cual, pasemos a comentar las ventajas de Node.js. La primera de ellas es que es muy fácil empezar a usar Node.js. Un factor crítico para la adopción rápida de una plataforma es que el tiempo requerido para llegar al “Hola Mundo!” no supere los veinte minutos y en esto Noode.js cumple con creces. Si sabes JavaScript y quieres conseguir resultados rápidos, entonces Node.js es tu plataforma. Además, presuntamente Node.js soluciona el Problema C10K mediante entrada/salida no bloqueante y el compilador Just In Time (JIT) de Google que ejecuta JavaScript más rápido que nadie o, al menos, más rápido que Rhino y tan rápido como el HHVM de PHP. El repositorio de paquetes npm (estándar para Node.js) es apabullante (unos 88.000). Y Node.js eclipsa a cualquier otra plataforma en el desarrollo de microservicios sobre HTTP.

Hasta aquí las buenass noticias. Ahora las malas. Para empezar, el bucle principal de Node.js es un único hilo de ejecución que lanza hilos de un pool. En la práctica esto implica que: a) es facilísimo bloquear un servidor Node.js con una única llamada a algo que deje el bucle principal tostado y b) como corolario de lo anterior, si tienes una máquina con cuatro CPUs probablemente estarás mejor con cuatro servidores de Node.js arrancados en ella.

El modelo de concurrencia de Node.js está basado en callbacks. Esto consiste en que cada vez que se hace una llamada asíncrona se se proporciona una función a la cual la subrutina debe llamar cuando termine. La razón de esto es usar un lenguaje inherentemente síncrono (JavaScript) para tareas asíncronas. Lo cual provoca un fenómeno conocido como callback hell.

La siguiente trampa llega a la hora del mantenimiento. Yo creo que nunca se debería usar un lenguaje con tipado dinámico para un proyecto que involucre a más de cinco desarrolladores quienes, además, sean absolutamente fanáticos de TDD. Esto incluye JavaScript y Python. El motivo es que cada vez que cambias el interfaz de una clase o los parámetros de una función en una librería escrita en un lenguaje de tipado dinámico no existe una forma fácil y fiable de saber a cuántas subrutinas cliente de la librería estás afectando y cómo.

Por último, existe un serio problema de seguridad permamente con JavaScript en el lado del servidor.

Mi conclusión es que Node.js es adecuado cuando el objetivo es crear rápidamente un proyecto que nunca crecerá por encima de un determinado umbral de trafico y desarrolladores pero no recomendaría su elección para proyectos con altos requerimientos de crecimiento en líneas de código.

> Play

Play, desde mi punto de vista, es la versión Java de Django. Opino que es la mejor plataforma para proyectos ambiciosos que no deseen pagar la bajada de bandera de Java/Tomcat/Spring. Al igual que con Node.js, empezaré enumerando las ventajas y luego las desventajas. Lo primero que se agradece en Play es que se trata de un intento de entregar un entorno MVC verdaderamente “full-stack” desde el HTML, CSS y JavaScript o CoffeeScript del lado cliente hasta los controladores y el modelo del lado servidor escritos en Java o Scala. Aunque Scala está todavía muy por detrás de JavaScript en cuanto a comunidad de usuarios, mi opinión es que Scala es claramente superior a JavaScript como lenguaje para el desarrollo de aplicaciones de alta escalabilidad/fiabilidad.

Como ya he comentado, el diseño conceptual de Play se parece al de Django: el asistente de creación de proyecto proporciona una estructura predefinida de aproximadamente unos 35 archivos (mucho más compleja que la estructura por defecto de Node.js). La idea es que el desarrollador tenga una manera por defecto defecto de hacer todo: plantillas HTML, persistencia en SGBDR, etc. Pero que pueda cambiar este comportamiento según le convenga.

El modelo de programación asíncrona de Play también es mejor que el de Node.js Al estar basado en Java, Play está supeditado a que el API de JDBC que es síncrono, pero por encima de él es posible utilizar Akka o ReactiveX. Además de que está disponible el API NIO de Java para acceso a archivos.

Play proporciona recompilado en caliente de páginas y clases como Django y Node.js. Algo muy fastidioso en Tomcat es que en un momento dado sus creadores decidieron que la forma correcta de desplegar aplicaciones debía ser mediante un WAR que no es ni más ni menos que un archivo ZIP que contiene toda la aplicación. Los WARs son justo lo contrario de los cambios incrementales deseables en un sistema con integración contínua y, además, requieren de re-arrancar el servidor para que se apliquen los cambios. Y este tiempo de re-arranque de todo el servidor es verdaderamente mortal para los cambios continuos durante el desarrollo. Existen soluciones a este problema como JRebel o DCEVM pero JRebel es de pago y DCEVM es Open Source pero bastante difícil de configurar.

Para la instalación de paquetes Play usa SBT y la cantidad de paquetes disponibles por defecto es algo así como 80. Pero Play puede hacer uso del repositorio de Maven donde hay más de 80.000 paquetes adicionales.

Ahora las malas noticias. Definitivamente no es buena idea intentar usar Play para obtener resultados rápidos a menos que se tenga una buena idea previa de Scala, y Scala no es fácil de aprender. Otro aspecto negativo es que históricamente las versiones de Play han tenido tendencia a romper la compatibilidad hacia atrás. Aunque gracias al tipado estático el problema es mucho más manejable con con Node.js cuando cambia una librería JavaScript. El compilador de Scala tiene fama de ser lento pero Play soporta compilación incremental además es probable que la velocidad se mejore en el futuro cuando se popularice Dotty como el nuevo compilador de Scala.

Mi impresión general es que Play constituye un paso adelande de Apache/PHP, Tomcat/Java e IIS/C# como la opción más moderna para aplicaciones web de tamaño mediano y grande.

Post relacionado:
Cómo seleccionar una plataforma de desarrollo para un proyecto web.

Publicado en Tecnologías Emergentes, Tecnologías Libres | Deja un comentario