¿Son los campeones realmente resilientes?

Una de las cosas que me intriga sobre la (auto)biografía de los campeones es que parece que ninguno de ellos hubiese tenido jamás ni el más mínimo atisbo de duda. Como si se hubieran levantado todos y cada uno de los días de su vida, con sol, viento, lluvia o nieve, para salir a correr en pos de su objetivo. Incluso en la biografía de Nelson Mandela –quien estuvo 27 años en prisión muchos de ellos en condiciones durísimas– da la impresión de que se comportase con la certeza de que un día saldría para tomarse la revancha.

Puede que esta combinación de infalibilidad más determinación sea la cualidad de los genios. Sin embargo, las personas que yo conozco personalmente no son así. Casi todas dan dos pasos hacia delante y uno hacia atrás. Se cansan, se deprimen (algunos psicólogos afirman que la depresión es un mecanismo defensivo para dejar de hacer cosas que no conducen a ninguna parte). Incluso a los emprendedores más exitosos y curtidos que me he encontrado me confesaron que les costaba llegar a su propio nivel. Tenían una vida más similar a la de esos artistas que lo mismo un año ganan un Oscar que al siguiente están en tratamiento de desintoxicación alcohólica. Voy a intentar enumerar lo que he podido aprender de algunos campeones, y cómo sobreviven a las tempestades con algo más que únicamente su propia determinación.

Sobreasignación

Uno de mis consejos favoritos y que más me divierte repetir es la Regla Nº1 del Gasto Militar: Nunca compres un tanque si puedes comprar dos por el doble de precio. Esto se puede aplicar a casi todo en la vida, si te lo puedes permitir, claro. Tener exceso de stock puede salvar a la empresa de una crisis en los proveedores o servir para aprovechar la oportunidad de un pico inesperado de demanda. También puede ser una forma de perder muchísimo dinero en obsolescencias.

Además de su coste, el inconveniente de la sobreasignación es que resulta difícil determinar el umbral de seguridad. La gente tiende a pensar que si el requerimiento normal es X entonces una sobreasignación prudente será 2X o 3X. Pero las sobreasignaciones eficaces con frecuencia son 10X o más. Los analistas de riesgo tienden a crear el “peor escenario” en función de la peor crisis conocida en el pasado. La falacia de esta hipótesis del “peor escenario” es que cada crisis pasada fue peor que la peor de las anteriores. Debido a esta creencia errónea de que el futuro nunca será peor que el pasado es por lo que revientan centrales nucleares como Chernobil y Fukushima.

La sobreasignación ya fue descrita por Tsung Tzu en su clásico Arte de la Guerra en lo que él denominaba “lento, lento, rápido, rápido”. Prepararse a conciencia durante el tiempo que haga falta y luego atacar con la velocidad de un relámpago en el momento oportuno.

Anticoraje

El sistema de start ups funciona creando un gran número de ellas de las cuales tanto como el 80% o el 90% muere antes de alcanzar los cinco años de vida. Los inversores lo saben, y les da igual porque ellos juegan apostando sobre el resultado estadístico promedio y no sobre una única empresa. Pero para el emprendedor la media es irrelevante. Existe el mito de que los emprendedores son personas que asumen riesgos. Esto es una idea equivocada del emprendizaje. Los que asumen riesgos innecesarios sólo son estúpidos e imprudentes. Los mejores emprendedores trabajan eliminando riesgos. Empiezan con una situación de gran incertidumbre y trabajan sistemáticamente para reducirla.

Si uno lee los consejos de billonarios con Warren Buffet es fácil encontrar entre los primeros consejos que antes de pensar en cómo ganar dinero hay que pensar en cómo no perderlo. La táctica habitual de los inversores es colocar el 80% de su capital en activos de muy bajo riesgo y el otro 20% en activos de muy alto riesgo. De esta forma si pierden nunca pierden más del 80% pero si ganan entonces obtienen grandes beneficios. La pega es que si todo el mundo hace lo mismo, los activos de bajo riesgo dejan de ser tales por la cantidad brutal de deuda a quienes los emite, y los juegos de azar con nuevos proyectos adquiren una probabilidad ínfima de ganancia. De hecho, la estrategia exitosa de Warren Buffet no fue esta del 80%-20% sino apostar fuerte y a medio-largo plazo por activos conyunturalmente devaluados.

Blindaje

El blindaje está relacionado con la sobreasignación y con el anticoraje, pero se extiende más allá de los recursos económicos o la evaluación de riesgos. Consiste en una protección a priori contra algo de lo que, en principio, no parece necesario protegerse. El blindaje sólo es eficaz si se instaló antes de que se produjese la catástrofe y la parte contraria desconoce su existencia pues en otro caso pensará en la forma de perforarlo.

La protección que más a menudo olvidan los emprendedores es aquella contra sus propios socios. Este blindaje es complicado porque requiere generar una situación de confianza que en realidad no existe. Sin confianza entre los socios no se puede llevar adelante un negocio, pero con confianza ciega tampoco por el hecho de la antireputación que comentaré más adelante.

Pocas si acaso alguna start up se constituye con un plan de contingencia para el caso en que la empresa quiebre. Lo cual es estúpido y temerario si se tiene en cuenta que estadísticamente el resultado más probable de una start up es el cierre por insolvencia.

Compartimentalización

La compartimentalización es una forma de blindaje. Consiste separar partes del sistema de modo que una catastrofe en una no destruya las demás. Esto casi nunca es sencillo de conseguir y las ideas modernas sobre la conciliación no ayudan en nada. Es complicadísimo competir por una medalla olímpica sin poner en serio riesgo la salud, pretender ser elegido presidente sin que sufra la vida familiar, obtener un préstamo sin tener que avalarlo personalmente o subir al Everest sin riesgo de morir por cansancio e hipotermia. La compartimentalización es uno de los desafíos más difíciles del campeón. Al actor Will Smith se lo escuché una vez enunciado como: “Si eres de esas personas que luchan por el 99% eso está bien, quédate en casa y sé feliz”. Muchos emprendedores no compartimentalizan, sólo queman sus naves como Hernán Cortés en el deseo de triunfar o morir en el intento. Esta falta de prudencia no es muestra de ninguna sabiduría especial. Los que sobreviven lo hacen sólo por pura suerte lo mismo que no todos los que en una batalla corren colina arriba en dirección a las ametralladoras mueren a causa de la balacera, sino que en cantidades numerables con los dedos de una mano vuelven para recibir una medalla y quizá un monumento a su insensatez en la plaza de su pueblo.

Antirreputación

Si te preocupa lo que la gente piense de ti es mejor que no te metas a político ni a emprendedor. Algunas profesiones como médico, juez o militar no admiten pérdidas de reputación. Por eso ni médicos ni jueces ni militares van por libre sino que están estrictamente regulados. Pero no es el caso de los emprendedores. Obama trató recientemente de descalificar a Donald Trump argumentando que conocía muchos empresarios tan exitosos como él, pero que no habían dejado a su paso un reguero de despidos, impagos y gente cabreada. Pues bien, es imposible ser emprendedor de éxito sin cabrear a alguien. Por dos motivos: 1º) un porcentaje significativo de las victorias se obtienen tras una acción audaz (y a veces no muy limpia) contra el adversario, y 2ª) una buena forma de construir un sistema resistente es con piezas débiles pero redundantes y reemplazables. Esto se aplica lo mismo a un centro de datos que opera sobre discos baratos que a una empresa que opera sobre mano de obra barata, excepto que las personas tienen derechos y sensibilidades bien diferentes a los de los discos. Hasta la fecha no ha funcionado en la práctica ningún sistema social basado en que nadie pueda fallar y quedarse por el camino. Existe una creciente preocupación por la solidaridad y la cohesión social pero a la postre cualquiera es prescindible.

Por otra parte, para tener éxito en muchas ocasiones el número de detractores no cuenta. Importa mucho más tener un pequeño grupo de seguidores fanáticos (Jesucristo tenía al principio sólo 12). Si los fanáticos son lo bastante activos e influyentes persuadirán a la masa indiferente y los destrozos denunciados por los detractores se verán eclipsados a los ojos de la mayoría.

Hasta las mejores causas tienen grupos opositores como el de los Trabajadores Inocentes que Murieron en el Ataque a la Estrella de la Muerte. Y diré más, en los negocios cuanto mayor es la reputación de una persona menos hay que fiarse de ella, pues sobre las personas de reputación incuestionable se relajan los controles que serían necesarios hasta tal punto que cuando la sociedad se da cuenta del desastre que han causado ya es demasiado tarde para arreglarlo.

Adrenaholismo

En psicología se sabe que una persona puede volverse adicta a casi cualquier cosa. Muchos emprendedores son adictos a la adrenalina y al cortisol hasta el punto de que no saben qué hacer con sus vidas cuando están relajados. Oficialmente sueñan con retirarse y descansar pero en la práctica no dejan de meterse en un lio detrás de otro. Personalmente creo que algunas personas tienen una resistencia natural extraordinaria a determinadas substancias. Puede que soporten la adrenalina o los esteroides de una forma que les permite obtener una ventaja competitiva sobre quienes simplemente no pueden tolerar dosis elevadas de dichos estimulantes en su sangre.

No hay que confundir la adicción a la adrenalina con la addición a trabajo. Muchas personas adictas al trabajo lo son precisamente por la causa contraria: a duras penas soportan su vida fuera del entorno laboral. Estas personas adictas al trabajo pueden ser buenos trabajadores y profesionales de éxito pero rara vez triunfan como emprendedores.

Sobrecompensación

El ejemplo más fácil sobrecompensación es el fisioculturismo. Los profesionales no entrenan 8 o 10 horas al día. Esto agotaría al organismo. Lo que hacen es entrenar con una intensidad brutal durante cortos periodos de tiempo y luego le dan al cuerpo gran cantidad de tiempo y comida para recuperarse. El truco consiste en evitar la exposición prolongada al desgaste de manera que sea posible acumular energía para vencer de forma rápida y demoledora a los que están más cansados, cuando se presente la ocasión.

Simetría de pérdidas y ganancias

Es indeseable para el individuo una situación en la que tiene potencialmente mucho que perder pero poco que ganar. Paradójicamente este puede ser el caso de los muy ricos, los cuales a duras penas pueden enriquecerse más, pero podrían arruinarse en cualquier momento y esa idea imaginaria que les causa un stress insoportable. Fue por esto que Séneca –uno de mis filósofos favoritos– abogó por el estoicismo a pesar de ser él mismo una de las personas más ricas e influyentes del Imperio Romano de su tiempo. La solución es deshacerse de aquello que le hace a uno dependiente lo cual puede ser la propia riqueza de la que se ha caído prisionero. Es por esto que muchos multimillonarios se han desecho de buena parte de su fortuna después de obtenerla, aunque sinceramente todavía estoy esperando encontrar alguno que haya regalado el Ferrari.

Una de las características de la juventud es que en un momento dado de ella uno sufre una epifanía y cree saber hacia dónde se dirige. En realidad el iluminado no tiene ni puñetera idea pero da igual porque los que le siguen tampoco. Cristobal Colón creía que iba a llegar a la India. E igual que Colón casi todo el mundo llega a alguna parte pero casi nadie a donde pensaba que iba a llegar. Se dispara entonces un proceso de revisión crítica en el cual uno se percata de dos hechos irrefutables: 1º) cualquier conocimiento que se crea tener es sólo una burda aproximación a la realidad y 2º) el resto de los presunto expertos tampoco tienen ni putidea de lo que se traen entre manos. Con frecuencia esto se produce tras un merecido batacazo en el cual el galardonado director de cine, por poner un ejemplo, obtiene financiación para hacer la que será su obra cumbre pero con la que en los cines no consigue tras el estreno ni recuperar los costes de producción. Entonces, y sólo entonces, es cuando empieza a cuestionarse si realmente sabe algo acerca de lo que le interesa a la audiencia. La pérdida de fé consecuencia del aumento del conocimiento es extraordinariamente nociva para el emprendizaje, ya que, como hemos enunciado anteriormente, el funcionamiento del sistema depende de la inconsciencia del peligro entre los individuos jóvenes y aguerridos.

Conclusiones

Mi opinión personal es que la capacidad para mantener una trayectoria exitosa está más relacionada con la habilidad para alejarse de lo nocivo y acumular fuerzas que con la capacidad de esforzarse y superar adversidades. Se trata de conservar en todo momento la iniciativa bélica. De luchar siempre por conquistar algo y nunca por preservar algo conquistado. Incluso si se acaba en prisión, como Mandela, usar esta circunstancia como arma arrojadiza contra el enemigo, acusándole de tirano y abusón, aunque la pena de cárcel haya sido por cargos de terrorismo y conspiración para derrocar al Estado.

Creo que algunos campeones empezaron con buen pie y luego tuvieron suerte. Lo bueno de los éxitos empresariales es que sólo necesitas un grán éxito para poder vivir de sus réditos el resto de tus días. Luego puedes fallar todas las veces que quieras.

De lo que no conozco tantos casos es de personas que lo volviesen a intentar tras fallar miserablemente en su primer intento. Existen excepciones, por supuesto, hay notables hunde-empresas en serie. Personas que quebraron una empresa (normalemente con el dinero de un tercero) y luego otra, y otra, y otra… por aquello de que de los fracasos se aprende, entonces la próxima será la vencida, y así sería de no ser porque son personas que no aprenden sino que simplemente superan el fracaso con indolencia debido a una percepción distorsionada de la realidad que les permite atribuir la culpa siempre a algo o alguien diferente de sí mismos.

Mi argumento es que la victoria es una espiral hacia arriba y la derrota es una espiral hacia abajo y lo único que importa es la tendencia al alza o a la baja.

La resistencia sí que importa pero no tanto porque los individuos se fortalezcan por sobrecompensación con lo que no les mata sino porque los más débiles se quedan por el camino y al final sólo llega uno que es quien fué más hábil en administrar sus energías sin derrocharlas en empresas estériles.

Posts relacionados:

Combatiendo a tus dragones.
Pírricas Victorias Empresariales.
Saṃsāra corporativo y stress del emprendedor.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Emprendizaje | Deja un comentario

Los adolescentes en las redes sociales

Adolescentes en redes socialesExisten no pocos padres preocupados por las relaciones de sus hijos a través de las redes sociales. Frente a mi casa hay un bonito parque con varios rincones secretos encantadores. Bueno, secretos excepto cuando miras desde mi ventana en un tercer piso. Entonces puedes ver a los adolescentes allí haciendo todas las cosas que sus padres no quieren que hagan. Existen adolescentes que no soportan relacionarse en persona con el mundo. Pero la mayoría de los adolescentes prefieren verse en persona, como los de mi parque. Si están a las once de la noche enganchados al móvil es sólo porque sus padres les obligaron a volver a casa a las diez. Las motivaciones humanas no cambian con la introducción de nuevas tecnologías, sólo encuentran nuevas formas de satisfacerse.

Uso de redes sociales en adolescentesSegun los estudios, algo así como el 72% de los adolescentes tienen cuenta en Facebook. Entre un 40% y un 50% usan Snapchat. Las cifras para Twiter varían mucho según la fuente, entre un 8% y un 33%. Y la cifra de 33% para Google+ no me la creo, excepto porque como efecto secundario de abrir una cuenta en GMail Google puede abrirte un perfil en Google+.

Nativos (e inexpertos) digitales

No hay que caer en el error de presuponer que porque un jóven haya nacido con un smartphone debajo del brazo automáticamente sabrá cómo hacer un uso mejor de él que un adulto. Debido a la vertiginosa velocidad del progreso, las nuevas tecnologías siempre preceden a las buenas prácticas de uso de las mismas. Un adolescente con un móvil sigue siendo igual de ingénuo y vulnerable que si móvil y puede perfectamente cometer el error de hacer un uso pésimo de la tecnología a su alcance.

Contexto y audiencia

Una de los primeros desafíos a los que se enfrentan los adolescentes en las redes sociales es la falta de visibilidad sobre la audiencia a la que se están dirigiendo. Si están en el parque pueden fácilmente cambiar de conversación –o apagar la yerba– cuando ven de lejos acercarse a un adulto. Pero en las redes sociales nunca pueden estar seguros de quién les estará leyendo, y los adolescentes casi siempre se traen algo entre manos de lo que no quieren que los adultos se enteren. Este es uno de los motivos –hay más– por el cual los críticos de Facebook dicen que está perdiendo tracción entre los adolescentes y por el cual Facebook trató de comprar Snapchat por 3.000 millones de dólares en noviembre de 2013 para captar a los millennials.

El problema de la audiencia no afecta sólo a los adolescentes, por supuesto. A los adultos también les afecta. A pesar de que Mark Zuckerberg declarase que Facebook quiere ayudar a sus usuarios a quitarse la máscara, la realidad es que la red social decide por su cuenta qué contenidos mostrar a cada usuario y censura lo que le aparece oportuno; incluyendo, por ejemplo, unos pechos femeninos, es decir, si te va el top-less playero y compartir fotos con tus amigos naturistas o hacerte fotos con una copa de vino en la mano, entonces Facebook no es para ti.

El desdoblamiento de personalidad digital es un problema no resuelto en las redes sociales. Existe, en mi opinión, una obsesión excesiva en las redes sociales por desvelar la identidad real del usuario. Esto es hasta cierto punto comprensible por razones de seguridad. Es razonable que debido a que la red social y el usuario firman un contrato de uso, ese contrato sólo puede ser válido si es posible identificar a ambas partes. Lo que no se sigue de forma inmediata es por qué la red debería informar al resto de los usuarios sobre la identidad real de cada uno. No es necesariamente malo que las personas usen avatares. Tampoco implica que tengas una personalidad múltiple. Una persona puede tener cuenta en Facebook y en LinkedIn y en Twitter y en Instagram y mostrará en cada una aspectos diferentes de si misma. También podría tener más cuentas en redes donde pueda expresar su fervor religioso o su orientación sexual sin ofender a ningún idiota. Algunas personas necesitan escapar temporalmente de la realidad porque dicha realidad es verdaderamente asfixiante. En estos casos los avatares pueden tener un uso terapéutico permitiendo a la persona acercarse libremente a lo que quiere ser.

Gamers y espacios propios

Merecen una mención aparte las interacciones sociales que se producen entre los jugadores de videojuegos (gamers) especialmente los MMOG (Massively Multiplayer Online Game). Cuando la gente habla de redes sociales piensa en Facebook o en Twitter, pero en los MMOGs también se produce una intensa interacción social. No todos los jugadores de videojuegos son en absoluto el arquetipo de muchacho gordito y tímido, hay hombres y mujeres de todas las edades y tipos. Tampoco es cierto que siempre diseñen avatares diferentes de ellos mismos. En ocasiones el avatar no tiene nada que ver con el usuario pero algunos jugadores diseñan avatares que son lo más parecidos a como son ellos mismos en la realidad. Una característica diferencial de los MMOGs es la forma en la que permiten crear un espacio propio. En Facebook los usuarios están avocados a interactuar con personas que conoces de acuerdo a las normas de su comunidad. En Twitter pueden buscar grupos de interés no locales e interactuar por afinidad cultural en lugar de por proximidad. Pero en un MMOG las posibilidades de alterar el entorno y crear una dinámica grupal propia son prácticamente ilimitadas. Las interacciones entre los jugadores pueden llegar a ser muy complejas requiriendo colaboración múltiples para pelear o alcanzar determinados objetivos. Los MMOG tampién pueden propiciar la convocatoria de encuentros presenciales. Según un estudio de Nicholas Yee el 15% de los varones y el 5% de las féminas quedan en alguna ocasión para conocerse en persona lo cual a mi me parece un porcentaje elevado teniendo en cuenta que no existe limitación geográfica, en principio, para la residencia del jugador.

Intimidad

La disponibilidad de nuevas tecnologías desde edad muy temprana ha causado que para los adolescentes sea natural hablar de temas íntimos a través del chat. Los adultos piensan que los temas delicados hay que tratarlos siempre en persona –si son muy delicados de hecho no sólo en persona sino en una sauna todos en pelota picada para que nadie lleve micros–. Pero los adolescentes perciben que el smartphone es un medio más para comunicarse como otro cualquiera, y de ahí el éxito de las conversaciones de Snapchat que se autodestruyen tras ser leídas.

Uso pervasivo del móvil

Una diferencia entre adultos y adolescentes es que esto últimos han crecido con el móvil. Para ellos atenderlo es algo tan natural escuchar la radio mientras cocinas, es decir, con frecuencia no le están realmente prestando demasiada atención. Esto contrasta con el uso típico que le dan los adultos quienes bien están absortos con el celular bien lo tienen boca abajo en la mesa con el timbre en modo silencio. Para los adolescentes es normal ver un partido mientras chatean.

Necesidad de aceptación social

El objetivo social de los adolescentes casi siempre es parecer “molones” en el entorno adecuado. Era así en los bailes de fin de curso de antaño donde para las chicas era cuestión de vida o muerte llevar el vestido adecuado. Y sigue siendo exactamente lo mismo en las redes sociales. Todo va de “molar”, ser cool, tener flow.

Esta necesidad de aceptación se manifiesta en dos interacciones fundamentales en las redes sociales: quien hace clic en 👍 Me Gusta y quien escribe comentarios. Entre los adolescentes la competición por ver quién obtiene más Likes y, por consiguiente, es más molón, puede acarrear una presión insoportable para los menos populares, especialmente entre las chicas. Respecto de los comentarios, en general, a ningún usuario le gusta descubrir que le ha leído alguien que no esperaba y, además, ha puesto un comentario que va en contra de su opinión o resulta vergonzante. Pero si además la redactora del comentario es la hermana mayor o la madre eso puede suponer para el adolescente la muerte por vergüenza y cabreo por falta de netiqueta. En general, lo que a nadie le gusta en las redes sociales es perder el control de una conversación que ha iniciado, lo cual es fácil si existe un grupo organizado de bullies.

Privacidad

La privacidad de los adolescetes require de un compromiso prácticamente inalcanzable. Por una parte todos, absolutamente todos los adolescentes quieren privacidad. Aunque no estén haciendo nada malo, a ninguno le gusta que los adultos metan las narices en sus asuntos. Por otra parte los tutores tienen no sólo el derecho sino también la obligación de estar al corriente de lo que están haciendo los menores de edad en tanto en cuanto son responsables legalmente de ellos.

Otro asunto peliagudo es el relacionado con publicar fotografías de menores sin su consentimiento. Personalmente opino que lo mejor es no publicar nunca fotografías de terceras personas en Facebook. Para compartir fotos hay sitios mejores como Flickr donde se pueden designar personas autorizadas y compartir sólo con ellas las imágenes.

Cyberbullying

El bullying es uno de los aspectos más controvertidos y creo que al mismo tiempo peor entendidos de las relaciones sociales en niños y adolescentes. No existe un acuerdo total acerca de lo que es bullying pero, en general, se acepta que se da cuando en una dinámica confluyen tres factores: agresión, repetición y desequilibrio de poder físico o psicológico.

Recientemente, algunos estudios han mostrado que el cyberbulling es un fenómeno mucho más frecuente entre chicas. Con un 70% de víctimas acosadas por otras chicas. Mientras que en el bullying físico sólo el 47% de las víctimas son mujeres.

El bullying frecuentemente no es considerado con la suficiente seriedad por el claustro y la dirección de muchos colegios. O a veces todo lo contrario, en una política de tolerancia cero se vuelven todos locos si se produce un caso. Además, yo personalmente opino que la teoría moderna de la víctima, el agresor y los testigos es incompleta y probablemente incluso inapropiada como remedio. Según esta teoría (que algunos afirman que tiene resultados milagrosos) la clave para erradicar el bullying consiste en hacer a los espectadores conscientes de su contribución pasiva a la agresión y, una vez que se han dado cuenta, moverles a actuar en grupo para prevenir ataques del agresor. Esta teoría falla por tres lados: 1º) no explica nada acerca de las causas originarias de la agresión, 2º) da por sentado que la agresión es de un individuo a otro cuando de hecho puede que todo el grupo sea el agresor, y 3º) pone sobre un grupo de niños o adolescentes el peso de una responsabilidad preventiva que posiblemente no estén preparados para asumir.

Las políticas de uso de las redes sociales no tienen medidas específicas contra el bullying. Las sugerencias contra el acoso de Facebook básicamente dicen que si alguien te está atacando bloquees su cuenta y ocultes sus actualizaciones. Pero ¡rayos! si eres un adolescente ¿qué haces? ¿ocultas a toda tu clase y te das de baja de la red? Según los community standards también es posible denunciar al agresor y su comportamiento “no será tolerado”, aunque no me queda claro qué implica “no tolerar” más allá de borrar algún comentario o foto.

Las causas del bullying suelen encontrarse en problemas familiares en la casa del agresor, stress, afán de poder, personalidad desordenada, complejo de superioridad o simple placer sádico en el caso de que el bully sea un sociópata, pero la gran mayoría de los bullies no son sociópatas sino las primeras víctimas de sí mismos. Además, el agresor es sólo uno de los implicados, el otro es la víctima quien también puede tener su propio conjunto de problemas que la hagan vulnerable a los ataques: inseguridad, vergüenza, segregación racial, limitaciones físicas, etc. Si no se actua sobre estas causas originarias del bullying entonces el cambio en la dinámica grupal es sólo un remedio sintomático.

El bullying tampoco es sólo un niño quitándole el bocadillo a otro todos los días en el patio. Muy frecuentemente toma la forma de rumores, risitas encubiertas, motes y comentarios jocosos sobre el acosado en los que participa una pandilla entera. Las personas, jóvenes y adultos, se envalentonan y se vuelven más agresivas en masa, entonces el bullying se produce por una dinámica de grupo y no por acción aislada de un individuo. En algunas ocasiones el acosado incluso puede asumir el papel de payaso del grupo y aceptar las vejaciones porque eso le proporciona cierta forma de protagonismo.

Las redes sociales implican, no obstante, buenas noticias para los defensores de la teoría de la víctima el agresor y los espectadores. En la red lo que ha sucedido es visible y perdura. Por consiguiente, fijar los hechos y mostrar lo que ha pasado es más fácil que tras una agresión verbal de la que no ha quedado ninguna constancia fidedigna excepto por las versiones diversas de los testigos.

Drama

Una peculiaridad de los adolescentes que rara vez se da entre los adultos –o al menos yo no la he encontrado en primera persona– es el drama. Los adolescentes pueden organizar una representación dramática para llamar la atención y obtener popularidad.

Peligros online

Por último, me he dejado premeditadamente en el tintero y no quiero entrar a comentar el tema de los peligros online: pederastas, timadores, ladrones, etc. Cualquier sociedad es más peligrosa de lo que debería y el ciberespacio no es diferente. “Cómo protegerse online” podría ser el título de otro post entero además de que no me queda claro si hay sólo que proteger a los adolesentes o también protegerse de ellos.

Posts relacionados:

Cómo y porqué la gente se vuelve adicta al móvil.
Cómo Internet modifica nuestras capacidades intelectuales y sociales.
Sobre la dinámica social en los sitios de dating.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Usos sociales de la tecnología | Deja un comentario

Cómo sacar partido al stack big data de Apache

Hubo un tiempo en que todos los proyectos de la Fundación Apache podían encontrarse listados en su página de inicio. Hoy en día los proyectos 172 que hay en el directorio ya no les caben en la home y se encuentran listados en una página aparte. Hay tantos proyectos que es difícil aclararse, incluso siendo programador. Además los nombres de los proyectos no es que ayuden precisamente a identificarlos (Hadoop es el nombre del elefante de goma que tenía el hijo de su creador). En este post voy a comentar de forma asequible para el lector no técnico los principales productos de Apache relacionados con Big Data. No voy a entrar en generalidades conceptuales sobre Big Data, las cuales daré por sentadas o en caso contrario recomiendo el libro Big Intelligence de Antonio Miranda.

Esquemas de datos, consistencia y disponibilidad

Antes entrar en productos y tecnologías, no obstante, sí quiero hacer hincapié acerca de una diferencia fundamental entre las tecnologías relacionales clásicas y el enfoque de Big Data. Esta diferencia es si se graban los datos contra un esquema de datos ya existente (como el de una base de datos relacional) o si los datos entrantes no deben forzosamente adaptarse a priori a ningún esquema predefinido ni cumplir restricciones de integridad referencial. Cuando se impone que los datos entrantes cumplan las restricciones de un esquema se introduce una penalización en el tiempo necesario para grabarlos y, potencialmente, también una gran cantidad de bloqueos en las tablas de datos. Las operaciones de chequeo llegan a ser demasiado costosas para un sistema que recibe una enorme cantidad de datos entrantes y, por consiguiente, la solución de Big Data es simplemente diferir las comprobaciones y la normalización de datos. Adicionalmente, otra ventaja de trabajar sin esquema previo es que todos los datos entrantes se graban sin modificar a bajo coste y a largo plazo lo cual permite crear nuevas formas de explotación en caso de ser necesarias en el futuro.

El otro gran desafío de las arquitecturas distribuidas es el enunciado por el Teorema CAP que establece que en un sistema distribuido no es posible garantizar la consistencia, la disponibilidad y la tolerancia al particionado simultáneamente. Aunque existen vias de escape si se prohibe actualizar o borrar cualquier dato una vez grabado. Varios productos Big Data funcionan de hecho con esa restricción permitiendo crear nuevas versiones de una fila en una tabla o de un documento pero nunca modificar ni borrar una fila o documento anterior.

Tipos de datos que hay que almacenar y explotar

En casi cualquier aplicación de negocio o científica hay ocho tipos de datos que precisan ser almacenados y explotados. Cada uno de estos tipos de datos tiene características especiales que requieren diferentes tecnologías de almacenamiento, recuperación y explotación.

1. Imágenes y documentos (electrónicos o escaneados).

Las imágenes y documentos pueden ser muy grandes pero poco o nada se sabe normalmente acerca de su contenido. Se almacenan bien en sistemas clave-valor estilo Amazon S3 o Berkeley DB, bien en gestores documentales especializados como Jackrabbit. Para la búsqueda de imágenes y documentos en un sistema clave-valor es posible emplear un indexador “full-text” separado como Solr (la versión distribuida de Lucene). Solr tiene adaptadores que le permiten leer e indexar directamente OpenDocument y muchos otros formatos.

2. Formularios.

Los formularios son lo que los usuarios rellenan en pantalla cuando quieren registrarse en un sitio web, realizar una solicitud o publicar en Facebook. Lo que caracteriza a los formularios es que puede haber muchos diferentes que además cambian con el tiempo. Y no está para nada garantizado que los usuarios vayan a introducir información de calidad (hasta 68 formas diferentes de declarar la nacionalidad española he encontrado yo en una columna de una base de datos procedente de un campo de texto libre en un formulario). Las aplicaciones que manejan procesos por etapas casi siempre necesitan almacenar formularios a veces compartidos por distintos usuarios si se trata de procesos de negocio. Los formularios no son, en general, adecuados para una explotación directa. Por ejemplo, supongamos que se trata de un proceso de registro en una web de comercio electrónico. En el formulario de alta se le pedirán al cliente sus datos personales y una dirección de envío, todo ello en la misma pantalla. Sin embargo, la base de datos necesita almacenar los datos personales por un lado y la dirección por otro, ya que la dirección podría cambiar en el futuro y, por consiguiente, es preciso mantener un histórico de direcciones. El producto de Apache más adecuado para almacenar formularios es CouchDB. Se trata de una base de datos sin esquema que almacena documentos en formato JSON. Bueno, en realidad cada documento incluye su propio esquema (derivado de los campos JSON). CouchDB es NoSQL con replicación multimaster e interfaz CRUD a través de HTTP. Es decir, es fácil comunicarse con CouchDB desde Javascript mandando y recibiendo objetos JSON a través de HTTP. CouchDB está escrito en Erlang, lo cual no tiene absolutamente nada de malo, pero, como no es una elección habitual para el lenguaje base, también hay otra implementación 100% JavaScript que puede correr sobre Node.js

3. Entidades.

Las entidades son con lo que trabajan las bases de datos relacionales clásicas: persona, compañía, empleado, dirección, etc. Las entidades se almacenan en tablas y, para ser eficaces, deben evitar la duplicidad de datos (esto se conoce como normalización) y mantener integridad referencial entre ellas (la provincia en una dirección debe existir en una tabla de provincias y pertenecer al pais elegido). En Apache se puede encontrar una base datos relacional llamada Derby, pero es sólo para sistemas empotrados con baja huella de memoria o fines de testeo. Casi todo el mundo usa MySQL o PostgreSQL como base de datos relacional en producción.

Merece la pena hacer una mención aparte para las entidades que representan productos de un catálogo pues son un caso muy particular debido a que cada producto puede tener un conjunto de muy atributos diferentes, por ejemplo una cámara digital versus un jersey. Además, para cada producto puede haber variantes en tallas y colores. Hay básicamente cuatro posibilidades para almacenar los atributos de los productos: 1ª) se pueden almacenar en una tabla relacional atributo-valor (lo cual es ineficiente), 2ª) se pueden almacenar en una base de datos orientada a columna (de las cuales hablaremos luego), 3ª) se pueden almacenar en un campo BLOB o CLOB de la base de datos relacional, o quizá algo más sofisticado como un HStore de PostgreSQL, 4ª) se puede usar una base de datos sin esquema como CouchDB y permitir que cada producto lleve su propio conjunto de atributos.

Otro caso de uso muy típico es el almacenamiento de entidades con relaciones jerárquicas (donde una entidad contiene otras). Este desafío técnico a mi me parece curioso porque aunque las primeras bases de datos empezaron siendo jerárquicas, como IMS, el modelo relacional simplemente no es adecuado directamente para almacenar jerarquías. Los dos métodos comunes para almacenar jerarquías en bases de datos relacionales son la lista de adyacencia y los conjuntos anidados en cuyos detalles técnicos no voy a entrar pero puede encontrarse una buena explicación aquí. Debido a que los árboles son un tipo de grafo, es posible utilizar eficientemente una base de datos de grafos para almacenar jerarquías, lo cual veremos a continuación.

4. Grafos.

Almacenar un grafo en una base de datos relacional no es realmente nada difícil. Solo se necesita una tabla de nodos y otra de vértices. En SQL para un grafo dirigido :


CREATE TABLE nodos (
id INTEGER,
CONTRAINT pk_nodos PRIMERY KEY(id)
)

CREATE TABLE vertices (
id_nodo_inicio INTEGER,
id_nodo_fin INTEGER
)

El problema de esta implementación es que para obtener la lista de nodos sucesores de uno dado hay que hacer:

SELECT id_nodo_fin FROM vertices WHERE id_nodo_inicio=?

Lo cual parece trivial pero hay que tener en cuenta que incluso estando la tabla vertices bien indizada esta consulta se ejecutará en un tiempo que será log(n) siendo n el número de filas en la tabla vertices. Entonces si el grafo es grande se sobrecargará rápidamente la base de datos.

Lo que hace esencialmente una base de datos orientada de grafos es almacenar los sucesores de cada nodo pegados al propio nodo de manera que el tiempo de recuperación de los sucesores de un nodo permanezca siempre constante independientemente del crecimiento en tamaño del grafo.

Puede ser conveniente separar el almacenamiento de la explotación de grafos. Una posibilidad es almacenar los grafos en tablas como las ejemplificadas y precargarlos enteros en memoria para explotarlos. Esto es lo que hace Apache Giraph. Los nodos y vértices se almacenan en Hadoop pero el grafo se carga en la memoria de los nodos de un cluster. El modelo de programación de Giraph sigue el Pregel de Google. Giraph es la herramienta que Facebook utiliza para analizar el grafo de sus usuarios.

Titan, otra herramienta de procesamiento de grafos, no es de Apache pero hace uso de Cassandra o de HBase para almacenar los grafos. La diferencia práctica con Giraph es que Giraph está más orientado a OLAP y Titan a OLTP.

Además de los sistemas de almacenamiento, en Apache se pueden encontrar otros dos toolkits con algoritmos sobre grafos: Tinkerpop y Spark GraphX.

5. Series temporales.

Las series temporales expresan como cambia una variable función del tiempo. Un ejemplo sencillo son las predicciones meteorológicas por localidad. La primera dificultad para almacenar y tratar series temporales es que el modelo entidad-relación no incluye ninguna noción de temporalidad. Supongamos que tenemos una tabla de empleados y otra de empresas. Entonces en una base de datos relacional es trivial crear una clave foránea desde empleados a empresas que garantice que la empresa referenciada siempre existira. Pero no existe ninguna forma directa de expresar que el empleado Fulanito de Tal trabajó para Cual empresa entre 1994 y 1999. Hay que crear una tabla de histórico de empleos donde el sistema gestor de bases de datos relacional tampoco garantiza que no se solapen los empleos.
Para el caso concreto de las series temporales como las meteorológicas es posible emplear una base de datos orientada a columna como Cassandra. En una base de datos orientada a columna cada fila puede contener un número diferente de columnas y, además una cantidad muy grande de ellas, entonces es posible utilizar el nombre de la localidad como clave de la fila y crear una columna cuyo nombre sea de de cada instante del tiempo en el cual se tomó una medición y la celda contenga el valor de la medición.

6. Logs.

Los logs son toda la actividad que hay que grabar por cuestiones de auditoría de seguridad, trazabilidad de usuarios o depuración del sistema. La moda para recopilar logs es Kafka un sistema distribuido escrito en Scala que prioriza el rendimiento sobre la garantía de grabación de los logs en caso de fallo. Los logs son fáciles de recopilar cuando se trabaja con una sóla máquina. Simplemente hace falta un archivo y una cola de escritura asíncrona. Apache Tomcat trae de serie un recopilador de logs asíncrono que puede activarse fácilmente. El problema con los logs aparece cuando se pretende combinar los procedentes de varios servidores, especialmente si se desea que estén grabados en un orden estricto (usualmente temporal). Lo que Kafka hace es encolar localmente en cada servidor los mensajes de log, y luego los publica en un cluster al cual los procesos que extraen información de los logs pueden suscribirse.

6. Eventos.

En ocasiones es necesario que la aplicación reaccione en un tiempo corto como respuesta a un evento externo. O que sea capaz de aceptar una avalancha de eventos externos. Para la recolección de eventos es posible usar Apache Flume. Y para el procesamiento en tiempo casi real es posible usar Flink o Storm.

Big Data Stack

8. Informes.

Los informes son normalmente de tres tipos: 1º) listados operativos (transferencias bancarias realizadas ayer), 2º) resúmenes de KPIs (Key Performance Indicator), 3º) resultados OLAP (OnLine Analytical Processing) para modelos predictivos, simulación, etc.
La creación de informes consta de dos etapas. Primero se hace un proceso de extracción, transformación y carga (ETL) en el cual se leen los datos del almacén NoSQL y se graban en otro almacén apropiado, típicamente cubos OLAP para el análisis multidimensional. El proceso ETL puede ser bastante costoso y complicado computacionalmente motivo por el cual requiere un análisis refinado de los tiempos necesarios para mover los datos teniendo en cuenta la velocidad de la electrónica de red y de los discos. El proyecto de Apache para hacer OLAP sobre Hadoop es Kylin donado por eBay.

Principales productos big data en Apache

Hadoop

Las plataforma base de almacenamiento distribuido en Apache es Hadoop, un sistema distribuido de archivos.

La forma más sencilla de entender conceptualmente Hadoop es pensar que es como un disco virtual que por detrás está compuesto realmente de montones de discos esparcidos por un cluster de servidores. Las tecnologías de virtualización hacen que una misma máquina física pueda ejecutar varias máquinas virtuales. Pues bien, Hadoop hace exactamente lo contrario: muestra varias máquinas físicas como una única máquina virtual.

El sistema de archivos de Haddop se conoce como HDFS. Por razones técnicas, HDFS no maneja bien archivos pequeños. El espacio minimo que un archivo HDFS ocupa se suele fijar en una cantidad entre 64Mb y 256Mb. HDFS permite crear, eliminar, leer secuencialmente y añadir datos a archivos, pero no se puede modificar el contenido de un archivo excepto copiándolo en local y subiendo a HDFS una nueva copia.

Hadoop también incluye un ejecutor de procesos llamado YARN (Yet Another Resource Negotiator). YARN se diseñó originalmente para ejecutar MapReduce pero luego evolucionó hacia la ejecución de procesos en general proporcionando facilidades para que los procesos ejecutados se encuentren lo más próximos posibles a los datos, a ser posible en la misma máquina o si no al menos en el mismo rack.

La principal pega del API de Hadoop es que originalmente sólo funcionaba con Java y, además, carece de abstracciones para representar otros objetos que no sean sus “archivos ballena”.

Al igual que sucede con las distros de Linux, es posible utilizar directamente el software de Hadoop disponible en la web de Apache, pero muchos clientes utilizan una distribución comercial con soporte y software adicional bajo licencia principalmente porque configurar y mantenar operativo un cluster de Hadoop no es para nada sencillo técnicamente. La distribución con mayor cuota de mercado es Cloudera, seguida de HortonWorks, MapR, Amazon Elastic MapReduce e IBM Infosphere BigInsights.

HBase

HBase es una base de datos maestro-esclavo orientada a columna implementada sobre Hadoop siguiendo el modelo de Google Bigtable. En HBase cada fila en una tabla debe tener una clave primaria. En principio, no existen índices secundarios, de modo que en esencia se trata de un sistema clave-valor pero con algunos “extras” importantes.

Cada tabla en HBase se compone de un conjunto de familias de columnas. Las familias de columnas deben definirse de forma estática cuando se crea la tabla pero luego cada fila puede contener un número diferente de columnas en cada familia de cada fila. Todas las columnas de una familia se almacenan juntas y ordenadas por nombre. Además, pueden existir múltiples versiones para los valores de cada celda, ordenados según una marca temporal (timestamp). El calificativo de tabla en las bases de datos orientadas a columna es, por consiguiente, equívoco, ya que sugiere algo similar a una tabla relacional o a una hoja Excel cuando en realidad consiste en una estructura distribuida de datos que dada una clave devuelve una colección de mapas (familias) nombre-valor.

Volviendo al caso de almacenamiento de grafos, recordemos que el problema de almacenarlos en una base de datos relacional es que para encontrar los sucesores de cada nodo es preciso realizar una consulta en una tabla cuyo tiempo de ejecución depende del tamaño del grafo y del número de sucesores. En HBase (u otra base de datos orientada a columna como Cassandra) los sucesores pueden obtenerse eficientemente como todas las columnas de una familia en una fila recuperada por clave primaria (el identificador del nodo de origen). Debido a que todas las columnas de una familia se almacenan juntas, los sucesores de un nodo pueden recuperarse en una única operación en lugar de tener que escanear la tabla con las relaciones nodo-origen – nodo-destino.

ilas y columnas HBase

A diferencia de las bases de datos relacionales, HBase no permite especificar claves foráneas, tampoco existen índices secundarios ni se pueden definir transacciones. Las operaciones de lectura y escritura son atómicas a nivel de fila pero HBase carece de un mecanismo para garantizar que dos filas serán actualizadas de forma coherente. Los índices secundarios pueden crearse mediante una funcionalidad llamada coprocesadores, que también sirve para emular disparadores y procedimientos almacenados, pero programar contra el API de los coprocesadores no es fácil. Las transacciones y el soporte SQL pueden montarse por encima con otro proyecto de Apache llamado Phoenix. No obstante, el uso de Phoenix implica una penalización en rendimiento y escalabilidad ya que hay que añadir un gestor centralizado de transacciones a un sistema cuya escalabilidad depende de que funcione de forma distribuida. Además, yo creo que el uso de SQL es innecesario y equívoco en el caso de las bases de datos orientadas a columna.

HBase almacena los datos ordenados por clave primaria, por tanto, ofrece un redimiento óptimo para recuperar datos por rango de valores de la clave primaria. Un ejemplo podría ser el almacenamiento de emails siendo la clave primaria un identificador de usuario seguido de una marca temporal, y dos familias de columnas, una para las cabeceras y otra para el cuerpo del mensaje. Esto permitiría recuperar eficientemente los últimos n mensajes de cada usuario. Los índices secundarios, no obstante, habría que montarlos manualmente por separado.

HBase proporciona interfaces Java y Thrift y también un shell JRuby.

Hive y Pig

Para superar las limitaciones funcionales de Hadoop en el tratamiento de datos aparecieron Hive y Pig. Hive lo que permite básicamente es tratar archivos de texto un dialecto de SQL (HQL) como si fuesen tablas de una base de datos relacional, pero sin precargar los datos en un SGBDR. El esquema de los archivos tratados se almacena como metadatos en una base de datos relacional auxiliar. Esto permite hacer operaciones como count() o sum() y también join de archivos pero sin pagar el coste del tiempo de carga en un SGBDR.

Pig es principalmente una herramienta de ETL. A diferencia de Hive, funciona sin esquema y consta de tres partes: 1ª) Pig Latin, un lenguaje de scripting para describir procesos MapReduce; 2ª) Grunt, un shell interactivo y 3ª) Piggybank, un repositorio de funciones definidas por el usuario (UDF).

Hive y Pig están siendo paulatinamente desplazados por Spark.

Spark

Spark ha sido de un tiempo a esta parte la estrella de las aplicaciones de Apache para Big Data. Es un desarrollo originario del AMPLab de UC Berkeley que fue donado a Apache. Su éxito se basa en una mayor orientación a hacer uso intensivo de la memoria por contraposición a Hadoop que está orientado a usar los discos y en su aproximación de programación funcional sobre dos abstracciones de datos conocidas como resilient distributed data set (RDD) y DataFrames. Los RDD básicamente tablas distribuidas e inmutables sobre las que se pueden realizar dos tipos de operaciones: transformación y acción. La transformación convierte el RDD en otro RDD. Por ejemplo, map, filter, flatMap, groupByKey, reduceByKey, aggregateByKey, pipe, y coalesce son transformaciones. Y algunas acciones son reduce, collect, count, first, take, countByKey, y foreach. Spark evalua las transformaciones y acciones de forma perezosa, es decir, los resultados no se calculan realmente hasta que un proceso trata realmente de consumirlos para hacer uso de ellos. A diferencia de Hadoop donde las etapas map y reduce de MapReduce se comunican a través del disco, Spark intenta comunicar los resultados entre etapas en memoria motivo por el cual puede alcanzar rendimientos de uno o más órdenes de magnitud superiores a Hadoop.

Spark requiere para funcionar de un gestor de cluster y de un sistema de almacenamiento persistente. El gestor de cluster puede ser uno nativo de Spark, o también YARN o Apache Mesos. Para el almacenamiento Spark puede usar HDFS, MapR-FS, Cassandra, OpenStack Swift, Amazon S3 o Kudu.

Spark se compone de cinco modulos: core, SQL, streaming, machine learning (MLib) y grafos (GraphX). El core proporciona las funcionalidades de procesamiento y almacenamiento distribuido a través de interfaces Java, Scala, Python y R.

Cassandra

Cassandra es otra base de datos orientada a columna. Originalmente desarrollada por Facebook y luego donada a Apache. No es maestro-esclavo como HBase sino que se compone de un conjunto de nodos iguales que se comunican por un protocolo P2P sin depender de Hadoop como HBase. La estructura de las tablas es similar a la de HBase aunque se permite que los valores de las celdas sean también mapas atributo-valor. Y se pueden crear índices secundarios sobre columnas que no contengan mapas en sus celdas. Es decir, se puede pensar en una fila de Cassandra como un conjunto de mapas anidados.

En general, los benchmarks tienden a mostrar que Cassandra muestra un buen comportamiento respecto de los tiempos de escritura, pero las latencias son mayores que las de HBase en los tiempos de lectura. Ambas base de datos manejan las escrituras grabando previamente cada petición en un log local que luego se graba en el nodo o nodos apropiados del cluster como un sistema de mezcla coordinada de logs.

Cassandra ofrece APIs Java, C#, Python y Thrift. Pero el interfaz Thrift está siendo descatalogado en favor de CQL sobre JDBC.

Machine Learning

Hay tres proyectos en Apache que incluyen algoritmos de machine learning: Spark MLib, Mahout y FlinkML. Mahout proporciona un motor genérico de álgebra pero a la postre se trata la mayoría de las veces de encontrar el proyecto que contiene el algoritmo de machine learning requerido.

Otros proyectos Apache

Para no abrumar al lector, me he dejado en el tintero al menos dos docenas de proyectos de Apache. Hay una lista descriptiva aqui.

Consejos para elegir y desplegar tecnologías big data

1. Hacer un inventario de tipos de datos que se vayan a necesitar.

2. Definir los patrones de acceso a los datos.

3. Crear los modelos de datos de acuerdo a las necesidades de los patrones de lectura y escritura.

4. Utilizar el menor número posible de productos y tecnologías diferentes pues cada pieza añade complejidad adicional y aumenta la probabilidad de fallo del sistema.

5. No obstante lo anterior, no almacenar nunca en una base de datos relacional ni los logs ni los archivos binarios grandes. Las razones para no hacerlo son: 1ª) la escritura constante de logs puede sobrecargar fácilmente el sistema gestor de base de datos y 2ª) los logs y los archivos binarios grandes crecerán rápidamente hasta representar la mayor parte del tamaño de la base de datos, eso dificultará los backups y creará problemas de espacio en disco que no existirían si los logs y los archivos se guardasen separadamente en otro lugar más apropiado.

6. Elegir los proveedores para cada tecnología seleccionada. Aquí entran en juego detalles técnicos que dependen de las necesidades de cada proyecto. No se puede decir que PostgreSQL sea mejor que MySQL o que Cassandra sea mejor que HBase. Tampoco es inmediato que una infraestructura cloud proporcionada por un tercero sea mejor que una infraestructura propia. Depende de para qué.

7. Estimar el coste de despliegue y de mantenimiento. Mantener operativo un cluster, en general, no es fácil ni barato.

8. Establecer las métricas de coste de almacenamiento y retorno de inversión por byte almacenado. En función de dichas métricas, decidir qué datos merece la pena conservar y por cuánto tiempo.

9. Verificar cómo se moverán los datos de una plataforma a otra.

10. No confiar aspectos críticos del negocio a nuevas tecnologías hasta que no se haya comprobado su estabilidad. No todo lo que se puede descargar de Apache es estable. En el caso de las bases de datos los mayores problemas casi siempre se encuentran en los drivers de la parte cliente. El servidor en si mismo es estable. Pero el driver pierde memoria, o un mal uso del mismo deja conexiones abiertas que acaban tumbando el servidor. Si se monta una base de datos relacional para las entidades, y Cassandra para almacenar el catálogo de productos, y un cluster de Hadoop para el almacenamiento de imágenes, y HBase para almacenar mensajes de los clientes, y CouchDB para almacenar los formularios de las encuestas de satisfacción y Flume para capturar eventos y Kafka para gestionar los logs y Spark para hacer análisis de los datos y Kylin para hacer OLAP y… y… y… Muy probablemente el sistema será escalable hasta el infinito al tiempo que por completo inestable e imposible de mantener.

Posts relacionados:

NoSQL para no programadores.
El ecosistema de productos Big Data.
Cómo diseñar una aplicación escalable.

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

El emprendedor adolescente

Todos los veranos blogeo alguna historia. La verdad es que en los ya más de 10 años desde que heredé La Pastilla Roja siempre he tratado de evitar la autobiografía pues me aburren, en general, las personas que se dedican a contar su opinión introspectiva ya que a fin de cuentas todo el mundo tiene una opinión frecuentemente tan válida como cualquier otra. No obstante, haré una pequeña excepción esta vez pues creo que algunas experiencias adquiridas en mi periplo emprendedor merece la pena compartirlas. Voy a contar sólo lo imprescindible (que no es poco) sobre los primeros años para que se entienda el contexto, e intentaré detallar un poco más los años recientes tras irme a Inglaterra por estar más próximos a la realidad que otro emprendedor pueda encontrarse ahora mismo.

Soy un emprendedor adolescente, empecé en 2000 y dieciseis años no es nada. A los dieciseis apenas ha terminado de salirles el bigote a los jóvenes imberbes. Tuve, no obstante, una ventaja de salida, que también fue una trampa (por razones demasiado largas de contar): la de provenir de una familia de abuelos y padres emprendedores. También me influyó mucho uno de mis primeros empleos, el de los años que pasé en Meta4, una multinacional española de desarrollo de software como nunca he vuelto a encontrar otra igual. No sólo por la velocidad a la que creció, sino también por su espíritu y sus políticas de recursos humanos que fueron capaces hasta de acomodar a un disidente crónico como yo. Meta4 falló básicamente por efecto de segundo de sistema en una historia que puede encontrarse resumida aquí, pero antes de eso creó un montón de valor y provocó una diáspora de profesionales de la cual yo fui parte.

Salir con buenas referencias de mi primer empleo por cuenta ajena me abrió algunas puertas. Cuando empiezas no tienes nada excepto la confianza en tu coraje que puedas generar en los compradores potenciales, y si ese coraje viene avalado por recomendaciones mejor que mejor. Tu cliente, la ciudad de Gotham, necesita a Batman y a Robin, no al inoperante departamento de policia local. Algunos emprendedores se acomplejan e intentan vender la empresa por lo que no es: más grande, más formal. Esto es un error pues también hay clientes muy interesados en contratar superhéroes.

Mi plan de negocio original no tenía ni pies ni cabeza, tampoco tenía ni idea de finanzas ni de cómo funcionaba realmente el mercado. Aún así conseguí el apoyo de algunos socios y P.P.P. (Primos, Parientes y Putas). Afortunadamente, por casualidad o por sapiencia, estábamos en medio de la primera burbuja punto com y nuestro cash burning rate era bajo, de modo que pronto empezamos a crecer en facturación con pingüe beneficio ya que en aquella época los márgenes brutos en consultoría rozaban el 60%

Después de fabricar un prototipo fallido de Dropbox y otro prototipo fallido de Magento, en el año 2003 (tres años después de fundar la empresa) averigué qué era lo que había que desarrollar, lo cual resultó ser un CRM Open Source bautizado hipergate que durante una década fue bastante exitoso antes de que el SaaS tomara el relevo como modalidad de distribución de software. A hipergate le exprimimos el jugo durante diez años desde 2003 a 2013. El truco erá que la inversión inicial necesaria fué baja (por debajo de 250.000€) y podíamos asumirla sin inversores externos. Además, el mantenimiento evolutivo anual también era barato y financiado en buena medida por clientes. Por consiguiente, cualquier múltiplo que le hiciésemos a esa cantidad iba a beneficio. Esto contrastaba con las inversiones millonarias que empezaron a recibir en los años siguientes otros productos de software empresarial Open Source. La realidad es que en el Software Libre una gran parte del valor creado se transmite al cliente de forma gratuita y, por tanto, la rentabilidad de la empresa es menor. También son menores sus costes comerciales pero hay que ajustarlo todo en función de los ingresos por ventas. Lo cual me conduce al primer gran hallazgo que creo merece la pena compartir:

No es necesaria inversión para ganar dinero.

Esta ha sido mi realidad una y otra vez. Los negocios en los que no he invertido dinero, o muy poco dinero, me resultaron muy provechosos, así fue en KnowGate y en iContainers. Por contra, los negocios en los que he invertido fuertemente he perdido siempre hasta la camisa. No fue hasta 2009 cuando en una visita de turismo tecnológico a Silicon Valley tuve la oportunidad de desayunar con Scott McNealy quien ataviado en vestimenta de golf se limitó a dar dos consejos: a) haz negocios siempre con el dinero de los demás, nunca con tu propio dinero, y b) si sacas tu empresa a bolsa la perderás inevitablemente.

No obstante lo anterior, existe un punto de inflexión en el que sí hay que estar preparado para endeudarse: cuando la empresa empieza a escalar en ventas. En retrospectiva, fué un error estratégico no globalizar KnowGate endeudándonos. Al principio del milenio hacíamos muy buen dinero con la venta de servicios pero el modelo de negocio no era adecuado para internacionalizarlo. Luego tuve otra buena oportunidad en 2004 con hipergate, pero decidí optar por quedarme en mi pueblo y diversificar invertiendo en ladrillos (con el resultado que el lector podrá imaginar). Y para cuando quise volver intentarlo en 2009 ya era tarde pues la competencia de software CRM había progresado mucho y yo andaba demasiado ocupado parcheando el socavón que la explosión de la burbuja inmobiliaria me había creado.

Gracias a la bonanza económica, entre 2006 y 2010 fue muy fácil conseguir financiación pública de diversas fuentes. Sé que los inversores privados critican a la financiación pública porque hace competencia desleal a sus productos financieros. Pero si se puede acceder a ella es dinero muy barato. Hay más detalles sobre cómo funcionaba esto aquí, aquí, y aquí.

En 2009 estábamos en una buena posición. El reventón de la primera burbuja punto com había impactado ciertamente la empresa en 2002, pero no tanto como para desposeerla de capacidad para seguir invirtiendo e innovando. Acumulábamos 9 años de beneficios consecutivos y no teníamos deuda. Y todavía no nos había alcanzado el tsunami de la crisis inmobiliaria porque las grandes empresas para las que siempre hemos trabajado hacen presupuestos anuales y tienen buena calificación de riesgo crediticio (aunque sea mentira).

La diferencia entre la crisis de 2002 y la de 2008 es que la de 2002 fue un suceso súbito y de alcance limitado. El IBEX Nuevo Mercado ¿alguien se acuerda? se fué en bloque a Alpedrete y aniquiló proyectos pioneros como Terra y TPI, pero no dañó demasiado la economía española en conjunto. Además inmediatamente a renglón seguido el ladrillo empezó a tirar del carro y volvieron las vacas gordas. Por contra, la crisis de 2008 fue, y sigue siendo, un proceso agónico que nadie pronosticaba que durase tanto ni tan duramente.

Al principio fué como caerse de un rascacielos: vas por el piso cuarenta y no te enteras demasiado excepto por cierta sensación de vértigo en el estómago. En 2011, casi tres años después del inicio oficial de la crisis y aún en beneficios, empezaron a combinarse varios factores para crear la tormenta perfecta.

• En primer lugar los precios por hora de consultoría prácticamente no habían variado desde el año 2000, pero los costes sí que habían crecido significativamente. Por consiguiente, los márgenes se habían reducido muchísimo, y la rentabilidad se mantenía en gran parte gracias a subvenciones públicas que se repercutían en los clientes. KnowGate vendía con frecuencia a pérdida y compensaba con la subvención. Pero tras la victoria electoral del Partido Popular las subvenciones se redujeron enormemente, tanto que en muchas ocasiones ni valía la pena solicitarlas.

• En segundo lugar los clientes habían apostado porque la crisis no sería muy larga y habían seguido endeudándose tanto como los bancos les habían permitido en la esperanza de que el temporal pasaría pronto. Creo que muchos incluso pensaron que la situación mejoraría con el ascenso al poder de Mariano Rajoy. Pero cuando empezaron a caer los bancos como fichas de dominó se secó definitivamente el crédito a las empresas. Especialmente el crédito procedente de las cajas quebradas que eran menos exigentes en análisis de riesgos que los grandes bancos como Santander y BBVA.

• En tercer lugar yo había estado derivando una cantidad excesiva de caja y de deuda desde el negocio tecnológico hacia el del ladrillo en un intento de salvar la moribunda inversión inmobiliaria. La sangría había reducido la capacidad de KnowGate para reinvertir en I+D justo en el momento en que la competencia venía pisando más fuerte en SaaS.

• El toque de gracia fueron los impagos sistemáticos de 2013. Prácticamente todos los clientes empezaron a tener problemas para pagar, variando desde la demora al impago total. En España la justicia civil es inoperante, especialmente en temas mercantiles (excepto si se trata de la AEAT, y a veces ni eso). En consecuencia, no había forma de cobrar ni tampoco de refinanciarse. Adicionalmente, un agravante era que en 2002 los clientes dejaron súbitamente de comprar (lo cual es malo) pero entre 2011 y 2013 siguieron comprando a sabiendas de que probablemente no podrían pagar, lo cual es mucho peor para el proveedor.

Empezaron a producirse situaciones absurdas. Una aseguradora nos ofreció una póliza de cobertura de impago que contenía una cláusula que decía que el seguro no sería aplicable en el caso de que la información financiera suministrada por el cliente no fuese totalmente veraz. Otro banco nos ofreció una línea de crédito con otra cláusula que estipulaba que la entidad podría cancelar unilateralmente la línea de crédito y exigir el retorno inmediato del principal en el caso de que nuestra calificación de riesgo variase. En otra ocasión un director de sucursal me ofreció una línea de crédito de 60.000€ al 7% y me dio largas durante cuarenta y cinco dias hasta el día 25 de un determinado mes. Entonces se presentó en el notario con una póliza de 30.000€ al 9,5% a sabiendas de que yo no tenía dinero para pagar las nóminas ese mes si no firmaba, alegando que en riesgos le habían prohibido ninguna otra cosa justo esa misma mañana pero sin que se hubiera producido ninguna variación importante en nuestra posición financiera desde que solicitamos y supuestamente se aprobase el crédito.

Fué el hartazgo en perseguir a los morosos lo que me impulso en último término a mover el culo y empezar de verdad a buscar clientes fuera de España. Era muy curioso porque contablemente la empresa estaba bien pero no teníamos ni un céntimo de caja. En cierto sentido los bancos nos hicieron un favor al no refinanciarnos, pues en el caso de haberlo hecho yo habría posiblemente contraido más deuda para financiar los impagos lo cual hubiese sido un error. La sociedad limitada española había que sanearla asumiendo los incobrables y al final en 2014 acabó dividida en dos, la propia KnowGate y QSWKS (nos van los nombres impronunciables) a cargo de mi hermano que había sido mi socio cofundador desde el principio. Un año después habíamos liquidado al resto de los socios fundadores de KnowGate y constituido una nueva sociedad en Inglaterra. La lección en todo esto es lo segundo que quiero compartir:

Voy a volver a trabajar con un banco en la próxima vida.

No he firmado un crédito desde 2008 y no pienso volver a hacerlo a menos que me apunten con un arma a la cabeza.

Desde 2003 teníamos muchos partners de hipergate pero hacíamos poco negocio con ellos pues nunca tratamos en serio de explotar comercialmente el mercado internacional. No trabajar más con los partner y las relaciones públicas internacionales fue un craso error estratégico.

Esto me conduce a lo tercero importante que quiero compartir:

El error estratégico que más lamento y que más me ha costado como emprendedor es no globalizar el proyecto desde el principio. Es haberme quedado en mi pueblo porque vivía bien haciendo ventas en el barrio y sus aledaños a grandes empresas que tenían más capacidad de compra que nosotros de venta.

Tenía varias opciones como destino: podía intentarlo en Silicon Valley, podía intentarlo en Londres o podia intentarlo en Zurich u Oslo. Dependía del modelo de negocio que eligiese. Silicon Valley parecía el destino más idóneo para crear un nuevo producto, pero implicaba quemar todas mis naves, además de que no tenía claro qué hacer con hipergate. Suiza o Escandinavia ofrecían los mejores salarios si lo que quería era trabajar como programador. Londres tenía la ventaja de la proximidad, facilidades de asentamiento y una fuerte demanda de servicios profesionales de desarrollo de software bien pagado. Así que fué Londres.

Desembarcar en el mercado inglés fue relativamente fácil. La burocracia requerida es mucho menor en Inglaterra que en España, y no tardé más de seis meses en encontrar socios en una empresa SaaS ansiosos por contar con mano de obra especializada que, además, podía ser reclutada y ubicada en España. Así que era posible crear un flujo de caja intracomunitario para contribuir a mantener el empleo en España. Esto no funcionó a la postre excepto por algunas subcontrataciones, pues los programadores que podían estaban huyendo en masa de España y acabamos contratando programadores españoles residentes en Inglaterra por un coste muy superior al que nos hubiese supuesto en España. También fue fácil que IBM se implicase en la comercialización conjunta de su stack sobre Websphere, y encontrar apoyo logístico y financiero de la multinacional española Habber Tec para intentar expandirse en el Reino Unido.

El mercado inglés es muy hostil y competitivo y no es para todo el mundo. Algunos españoles nunca consiguen adaptarse. La pretendida educación y buenas maneras de los ingleses enmascara una agresividad insospechada. Algunos compradores potenciales pueden vapulearte sólo por placer. El nivel técnico de la oferta es más elevado y cómo en la City ya no cabe más gente el número de candidatos bien preparados es a veces apabullante. Hay de todo, españoles, italianos, griegos, sudafricanos, hindues, africanos, y un larguísimo etcétera de gente de todos los colores.

El mal clima es un mito. Es verdad que en invierno se hace de noche a las cuatro y media, pero los veranos son muy agradables. El calor nunca es sofocante. La lluvia frecuente ha puesto fin a mi congestión nasal crónica y en la periferia hay menos polución que en Madrid o Barcelona. Lo peor es el viento, solo los extranjeros usan paragüas, pues los nativos saben que no es buena idea a menos que se pretenda volar como Mary Poppins. El transporte ferroviario también es comparativamente muy malo, al nivel de los trenes de media distancia que unían Madrid con Extremadura en los noventa.

La competencia de productos también es dura en Inglaterra. Las empresas proveedoras están muy especializadas y encontrar un “océano azul” o una buena imperfección de mercado es extraordinariamente difícil. Estratégicamente puede que compense expandirse hacia los Midlands donde la oferta es menor debido a lo mal comunicado que está el país isleño. Y sobre todo Irlanda debido a su ventajosa fiscalidad y facilidades para el asentamiento. Yo aún no he explorado estas opciones, pero parecen prometedoras.

Una ventaja del mercado inglés es que los clientes, además de tener más capacidad de compra, se molestan menos si te enriqueces trabajando para ellos. En España era frecuente tener la sensación de que el cliente estuviese molesto porque ganábamos dinero “a costa suya”. Siempre andaban indagando sobre nuestros márgenes para dejarnos en coste de empresa más 15%. En Inglaterra hemos recuperado márgenes por encima del 40% que es el mínimo en una empresa de consultoría para resultar rentable.

Por el momento no tengo planeado volver a España, lo siento. La razón es que, básicamente, con respecto a la coyuntura de mercado hay dos entornos posibles: a) el país está bien desarrollado, hay competencia, burocracia, elevados impuestos y mano de obra cara pero también una potente demanda; o b) el país está subdesarrollado, la demanda es débil excepto por algunas grandes cuentas pero existe poca competencia y es barato producir. Mi problema con España es que es complicado como un mercado desarrollado pero con una demanda débil. Los salarios se han abaratado, si, gracias al glorioso plan estratégico estatal de intentar copiar el modelo económico chino, pero los buenos programadores han huido y, paradójicamente, es más difícil ahora mismo encontrar mano de obra bien cualificada en España que en el Reino Unido. En España llegó un momento en el que prácticamente teníamos que suplicarle a los clientes que nos comprasen algo. Luego había suplicarles que nos lo pagasen, en el mejor de los casos a 90 días. En Inglaterra es muchísimo más fácil que un cliente potencial se interese por lo que le cuentas y los pagos son treinta dias máximo, a veces a quince, sin historias de indios y vaqueros en plan “el SAP no me deja pagar en agosto”.

El plan a futuro es innovar en la forma en la que se produce el software empresarial y se distribuyen los servicios profesionales en una economía globalizada. Los detalles de este plan aún no los puedo desvelar. Espero que sean la transición de la adolescencia a la madurez conduciendo a un éxito sereno.

Hay más detalles biográficos, mios y de otros emprendedores similares, en este libro de Ana Oliva.

Post relacionados:
Las reglas del perro viejo para los negocios.
La trampa mortal del crecimiento.
Pírricas victorias empresariales.
Saṃsāra corporativo y stress del emprendedor.
Preguntas típicas que hacen los emprendedores noveles.
Combatiendo a tus dragones.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Emprendizaje, Mercado y Oportunidades de Negocio, Modelos de Negocio | Deja un comentario

Cómo sobrevivir al software “Enterprise”

Hace poco me sonreía con una viñeta cómica que presentaba el concepto de “Programador Orientado a Google” en referencia a aquellos quienes han adquirido la mayor parte de sus conocimientos por su propia cuenta buscando Internet. Conozco no pocos programadores de esta clase, un puñado de ellos me parecen realmente sobresalientes. No obstante, la industria de software que se ve en Google, como toda la WWW en sí misma, es sólo la punta del iceberg. Este post me ha quedado algo largo y plúmbeo en comparación con las batallitas que suelo narrar. Pero si el lector es informático, o sufrido usuario de informática, le ayudará a reflexionar sobre cosas que posiblemente ya sabe aunque no se haya dado cuenta.

¿Qué caracteriza al software “Enterprise”?

Para los que no estén familiarizados con la historia, el Software Enterprise es algo demoníaco. Es tan pernicioso que se generó un movimiento cultural mundial, el Software Libre, en su contra. Y, sin embargo, el software enterprise también es necesario para el mantenimiento de la industria, incluso la industria del Software Libre. Aunque la innovación la encabeza el software libre, gran parte del dinero que nutre dicha innovación sale de empresas de software privativo ya sea on premise o SaaS. Y los algoritmos más avanzados en inteligencia artificial, machine learning y aplicaciones militares siguen estando sólo al alcance de unos pocos ojos.

Ahora la moda es publicar código en Github (benditos aquellos años 2003-2005 en los que estábamos en el top 10 de SourceForge con nuestro CRM libre hipergate :D). Pero la mayoría de los informáticos no hacen carrera publicando en Github ni sumando medallas en HackerRank. Por consiguiente, necesitan habilidades diferentes de las del Programador Orientado a Google que se caracterizan por lo siguiente:

1. La documentación es comparativamente paupérrima. No tanto por los manuales en sí mismos sino por la imposibilidad de consultar en Stackoverflow cómo se hace esto o aquello. Incluso los ISVs más importantes como IBM, Oracle y SAP tienen lagunas enormes en su documentación. Tampoco existe una comunidad de usuarios como tal, sino que se depende del soporte técnico del fabricante, el cual es caro, lento y a menudo con menos conocimientos prácticos que el cliente que está sufriendo en sus carnes la puesta en producción.

2. Los módulos son cajas negras. No se puede mirar dentro de ellos para ver qué están haciendo. Si no funcionan bien poco se puede hacer para soslayar el problema.

3. El programa de instalación no es algo a lo que le hayan prestado mucha atención. Hay algunas excepciones, creo que la más notoria que conozco eran los instaladores de Panda, por la dificultad excepcional de instalar un antivirus. Pero el instalador no suele considerarse un componente prioritario. Es por eso que empresas como Bitnami han tenido tanto éxito externalizando la función de instalación. A los desarrolladores normalmente se les da una máquina virtual con todo el entorno preinstalado pero no es fácil replicar todo un ecosistema empresarial en local, por consiguiente, pocas veces se puede desarrollar en remoto sino que hay que trabajar de cuerpo presente conectado a las redes internas del cliente.

4. Los expertos escasean. Debido a la dificultad para autoformarse, sólo la gente que ha trabajado en proyectos reales tiene los conocimientos necesarios.

5. El control de versiones es propietario. En el software enterprise muchas veces se programa con un lenguaje de scripting que corre sobre la plataforma privativa. Es frecuente que la plataforma no esté integrada con un sistema de control de versiones estándar como Git o Subversion.

6. Puede ser difícil hacer TDD. Muchas plataformas no incorporan un marco idóneo para el diseño dirigido por tests. Hay que instrumertarlo por fuera con Selenium o alguna otra herramienta.

7. Los componentes están pensados para integrarse en arquitecturas existentes. Esto implica que existirán piezas de las que les gustan a los administradores de sistemas, como single sign-on o sistemas de monitorización. También implica que el número de novísimas librerías “alienígenas” es menor debido a que a los técnicos del cliente no les suele gustar, y con razón, tener que mantener tecnologías de las que son totalmente desconocedores además de ser cuestionables en estabilidad, seguridad y rendimiento debido a su novedad. Ciertamente es posible encontrar piezas de Python 3 escondidas en lo profundo de la aplicación Core Java más recalcitrante, pero no suele ser la tónica que las grandes empresas sean adoptadores tempranos de tecnología excepto en proyecto tácticos con los que pretenden ganar una ventaja competitiva.

¿Qué tener en cuenta a la hora de producir software enterprise?

Como consecuencia de los puntos anteriores, conviene tomar en consideración que:

1. La especificación no puede contener nada que no esté en la documentación. El cliente no puede escribir la clase de Carta a los Reyes Magos tradicional en un proyecto de desarrollo a medida sobre Software Libre. Sólo puede pedir lo que se pueda encontrar en la documentación, pues el nivel de esfuerzo para hacer cualquier otra cosa variará desde titánico a imposible según el caso.

2. Los usuarios tienen que aprender a usar el software. Y no al revés. Quiero decir, cuando se va cambiando su comportamiento del software para adaptarlo a lo que los usuarios esperan que haga.

3. La instalación pueden convenir encargársela al ISV. Así como la actualización de versiones y el desarrollo de plug-ins estrechamente acoplados con el sistema principal.

4. Hay que incluir programas de formación para desarrolladores en la planificación. No se puede conjeturar que habrá en el mercado consultores disponibles. Puede que si, o puede que no. Por consiguiente, lo más prudente es pagar por la formación previa de todos los que vayan a desarrollar sobre la plataforma.

5. Hay que hacer el control de cambios a la antigua usanza. Aunque casi todas las herramientas enterprise proporcionan algún tipo de gestión de versiones, en muchas de ellas no existe una forma sencilla de trazar los commits o revertir un cambio puntual.

6. Conviene sobredimensionar los servidores. Muchas de las aplicaciones enterprise son bastante pesadas, sobre todo en consumo de memoria porque suelen hacer uso de un número muy considerable de librerías. Además, debido a la opacidad sobre el funcionamiento interno de los módulos es difícil hacer optimizaciones en el caso de que el rendimiento no sea el deseado.

¿Cómo influye el entorno organizativo?

Además de la naturaleza particular del software enterprise, hay que tener en cuenta el ecosistema de departamentos que coexisten en una gran empresa donde cada incumbente tiene intereses diferentes de los demás.

1. Patrocinio directivo. Según el capítulo primero de cualquier libro de gestión de proyectos, nada sale adelante sin la sponsorización de la alta dirección. El soporte de alto nivel ejecutivo sirve para garantizar que se mantendrán los recursos humanos, físicos y monetarios asignados al proyectos. Pero cuidado porque el soporte ejecutivo también puede ser una manzana envenenada por tres motivos: a) los miembros del consejo de administración no siempre actúan como una piña sino que pueden usar los proyectos para atacarse unos a otros, b) los altos mandos rara vez pueden defender a los operativos de las malas prácticas de los mandos intermedios esencialmente porque no es fácil reemplazar a los mandos intermedios indeseables, y c) cuanto más apoyo ejecutivo -y por ende dinero- recibe un proyecto más visible se vuelve a los ojos de los Nazgull de otras empresas.

2. Dedicación del staff del cliente. A menudo el staff del cliente se encuentra en una situación de sobrecarga laboral en la cual debe por una parte colaborar con los desarrolladores en la definición y validación de nuevos sistemas, y por otra seguir sacando adelante su trabajo diario habitual.

3. Procesos organizacionales. Cualquier empresa que lleva sufientes años en el mercado probablemente ha invertido una gran cantidad de esfuerzo en definir y mejorar sus procesos hasta el punto de que se han quedado grabados de forma indeleble en la mente de los usuarios. Los procesos de cambio organizacional son, en general, muy difíciles y llevan años cuando no lustros de completar, incluso muchas empresas acaban fuera del mercado antes de ser capaces de cambiar.

4. Dispersión geográfica. Ni el SaaS más puro para empresas puede librarse de al menos un recurso que se necesita de forma casi lineal con respecto al crecimiento de la base de usuarios: el soporte. Muchos pequeños proveedores de software no están preparados para instalar su producto en grandes empresas aunque el producto sea idóneo y funcione bien carecen de la capacidad para movilizar suficientes recursos de postventa. Si las sedes del cliente están geográficamente dispersas el esfuerzo en formación y soporte se incrementa todavía más. No quiero sugerir con lo anterior que el software como servicio no suponga ninguna diferencia, sí la supone, por ejemplo, uno de los factores claves del éxito de Salesforce fué su capacidad diferencial para desplegar apliaciones de CRM para equipos dispersos.

5. Normativas y KPI. En una gran empresa cada departamento tiene sus propias normativas y Key Point Indicators en los que basan sus métricas de eficiencia y cumplimiento de objetivos. Aunque el software tenga una misión global, para alcanzarla todavía necesita cumplir con una larga lista de requisitos burocráticos intermedios.

¿Cómo influye la arquitectura técnica?

No es posible, en general, llegar a una gran empresa y pretender que adopte el último grito en tecnología sólo porque sea teóricamente disruptiva. Algunas veces pasa, y ciertamente en los departamentos web hay bastante libertad para incorporar novedades, pero simplemente no se puede sacar algo de una chistera y que el cliente lo use porque es “mágico”. Los arquitectos de software en los clientes piensan de forma holística en términos de plataformas interoperables: ¿Cuánto me costará adoptar esta plataforma? ¿Tengo a gente formada? ¿Cómo haré el mantenimiento diario de sistemas? ¿Qué pasa si algo funciona de forma defectuosa? ¿Cómo voy a comunicar esta plataforma con aquella? ¿Cuantos años puedo usarla antes de que esté obsoleta?

La SEGURIDAD suele ser una característica deficiente en casi todo el software que se instala en las empresas. Además normalmente hay bastantes restricciones de acceso. Es frecuente que los ordenadores desde los que se ejecutan las aplicaciones empresariales tengan severamente restringido el acceso a Internet (o ningún acceso a Internet). Incluso dentro de la red interna de la empresa es probable que una aplicaciones no “vean” a otras. La electrónica de red, por cierto, puede jugar muy malas pasadas en una red empresarial porque la situación típica consiste en centenares de usuarios enviando correos ballena y moviendo archivos diplodocus sobre una infraestructura física que puede tener hasta una década de antigueadad. En una empresa es muy habitual que el rendimiento de una apliación se vea degradado porque otra aplicación está compitiendo por los mismos recursos (casi siempre la red). Por último, para las aplicaciones que trabajan con los datos más sensibles todo tiene que funcionar con certificados y protocolos seguros que garanticen que la información en tránsito no ha sido espiada ni alterada en modo alguno.

Otra regla del dedo gordo es que no quieres que tu software tenga que llamar a ningún otro sistema. Siempre hay que pelear a muerte que sean los otros sistemas los que le llaman a uno. Esto es debido a que siempre es posible monitorizar las llamadas entrantes y el software propio. Pero si se produce un mal funcionamiento los sistemas de terceros son una caja negra con la que se pueden tardar días o semanas en diagnoticar cualquier cosa tras una discusión interminable con el otro sobre quién tiene la culpa de qué.

¿Cómo diseñar software enterprise?

Los requisitos a priori para que un producto de software enterprise sea vendible son una consecuencia de todos los puntos expuestos anteriormente.

1. Tecnología. Debe estar basado en una tecnología que el cliente no perciba como un riesgo a medio-largo plazo. Además, las empresas de software se fagocitan unas a otras. Por consiguiente, desde el día 1 las elecciones de tecnología base deben hacerse teniendo en cuenta quienes podrían ser los compradores potenciales de la empresa. Esto no necesariamente descarta el Open Source, en Google, por ejemplo, se usa mucho Python. Pero si el objetivo último es Oracle o IBM entonces mejor si todo está escrito en Java.

2. Funcionalidades. Los pliegos de compra de software enterprise contienen casi siempre tantos requisitos que parece que el programa vaya a ser capaz de conectarse con la tostadora de tu casa y prepararte el desayuno antes de que te levantes. Hay un dilema irresoluble con respecto a esto: con pocas funcionalidades no se gana el pliego y con muchas el producto es como una navaja suiza útil para todo y buena para nada. Algunos fabricantes han resuelto el problema con una versión “estándar” que contiene lo que funciona, y un conjunto de módulos accesorios con lo que no funciona pero queda bien decir que lo hace el producto.

3. Posicionamiento. El posicionamiento del producto depende del alcance que tenga. Para los productos tácticos que sólo satisfacen una necesidad concreta de un departamento es posible dirigirse directamente a los clientes sin muchas maniobras. Para los productos más ambiciosos se suelen emplear tres tácticas: a) puntuar bien en los informes de las consultoras como Gartner, b) aliarse con socios estilo Accenture o KPMG para que prescriban el producto, c) autoproclamarse sistemáticamente el líder indiscutible en algún determinado nicho. Cualquiera de estas tácticas es costosa. Trabajar con las consultoras que evalúan producto no es barato aunque a veces se puede ahorrar dinero anunciando que se lanzará al mercado justo lo que la consultora pronosticó como tendencia futura a corto plazo. Es peligroso que el roadmap de producto lo condicione un tercero con una tasa de acierto en sus predicciones que no siempre es espectacular. Pero si los clientes también se creen las predicciones entonces se puede salir en el magic quadrant de la consultora y cerrar ventas simultáneamente. Por otro lado, las empresas como Accenture y KPMG lo que buscan es posicionarse como líderes en asesoría de negocio y proyecto en determinados sectores, para lo cual una de las piezas que necesitan es el software. Todos los socios para la implantación son, en general, muy oportunistas y sólo apuestan a corto plazo, pero si se consiguen algunos pocos proyectos exitosos con ellos es posible convencerles de que inviertan más en formar personal de venta, gestión y soporte postventa al software. Por último, aclamarse como el líder indiscutible de un nicho requiere de buenas referencias, una gran pericia en relaciones públicas y no poco gasto publicitario.

4. Precio. Una de las cosas que no se puede buscar en Google es el precio de un software enterprise. Existe un precio de lista que se facilita sólo a los distribuidores pero los fabricantes pueden aplicar descuentos de hasta el 60% según lo que les interese entrar en una cuenta o redondear el cierre de trimestre. La política de precios consiste, basicamente, en cobrar lo que se pueda a quien se pueda.

5. Soporte. El soporte es un área curiosa para mi, porque tiene tanto de gestión de expectativas como de solución real de problemas. Normalmente lo que el cliente quiere es saber qué es lo que sucede y cuándo va a estar arreglado (o no). Pocas veces hay incidencias críticas de verdad. En una ocasión leí una publicidad de una empresa que ofrecía “soporte fanático”, no he vuelto a saber de ellos, probablemente porque cuando los de soporte son unos fanáticos todo el mundo va como loco. Y si hay algo que detestan los clientes corporativos es la incertidumbre. En la mayoría de las empresas de software enterprise hay un departamento de I+D (que va a su puta bola) y un departamento de servicios que son los que tragan con la comida de perro de los de I+D. Yo no soy partidario de la separación radical entre desarrollo y soporte por esta razón enunciada de que los programadores acaban viviendo en una torre de marfil, pero tampoco se puede asignar a una persona simultáneamente a desarrollo y a soporte porque acabará haciendo pobremente lo uno y lo otro.

¿Qué ventajas tiene el software enterprise?

Por lo que he escrito hasta ahora, sé que parecería que uno no desearía caer prisionero del software enterprise ni en su peor pesadilla. Pero no todo es malo respecto de este segmento de la industria de software.

1. Acceso a componentes y procesos predefinidos y testeados. Para muchas aplicaciones simplemente no existe ninguna alternativa libre. Los programadores son técnicos a quienes lo que les gusta resolver problemas técnicos y luego publicar las soluciones para ganar fama, pero muchos de los procesos empresariales son aburridos a morir ergo no les interesan. Faricarse el software a medida uno mismo puede ser mucho peor. Yo he estado en proyectos con más de 300 aplicaciones a medida cada una de su padre y de su madre y eso es un sin Dios.

2. Disponibilidad de un marco de desarrollo común. Cuando se trabaja con varios equipos, posiblemente subcontratados de forma cambiante, es necesario tener un marco de desarrollo común que aporte un mínimo de homogeneidad a las aplicaciones. Los desarrolladores de funcionalidades deben estar, además, lo más aislados posibles del núcleo técnico para que no puedan por error provocar ningún desastre en la base de datos.

3. Acceso a innovación precocinada. Una pega de las herramientas Open Source es que muchas de ellas se distribuyen como un kit de hágaselo usted mismo. Entonces, una parte de lo que se ahorra en licencias hay que gastarlo en configuración y atención diaria de sistemas.

4. Mejor arquitectura. No siempre es el caso porque algunos programas bastante populares son un verdadero truño. Pero normalmente un software enterprise que ha sobrevivido suficiente tiempo en el mercado ha pasado por una serie de versiones en las que ha tenido que evolucionar en función de los requisitos de múltiples clientes en producción. Algunas de las aplicaciones Open Source más rabiosamente de moda son software extraído, es decir, software que se fabricó en una empresa concreta para un propósito concreto y luego se liberó sin demasiados cambios.

5. Continuidad. Esto sólo se aplica a los programas que son tan grandes como para no se blanco de compra de nadie. Las empresas de software empresarial tienen tres opciones de futuro: crecer muchísimo, ser absorbidas o desaparecer. Existen incluso empresas especializadas en gestionar el fin del ciclo de vida de software empresarial obsoleto. A decir verdad nunca se está a salvo. Spring y JBoss se fueron a manos de Red Hat y MySQL acabó nada menos que en manos de Microsoft Oracle con todos los directivos abandonando el barco y Monty Widenius creando MariaDB por su cuenta. Y si el software no es comprado por otro más grande es posible que al proveedor deje de interesarle y no invierta en actualizaciones.

Conclusiones

Existen muchos aspectos a tener en cuenta en el software que no son el lenguaje de programación o la productividad del último grito en herramientas. El software empresarial debe gestionar un complejo conjunto de subsistemas interconectados y debe cumplir con una larga lista de requisitos técnicos y funcionales de los clientes. Todo esto tiene un coste que, unido a lo largos que son los procesos de venta, implica que el precio del software empresarial no puede ser bajo. Por último, es legítimo invertir en innovación y pretender cobrar por ello. Creo que una parte de los defensores a ultranza del Software Libre se equivocan al pensar que todas las licencias de software deberían ser GNU o Apache. El movimiento Open Source surgió como reacción a las prácticas abusivas de venta por dominio de algunos fabricantes y como respuesta a regulaciones absurdas como las patentes de software. Pero no se trata de negar el derecho a cobrar por la propiedad intelectual y el esfuerzo en innovar, testear y distribuir.

Post relacionados:

El ciclo de vida del cliente B2B.
Los nuevos productos y el poder en las organizaciones.
Cómo ponerle precio a un producto software.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Adoptando Sw Libre en una Organización | Deja un comentario

Muerte por agilismo

He perdido la cuenta de la cantidad de empresas que he visitado las cuales, pretendiendo hacer Agile a ultranza, se enfrentan a serios problemas de retrasos en los plazos y falta de calidad en los entregables. La justificación siempre es la misma: que el problema no es Agile sino que no están haciendo Agile bien. Que el problema es que no cierran una release verdaderamente estable en cada sprint o que la descripción de cada tarea en JIRA cabría perfectamente en un tweet, o que los tests son insuficientes, o cualquier otra excusa justificando la disfuncionalidad en base a una falta de ortodoxia. Pero es falsa la creencia extendida de que más Agile arreglará los problemas de una empresa con dificultades para producir versiones estables dentro de los plazos estipulados. A renglón seguido contaré la historia que nos ha traído a la situación actual. Me ha quedado un post algo largo, pero prometo al lector paciente que es todo “lean”, sin circunloquios ni banalidades.

Agile nace gestado por la Primera Burbuja Punto.com

Agile nació poco después de que creciese la Primera Burbuja Punto.com. Agile apareció como una metodología para que las consultoras pudiesen gestionar de alguna forma su relación con clientes que no sabían exactamente lo que querían. Agile no se inventó durante la década de los sesenta para el Programa Apolo porque la misión era poner a un hombre en la Luna antes del 1 de enero de 1970. No necesitaban una sucesión de lanzamientos con mejora contínua de los resultados. Sí necesitaban, en cambio, nuevas herramientas como IBM IMS para gestionar el inventario del Saturno V o las metodologías estilo Waterfall de los 70 que siguieron vigentes durante muchos años tras su invención. Pero en el año 2000, con clientes que no sabían ni a qué planeta querían llegar o, peor aún, cambiaban el planeta de destino según avanzaba el proyecto, era muy difícil hacer un inventario de necesidades y presupuestarlas. Entonces se inventó algo para facturar al cliente no una cantidad fija por proyecto cerrado sino por “time & materials” (horas/hombre y cualquier otro coste imputable) sin límite presupuestario. Obviamente, si el cliente pagaba por horas en lugar de por resultados era necesario demostrarle que los programadores estaban trabajando de la forma más eficiente posible. Y de ahí surgieron todas las prácticas ágiles para optimizar la productividad de los programadores exprimiéndoles como cítricos.

Agile emigra a las grandes corporaciones

Aproximadamente un lustro después de que las consultoras introdujesen Agile, los gestores de proyectos de los clientes empezaron a pensar que si la metodología funcionaba tan estupendamente para las consultoras entonces funcionaria igualmente bien para los proyectos internos de la compañía. Como las grandes empresas cambian despacio, les llevó aproximadamente otros cinco años, hasta 2010, entrar de lleno en la cruzada por el agilismo.

Fué en este momento cuando se empezó a complicar la cosa. No es lo mismo hacer un proyecto táctico para un departamento de una gran corporación que un megaproyecto de transformación empresarial de gran calado. Las consultoras web muy a menudo trabajaban para directores de desarrollo de negocio que estaban frustrados con la lentitud de su servicio de informática interno respecto de la velocidad que había tomado el mercado. Querían soluciones rápidas de negocio, y no les importaba si estaban bien o mal integradas con el resto de los sistemas de la casa. Sólo buscaban correr para no perder el tren de Internet. Agile primaba la entrega sobre la calidad, porque la consultora tenía un tiempo de vida limitado para conseguir algún éxito rápido antes de que les cancelasen el proyecto o fuese absorbido por el departamento de informática del cliente. Pero a un mando intermedio de una gran empresa casi nunca le conviene priorizar la entrega sobre la calidad por dos motivos: a) vive permamentemente en competencia por el ascenso con otros mandos quienes están siempre pendientes para descubrir dónde se ha equivocado; y b) a las empresas les cuesta tanto cambiar organizativamente que la velocidad de desarrollo no es casi nunca un cuello de botella. Es más, el tiempo de codificación sólo supone, como mucho, el 30% o el 40% del tiempo de trabajo de un programador. Al obcecarse con reducir el tiempo de programación se optimiza sólo el 30% del tiempo y no se hace nada respecto del otro 70%. Entonces, el cliente puede acabar pagando “time & materials” de programadores quienes, siendo muy eficientes en su labor, pasan no obstante una fracción significativa de su tiempo esperando.

Se eliminan los gestores de cuenta

Los vendedores y gestores de cuenta en las consultoras provocaban con frecuencia el siguiente problema serio: en un caza de combate el piloto puede normalmente hacer sólo tres o cuatro maniobras de alta velocidad antes de agotar su reserva de combustible y tener que volver a la base. Análogamente, los gestores de cuenta tenían tendencia a pulsar el botón que activaba la postcombustión cada vez que se veían al borde de ganar o perder una cuenta porque les faltaba esta o aquella funcionalidad en el producto. Esto dejaba a los programadores quemados y agotados y encima con frecuencia no servía para lograr los objetivos comerciales deseados. Tras una serie de motines de los programadores, la solución fue quitar el poder a los gestores de cuenta para dárselo a los programadores.

Se decidió que los programadores debían hablar directamente con los clientes, ya que los gestores de cuenta entendían y trasladaban mal los requisitos. Y que los programadores debían auto-organizarse fijando sus propios objetivos y estimaciones. ¡Bien! ¡Poder para el pueblo!

Se decidió también que los programadores podían programar y reunirse con los clientes al mismo tiempo. De todas formas si no se reunían con el cliente se tenían que reunir con el gestor de cuenta lo cual es casi lo mismo ¿no?

De nuevo, esto funcionó bien para las consultoras. Más horas hablando con el cliente estrechaban el vínculo emocional con él y proporcionaban más información a la consultora para hacer venta cruzada.

Pero ¿qué pasó en los grupos de trabajo de los clientes? Bien. Lo que sucedió fué básicamente que Agile tomó el control estratégico de la empresa. En lugar de un equipo directivo fijando la visión y misión y un equipo operativo tratando de ponerla en práctica, la empresa pasó a estar gobernada por un grupo de ejecutivos desvalidos que mendigaban al cognitariado agilista si era posible hacer esto o aquello. Cualquier intento de dirigir la empresa fuera de los límites de Agile era vaticinado como una hecatombe segura por el Oráculo Agile. Y así Agile pasó a convertirse en una cuestión de fé.

Respecto de la comunicación, si las empresas ya estaban saturadas de reuniones, Agile potenció todavía más reuniones. Y además introdujo la idea de que los usuarios pueden (y deben) crear las historias “de usuario”. El problema es que los usuarios carecen normalmente de formación en diseño estructurado de sistemas y, por consiguiente, no pueden crear una especificación de calidad porque nadie les ha enseñado cómo hacerlo. Tienen un conocimiento experto de su negocio, pero necesitan coaching de un analista-programador para plasmar dicho conocimiento en un papel.

Se veta a los senior

Una consultora obtiene beneficios de la diferencia entre lo que le cobra al cliente y lo que le paga a sus empleados. Por consiguiente, una consultora rentable es, por definición, una horda de juniors. No todas las consultoras son así, por supuesto, algunas son boutiques de un puñado de verdaderos expertos, pero si la consultora tiene más de 10 empleados entonces el 80% de ellos son junior porque las consultoras existen tanto para hacer lo que el cliente no sabe hacer como para que éste les lance toda la basura que no quiere procesar.

Los senior tienen mala cabida en una metodología Agile. No da tiempo en un único sprint de producir un buen análisis o una arquitectura de software para un proyecto complejo. Además, la presión constante por alcanzar el sprint abona el terreno a peligrosísimos errores de diseño. Agile microgestiona a los senior obligándoles a acudir a reuniones diarias de control. Y es fácil eliminar miembros de alto potencial identificándoles falsamente como de bajo rendimiento simplemente porque no siguen a pies juntillas los sprints por absurdos que estos sean.

Un cliente con sistemas de información complejos quiere personal senior entre sus empleados. Quiere arquitectos capaces de aprehender todas las interacciones sutiles entre una miriada de sistemas de información y de adquirir una visión holística desde el alto nivel de las necesidades de negocio hasta los detalles de la electrónica de red. Esto simplemente no casa con Agile.

Se introducen métricas envenenadas

Junto con Agile, se introdujeron ciertas “prácticas Agile”. Algunas ya existían previamente con otro nombre, estilo las retrospectivas antaño conocidas como post-mortems, excepto que el nombre era muy tétrico y por eso se cambió y se le añadieron al método algunas viñetas graciosamente elocuentes.

Algunas prácticas fueron definitivamente un avance: Domain Driven Design, Integración Contínua, Refactorización, etc. Otras introdujeron caballos de Troya.

El primer troyano fueron las Historias de Usuario. En la época del diseño estructurado se abogaba por estimar el esfuerzo requerido usando métricas como los Puntos Función o la Complejidad Ciclométrica. Los puntos función, básicamente, consistían en medir la complejidad de los datos de entrada y los datos de salida y estimar que el esfuerzo requerido para desarrollar un programa sería proporcional a la complejidad requerida para manipular los datos. Algunas empresas como IBM llegaron a poder producir estimaciones muy fiables para determinado tipo de proyectos con estas métricas. Pero en las Historias de Usuario no se trataba tanto de estimar el esfuerzo requerido como el valor que aportaría al cliente la funcionalidad. Esto era debido a que la consultora estaba interesada en cobrarle al cliente no por su coste de producción más un márgen sino por el valor añadido. Hablando de valor y no de coste se evitaba que el cliente dejase a la consultora cobrando “time & materials” más un 15%. Pero en los proyectos internos en grandes empresas el valor que añade cada funcionalidad es mucho menos relevante puesto que las grandes empresas casi siempre operan en oligopolios que pueden repercutir sus sobrecostes a los clientes. Lo que sí es crucial es saber cuándo estará terminado y qué hará, debido a que puede que se avecine una campaña de Navidad o una salida a bolsa. Pero ese ¿cuándo? y ¿qué? es justamente lo que NO garantiza Agile. En cambio, la sucesión interminable de releases incompletas lo que acaba generando es una profunda desazón en los usuarios y patrocinadores quienes empiezan a tener la sensación de que el proyecto no estará terminado nunca.

El segundo troyano fue Test Driven Design (TDD). No es que TDD sea para nada malo en sí mismo. De hecho, ningún programador profesional hoy en día escribe código sin un juego de tests que lo acompañe y eso es por muy buenos motivos demasiado largos y técnicos para enumerarlos aquí. El problema de TDD fué que generó la idea de que el código estaba “listo” cuando estaba “listo para lanzárselo a control de calidad” como quien pasa una patata caliente. Si pasaba los tests entonces el código funcionaba, fin de la historia. La mil veces repetida excusa de los programadores “en mi PC funciona” pasó a ser “pasa los tests”. Gracias a la integración continua, todas las máquinas virtuales podían tener fácilmente la misma configuración, luego ya no sucedía que funcionase en una si y en otra no, pero pasar los tests no implicaba que el programa hiciese en absoluto lo que el cliente esperaba que hiciese, pues, cómo ya hemos explicado anteriormente, quién había redactado la historia de usuario no sabía explicar exactamente lo que necesitaba. De postre, los tests escritos por el programador nunca incluyen pruebas de carga, puesto que son muy tediosas de escribir y además bloquearían el sistema de integración continua. De modo que incluso si el software funciona en producción lo hace a la velocidad de un trasatlántico a pedales.

El tercer troyano fueron los Product Backlogs. Estos priorizaban la aceptación de cambios y el desarrollo sobre la planificación. La forma en la que un backlog fuera de control aniquila un proyecto la describí en otro post titulado lo que sucede cuando un software se convierte en un agujero negro, de modo que no voy a extenderme aquí sobre este punto.

Se arregla Agile con más Agile

Como corolario de todo lo anterior, la situación típica es una de las siguientes:

a) Si la empresa es pequeña, el CEO ha caído prisionero de los programadores. Cada vez que intenta pedir algo, los programadores le responden que debe conseguir más recursos, o más inversión ¡o traer menos clientes! porque no les da tiempo de atenderles.

b) Si la empresa es grande, hay una gran cantidad de proyectos bloqueados a la espera de que un tercero entregue algo. El proyecto avanza, pero lo hace a una velocidad exasperantemente lenta y no exenta de sobresaltos.

El diagnóstico siempre es invariablemente el mismo: no se está haciendo Agile correctamente. Pero ¿quién puede hacer Agile correctamente? y… ¿de qué manera? si ya se ha intentado todo y se han mantenido sempiternas reuniones.

Entonces ¿Cómo salvar el proyecto?

1. Se deja de esperar a que los usuarios produzcan ninguna especificación. En cambio, se asignan analistas para trabajar con ellos en la producción conjunta de especificaciones.

2. Cada sprint durará lo que tenga que durar. ¿Por qué dos o tres semanas? Tampoco seis meses, para evitar los sustos que daba Waterfall. Puede haber puntos de control intermedios, pero si se necesitan ocho semanas para producir algo estable, se necesitan ocho semanas, y no cuatro sprints de dos semanas.

3. Se resucitan los Gantt, si ¡horror! Se restituyen los análisis de caminos críticos que muestren quién está bloqueando a quien y dónde. Se instalan pantallas gigantes que muestren en tiempo real el grado de progreso del sprint, los retrasos acumulados, el estado de los tests de integración y la actividad de usuarios en producción.

4. Se para en seco la aceptación de nuevas funcionalidades hasta que se estabilicen por completo todas las que hay. Es decir, desde mañana y hasta nuevo aviso los cambios NO son bienvenidos en la planificación del proyecto.

5. La decisión sobre la fecha de release pasa al departamento de control de calidad. Será este, de común acuerdo con los usuarios, quien valide que el software producido cumple con los requisitos.

6. La misión de sprint es cumplir expectativas. Al cuerno con la verborrea sobre valor añadido al negocio o restricciones técnicas insalvables. No se acepta ninguna excusa técnica ni organizativa en el último minuto para justificar por qué el cliente no obtendrá lo que esperaba obtener.

7. Cada programador arregla los bugs que él mismo haya introducido. Además, no gozará de más tiempo sobre el que tuviera pre-asignado a sus tareas. El programador no sufrirá penalización salarial ni de carrera profesional por un bug, pero tendrá que arreglarlo haciendo horas extra no retribuidas.

8. Se diseñan informes que muestren claramente cuánto tiempo se está dedicando a : desarrollo, corrección de bugs, soporte a cliente y reuniones. En la contabilidad analítica se diferenciará claramente el coste de producción del coste de soporte.

9. Quedan abolidas las reuniones. En lugar de una metodología que fomente que la gente se reuna y hable con la mayor frecuencia posible, se intenta que los programadores tengan que ir al mínimo número de reuniones. Como máximo una por semana. No se puede ser creativo y explicar lo que se está haciendo al mismo tiempo. El daily se substituye por un chat online donde todos los programadores y gerentes puedan acceder de forma inmediata a cualquier otro miembro del equipo en caso de necesidad urgente.

10. Los programadores son obligados a documentar lo que están haciendo. Si bien no están obligados a estar cada dos por tres de pie en una sala, sí deben mantener actualizado un repositorio documental con el progreso y detalles de todo su trabajo ya que no existe tal cosa como el código autodocumentado. La herramienta puede ser JIRA, Redmine, un wiki o incluso un blog donde los programadores compartan sus progresos en lugar contarle a nadie lo que están haciendo o enviar un mail a una lista y crear un hilo interminable. Evitar las reuniones no implica desinformarse. El desafio es mantener a todo el mundo informado sin necesidad de mantenerlo permanentemente reunido.

11. Se añade una capa de metodología de optimización global sobre Agile.

12. Se decreta la Anarquía de los Programadores. Podrán reirse a carcajadas de una decisión. Podrán ser sorprendidos trabajando en cosas aparentemente no relacionadas en absoluto con el proyecto. Podrán soñar con dragones.

Posts relacionados:
Las zonas grises de Agile.
Cheat Sheet de marrones en un proyecto.

El oportunismo del agilismo (Luis Lobo).

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

Sobre la dinámica social en los sitios de dating

He estado tentado de titular este post cómo ligar en sitios de dating. Mucha gente busca una relación estable o casual. Pero a mi lo que me interesa es el uso social de la tecnología para conocer gente, concretamente del sexo opuesto en el caso de los sitios de dating.

Opinions on Online Dating 2005 vs 2013¿Funcionan realmente los sitios de dating? Bien, no existen pruebas científicas a favor o en contra. Yo creo que sí funcionan. La razón es que si no funcionasen entonces no habrían sobrevivido más de una década ya desde sus inicios. A principios de 2016 un 5% de los norteamericanos casados o en una relación estable reconocían haber conocido a su pareja online. Según PEW Research Centre el número de adultos usuarios de los sitios de dating se ha duplicado entre 2014 y 2016. El gráfico muestra cómo la opinión de los usuarios se ha vuelto más favorable de 2005 a 2013 Pero ¿funcionan los sitios de dating con efectividad? Eso seguro que no. Y a continuación explicaré algunas causas de su ineficiencia.

El mito de Mr. Right

Boyfriend Application FormFué Cortázar quien escribió: “Lo que mucha gente llama amar consiste en elegir una mujer y casarse con ella. La eligen, te lo juro, los he visto. Como si se pudiera elegir en el amor, como si no fuera un rayo que te parte los huesos y te deja estaqueado en la mitad del patio”. Y si hay un lugar donde las personas se eligen unas a otras ese lugar son las redes de dating. No está demostrado que exista ningún cuestionario ni check-list que sirva para seleccionar a la pareja adecuada. Varias redes de dating proclaman que tienen algoritmos de matching basados en similitudes de edad, ingresos, profesión, etc. y en tests de personalidad estilo 16PF o MMPI. Pero no hay datos que demuestren que una persona tiene más probabilidades de mantener a largo plazo una relación con otra si ambas son muy similares. Lo que sí parece comprobado es que es falso que los polos opuestos se atraen. Si uno cocina y limpia y el otro sólo come, probablemente acabarán mal. La relación sin embargo sí puede funcionar cuando hay complementariedad (uno cocina y el otro friega los platos). Según un estudio de la Universidad de Chicago, existe una fuerte afinidad por raza con tan sólo un 4% de matrimonios interraciales en EE.UU. Los caucásicos tienen ligeramente más probabilidades de ser elegidos por la mayoría de las otras razas aunque con importantes excepciones como hindues y coreanos.

Sin perjuicio de lo anterior, existen decenas de sitios especializados por perfiles: casaderos, gays, fetichistas, gorditos, yuppies, hipsters, amish o hasta capitanes de barco.

Amish Dating

Sea Captain

La Paradoja de la Elección

La Paradoja de la Elección es un efecto psicológico que provoca una tendencia a estar menos satisfechos con nuestras adquisiciones mientras más alternativas existan. Es por eso que Tinder tuvo tanto éxito limitando la cantidad de candidatos mostrados. Es mejor hacer una preselección y trabajar con un subconjunto de aspirantes. Probablemente la tasa de abandono de mujeres en Match y Meetic está relacionada con la avalancha de inmails que pueden llegar a recibir.

Factores predominantes en la elección

Según los estudios, los hombres con perfil dominante (machos alfa) puntúan mejor a primera vista aunque no está tan claro que luego sean los preferidos para formar pareja estable. Sin embargo, las fotografías agresivas, mirando de frente a la cámara con cara de pocos amigos, intimidan a las mujeres quienes pueden preferir imágenes de hombres con la mirada desviada en el momento de tomar la imagen. Otro factor comprobado en estudios es que incluir niños en las fotografías incrementa la percepción de atractivo del varón. Es decir, el mismo hombre es percibido como más atractivo en la foto por el mismo grupo de mujeres si aparece un niño a su lado.

En cuanto a las fotografías femeninas, prima la estética. Hombres y mujeres tienen tendencia a mentir en media más o menos por igual en los perfiles, excepto en las fotografías donde las mujeres mienten muchísimo más. Según algunos estudios hasta el 46% de las fotografías femeninas no son fidedignas frente al 11% de poco o nada realistas en los hombres.

Las mujeres aprecian el sentido del humor. Existe una correlacion demostrada entre la cantidad de risa que un hombre es capaz de inducirle a una mujer y la probabilidad de que acaben pasando la noche juntos. El recíproco, sin embargo, no es cierto. Si en un bar se encuentra a un hombre desternillándose de la risa con una mujer probablemente ella acabe volviendo a casa sola.

Aunque prima lo visual sobre lo textual, sobre los textos, tanto hombres y mujeres están de acuerdo en que prefieren información personal y relevante alejada de frases hechas y hobbies comunes. Las personas no conectan tanto por coincidencia en grandes temas vitales como por afinidad en muchos pequeños detalles.

Factores imponderables

Muchos de los críticos con las redes de dating afirman que las cualidades verdaderamente relevantes para estimar la viabilidad de una pareja simplemente no pueden medirse a través de Internet. La más citada es el olor de la otra persona. Parece ser que las personas con sistemas inmunes complementarios se atraen mutuamente. Otros factores como el uso del espacio, la forma de andar o la forma de comer tampoco suelen desvelarse hasta la primera cita. Yo personalmente opino que el factor que mejor sirve para predecir cómo es una persona en la cama consiste en observar qué y cómo come, aunque eso sería otra larga historia muy subjetiva.

Tiempo dedicado a buscar online

Aunque no existen datos proporcionados por los portales, preguntando a los usuarios cuando están activos parece ser que se conectan unas 12 veces por semana durante 22 minutos en cada sesión. Y en Francia en 2015 tanto como un 30% de los encuestados reconocía haber visitado un sitio de dating en los últimos tres meses. Por edades los más jóvenes son el grueso de usuarios seguidos de los más mayores y por último las personas de mediana edad. No está clara cual es la distribución de hombres y mujeres. Cuando se filtró la base de datos de Ashley Madison trascendió que tanto como el 80% de los usuarios eran hombres, aunque otras cifras afirman que la cantidad de mujeres es igual o sólo ligeramente inferior a la de hombres.

Si se examina el modelo de negocio de los sitios de dating es fácil deducir que lo más provechoso para el proveedor es que el uso esté gamificado de tal manera que los usuarios tengan una tasa de éxito lo bastante elevada como para quedarse enganchados pero no tan elevada como para acertar a la primera y abandonar el sitio debido a muerte por éxito.

Timadores

Las redes de dating, como cualquier otro lugar en el mundo, no están exentas de peligro. Se puede encontrar de todo pero los perfiles más comunmente peligrosos son los tres siguientes:

El timador económico. La dinámica de timo más común es contar una historia triste y conmovedora. Al cabo de un tiempo pedir una pequeña cantidad. Por ejemplo, 50€ o 100€ para pagar una presunta factura de la luz. Y por último inventar una gran catástrofe sobrevenida del tipo “tengo a mi hijo en el hospital y no tengo dinero para el tratamiento”. La pequeña cantidad se pide porque es sabido que las personas que ya han hecho una aportación previa tienen más probabilidades de aceptar hacer otra mayor.

El narcisista y el sociópata. De todos los enfermos mentales que se pueden encontrar online probablemente el narcisista y el sociópata son probablemente los más peligrosos debido a que no resulta para nada sencillo detectarlos tempranamente.

El irresoluto. Este último no es un tipo realmente peligroso. Sólo hace perder el tiempo. Uno de cada tres usuarios de las redes de dating afirma que nunca ha tenido una cita en la vida real. Algunas personas quedan online porque sólo quieren quedar online.

Desvirtuación de otras redes sociales

No sólo se liga en redes de dating. Cada vez son más los usuarios de LinkedIn que se quejan de lo poco profesional que se ha vuelto la red en una deriva hacia perfiles cool del estilo de A Small World. Conozco al menos un caso de alguien que abrió una cuenta de Twitter sólo para compartir fantasías sexuales. Y también es común entre los gamers que una relación que comienza matando bichos en un mundo virtual evolucione hacia unas tapas en un bar. En Facebook los anuncios de sitios con énfasis sexual estan prohibidos lo cual incluye anuncios de sitios de dating que muestren fotos provocativas.

Ad Pictures

Conclusiones

Como en tantas otras áreas de innovación, la tecnología ha evolucionado más rápido que la capacidad de los usuarios para adaptarse a ella y todavía existe un largo camino por recorrer tanto en el funcionamiento de los servicios como en el aprendizaje de los usuarios para sacar el mejor provecho de ellos. Aunque todavía representa un porcentaje minoritario como medio de establecimiento de relaciones, el dating online está creciendo como mucha fuerza especialmente entre los más jóvenes. Una evolución que a mi personalmente no me parece ni intrínsecamente buena ni mala sino una consecuencia inevitable de la globalización de un mundo en el que nos relacionamos cada vez menos por proximidad geográfica y más por afinidad en otros parámetros.

Un estudio analiza qué funciona para ligar en Tinder (Daniel Mediavilla)

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Publicado en Usos sociales de la tecnología | Deja un comentario

Tax Loans

Leo en eldiario.es un certero artículo de Marta Sofía Ruiz aclarando la diferencia entre el EBITDA y el beneficio real en las empresas. Trata sobre la esencia del mecanismo principal para evadir impuestos legalmente en la actualidad.

Los impuestos se recaudan por la diferencia entre ingresos y gastos (no tendría sentido intentar cobrarle a alguien que tiene muchos ingresos pero ningún beneficio). Los gastos incluyen costes financieros (intereses). Entonces una forma de reducir el beneficio (aka no pagar impuestos) es tener una enorme deuda y, por consiguiente, muchísimos costes financieros. He aquí la clave que comenta el artículo de eldiario.es: las punto com son empresas cuyo EBITDA es positivo (ergo cotizan al alza en bolsa) pero en el cierre contable después de intereses e impuestos arrojan pérdidas (ergo no pagan impuestos).

Se trata de una regulacion legal perversa mediante la cual, aunque tengas mucho dinero, lo más eficiente fiscalmente es estar endeudado. Es por eso que incluso las empresas que tienen cantidades ridículamente altas de caja mantienen deuda.

El patrón no se aplica sólo a las empresas. En el Reino Unido, desde hace ya casi una década, y en España según se ha descubierto tras los papeles de Panamá, existe mucha gente que cede sus ingresos a cambio de una renta. En la jerga legal británica se conoce como los tax loans. El mecanismo es como sigue: tú eres autónomo, y vas a firmar un contrato, supongamos de 200€/día por 6 meses. A 22 días por mes igual a 26.400€ de ingreso bruto (más IVA). Entonces haces lo siguiente: pides un préstamo por 20.000€ a una empresa off-shore con un interés del 10% anual. Como garantía de este préstamo pones tu nómina pero de manera que tú nunca llegues a percibir el ingreso. Es decir, el cliente debe pagarle a la off-shore directamente. Fiscalmente, tienes una deuda de 21.000€ (20.000+intereses) y la off-shore debe de reconocer el ingreso pero como está radicada en un paraíso fiscal no tributa. Para que el trabajador tenga cobertura en la seguridad social, la off-shore subcontrata a una empresa en el país que le paga al sujeto pasivo un salario muy bajo, pongamos por caso 20€/día. El resultado neto es un coste real entre el 15% y el 18% para el (no)contribuyente. Puede que ni siquiera se aplique el IVA ya que la venta de servicios entre países intracomunitarios está exenta. Y es todo “legal”. O más bien “legal” sobre el papel. Pues existe un principio de derecho que establece que las cosas son “lo que son” y no “lo que las partes dicen que son”. Es por esto que un juez puede limpiarse el trasero con una carpeta de facturas por muy “legales” que sean si en realidad no se corresponden con ningún producto o servicio real o se emitieron con el único fin de eludir el pago de impuestos.

En el Reino Unido le han dado a los listillos de plazo hasta 2019 para dejar en cero sus tax loans y están tratando de llegar a acuerdos negociados de amnistía fiscal (pagando el 10% y esas cosas…) para evitar difíciles batallas judiciales con los implicados ya que con la ley actual no está claro que Hacienda pueda ganarles en un juicio. Algunos tienen un serio problemilla porque, puestos a endeudarse a costa de la nómina, pidieron un préstamo para el Jaguar, el ático en la costa y los costes del divorcio, y, claro, ahora el HMRC (la AEAT en UK) les reclama una cantidad en decenas de miles que no tienen en la cuenta bancaria. Y como llevan haciéndolo años están dentro del rango de delitos fiscales punibles con cárcel. Sin embargo, no llegará la sangre al rio porque hay tanta gente pringada a todos los niveles que a nadie le interesa que se destape todo el cotarro.

La raíz del problema, no obstante, es un sistema fiscal inapropiado donde las personas jurídicas están obligadas a una presión fiscal excesiva. Debido a que no se pueden poner puertas al campo en una economía globalizada, el impuesto de sociedades debería estar siempre por debajo de los costes financieros. Esto implicaría dejar dicho impuesto en una horquilla entre el 3% y el 5%. Ya sé que esto suena completamente impopular ¡Mosquis! ¿No sería eso acaso reducir la presión fiscal sobre los multimillonarios y sus grandes empresas? Pues no. Resulta que el beneficio de una empresa no es de nadie. Bueno, es de la empresa, pero ese es el dinero que la empresa tiene para crecer y generar empleo. Gravándolo al 35% lo único que se consigue es que a las empresas les resulte más rentable estar perennemente endedudas, con el consiguiente riesgo que eso acarrea. El único momento en el que se debería fiscalizar el beneficio es cuando se reparte entre los accionistas bien sea via nómina, dividendos o retribución en especie. Por último, mantener una empresa (o a uno mismo) permanentemente endeudada hasta las trancas es peligroso pues pone a la empresa a merced de los acreedores (bancos y otros aún más fieros) en el caso de que se desplomen los ingresos por causas impredecibles.

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

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