Seis principios de medicina aplicados al management

La medicina es una ciencia estadística. Tanto que si la gente supiera realmente hasta qué punto se basa sólo en probabilidades, iría espantada a la consulta. Es por tal motivo que los médicos fingen tan a menudo que tienen alguna certeza sobre el diagnóstico. El ejercicio de la medicina requiere de grandes conocimientos y sabiduría en igual medida. Por ello algunos de los secretos de los mejores doctores se pueden aplicar a muchos otros ámbitos, como el management o el desarrollo de software objeto de este blog.

Regla #1: El 90% de las enfermedades se curan sin intervención externa. Entonces, debido al juramento hipocrático, el médico debe hacer lo necesario para dañar al paciente lo menos posible, es decir, lo mejor probablemente es que no haga nada en absoluto. El problema es que esa no es la solución que el paciente quiere oir (es por eso que cada año se vende tanto paracetamol y amoxicilina). Igual que el cuerpo ha evolucionado a lo largo de decenas de miles de años para sobrevivir y recuperarse de las agresiones externas, las organizaciones también cuentan con mecanismos de autodefensa. Entonces, cualquier consultor sensato llamado para resolver un problema intentará intervenir lo menos posible. Este principio, llevado al extremo, se conoce entre los ingenieros como “si no está roto no intentes arreglarlo”. En ocasiones, el placebo puede incluso poner las cosas aún peor si el paciente resulta por casualidad ser alérgico al remedio.

Regla #2: Curar repetidamente a un organismo que podría curarse por si mismo acaba por privarle de su capacidad original para hacerlo. Se sabe y está más que demostrado que el abuso innecesario de antibióticos propicia la aparición de bacterias resistentes a ellos. Mi aplicación favorita de este principio a las organizaciones es la burocratización sistemática. Alguien comete un error y, para evitar que vuelva a suceder en el futuro, se crea un procedimiento. Luego otra persona comete un error diferente, y se crea otro procedimiento. Se siguen creando procedimientos hasta que la organización es el conjunto de procedimientos y, por consiguiente, no puede resolver ningún desafío nuevo que no esté contemplado en los procedimientos.

Regla #3: Principio de Pareto aplicado al diagnóstico. El 80% de las enfermedades se determinan con un diagnóstico sencillo y su cura es bien fácil bien totalmente imposible. El diagnóstico del otro 20% de las enfermedades requiere una cantidad horrorosa de tiempo. Esto lo ilustra magníficamente la teleserie del Doctor House. House nunca acierta a la primera en el diagnóstico. Pero sabe que el éxito con frecuencia es simplemente continuar donde otros abandonaron. Y en eso nadie gana a House pues en su testarudez él nunca abandona a un paciente. Análogamente, la mayoría de los consultores tiran la toalla ante los problemas difíciles. Pagados por horas, lo dejan por imposible cuando la cantidad de horas necesarias para diagnosticar y resolver el problema superan a las que podrían facturarle al cliente.

Regla #4: Un tratamiento tiene dos partes: la medicina y la forma de tomarla. Los antibióticos no son eficaces si se dejan de tomar demasiado pronto. Las metodologías tampoco si no las aplica un experto de la forma correcta. Aplicar un tratamiento durante demasiado tiempo torna al paciente adicto al remedio. Aplicarlo demasiado brevemente permite que rebrote la enfermedad. Mezclar un buen tratamiento con otro buen tratamiento pero incompatible con el primero puede tener como resultado neto consecuencias muy indeseables.

Regla #5: Si el tratamiento lógico no funciona, entonces se requiere otro tratamiento. No importa lo descabellada que parezca la alternativa. Si lo que se está haciendo, por muy bien justificable que parezca, no está funcionando, entonces hay que hacer otra cosa. A mi me gusta decir que lo que diferencia a un programador bueno de uno genial es la capacidad de este último para encontrar soluciones a problemas que desafían la lógica.

Regla #6: Sólo se le hará caso al doctor si se le atribuye ser un experto. Lo cual en management y consultoría equivale a decir que sólo le harán caso al consultor si cobra suficiente dinero por su consejo, o, en otras palabras, que es esencial fijar bien el precio por hora para tener credibilidad.

Como cierre del post, haré incapié en la diferencia entre un diagnóstico y una consulta. En el diagnóstico el paciente no sabe lo que le sucede ni tampoco cómo arreglarlo. En la consulta el paciente sabe lo que le sucede y cómo arreglarlo. La mayoría de los trabajos para las empresas son de consultoría, no de diagnóstico. Muchas de las visitas al médico también son consultas, sólo que demasiados médicos no lo saben y, por consiguiente, se ponen a hacer un diagnóstico sin haber determinado primero si el paciente sabe lo que le sucede.

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

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 | 1 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