Combatiendo a tus dragones

En verano de 1999 el pontífice Juan Pablo II sentenció que el Cielo no es “un lugar físico entre las nubes” y que el Infierno tampoco es “un lugar”, sino “la situación de quien se aparta de Dios”. Por supuesto, yo carezco de conocimientos de teología, de inspiración divina y de infalibilidad papal como para poder decidir si el Infierno es un lugar o no. Ni siquiera podría decidir si es endotérmico o exotérmico. Pero hay una cosa que sí sé con certeza: el Infierno es una experiencia privada. Cada uno tiene el suyo y no es igual al de ninguna otra persona.

El procedimiento para evitar acabar en el Infierno ha sido estudiado durante milenios por sesudos predicadores quienes han llegado más o menos a las mismas conclusiones, bien sea mediante no cometer ninguno de los Siete Pecados Capitales o por seguir el Óctuple Noble Sendero, el truco consiste esencialmente en hacer siempre más por ayudar al prójimo de lo que uno haría por ayudarse a si mismo aunque hay muchos matices en esto los cuales comentaré a continuación.

Tengo algunos buenos amigos que han desarrollado tendencias budistas. Y no les va mal. El peligro con el budismo es que empieza por la aceptación de que “nada importa nada”¹ y eso está peligrosamente cerca del nihilismo. También conozco de primera mano católicos acérrimos a quienes les va bien, con el riesgo justamente contrario de tomarse la vida como el calvario de camino al Cielo.

A caballo entre estos dos extremos están los emprededores. Quienes forman uno de los colectivos más estúpidos que conozco. Tampoco es que conozca muchos colectivos, ergo probablemente los hay aún más tontos, pero dado el porcentaje de fracaso de las start ups y los daños que causan al quebrar bien podríase concluir —a primera vista— que emprender es estupidez.

Mas el problema no es el emprendizaje en sí mismo sino la filosofía de la que están imbuidos los emprendedores. Herederos de las mejores tradiciones bélicas, los emprendedores se consideran a menudo a sí mismos como los sucesores de los guerreros de antaño. Craso error derivado de no haber tomado buena nota de lo que aconseja Tsung Tzu en El Arte de la Guerra: la mejor forma de ganar una batalla es no tener que combatirla. Y sin embargo, aquí tenemos a todos estos emprendedores a la conquista de un mercado (y a veces ni eso, simplemente a la conquista de una causa social) del modo más difícil.

Emprendes y, entonces, antes de que puedas percatarte, estás metido en un berengenal. Y no me refiero exclusivamente a emprender una empresa. Lo mismo emprendes una familia o una colección de cromos. ¿Dónde está escrito que haya que terminar una colección de cromos? pero tú, nada, erre que erre, a ver si consigues el cromo de Superman que es el único que te falta.

Llegado a este punto estás de puta madre, tus amigos envidian tu éxito y tu independencia, eres la estrella de la prensa y tus empleados te adoran. Pero en el fondo estás más de puta que de madre porque con la plata de los inversores le estás pagando a cada asalariado más dinero del que te llevas tú a casa a fin de mes, y tras cada cogorza tienes que mear en el depósito del Porsche para que funcione porque llenarlo de gasolina excede el máximo diario permitido por tu tarjeta de crédito.

Y, lo peor: aquello que pensabas que iba a ser una blitzkrieg de la cual saldrías rápidamente victorioso ha degenerado en una guerra de trincheras; calado, con fango hasta la rodilla, rodeado de ratas y con centenares de piojos corriendo por la camiseta.

Para esto no te habían preparado ¿verdad? (no es posible “prepararse” para una guerra de trincheras). Se les olvidó decirte que se combate “sin turnos y sin contar los días, ni los meses ni los años”².

Funciona más o menos de la siguiente manera: a las 5:30 a.m. aproximadamente, tanto si lo quieres como si no, tu cerebro entra en vigilia y empiezas a pensar: “¡joder! ¡joder! ¡joder! ¡joder!”. Esto no es un suceso aislado, sino que se repite sin contar los días, ni los meses ni los años.

Voy a compartir ahora mis consejos para combatir a los dragones, incompletos, pues aún los estoy ampliando y refinando, de momento es lo que tengo.

• Nada importa nada, todo es vanidad.

• Pase lo que pase, mantente calmado. Si pierdes la calma no podrás pensar y si no piensas estas acabado.

• Buscar el combate es estúpido. No hay ninguna gloria en la guerra. Las únicas buenas guerras son las que se ganan sin pegar un solo tiro.

• No desperdicies ninguna oportunidad de mostrar alguna bondad.

• No nuestres clemencia con tus enemigos, pues ellos no la tendrán contigo.

• La vida es como un periplo con maletas de un puerto a otro. Por mucho que intentes conservar el equipaje, tarde o temprano lo irás perdiendo. No se trata de ganar o perder. Vas a perder seguro porque te morirás de todas formas. La única diferencia que puedes marcar es a cuánta gente puedes ayudar o cuántos enemigos puedes abatir antes de caer finalmente tú mismo.

• Aprende a meditar (o a rezar, según prefieras). Es un proceso larguísimo que requiere años de práctica y es tremendamente coñazo (al menos para mi) pero compensa si consigues aprender.

• No descuides tu cuerpo. Las emociones pasan por el cuerpo. La mayor parte de cómo te sientes es debido a cómo se siente tu cuerpo.

• Puedes drogarte un poco. Todo el mundo necesita un chute de morfina algún día en que el dolor además de inútil es insoportable. Pero ten mucho cuidado con las drogas, puesto que te hacen creer que el mundo es un lugar mejor de lo que es en realidad, lo cual no es lo que deseas. Además, si abusas te volverás adicto o, peor aún, dejarán de hacerte efecto.

• Crea indicadores que te permitan saber si estás progresando o retrocediendo. No es tan importante si actualmente estás bien o mal como la tendencia. Según su biógrafos, Warren Buffet atesoró el 95% de su fortuna después de los 65 años.

• Ármate de una determinación inagotable. El éxito con frecuencia es simplemente continuar donde otros abandonaron. Lo que diferencia a un equipo grandioso de otro que simplemente es bueno es la capacidad de jugar 80 minutos perdiendo dos a cero y meter tres goles seguidos al final de la segunda parte porque el contrario ya no tiene aliento para correr más.

• Ponle límites a tu alcoholismo laboral. No trabajes más de doce horas al día. Ni más de seis días en semana.

• Moléstate sólo en conquistar territorios que puedas mantener. Cuando una persona adquiere algo desarrolla inmediatamente el miedo a perderlo. No asaltes posiciones indefendibles a largo plazo.

• Si te enfrentas a muchos enemigos, no los combatas a todos a la vez, colócate en una posición central y derrótalos uno por uno³.

• Relájate, nada está bajo control.

Posts relacionados:
El camino del guerrero samurai anónimo.
Saṃsāra corporativo y stress del emprendedor.
Cómo prepararse para el fracaso.
El emprendedor descuartizado.
España no es país para viejos.

¹ Esto se lo leí a Fernando Sanchez Dragó en El Sendero de la Mano Izquierda.
² Esto es del Credo Legionario.
³ Napoleón Bonaparte.

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

De la inteligencia artesanal a la inteligencia industrial

Nos encontramos probablemente al borde de un nuevo gran avance en Internet. Algo tan grande como cuando los buscadores pasaron de ser recopilaciones de enlaces seleccionados a mano estilo DMOZ a indexadores robotizados como Bing y Google.

La mayoría aún no se ha enterado, hasta tal punto que la inminente revolución todavía no tiene ni nombre oficial. Siguen despistados con la Internet de la Cosas, la cual, coincido con Alfredo citando a Tim O’Reilly, carece de potencia transformadora puesto que ningún gadget aislado (así sea un iPhone) puede transformar radicalmente sociedad.

La revolución consiste en la transición desde la inteligencia artificial propietaria y basada en ontologías construidas manualmente hacia la inteligencia artificial como utility y las bases de conocimiento generadas por bots, en cuya vanguardia se encuentra la base de conocimientos probabilística Google Knowledge Vault.

Antes de entrar en los detalles arquitectónicos de Knowledge Vault, daré un ejemplo de uso para poner de relieve el impacto potencial. La medicina es una ciencia estadística. Mucha gente no es consciente de ello, pero la medicina occidental no es más que un enorme conjunto de reglas “si esto entonces aquello” justificadas por pruebas empíricas. El problema es que a menos que exista un indicador singular muy claro (azúcar alto, colesterol alto) o una evidencia estadística abrumadora (tabaquismo → enfisema) lo médicos tienen grandes dificultades para interpretar conjuntos de síntomas que aisladamente son inconcluyentes. Las “enfermedades raras” son mucho menos “raras” de lo que su nombre da a entender, pero como la mayoría no son letales y su diagnóstico es tan complejo, nadie se ocupa de ellas. A menos que lo veamos en un gráfico convenientemente diseñado, los humanos somos especialmente malos encontrando patrones en grandes conjuntos de datos (de ahí la dificultad de hacer un Sudoku) pero resulta que los algoritmos de machine learning han progresado vertiginosamente en la tarea de hallazgo de patrones. Esto aplicado a la medicina podría alargar una década la esperanza de vida de la población de los países desarrollados y es por eso que IBM está poniendo tantos huevos en la cesta de Watson. Si quieres hacer una simple prueba de lo más básico que está por venir visita Wolfram Alpha y pregúntale algo como “LDL 140 male age 40″ para ver qué le pasa a tu nivel de colesterol a los cuarenta años.

Con respecto al text crunching, Google nunca ha sido fan del conocimiento recopilado y organizado a mano pero todavía depende de él en gran medida para interpretar lo que un usuario le está intentado preguntar al buscador. Las capacidades semánticas de Google se basan en Knowledge Graph que a su vez depende de Freebase y de Schema.org. Freebase es una base de datos de personas, lugares y objetos. Freebase contiene información del estilo “Francia es un país, su PIB es X billones de euros y el número de habitantes es Y millones”. Esto permite al buscador responder a preguntas tales como ¿cuál es el PIB por habitante en Francia? Schema.org es un sistema de tagging que permite a los sitios web proporcionarle este tipo de información al buscador, por ejemplo para decirle a Google que Avatar es una película de ciencia ficción dirijida por James Cameron, el contenido de la página web sería:

<div itemscope itemtype="http://schema.org/Movie">
<h1 itemprop="name">Avatar</h1>
<span>Director: <span itemprop="director">James Cameron</span></span>
<span itemprop="genre">Ciencia Ficción</span>
<a href="../movies/avatar-theatrical-trailer.html" itemprop="trailer">Trailer</a>
</div>

El problema es que la mayoría de la información en Internet no está publicada con tags como los de Schema.org que los buscadores puedan entender. E incluso cuando sí lo está suelen faltar muchos datos. Por ejemplo, en Freebase el 71% de las personas listadas carecen de ciudad de nacimiento. Entonces la estrategia experimental de Knowledge Vault es combinar las bases de datos de conocimientos validados por humanos con hallazgos de hechos realizados por bots y combinar la información mediante algoritmos de machine learning. Con este acercamiento Knowledge Vault ha recopilado 1.600 millones de hechos de los cuales 271 millones tienen una probabilidad superior al 90% de ser ciertos y 324 millones tienen una probabilidad superior al 70% de ser ciertos. Lo cual no es un porcentaje muy bueno de éxito (sólo el 20% de los hechos en Knowledge Vault se considera que tienen más de un 70% de probabilidades de ser ciertos). Pero el propio documento de Google sobre Knowledge Vault sugiere métodos para mejorar el porcentaje de aciertos que no se han probado porque son demasiado complejos y computacionalmente costosos, en particular el tratamiento de los hechos como sucesos independientes, lo cual no es cierto:
• Algunos hechos son mutuamente excluyentes.
• Algunos hechos están correlacionados.
• Algunos hechos son sólo temporalmente ciertos.
Por ejemplo, si se sabe que Barrack Obama nació en Honolulu entonces se sabe que nació en Hawaii. Pero la base de datos no contiene directamente esta información. Para responder a la pregunta ¿nació Barrack Obama en EE.UU.? se necesita un hecho sobre que Honolulu es parte de Hawaii y otro hecho sobre que Hawaii es parte de EE.UU. Y ser capaz de explotar dicha información encadenada.

La rama de este tratamiento semántico de la web en la que yo estoy involucrado desde hace algún tiempo a través de Virtualstock es la compatibilización de catálogos comerciales. Creo que los analistas yerran cuando piensan que la Internet de las Cosas consiste en cosas conectadas a Internet. La Internet de las Cosas es ¡cosas en Internet! Opino que la compra social y los móviles han desviado la atención sobre el enorme problema que todavía hoy es encontrar un objeto físico en Internet, y, aunque lo encuentres, compararlo con otros objetos físicos. No es posible tomar un laptop y decirle al buscador: “muy bien, aquí tengo este laptop ¿existe algun otro del mismo tamaño y con la misma potencia de procesador y disco pero que pese menos?”. Las implicaciones para el comercio son enormes pues la mayoría de productos, todavía hoy, no se pueden buscar y comparar online, lo cual crea imperfecciones de mercado que los proveedores explotan con pingües beneficios a costa de los clientes. El problema es en el fondo tan simple como que un proveedor lo llama “peso” y otro lo llama “peso unitario” y esta cantidad viene expresada en gramos, kilos, onzas o libras. De modo que teóricamente debería ser fácil informar al buscador pero es que a los propios proveedores a menudo no les interesa que exista un mercado de competencia perfecta donde los clientes puedan comparar y encontrar la mejor oferta con facilidad.

En conclusión, ya lo he publicado con anterioridad, pero creo que vale la pena recalcarlo, la próxima “gran cosa” en programación son lenguajes funcionales operando sobre vastas bases de datos de conocimiento, que, hasta ahora, eran muy difíciles de construir, pero es posible que en el futuro próximo no tanto.

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

Apalancamiento de productos y servicios

Hace no mucho estuve por primera vez aconsejando a start ups en el Reino Unido. Inglaterra es un mercado a caballo entre Estados Unidos y Europa. Uno de los aspectos en los que se manifiesta esta transición es en que las start ups tienden a crear rodajas más finas de funcionalidad. En España lo que funciona es la start up que tira “al bulto”, más que nada porque el mercado es demasiado pequeño como para que la mayoría de los jugadores de nicho puedan sobrevivir. En Inglaterra se tiende más hacia el posicionamiento norteamericano de la empresa que hace una cosa, y sólo una cosa, hasta el punto de que el nombre de una marca y el de la empresa que la vende es el mismo. En EE.UU. se lleva ser Twitter (140 caracteres y ya) o iPod Nano o Nvidia o el último grito en realidad virtual o, si tienes menos dinero, algo tipo WinZIP (comprime y basta). Esta hiperespecialización induce empresas que con frecuencia son incapaces de sacar buen partido de su fondo de comercio. Obsesionadas con solucionar un problema concreto o con acaparar la cuota de mercado de un nicho, las empresas pueden perder la oportunidad de expandirse, no porque operativamente no pudieren hacerlo sino porque están estratégicamente bloquedas en la mente de los miembros del consejo.

Cuando las start ups piensan en expansión casi invariablemente piensan en expansión geográfica, lo cual está bien (el mundo es plano) pero clásicamente se concebía la expansión en términos de “horizontal” y “vertical”. Las empresas asumían que no podrían salir de su país (imagínese un francés tratando de venderle a un alemán en 1938) ergo trataban bien de comprar a sus proveedores y clientes bien de hacer venta cruzada de productos y servicios complementarios.

A priori, podría parecer que bastante tiene una start up con sobrevivir en un nicho como para encima pensar en expandirse horizontal o verticalmente. Pero de hecho la expansión desde el principio puede ser la clave de la supervivencia. El ejemplo más fácil de observar es el de las asesorías jurídicas, contables, fiscales y laborales. Un abogado puede obtener cuantiosos beneficios de las costas de un juicio (sobre todo si las paga la parte contraria) pero los juicios tardan años en llegar a una sentencia, entonces lo que hacen los abogados es proporcionar servicios de asesoría fiscal, contable y laboral por una cuota mensual fija como medio de sacar algo de rentabilidad y mantener el contacto con los clientes que les contratarán asesoría jurídica. De hecho, algunas asesorías lo hacen incluso al revés y viven realmente de las igualas (cobrar una cantidad fija al mes a cambio de representar al cliente en cualquier pleito que pudiere surgir). Las asesorías tienen un caudal de ingresos mensuales que les cubren los costes fijos y mejoran el margen con los ingresos extra de las costas de los juicios.

Esta estrategia no es para nada exclusiva de las empresas de servicios, basta mirar la cuenta de resultados de Apple para darse cuenta de lo portentosamente rentable que es Apple Store. La sinergia iPod+iPad+Macbook fué un éxito rotundo. Y no sólo eso, el gran valor bursátil de Apple se debe en parte a que sus grandes inversores pueden invertir en toda la cadena de producción desde los discos de estado sólido basados en flash a las pantallas de alta densidad (Retina™) desarrolladas por Sharp, Apple genera verticalmente negocio en una gran cantidad de empresas proveedoras.

Sin embargo, es crucial diferenciar la venta cruzada de servicios del loss leader que vende a pérdida en la esperanza de que el cliente le compre otro producto a posteriori o de las empresas que se han diversificado mal y sin sinergias entre sus productos.

Un loss leader es Microsoft con su XBox. La videoconsola se vende por menos dinero del que cuesta fabricarla y el beneficio se obtiene realmente con los videojuegos, siempre y cuando la consola alcance un determinado volumen de ventas, claro.

El caso real más evidente de mala diversificación yo lo vi en España con algunas promotoras inmobiliarias, cuando en el pico de sus expectativas se metieron a comprar de todo, desde centros comerciales a geriátricos pasando por renovables y canales de televisión. Actividades que nada tenían que ver con el ladrillo y que acabaron casi siempre pagando muy caras pues aunque el construir un edificio puede darte acceso a suministrar quienes serán sus trabajadores se trata de negocios esencialmente diferentes.

Algunas empresas pueden permitirse el lujo de que su producto “vaca” sustente a varias decenas de productos “perros”. Google me parece un buen ejemplo. Tienen tanto dinero para “innovar” que simplemente se pueden permitir el lujo de lanzar, y hasta mantener, cualquier servicio que se les antoje, por majadero que sea en realidad. Para las start ups en cambio este tipo de experimentos caseros con la gaseosa son, en general, una mala idea ya que no se dispone de caja para pagar holgadamente el coste del fracaso.

En conclusión, según la teoría económica, quien gana dinero es quien controla el recurso escaso y, actualmente, casi siempre el recurso escaso es el cliente. Por consiguiente, la empresa que controla el cliente debe tratar de sacar el máximo rendimiento del mismo.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Modelos de Negocio | 1 comentario

Cómo orquestar el soporte post-venta TIC

En lo relativo al soporte post-venta, hay fundamentalmente dos tipos de empresas TIC: las que planean dar un soporte fanático y las que planean no dar ninguno en absoluto.

Las empresas que se decantan por el soporte fanático buscan la lealtad de sus clientes: que renueven siempre sus contratos y que hablen bien de la empresa a otros clientes potenciales; mientras que las empresas que pretenden no dar soporte buscan el máximo de rentabilidad por operación. No está demostrado, en mi opinión, que invertir en la relación a largo plazo con el cliente sea siempre la mejor opción. Los bancos y las telcos casi invariablemente trabajan sólo la relación a corto plazo y obtienen pingües beneficios sostenidos en el tiempo con esa política, no sé si gracias a sus oligopolios o a que los clientes también buscan casi siempre la mejor oferta a corto.

El soporte de calidad es muy costoso y a menudo difícil de facturar con buen margen. Por consiguiente, no es de extrañar que muchos emprendedores pretendan posicionar su start up en el grupo de las empresas que no dan soporte. Por desgracia para estos emprendedores, muchos de ellos también pretenden seguir una metodología lean y empezar con un mínimo producto viable. Y si el producto es lean entonces (asumámoslo) será también al menos un poco crapy y, por consiguiente, todo lo que se ahorre en desarrollo inicial se pagará después en soporte, es decir, el lean es sólo una forma de diferir el gasto, lo cual no es necesariamente malo (sobre todo cuando no se dispone de caja al principio) siempre y cuando se sea consciente de la cantidad de deuda técnica que se va acumulando. Y me gustaría ampliar el concepto de deuda técnica no sólo a lo que los agilistas entienden por ella sino también al conjunto de cosas que el producto debería hacer y no hace, definiendo “cosas que debería hacer” como que si le hechas una moneda a la máquina expendedora te entrege tu lata de Coca-Cola sin necesidad de que llames al de soporte para que le dé dos patas que hagan caer la lata del dispensador.

Metodologías Oficiales

Para los más puristas, las metodologías oficiales de servicio post-venta son el libro de soporte de servicio de ITIL e ISO 20000, aunque a menos que uno haya sido condenado a largos años de prisión sin nada mejor que hacer que leer, o la empresa pague curso para escaquearse una semana del trabajo, yo no le recomiendo a nadie que empiece por ahí.

Desconozco si existe algo similar a Agile para el soporte post venta. De manera que tendremos que ir improvisando. Aunque lo que sí puede encontrarse con facilidad son decenas de sistemas para la gestión de tickets de soporte tanto Open Source (Bugzilla, Redmine, Trac) como SaaS (Zendesk, JIRA). JIRA tiene muy buenas integraciones tanto con SaaS para Git como con productos de monitorización estilo Sentry, pero las herramientas podrían merecer un post entero sobre sus funcionalidades, de modo que aquí no me voy a detener en ellas, sino que haré un resumen de lo esencial a tener en cuenta cuando se organiza el soporte con independencia de la herramienta que se use.

Capas de soporte

Lo habitual es tener al menos dos capas del soporte: el que prestan los técnicos de soporte y el que prestan los desarrolladores.

Dependiendo de la cantidad de clientes que tenga la empresa, las incidencias pueden agruparse por proyecto, por cliente, por nivel de servicio contratado (silver, gold, etc.) o por el número de ocurrencias de la misma incidencia durante un intervalo de tiempo.

Es necesario que los programadores tengan un porcentaje de su tiempo destinado a corregir bugs. En una empresa sin un producto maduro, este porcentaje puede ser tanto como un 40% del tiempo. “Maduro” significa que el producto tiene al menos 4 años de vida y es estable sin necesidad de ninguna intervención a menos que se produzca un fallo en el hardware o en la red.

La clasificación de incidencias en dos “torrentes”: el torrente del departamento de servicio post-venta, y el “torrente” del departamento de I+D es de especial importancia en las empresas que venden SaaS pues en estas compañías no existe una relación directa entre la estructura coste del servicio y el esquema de facturación a los clientes. Por ejemplo, si se tienen 30 técnicos de soporte, 30 desarrolladores y 250 clientes todos en SaaS en fácil perder la cuenta de cuánto tiempo están dedicando realmente los desarrolladores a mejorar el producto versus cuánto tiempo están dedicando a corregir errores o implementar funcionalidades no facturables, o interesantes únicamente para un cliente, que sólo hacen el producto más costoso de mantener pero no más rentable a largo plazo.

Acuerdos de nivel de soporte

Las empresas que proporcionan servicios de pago están sujetas a acuerdos de nivel de servicio SLA (Service Level Agreements). El SLA dice básicamente que ante una incidencia X el proveedor responderá en un tiempo T y destinará los recursos R a la tarea.

Es importante recalcar que el SLA lo que garantiza es una respuesta y no una solución en un tiempo máximo.

Mi recomendación es que (a falta de requerimientos específicos del cliente) el SLA del soporte de primer nivel incluya sólo cuatro niveles de incidencias:

Crítica: El proveedor responderá en un máximo de 15 minutos.

Urgente: El proveedor responderá en un máximo de 2 horas.

Importante: El proveedor responderá en un máximo de 24 horas.

Media: El proveedor responderá en un máximo de 72 horas.

Qué, básicamente, se corresponden con lo que vas a hacer ahora mismo, lo que vas a hacer hoy antes de irte a casa, lo que puedes dejar para mañana, y lo que puedes dejar para la semana próxima. La existencia de una prioridad baja a mi personalmente no me parece conveniente ya que a nadie le gusta que le atiendan con baja prioridad ¿no?

Con respecto a los tickets del soporte de segundo nivel prestado por los desarrolladores, mi consejo es que se organicen los niveles de prioridad bien del 1 (ahora mismo) al 100 (cuando el infierno se congele) bien sin prioridades y sólo por sprints. El motivo es que es habitual que un programador tenga entre 10 y 40 tareas pendientes simultáneamente. Luego la disponibilidad de un rango amplio de prioridades permite a los gerentes y técnicos de soporte ver con claridad qué estará haciendo el desarrolador en el futuro próximo. Alternativamente, o complementariamente, cada tarea se puede asignar a un sprint o (si es muy urgente) a un parche (hotfix). Con sprints cada dos semanas pues lo que sabe el observador es si una determinada funcionalidad o corrección estará disponible tras el sprint del próximo viernes o tendrá que esperar dos semanas adicionales a menos que consiga meterlo en un parche urgente.

La asignación de prioridades a las incidencias debe hacerse siempre desde la óptica de los daños que está causando en el cliente y no desde la óptica de cuán grave es del desarrollador. Esto lo puedo ilustrar con un ejemplo reciente: desde hace meses teníamos un sistema en funcionamiento para la gestión de órdenes de compra, uno de los campos de estas órdenes es el código aduanero, este código aduanero no estaba siendo rellenado por el sistema pero, por casualidad, todos los usuarios sólo hacían compras domésticas ergo no necesitaban dicho código, hasta que un día vendimos el uso a un cliente y sus proveedores que hacían órdenes de compra internacionales, inmediatamente llegó un reporte de error que decía “el código aduanero no está siendo rellenado”, revisamos el sistema y encontramos que el error era cierto pero, como llevaba sin funcionar desde el principio de los tiempos, no le dimos importancia al hallazgo; en pocos días empezaron a acumularse cetenares de órdenes de compra que no podían despacharse por falta del código aduanero, y para cada órden de compra el proveedor y el cliente tenían que comunicarse el código por email o por teléfono, lo que generaba horas perdidas entre el cliente y sus proveedores para rellenar un campo que debería estar en el sistema desde el principio, la moraleja es que lo que desde el equipo de desarrollo se veía como un nimio mal funcionamiento para el cliente era un error gordísimo que había que corregir perentoriamente.

Devops

En teoría, la correción de bugs debería ser siempre más prioritaria que la introducción de nuevas funcionalidades. En la práctica lo que sucede es que a menudo algunos desarrolladores son considerados (erróneamente) como demasiado valiosos para que pierdan el tiempo corrigiendo bugs. Esto es un error, y, de hecho, en las grandes empresas como Microsoft, Google o Facebook se penaliza mucho más la introducción de bugs de lo que se premia una brillante productividad, y, además, el que lo rompe lo arregla. La pega de este sistema es que los programadores pueden argumentar que no produjeron los story points del sprint porque estaban corrigiendo bugs o, inversamente que no pudieron corregir los bugs porque tenían que entregar los story points.

Si no es el caso que cada programador tenga que arreglar siempre los errores que haya introducido entonces mi opinión es que lo mejor es organizar grupos de DevOps (development & operations) en los cuales un grupo de programadores presta el soporte de segundo nivel y otro se encarga de los nuevos desarrollos. Si la empresa es lo bastante pequeña es bueno que los turnos de devops sean rotativos de manera que nadie se acostumbre a no innovar ni desarrollar nada nuevo ni tampoco sólo a desarrollar sin sufrir nunca las consecuencias de la falta de cuidado programando.

Monitorización

Cualquier sistema cuya misión sea otra que la de matar a los técnicos de soporte de un infarto debe contar con sistemas de monitorización. La monitorización debe ser de dos tipos: pasiva y activa.

La monitorización pasiva consiste en alertar de errores que se han producido. Por ejemplo, cuando salta un error 500 en una página web, o el servidor de repente no es accesible o falla una transacción de escritura en la base de datos.

La monitorización activa consiste vigilar que el sistema se está comportando con normalidad. Por ejemplo, que el número de páginas servidas por minuto se mantiene dentro de un rango, pues lo contrario podría indicar un ataque o un fallo en algún DNS que impide alcanzar el servidor. O contar el número de pedidos que se han enviado a cada dirección postal en la última semana por si alguien está haciendo compras fraudulentas.

Gestión Emocional del Cliente

En la teoría, las herramientas deben permitir que el proveedor mantenga una conversación con el cliente a lo largo del tiempo con independencia de quienes sean los interlocutores de las partes. En la práctica es mejor asignar algo así como el “técnico de soporte de cabecera” del cliente de manera que los interlocutores de las partes se conozcan y estén acostumbrados a trabajar juntos. Según todos los estudios la mayoría de los clientes prefieren el soporte telefónico. Yo personalmente lo detesto como usuario, pero debo ser la excepción que confirma la regla. Lo fundamental para gestionar al cliente es que no se sienta nunca abandonado. Si abre una incidencia crítica hay que responderle inmediatamente aunque sólo sea para decirle “OK, estamos en ello…” y si tiene una incidencia abierta que se está demorando también hay que llamarle para informarle de que se sigue trabajando en ella aunque no se haya producido ningún avance significativo.

Algunos gurús del CRM afirman que los clientes quieren soluciones, no explicaciones. En mi experiencia, esto, en general, no es cierto. Los clientes pueden tolerar muchísimo más los errores y las deficiencias en el servicio si entiende la causa de ellos. Y, aún más que eso, los clientes veteranos en comprar servicios TIC no sólo quieren saber por qué sucedió algo sino también las medidas que se van a adoptar para que no vuelva a suceder en el futuro.

Métricas

El tratamiento estadístico de defectos software es una ciencia en sí misma con estándares como ISO/IEC 25010 o IEEE 1061-1998. Aquí sólo voy a repasar lo esencial que debe contener un cuadro de mando con KPIs de métricas de soporte.

Se deben recoger tres tipos de métricas: financieras, operativas y de satisfacción del cliente. Voy a omitir algunas métricas clásicas en atención al cliente que no son propiamente aplicables a empresas TIC tales como el número de incidencias entrantes por canal o la tasa de clientes que cuelga el teléfono antes de ser atendidos por un técnico. Si la empresa es de las que aspira a no prestar ningún soporte en absoluto entonces el objetivo es que el cliente se resuelva él mismo la incidencia y se miden cosas como cantidad de veces que el cliente fué capaz de encontrar una solución mediante el uso de un buscador o inteligencia artificial, yo personalmente detesto cuando intento hablar con un humano y me contesta R2D2, de modo que ni voy a comentar las métricas de calidad de los agentes robotizados de soporte, si la empresa aspira a no prestar soporte entonces es que en primer lugar el cliente no debería estar en necesidad de buscar ninguna ayuda.

• Margen: Diferencia entre ingresos y gastos por soporte.

• Coste de la mano de obra: Coste salarial por hora multiplicado por número de horas imputadas al soporte.

• Incidencias por unidad de tiempo: Es normal que a medida que la empresa crece crezca también el número de incidencias de primer nivel (cosas del estilo “he perdido mi contraseña” etc.) lo que no debe crecer al mismo ritmo son las incidencias que traspasan el primer nivel y llegan al segundo pues esto indica que el producto se está volviendo imposible de mantener. El número de incidencias por unidad de tiempo, en general, se puede decir que será igual o superior al período de tiempo inmediatamente anterior. Es decir, sin en una semana se han descubierto 30 bugs entonces hay que presuponer que en la siguiente se encontrarán 30 más.

• Nuevas incidencias por release: Correlacionadas con los story points de manera que se aprecie cuantos bugs por story point se han introducido en cada release. Ya lo he comentado al referirme a la métrica de incidencias por unidad de tiempo pero es tan importante que lo repetiré: la tendencia en el número de incidencias de segundo nivel por release debe ser decreciente, lo contrario significa que se está dirigiendo el desarrollo del producto hacia una situación que lo hará imposible de mantener.

• Grado de cumplimiento del acuerdo de nivel de servicio: Porcentaje de incidencias que se respondieron dentro de los límites de tiempos según su prioridad fijados por el SLA.

• Incidencias resueltas en el primer contacto: Es decir, aquellas para las que el cliente obtuvo una solución exitosa en la primera respuesta que se le proporcionó.

• Incidencias no resueltas acorde a su severidad: Aunque el SLA no lo especifique, debe existir una cota máxima de tiempo interna para resolver cada incidencia según su severidad.

• Tiempo medio de resolución: Para aplicar esta métrica conviene eliminar las incidencias resueltas en el primer contacto y las incidencias no resueltas acorde a su severidad para no distorsionar la media.

• Tasa de conversión de las incidencias de nivel 1 en incidencias de nivel 2: Esto mide la calidad de las herramientas de que disponen los técnicos de soporte las cuales les permiten solucionar el problema del cliente sin necesidad de perturbar al equipo de desarrollo.

• Número de incidencias abiertas por técnico: Se cuentan sólo las que están abiertas, no las totales, como una medida de cuántas tareas simultáneas debe realizar cada persona.

• Número de incidencias abiertas por cliente: Permite relacionar el nivel de ruido causado por un cliente con la cantidad de dinero que está pagando por el soporte.

• Grado de satisfacción del cliente con el servicio: Se suele obtener mediante una breve encuesta realizada tras el cierre de la incidencia estilo “En una escala del 1 al 10 usted ¿cómo valoraría la calidad del soporte recibido?”.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Adoptando Sw Libre en una Organización, Casos Prácticos, Organizando la Comunidad. Modelos de Desarrollo | Deja un comentario

Repaso didáctico sobre machine learning

Iba a escribir un post sobre Google Knowledge Vault como continuación del que escribí sobre Watson y Wolfram Language pero me he dado cuenta de que sólo con la introducción que dí al científico de datos es muy difícil entender los fundamentos que hay detrás de recientemente renovado interés por el aprendizaje automático. De modo que voy a hacer un receso con fines didácticos para el que le interesen los fundamentos sobre cómo aprenden las máquinas. Existen centenares de algoritmos, algunos bastante complejos. Aquí sólo hago un repaso sobre los principios elementales de los métodos más simples y populares.

Percepción

La percepción es la organización, identificación e interpretación de información sensorial con el propósito de representar y entender el entorno. Veamos un ejemplo sencillo sobre algo que se puede enseñar a una máquina a que identifique en una fotografía.

Scene Labeling

Aprendizaje

Lo que se entiende por aprendizaje en el contexto que nos ocupa es el hallazgo de una función h(x) —llamada frecuentemente hipótesis— que dado un vector de entrada x proporcione una estimación lo bastante buena de otra cantidad relacionada con x. Por ejemplo, para una casa sea x = (metros construidos, dormitorios, baños, planta, código postal, fecha de construcción, fecha de última reforma) y el valor que h(x) debe aproximar lo mejor posible es el precio de mercado p.

El entrenamiento se realizará de forma progresiva refinando progresivamente la función hipótesis mediante otra función de coste que en el ejemplo del precio de las casas podría ser un cálculo de mínimo error cuadrático. Si tenemos n transacciones de compra-venta para las que se conocen las características de las casas y el precio real p de la operación el error cuadrático será:

1/2n × ∑ (h(xi) – pi

Es decir, se trata de encontrar la función de hipótesis que hace mínimo el valor de la función coste, idealmente cero, si se pudiese predecir con total exactitud el precio de compra-venta.

La búsqueda del mínimo para la función coste se lleva a cabo mediante un método conocido como descenso del gradiente en cuyos detalles técnicos no voy a entrar pero, que visualmente, consiste en encontrar el punto más bajo de la superficie que en siguiente gráfico representaría el valor de la función coste para una función hipótesis con dos parámetros escalares de entrada.

Gradiente

Tipos de aprendizaje automático

Todo el mundo lo llama machine learning, abreviadamente ML, de manera que me referiré a él en lo sucesivo como ML. Hay dos tipos principales de ML: aprendizaje supervisado, y aprendizaje no supervisado con varios subtipos.

El aprendizaje supervisado consiste, por ejemplo, en proporcionarle a la máquina dos conjuntos de imágenes etiquetadas perro y gato. Entonces la máquina debe encontrar una función que aplicada a una nueva imagen clasifique si es un perro o un gato.

La recompensa por la señal supervisada puede ser diferida. Por ejemplo, para el caso de aprender a encontrar la salida a un laberinto. Esto se conoce como reinforcement learning (RL). En el caso más general de RL incluso se desconoce la forma del mundo sobre el que se trabaja (la forma del laberinto). Esto acarrea la necesidad de elegir estratégicamente sobre cuánto tiempo se emplea desvelando la forma del laberinto y cuánto tiempo se emplea aplicando lo que se sabe sobre cómo salir de él (compromiso entre exploración y explotación).

En el aprendizaje no supervisado no se suministran categorías inicialmente a la máquina. No es una tarea de clasificación sino de organización para descubrir la estructura de los datos para visualizarlos o comprimirlos mejor. Examinando la estructura hallada por la máquina es cómo se extraen los conceptos, abstracciones, factores, etcétera. que explican el significado de los datos.

Expresado de otra forma, en el aprendizaje supervisado existe un conjunto de variables X1, X2, …, Xn y la misión es predecir el valor de otra variable Y. En el aprendizaje no supervisado se trata de encontrar patrones en el conjunto de valores posibles para X1, X2, …, Xn.

Unsupervised Learning

Existen dos grandes subtipos de aprendizaje supervisado: regresión, en el cual el valor predicho cae dentro de un rango (estilo ¿cuánto tiempo? ¿cuántas unidades?) o clasificación (estilo ¿es el tumor canceroso?).

A su vez, el aprendizaje no supervisado puede dividirse en dos subtipos: el clustering, que es esencialmente organizar los datos en grupos, y los algoritmos que persiguen proyectar los datos en un espacio de dimensión inferior y en este último caso las dimensiones deben interpretarse como factores semánticos.

Es posible que se necesiten aprender varias tareas simultáneamente. En el más famoso concurso de ML hasta la fecha, el premio del millón de dólares de Netflix al mejor recomendador de películas, lo óptimo es poder contar con las opiniones que cada usuario ha realizado sobre las películas que ha visto, y comparar dichas opiniones con las de otros usuarios para averiguar qué le gustará ver. Pero, por otra parte, existen usuarios recién llegados quienes no han publicado ningún rating. A estos usuarios por supuesto también se desea ofrecerles alguna recomendación por otro medio que no sea cotejar opiniones. Por consiguiente, se necesita alguna forma estadística de encontrar su similitud con otros usuarios. Evidentemente, ambas tareas están relacionadas. El truco para conseguir mejores modelos con ambas es no compartir demasiado ni demasiado poco entre ellas, lo cual depende de cuántos datos se disponga y cuánto conocimiento previo para el ajuste fino de cada tarea. Esto se conoce como multi-task learning.

Modelos paramétricos vs. no paramétricos

Los modelos paramétricos son aquellos que asumen que los datos de entrada se distribuyen con una probabilidad que puede ser descrita mediante un conjunto de parámetros. En los modelos no paramétricos la complejidad de su espacio de hipótesis crece según lo hace el número de instancias de datos a considerar y no se puede “comprimir” en un conjunto de parámetros.

Los modelos paramétricos, en general, son computacionalmente más eficientes que los no paramétricos. También pueden ser predictivamente mejores si las hipótesis ad hoc sobre la distribución de los datos son correctas. Pero si las hipótesis son falsas, la capacidad predictiva resulta seriamente mermada por lo cual lo modelos paramétricos son menos robustos que los no paramétricos.

k-NN

k-NNk-NN es el acrónimo de k Nearest Neighbors classifier. Es el método más simple no paramétrico de aprendizaje supervisado. Los datos de entrada tienen la forma {Xin, Yn} donde Xin es el valor del atributo i para el caso n e Yn es la etiqueta a la que debe adscribirse ese caso. También se necesita una métrica de similitud entre casos (distancia) d(Xm, Xn) donde, por convenio, generalmente a mayor d mayor similitud. La clasificación es sencilla, para cada nuevo caso Xp se calcula la distancia d(Xp, Xn) para todo caso en el conjunto de datos y se toman los k casos más similares. A continuación se toman las etiquetas de esos casos y se asigna al nuevo caso la etiqueta más popular entre sus vecinos. k-NN sufre lo que se conoce como “la maldición de las altas dimensiones”. Es posible que al introducir nuevas variables se deteriore la capacidad predictiva del algoritmo, por consiguiente, se necesitan técnicas para elegir las características relevantes que podrían ser objeto un artículo entero en si mismas.

Naive Bayesian

Naive Bayesian es la técnica empleada habitualmente por los filtros antispam. Consiste en crear una serie de reglas con una probabilidad asociada a cada una. Por ejemplo, si el título del mensaje contiene la palabra “Viagra” entonces tiene un 80% de probabilidades de ser spam. Las reglas pueden votar a favor o en contra de que el correo sea spam. Se considera que las probabilidades son independientes unas de otras (de ahí el adjetivo naive) aunque se pueden crear reglas combinadas estilo “si contiene la palabra Viagra y las palabras farmacia online”.

El clasificador bayesiano se puede entrenar progresivamente para mejorar sus resultados. No voy a poner aquí las matemáticas de cómo se hace, pero la idea intuitivamente es sencilla: las probabilidades inicialmente se estiman contando cuántos correos en el juego de entrenamiento son spam y qué reglas cumple cada uno; luego, dado un nuevo correo, el operador humano lo clasifica como spam o no spam. Entonces la máquina recalcula las probabilidades para las reglas teniendo en cuenta la nueva información proporcionada por el operador.

Hay otros detalles relevantes para que el clasificador bayesiano funcione bien. En particular, la regularización, que tiene que ver con cómo evitar que el peso de una regla sea superior al de todas las otras juntas. Y los umbrales de “presunción de inocencia” para no declarar spam correos que no tengan realmente una probabilidad muy alta de serlo.

Máquinas de Soporte Vectorial

En inglés support vector machines (SVMs). Se trata de otro conjunto de algoritmos de clasificación lineal con aprendizaje supervisado alternativos a las redes de neuronas formadas por perceptrones. Como en el caso de las redes de neuronas, se trata de encontar un hiperplano que separe dos clases de objetos. Las SVMs son el ejemplo más popular de los métodos kernel.

En el caso de que las clases sean linealmente separables, para hallar el hiperplano que las separa se toman un conjunto de casos, llamados vectores de soporte (en el gráfico v1 y v2) y se elige el hiperplano que proporcione los mayores márgenes de distancia desde el hiperplano a los vectores de soporte más próximos. En el ejemplo, tanto el plano z1 como z2 podrían servir para distinguir las clases, pero z2 es mejor porque el margen es más amplio.

Support Vector Machines Margins

En el caso de que las clases no sean linealmente separables lo que se intenta hacer es proyectar los casos a un espacio de dimensión superior donde sí sean linealmente separables.

Input and Feature Spaces

El perceptrón

El perceptrón es la neurona artificial. El perceptrón funciona como un discriminador lineal. Es una variante de aprendizaje supervisado para clasificación binaria. La forma más fácil de entender el concepto es mediante un dibujo. Veamos la representación en un plano de las funcionas booleanas AND y OR.

And Or

El perceptrón de una capa sólo puede distinguir las funciones si sus resultados pueden separarse mediante una recta. Si los patrones no son linealmente separables (como en el caso de la función XOR) entonces hay que emplear redes de neuronas multicapa con funciones de activación no lineales.

XOR

Las redes multicapa tiene una capa de entrada una capa de salida y una o más capas intermedias. La capa de entrada tiene tantos perceptrones como dimensiones tenga el vector que representa el caso a clasificar. Las capas de neuronas se conectan hacia delante mediante “pesos” ajustables. Cada neurona de cada capa está conectada con todas las neuronas de la siguiente aunque las conexiones se pueden desactivar asignando un peso cero al enlace. El aprendizaje en el caso de las redes neuronales consiste en encontrar el peso correcto para cada neurona.

Multilayer neural network

Aunque se introduzcan capas intermedias, si los perceptrones usan funciones de activación que sean lineales, entonces la salida siempre será una funcion lineal de la entrada (dado que cualquier combinación de funciones lineales es otra función lineal). Por ello, casi todas las redes de neuronas usan funciones de activación no lineales para los perceptrones: logística, hiperbólica, escalón, base radial, gaussiana, etc.

Los perceptrones multicapa no lineales se pueden usar como aproximadores universales para cualquier función. Es decir, dada una función que devuelve valores aleatorios a partir de las entradas, es posible entrenar una red multicapa de perceptrones que produzca una buena aproximación. O, expresado de otra forma, se puede implementar cualquier algoritmo con una red multicapa lo bastante lo bastante grande.

Redes de neuronas artificiales

FFN: El tipo más simple de red neural es la feedforward en la que la información fluye en una única dirección, desde la capa de entrada a la de salida a través de las capas ocultas. No hay caminos cíclicos entre las conexiones. Con frecuencia se usa la sigmoide como función de activación. Las feedforward utilizan como método de aprendizaje supervisado la retropropagación (backpropagation). Para cada salida se calcula la diferencia entre la respuesta correcta y la obtenida y se reajustan hacia atrás los pesos de los perceptrones de manera que el reajuste minimice el error buscando el mínimo mediante una variante del método del gradiente presentado con anterioridad conocida como descenso del gradiente incremental (o estocástico) en el cual los pesos se actualizan después de considerar cada ejemplo de entrenamiento en lugar de esperar a considerarlos todos. El gradiente de la función coste h(x,y) en un punto (x, y) es un vector que sale del punto y sus componentes son las derivadas parciales de la función en dicho punto. grad(h) = ∇h = (∂h/∂x,∂h/∂y) Una pega de la retropropagación es que es posible que existan mínimos locales del gradiente donde el aprendizaje se quede atascado sin encontrar el mínimo global.

Autocodificadores: Los autocodificadores (autoencoders) son otro subtipo de feedforward de tres capas que se usa como componente en deep learning.

CNN: Las redes neuronales convolucionales (convolutional neural networks) son otro subtipo de feedforward utilizado para el reconocimiento y clasificación de imágenes. Las CNN simulan cómo funciona la corteza visual primaria (V1) de un cerebro biológico. En las CNN cada neurona de una capa no recibe conexiones entrantes de todas las neuronas de la capa anterior, sino sólo de algunas.

RBF: Las redes de base radial (radial basis function) tienen siempre tres capas: entrada, oculta y salida y producen una salida que calcula la distancia de la entrada a un punto elegido como centro. La salida es una combinación lineal de las funciones de activación radiales utilizadas por las neuronas individuales. Una ventaja de las RBF es no presentan mínimos locales donde la retropropagación pueda quedarse encallada como en las feedforward de perceptrones multicapa.

RNN: En las redes neuronales recurrentes (recurrent neural networks) las neuronas pueden estar conectadas hacia adelante o hacia atrás. Puede que la conexión bidireccional esté limitada a neuronas de capas consecutivas (SRN simple recurrent networks) o que no exista ninguna restricción hasta el punto de que todas las neuronas estén conectadas con todas, aunque las redes con interconexión total se han demostrado hasta la fecha inútiles para fines prácticos. Las SRN de tres capas se conocen también como redes Elman. Las SRN tienen como ventajas sobre las feedforward que para una salida objetivo dada con un margen de error la Elman puede converger más rápido hacia el coste mínimo que la feedforward. Es decir, el número de de iteraciones que los datos de entrenamiento y posteriormente los datos de prueba deben realizar dentro de la red es menor. El porcentaje de efectividad de las Elman también es mejor debido a que los caminos de retroalimentación generan un mejor comportamiento no-lineal durante el aprendizaje supervisado. Sin embargo, estas ventajas tienen un impacto elevado en el tiempo de
procesamiento necesario.

Otro subtipo importante de RNN es Máquina de Boltzmann inventada por Hinton y Sejnowski en 1985. En 1986 Paul Smolensky introdujo la máquina de Boltzmann restringida (RBM). La RBM tiene tres capas en la que cada neurona de una capa puede estar conectada bidireccionalmente con las neuronas siguiente capa, pero no existen conexiones entre las neuronas de la misma capa.

Deep Learning

Deep Learning es la etiqueta para un conjunto de algoritmos que habitualmente se emplean para el entrenamiento no supervisado de redes de neuronas multicapa.

Desde que hace aproximadamente una década Hinton y Salakhutdinov descubrieron un algoritmo eficiente para entrenar un tipo de redes de neuronas multicapa conocida como deep belief nets, se ha producido un avance espectacular en el reconocimiento de imágenes, escritura manual, lenguaje hablado y traducción automática.

La popularidad del deep learning se basa en que el método conocido como descenso por gradiente estocástico (SGD) puede entrenar eficazmente redes neuronales de entre 10 y 20 capas para resolver problemas que ocurren en la práctica. Lo cual es relevante porque el reajuste de pesos en una red neuronal a partir de los errores es un problema de optimización no convexa NP-Completo.

Voy a dejar esta introducción (incompleta) aquí. A quien le queden fuerzas para seguir leyendo, la explicación continúa de forma muy asequible en el post ¿Qué es y cómo funciona “Deep Learning”? de Rubén López.

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

Tipos de presidentes ejecutivos

A lo largo de mi carrera creo que me he topado con todos los tipos de presidente ejecutivo de una compañía de base tecnológica. El presidente dospuntocerista es un tipo muy especialito de persona que requiere un tratamiento muy específico en función de su tipología que describiré a continuación.

El pajero mental

Al pajero mental se le reconoce porque pasa largos períodos de tiempo fuera de la oficina, en su casa o en un retiro espiritual en el Tíbet meditando acerca de lo que quieren los clientes. El pajero mental empezó su ascenso cuando, por casualidad, una de sus pajas resultó ser lo que quería un cliente y en poco tiempo uno o dos campeones produjeron un mínimo producto viable que implementaba exitósamente la idea. Cuando la empresa alcanza cierto tamaño el pajero mental va por libre y las operaciones reales las gestionan los clones de los campeones y un equipo gerencial reclutado gracias al capital riesgo. El pajero mental es, de hecho, una persona bastante inteligente y carismática. Es sorprendente como el pajero puede redescubrir por su cuenta ramas enteras de la ciencia cuando ha tomado suficiente peyote mezclado con ayahuasca aunque, por desgracia, sus ideas suelen llegar a un mercado que las conoce (y las aplica) desde hace diez años. No obstante lo anterior, nunca y por ningún motivo hay que cuestionarle abiertamente al pajero la cualidad disruptiva de sus ideas. La misión vital del pajero es convertirse en un líder visionario que da charlas e inspira a la gente para que alcance su verdadero potencial.

El supertacañón

El supertacañón nunca tuvo ni idea de los fundamentos de la tecnología que vende, lo suyo son las finanzas. Se refiere al departamento de recursos humanos como “departamento de recursos porcinos” y es un hacha con el Excel, sobre todo a la hora de cobrar el máximo a los clientes y pagar lo mínimo a los empleados y proveedores que es cómo se mantiene su negocio. El supertacañón es el Terminator del departamento de operaciones. La misión vital del supertacañón es vender la empresa el día hora, minuto y segundo que alcance su máxima valoración y usar el dinero para montar otra empresa con la que hacer lo mismo.

El galáctico

El galáctico era anteriormente un trepa en la mayor empresa de la competencia. Era tan buen trepa que llegó tan alto que no pudo ascender más y entonces un headhunter lo reclutó a golpe de talonario. El galáctico es duro e implacable y a menudo goza de una excelente reputación en el sector. El problema con el galáctico es que el ego no le cabe en el cuerpo y, como hasta la fecha nunca ha cometido ningún gran error, el primer fiasco que cometerá será en la empresa que le han encomendado dirigir y, debido a su exceso de confianza en sí mismo, normalmente es un fiasco brutal. La misión vital del galáctico es demostrar que es más listo y competente que los demás.

El cuñado

Al cuñado le otorgaron la presidencia porque hace unas décadas dió el braguetazo correcto. O, por casualidad, resultó ser el primo de un tipo listo. El cuñado es un Lord Sith que mantiene el poder utilizando al departamento de recursos humanos como si fuese la Estrella de la Muerte. La misión vital del cuñado es probar tantos habanos, whisky y putas como le permita la tarjeta black de la empresa.

El buscavidas

El buscavidas es la versión adulta del niño hiperactivo. Excitable, éstiloso, bullicioso y, aparentemente, ingénuo, el buscavidas sobresale en la búsqueda de capital riesgo al que mesmeriza con palabras grandilocuentes y un blog que se sale. La misión vital del buscavidas es salir en la portada de la revista Times.

El nautilus

El nautilus consiguió alzarse con el poder mediante la aplicación sistemática y repetida de una técnica muy sencilla: permanecer en su sitio y mantener la boca cerrada. De apariencia tímida y apocada, el nautilus es, sin embargo, tan letal como un submarino nuclear. Nadie conoce la misión vital del nautilus.

El experto

El experto inició su andadura siendo el profesional más competente y de reconocida habilidad en su sector. De alguna forma atrajo a colegas como él y montaron una empresa que un puñado de clientes adinerados estaban siempre ansiosos por subcontratar. El experto suele aburrirse mortalmente en las reuniones, mediando de mala gana entre sus mandos intermedios. La misión vital del experto es que le dejen volver al laboratorio de dónde salió.

El legionario

El legionario es un tipo salido de la nada que empezó como soldado raso. Con unos huevos cuadrados y tanta mala leche como ganas de cambiar el mundo, el legionario ascendió de tropa a brigada, de brigada a capitán y de capitán a general. Al legionario no le puedes hablar sobre la importancia de la estrategia porque te responde que en su trabajo anterior cada vez que alguien la pifiaba en Afganistán le traían a dos chavales de veintitantos metidos en sendas bolsas de plástico. Nunca hay que tocarle los cojones a un presidente, pero al legionario menos que a ninguno. La misión vital del legionario es servir a Dios.

El niño rico

El niño rico es hijo de un legionario. Por desgracia, nunca consiguió llevarse bien con su progenitor, de modo que decidió montar su propia empresa más cool que la de papá. Pero como nadie tiene los cojones de un legionario, la empresa del niño rico es simplemente una incineradora del dinero de papi y los amigos multimillonarios de éste que coinvirtieron. La misión vital del niño rico es que le admitan en La Legión por sus propios méritos antes de heredar la empresa de su padre.

El heredero

Como el niño rico, el heredero también es hijo de un presidente, pero a diferencia del primero, el heredero nunca intentó fundar su propia empresa. De joven soñaba con ser músico o vulcanólogo. Pero al abandonar la adolescencia se resignó a acatar la llamada del deber como sucesor del imperio. El heredero es habitualmente un gestor diligente cuya misión vital es preservar el legado y, si le sobra tiempo, viajar y tocar la guitarra.

El limpiador

El limpiador suele ser el ex-director financiero y ocupa el cargo porque el anterior presidente organizó un buen desastre. A veces es también un consultor externo nombrado por los inversores hastiados de alguno de los otros tipos de presidente. Del limpiador se espera que cumpla una misión muy concreta y que luego abandone el cargo, algo así como lo que la curia espera del Papa, aunque algunos limpiadores acaban sobreviviendo a todos los que les nombraron.

El visionario

El visionario genuino es un híbrido entre el pajero, el experto y el supertacañón. Similarmente al pajero trabaja en la creación de productos disruptivos, pero en vez de crear a ciegas conoce perfectamente el mercado en el que se mueve y en su laboratorio trabajan dos premios Nobel que se quitan el sombrero cada vez que el visionario se remanga y hace algo; además tiene una idea cuantitativa muy precisa de cuántos recursos y tiempo necesitará para convertir su idea en realidad. Dependiendo de si es un psicópata o sufre asperger, externamente parecerá un buscavidas o un nautilus, aunque el estilo gerencial interno es como el del galáctico y emocionalmente es duro como el legionario. La misión vital del visionario es convertir cualquier coste el mundo en lo que él piensa que debería ser.

Cómo gestionar a cada tipo

La gestión de un presidente recién adquirido se basa en un principio y tres etapas.

El principio es que es más sencillo crear stress bottom-up que top-down. Por mucho que los empleados piensen que están puteados, a quién le suele acabar dando un infarto es al más jefazo porque la cantidad de problemas que tienes en tu vida depende linealmente de la cantidad de personas a tu cargo capaz de causarlos haciéndote a ti responsable subsidiario. Por consiguiente, la estrategia de gestión debe ser ofensiva: mantener ocupado al presidente antes de que él te mantega ocupado a ti, y esto es, de hecho, lo que hacen los miembros del consejo cuando conspiran en favor de sus propios intereses.

Las etapas para sobrevivir a un presidente son:

– Observación
– Condicionamiento
– Explotación

En la etapa de observación hay que anotar meticulosamente todo lo que hace el presidente. A qué hora llega a qué hora se va. Con quién se reúne. Qué toma para comer. Qué tiene como fondo de pantalla, etc. Durante esta fase hay que ser totalmente cauto y mantener el perfil más bajo posible hasta que se haya reunido la inteligencia necesaria.

Basándose en esta observación hay que clasificar al presidente en base a la taxonomía anterior y también, recomendablemente, de acuerdo a alguna otra técnica como el eneagrama (que no es objeto de este post).

Cuando termina la observación empieza el condicionamiento. En esta fase el objetivo es amaestrar al presidente para que no toque demasiado las narices. El condicionamiento presidencial se hace siempre mediante refuerzo positivo, nunca negativo, ya que es una muy mala idea cabrear a un presidente.

Por último, la explotación se basa en apalancarse en los miedos del presidente. Por ejemplo, los pajeros mentales son totalmente dependientes de los héroes tecnológicos ya que sin ellos no pueden hacer prototipos con los que mostrar si vívida imaginación al mundo, los buscavidas dependen de los estados financieros y de su fama para seguir consiguiendo dinero que quemar y con los cuñados es aún más fácil, sólo consiste en que te guste la misma marca de puros que a ellos.

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

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

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

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

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

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

Derechos de liquidación preferente

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

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

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

Suscripción preferente y dilución

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

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

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

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

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

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

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

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

Lock-ups de venta

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

Derecho a sentarse en el consejo

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

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

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

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

Post relacionado: Cómo elegir un inversor para tu startup (Iñaki Arrola)

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

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

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

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

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

1. Creer es ver

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

2. Efecto Halo

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

3. Alineación Ideológica

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

4. Atribución de Credibilidad (Framing Effect)

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

5. Métricas Relativas (Contrast Effect)

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

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

6. Fobia a la Ambigüedad

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

7. Sensibilidad Sensorial

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

8. Heurística Substitutiva

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

9. Preprocesamiento emocional

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

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

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

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

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

10. La falacia de la conjunción

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

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

¿Qué es más probable?

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

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

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

11. La ilusión del cluster

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

12. Estereotipos

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

13. Ilusión de familiaridad

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

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

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

Cosas que necesitas saber sobre el despliegue en La Nube

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

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

En resumen, son cinco los pilares que debes establecer:

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

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

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

Despliegue de Software I: Fase Prototipo

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

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

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

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

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

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

Despliegue de Software II: Fase Mínimo Producto Viable

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

Despliegue de Software III: Ampliación de capacidad

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

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

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

Infraestructura Hardware

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

Las reglas del dedo gordo son las siguientes:

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

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

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

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

Comparativa de clouds públicos

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

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

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

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

UnixBench Scores by Cost

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

Average base IaaS prices over time

Conectividad

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

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

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

Políticas de protección y recuperación

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

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

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

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

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

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

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

Monitorización

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

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

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

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

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

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

Administradores de Sistemas

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

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

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

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

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

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

Sobre la gestión de la complejidad

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

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

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

• Cuando el problema es tan complejo que no se puede encontrar una solución exacta entonces hay que encontrar una solución aproximada y luego refinarla progresivamente observando los errores que se producen y pensando cómo podrían evitarse.

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

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

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

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

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

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

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

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

Sobre la detección y corrección de errores

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

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

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

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

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

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

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

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

Sobre la sostenibilidad

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

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

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

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

Sobre el rendimiento

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

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

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

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

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

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

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

Sobre la organización de equipos

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

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

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

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

Sobre la seguridad

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

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

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

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

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

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

Sobre la fiabilidad

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

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

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

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

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

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

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

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

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

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