Código de sólo escritura

Cada vez que me encuentro con un programador a quien le gusta programar me echo a temblar. La razón es que programar es como escribir, escribir es como hablar y hablar es más fácil que escuchar.

Los pedagogos saben por experiencia que es casi tan fácil enseñar a un niño a escribir que enseñarle a leer. El motivo es que, si bien escribir es intrínsecamente más difícil, el niño está interesado en primer lugar en que le escuchen y le entiendan antes que en escuchar él mismo ningún rollo patatero prefabricado.

Cuando me topo con un programador a quien se le llena la boca sobre la manera correcta de implementar la solución a un desafío me resulta sencillo determinar rápidamente si es (o no) tan bueno como él mismo cree. El pecado capital de los programadores es el orgullo, la ilusión de hacerse cargo, la convicción de que ellos harán (por fin) lo correcto allí donde otros menos capacitados sólo desarrollaron algo mediocre. La realidad suele ser que son optimistas sobre su capacidad de resolver un nudo gordiano porque no conocen su verdadera complejidad.

Escribir código es más divertido que leer código. Esto es porque cuando lo escribes lo que haces es plasmar en el editor los detalles de lo que tienes en la cabeza, le pones palabras a tu imaginación y eso mola; mientras que cuando lees código lo primero que necesitas es adivinar qué tenía en la cabeza la persona que lo escribió y el esfuerzo que requiere empatía no mola.

Lo que diferencia un código que simplemente resuelve un problema de otro código realmente grandioso es que este último (además de resolver el problema) está pensado para que alguien se lo lea.

Programar es explicarle todos los detalles de cómo se resuelve un problema a la persona más incapaz del mundo. Diez atributos que debe tener esta explicación para ser de escritura/lectura y no sólo de escritura son los siguientes:

1º) Debe ser posible intuir de un vistazo cual es la arquitectura general, en qué consiste a alto nivel la solución, cómo se comunican las partes entre ellas.

2º) Para que sea fácil entender la arquitectura mencionada en el punto primero, la implementación debe resolver directamente el problema y no un caso más general del cual el problema es sólo una instancia particular.

3º) No obstante el punto segundo, debe ser fácil refactorizar el código para resolver un caso más general.

3º) El código debe explicar no sólo lo que hace, sino también por qué lo hace de esa manera. Para eso se inventaron los comentarios insertados dentro del código. Escribe la puta documentación. Es ilegal vender gadgets sin un manual de uso e instrucciones de seguridad. Entonces ¿por qué das por acabado software simplemente con una licencia que dice que se entrega “tal cual”?

4º) Si no queda otro remedio que introducir código espagueti hay que documentar cuándo se introdujo, porqué y qué pasará si se elimina.

5º) Si el programa genera una excepción inmanejable automáticamente, debe ser fácil determinar dónde y por qué ha fallado.

6º) Cuando no funcione correctamente debe informar del funcionamiento degradado. No debe fallar silenciosamente.

7º) Si funciona no hay que tocarlo. Cada vez que se añade una línea de código aumenta el número de defectos software y el coste de mantenimiento. Agregar nuevo código para mejorar uno anterior (sin retirarlo de servicio) sólo es más bugs y más coste de mantenimiento. Por otra parte, todo ese horrible código espagueti del programador anterior está ahí por una razón la cual conviene saber antes de re-escribirlo para retirarlo.

8º) Salvo casos excepcionales, las funciones tendrán entre 10 y 100 líneas de extensión. No tan cortas como para no hacer nada significativo ni tan largas como para que no quepan enteras en la pantalla.

9º) La configuración del comportamiento específico para cada cliente se encontrará en un único lugar donde se especifiquen todos los parámetros que condicionan un modo de comportamiento u otro.

10º) No es suficiente con tener un patrón Modelo-Vista-Controlador, además hay que tener una capa de microservicios agrupados en servicios que el controlador pueda llamar.

En conclución: ¿Tu escribes o lees? Si sólo escribes eres un pedante. Si sólo lees careces de creatividad. El trabajo en equipo consiste en mantener una conversación con los otros programadores; es lectura/escritura.

Post relacionado: Por qué hay que enseñar a los niños a programar.

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

Computación distribuida con Docker y Mesos

De un tiempo a esta parte puedo estimar con escaso margen de error la calidad de un equipo de desarrollo por el grado de innovación en sus herramientas de despliegue de entregables. Algunos dicen que el nuevo documento de Google sobre Borg es el sucesor de aquellos ya clásicos sobre BigTable y MapReduce.

Hace no mucho desarrollábamos y ejecutábamos en El Servidor o, como mucho, en La Granja de Servidores (que eran de dos a diez). Las aplicaciones corrían sobre un servidor web, una base de datos, algún bus de integración y poco más. Pero ahora no es para nada raro que incluso una PyME tenga una decena de instancias de máquinas virtuales alojadas en algún proveedor. Y para las empresas medianas y grandes podemos estar hablando de centenares o miles de máquinas virtuales. Además, la infraestructura software se ha vuelto más compleja, almacenes atributo-valor para las imágenes, caches, soporte de sistemas de ficheros distribuidos, colas, servidores LDAP, … Replicar el entorno de producción con fines de desarrollo/testeo es un verdadero desafío, cuando no imposible, debido a la dependencia de servicios web de terceros.

Software-Hardware Matrix

El desafío de la distribución de aplicaciones no es nuevo. La primera versión de Microsoft Systems Management Server data de 1994. Aunque entonces se trataba de instalar y mantener actualizado Office en los PCs de los usuarios, más que de distribuir aplicaciones en los servidores.

Ya he escrito anteriormente que, en mi opinión, el lenguaje de programación no importa demasiado. Existen ejemplos de sitios web muy exitosos desarrollados en PHP/Zend, Python/Django, Ruby/RoR, Java/JSP o incluso C#/ASP.NET como Stackoverflow. Comunmente se cita que Facebook está desarrollado en PHP, pero para poder ejecutarlo eficientemente en las decenas de miles de servidores que necesitan tuvieron que desarrollar su propio compilador de PHP sobre la máquina virtual HHVM y una variante de PHP con tipado estático llamada Hack. La aplicación de Facebook se compila a un único binario “ballena” que se distribuye vía BitTorrent a los servidores.

Docker, Borg y Mesos son un intento de estandarizar una solución a este problema de la distribución masiva de aplicaciones en una granja con mayor número de servidores de lo que razonablemente se pudiere gestionar manualmente o con algunos simples scripts.

Previamente disponíamos de Vagrant y Puppet. Ambas fantásticas herramientas para la definición y creación de máquinas virtuales sobre VMWare o VirtualBox. La única pega de estás herramientas es que están orientadas a crear máquinas virtuales enteras. Se pueden definer variantes de la misma máquina virtual base, pero no son herramientas orientadas a la distribución de aplicaciones de software a través de un conjunto de máquinas virtuales que ya existen.

Docker

Docker es un software libre que pretende facilitar que la distribución y ejecución de aplicaciones en un conjunto de servidores se asemeje al transporte de contenedores marítimos estandarizados.

Docker fué liberado en marzo de 2013, pero creo que la primera versión relevante fue la que se liberó un año después. La diferencia es que la versión de 2014 explota la nueva funcionaldidad LXC incluída en el kernel de Linux 2.6.24 que permite aislar completamente procesos dentro de la misma máquina virtuales, dotándoles de su propia memoria, CPU, punto de montaje en disco, recursos de red, etc. Los contenedores de Docker no necesitan de un hipervisor, por consiguiente, se pueden empaquetar más eficientemente dentro de un host físico que usando una máquina virtual por cada aplicación.

Los contenedores se almacenan en repositorios de los cuales pueden ser descargados por los servidores de la granja. También es posible crear grupos de contenedores para gestionar dependencias.

Daniel J Walsh cuestiona la seguridad de los contenedores en su artículo Bringing new security features to Docker, señalando que algunos subsitemas del kernel como SELinux, /sys , /proc/sys, etc. y dispositivos /dev/mem , /dev/sd* pueden ser potencialmente vulnerables a ataques maliciosos de código en los contenedores. Tampoco es posible por ahora firmar el contenido de los contenedores y certificar su origen.

Borg

El documento publicado en abril describe la tecnología que Google lleva utilizando para gestionar sus datacenters desde hace más de una década. Es posible que la tecnología sea ya incluso obsoleta, al menos para Google donde están trabajando en la nueva versión de Borg bautizada como Omega.

Borg no usa máquinas virtuales, en teoría para mejorar la eficiencia, pero es posible también debido a que cuando empezaron a usarlo la tecnología de virtualización no estuviese aún suficientemente madura.

Los servidores de Borg se agrupan en celdas, una celda típica contiene alrededor de 10.000 servidores. Las celdas, a su vez se agrupan en clusters. Cada cluster está contenido dentro de un único datacenter y contiene usualmente una celda principal y varias celdas auxiliares más pequeñas.

Cada celda ejecuta una actividad (job) que se compone de tareas (tasks). Cada tarea es un único ejecutable con linkado estático. En cada máquina existe un alloc para cada tarea que puede ejecutar, el alloc describe las cuotas de recursos computacionales de la máquina que la tarea puede ejecutar.

En cada máquina se ejecuta de forma permanente un borglet encargado de gestionar la tareas y en cada celda se ejecutan varios borgmasters que gestionan las actividades mediante un sistema de colas. Los datos para cada tarea se almacenan por quintuplicado y se gestionan mediante un sistema Paxos.

En Borg, las actividades se dividen en dos grupos: baja latencia y procesos por lotes. Las actividades de baja latencia (como el email) reciben el 70% de los recursos mientras que aquellas que pueden tardar un tiempo arbitráriamente largo en responder reciben el 30%.

Mesos

A falta de una versión liberada de Borg, es posible utilizar Mesos el cual incluye soporte para contenedores Docker. Se puede concebir Mesos como un kernel distribuido accesible via APIs en C++, JVM, Python, y Go. La arquitectura de Mesos es similar a la de Borg. En cada máquina hay un slave daemon equivalente a un borglet y en cada cluster hay un master daemon que se corresponde con el borgmaster. Y también hay actividades (llamadas frameworks en Mesos) que están compuestas por tareas basadas en los ejecutores de Hadoop. No voy a entrar en los detalles técnicos sobre cómo Mesos hace asignación de recursos de grano fino descritos hace ya casi un lustro, simplemente reseñaré que la estrategia de asignación de recursos a las actividades influye considerablemente en el rendimiento y los interbloqueos de tareas concurrentes.

Proyectos como Spark, Storm, o Jenkins son ejemplos de aplicaciones muy diversas que pueden beneficiarse del uso de Mesos.

En combinación con Mesos es posible utilizar Marathon o Kubernetes. En muchos aspectos Mesos y Kubernetes se solapan funcionalmente en su intento de proporcionar al desarrollador un cluster de máquinas Linux que se comportan como un único sistema. Pero el acercamiento es sutilmente diferente. Kubernetes proporciona la abstracción pod (una agrupación de contenedores Docker), así cómo etiquetado de los pods para descubrimiento dinámico de servicios, balanceo de carga, y control de replicación. Mesos proporciona asignación fina de recursos para los pods a través de los nodos del cluster. En Kubernetes viene con un scheduler predeterminado mientras que en Mesos es preciso usar alguno como Yarn.

Beneficios de las nuevas tecnologías

• Utilización más eficiente de los recursos.
• Menores tiempos de latencia.
• Menor cap-ex del equipamiento.
• Menos licencias (VMs).
• Despligue más rápido y fácil de servicios a gran escala.
• Clusters de uso combinado para testeo y producción.

Post relacionado: Cosas que necesitas saber sobre el despliegue en La Nube.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Computación en la Nube, Tecnologías Emergentes, Tecnologías Libres | Deja un comentario

Carpintería de oro

kintsukuroiKintsukuroi (金繕い) (Japonés: reparación de oro) Los japoneses creen que cuando un objeto ha sufrido daño y tiene una historia se vuelve más hermoso. Por eso, en lugar de ocultarse, las roturas se muestran y se celebran como prueba de la imperfección y la fragilidad pero también de la capacidad para recuperarse y hacerse más fuerte.

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

El jardín privado

Hoy le hablé por Skype a un emprendedor sobre EO. Le dije que en EO la gente habla de cosas “del 5%” y me preguntó ¿qué es el 5%?

El 5% es el porcentaje de cosas que no le cuentas a nadie. El literariamente famoso Dorian Gray (por favor, quien lo confunda con Christian Grey que se beba ahora mismo un vaso de cicuta) no podía mirar ese 5% de cosas ni en su autorretrato.

El 5% es nuestro jardín privado, y en las lindes de dicho jardín se encuentra la intimidad. Las plantas que crecen en el jardín privado pueden agruparse en cuatro especies: a) nuestro trabajo, b) nuestra comunidad, c) nuestra familia, d) nosotros mismos. En el centro del jardín está el amor (Freud pensaba que era el sexo, pero ya se sabe que no es así, el sexo sólo es una parte del amor).

En el fondo de nuestros corazones todos ansiamos invitar a alguien a nuestro jardín privado, pero existen demasiados sentimientos que, razonablemente, nos bloquean: el miedo, la culpa, la vergüenza, la ira, … Para más INRI, los progenitores, el cónyuge, los hijos y los compañeros de trabajo son personas poco indicadas para invitarlas al jardín privado debido a un conflicto de intereses. Esto nos deja bastante solos, especialmente a los emprendedores empezadores pues es bastante difícil encontrar a alguien que comprenda porqué hemos empezado algo.

La conexión con otras personas se establece a través del 5% y el otro 95% prácticamente no importa. Es por esto que algunos empleados se desgañitan intentando que su jefe les haga caso, algunos jefes no entienden por qué están casi todos los empleados tan descontentos en la empresa que mejor paga del sector, algunos maridos no comprenden la razón por la cual después de darle todo a la esposa ella parece permanentemente una gallina cabreada y algunas esposas no entienden qué le ha visto él a la pelandusca esa con la que se cita a hurtadillas.

Algunas zonas del jardín privado son tan recónditas que ni siquiera su propietario sabe que existen. Esto se conoce metodológicamente como la zona ciega, aquello de nosotros mismos que no podemos ver. A veces estas zonas ciegas están ocultas para nosotros mismos pero no para los demás, por eso tener un coach está tan de moda ahora. Aunque muchas zonas ciegas tampoco son visibles para los demás debido a que en el fondo hacemos todo lo posible por ocultarlas.

Existen técnicas para acceder al jardín privado de otra persona. Sobre unas cuantas ya he escrito y no voy a repetirme aquí. Quizá la única mala noticia es que si quieres que alguien te invite a su jardín privado primero vas a tener que invitarle tú al tuyo.

Posts relacionados:
Porqué la mitad de la población no se entiende con la otra mitad
Cómo evitar arruinarlo todo con violencia verbal
Cómo conectar de forma instantánea con la gente
Dragon Dreaming

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

Cash Burning Rate

Gastar dinero es siempre más divertido que ganarlo. Es por esto (creo) que muchos emprendedores buscan a alguien que invierta dinero en su empresa con el cual hacerse pajas mentales sobre lo que necesita desesperadamente un mercado imaginario.

Antes de entrar en la pregunta ¿cuánto dinero debería quemar una start up mes a mes? quiero decir que, en mi caso, existe una relación inversamente proporcional entre el dinero que invertí en empresas y el dinero que gané. Los buenos negocios los hice sin inversión, o con muy poca inversión, mientras que aquellos en los que he invertido más he perdido hasta la camisa. Lo cual me conduce a una regla previa: haz siempre negocios con el dinero de los demás, nunca con tu propio dinero.

Disponibilidad de capital por países

Fuera de España ahora es facilísimo obtener dinero para una start up. Quizá demasiado fácil. A lo largo de las últimas décadas en el Área de la Bahía han proliferado decenas de miles de business angels. Sólo en AngelList hay registrados más de cuarenta y dos mil. Se estima que en EE.UU. hay entre medio millón y tres cuartos de millón de inversores quienes han realizado una inversión de capital semilla en los últimos tres años. Y EE.UU, no es el único país donde es fácil encontrar un inversor, Londres, por ejemplo, también está infestado de multimillonarios buscando cómo colocar su dinero. Todo empezó alrededor del año 2005 cuando el cloud computing posibilitó la aparición de una clase de inversores y fondos que antaño no existían. Algunos avisan de que está creciendo una burbuja gigantesca alrededor las start ups tecnológicas norteamericanas, sostenida sólo por Apple, debido a que la competencia entre los inversores les obliga a entrar cada vez en fases más tempranas cuando la empresa aún carece de un producto validado por el mercado. Los llamados “unicornios” start ups valoradas en más de mil millones de dólares suelen requerir centenares de millones de dólares de inversión haciendo que el lean start up (ya inventado por Microsoft en 1975) parezca cosa de la historia. Es cierto que el elevadísimo coste de los técnicos cualificados en los países desarrollados implica que se necesitan cantidades en millones para desarrollar y vender productos de alta tecnología, pero eso llevaría a la discusión de si hay que contratar a los técnicos en esos países o externalizar la producción, lo cual podría ser objeto de otro post entero.

En España el acceso a la financiación es bastante más difícil. También hay foros y grupos de inversores como: ESADE BAN, AEBAN, BAN madri+d, etc. Pero la lista de inversores relevantes cabe en un folio similar al que redactó Carlos Blanco en 2012[1]. Debido a la mayor escasez de capital y al menor coste de la mano de obra las start ups españolas tienden a quemar caja mucho más despacio que sus homólogas estadounidenses y británicas. Esto, en principio, es una ventaja, excepto porque en ocasiones la cuantía de las rondas de financiación se reduce a sumas ridículas. Como compensación, en España existen préstamos y subvenciones públicas que no se encuentran en casi ningún otro país. Ya sé que el dinero público está mal visto, sobre todo por los inversores pues compite con ellos, pero, si existe la posibilidad, no hay que descartar apalancarse en préstamos blandos del Estado o las administraciones autonómicas.

Cash burning rate bruto vs. neto

El cash burning rate es, para mi, un término ambiguo, ya que puede referirse (en bruto) a la cantidad de dinero que una empresa gasta por mes o (en neto) a la cantidad que pierde. Aquí me voy a referir siempre a la cantidad neta que pierde. Aunque el bruto también es muy relevante para empresas de alto riesgo porque sus ingresos dependan de unos pocos clientes, de mercados muy volátiles o de cambios políticos y monetarios impredecibles.

Existen variadas razones por las cuales una empresa puede empezar súbitamente a quemar más caja de la que produce. Es posible que la empresa haya acometido un ciclo de expansión internacional, que sufra los efectos negativos de una súbita fluctuación en el cambio de moneda o, simplemente, que su mercado atraviese una depresión. Voy a comentar sólo el caso de las start ups y no las medidas a tomar cuando una empresa consolidada necesita inversión debido a desafíos de liquidez o de solvencia.

Cuándo y cómo quemar caja

La mayoría de las veces que un grupo de gente se reune para crear una empresa ni siquiera llegan a lanzar un producto. De las que lo lanzan, aproximadamente el 40% muere porque el mercado no necesitaba realmente dicho producto, o porque el producto tiene fallos de diseño o simplemente porque los hábitos de los consumidores aún no están preparados para el producto.

Unos poquísimos productos son un éxito instantáneo. La mayoría, en cambio, atraviesa un lento ciclo de adopción. Es muy tentador para los emprendedores (y para los inversores) tratar de acelerar este ciclo. La regla del dedo gordo suele ser asegurar entre 12 y 18 meses de financiación en cada ronda. Pero de un tiempo a esta parte no es raro encontrar start ups que están quemado 100.000 al mes y buscan una serie B entre 5 y 10 millones.

Las razones por las cuales los emprendedores buscan estas cantidades son básicamente alguna/s de estas cinco:
1) Creen que el producto no se vende tan bien como esperaban porque le faltan funcionalidades y hay que invertir más en I+D.
2) Creen que el producto no se vende tan bien como esperaban porque carecen de los recursos suficientes para marketing y ventas.
3) Creen que podrán comprar otra empresa o un activo que es la pieza clave que les falta.
4) Creen que a mayor valoración en cada ronda mayores probabilidades de forrarse en el exit.
5) Les gusta ver una cantidad de seis cifras en sus balances.

Los inversores entran al trapo porque les pierde la codicia y porque no es fácil encontrar start ups que estén demostrando tener tracción en el mercado.

En algunas ocasiones es posible que exista una buena razón para una cuantiosa ronda de inversión en serie A o B, pero en la mayoría de los casos lo único que consigue la start up con más caja es inventar formas más rápidas y eficientes de quemar dinero mes a mes. Si la empresa opera con márgenes brutos elevados (superiores al 80%) y además es probable que se produzca inminentemente un pico de demanda entonces está justificado quemar mucho dinero durante un tiempo para conquistar cuota de mercado. En el resto de los casos casi nunca está justificado. Si los márgenes brutos son bajos (inferiores al 40%) ni siquiera los grandes volúmenes de ventas justifican la inversión como ya han demostrado los múltiples fracasos de retailers online. Grosso modo, la creación de valor debe ser el triple del dinero quemado pues eso es más o menos lo que el inversor necesita para alcanzar sus expectativas. Es decir, si la empresa ha quemado 100.000 en el último mes entonces o a creado 300.000 de valor a medio plazo o de lo contrario simplemente ha malgastado el dinero.

Reglas del dedo gordo para la gestión de la caja

1ª) El dinero hay que buscarlo cuando no lo necesitas. Al principio creerás que es imposible lanzar la empresa sin dinero, y aquí viene tu primera prueba de fuego para demostrar si tienes madera de emprendedor: cuánto puedes hacer sin dinero. Porque si buscas dinero cuando sólo tienes un PowerPoint y dos followers se van a quedar con un pedazo enorme de tu empresa a cambio de muy poco capital, excepto que seas un genio levantando dinero o estés por casualidad en medio de una dinámica en la que los inversores se han vuelto todos temporalmente majaretas.

2ª) Uno de los fundadores debe ser el encargado de gestionar a los inversores. Y preferiblemente no debe ser el CEO. Los inversores son como un tipo especial de clientes solo que no quieren comprar el producto sino otras cosas en la empresa. Todo tiempo que se necesita dedicar a vender y gestionar a los inversores no se dedica a las actividades esenciales de la empresa y, por consiguiente, pone en riesgo la supervivencia de la misma si el CEO ha perdido el foco estratégico y sólo piensa en cómo contentar a los inversores para que le den otra ronda.

3ª) Nunca hay que quedarse con menos de 6 meses de reservas en caja. Esto es porque en el momento en que bajes de los seis meses los inversores sabrán que necesitas el dinero y, por tanto, estarán en una posición mucho más ventajosa para negociar. Y cuidado porque en no pocas ocasiones son los propios inversores quienes animan a la start up a quemar dinero hasta quedarse sin caja con la intención de comprarla luego a precio de saldo.

4ª) En los países con elevados costes de mano de obra, el coste de empresa total por empleado cualificado es, burdamente, de 500 por día laborable. Súmale otros 250 de costes de estructura y resta de 15.000 lo que estés ingresando por mes para saber cuánto estás perdiendo (o vas a perder) en función del tamaño del equipo. En los países desarrollados con mano de obra barata puedes estimar 300+100 de coste, ergo sólo necesitas restar de 8.000. Si consigues producir en India o en Vietnam podrías restar de 4.000 pero sinceramente no tengo ni idea de cómo se puede conseguir eso en la práctica.

5ª) El dinero se debe de estar quemando en la generación de activos de valor, principalmente en sueldos de empleados. Si tus gastos de viajes, comidas e infraestructura superan el 20% revisa tu contabilidad y recorta gastos supérfluos. Si estás usando el dinero de capital riesgo para pagar la factura de la luz ¡detente! y bájate del tren pues probablemente vas a toda máquina hacia un puente quebrado sobre un abismo. Si habeis servido caviar beluga por cuenta del inversor en la última fiesta ¡pégate un tiro!

6ª) No te autoengañes con métricas de mentira. Estas son las basadas en un valor ficticio a largo plazo del cliente o en hipotéticos ingresos por publicidad. Vender es duro. Es por eso que todos los VCs veteranos reservan dinero para rondas sucesivas ya que saben que el coste de adquisición de clientes casi siempre será mayor del previsto y el ticket medio de venta menor.

7ª) Ten cuidado con la mezcla entre líneas de crédito y capital riesgo. No estoy intentando sugerir que no se deba aceptar deuda bancaria además de inversión ¡todo lo contrario! El crecimiento en una empresa hay que financiarlo con inversión y no con líneas de crédito a seis meses, y las líneas de crédito son mucho más baratas si lo único que necesitas es poder esperar a cobrar una factura a 90 días. Pero si quiebras y le dejas un descubierto al banco este probablemente sabrá que aunque la empresa no tenga dinero el inversor sí lo tiene y, aunque no sea su deuda, el inversor sabía, o razonablemente debería haber sabido que la empresa se iba a quedar sin caja para liquidar al banco.

8ª) Maneja la temporización para conservar la iniciativa. No permitas que ni los inversores ni los bancos dicten tu agenda. Esto es complejo porque desde el preciso instante en que aceptas inversión hasta que alcances el punto de equilibrio financiero estás sentado sobre una bomba de tiempo que hace tic-tac muy rápidamente.

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

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