Mapa de cada pais en función de sus internautas

Mapa de densidad de internautas

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en ¿Dónde estamos? ¿Hacia dónde vamos? | Deja un comentario

Hackers vs. Space Cowboys

Gravity Clooney BullockEn este post explico porqué deberias contratar un Space Cowboy y no un Hacker. La justificación es un poco difusa y narrativa, espero que no aburra en exceso a nadie. Además, antes de sacar la antorcha y despacharme a gusto porque en un blog uno puede escribir lo que le dé la gana, debo decir que conozco al menos un par de grupos en Madrid en los cuales buscar a un joven programador “hacker” con talento. Uno es ßetabeers de Miquel Camps y otro Ironhack de Gonzalo Manrique y Ariel Quiñones. Los cuales serían los sitios donde yo empezaría a buscar desarrolladores junior si estuviese pensando en montar algo ahora mismo en España.

Si hay una palabra que se ha ido pervirtiendo a lo largo de la historia de la informática esa es “hacker”. Desde su nacimiento en los años sesenta en el MIT esa gente apasionada del Software Libre y la WWW pasó a ser identificada primero con los piratas informáticos y, recientemente, con los jóvenes fanáticos de la tecnología.

Cuando tenía 13 años “descubrí” el algoritmo de ordenación por burbuja y lo programé en LISP. Durante un breve tiempo me sentí muy orgulloso de mi mismo, pero poco después me llevé una gran decepción al comprobar que se me había ocurrido, de hecho, uno de los algoritmos más ineficientes que se conocen para ordenar una lista. Lo que realmente descubrí ese día es que no soy una persona extraordinariamente inteligente y que haría mejor en sacar el mejor partido de mis capacidades intelectuales antes que intentar explotarlas directamente por fuerza bruta. Ahora, 28 años después de aquello, me encuentro semanalmente a gente a gente haciendo hallazgos como el mio con el bubble sort, sólo que no se dan cuenta de lo que han descubierto…

En la vida se necesitan un mínimo de 10 años para dominar cualquier disciplina. Da igual que quieras ser violinista, karateka o programador, da igual. Es posible leerse la teoría en menos tiempo, pero ningún matemático es realmente bueno hasta haber hecho todos los ejercicios, tarea que requiere bastante tiempo.

Hackers

El perfil típico del autollamado hacker es alguien que se ha topado con alguna herramienta y le parece la rebomba. Pasa mucho con los frameworks de JavaScript. No voy a mencionar ninguno concreto porque podría ser tiroteado por algún zelote, pero si te bajas la versión no comprimida de los fuentes y tratas de averiguar lo que está haciendo algún framework entre bastidores podrían entrarte ganas de cortarte las venas, lo cual me lleva a la primera razón por la que no deberías contratar a un hacker.

Los hackers tienen tendencia a incluir librerías de moda y novedosas en el diseño. Les gusta, sobre todo, la novedad, y les dan subidones cuando creen que han descubierto la próxima píldora mágica de la productividad. Es innegable que hemos avanzado mucho en la infraestructura software ¡Dios! En los 90 teníamos que escribir hasta las estructuras de datos más básicas (gracias Joshua Bloch). Pero hay que saber sobre las librerías que son como los huevos de Alien: los metes en tu nave espacial y, al principio, no sucede nada, hasta que de repente empiezan a salir arañas con sangre ácida que se comen a toda la tripulación. El caso más notable de “librería Alien” (de los que yo conozco) es probablemente Hibernate y las otras implementaciones de JPA pero hay muchísimos ejemplos de librerías que se han popularizado sin benchmarks ni evaluaciones previas lo suficientemente exhaustivas.

La siguiente desventaja de los hackers modernos es su inexperiencia en el mantenimiento de sistemas en producción. Desarrollar un software es sólo una parte de su ciclo de vida. Luego hay que mantenerlo y el mantenimiento es un arte en sí mismo que los hackers suelen odiar porque la regla básica es justo lo contrario de lo que a ellos les gusta hacer: “si funciona ¡no lo toques!”.

Muchos presuntos hackers sufren una carencia de conocimientos fundamentales suficientemente sólidos. Los que van un poco mejor pueden explicar, por ejemplo, los entresijos del garbage collector de Java, pero pregúntale a alguno de ellos quién es Donald Knuth y mira la cara de haba que se le pone, o escríbele esto en una pizarra DTIME(ƒ(n)) ⊊ DTIME(ƒ(n) · log²(ƒ(n))) y pídele que te explique qué significa.

Si el hacker te dice que va a diseñar un sistema escalable, pídele un modelo sobre como cambiarán los tiempos de latencia en función del número de usuarios o un cálculo de cómo influirá el tiempo medio entre fallos de los discos duros en la disponibilidad del sistema.

Los hackers, en general, no hablan mucho. O mejor dicho no hablan mucho sobre lo que deberían hablar en las empresas. Es por eso que siguen haciendo falta esos mandos intermedios de las tiras de Dilbert que van a reuniones y mueven información de un lado para otro que se podría mover de forma más eficiente si los programadores estuviesen realmente por la labor de ello.

Por último, pregúntale al hacker cuántos centenares de miles de líneas de código ha escrito. Programar se parece en cierto sentido a pilotar. Durante la mayoría de las horas de vuelo no pasa realmente gran cosa, hasta que un dia te pilla un temporal huracanado con viento cruzado y entonces se comprueba qué tan bueno eres haciendo crabbing.

Space Cowboys

Entonces ¿cómo se identifica a un genuino experto en programación a quien confiarle tu sistema crítico? Lo sabrás por lo siguiente:

• Te dirá que el problema nuevo que afrontais en realidad no es tan nuevo y que se parece a otro que él ya resolvió largo tiempo atrás.
• Te hablará de la experiencia de usuario y no de trucos milagrosos con la implementación.
• El Space Cowboy no te prometerá milagros, sabe que muchos remedios funcionan, pero la píldora mágica para programar es igual de falsa que la píldora mágica para adelgazar.
• Discutirá contigo sobre las implicaciones a largo plazo de cada decisión técnica en vez de sugerirte como podríais lanzar una beta el mes que viene.
• Ante una caída del sistema te enumerará una lista de causas posibles, con la probabilidad de cada una y estimando de tiempo de resolución para cada caso.
• No oirás al Space Cowboy aburriéndote con una chapa sobre cómo hace su trabajo, eso son detalles técnicos que a ti no te importan, lo único que quieres oir (aunque todavía no lo sepas) es como vas a aumentar el ROI de tu negocio.

Tampoco todos los Space Cowboys son buenos, por supuesto. Algunos viven anclados en tecnologías del pasado. Capaces son de decirte que no vale la pena programar nada que no sea en VisualBASIC 6. Otros vienen con una mochila a cuestas y tratan de colarte por todos los medios unas librerías que llevan años escribiendo por su cuenta. Algunos dejaron de aprender por el camino y no pocos se quemaron tanto en el ejercicio de la profesión que ya les da todo igual. La innovación la generan habitualmente los becarios y no los mamuts pues estos últimos están más interesados en hablar de lo que ya construyeron antes que en construir nada nuevo.

En resumen, concluiré con una referencia a la película Gravity: deberías contratar un Space Cowboy y no un Hacker por dos razones: 1ª) porque sabe que el mismo motor que sirve para aterrizar sirve para despegar, y 2ª) porque sabe dónde tienen los rusos escondido el vodka.

Post relacionado: ¿Porqué la gente odia a los programadores?.

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

El nuevo científico de datos

Todos los años se publican predicciones sobre las profesiones del futuro, en las cuales los programadores repiten sistemáticamente entre las primeras posiciones. Sin necesidad de irnos hacia el siguiente lustro o década, sin duda uno de los puntos calientes del mercado de trabajo es actualmente el puesto del científico de datos.

A decir verdad el nombre de científico de datos no me parece del todo apropiado. El puesto es una combinación de administrador de base de datos, programador y matemático. El científico de datos una de esas mezclas como la de un biólogo con un informático para sacar un bioinformático o un ingeniero industrial con un informático para dar un especialista en smart grids.

El hito más llamativo en la inaguración de esta nueva profesión fue el fallido premio Netflix de 1 millón de dólares a quién mejorase la precisión de su algoritmo de recomendaciones en un 10%.

Es un trabajo en el que se distinguen varias etapas:

- Definición de modelos y algoritmos.
- Montaje de la infraestructura hardware y software.
- Extracción y carga de datos.
- Procesado.
- Análisis, interpretación y presentación de resultados.

Es bastante difícil encontrar un buen científico de datos, pues se requiere una combinación poco común de conocimientos de matemáticas, administración de sistemas, y programación, además de la capacidad de extraer y explicar las conclusiones de una forma clara para que los directivos las entiendan.

¿Qué se necesita para ser científico de datos?

Si quieres ser científico de datos debes hacer básicamente lo siguiente:

1º) Desempolva todos tus apuntes de estadística.
2º) Escoge una pila de productos de las que describeré a continuación.
3º) Aprende a programar en Java y Python o R.
4º) Aprende a usar algunas herramientas de visualización de datos.

Algoritmos

El machine learning es una rama de la inteligencia artificial que trata sobre cómo los algoritmos pueden aprender de los datos. A grandes rasgos, el machine learning consiste en encontrar una forma de representar datos y evaluarlos de manera que se puedan obtener generalizaciones de los mismos. Típicamente, lo que hacen los algoritmos es aplicar una función de evaluación (también llamada en inglés objective function o scoring function) y luego aplicar otra rutina para buscar máximos de dicha función. La siguiente tabla muestra ejemplos de estos tres componentes de representación, evaluación y optimización.

Representación Evaluación Optimización

Instancias
    Neighbor-joining

    SVM

Hiperplanos

    Bayes Naive

    Regresión logística

Árboles de decisión

Redes de neuronas

Precision y recall

Error cuadrático medio mínimo

Divergencia de Kullback-Leibler

Optimización Combinatoria

    Greedy Search

    Beam Search

Optimización Contínua

    Gradiente descendiente

    Gradiente conjugado

    Programación lineal

La lista de algoritmos de machine learning es muy extensa y su comprensión requiere de conocimientos bastante técnicos, por lo cual no voy a entrar aquí detalladamente en ella. Los algoritmos se pueden agrupar en 5 grandes familias: aprendizaje supervisado, aprendizaje no supervisado, inferencia transductiva, aprendizaje por refuerzo, y deep learning (que es con lo que parece que está experimentando Netflix últimamente).

Entre los algoritmos más populares están: k-medias, máquinas de vectores de soporte, apriori, esperanza-maximización, AdaBoost, Knn, Bayes Naive y CART.

Las redes de neuronas parece ser que se van a volver a poner de moda, especialmente las implementadas en hardware, aunque yo tengo artículos y prototipos de emuladores de neuronas con resistencias ajustables que datan de los años noventa. Ya veremos si llegan a algún sitio o suman y siguen en la larguísima lista de expectativas incumplidas de la inteligencia artificial.

Desafíos del machine learning

Con independencia del algoritmo utilizado lo que cuenta es la generalización más allá del juego de pruebas porque es prácticamente imposible que los datos reales de entrada sean iguales a los del juego de prueba. El error más común entre los principiantes en machine learning es crearse una ilusión de éxito sólo porque el algoritmo se comporta bien con el juego de pruebas, hasta que se prueba con datos reales y entonces se descubre que se comporta sólo un poco mejor que si estuviera haciendo elecciones al azar. Por consiguiente, si contratas a alguien para un trabajo de machine learning, guárdate un conjunto de datos que el desarrollador no haya visto con anterioridad para probar lo que te entregue.

Es importante mantener separados los juegos de datos para entrenamiento y para pruebas porque es fácil contaminar el clasificador con datos de prueba. El caso más extremo se conoce como overfitting, cuando el clasificador acierta el 100% de las veces con el juego de pruebas pero sólo el 50% con los datos reales. La razon para ello es que los datos en sí mismos no son suficientes. Como punto de partida es necesario hacer algunas suposiciones iniciales acerca de los datos. De hecho existe un teorema llamada no free lunch según el cual cualquier par de algoritmos de optimización es equivalente cuando su rendimiento se promedia a través de todos los problemas posibles. El overfitting suele descomponerse en el error sistemático (bias) y la varianza (variance). El error sistemático es una medida de la tendencia del sistema a prender la misma cosa equivocada. La varianza es la tendencia a aprender cosas al azar con independencia de la señal de entrada.

Tras el overfitting, el segundo mayor problema del machine es la dimensionalidad. Muchos algoritmos funcionan muy bien con dimensiones bajas, pero, en general, la dificultad del problema crece exponencialmente con su dimensión. Con una dimensión de tan solo 100 y un juego de prueba de 1012 la cobertura de casos es sólo 10-18 del espacio de entrada. Las intuiciones que tenemos extraidas sobre el mundo tridimensional no se cumplen en dimensiones altas. En dimensiones altas la mayoría del volumen de una naranja está en su corteza y no en su pulpa.

Pilas de productos

Hay en esencia tres pilas de productos para el científico de datos :

- Software Open Source sobre Hadoop.
- Productos privativos.
- Soluciones SaaS.

Ningún producto soluciona todas las necesidades y ninguna pila es absolutamante mejor para cualquier cosa. La fiebre mayor es actualmente alrededor de Hadoop. Hadoop en sí mismo sólo es un sistema de ficheros distribuidos. Encima de Hadoop se puede montar HBase como implementación del Bigtable de Google. Pero Hadoop en en sí mismo lo único que permite es almacenar ficheros de forma redundante en varias máquinas y ejecutar procesos de transformación sobre dichos ficheros minimizando el tráfico de red entre los nodos. Lo más popular es ejecutar MapReduce. Pero Hadoop no está para nada limitado a MapReduce. La Fundación Apache tiene su propio producto de machine learning sobre Hadoop, Mahout, el cual implementa algunos de los algoritmos que hemos mencionado anteriormente (k-medias, Bayes, Naive…) para crear recomendadores de producto y cosas por el estilo.

A mi me sorprende un poco que no se aprecie en el mercado más demanda de Cassandra. Ya que Hadoop en sí mismo no es una base de datos, mientras que Cassandra sí es una base de datos orientada a columna. Quizá sea por el pequeño pero importante detalle técnico de que Cassandra no proporciona ninguna forma de ordenar resultados en las consultas, o, al menos, ese fue un factor decisivo para descartar su uso en un par de proyectos en los que yo estuve involucrado en los últimos años.

En paralelo a la creciente oferta Open Source se pueden encontrar productos bastante especializados. KXEN para análisis predictivo en desafíos como la detección de fraude, PROS para pricing, etc. Que se suman a los productos clásicos de Business Intelligence: QlikTech, Cognos, PowerPivot, etc. La moda entre las start ups y muchas empresas medianas es hacerlo todo in-house. Sobre todo porque los productos comerciales de BI/Big Data no son a priori baratos, aunque por lo que yo voy viendo, contratar a una legión de científicos de datos inexpertos para resolver un problema que no se conoce muy bien les saldrá probablemente más caro a muchas empresas que haber contratado de saque a alguien con experiencia en minería de datos.

Por último, están las soluciones SaaS, de las cuales en España hemos visto de un tiempo a esta parte algunas start ups muy prometedoras como BrainSINS para las recomendaciones de eCommerce, SocialBro para targeting y analítica en Twitter, Alto Analytics para análisis de lenguaje natural en redes sociales, Intelify Cities, o Bynse para llevar el Big Data a la agricultura. La razón para elegir un SaaS es sencilla: los proyectos Big Data no son para nada simples ni en su concepción ni en su infraestructura ni en su operación diaria. Se pueden tardar fácilmente seis meses en armar un proyecto Big Data y otros dieciocho en conseguir que empiece a proporcionar resultados significativos. Conozco bastantes empresas que últimamente han cogido dinero y se han puesto a hacerse el Big Data ellas mismas, amenudo anticipando preguntas y prejuzgando sus respuestas, pero sólo tras estudiar decena de millones de tickets de la compra de supermercados se puede saber con certeza que los pañales se compran con las cervezas.

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

Black Box Trading

Es posible que el siguiente gran thriller sobre entramados financieros estilo Inside Job sea todo acerca de software y algoritmos. En el mercado laboral los programadores con conocimientos de algoritmos de trading se cotizan a precio de oro en uno de los nichos de trabajo técnico más lucrativos si a uno lo que le interesa sobre todo es el dinero.

Según explica Kevin Slavin en su charla How Algorithms Shape Our World, el 73% de las operaciones bursátiles sobre equity en EE.UU. son llevados a cabo por algoritmos específicamente diseñados para que no se detecte lo que el trader está haciendo realmente empleando técnicas que se asemejan a las que se utilizan para esconder un avión del radar. Y, al mismo, tiempo, existen algoritmos que buscan patrones entre los millones de transacciones para averiguar lo que está sucendiendo realmente.

Los algoritmos de trading dependen de forma crítica de su velocidad para ser efectivos. Tanto que las latencias típicas ahora mismo oscilan alrededor de 500 microsegundos. Para hacerse una idea de lo que son 500 microsegundos, la luz necesitaría 66.838 microsegundos para recorrer los aproximadamente 20.000 Km que separan dos puntos en las antípodas. Slavin presenta un mapa extraído del trabajo Relativistic statistical arbitrage en el cual se afirma que para sacar el máximo rendimiento a los algoritmos de trading teniendo en cuenta las latencias de transmisión los servidores deberían estar localizados en los puntos azules ¡algunos de los cuales están en medio del océano!

Relativistic statistical arbitrage

La dinámica generadas en las bolsas por los algorítmos es tan compleja que los mercados se han vuelto caóticos y están expuestos a desplomes súbitos impredecibles como el Flash Crash de 2010.

Existe sin duda una fiebre del Forex que acabará pillando a más de uno con los pantalones bajados. Pero probablemente en siguiente gran susto a la economía global se lo darán los high frequency traders.

Post relacionado: Las cajas negras y la ilusión de hacerse cargo.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Disrupción, Iniciativas que cambiarán el mundo, Mercado y Oportunidades de Negocio, Minería de Datos, Modelos de Negocio | Deja un comentario

Las reglas del perro viejo para los negocios

Juantomás me envió hace poco la referencia a un artículo con consejos cargados de honor y buenas intenciones. En la vida es tentador intentar caer en un dogmatismo de principios a ultranza. Sin embargo, cualquier persona realmente cuerda debe ser paradójica, esto es así porque el mundo en sí mismo es una paradoja incomprensible. Con el paso del tiempo todo se acentúa como los surcos de la cara. Uno profundiza en sus principios, aunque, igual que nos cambia impredeciblemente el rostro, los principios que uno afianza en su madurez rara vez se parecen a los que se tenían de joven. Y he aquí a continuación algunas de las reglas prácticas a las que yo he llegado por el método de ensayo y error.

• Si ves un autobus amarillo, sabrás que es amarillo por ese lado, mas nunca asumas a priori que será también amarillo por el otro lado.

• Nadie es de fiar, y los que parecen de fiar a primera vista esos son los más peligrosos de todos.

• Como corolario de lo anterior, por un trabajo cobrarás sólo lo que percibas por anticipado.

• Nunca asumas que alguien no estará lo bastante loco, o lo bastante desesperado como para hacer algo totalmente temerario, estúpido, ilegal o deshonroso.

• La garantía jurídica real no existe. Hagas lo que hagas ponte en una posción legal en la que sólo te tengas que defender, nunca ser la parte demandante.

• Para salir de un pozo lo primero es dejar de cavar hacia abajo. No abras una línea de crédito para tapar un déficit de caja. No contrates ingenieros cuando no tienes ventas para desarrollar funcionalidades con las que presuntamente venderás el producto.

• Hay invertir sólo en bienes artificialmente devaluados. Cuando todo el mundo esté comprando pisos, compra oro. Cuando todo el mundo esté comprando oro, compra divisas. Cuando todo el mundo esté haciendo trading de divisas compra bitcoins. Cuando todo el mundo esté loco por los bitcoins compra derechos sobre recursos naturales.

• En una burbuja hay que entrar antes que nadie y haber salido cuando la masa se haya dado cuenta de ella. Si estás dentro de una burbuja entonces te encuentras en el lugar equivocado.

• El trabajo duro no le importa a nadie excepto a ti.

• Hacerlo muy bien da, en general, mejores resultados que tener ideas brillantes. La práctica es más importante que la técnica.

• El día, hora, minuto y segundo en que tu empresa alcanza su máxima valoración no es el momento de celebrar el éxito, es el momento de venderla.

• Es mucho más fácil de lo que parece contraer involuntariamente una deuda impagable. Nunca hay que hacerse personalmente avalista del buen fin de ninguna aventura empresarial.

• Es importante comprometerse con el mínimo absoluto de ataduras vitales a largo plazo: económicas, laborales, familiares, etc.

• Si tuviste éxito con tu primer negocio, preocúpate, pues probablemente no has aprendido mucho y, por consiguiente, lo próximo que te espera es un tortazo épico debido a tu exceso de autoconfianza.

• El pánico cunde rápidamente y el valor no es una virtud muy común, de modo que mejor si cuentas con algunos mecanismos cohercitivos extra para mantener a la gente en su sitio cuando la cosa se ponga fea.

• Los negocios consisten en cobrar el máximo que se pueda a los clientes y pagar el mínimo posible a empleados y proveedores. Aunque no quieras comportarte así el mercado y los inversores te obligarán a ello. Si te has creído el cuento de la reputación y responsabilidad corporativa pon en los comentarios un ejemplo real de empresa que haya conquistado un mercado con esa estrategia.

• Si indagas en la historia de alguien exitoso, casi seguro descubrirás que aprovechó una oportunidad que se le presentó, no desperdicies la tuya por cuestiones sentimentales.

• Los hombres y las mujeres viven, en general, motivados por incentivos diferentes. A los hombres les motiva el dinero y el poder. A las mujeres las relaciones sociales y el logro. Diseña tus incentivos en función de las aspiraciones de cada persona.

• En general, no es posible hacerlo todo bien y agradando a todo el mundo. Si lo intentas contra viento y marea acabarás probablemente con ganas de suicidarte.

• La mayoría de la gente tiene mucho miedo a perder trabajo. Curiosamente no parecen tener tanto miedo de perder a la familia o a los amigos por causa del trabajo. Aunque es mucho más fácil encontrar otro trabajo que otra familia u otros amigos.

• Al final lo que importa son las relaciones entre las personas, si haces cosas por otros motivos a costa de la gente a la postre te darás cuenta de que cometiste un craso error.

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

Sobre la fuerza de ventas

Los dos puestos más difíciles de cubrir en una empresa son los ingenieros senior y los comerciales sistemáticamente exitosos. Vender es tan costoso que muchísimas empresas tratan de evitarlo mediante inbound marketing, canales de venta o cualquier otro medio.

Hace un par de semanas tuvimos una sesión de técnicas de comercialización en EO Network. No me voy a extender demasiado acerca de los beneficios de pertenecer a una asociación de mentoring como EO, pues parecería que intento venderla y, ni tengo ahí el bocadillo ni cobro nada por ello, simplemente lo cuento como uno de los muchísimos miembros que recomiendan EO año tras año. Este post está basado en partes del contenido de una sesión privada sobre comercialización en EO.

¿Cuándo contratar a un comercial?

La primera cosa que hay que saber acerca de los comerciales es que venden tanto hacia afuera como hacia adentro de la empresa. Por consiguiente, es necesario evaluarles con métricas que permitan determinar si realmente compensa tenerlos en nómina o sólo están vendiendo la moto internamente con expectativas irreales.

Para la métrica básica de rentabilidad de un comercial se necesitan los siguientes parámetros:

N = Número de transacciones comerciales
T = Tamaño de cada transacción
M = Margen medio por transacción en porcentaje sobre el tamaño
C = Coste fijo del comercial (salario + gastos)

Entonces el número mínimo de transacciones comerciales que el vendedor debe llevar a cabo para resultar rentable se alcanza cuando su coste total es igual al beneficio generado por todas sus ventas: C = N × T × M o despejando N = C ÷ (T × M) Veamos un ejemplo concreto. Supongamos que el comercial cobra 30.000€ anuales de sueldo base y necesita 10.000€/año en gastos. El tamaño medio de cada transacción son 1.000€ y el margen medio por transacción es del 40% Entonces el número de transacciones que tiene que cerrar a lo largo de un año es 40.000 ÷ (1.000 × 0,45) = 100

El margen debe incluir la comisión del comercial, además es preciso fijar margenes mínimos para cualquier operación. Todas las organizaciones que funcionan de forma razonable fijan márgenes mínimos en torno al 20% pues de lo contrario los comerciales tienden a aumentar la cifra de ventas a costa del margen para la empresa hasta que el beneficio de cada venta se emplea sólo en pagar su comisión.

Es muy habitual que sea imposible alcanzar la cantidad mínima de transacciones de venta al año como para que un comercial sea rentable. Entonces hay que recurrir bien a invertir más en marketing bien a potenciar el inside sales.

¿Cómo se puede mejorar la eficiencia de un comercial?

A los comerciales les motiva casi exclusivamente el dinero. A casi todo el mundo le motiva el dinero pero a los comerciales más que a nadie. A partir de tener cubierto el factor higiénico de la retribución, se puede hablar de cómo mejorar su productividad.

Lo primero de todo a saber es que a un comercial hay que decirle lo que quieres vender, cómo, a quién, cuándo y por qué. Algunos ingenieros tienen la brillante idea de “la mejor trampa para ratas” y piensan que podrán reclutar un comercial lo bastante bueno como para conquistar el mercado de control de plagas. Esto es, en general, falso. Al comercial hay que darle hecho:

• Brochureware lo más detallado posible del producto a vender.
• Listado de clientes potenciales con los que tiene que contactar.
• Argumentario de ventas y ventajas competitivas frente a otros productos.
• Objetivos de contactos y ratios de conversión y márgenes mes a mes.

Es importante que todo el proceso de venta sea sistemáticamente repetible. Simplemente darle un producto a un comercial y mandarle a la calle a venderlo no sirve para nada. Es más, peor que nada, pues incremente inútilmente los gastos.

Cuando ya se tienen claras las tácticas de comercialización es posible empezar a pensar en utilizar herramientas que mejoren la productividad. Lo básico es un CRM. CRMs hay muchísimos porque los procesos de venta son totalmente diferentes de un sector a otro. Hay básicamente tres opciones: los productos Open Source, como hipergate (de los que cada vez quedan menos), los SaaS tipo Salesforce, Vtiger o Zoho, y los grandes y costosos paquetes integrados de software privativo de toda la vida. En paralelo a las herramientas básicas para gestionar la base de datos se pueden utilizar otras específicas para mejorar la productividad de la fuerza de ventas como SalesLoft, Rivalry o Voxa.

¿Cuándo escalar la fuerza de ventas?

Como en cualquier otro departamento se necesita una medida para determinar cuándo es necesario contratar a más comerciales. Daré aquí dos disparadores muy sencillos:

a) Cuando el coste total trimestral de ventas es inferior al ingreso obtenido por nuevas ventas para el año siguiente.

b) Cuando el ingreso anual recurrente de ventas pasadas es tres veces el coste total anual de las ventas.

Diapositivas en SlideShare: Tácticas de Comercialización.

Post relacionados:
Cómo engrasar la maquinaria de ventas SaaS
Técnicas de venta guerrillera en tecnología
¿Qué puede hacer una empresa para llamar la atención sobre su producto?

Publicado en Mercado y Oportunidades de Negocio, Modelos de Negocio | 2 comentarios

La “tasa Google” y el canon al RSS

Hace ya bastante tiempo que andaba esperando que España se alinease con Francia, Alemania y Bélgica en la imposición de algún tipo de peaje a los buscadores y agregadores de noticias. No me gusta mucho escribir acerca de las negociaciones por el céntimo en propiedad intelectual, pues me parece que ahora mismo tenemos sobre la mesa problemas mucho más perentorios, pero siendo un tema tan polémico y con tan pocas opiniones neutrales le voy a dedicar unas líneas.

¿Qué es justo?

Empecemos por los fundamentos. La hipótesis de partida es que los periódicos ofrecen información “gratuita” a cambio de que los usuarios vean la publicidad que acompaña a dicha información. Si los usuarios ven la información pero no la publicidad entonces se rompe el contrato implícito en tal relación. Debido a que las empresas como Google crean una disrupción en ese modelo, merecen ser fiscalizadas para evitar abusos. Esa es la lógica subyacente en la nueva LPI para la compensación a los editores de medios de comunicación que AEDE lleva tiempo solicitando al gobierno. La imposición de un pago a quien crea una disrupción es algo así como cobrarle al tramposo. Existe una manera de hacer las cosas y de repente llega alguien y encuentra una forma de “hacer trampas”, es decir, crea una disrupción. Entonces es discutible si el nuevo jugador que está obteniendo unos pingües beneficios a costa de los otros debería compensarles por su audacia. Además, no se habla del tráfico que Google induce gratuitamente a los medios por el cual Google también podría pedirles una compensación sólo por poder aparecer en las listas de resultados.

¿Qué se ha hecho hasta ahora en Europa?

Seguidamente, veamos cuales han sido los precedentes en Europa. En Alemania, se obligó a Google a pactar con cada medio una compensación, en Francia se le impuso a Google un pago de 60 millones de euros a repartir entre los medios y en Bélgica se prohibió directamente a Google que enlazara a los medios sin un acuerdo previo con ellos. Cada una de estas “soluciones” tiene sus inconvenientes. La alemana porque, como los acuerdos son uno a uno, es posible que los grandes medios puedan sentarse a la mesa de negociación en igualdad de condiciones con Google pero los pequeños obtendrán un “lo tomas o lo dejas” en una negociación a la siciliana por parte de Google. La francesa porque Google se las apañó para que los 60 millones se repartiesen contra proyectos de generación de contenidos que tenían que presentar los medios, es decir, se creó una situación de concurrencia competitiva por el dinero de Google. Y la belga, pues, bueno, porque se asemeja a la solución de curar la enfermedad por la vía de matar al paciente.

¿Por qué hay tanto lobby de los medios?

Lo que sucede es que los medios están económicamente mal. Y no sólo en España. Hasta el Washington Post acabó en manos de Jeff Bezos. Yo personalmente creo que la razón principal (entre otras muchas otras) de que Pedro J. Ramírez dejase la dirección de El Mundo es sencillamente que la prensa impresa se está muriendo de obsolescencia lo mismo que murió la máquina de escribir. Como prácticamente todos los medios han tenido históricamente una afiliación partidista, se produce entonces una reacción de apoyo paternalista por parte del Gobierno cuando su viabilidad económica peligra. Pienso que este intervencionismo en el mercado es malo. No porque opine que Google tenga moralmente razón sino porque, en general, todos los intervencionismos en el mercado suelen ser contraproducentes para la sociedad.

Los medios tratan de defenderse arguyendo que son uno de los pilares básicos de la democracia y que si desapareciesen con ellos desaparecería uno de los elementos esenciales del estado de derecho. Este es un razonamiento espurio. Es cierto que no puede haber democracia real sin derecho a la información y libertad de prensa. Pero dichas libertades no tienen necesariamente que articularse a través de periódicos, los cuales son sólo un medio de transporte de la información. Además del desprestigio innegable de casi todos los medios debido a su sesgo en favor del partido político que les patrocina. La mayoría de los medios son puros panfletos propagandísticos y con su cierre sólo desaparecería un instrumento de desinformación. Y no es que los grupos de opinión en redes sociales con los que se informa cada vez más gente sean para nada imparciales, todo lo contrario, son aún menos veraces que los periódicos, pero al menos se sabe de qué palo va el grupo de opinión y hasta dónde se puede uno fiar, o no, de lo que dicen.

¿Qué sucede con la fiscalidad de las multinacionales?

Por otra parte, Google no es ningún corderito. Según algunas estimaciones desvía unos 10.000 millones de dólares al año desde Europa a Bermudas de forma totalmente legal. La situación en la que la tasa impositiva real que se aplica a Google parece que ronda el 2,4% no es nada justa para las otras empresas que tributan, en teoría, al treinta y tantos por ciento. No obstante, yo estoy firmemente convencido de que el impuesto de sociedades no debería de existir. Por dos motivos: 1º) porque mientras se pueda mover dinero legalmente entre países con diferentes sistemas fiscales es inútil intentar imponer que una empresa global tribute en un pais que es fiscalmente más caro que otro, y 2º) porque el beneficio de una sociedad mercantil sólo puede emplearse de dos formas, bien para generar más inversión, crecimiento y puestos de trabajo, bien para repartir dividendos entre los accionistas. También puede simplemente quedarse en la caja de la empresa pero en algún momento futuro se hará alguna de las dos cosas anteriores pues mantener dinero ocioso es estúpido. El Impuesto de Sociedades merma directamente la capacidad de las empresas para crear riqueza reinvirtiendo beneficios y, por consiguiente, es terriblemente dañino para el crecimiento económico. En conclusión, no creo que se deba tratar de aumentar los impuestos a Google del 2,5% (o lo que sea) al 30% sino hacer que TODAS las empresas tributen al 2,5% sin necesidad de llevarse el dinero a Bermudas vía Irlanda.

¿Por qué la están liando?

Desde mi punto de vista, la intención de fondo en la reforma de la LPI no es mala. Se trata de que multinacionales extranjeras paguen a medios españoles quienes, a su vez, usarán parte de ese dinero para generar puestos de trabajo y pagar impuestos en España. El problema es que la reforma, o lo que se sabe de ella (porque hasta ahora se han explicado como un libro cerrado) demuestra que todavía se tiene poco conocimiento, o no se quiere aceptar, cómo funciona Internet. No se pueden poner puertas al campo. No sé cómo se va a determinar esa “compensación equitativa” a los medios de la que habla la ley. Supongo que se hará regateando como los gitanos (con perdón) y para evitar que se produzcan agravios comparativos entre medios grandes y pequeños, como ha pasado en Alemania, se delega la negociación colectiva en Cedro y Vegap, de las cuales no dudaría, de no ser por el precedente nefasto de la SGAE y su tremenda trama de corrupción. Asimilar Cedro y Vegap a la SGAE es hacer pagar a priori a justos por pecadores, mas habrá que esperar a ver qué pasa…

La obligación de una compensación por enlazar fragmentos no significativos podría inducir, llevada al absurdo, a la aplicación de un canon a los canales RSS similar al canon digital que finalmente abolió la Unión Europea.

¿Y si todos los autores se asociaran a Cedro? El coste de adhesión es gratuito. ¿Porqué sólo retribiur a los periódicos? ¿Tendría Google que pagar por todas y cada una de las visitas que manda a cualquier web con contenidos originales?

Los indexadores podrían banear a los medios uno por uno en una estrategia de divide y vencerás. Ricardo Galli ya ha dicho que en menéame banearan a cualquier medio que trate de cobrarles por los enlaces. Y si menéame puede permitirse el lujo de hacer eso ¿por qué no Google? Que se sepa, la ley no contiene ninguna prohibición de guerra sucia mediante la cual el indexador pueda arbitrariamente dirigir tráfico a medios que no cobren por derechos.

En el otro gran aspecto de la reforma de la LPI, las nuevas sanciones civiles y penales para los facilitadores de actividades vulneradoras de la propiedad intelectual, no voy a entrar aquí, porque son un despropósito tan grande que merecería otro post entero.

En conclusión con esta “tasa Google” el Gobierno probablemente ha creado una Hidra de Lerna a la que le irán saliendo nuevas cabezas, ya veremos si dos, nueve o diez mil.

Artículos relacionados:
Derecho por agregación de contenidos en la reforma de la LPI y su impacto a servicios de internet (David Maeztu)
Preguntas frecuentes sobre la nueva Ley de Propiedad Intelectual (David Bravo)
El vampiro no es Google (David Fernández)

Newspaper extinction timeline

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Disrupción, Entorno Legal del Software Libre, Libertad de Expresión | 3 comentarios

El kōan sobre cuánto pesa un problema

Coge un problema que te abrume, cierra los ojos y visualízalo en tu mente, estúdialo con detalle, todo el tiempo que quieras. Ahora extiende tu brazo con la palma de la mano hacia arriba e imagínate que el problema sale de tu mente y se posa en tu mano. Mantén el brazo recto y dime ¿cuánto pesa el problema?
Sigue leyendo

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

Cosas a tener en cuenta en el despliegue de software

Military PornYo no soy militar pero no me cabe ni la menor duda de que la logística es un factor clave para ganar cualquier guerra. El software también tiene su logística y es tan fundamental para conquistar un mercado como para ganar una campaña militar. El Software Libre consiste en gran parte una disrupción en la forma en que se distribuye el código. Afortunadamente ya no hay que distribuir el software en CD-ROM ¡o en diskettes! Mediante el SaaS ya no hay ni siquiera que distribuirlo en absoluto, pero hasta los SaaS archiconocidos tienen despliegues, los cuales son el tema de este post.

Lo primero que hay que entender acerca de los despliegues es que cada empresa tiene su propia metodología que es la mejor, para ellos. Es la mejor para ellos porque cada aplicación tiene sus propias peculiaridades y, por consiguiente, la metodología que es fantastica para una aplicación puede ser desastrosa para otra.

Estrategias de incorporación de mejoras

Existen a grandes rasgos tres estrategias de despliegue e implantación:

1ª) Desarrollar un núcleo de producto y hacer las adaptaciones a medida por fuera mediante plug-ins o kits de desarrollo.

2ª) Incorporar las funcionalidades de los clientes dentro del producto principal.

3ª) Ignorar por completo las demandas de los clientes y convencerles a ultranza de que usen el producto “tal cual” porque ello es lo que aportará mayor valor a sus procesos de negocio.

La viabilidad de cada una de estas estrategias depende del tipo de software y del número de clientes. Para software de gestión financiera, por ejemplo, la tercera puede ser una opción porque la contabilidad y las finanzas se manejan, en general, de forma muy similar en todas las empresas. Pero en cambio si se trata de un CRM es imposible fabricar un producto de “talla única” porque los procesos de venta de un sector vertical no se parecen en nada a los de otro.

El número de clientes también importa, una empresa que tenga una decena puede posiblemente permitirse ir incorporando todas las mejoras en el producto principal pero en una que tenga varios centeneres de clientes eso es imposible por tres razones: a) el elevadísimo número de programadores que se requeriría; b) el lio que se armaría al estar tocando el núcleo todos a la vez y c) la complejidad inmanejable que adquiriría la aplicación.

La estrategia de incorporación de mejoras determina la estructura que deben tener los equipos de desarrollo y servicios. Si hay un único producto en el cual se incorpora todo entonces no es necesario contar con un departamento de servicios de implantación pues es posible asignar a los programadores directamente a proyectos de clientes e ir rotándolos en funciones de análisis, codificación y soporte. Si no es factible incorporar todas las mejoras en el producto principal entonces se requiere una política de gestión de los productos derivados generados a la medida de cada cliente por un partner o un departamento de servicios internos.

Fases de la Implantación

Todas las metodologías de implantación tienen más o menos las mismas fases y hablan de las mismas cosas: de la importancia de realizar un buen análisis, de la gestión del cambio, etc. Tratan de aspectos generales y, como el demonio está siempre en los detalles, no es infrecuente que gerentes y usuarios en el cliente acaben hasta las narices del nuevo software de marras. La mayoría de las metodologías específicas de software son adaptaciones de otras más generales como DSDM, Prince2 o Metrica3 que a su vez están basadas en estándares como ISO/IEC 12207 o TOGAF.

Fases de Implantacion de Software

Análisis de Requisitos

Tras el presupuesto que, curiosamente, en muchos casos se ha hecho antes que el análisis, empieza el análisis y modelado de requisitos. Las técnicas de modelado también puedes ser propietarias del fabricante como el Dynamic Enterprise Modeling de BaaN, SAP ARIS u Oracle AIM. Las técnicas de modelado son principalmente de cuatro clases:

• Modelado de datos.
• Modelado de funciones y procesos.
• Modelado de flujos de trabajo.
• Modelado de estructura corporativa.

Antaño se modelaban primero los datos y luego los procesos. Ahora está más de moda usar herramientas de definición de flujos de trabajo algunas de las cuales son tan modernas que hasta generan dinámicamente el modelo de datos que supuestamente debería haber por detras.

No hay espacio en un post ni tan siquiera para arañar la superficie de todas las metodologías de modelado que existen, pero aquí lo que me interesa no son sus entresijos sino cómo se aplican en la práctica.

El primer paso suele ser hablar con los usuarios. A fin de cuentas se supone que lo más importante son los usuarios ¿no? Pues bien, sucede muy amenudo que los usuarios no saben lo que quieren o, si lo saben, entonces son incapaces de explicarlo de forma estructurada para que un analista lo entienda. Muy pocos usuarios tienen metaconocimiento acerca de cómo hacen su trabajo. No es infrecuente que los usuarios pidan funcionalidades que a la larga irían evidentemente en detrimento de la usabilidad del software. En esencia de los usuarios quieren introducir y buscar datos de cualquier manera pero luego obtener resultados perfectamente precisos en los informes y flujos de trabajo a prueba de errores.

Resistencia al cambio

Tan pronto como se entablan los primeros contactos con los usuarios empieza la resistencia al cambio. Este es un fenómeno natural porque incluso aunque el nuevo sistema sea mucho mejor que el anterior y además funcione perfectamente, los usuarios, como mínimo, tendrán que aprender a manejarlo. Lo que yo he aprendido a lo largo de los años acerca de la formación a usuarios es más o menos lo siguiente:

1º) No importa cuántas veces se les explique a los usuarios la teoría sobre cómo funciona un sistema, hasta que no hagan algunos ejercicios no lo van a entender. Para aprender acerca de algo, la verdad no puede ser dada, sino que debe ser descubierta.

2º) Nunca hay que reunir a más de 8 o 10 usuarios en una sala a la vez. Si el grupo de alumnos es demasiado grande pueden sindicarse para atacar en bloque al formador.

3º) Empezar la formación de forma temprana, antes de que el software esté listo para salir a producción puede ser una buena técnica para detectar necesidades no descubiertas durante el análisis, pero cuidado, porque si faltan funcionalidades durante la formación los usuarios se pondrán nerviosos y extenderan por los pasillos rumores terroríficos acerca del nuevo software.

4º) El mejor estilo de documentación para usuarios me lo mostró un gerente de proyectos que conozco desde hace años, se trata del documento GUIABURROS. El guiaburros es un PowerPoint con poco texto que explica paso a paso cómo completar una o varias tarea. La clave para un guiaburros exitoso es aturullar lo menos posible al usuario con explicaciones conceptuales y llevarle directamente a la resolución de la tarea que tiene pendiente en ese mismo momento.

Y cuidado porque el hecho de que un sistema genere eficiencias en la producción no implica para nada que los usuarios vayan a verlo con buenos ojos. Conviene recordar que la palabra saboteador parece ser que proviene de aquellos obreros de la revolución industrial que metían zuecos en las máquinas para averiarlas en señal de protesta.

Validación y control de calidad en cliente final

Para poder cerrar un proyecto hay que conseguir una lista de procesos de negocio documentados, validados y aceptados por el cliente. Al menos esa es la teoría, porque en la vida real los usuarios más que seguir siempre un conjunto de procesos tienden más bien a usar el software como les da la gana.

Por otra parte, es necesario disponer de algún sistema de tickets para hacer seguimiento de las incidencias y llevar el control de las horas empleadas. Yo personalmente uso Redmine o Jira, pero hay muchas herramientas de seguimiento y control Open Source, EULA o SaaS como Basecamp.

Precarga de datos y transición desde el sistema antiguo al nuevo

Las cargas de datos pueden ser algo muy complejo y traicionero. Nunca hay que subestimar el esfuerzo que puede requerir una carga de datos, ni siquiera con las mejores herramientas ETL (Extract, Transform, Load). Lo mejor con las precargas de datos es empezar con las pruebas tan pronto como se disponga del nuevo modelo de datos.

Cambiar de un sistema a otro puede ser extraordinariamente delicado. Muchos clientes simplemente no pueden permitirse ni una hora de parada de servicio. A veces se puede montar un Enterprise Software Bus (ESB) para sincornizar durante un tiempo los datos entre el sistema antiguo y el nuevo, pero en otras ocasiones hay que hacer simplemente el “cambiazo” entre un sistema antiguo y el nuevo.

Si se puede instrumentar desde fuera, el sistema puede servir en algunas ocasiones como medio de control, comparando la salidas que produce frente a las del sistema nuevo.

Actualizaciones y soporte post-venta

Entre los equipos Ágiles son muy comunes las herramientas de integración contínua como Maven o Jenkins. Lo que no es tan común es oirles hablar sobre cómo llevar el control de versiones en el cliente.

Cualquier software distribuible que no esté específicamente diseñado para volver loco al que lo mantiene debe necesariamente de disponer de un mecanismo para enviar un reporte de todos los componentes y versiones en uso al fabricante. Recalco en uso porque en una ocasión yo me encontré una instalación que tiraba de una DLL registrada en la papelera de Windows.

También es fundamental que el instalador lleve un control del orden en que pueden instalarse (o no) las actualizaciones.

Para el soporte post-venta hay dos opciones: que lo presten directamente los desarrolladores o que los preste un departamento de servicios especializado. Elegir una u otra opción depende de la estrategia de incorporación de mejoras que se haya seleccionado. Si todas las mejoras se incorporan en una única rama de código entonces tiene sentido que los programadores, por turnos rotativos presten soporte directo a los clientes. Es mejor que sean turnos rotativos bisemanales puesto que si la misma persona está desarrollando y dando soporte simultáneamente entonces cuando no cumpla los plazos de desarrollo argüirá que estuvo prestando soporte y cuando el cliente se queje de mala calidad de servicio alegará que tenía que desarrollar para llegar al último sprint. Si las mejoras se incorporan en plug-ins o módulos externos lo lógico es que el soporte de primer nivel lo preste quien ha creado dichos módulos apoyado por soporte de segundo nivel de los desarrolladores del núcleo. La gestión de expectativas y cabreos del cliente es toda una disciplina en sí misma que frecuentemente requiere de personas especialmente hábiles en reducir los niveles de crispación y frustración de otras personas.

Planes de contingencia

En un proyecto pueden ir mal esencialmente tres cosas:

1ª) Puede que sea imposible cumplir los plazos. Por culpa de quien sea, del implantador, del cliente o de los elementos. El caso es que el problema le tocará solucionarlo al implantador.

2ª) Que el sistema funcione mal, con demasiadas incidencias, lento o de forma funcionalmente limitada.

3ª) Que tras intentar su implantación esta se demuestre inviable y haya que cancelar todo el proyecto.

Seré muy breve a este respecto, es razonable pactar que el proveedor arreglará gratuitamente los defectos software que pudieren aparecer en un periodo de tiempo posterior a la puesta en producción. Pero lo que no hay que hacer es jamás ni por ningún motivo aceptar penalizaciones expresas por retrasos u otros incumplimientos en los contratos. Esto es debido a que las penalizaciones pueden convertirse, de hecho, en un incentivo para que al cliente le interese terminar tarde el proyecto y así impagar parte del precio.

Cierre de proyecto y entrega de medallas

Todo proyecto digno se cierra con una entrega de medallas y diplomas. Conviene recordar que hasta Hitler ascendió a Paulus a Mariscal de Campo justo antes de la caída de Stalingrado. Normalmente, Cuando un directivo propone la compra de un paquete de software ya no puede permitirse el lujo de criticar al proveedor pues al criticarle estaría admitiendo indirectamente que se ha equivocado y se convertiría en objetivo de los dardos envenenados de otros directivos (suelen ser así de majos entre ellos). Lo ideal es crear la historia de un caso de éxito que sea noticiable. La campaña de marketing posterior al lanzamiento puede ser incluso parte de la propuesta de proyecto inicial. El caso de éxito de le interesa a todo el mundo: a la empresa porque mejora su eficiencia y su imagen frente a los clientes, al responsable de la compra porque la fama supone una oportunidad de promoción y al proveedor porque es una referencia que puede utilizar para venderle el mismo software a otros clientes del mismo sector.

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

Cheat Sheet de marrones en un proyecto

Todos los proyectos de desarrollo de software presentan la misma clase de problemas, se conocen, y por eso se han creado las diversas metodologías que tratan de paliarlos. Aún así rara vez se hacen las cosas del todo bien debido a la naturaleza intrínsecamente falible del ser humano. He intentado resumir en un cheat sheet los problemas más comunes.

Cheat Sheet Gestion Proyectos

Cheat Sheet Gestion Proyectos

Descargar en PDF

Mas… ¡un momento! antes de que pienses en pegar con celo la cheat list en algún lugar visible. Debes conocer algunos conceptos de la jerga imprescindible en la gestión de proyectos informáticos.

Para empezar, en un proyecto informático JAMÁS se habla de “errores” sino de “incidencias” o, a lo sumo, de “defectos software”. La razón para esto es que el “error” es directamente atribuible a alguien, alguien se ha equivocado, mientras que la “incidencia” sugiere algo que ha pasado fortuitamente, y el “defecto” parece una característica intrínseca del código, que salió defectuoso como puede salir defectuosa una magdalena del horno debido a un grumo en la levadura.

Existen tres niveles de gravedad operativa en cualquier incidencia: el tema (T), el tema turbio (T²), y el tema tope turbio (T³).

Tema. El “tema” es cuando alguien hizo un bucle de 1 a n-1 que debía ir de 1 a n y al último de la lista el software nunca le envía su transferencia de nómina. Bueno, no pasa nada, se hace a mano y en paz, el cliente puede esperar. El tema se distingue porque puede figurar en el bug tracker, y se despacha alegando que fue culpa del cliente por no tener instalada la última versión. El tema no se detectó en los test porque a nadie se le ocurrió escribir un test tan tonto como “a final de mes todos los empleados deben haber cobrado la nómina”.

Tema Turbio. El “tema turbio” (o T²) es cuando alguien se ha olvidado de que algunos conceptos de nómina no son susceptibles de retenciones y a todos los empleados se les han retenido 2€ de más. En el cliente, el del sindicato se ha reunido con el director de recursos humanos y se ha armado la de Dios. El tema turbio no figura en el bug tracker, porque no es un bug (si lo fuera podría peligrar el variable de alguien) ergo se despacha alegando que es culpa del departamento de servicios, porque está plagado de zotes que no saben hacer ni una simple parametrización. El tema turbio no se detectó en los test porque no es un defecto software, la aplicación es así “por diseño”.

Tema Tope Turbio. El “tema tope turbio” (o T³) es cuando el software ha confundido los puntos con las comas y le ha pagado a todos los empleados del cliente dos ceros de más. El T³, por definición, no existe. Se resuelve echándole la culpa a la gravedad cuántica. Esto parece imposible, en principio, mas no hay que olvidar que la informática es la única ciencia en la cual un profesional le puede dar a otro profesional una explicación que es, de forma simultánea, perfectamente verosímil y totalmente falsa. El responsable del T³ es un becario y no se detectó en los test porque se supone que la aplicación debe alimentarla de datos un ser humano y no un chimpancé. El T³ se conoce también como “ELAC” (Evento Ligado a la Actualización del Currículo).

En otra dimensión a la gravedad operativa existe la gravedad gerencial. En la gravedad gerencial se distingue:

Problema: El jefe de tu grupo se reúne con el jefe de otro grupo en la mesa de alguno de los dos.

Lio: El jefe de tu departamento se reúne con el jefe de otro departamento en el despacho de alguno de los dos.

Embrollo: El jefe de tu departamento se reúne con el jefe de otro departamento en el despacho de uno de los vicepresidentes.

Follonazo: El vicepresidente de tu división se reúne con los otros vicepresidentes en el despacho del presidente.

Chiringuito Total: El vicepresidente de tu división, se reune con los vicepresidentes de otras divisiones y el presidente, más el director de recursos humanos y el director de la asesoría jurídica todos ellos en el despacho de un gabinete de abogados independientes.

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