Muerte por agilismo

He perdido la cuenta de la cantidad de empresas que he visitado las cuales, pretendiendo hacer Agile a ultranza, se enfrentan a serios problemas de retrasos en los plazos y falta de calidad en los entregables. La justificación siempre es la misma: que el problema no es Agile sino que no están haciendo Agile bien. Que el problema es que no cierran una release verdaderamente estable en cada sprint o que la descripción de cada tarea en JIRA cabría perfectamente en un tweet, o que los tests son insuficientes, o cualquier otra excusa justificando la disfuncionalidad en base a una falta de ortodoxia. Pero es falsa la creencia extendida de que más Agile arreglará los problemas de una empresa con dificultades para producir versiones estables dentro de los plazos estipulados. A renglón seguido contaré la historia que nos ha traído a la situación actual. Me ha quedado un post algo largo, pero prometo al lector paciente que es todo “lean”, sin circunloquios ni banalidades.

Agile nace gestado por la Primera Burbuja Punto.com

Agile nació poco después de que creciese la Primera Burbuja Punto.com. Agile apareció como una metodología para que las consultoras pudiesen gestionar de alguna forma su relación con clientes que no sabían exactamente lo que querían. Agile no se inventó durante la década de los sesenta para el Programa Apolo porque la misión era poner a un hombre en la Luna antes del 1 de enero de 1970. No necesitaban una sucesión de lanzamientos con mejora contínua de los resultados. Sí necesitaban, en cambio, nuevas herramientas como IBM IMS para gestionar el inventario del Saturno V o las metodologías estilo Waterfall de los 70 que siguieron vigentes durante muchos años tras su invención. Pero en el año 2000, con clientes que no sabían ni a qué planeta querían llegar o, peor aún, cambiaban el planeta de destino según avanzaba el proyecto, era muy difícil hacer un inventario de necesidades y presupuestarlas. Entonces se inventó algo para facturar al cliente no una cantidad fija por proyecto cerrado sino por “time & materials” (horas/hombre y cualquier otro coste imputable) sin límite presupuestario. Obviamente, si el cliente pagaba por horas en lugar de por resultados era necesario demostrarle que los programadores estaban trabajando de la forma más eficiente posible. Y de ahí surgieron todas las prácticas ágiles para optimizar la productividad de los programadores exprimiéndoles como cítricos.

Agile emigra a las grandes corporaciones

Aproximadamente un lustro después de que las consultoras introdujesen Agile, los gestores de proyectos de los clientes empezaron a pensar que si la metodología funcionaba tan estupendamente para las consultoras entonces funcionaria igualmente bien para los proyectos internos de la compañía. Como las grandes empresas cambian despacio, les llevó aproximadamente otros cinco años, hasta 2010, entrar de lleno en la cruzada por el agilismo.

Fué en este momento cuando se empezó a complicar la cosa. No es lo mismo hacer un proyecto táctico para un departamento de una gran corporación que un megaproyecto de transformación empresarial de gran calado. Las consultoras web muy a menudo trabajaban para directores de desarrollo de negocio que estaban frustrados con la lentitud de su servicio de informática interno respecto de la velocidad que había tomado el mercado. Querían soluciones rápidas de negocio, y no les importaba si estaban bien o mal integradas con el resto de los sistemas de la casa. Sólo buscaban correr para no perder el tren de Internet. Agile primaba la entrega sobre la calidad, porque la consultora tenía un tiempo de vida limitado para conseguir algún éxito rápido antes de que les cancelasen el proyecto o fuese absorbido por el departamento de informática del cliente. Pero a un mando intermedio de una gran empresa casi nunca le conviene priorizar la entrega sobre la calidad por dos motivos: a) vive permamentemente en competencia por el ascenso con otros mandos quienes están siempre pendientes para descubrir dónde se ha equivocado; y b) a las empresas les cuesta tanto cambiar organizativamente que la velocidad de desarrollo no es casi nunca un cuello de botella. Es más, el tiempo de codificación sólo supone, como mucho, el 30% o el 40% del tiempo de trabajo de un programador. Al obcecarse con reducir el tiempo de programación se optimiza sólo el 30% del tiempo y no se hace nada respecto del otro 70%. Entonces, el cliente puede acabar pagando “time & materials” de programadores quienes, siendo muy eficientes en su labor, pasan no obstante una fracción significativa de su tiempo esperando.

Se eliminan los gestores de cuenta

Los vendedores y gestores de cuenta en las consultoras provocaban con frecuencia el siguiente problema serio: en un caza de combate el piloto puede normalmente hacer sólo tres o cuatro maniobras de alta velocidad antes de agotar su reserva de combustible y tener que volver a la base. Análogamente, los gestores de cuenta tenían tendencia a pulsar el botón que activaba la postcombustión cada vez que se veían al borde de ganar o perder una cuenta porque les faltaba esta o aquella funcionalidad en el producto. Esto dejaba a los programadores quemados y agotados y encima con frecuencia no servía para lograr los objetivos comerciales deseados. Tras una serie de motines de los programadores, la solución fue quitar el poder a los gestores de cuenta para dárselo a los programadores.

Se decidió que los programadores debían hablar directamente con los clientes, ya que los gestores de cuenta entendían y trasladaban mal los requisitos. Y que los programadores debían auto-organizarse fijando sus propios objetivos y estimaciones. ¡Bien! ¡Poder para el pueblo!

Se decidió también que los programadores podían programar y reunirse con los clientes al mismo tiempo. De todas formas si no se reunían con el cliente se tenían que reunir con el gestor de cuenta lo cual es casi lo mismo ¿no?

De nuevo, esto funcionó bien para las consultoras. Más horas hablando con el cliente estrechaban el vínculo emocional con él y proporcionaban más información a la consultora para hacer venta cruzada.

Pero ¿qué pasó en los grupos de trabajo de los clientes? Bien. Lo que sucedió fué básicamente que Agile tomó el control estratégico de la empresa. En lugar de un equipo directivo fijando la visión y misión y un equipo operativo tratando de ponerla en práctica, la empresa pasó a estar gobernada por un grupo de ejecutivos desvalidos que mendigaban al cognitariado agilista si era posible hacer esto o aquello. Cualquier intento de dirigir la empresa fuera de los límites de Agile era vaticinado como una hecatombe segura por el Oráculo Agile. Y así Agile pasó a convertirse en una cuestión de fé.

Respecto de la comunicación, si las empresas ya estaban saturadas de reuniones, Agile potenció todavía más reuniones. Y además introdujo la idea de que los usuarios pueden (y deben) crear las historias “de usuario”. El problema es que los usuarios carecen normalmente de formación en diseño estructurado de sistemas y, por consiguiente, no pueden crear una especificación de calidad porque nadie les ha enseñado cómo hacerlo. Tienen un conocimiento experto de su negocio, pero necesitan coaching de un analista-programador para plasmar dicho conocimiento en un papel.

Se veta a los senior

Una consultora obtiene beneficios de la diferencia entre lo que le cobra al cliente y lo que le paga a sus empleados. Por consiguiente, una consultora rentable es, por definición, una horda de juniors. No todas las consultoras son así, por supuesto, algunas son boutiques de un puñado de verdaderos expertos, pero si la consultora tiene más de 10 empleados entonces el 80% de ellos son junior porque las consultoras existen tanto para hacer lo que el cliente no sabe hacer como para que éste les lance toda la basura que no quiere procesar.

Los senior tienen mala cabida en una metodología Agile. No da tiempo en un único sprint de producir un buen análisis o una arquitectura de software para un proyecto complejo. Además, la presión constante por alcanzar el sprint abona el terreno a peligrosísimos errores de diseño. Agile microgestiona a los senior obligándoles a acudir a reuniones diarias de control. Y es fácil eliminar miembros de alto potencial identificándoles falsamente como de bajo rendimiento simplemente porque no siguen a pies juntillas los sprints por absurdos que estos sean.

Un cliente con sistemas de información complejos quiere personal senior entre sus empleados. Quiere arquitectos capaces de aprehender todas las interacciones sutiles entre una miriada de sistemas de información y de adquirir una visión holística desde el alto nivel de las necesidades de negocio hasta los detalles de la electrónica de red. Esto simplemente no casa con Agile.

Se introducen métricas envenenadas

Junto con Agile, se introdujeron ciertas “prácticas Agile”. Algunas ya existían previamente con otro nombre, estilo las retrospectivas antaño conocidas como post-mortems, excepto que el nombre era muy tétrico y por eso se cambió y se le añadieron al método algunas viñetas graciosamente elocuentes.

Algunas prácticas fueron definitivamente un avance: Domain Driven Design, Integración Contínua, Refactorización, etc. Otras introdujeron caballos de Troya.

El primer troyano fueron las Historias de Usuario. En la época del diseño estructurado se abogaba por estimar el esfuerzo requerido usando métricas como los Puntos Función o la Complejidad Ciclométrica. Los puntos función, básicamente, consistían en medir la complejidad de los datos de entrada y los datos de salida y estimar que el esfuerzo requerido para desarrollar un programa sería proporcional a la complejidad requerida para manipular los datos. Algunas empresas como IBM llegaron a poder producir estimaciones muy fiables para determinado tipo de proyectos con estas métricas. Pero en las Historias de Usuario no se trataba tanto de estimar el esfuerzo requerido como el valor que aportaría al cliente la funcionalidad. Esto era debido a que la consultora estaba interesada en cobrarle al cliente no por su coste de producción más un márgen sino por el valor añadido. Hablando de valor y no de coste se evitaba que el cliente dejase a la consultora cobrando “time & materials” más un 15%. Pero en los proyectos internos en grandes empresas el valor que añade cada funcionalidad es mucho menos relevante puesto que las grandes empresas casi siempre operan en oligopolios que pueden repercutir sus sobrecostes a los clientes. Lo que sí es crucial es saber cuándo estará terminado y qué hará, debido a que puede que se avecine una campaña de Navidad o una salida a bolsa. Pero ese ¿cuándo? y ¿qué? es justamente lo que NO garantiza Agile. En cambio, la sucesión interminable de releases incompletas lo que acaba generando es una profunda desazón en los usuarios y patrocinadores quienes empiezan a tener la sensación de que el proyecto no estará terminado nunca.

El segundo troyano fue Test Driven Design (TDD). No es que TDD sea para nada malo en sí mismo. De hecho, ningún programador profesional hoy en día escribe código sin un juego de tests que lo acompañe y eso es por muy buenos motivos demasiado largos y técnicos para enumerarlos aquí. El problema de TDD fué que generó la idea de que el código estaba “listo” cuando estaba “listo para lanzárselo a control de calidad” como quien pasa una patata caliente. Si pasaba los tests entonces el código funcionaba, fin de la historia. La mil veces repetida excusa de los programadores “en mi PC funciona” pasó a ser “pasa los tests”. Gracias a la integración continua, todas las máquinas virtuales podían tener fácilmente la misma configuración, luego ya no sucedía que funcionase en una si y en otra no, pero pasar los tests no implicaba que el programa hiciese en absoluto lo que el cliente esperaba que hiciese, pues, cómo ya hemos explicado anteriormente, quién había redactado la historia de usuario no sabía explicar exactamente lo que necesitaba. De postre, los tests escritos por el programador nunca incluyen pruebas de carga, puesto que son muy tediosas de escribir y además bloquearían el sistema de integración continua. De modo que incluso si el software funciona en producción lo hace a la velocidad de un trasatlántico a pedales.

El tercer troyano fueron los Product Backlogs. Estos priorizaban la aceptación de cambios y el desarrollo sobre la planificación. La forma en la que un backlog fuera de control aniquila un proyecto la describí en otro post titulado lo que sucede cuando un software se convierte en un agujero negro, de modo que no voy a extenderme aquí sobre este punto.

Se arregla Agile con más Agile

Como corolario de todo lo anterior, la situación típica es una de las siguientes:

a) Si la empresa es pequeña, el CEO ha caído prisionero de los programadores. Cada vez que intenta pedir algo, los programadores le responden que debe conseguir más recursos, o más inversión ¡o traer menos clientes! porque no les da tiempo de atenderles.

b) Si la empresa es grande, hay una gran cantidad de proyectos bloqueados a la espera de que un tercero entregue algo. El proyecto avanza, pero lo hace a una velocidad exasperantemente lenta y no exenta de sobresaltos.

El diagnóstico siempre es invariablemente el mismo: no se está haciendo Agile correctamente. Pero ¿quién puede hacer Agile correctamente? y… ¿de qué manera? si ya se ha intentado todo y se han mantenido sempiternas reuniones.

Entonces ¿Cómo salvar el proyecto?

1. Se deja de esperar a que los usuarios produzcan ninguna especificación. En cambio, se asignan analistas para trabajar con ellos en la producción conjunta de especificaciones.

2. Cada sprint durará lo que tenga que durar. ¿Por qué dos o tres semanas? Tampoco seis meses, para evitar los sustos que daba Waterfall. Puede haber puntos de control intermedios, pero si se necesitan ocho semanas para producir algo estable, se necesitan ocho semanas, y no cuatro sprints de dos semanas.

3. Se resucitan los Gantt, si ¡horror! Se restituyen los análisis de caminos críticos que muestren quién está bloqueando a quien y dónde. Se instalan pantallas gigantes que muestren en tiempo real el grado de progreso del sprint, los retrasos acumulados, el estado de los tests de integración y la actividad de usuarios en producción.

4. Se para en seco la aceptación de nuevas funcionalidades hasta que se estabilicen por completo todas las que hay. Es decir, desde mañana y hasta nuevo aviso los cambios NO son bienvenidos en la planificación del proyecto.

5. La decisión sobre la fecha de release pasa al departamento de control de calidad. Será este, de común acuerdo con los usuarios, quien valide que el software producido cumple con los requisitos.

6. La misión de sprint es cumplir expectativas. Al cuerno con la verborrea sobre valor añadido al negocio o restricciones técnicas insalvables. No se acepta ninguna excusa técnica ni organizativa en el último minuto para justificar por qué el cliente no obtendrá lo que esperaba obtener.

7. Cada programador arregla los bugs que él mismo haya introducido. Además, no gozará de más tiempo sobre el que tuviera pre-asignado a sus tareas. El programador no sufrirá penalización salarial ni de carrera profesional por un bug, pero tendrá que arreglarlo haciendo horas extra no retribuidas.

8. Se diseñan informes que muestren claramente cuánto tiempo se está dedicando a : desarrollo, corrección de bugs, soporte a cliente y reuniones. En la contabilidad analítica se diferenciará claramente el coste de producción del coste de soporte.

9. Quedan abolidas las reuniones. En lugar de una metodología que fomente que la gente se reuna y hable con la mayor frecuencia posible, se intenta que los programadores tengan que ir al mínimo número de reuniones. Como máximo una por semana. No se puede ser creativo y explicar lo que se está haciendo al mismo tiempo. El daily se substituye por un chat online donde todos los programadores y gerentes puedan acceder de forma inmediata a cualquier otro miembro del equipo en caso de necesidad urgente.

10. Los programadores son obligados a documentar lo que están haciendo. Si bien no están obligados a estar cada dos por tres de pie en una sala, sí deben mantener actualizado un repositorio documental con el progreso y detalles de todo su trabajo ya que no existe tal cosa como el código autodocumentado. La herramienta puede ser JIRA, Redmine, un wiki o incluso un blog donde los programadores compartan sus progresos en lugar contarle a nadie lo que están haciendo o enviar un mail a una lista y crear un hilo interminable. Evitar las reuniones no implica desinformarse. El desafio es mantener a todo el mundo informado sin necesidad de mantenerlo permanentemente reunido.

11. Se añade una capa de metodología de optimización global sobre Agile.

12. Se decreta la Anarquía de los Programadores. Podrán reirse a carcajadas de una decisión. Podrán ser sorprendidos trabajando en cosas aparentemente no relacionadas en absoluto con el proyecto. Podrán soñar con dragones.

Posts relacionados:
Las zonas grises de Agile.
Cheat Sheet de marrones en un proyecto.

El oportunismo del agilismo (Luis Lobo).

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

Sobre la dinámica social en los sitios de dating

He estado tentado de titular este post cómo ligar en sitios de dating. Mucha gente busca una relación estable o casual. Pero a mi lo que me interesa es el uso social de la tecnología para conocer gente, concretamente del sexo opuesto en el caso de los sitios de dating.

Opinions on Online Dating 2005 vs 2013¿Funcionan realmente los sitios de dating? Bien, no existen pruebas científicas a favor o en contra. Yo creo que sí funcionan. La razón es que si no funcionasen entonces no habrían sobrevivido más de una década ya desde sus inicios. A principios de 2016 un 5% de los norteamericanos casados o en una relación estable reconocían haber conocido a su pareja online. Según PEW Research Centre el número de adultos usuarios de los sitios de dating se ha duplicado entre 2014 y 2016. El gráfico muestra cómo la opinión de los usuarios se ha vuelto más favorable de 2005 a 2013 Pero ¿funcionan los sitios de dating con efectividad? Eso seguro que no. Y a continuación explicaré algunas causas de su ineficiencia.

El mito de Mr. Right

Boyfriend Application FormFué Cortázar quien escribió: “Lo que mucha gente llama amar consiste en elegir una mujer y casarse con ella. La eligen, te lo juro, los he visto. Como si se pudiera elegir en el amor, como si no fuera un rayo que te parte los huesos y te deja estaqueado en la mitad del patio”. Y si hay un lugar donde las personas se eligen unas a otras ese lugar son las redes de dating. No está demostrado que exista ningún cuestionario ni check-list que sirva para seleccionar a la pareja adecuada. Varias redes de dating proclaman que tienen algoritmos de matching basados en similitudes de edad, ingresos, profesión, etc. y en tests de personalidad estilo 16PF o MMPI. Pero no hay datos que demuestren que una persona tiene más probabilidades de mantener a largo plazo una relación con otra si ambas son muy similares. Lo que sí parece comprobado es que es falso que los polos opuestos se atraen. Si uno cocina y limpia y el otro sólo come, probablemente acabarán mal. La relación sin embargo sí puede funcionar cuando hay complementariedad (uno cocina y el otro friega los platos). Según un estudio de la Universidad de Chicago, existe una fuerte afinidad por raza con tan sólo un 4% de matrimonios interraciales en EE.UU. Los caucásicos tienen ligeramente más probabilidades de ser elegidos por la mayoría de las otras razas aunque con importantes excepciones como hindues y coreanos.

Sin perjuicio de lo anterior, existen decenas de sitios especializados por perfiles: casaderos, gays, fetichistas, gorditos, yuppies, hipsters, amish o hasta capitanes de barco.

Amish Dating

Sea Captain

La Paradoja de la Elección

La Paradoja de la Elección es un efecto psicológico que provoca una tendencia a estar menos satisfechos con nuestras adquisiciones mientras más alternativas existan. Es por eso que Tinder tuvo tanto éxito limitando la cantidad de candidatos mostrados. Es mejor hacer una preselección y trabajar con un subconjunto de aspirantes. Probablemente la tasa de abandono de mujeres en Match y Meetic está relacionada con la avalancha de inmails que pueden llegar a recibir.

Factores predominantes en la elección

Según los estudios, los hombres con perfil dominante (machos alfa) puntúan mejor a primera vista aunque no está tan claro que luego sean los preferidos para formar pareja estable. Sin embargo, las fotografías agresivas, mirando de frente a la cámara con cara de pocos amigos, intimidan a las mujeres quienes pueden preferir imágenes de hombres con la mirada desviada en el momento de tomar la imagen. Otro factor comprobado en estudios es que incluir niños en las fotografías incrementa la percepción de atractivo del varón. Es decir, el mismo hombre es percibido como más atractivo en la foto por el mismo grupo de mujeres si aparece un niño a su lado.

En cuanto a las fotografías femeninas, prima la estética. Hombres y mujeres tienen tendencia a mentir en media más o menos por igual en los perfiles, excepto en las fotografías donde las mujeres mienten muchísimo más. Según algunos estudios hasta el 46% de las fotografías femeninas no son fidedignas frente al 11% de poco o nada realistas en los hombres.

Las mujeres aprecian el sentido del humor. Existe una correlacion demostrada entre la cantidad de risa que un hombre es capaz de inducirle a una mujer y la probabilidad de que acaben pasando la noche juntos. El recíproco, sin embargo, no es cierto. Si en un bar se encuentra a un hombre desternillándose de la risa con una mujer probablemente ella acabe volviendo a casa sola.

Aunque prima lo visual sobre lo textual, sobre los textos, tanto hombres y mujeres están de acuerdo en que prefieren información personal y relevante alejada de frases hechas y hobbies comunes. Las personas no conectan tanto por coincidencia en grandes temas vitales como por afinidad en muchos pequeños detalles.

Factores imponderables

Muchos de los críticos con las redes de dating afirman que las cualidades verdaderamente relevantes para estimar la viabilidad de una pareja simplemente no pueden medirse a través de Internet. La más citada es el olor de la otra persona. Parece ser que las personas con sistemas inmunes complementarios se atraen mutuamente. Otros factores como el uso del espacio, la forma de andar o la forma de comer tampoco suelen desvelarse hasta la primera cita. Yo personalmente opino que el factor que mejor sirve para predecir cómo es una persona en la cama consiste en observar qué y cómo come, aunque eso sería otra larga historia muy subjetiva.

Tiempo dedicado a buscar online

Aunque no existen datos proporcionados por los portales, preguntando a los usuarios cuando están activos parece ser que se conectan unas 12 veces por semana durante 22 minutos en cada sesión. Y en Francia en 2015 tanto como un 30% de los encuestados reconocía haber visitado un sitio de dating en los últimos tres meses. Por edades los más jóvenes son el grueso de usuarios seguidos de los más mayores y por último las personas de mediana edad. No está clara cual es la distribución de hombres y mujeres. Cuando se filtró la base de datos de Ashley Madison trascendió que tanto como el 80% de los usuarios eran hombres, aunque otras cifras afirman que la cantidad de mujeres es igual o sólo ligeramente inferior a la de hombres.

Si se examina el modelo de negocio de los sitios de dating es fácil deducir que lo más provechoso para el proveedor es que el uso esté gamificado de tal manera que los usuarios tengan una tasa de éxito lo bastante elevada como para quedarse enganchados pero no tan elevada como para acertar a la primera y abandonar el sitio debido a muerte por éxito.

Timadores

Las redes de dating, como cualquier otro lugar en el mundo, no están exentas de peligro. Se puede encontrar de todo pero los perfiles más comunmente peligrosos son los tres siguientes:

El timador económico. La dinámica de timo más común es contar una historia triste y conmovedora. Al cabo de un tiempo pedir una pequeña cantidad. Por ejemplo, 50€ o 100€ para pagar una presunta factura de la luz. Y por último inventar una gran catástrofe sobrevenida del tipo “tengo a mi hijo en el hospital y no tengo dinero para el tratamiento”. La pequeña cantidad se pide porque es sabido que las personas que ya han hecho una aportación previa tienen más probabilidades de aceptar hacer otra mayor.

El narcisista y el sociópata. De todos los enfermos mentales que se pueden encontrar online probablemente el narcisista y el sociópata son probablemente los más peligrosos debido a que no resulta para nada sencillo detectarlos tempranamente.

El irresoluto. Este último no es un tipo realmente peligroso. Sólo hace perder el tiempo. Uno de cada tres usuarios de las redes de dating afirma que nunca ha tenido una cita en la vida real. Algunas personas quedan online porque sólo quieren quedar online.

Desvirtuación de otras redes sociales

No sólo se liga en redes de dating. Cada vez son más los usuarios de LinkedIn que se quejan de lo poco profesional que se ha vuelto la red en una deriva hacia perfiles cool del estilo de A Small World. Conozco al menos un caso de alguien que abrió una cuenta de Twitter sólo para compartir fantasías sexuales. Y también es común entre los gamers que una relación que comienza matando bichos en un mundo virtual evolucione hacia unas tapas en un bar. En Facebook los anuncios de sitios con énfasis sexual estan prohibidos lo cual incluye anuncios de sitios de dating que muestren fotos provocativas.

Ad Pictures

Conclusiones

Como en tantas otras áreas de innovación, la tecnología ha evolucionado más rápido que la capacidad de los usuarios para adaptarse a ella y todavía existe un largo camino por recorrer tanto en el funcionamiento de los servicios como en el aprendizaje de los usuarios para sacar el mejor provecho de ellos. Aunque todavía representa un porcentaje minoritario como medio de establecimiento de relaciones, el dating online está creciendo como mucha fuerza especialmente entre los más jóvenes. Una evolución que a mi personalmente no me parece ni intrínsecamente buena ni mala sino una consecuencia inevitable de la globalización de un mundo en el que nos relacionamos cada vez menos por proximidad geográfica y más por afinidad en otros parámetros.

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

Tax Loans

Leo en eldiario.es un certero artículo de Marta Sofía Ruiz aclarando la diferencia entre el EBITDA y el beneficio real en las empresas. Trata sobre la esencia del mecanismo principal para evadir impuestos legalmente en la actualidad.

Los impuestos se recaudan por la diferencia entre ingresos y gastos (no tendría sentido intentar cobrarle a alguien que tiene muchos ingresos pero ningún beneficio). Los gastos incluyen costes financieros (intereses). Entonces una forma de reducir el beneficio (aka no pagar impuestos) es tener una enorme deuda y, por consiguiente, muchísimos costes financieros. He aquí la clave que comenta el artículo de eldiario.es: las punto com son empresas cuyo EBITDA es positivo (ergo cotizan al alza en bolsa) pero en el cierre contable después de intereses e impuestos arrojan pérdidas (ergo no pagan impuestos).

Se trata de una regulacion legal perversa mediante la cual, aunque tengas mucho dinero, lo más eficiente fiscalmente es estar endeudado. Es por eso que incluso las empresas que tienen cantidades ridículamente altas de caja mantienen deuda.

El patrón no se aplica sólo a las empresas. En el Reino Unido, desde hace ya casi una década, y en España según se ha descubierto tras los papeles de Panamá, existe mucha gente que cede sus ingresos a cambio de una renta. En la jerga legal británica se conoce como los tax loans. El mecanismo es como sigue: tú eres autónomo, y vas a firmar un contrato, supongamos de 200€/día por 6 meses. A 22 días por mes igual a 26.400€ de ingreso bruto (más IVA). Entonces haces lo siguiente: pides un préstamo por 20.000€ a una empresa off-shore con un interés del 10% anual. Como garantía de este préstamo pones tu nómina pero de manera que tú nunca llegues a percibir el ingreso. Es decir, el cliente debe pagarle a la off-shore directamente. Fiscalmente, tienes una deuda de 21.000€ (20.000+intereses) y la off-shore debe de reconocer el ingreso pero como está radicada en un paraíso fiscal no tributa. Para que el trabajador tenga cobertura en la seguridad social, la off-shore subcontrata a una empresa en el país que le paga al sujeto pasivo un salario muy bajo, pongamos por caso 20€/día. El resultado neto es un coste real entre el 15% y el 18% para el (no)contribuyente. Puede que ni siquiera se aplique el IVA ya que la venta de servicios entre países intracomunitarios está exenta. Y es todo “legal”. O más bien “legal” sobre el papel. Pues existe un principio de derecho que establece que las cosas son “lo que son” y no “lo que las partes dicen que son”. Es por esto que un juez puede limpiarse el trasero con una carpeta de facturas por muy “legales” que sean si en realidad no se corresponden con ningún producto o servicio real o se emitieron con el único fin de eludir el pago de impuestos.

En el Reino Unido le han dado a los listillos de plazo hasta 2019 para dejar en cero sus tax loans y están tratando de llegar a acuerdos negociados de amnistía fiscal (pagando el 10% y esas cosas…) para evitar difíciles batallas judiciales con los implicados ya que con la ley actual no está claro que Hacienda pueda ganarles en un juicio. Algunos tienen un serio problemilla porque, puestos a endeudarse a costa de la nómina, pidieron un préstamo para el Jaguar, el ático en la costa y los costes del divorcio, y, claro, ahora el HMRC (la AEAT en UK) les reclama una cantidad en decenas de miles que no tienen en la cuenta bancaria. Y como llevan haciéndolo años están dentro del rango de delitos fiscales punibles con cárcel. Sin embargo, no llegará la sangre al rio porque hay tanta gente pringada a todos los niveles que a nadie le interesa que se destape todo el cotarro.

La raíz del problema, no obstante, es un sistema fiscal inapropiado donde las personas jurídicas están obligadas a una presión fiscal excesiva. Debido a que no se pueden poner puertas al campo en una economía globalizada, el impuesto de sociedades debería estar siempre por debajo de los costes financieros. Esto implicaría dejar dicho impuesto en una horquilla entre el 3% y el 5%. Ya sé que esto suena completamente impopular ¡Mosquis! ¿No sería eso acaso reducir la presión fiscal sobre los multimillonarios y sus grandes empresas? Pues no. Resulta que el beneficio de una empresa no es de nadie. Bueno, es de la empresa, pero ese es el dinero que la empresa tiene para crecer y generar empleo. Gravándolo al 35% lo único que se consigue es que a las empresas les resulte más rentable estar perennemente endedudas, con el consiguiente riesgo que eso acarrea. El único momento en el que se debería fiscalizar el beneficio es cuando se reparte entre los accionistas bien sea via nómina, dividendos o retribución en especie. Por último, mantener una empresa (o a uno mismo) permanentemente endeudada hasta las trancas es peligroso pues pone a la empresa a merced de los acreedores (bancos y otros aún más fieros) en el caso de que se desplomen los ingresos por causas impredecibles.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Análisis Financiero del Software Libre | Deja un comentario

Programación orientada a procesos de negocio

Los desarrolladores suelen catalogarse en dos grandes grupos: imperativos y funcionales. Y dentro de cada grupo, front-end o back-end. Existen luego especialidades: los que hacen programación concurrente con actores, los especializados en algoritmos de programación dinámica, los científicos de datos, etc. La gestión de procesos de negocio, o Business Process Management (BPM) en inglés, se concibe usualmente como un conjunto de herramientas, pero técnicamente se trata más bien de otro paradigma al mismo nivel que la programación orientada a objetos. En este post explicaré principalmente desde el punto de vista del desarrollador en qué consiste BPM y cuales son las herramientas más populares disponibles en el mercado.

BPM

Al BPM lo empezamos llamando Workflow allá por los noventa, luego los fabricantes fueron evolucionando hacia estándares de OMG y OASIS que veremos más adelante y le cambiaron la denominación por motivos comerciales. La piedra angular de BPM es la definición de lo que es un proceso de negocio. En esencia, es sencillo: un proceso de negocio toma unas entradas, que son objetos de negocio, y produce unas salidas, otros objetos de negocio. Por el camino, realiza una serie de actividades con las entradas y toda decisiones sobre qué actividades realizar a continuación en función de cómo van siendo modificadas las entradas o en respuesta a eventos externos. El proceso también puede mantener algunas variables internas de estado que no son visibles externamente. Y la salida puede enviarse a un sistema externo normalmente a través de un servicio web.

El BPM maneja sus propios objetos de negocio los cuales, en general, son diferentes de las entidades que se almacenan en el modelo relacional subyacente a los datos empresariales. Por consiguiente, se requiere alguna forma de mapeo entre los objetos del BPM y las entidades relacionales de larga vida.

Los objetos de negocio del BPM se parecen mucho a las estructuras de datos en C. Es decir, son clases que tienen propiedades pero no métodos. Esto es debido a que en BPM es responsabilidad de la actividad modificar el estado de los objetos que maneja. No obstante, en algunas herramientas, los objetos de negocio se pueden representar como clases Java y la actividad puede delegar el comportamiento en métodos de la clase. Pero una diferencia clave entre la programación orientada a objeto y la programación orientada a procesos es que en esta última es la actividad quien controla los cambios en el estado interno de los objetos de negocio. Los objetos de negocio sobreviven sólo en tanto en cuanto el proceso al que pertenecen siga abierto, y deben persistirse explícitamente a la base de datos en el caso de que deban ser preservados tras la finalización del proceso. Los procesos se pueden organizar en carriles para identificar las diferentes etapas del proceso y asignar roles de usuario a cada una de ellas. Finalmente, los procesos se almacenan en aplicaciones que se despliegan a un servidor. En resumen, de más alto a más bajo nivel tenemos:

— Servidores de aplicaciones.
— Aplicaciones de proceso.
— Carriles.
— Procesos.
— Subprocesos.
— Actividades.
— Reglas de decisión.
— Eventos.
— Objetos de negocio de entrada.
— Objetos de negocio de salida.

El estándar de OMG para especificar todo esto es BPMN. Se trata de un esquema XML que casi todas las herramientas pueden leer y representar en pantalla mediante una notación gráfica bien definida. Por ejemplo, he aquí una captura del BPM de IBM que es el que tengo en local. Muestra tres carriles: Analisys, System y Vendor y seis actividades.

Order Fullfilment BPM

Nunca se trabaja directamente con BPMN, las herramientas permiten pinchar y arrastrar los componentes del proceso para componerlo visualmente. De hecho, se supone que esa es una de las ventajas de BPM, que los usuarios y los programadores pueden compartir una visión de los procesos de negocio. Sin embargo, la mayoría de las herramientas no están pensadas para que los usuarios diseñen nada. IBM enfocó este problema ofreciendo una herramienta web específica sólo de modelización Blueworks Live. Microsoft Visio también puede crear diagramas exportables a BPMN. La ventaja de Blueworks es que al tratarse de una herramienta web permite a usuarios remotos colaborar en la creación y revisión de un proceso.

Alternativamente, o complementariamente, es posible definir los procesos en BPEL, sucesor del WSFL de IBM y XLANG de Microsoft mantenido por OASIS. BPEL nació como un vehículo para la orquestación de procesos mediante servicios web descritos mediante WSDL. La ventaja de BPEL frente a BPNM es que está más próximo a lo que una máquina puede ejecutar realmente. Sin embargo, a diferencia de OMG con BPMN, OASIS no proporciona una notación gráfica estándar para BPEL e internamente el XML de BPEL es más complejo que el de BPMN. No obstante, prácticamente todos los grandes fabricantes: IBM, Oracle, SAP, Microsoft, Red Hat, etc. Dan soporte tanto a BPEL como a BPMN.

En la práctica y en mi propia experiencia, las arquitecturas SOA descritas en BPEL presentan inconvenientes:

1º) Cuando cada servicio es responsabilidad de un equipo independiente resulta complicado coordinarlos entre ellos para que no se bloqueen unos a otros.

2º) Debido a que los subsistemas se comunican por HTTP, los tiempos de latencia son difíciles de estimar ya que dependen de la electrónica de red con la consecuencia de que el funcionamiento del sistema en conjunto fácilmente puede llegar a ser lento e impredecible.

3º) Debe existir algún convenio para garantizar la compatibilidad de versiones entre el cliente y el servidor de cada servicio.

4º) Es complicado crear y ejecutar sistemáticamente pruebas unitarias. Aunque los procesos se pueden simular, las herramientas no proporcionan en general un buen marco de trabajo TDD e integración contínua.

Mi acercamiento personal es que lo mejor suele ser modelizar primero los procesos en BPMN sin definir explícitamente los de detalles de las interacciones entre los servicios. Luego encapsular las llamadas a cada servicio en subprocesos BPEL. Esto puede diferir de las mejores prácticas recomendadas por el fabricante, como en el caso de Oracle, ya que sus herramientas presumen de soportar BPMN o BPEL indistintamente, y, por consiguiente, no es preciso trazar una línea divisoria clara entre el uso que se le da a cada uno de ellos.

DMN

Complementario y relacionado con BPM se encuentra DMN Decision Model and Notation. DMN es una notación específica para representar reglas de negocio. BPM se relaciona con DMN a través de una actividad denominada Business Rule Task. Es decir, existe un punto en el proceso de negocio en el cual se ejecuta una regla DMN que sirve para tomar una decisión sobre por dónde debe continuar el proceso. La motivación principal para DMN es externalizar las reglas de negocio y permitir que los usuarios puedan modificarlas para adaptar el funcionamiento de proceso a los requerimientos cambiantes del entorno. Además de DMN, que es un estándar relativamente nuevo de OMG, existen varios lenguajes específicos de domino o Domain Specific Language (DSL) en inglés. Estos lenguajes tratan de proporcionar una representación de las reglas que los usuarios puedan leer en lenguaje natural y modificar de forma segura con un asistente. Antaño, IBM mantenía su propio estándar BRML, aunque lo descontinuó en favor de DMN.

La pega fundamental de los DSL para reglas de negocio es que existe un peaje de entrada a pagar tanto en la complejidad de la aplicación que los maneja como en la curva de aprendizaje del lenguaje. Por ejemplo, el siguiente DSL y regla de negocio estan tomados de IBM ODM (Operational Decision Manager).

DSI Entities

Business Rule

Herramientas

Debido a que la necesidad de automatizar procesos de negocio es importante, los grandes fabricantes de software llevan ya bastante tiempo invirtiendo en el desarrollo de herramientas de gestión de procesos y reglas de negocio. Las herramientas de BPM, en general, no son sencillas. Los fabricantes se lanzaron a la carrera de añadir más y más funcionalidades para puntuar mejor en los rankings comparativos. Además los peces grandes se fueron comiendo a los pequeños. Como resultado, las herramientas resultan con frecuencia complejas y bastante pesadas. Usarlas no es nada trivial (hasta que se aprende cómo hacerlo). Además no siempre se pueden poner los procesos bajo un sistema de control de versiones estándar como SVN o Git y los despliegues al servidor de aplicaciones también siguen un procedimiento exclusivo de cada herramienta.

Los proyectos de BPM pueden reportar grandes beneficios operativos pero con frecuencia son caros y difíciles de poner en práctica, ya que requieren de una costosa coordinación interdepartamental, integraciones de datos complicadas y procesos de cambio mental y organizacional que pueden tardar toda la vida.

Los principales proveedores de software BPM privativo son PEGA Systems, IBM, Oracle y Appian. En el mercado español también es significativo AuraPortal. Y las opciones Open Source más comunes son BonitaSoft, Alfresco Activiti, Drools, OpenRules y jBPM de Red Hat quien también compró Polymita, otro proveedor español, en 2012. Por otro lado, los usuarios de SAP también pueden contar con herramientas que no son para nada una mala opción, aunque tanto IBM como Oracle han invertido bastante en la intergración de sus respectivos BPM con SAP.

Las herramientas se pueden comparar en función de su puntuación en los siguientes criterios:

— Modelización de procesos.
— Definición y ejecución de reglas de negocio.
— Diseño de pantallas.
— Interfaces con sistemas externos.
— Simulación de procesos.
— Analíticas de rendimiento.
— Despliegue y gestión de la configuración.
— Administración diaria del sistema en producción.

Los proveedores de las herramientas más potentes ponen énfasis en que no sólo se trata de descubrir, modelizar e implentar procesos, sino también de medir su eficiencia y buscar puntos calientes a mejorar. En la práctica, la simulación y la optimización se usan casi siempre menos de lo previsto, ya que bastante tiene el cliente con sobrevivir al proceso de transformación organizacional como para ponerse a optimizarlo antes de tenerlo ni siquiera funcionando.

El diseño de pantallas es otro punto caliente. Yo personalmente aún no he encontrado ningún diseñador de pantallas integrado que me convenza. Los diseñadores de pantalla integrados que conozco carecen de funcionalidades nativas para evitar el cross-site scripting, la inyección de SQL y otras modalidades de ataque. Por todo esto, mi opinión personal es que lo mejor es diseñar las pantallas con un framework MVC y conectarlo al BPM mediante un bus de integración de datos.

SaaS

El BPM en modo de software como servicio merece una mención aparte. Appian, IBM, Oracle, Bonita y muchos otros fabricantes que no he podido evaluar ofrecen soluciones de BPM en la nube. Hasta donde yo conozco, el escollo intrínseco de estas plataformas es que son externas a los sistemas de la casa. Un BPM tiene que integrarse casi siempre al menos con otros tres tipos de sistemas: una base de datos relacional, un gestor documental y varios ERPs y CRMs. Si el BPM está en la nube al final tiene que cruzar toda la Internet cada vez que se ejecuta alguna actividad, lo cual es tanto un problema de rendimiento como de seguridad. No obstante, el BPM en cloud puede ser una opción muy viable para empezar con un proyecto táctico experimental más rápido y barato de lo que costaría desplegar un cluster de BPM on-premise; o cuando se requiere de una solución de BPM en una organización geográficamente distribuida.

Conclusiones

Aunque las herramientas de BPM han mejorado, y siguen mejorando bastante, el diseño e implementación de una solución BPM sigue presentando importantes desafíos.

Desde el punto de vista del desarrollador requiere un cambio de mentalidad en el diseño técnico y en la gestión de la configuración, acostumbrándose a sacar partido de las herramientas de programación visual, de las funcionalidades para el despliege de aplicaciones de proceso, y superando el desafío de combinar la integración contínua y el control de versiones con ramas con ciclo de vida de un proceso en desarrollo, pruebas y producción.

Desde el punto de vista del usuario, requiere aprender a utilizar nuevas herramientas y colaborar de forma más estrecha con los desarrolladores en la definición de los procesos .

Desde el punto de vista del gerente, requiere reunir una gran cantidad de apoyo directivo y organizacional y descubrir los KPIs y puntos de mejora en un conjunto de procesos que puede proliferar rápidamente hasta hacerse difícilmente manejable sin una buena metodología de gestión de cambios.

Post relacionado: Introducción a Domain Driven Design.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Casos Prácticos, Tecnologías Emergentes | Deja un comentario

¿Por qué el mercado de informática está roto?

En el mercado de desarollo de software hay mucho movimiento últimamente. Por una parte, una fuerte demanda de mano de obra; por otra, bastantes candidatos, muchos de ellos insuficientemente cualificados, y en medio, montones de intermediarios y mercachifles. Entre todos ellos, el mercado de TI está roto. En este post voy a comentar el porqué de las ineficiencias del mercado.

En economía se sabe y está más que demostrado que el que gana dinero es bien quien controla un recurso escaso, bien quien saca provecho de una imperfección de mercado. En informática, los recursos escasos son: a) el acceso a cuentas y b) los programadores. Y las imperfecciones son: a) cómo resulta de difícil seleccionar a un candidato y b) cómo resulta de difícil gestionar un proyecto.

Acceso a cuentas

El acceso a cuentas en el mercado informático está severamente restringido por una serie de medidas diseñadas para evitar la concurrencia competitiva real. Esto es debido principalmente a que a los proveedores en una posición dominante no les interesa que un proyecto esté abierto a propuestas de todo el mundo. Pero también es debido a que un cliente sólo puede razonablemente considerar como máximo de cinco a ocho ofertas diferentes para cada proyecto o de diez a veinte candidatos para un puesto.

Lo que sucede es que las consultoras acceden a diferentes niveles de la estructura de mando de los clientes y bloquean el acceso mediante diversos mecanismos, entre ellos:

– Acuerdos marco que restringuen la provisión de recursos a determinados proveedores.
– Procesos de homologación que dificultan la entrada de nuevos proveedores.
– Contratación por parte de la consultora de personas de confianza del cliente.
– Recolocación de recursos de la consultora como empleados del cliente.
– Venta de plataformas cerradas sobre las que otros proveedores no pueden trabajar.

El efecto práctico de esto es que en cada cliente hay un “amo del calabozo” quien se queda entre un 20% y un 40% de la facturación por “gestionar” la cuenta y asesorar al cliente.

Además, la naturaleza de la demanda ha cambiado en la última década. Durante la primera burbuja punto com la mayoría de los clientes no sabían ni lo que necesitaban verdaderamente ni cómo gestionar los proyectos. Entonces compraban carísimos productos bajo licencias privativas y contrataban proyectos a precio y plazo cerrado. Estos proyectos eran como una caja negra en lo referente a su estructura interna de costes lo cual proporcionaba pingües beneficios a los implantadores. Con el paso del tiempo, los clientes han ido dándose cuenta de que la mayoría de las veces es posible reemplazar los productos privativos por soluciones de software libre, pero además han ido aprendiendo a gestionar ellos mismos los proyectos o a subcontratar la gestión a una empresa diferente de la que desarrolla e implanta el software. Esto ha erosionado el margen de las consultoras, que obtienen menos comisiones por la reventa de software y están más controladas en cuanto a los costes de mano de obra que le repercuten al cliente. En otras palabras, el mercado se ha tornado mucho más “cárnico” con clientes menos interesados en comprar valor añadido, pues creen que ya lo añaden ellos mismos, y más interesados en obtener el recurso escaso que es la mano de obra experta.

Escasez de programadores

Los buenos programadores escasean. En mi opinión, esto es debido a que se requieren al menos diez años de tediosa práctica diaria para llegar al nivel senior, más luego mantenerse actualizado.

Agravando aún más el problema, en los paises con más demanda de programadores bien retribuidos: EE.UU., Reino Unido, Suiza y Países Nórdicos, los más veteranos se han dado cuenta de que no les compensa estar en nómina. En Inglaterra calculo que el 80% de los programadores senior que saben algo de Scala o de Big Data son autónomos, para las empresas encontrar uno que quiera aceptar una nómina es como buscar una aguja en un pajar. Esta negativa a aceptar un salario se ha producido en parte como respuesta a los abusos laborales de algunas empresas. Con horas extra interminables no retribuidas o, peor aún, retribuidas en stock options basura, justificadas porque “somos un equipo” o porque “hay que sacar la release”. Históricamente, la unión sindical de los programadores ha sido prácticamente inexistente y como resultado muchos han acabado yendo por libre cazando recompensas como buenamente pueden.

Los autónomos son bienvenidos en algunas empresas, porque trabajan a destajo y no alteran el status quo (al menos en teoría). Pero en la mayoría de las organizaciones suelen incomodar porque no forman parte de la “mafia departamental”. Las empresas intentan sistemáticamente convertir a los autónomos más capaces en empleados, y suelen fallar miserablemente porque les ofrecen los incentivos equivocados. Así que a la postre acaban contratando en plantilla a los autónomos que simplemente no tenían un lugar mejor al que mudarse en el próximo proyecto.

Ineficiencias en el proceso de selección

Si los hospitales reclutasen médicos con el mismo proceso que las empresas reclutan informáticos a todos los pacientes se le ofrecería la extremaunción antes de someterse a cualquier tratamiento. En informatica, el 99% de las veces el intermediario no tiene capacidad para evaluar el talento real del candidato y en el caso de projectos llave en mano el gerente de cuenta no entiende nada sobre los detalles de implementación de lo que está vendiendo.

Adicionalmente, los propios clientes se equivocan en lo que buscan. Siguiendo las creencias de que: a) la inteligencia es el factor que mejor predice el éxito de un candidato y b) se necesitan cononocimientos técnicos muy específicos. Los clientes se han lanzado en masa a contratar por los criterios erróneos. En primer lugar, se asocia la inteligencia únicamente con la capacidad del candidato para resolver problemas algorítmicos. Es verdad que empresas como Google o Facebook son legendarias por la complejidad de los algoritmos y estructuras de datos que emplean y, por consiguiente, necesitan algunos programadores extraordinariamente bien dotados en problemas del estilo de ordenar grandes listas de cosas, buscar y contar subcadenas, etc. Pero la mayoría de las empresas no desarrollan algoritmos complejos. Lo que tienen son sistemas de información grandes y complejos, lo cual es un problema diferente. Existe un desdén absoluto por cualquier cosa que no sea la capacidad de los candidatos para escribir subrutinas de código o recitar los detalles de los APIs de programación. Como resultado, se contrata a menudo a candidatos que no encajan. Según los propios incumbentes, parece ser que tanto como el 70% de los candidatos fallidos lo son por inadaptación a la cultura de la empresa y no por falta de suficiente talento profesional.

El grado en el que los seleccionadores pueden llegar a ser retorcidos durante el proceso es difícilmente imaginable si no se conoce. Por ejemplo, a continuación la lista de algunas “mejores prácticas” recomendadas según el artículo Top Tech Companies’ Secrets to Hiring the Best People. Traduzco:

1. Empezar la entrevista telefónica media hora tarde o media hora temprano, o incluso decirle al candidato que le llamarás y no llamarle.
2. Hacer la agenda de la entrevista tan caótica y confusa como sea posible.
3. Provocar que algo vaya mal durante la presentación de la empresa.
4. Hacer un montón de suposiciones incorrectas durante el diálogo.
5. Pedirle al candidato que resuelva un problema específico sólo del cliente.
6. Moverse de una sala a otra durante la entrevista.
7. Hacer la misma pregunta una y otra vez.
8. Jugar a “poli bueno, poli malo” durante la entrevista.
9. Hacer una pregunta y empezar a teclear muy fuerte mientras el candidato responde.
10. Llamar al candidato 3 meses después para ofrecerle un empleo que no solicitó.

y etcétera, etcétera.

Teniendo en consideración lo anterior, y cosas aún peores que no voy a contar, al autor no le parece extraño que muchos candidatos serios manden directamente a tomar por el culo al entrevistador. De hecho, conozco varios programadores quienes ni siquiera se ponen al teléfono si les llama un head hunter sea lo que sea que pretenda proponerles.

Dificultades en la gestión del proyecto

La mayoría de las empresas son seriamente disfuncionales en su dinámica interna. Usan Agile, si, esa adaptación de Kaizen ideada para exprimir a los programadores como limones. Pero es que Agile no es una metodología de gestión de recursos humanos y además muchos lo usan mal.

Llevo 20 años como desarrollador, consultor y empresario. He estado en contacto con más empresas de las que puedo enumerar. He visto a gente despedida por incompetente o incluso por alcohólica. Pero la razón principal por la que he visto a personas capacitadas “saltar” del puesto ha sido por desalineación con una línea de gerencia completamente demencial. Los problemas suelen estar relacionados con:

– Blindar la posición de alguien en el organigrama.
– Acosar y eliminar a cualquier rival potencial (si es mujer, o negro o GLTB mejor).
– Subcontratar a determinados proveedores.
– Defender a ultranza la ortodoxia de una metodología.
– Evitar sistemáticamente cualquier riesgo.
– Mantener o elevar artificialmente la valoración de la empresa.

Conclusión

El resultado del cóctel anterior son un montón de clientes desesperados y un montón de programadores quemados. Y en un mercado que debería funcionar con gran dinamismo y elevados salarios, ambas partes se desgastan arrastrando piedra sobre arena en lugar de usar ninguna rueda.

Post relacionados:
Cómo hacer entrevistas de selección.
Consejos para elegir un candidato o un puesto de trabajo.
Porqué el talento no importa en las empresas.
Contratar a un Space Cowboy y no a un hacker.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Mercado y Oportunidades de Negocio, Tecnología y Empleo | 1 comentario

Internet de las Cosas es Gran Hermano

Ya hace más de una década que muchas empresas decidieron que su producto iba a ser sus usuarios. En todos estos años la tendencia no ha hecho más que acentuarse. Basta con instalarse por error Windows 10 (lo difícil es que no se te instale automáticamente incluso en contra de tu voluntad) para percatarse hasta qué punto Microsoft lo ha diseñado para recopilar información sobre todo lo que haga el usuario. Echar un vistazo a las cookies almacenadas en el navegador es descubrir aspectos de tu personalidad que ni siquiera tú eras consciente de que existían. El uso que hace una persona de sus tarjetas de crédito puede decirte prácticamente quién es. Y el patrón de uso de las apps se rumorea que es usado últimamente por algunos bancos para la evaluación de riesgos crediticios.

Hay dos dispositivos, no obstante, que han abierto todavía más oportunidades para el espionaje permanente a los usuarios: Google Nest y Amazon Echo.

Nest se compone de un termostato, una alarma anti-incendios y una cámara con la que ver el interior desde tu casa desde el smartphone. El problema es que Nest detecta cuánta gente hay en cada habitación de la casa en cada momento.

Echo es un interfaz de voz para Alexa. Se activa al escuchar la palabra “Alexa” y puede distinguir la voz de las personas. De modo que Alexa no sólo sabe cuántos hay sino también quienes son los presentes en una habitación ergo deducir fácilmente lo que están haciendo a partir de las interacciones con el dispositivo.

Algún día a lo mejor incluso aún llega al mercado aquella descabellada nevera conectada a Internet imaginada por alguien quien evidentemente no tenía ni idea de cómo y por qué la gente hace la compra. Pero mientras tanto, el siguiente paso es que los wearables recopilen información sobre nuestras constantes vitales en tiempo real y las envíen Dios sabe dónde. Interpretando nuestro ritmo cardíaco, sudoración, etc. será fácil conocer no sólo lo que estamos haciendo sino también cómo nos estamos sintiendo.

No debería haber problemas, en teoría, si toda esa información acerca de nosotros está almacenada de forma segura y sujeta a leyes estrictas de protección de la privacidad. Lo que sucede es que por la inexorabilidad que predice la Teoría de las Catástrofes, es inevitable que se produzcan filtraciones y malos usos a gran escala.

Las leyes de protección de datos personales han sido un primer paso pero es muy difícil adaptarlas con suficiente rapidez al progreso de los medios técnicos para la recopilación, análisis y explotación de datos sobre los usuarios.

Post relacionado: Escapar de Gran Hermano

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Minería de Datos | Deja un comentario

Cómo elegir librerías y sobrevivir a JavaScript

Nunca salgo de mi asombro cada vez que leo que JavaScript ha repetido, un año más, en las estadísticas de GitHub como lenguaje más utilizado. Por favor, que alguien nos libre de esta cosa presuntamente creada en 10 días de 1995 por Brendan Eich y originalmente bautizada Mocha. Aunque no puedo sino reconocer el logro de Eich como grandioso, ese lenguaje multiparadigma útil para todo y bueno para nada, ese Lisp con sintaxis de C, nunca debió trascender los límites de Netscape. No voy a entrar en los tecnicismos que justifican por qué JavaScript es un campo minado, es fácil encontrar en Internet artículos como este o este que los comentan. La combinación de JavaScript con CSS3 es tan endemoniadamente traicionera que ningún programdor profesional los usa directamente sin librerías intermedias. Lo que voy a hacer, pues, es repasar las opciones que existen para tecnologías front-end en el navegador.

JavaScript presenta seis desafios principales cuando se usa como lenguaje de scripting en los navegadores web:

1. Cómo añadir contenido dinámicamente al árbol DOM del HTML.
2. Cómo gestionar cambios en CSS.
3. Cómo obtener información del servidor y sincronizarla con las variables locales de la página.
4. Cómo cargar dinámicamente sólo las librerías requeridas en cada página.
5. Cómo gestionar contenidos multimedia.
6. Cuestiones de estilo derivadas de la sintaxis de JavaScript.

Estos desafios son consecuencia de que cuando se creó JavaScript no se podía usar para añadir contenido dinámicamente a una página. Tampoco existía CSS. La idea era usarlo para hacer algunas validaciones de datos antes de un HTTP POST o crear transiciones de página que dependían de datos previamente seleccionados por el usuario.

El último punto tiene que ver en gran parte con que en JavaScript la programación orientada a objeto se puede hacer como una consecuencia de la estrutura interna del lenguaje donde las funciones son objetos que pueden tener propiedades definidas dinámicamente. Pero no existe una forma explícita de definir clases, implementación de interfaces y herencia como en los lenguajes orientados a objeto.

Hubo un tiempo en el cual la competición era crear extensos conjuntos de librerías que hicieran de todo. De aquella época han sobrevivido fundamentalmente JQuery y Dojo. A mi me gustaba YUI, sobre todo por su documentación superior al resto, pero, por desgracia Yahoo! decidió abandonarlo y lo reemplazó en parte por Pure. La tendencia más actual es hacia crear librerías más pequeñas de propósito específico.

Librerías JavaScript agrupadas según su funcionalidad principal

DOM, eventos y efectos Carga dinámica de datos CSS Gestión de Configuración Otras Sintaxis
JQuery

Dojo

Bootstrap
AngularJS

React.js

Backbone.js
LESS

Sass

Pure

Zimit
npm

Bower

RequireJS
Modernizr

Date.js

plotly.js

Textures.js

Hammer.js

Lightbox
CoffeeScript

PureScript

ClojureScript

Dart

TypeScript

ECMAScript6

Interfaz visual

JQuery

No se puede escribir sobre librerías JavaScript sin hacer referencia a JQuery. El núcleo de JQuery comprimido para producción ocupa 95Kb aunque cuenta con una arquitectura de plug-ins para extenderlo.

JQuery empieza por reemplazar el Javascript:
document.getElementById("hello");
por
$("#hello");

La notación $ permite usar selectores CSS. Por ejemplo, el siguiente fragmento añadirá un gestor de evento click a todos los tags de tipo <p> (párrafo).

$(document).ready(function(){
    $("p").click(function(){
        $(this).hide();
    });
});

JQuery incluye selectores CSS, manejo de eventos, Ajax, y efectos visuales sobre capas. Es una librería de propósito general. Fácil de aprender y con una amplia comunidad de usuarios.

Dojo Toolkit

Dojo es una extensa librería de 13Mb. El gestor de dependencias básico pesa 117Kb. Tiene muchos módulos, incluidos widgets, MVC, grids, gráficos vectoriales, charting, validación de formularios, soporte HTML5, etc. Si lo que se busca es una librería que cubra el máximo de funcionalidades potencialmente requeridas, probablemente es la mejor opción. No obstante, a mi la curva de aprendizaje de dōjō siempre me ha echado para atrás. Basta con echar un vistazo al “Hello World!” de ejemplo.

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>Tutorial: Hello Dojo!</title>
</head>
<body>
    <h1 id="greeting">Hello</h1>
    <!-- load Dojo -->
    <script src="//ajax.googleapis.com/ajax/libs/dojo/1.10.4/dojo/dojo.js"
            data-dojo-config="async: true"></script>
    <script>
        require([
            'dojo/dom',
            'dojo/dom-construct'
        ], function (dom, domConstruct) {
            var greetingNode = dom.byId('greeting');
            domConstruct.place('<em> Dojo!</em>', greetingNode);
        });
    </script>
</body>
</html>

¡Mi madre! Trata de escribir semejante ejemplo intuitivamente. Usar dōjō es fácil cuando aprendes lo que tenían en la cabeza quienes lo diseñaron. Mientras tanto lo que es fácil es pasarse varias horas intentando averiguar cómo hacer algo tan trivial como añadir y quitar items en una combobox.

AngularJS

AngularJS es una librería de 150Kb creada principalmente para añadir contenido dinámicamente a una página. AngularJS tiene arquitectura MVVW. En palabras sencillas, funciona definiendo una plantilla a la que luego se pasan datos. Un buen ejemplo podría ser la creación de un scroll infinito similar al del archivo de un blog en Tumblr. La idea diferencial de AngujarJS sobre JQuery y Dojo es no manipular el árbol DOM directamente sino que al hacer cambios en el modelo de datos la librería los detecte dinámicamente y redibuje las plantillas afectadas. El “Hello World!” de los tutoriales es fácil de entender, pero para cargar datos dinámicamente mediante Ajax y presentarlos en pantalla la cosa tiene no poca complejidad adicional. Existen diferencias sustanciales entre la version 1.x y la 2.x de AngularJS, básicamente son dos productos diferentes y en la 2.x se usa TypeScript con un transcompilador. Por último, se pueden encontrar en Internet tantos tutoriales sobre cómo optimizar el rendimiento de AngularJS como para intuir incluso antes de hablerlo probado uno mismo que lo que hace por detrás la implementación no es precisamente ligero. Una librería MVC alternativa a AngularJS es Backbone.js que no voy a comentar aquí.

React.js

Originario de Facebook, el propósito de React.js es similar al de AngularJS pero a diferencia de este no es un framework MVC ni usa plantillas. La propuesta alternativa de React.js se llama JSX y es una mezcla de JavaScript con XML. Por ejemplo:


<script type="text/babel">
var CommentBox = React.createClass({
  render: function() {
    return (
      <div className="commentBox">
        Hello, world! I am a CommentBox.
      </div>
    );
  }
});
ReactDOM.render(
  <CommentBox />,
  document.getElementById('content')
);
</script>

será traducido por React.js a

<script type="text/javascript">
var CommentBox = React.createClass({displayName: 'CommentBox',
  render: function() {
    return (
      React.createElement('div', {className: "commentBox"},
        "Hello, world! I am a CommentBox."
      )
    );
  }
});
ReactDOM.render(
  React.createElement(CommentBox, null),
  document.getElementById('content')
);
</script>

Bootstrap

Bootstrap es una librería de componentes visuales salida de Twitter: botones, barras de navegación, dropdowns, etc. Está pensada para diseños responsive y soporte de dispositivos móviles. El núcleo pesa 37Kb y en total ocupa 1,1Mb en disco. La ventaja de Bootstrap es que proporciona un interfaz de usuario limpio y moderno “out-of-the-box” aunque también se puede personalizar.

Date.js

Haré una breve reseña sólo a mi librería favorita para solucionar el problema de las fechas en diferentes idiomas: Date.js.

LESS y Sass

LESS y Sass no son librerías JavaScript. Son preprocesadores de CSS. Nadie que pretenda escribir una hoja de estilos de más de 100 líneas debería planterse hacerlo sin usar alguno de estos preprocesadores. Yo siempre he usado LESS, pero últimamente parece ser que Sass se está imponiendo entre los creadores de opinión. El preprocesamiento puede hacerse en el lado cliente con Javascript o en el lado servidor mediante Rhino. Lo que permite básicamente es añadir variables a las hojas de estilo. Por ejemplo:

@backgroundcolor:white;
@textcolor:dimgray;
@textfont:Droid Sans,Arial,Helvetica,sans-serif;
html {
height:100%;background-color:@backgroundcolor;
}
body {
margin:auto;height:100%;font-family:@textfont;color:@textcolor;font-size:small;background-color:@backgroundcolor;
}

Sin el preprocesador habría que especificar el color de fondo white y el color de texto dimgray repetidos en html y en body.

Pure

La funcionalidad que me gusta de Pure es su herencia de los grids de YUI. Los grids son una forma de dividir la página verticalmente en fracciones del ancho. Por ejemplo
¼+¾ Los otros frameworks para diseño responsive como Zimit también pueden hacer esto, pero a mi Pure siempre me ha parecido el más práctico con el que comenzar.

Modernizr

Modernizr es un una librería que permite detectar si el navegador soporta o no una determinada funcionalidad. Se usa pues para variar el comportamiento en función de lo moderno (o no) que sea el navegador del usuario.

if (Modernizr.awesomeNewFeature)
    showOffAwesomeNewFeature();
else
    getTheOldLameExperience();

Otras librerías

Existen decenas de pequeñas librerías para tareas específicas: crear mapas con zonas clickables, pop-ups, etc. Ya en 2013 Juantomás publicó un enlace a una extensa lista de frameworks CSS3.

Gestión de la configuración

npm

El gestor de paquetes que se está estandarizando para Javascript es npm. npm viene incluído con Node.js (de hecho para instalarse npm hay que instalarse Node.js). npm permite definir modulos y almacenarlos en un repositorio desde el cual se pueden cargar dinámicamente mediante un comando require().

Bower

Por encima de npm es posible utilizar Bower. Bower se instala com npm y proporciona funcionaldiades específicas para la gestión de la configuración en aplicaciones web.

Require.js

Por último, una vez que se tienen instalados los paquetes en el servidor se pueden cargar dinámicamente en el navegador con RequireJS. RequireJS se puede usar con JQuery, Dojo y Bower.

Alternativas sintácticas

Existe una gran cantidad de lenguajes que pueden traducirse a JavaScript. Personalmente yo no he llegado a utilizar ninguno de ellos en producción pues todos me han parecido propuestas para cambiar el estilo sintáctico tipo C de Javascript por el de Python y Ruby (CoffeeScript), el de Haskell (PureScript), el de Lisp (ClojureScript), o el de C++ (Dart). Quizá una alternativa interesante sea TypeScript en tanto en cuanto no pretende como el resto cambiar la sintaxis del lenguaje sino permitir la anotación de tipos y la definición de interfaces y clases como extensiones al propio JavaScript. Por último, vale la pena echar un vistazo a las novedades en ECMAScript 6 que incluyen clases, cargadores de módulos y otras funcionalidades hasta ahora sólo disponibles a través de librerías y precompiladores.

Conclusiones

Desde la aparición de la WWW, ha habido un incremento constante de las funcionalidades presentes en el lado cliente. Este incremento en la demanda, no ha podido ser atendido con suficiente rapidez por los estándares. Por consiguiente, han proliferado muchas librerías y tampoco se ha llegado a un acuerdo sobre la mejor manera de utilizarlas.

Antes de empezar a escribir la aplicación hay que hacer una lista de requerimientos y mapearlos con las librerías que serán necesarias. ¿Es una aplicación web para gestión desde un desktop o debe tener soporte smartphone? ¿Presenta sólo páginas estáticas con algún efecto visual o carga contenidos dinámicamente mediante Ajax? ¿Requiere gráficos SVG o charting? ¿Necesita soporte multi-idioma? etc.

Para el principiante que no quiera complicarse lo mejor es probablemente empezar por JQuery, LESS y Pure. Bootstrap es una buena opción para aplicaciones de gestión que requieran muchos controles de entrada (botones, menús, pestañas, etc.)

AngularJS y React.js requieren algo de esfuerzo para aprender a utilizarlos el vale la pena sólo si las páginas deben cargar dinámicamente datos del servidor en respuesta a eventos generados por el usuario.

Por último, si usaste estas u otras librerías, deja un comentario sobre tu experiencia :)

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Tecnologías Libres | 1 comentario

Inteligencia emocional artificial

Leo en Wired algunas especulaciones sobre cómo la inteligencia emocional artificial podría cambiar nuestras vidas. La verdad es que no me contenta por completo el enfoque del artículo de Alain de Botton, de modo que voy a desarrollar mi propia versión sobre el tema.

Opino que algunos problemas de inteligencia artificial como la clasificación y la interpretación de imágenes y texto están resueltos. Y, si no lo están por completo, es cuestión de unos pocos años que se resuelvan hasta que sea imposible distinguir a una máquina de un humano excepto por la mayor eficiencia de la máquina en la resolución de este tipo de problemas.

Por otro lado, el comportamiento humano es muy difícil de emular. En parte porque casi siempre las máquinas carecen de información sobre el contexto y en parte porque la mayoría de las respuestas humanas a estímulos son irracionales. Los humanos sentimos antes de pensar.

Yo opino que las emociones son algo que la evolución puso en nosotros por buenas razones. Las emociones sirven esencialmente a cuatro fines:

1º) Tomar decisiones en ausencia de la información suficiente para tomarlas de forma racional.
2º) Forzar una cohesión social mediante la cual la supervivencia del grupo prevalece sobre la supervivencia del individuo.
3º) Incentivar la repetición de un comportamiento exitoso o desincentivar la de uno fallido.
4º) Apostar de vez en cuando por alternativas improbables de futuro pero que podrían reportarnos grandes beneficios en el caso de que acaeciese la opción menos probable.

Las emociones humanas primarias son seis: alegría, tristeza, miedo, amor, ira y sorpresa. Cada emoción básica se compone de emociones secundarias. Miedo (ansiedad, terror, …), tristeza (depresión, miseria, …). Algunas veces incluso se habla de emociones terciarias como furia, amargura, odio.

Las emociones son un mecanismo de respuesta genérico y automático frente a estímulos externos. Son algo así como la inflamación que se produce ante una infección bacteriana. El cuerpo no sabe ante qué está reaccionando pero sí sabe que cuando estás enfermo lo mejor es que te quedes en algún lugar calentito y no te muevas demasiado.

Cada emoción cumple una función. La ansiedad nos hace actuar con mayor antelación. La depresión podría ser una forma de que dejemos de empeñarnos en misiones imposibles.

No voy a entrar aquí en un estudio de todas las emociones y para qué sirve cada una, lo cual sería tema para un libro entero escrito por algún psicólogo experto. Mi argumento es que una vez especificada la función de cada emoción podría ser posible modelar cual debería ser la respuesta emocional de una máquina ante un estímulo y, además, usar la máquina para cuantificar la veracidad e intensidad del estímulo y calcular las probabilidades de cada escenario futuro. Y el cálculo sistemático de probabilidades es donde las máquinas pueden ser de tremenda ayuda. Por ejemplo, se ha comprobado que las mejores partidas de ajedrez no son las que juega una máquina sola o un humano sólo sino aquellas en las que el humano se apoya en la máquina haciendo sólo pequeños ajustes en la estrategia de vez en cuando, teniendo en cuenta la información sobre la personalidad de su oponente o arriesgándose a aprovechar una ventaja obtenida de forma temeraria.

La sistematización del estudio cuantitativo de las emociones serviría para hacer a los robots aparentemente más humanos. Me gustaría recalcar, aparentemente, puesto que aunque pudieran simular las emociones a las máquinas todavía les faltaría un nivel de autoconciencia del cual ahora mismo carecen por completo y, además, nadie (que yo sepa) tiene ni la más leve pista de cómo codificar.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Minería de Datos, Tecnologías Emergentes, ¿Dónde estamos? ¿Hacia dónde vamos? | Deja un comentario

Google y Microsoft liberan herramientas de inteligencia artificial

Casi de forma simultánea Google ha liberado Tensorflow y Microsoft ha liberado CNTK. Doos toolkits para la implementación de algoritmos de inteligencia artificial basados en redes de neuronas. Microsoft ya publicó el código de CNTK en abril de 2015 pero lo hizo sólo en su propio Codeplex bajo licencia AFL. Además, Microsoft ya liberó también DMTK en 2015, otro toolkit para machine learning genérico.

La herramientas liberadas, en si mismas, no son muy relevantes, más adelante explicaré por qué. Lo importante es la tendencia que ya apuntábamos en 2014 de la inteligencia artificial a convertirse en una utility.

La oferta de herramientas de deep learning ya es bastante extensa: Theano, Caffe, Mocha, DL4J, Torch, etc. Hasta donde alcanzan mis limitados conocimientos sobre inteligencia artificial, ni Google ni Microsoft aportan ninguna novedad disruptiva en la implementación. Microsoft insiste en que, según sus propios benchmarks, CNTK es mucho más eficiente que el resto de herramientas.

Google TensorFlow es una librería de bajo nivel heredera de DistBelief, similar en ciertos aspectos a Theano. El punto fuerte de Google, a mi juicio, es la documentación y los tutoriales, los cuales son asequibles incluso para personas sin conocimientos previos de inteligencia artificial basada en redes de neuronas. TensorFlow se instala fácilmente con pip install (el núcleo está escrito en C++ pero se usa desde Python). Los tensores (matrices multidimensionales) que maneja TensorFlow se almacenan como objetos numpy.ndarray. La versión libre de TensorFlow es multiplataforma y puede aprovechar las ventajas de usar GPUs pero es mono-nodo lo cual limita enormemente su escalabilidad. Además, algunos críticos dicen que TensorFlow es lento en comparación con otras librerías alternativas, aunque la imparcialidad de los benchmarks que yo he encontrado podría ser cuestionable. Por encima de TensorFlow y Theano se pueden encontrar herramientas para implementar deep learning como Keras o Pretty Tensor. Como alternativa a TensorFlow para deep learning con soporte nativo de entrenamiento distribuido e interfaz para lenguaje R, es posible utilizar MXNet.

Por último, también es posible encontrar herramientas de machine learning en plataformas SaaS como Wolfram o BigML.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Minería de Datos, Tecnologías Emergentes, Tecnologías Libres | Deja un comentario

Qué caracteriza a un mensaje viral

Hoy me llegó un email procedente de la hija de una amiga. En el correo me decía que mañana tiene un examen. Resulta que los exámenes en algunas universidades europeas han cambiado mucho desde que yo era estudiante. Ahora la prueba consiste en que le dan un problema a un alumno y 72 horas para presentar lo mejor que se le ocurra sobre cómo resolverlo empleando cualquier medio que encuentre a su alcance. Lo cual me parece fantástico porque a fin de cuentas es la forma en la que nos enfrentamos a desafíos reales en el mundo laboral.
Los detalles operativos del caso no los voy a comentar, pero tenía mucho que ver con cómo generar viralidad, que es sobre lo que voy a escribir en este post.

Existen no pocos expertos en marketing y publicidad que opinan que la viralidad es aleatoria y que básicamente no se puede predecir si un mensaje será un bombazo o pasará mayormente desapercibido. Yo tenía una opinión un poco menos pesimista hasta que triunfó Gangnam Style. Lo que queda en pie de las teorías comúnmente aceptadas sobre factores de viralidad es como sigue.

La viralidad de un mensaje depende de su contenido y de la forma empleada para distribuirlo. Factores desglosados a continuación.

Atributos que contribuyen a hacer un contenido viral

Valor social.

El valor social es la medida en la cual el contenido proporciona relevancia social al emisor o utilidad al receptor. La relevancia se adquiere porque el contenido sea:

• Novedoso
• Sorprendente
• Hilarante
• Controvertido
• Secreto
• Extremo
• Interesante
• Útil
• Bello

Curiosamente para mi, la capacidad para apreciar la belleza no es considerada como de gran valor social, excepto por algunas minorías en Flickr o Pinterest o incluso en Tumblr, aunque esos últimos suelen compartir otro tipo de belleza normalmente con bastante poco gusto.

La gente que no es profesional de los medios comparte cosas principalmente por necesidad de aceptación social. A veces simplemente también para sentirse menos sola. A las personas les gusta hablar, sobre todo, acerca de sí mismas. Es por esto que hay tantos escritores aburridísimos, pues no escriben sobre otro tema que no sean sus propios pensamientos, peripecias y emociones.

Emocionalidad.

En general, cuanta mayor sea la carga emocional de un mensaje mayor es la probabilidad de que se redifunda. Pero hay un límite. Cuando el contenido es demasiado impactante el redifusor tiende a autocensurarse o, al menos, a emitir una versión incompleta del contenido original. El grado de respuesta emocional al mensaje lo condicionan principalmente:

• Injusticias
• Calamidades
• Grandes logros
• Grandes sacrificios
• Historias enternecedoras
• Historias divertidas

No todas las emociones aumentan la viralidad de un mensaje. En particular, una carga de tristeza o negatividad hace que un contenido sea menos viral.

Lo más eficaz suele ser cabrear a la audiencia. Muchos periódicos y bloggeros se han hecho populares dándole a los lectores una ración diaria de motivos para pasar el resto de la jornada cabreados. Mas generar indignación es una peligrosa arma de doble filo poco recomendable como táctica de comunicación para la mayoría de los productos.

Lo siguiente más eficaz después de la indignación es causar risa.

Por último, existen emociones de alto impacto pero baja viralidad. Por ejemplo, se sabe desde hace mucho tiempo que poner bebés en los anuncios aumenta las ventas (tanto que su uso está restringido. Sin embargo, el porcentaje de población que hoy día no quiere saber nada sobre bebés es tan elevado que la viralidad de mensajes de retoños se limita casi siempre a los célebres casos graciosos como “David after Dentist” o “Charlie bit my finger. Again!”

Formato.

La mayoría de la audiencia prefiere los mensajes cortos en los que predomina lo visual sobre lo textual. Les encantan las “píldoras de contenidos”. Las listas cortas: “7 cosas que podrías hacer para…” También huyen de explicaciones largas y complejas (aunque sean veraces) en favor de explicaciones sencillas y rápidas (aunque incompletas).

Historia.

A la audiencia le gustan las historias. Aunque no suelen tener paciencia para escucharlas de golpe como quien se sienta a leer El Señor de los Anillos hasta que lo termine. Las historias deben irse desarrollando a lo largo de una colección de mensajes que el público objetivo pueda ir asimilando. La continuidad de una historia por entregas sirve para mantener la atención. Atraer la atención sobre algo nuevo es más sencillo de lo que se piensa pues el cerebro es especialmente sensible a las novedades. Sin embargo, mantener la atención es muy difícil y ahí es donde una historia que se extiende en el tiempo puede ayudar a mantener a la audiencia enganchada.
No voy a ahondar en la letra pequeña de qué hace grandiosa una historia, la cual se me escapa por no ser novelista, además de que requeriría un libro entero destinado a explicarla.

Distribución de mensajes virales

Además del contenido en sí mismo, la forma en la que se distribuye el mensaje también afecta a su viralidad.

Canales.

Los medios de información y las redes sociales se pueden dividir en dos tipos: de audiencia abierta y de audiencia restringida. Los abiertos son, por ejemplo, Twitter y Youtube. Los restringidos LinkedIn y Facebook. Las redes sociales de audiencia abierta son, en teoría mejores, pero en la práctica el gran dominador de tráfico inducido a webs es Facebook. Twitter tiene serios problemas para generar tráfico y sus tasas de conversión publicitaria son demasiado bajas.

No obstante la popularidad de las redes sociales, el mejor canal viral es, sin lugar a dudas, el boca a boca. Esto es debido a que:

a) La credibilidad de un mensaje es muchísimo mayor cuando procede de alguien de nuestra confianza

b) El boca a boca llega más veces en el momento oportuno a menudo como respuesta a un comentario del receptor. Es posible segmentar la publicidad, pero a menos que se cuente con el contexto de lo que está pensando el usuario (como lo tiene Google) es muy difícil acertar en el día, hora y minuto adecuado para dar un impacto publicitario eficaz.

Detonantes.

Algunos contenidos se vuelven virales debido a un evento que genera repentino interés. Los detonantes se pueden desencadenar de forma natural pero también es posible producirlos artificialmente publicando cierta información con el fin de que la gente hable de otra que está relacionada. También es posible, por cierto, producir detonantes de conversaciones en contra de productos de la competencia. El grado de eficacia de un detonante depende del contexto en el que se produzca.

Un detonante inesperado pero de eficacia bien demostrada es el ejercicio físico. La gente comparte más después de un periodo de actividad física (eso lo sabe y puede comprobarlo cualquiera que tenga un amigo runner).

Influenciadores, imitación y prueba social.

Los psicólogos se refieren a la “prueba social” como el fenómeno mediante el cual la gente asume el mismo comportamiento que otros en un intento de hacer lo correcto en cada situación. Una prueba social fácil de ver es aquella mediante la cual, en ausencia de otros criterios, las personas asumirán que un restaurante que está más lleno será de mejor relación calidad/precio que otro justo al lado que ande vacío.

Cuando el producto alcanza cierta masa crítica los propios usuarios se convierten en “testigos sociales” y atraen activamente a otros usuarios. Esto sucedió, por ejemplo, con Facebook.

Cuando el producto no tiene aún masa crítica, hay que conseguir que la masa imite a un reducido grupo de influenciadores. Esto lo explica muy bien Malcolm Gladwell en su libro The Tipping Point publicado en 2000. Gladwell enumera tres tipos de influenciadotes: los expertos, los conectores y los vendedores. También pone ejemplos sobre cómo las estrellas de cine promueven modas. Todo es un fenómeno de monos imitadores.
Los expertos pueden ser reconocidos como tales por varios motivos. A veces porque realmente lo son, otras porque ostentan un cargo para el que se presuponen ciertos conocimientos y acceso a información privilegiada. En muchas ocasiones sin embargo los expertos simplemente se han autoproclamado como tales y sus conocimientos reales a duras penas superan los de la media de su audiencia.

Hora y día de la difusión.

Para los contenidos de corta vida, el día y la hora importan a la hora de publicar. Evidentemente no quieres publicar un hallazgo científico la misma tarde que juega el Real Madrid. Las horas de mayor audiencia es muy fácil determinarlas con una herramienta de estadísticas web estilo Google Analytics. En el caso de este blog, por ejemplo, la mayoría de los asiduos leen algo de lunes a miércoles por la mañana. Y aparte existe otro grupo que llega buscando algo a través de Google cuyos visitantes están mucho más dispersos en franjas horarias.

Post relacionados:
Qué es un producto viral.
Lo que se comparte es diferente de lo que se lee.
Tipos de personas influyentes.
Cómo hacer propaganda 2.0.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Marketing Online | 1 comentario