Programación orientada a procesos de negocio

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

BPM

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

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

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

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

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

Order Fullfilment BPM

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

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

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

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

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

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

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

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

DMN

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

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

DSI Entities

Business Rule

Herramientas

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

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

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

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

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

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

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

SaaS

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

Conclusiones

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

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

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

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

Post relacionado: Introducción a Domain Driven Design.

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

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

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

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

Acceso a cuentas

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

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

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

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

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

Escasez de programadores

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

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

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

Ineficiencias en el proceso de selección

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

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

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

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

y etcétera, etcétera.

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

Dificultades en la gestión del proyecto

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

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

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

Conclusión

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

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

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

Internet de las Cosas es Gran Hermano

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

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

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

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

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

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

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

Post relacionado: Escapar de Gran Hermano

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

Cómo elegir librerías y sobrevivir a JavaScript

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

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

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

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

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

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

Librerías JavaScript agrupadas según su funcionalidad principal

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

Dojo

Bootstrap
AngularJS

React.js

Backbone.js
LESS

Sass

Pure

Zimit
npm

Bower

RequireJS
Modernizr

Date.js

plotly.js

Textures.js

Hammer.js

Lightbox
CoffeeScript

PureScript

ClojureScript

Dart

TypeScript

ECMAScript6

Interfaz visual

JQuery

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

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

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

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

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

Dojo Toolkit

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

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

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

AngularJS

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

React.js

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


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

será traducido por React.js a

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

Bootstrap

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

Date.js

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

LESS y Sass

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

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

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

Pure

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

Modernizr

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

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

Otras librerías

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

Gestión de la configuración

npm

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

Bower

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

Require.js

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

Alternativas sintácticas

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

Conclusiones

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

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

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

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

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

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

Inteligencia emocional artificial

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

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

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

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

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

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

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

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

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

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

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

Google y Microsoft liberan herramientas de inteligencia artificial

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

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

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

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

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

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

Qué caracteriza a un mensaje viral

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

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

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

Atributos que contribuyen a hacer un contenido viral

Valor social.

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

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

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

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

Emocionalidad.

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

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

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

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

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

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

Formato.

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

Historia.

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

Distribución de mensajes virales

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

Canales.

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

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

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

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

Detonantes.

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

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

Influenciadores, imitación y prueba social.

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

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

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

Hora y día de la difusión.

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

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

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

Lo que sucede cuando un software se convierte en un agujero negro

Un agujero negro se empieza a formar cuando una estrella de masa al menos 2,5 veces la del Sol se convierte en una supernova e implosiona hasta formar una singularidad de la cual nada puede escapar.

De forma análoga, una aplicación de software lo suficientemente grande puede sufrir un proceso de colapso y convertirse en un agujero negro siguiendo la secuencia que viene a continuación.

Fué a Bjarne Stroustrup a quién le leí que “un sistema grande y complejo que no ha evolucionado a partir de otro más simple que funcionaba bien, no funciona y, además, es imposible arreglarlo para que funcione” (creo que esto es del libro The Design and Evolution of C++ publicado en 1994). Tal hipótesis se comprobó empíricamente muchas veces en el siglo XX y es por eso que se cambió el foco a proyectos ágiles.

De modo que es mejor empezar con un mínimo producto viable (MVP). El desafío es que aunque el producto sea inicialmente pequeño su arquitectura debe estar pensada para crecer. Ello supone un equilibrio muy difícil entre la simplicidad y la escalabilidad.

El MVP es, por lo general, una chapuza, aunque si los adoptadores tempranos están lo bastante necesitados, la empresa llega a la versión 2.0 que es la que suele tener verdadero éxito comercial. En la versión 2.0 ya se ha adquirido un buen conocimiento del problema a base de depurar la versión 1.0 pero el producto todavía lo mantiene poca gente y no ha crecido hasta un tamaño desmesurado. La versión 2.0 es una bonita estrella de tamaño mediano como nuestro Sol.

En la industria del software, con una buena versión estás en el negocio y con una mala estás fuera. Tras la versión 2.0 hay dos formas rápidas de morir: por el efecto del segundo sistema o por agujero negro.

El segundo sistema es, básicamente, rediseñarlo todo desde cero en contra del consejo de Stroustrup. Siguiendo la analogía se trata de crear una supergigante azul que pesa demasiado y genera demasiada gravedad y calor.

La dinámica del agujero negro en software

Siguiendo la secuencia principal la estrella 2.0 se convierte en una gigante roja que funcionalmente sirve para todo y no hace bien absolutamente nada. En este momento algunas cosas empiezan a pasar:

– Un grupo de desarrolladores radicales mantiene algunos puntos de vista inflexibles acerca de cómo debe ser la arquitectura del sistema.

– Al MVP se le van añadiendo funcionalidades sprint tras sprint.

– Individualmente, las funcionalidades parece que tienen sentido, pero están dictadas por las necesidades impuestas por diferentes clientes y todas juntas generan un producto complejo e inconsistente.

– Como los sprints son cortos, las prioridades cambian con frecuencia y muchas funcionalidades quedan inacabadas.

– El backlog del producto crece de forma continuada.

– Simultáneamente, cada vez se emplea una cantidad de tiempo creciente corrigiendo bugs.

– Los tests unitarios no son de gran ayuda pues aunque los módulos funcionen bien la arquitectura sigue fallando.

– Debido a la acumulación de deuda técnica, los jefes de equipo empiezan a quejarse sistemáticamente sobre la falta de recursos humanos para el desarrollo.

– Sin embargo, a pesar de agregar más recursos se incrementan los retrasos en las fechas previstas.

– Superado un determinado umbral de complejidad, se inicia un colapso cuyo desenlace fatídico es inevitable. Con cada nueva versión el software es más lento y más inestable hasta que llega un momento en el que no se dispone de ninguna versión reciente que alcance el nivel de calidad requerido para entrar en producción.

Síntomas de que la aplicación se está colapsando

– En cada versión se introducen más bugs que funcionalidades.

– Nadie confía realmente en que la última versión sea estable.

– En el dpto. de calidad ya no saben muy bién qué testear ni cómo.

– Cada vez se tarda más en sacar una versión.

– El rendimiento de la siguiente versión es sistemáticamente peor que el de la anterior.

– Empiezan a aparecer aplicaciones satélite que hacen lo mismo que debería hacer la aplicación original pero “mejor”.

– Se convocan reuniones recurrentes a diario para seguir el progreso de determinados temas.

– Los jefes de equipo críticos con la dinámica de trabajo empiezan a desaparecer de la plantilla por razones poco claras.

– El sprint board se ha convertido en lo que gobierna la estrategia de la empresa, dictando lo que se puede hacer (o no) y cuándo.

Razones del colapso

a) La arquitectura del software es tal que contiene la semilla de su propia destrucción.

b) Alguna pieza del producto causa problemas constantemente.

c) El rendimiento está sistemáticamente por debajo de lo aceptable.

d) La configuración y mantenimiento de la aplicación es extraordinariamente costosa.

Reemplazar una pieza defectuosa parece un problema fácil a primer vista, pero puede no serlo porque exista miedo de que el recambio será aún peor, o el programador que la desarrolló ya no está o existen acuerdos con terceros que obligan a usarla.

El rendimiento típicamente es malo por una o varias de la siguientes razones:

– Las peticiones de red son demasiadas.
– Los accesos a la base de datos son excesivos y/o ineficientes.
– La aplicación tiene una estructura en múltiples capas como una cebolla.
– Algunos algoritmos son demasiado costosos.

Las mayores ganancias se obtienen optimizando los recursos más lentos, por orden: red, disco, memoria y CPU.

Es frecuente que las herramientas para la gestión de la configuración sean paupérrimas. Se invierte mucho tiempo en lo que ve el cliente en detrimento de lo que necesitan los implantadores y operadores y despreciando el principio de cibernética que establece que la complejidad de cualquier sistema de control es siempre proporcional a la complejidad del sistema controlado.

Cómo eludir el agujero negro

Lo peligroso de la dinámica del agujero negro es que no es fácil percatarse de que la estrella está punto de colapsarse súbitamente. Con un producto en fase de “gigante roja” es necesario tomar medidas perentoriamente:

1. Reconocer que el producto requiere una re-ingeniería profunda.

2. Detener por completo el flujo entrante de nuevas funcionalidades.

3. Nombrar un nuevo arquitecto jefe.

4. Organizar sesiones de diseño donde todos los que tienen experiencia en el desarrollo y uso del software puedan participar en igualdad de condiciones.

5. En general, mejor evitar los comités para la toma de decisiones, pues tienden a adoptar soluciones “de compromiso” que no satisfacen por completo a nadie y carecen del coraje y la audacia necesarios para escapar del pozo gravitacional.

5. Quitar de en medio a los que obstaculizan el cambio, mandarlos un mes a la playa, o lo que sea…

6. Definir la batería de tests de aceptación de los cambios.

7. Especificar las dependencias entre los módulos y cómo se verá afectada cada parte con el cambio. Si esto no es posible, mejor pensar en abandonar el producto existente y volverlo a hacer.

8. Diseñar el plan de migración. Nunca sacar una versión que sea incompatiblle con la anterior. Por muchos problemas que resuelva, si es incompatible hacia atrás, se obligará al departamento comercial a vender el producto de nuevo abriendo una puerta de par en par a la competencia.

9. Quemar las naves. No hay vuelta atrás, o el producto se rediseña o muere, pero no se seguirá manteniendo la versión anterior pues ello implicaría igualmente la muerte.

10. Acordar el roadmap de desarrollo. No introducir nuevas funcionalidades a la espera de las cuales se encuentren los clientes. Se pueden introducir nuevas funcionalidades pero nunca condicionadas a un plazo de entrega distinto del de las necesidades intrínsecas de la re-ingeniería.

11. Inducir stress creativo. En ausencia de un plazo de entrega los programadores se relajan y empiezan a producir código muy bonito pero difícilmente rentable. Aunque no se esté a merced de las exigencias del cliente, el equipo aún tiene que sentir la presión para entregar algo que funcione bien en un período razonable de tiempo.

12. Vigilar de cerca las estadísticas de bugs y benchmarks.

13. Formar a todos los incumbentes en la nueva arquitectura. Ganarse a los campeones en cada departamento. Mentalizar a la gente de que cualquier proceso de cambio es inexorablemente traumático en alguna medida. Repartir relajantes musculares, evitar que cunda el pánico.

14. Hacer un piloto de actualización.

15. Actualizar al resto de clientes. Celebrarlo. Irse a casa.

Posts relacionados:
Windows Vista y el Efecto del Segundo Sistema.
Cómo diseñar una aplicación escalable.

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

Consejos para elegir un candidato o un puesto de trabajo

Shackleton Job AdDe un tiempo a esta parte me llegan ecos de que la matriz española de Habber Tec (empresa con la que estoy vinculado desde hace un año) está contratando desarrolladores. Esto me llena de alegría pues veo como un verdadero brote verde que se reactive la contratación en las empresas españolas. Esta tarde comentaba con un miembro del staff de Habber Tec las dificultades para encontrar candidatos idóneos para los puestos que requiren más competencias técnicas. La conversación me ha ayudado a rememorar mi experiencia como reclutador y como candidato, parte de la cual comparto a continuación.

1. No reclutes para cubrir un puesto de trabajo sino para crear una cultura.
Prácticamente todo el mundo contrata sólo cuando le aprieta el zapato ¿Quién iba a estar en otro caso tan chiflado como para pagar lo que cuesta la extorsión de un programador? Se crea una definición del puesto que contiene un listado interminable de requisitos técnicos y NADA acerca de la forma de pensar del candidato. Esto es un craso error. Hay estudios que indican que sólo al 11% de los candidatos fallidos hay que despedirlos por falta de competencias técnicas. El otro 89% es despedido o pide una baja voluntaria por desalineación con la cultura o los planes de carrera de la empresa.

Si eres el candidato, no aceptes una oferta de una empresa cuya cultura te parezca apestosa.

2. Contrata por actitud más que por aptitud.
¿Que actitud? Bueno, no contrates a alguien si:
• No sabes lo que le motiva.
• No siente curiosidad.
• No sabe reirse de sí mismo.
• No tiene intereses diversos.
• No harías un largo viaje con el.
• No le querrías a tu lado en una trinchera.
• Se presenta luciendo títulos.
• No han tenido nunca un trabajo de mierda.
Respecto de los dos últimos puntos, está muy bien que una persona se crea más inteligente que el resto, siempre y cuando pueda demostrarlo con algo más que con un papel. Y el cerebro humano sólo puede apreciar las cosas por comparación. Si contratas a un jóven licenciado quien sólo ha tenido trabajos relajados, bien organizados y bien pagados entonces cualquier grado de stress le parecerá excesivo, cualquier grado de organización le parecerá caótico y cualquier retribución le parecerá insuficiente.
En una entrevista, pregunta primero por los valores : pasión, tolerancia, solidaridad, motivación, autoconciencia.

Si eres el candidato, manda directamente a la porra a los que te frían a preguntas técnicas a priori. A esos no les interesa quién eres como persona. Tú podrías ser un pederasta y les daría igual. No trabajes con esa gente.

3. La cultura se come a la estrategia.
Esta frase es de Peter Drucker y alerta sobre el peligro que supone crear una cultura tan fuerte que llegue un momento en que la alta dirección no puede hacer nada contra la cultura.

Si eres el candidato, no te vuelvas “talibán”. En el momento en que abrazas totalmente la cultura de la empresa dejas de pensar independientemente y te conviertes en un fanático.

4. La diversidad no se mide en ratios de blancos vs. negros, hombres vs. mujeres o junior vs. senior.
No aporta ningún valor añadido tener una empresa multirracial, con paridad de género y buena mezcla de ímpetu juvenil con prudencia madura si todos ellos piensan igual. El desafío consiste en integrar la pluraridad dentro de la cultura, no en conseguir que todos piensen igual. Si todos piensan igual entonces el coeficiente de inteligencia total de la empresa es el mismo que el de su presidente.

Si eres el candidato, exige que la empresa respete (aunque no comparta) tu punto de vista. Si tienes una opinión vehemente en la cual discrepas con tus jefes, probablemente tú tienes razón y ellos están equivocados.

5. Crea puestos a medida de la gente excepcional.
Cuando te encuentres a una persona realmente sobresaliente, no intentes encajarla en ningún puesto prefabricado. Porque no va a encajar. Las personas que se salen de la escala casi nunca siguen las normas. Por consiguiente, en lugar de intentar imponérselas, lo mejor es establecer normas de seguridad para evitar que detonen una bomba nuclear mientras experimentan con el Uranio y por lo demás dejarles que hagan lo que quieran. No sólo hay que proteger los resultados sino también a las personas pues los genios trabajan de forma tan tozuda y obsesiva que en ocasiones causan un nivel de stress a su alrededor que la gente normal no puede soportar.

Si eres el candidato, explícale a tu jefe por qué necesitas un tratamiento aparte. Si es cierto que eres un genio probablemente también es cierto que estás pirado y necesitas ayuda. Por tanto en lugar de batallar contra todo y contra todos mejor pídele a los demás que te ayuden a sobrevivir a tu propia genialidad.

6. Pregúntate por qué se unió el empleado número 20 a tu empresa.
Si la respuesta que tienes en mente es: a) por la esperanza de opciones sobre acciones, b) por trabajar con gente más lista o c) por aceptar un desafío que nadie más puede superar. Entonces estás en un error. Pregúntale al candidato si eligiría el empleo en el caso de que sólo le quedase un año de vida.

Si eres el empleado número 20, mejor no te dejes impresionar por un golpe de suerte o una abultada ronda de inversión. No te endeudes para comprar acciones, pues probablemente estas nunca te pagarán la hipoteca. Y no andes comiendo yuca a diario en la esperanza de que dentro de tres años llegará el vesting pues a lo mejor sólo te queda un año de vida.

7. Los profesionales no responden a ofertas de empleo sino sólo a avances de carrera.
Querrás explicarle al candidato cómo va a avanzar en su carrera profesional. Por tanto, mejor si buscas candidatos que estén en teoría ligeramente por debajo del nivel que buscas y les ayudas a crecer.

8. Si te has equivocado con el candidato entonces despídele lo antes posible.
Pocas veces las segundas oportunidades con los candidatos dan algún fruto. Si no consigues hacerle encajar lo mejor es que llegueis a un acuerdo pacífico y honorable para que se marche lo antes posible.

Si eres el candidato y te sientes desalineado con tu jefe entonces bien vete bien trata de que le despidan. Por honor y salud mental, yo te recomiendo que te vayas, aunque en algunas ocasiones realmente es posible moverle la silla al de arriba. Con el jefe sólo se puede estar totalmente a favor o totalmente en contra. Si estás en algún lugar intermedio nunca llegarás a ninguna parte pues si le ascienden tú no ascenderás con él y si le despiden nadie te percibirá como un buen substituto.

Posts relacionados:
El perfil del empleado perfecto.
Porqué el talento no importa en las empresas.
Cómo hacer entrevistas de selección.

Artículo relacionado:
Esto es lo que Google ha averiguado sobre por qué hay equipos de trabajo que fracasan y otros que funcionan (Alex C)

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Organizando la Comunidad. Modelos de Desarrollo, Tecnología y Empleo | Deja un comentario

Metodologías basadas en la gestión de expectativas

Estos últimos días he estado rememorando todos los proyectos en los que he participado, que desde el 95 a esta parte son unos cuantos. Recopilando esa experiencia voy llegando a la conclusión de que casi todas las metodologías comunmente empleadas se equivocan en el objetivo fundamental. A renglón seguido voy a proponer mi conjetura sobre el error de base, que se aplica no sólo a los proyectos informáticos sino también a cualquier proyecto vital.

Veamos, históricamente teníamos waterfall. Waterfall, en resumen, viene a decir que el cliente te da una serie de requisitos, digamos: el logro profesional, la casa, el coche, los niños, las vacaciones en la Costa del Sol, etc. Y tú diseñas como implementarlo: el empleo, la hipoteca, el leasing, la clínica de fertilización in vitro, la multipropiedad costera… El problema de waterfall es que resultaba muy difícil cambiar la salida del sistema una vez que se habían introducido las entradas, ya que no te puedes cambiar fácilmente de empleo, ni puedes divorciarte del banco, y a los hijos bien les quieres a morir bien preferirías haber tenido un perro según te hayas levantado de la cama ese día con el pie izquierdo o con el derecho.

Entonces alguien propuso Agile, que grosso modo es una herencia de metodologías japonesas para incrementar la productividad. El manifiesto agilista afirmó que lo importante ya no era saber exactamente desde el principio qué es lo que se quería hacer, sino maximizar la productividad y facilitar la incorporación de cambios de la mejor forma posible. Creo que fué entonces cuando aparecieron los yuppies 100% enfocados en ganar más dinero por día del que pueden razonablemente gastar.

Incrementar la productividad sin incorporar controles contínuos de calidad era suicida y es por eso que todos los equipos ágiles hacen también Test Driven Development (en la vida real el TDD es como acostarse con una persona antes de casarse con ella).

Hasta aquí teóricamente muy bien. Tenemos una idea aproximada de lo que queremos, tenemos una buena metodología de gestión de cambios y somos productivos. Excepto que por el camino se nos ha perdido el factor humano, concretamente, se nos ha olvidado cuánto miedo y cuánta frustración experimentan las personas durante el proceso de alcanzar los objetivos.

Y aquí vienen mis diez postulados sobre la gestión de proyectos basada en expectativas:

1. El cliente no sabe lo que quiere. Sabe cuales son sus objetivos de negocio. Pero no sabe cómo traducir estos objetivos en una lista de tareas técnicas. El gerente de cuenta tampoco lo sabe (porque tampoco es técnico). El único que sabe exactamente lo que hay que hacer es el programador. Pero al programador se le ocultan normalmente los objetivos de negocio. Por consiguiente, el programador va a ciegas respecto de los objetivos reales del proyecto.

2. El éxito se mide sólo en función de las expectativas. La productividad no importa. Con las herramientas modernas la productividad es tan grande que normalmente sobrepasa cualquier requisito de la demanda. El éxito de un proyecto no es lo que se alcanzó en términos absolutos, sino la diferencia entre lo que el cliente esperaba obtener y lo que obtuvo realmente. He aquí el gran malentendido de los story point. En Agile, el story point es una métrica abstracta del valor que obtiene el cliente. Se supone que cuantos más story points por sprint obtenga el cliente más satisfecho estará. Pero esto, en general, es falso. Lo que el cliente quiere realmente (aunque a veces pida otra cosa) es saber a priori cuántos story points obtendrá de forma segura por unidad de tiempo en el futuro próximo. En la vida cotidiana así es como mucha gente termina con el superpuesto directivo, la mansión, los niños, el perro, el smartphone, el superdeportivo y profundamente amargada y decepcionada.

3. La mayoría de la gente no aguanta trabajar bajo presión. La predictibilidad y la tranquilidad son mucho más importantes que la productividad. Esto es debido a que la mayoría de la gente es incapaz de gestionar la incertidumbre, pues la duda sobre lo que va a suceder les causa una ansiedad insoportable incluso cuando el resultado más probable de la incertidumbre sea un éxito rotundo. Es decir, la sensación de “éxito” en un proyecto no se percibe tanto por la velocidad a la que avanza sino por la cantidad de incertidumbre que reduce.

4. Los detalles sobre lo que está sucediendo no son para corazones sensibles. La mayoría de las personas se desmayan o entran en pánico cuando ven sangre. Es por esto, en parte, que al paciente lo sedan y a los médicos no les gusta tener público observando cómo trabajan, pues cuanta más gente haya mirando cómo está el pulso del paciente mayor es la probabilidad de que cunda el pánico si tiene un latido más rápido o lento que otro. El veto informativo no sólo se aplica al cliente o a los familiares del paciente, sino también a los propios gestores de cuenta. Por dicha razón, el Doctor House va por libre y no le comenta a nadie lo que está haciendo. Aunque si no se tratase de una ficción televisiva en la vida real a House lo habrían despedido tres veces en cada temporada por saltarse los protocolos.

5. Los planes son papel mojado, pero la planificación es imprescindible. Es imposible especificar a priori de forma completa y rigurosa todo lo que se requiere en un proyecto. Pero, por otra parte, si no se hace tal esfuerzo, a posteriori en el mismo instante en que algo salga mal (y siempre hay algo que sale mal) los incumbentes empezarán a culparse unos a otros sobre quién no se había enterado de qué. El desarrollo iterativo basado en adaptarse a las necesidades cambiantes del cliente es un plan suicida debido a que termina inexorablemente en una discusión acalorada sobre quién cambió qué y cuándo, en la cual el proveedor (aunque sea inocente) lleva siempre las de perder.

6. La metodología debe cambiar con la fase del proyecto. No era posible descubrir América calculando exactamente dónde estaba, ni agua para cuántos días se requeriría en el camino. Por otra parte, no es posible mantener un asentamiento colonial viable sin saber cuánta agua se necesita a diario. Es decir, con una metodología de colono nunca descubrirás América y con una metodología de descubridor nunca sobrevirás en América.

7. Obsesionarse con hacerlo todo bien conduce a resultados indeseados. El objetivo de un proyecto es lograr un resultado excelente y para ello hay que hacerlo todo siempre lo mejor posible. Nunca hay que despreciar las buenas prácticas pues se crearon por muy buenas razones, pero no se debe confundir el fin con los medios. Algunas personas se obsesionan tanto con las metodologías y los protocolos que estos acaban siendo un fin en si mismos. Y el día en que la metodología empieza a gobernar tu vida es que has perdido el norte, lo mismo seas un fanático del gantt o del sprint board o un fanático religioso. Las personas se aferran a rajatabla las metodologías y a los rituales porque les proporcionan una falsa sensación de seguridad.

8. Sólo un profesional puede juzgar el desempeño de otro profesional. Todos los programadores que he conocido son geniales. Y todos los médicos que he conocido son los mejores en su especialidad. Pero yo carezco de criterio para determinar si mi médico de cabecera es un milagrero o un matasanos.

9. Nunca hay que hacer caso de lo que dice la persona presuntamente a cargo. Esto es debido a que por el Principio de Peter las personas ascienden en la jerarquía hasta que no son capaces ni de formular sus propios objetivos. Hay que tener en cuenta que la explicación que da el responsable de algo consiste en un conjunto de justificaciones para demostrar porqué no es su responsabilidad. Los mayores desastres son siempre causados por los “mejores” gestores debido a la confianza ciega que la gente deposita en ellos.

10. Cualquier metodología que ignore el factor humano está condenada al fracaso. No se puede poner en práctica un proceso sin tener en cuenta cómo se sentirán las personas implicadas en ese proceso. Esto los militares lo saben muy bien y es por eso que se pone a los soldados a cantar en grupo, además de muchísimos otros rituales castrenses. Como por alguna absurda razón nos parece ridículo que los programadores se junten para cantar, lo que hemos hecho es tratar de eliminar el factor humano de la metodología, automatizarlo todo con sistemas de integración contínua y reducir al empleado a un robot que produce story points bajo una estricta supervisión. Lo cual sería una idea fantástica de no ser porque el empleado no es un robot dotado de inteligencia.

Como conclusión, todo tiene que ver con el difícil equilibrio entre nuestras grandes esperanzas y la conciencia sobre lo que podemos alcanzar realmente. Si no fracasas y te equivocas lo bastante entonces es que tus objetivos no eran lo suficientemente ambiciosos. Por otra parte, los humanos reaccionan de forma muy desagradable ante el fracaso, e incluso sólo ante la idea imaginaría de fracasar. La solución a este dilema es ser capaz de encapsular los riesgos en una caja de seguridad, de modo que si todo explota los daños estén controlados. Es como correr Fórmula 1. No se trata de ir despacito por la pista para no salirte de ella. Sino de correr a la mayor velocidad posible en la confianza de que si te sales del trazado y das tres vueltas de campana destrozarás el bólido pero tú aún conseguirás salir de él en una sola pieza.

Post relacionado: Las zonas grises de Agile.

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