Qué hacer cuando se va un programador

Hace años conocí a un emprendedor cuyo responsable técnico era conocido cómo “El Hechicero”. Al parecer todo el mundo en la empresa pensaba que lo que aquel programador hacía era Magia Negra. Por consiguiente, es predecible que el aviso de su baja voluntaria causase cierta ansiedad respecto del futuro. En este post explico cómo paliar los efectos indeseables de la pérdida de conocimiento que acarrea la marcha de un trabajador con conocimientos únicos.

El proceso de transición

Para empezar, nadie es irremplazable. Creo que en treinta años nunca me he encontrado ninguna empresa que quebrase porque se marchó un programador. Si se marcha un equipo entero la situación puede ser más peligrosa, pero sobre eso escribiré más adelante. Es decir, ante todo: calma. Lo cual no implica ignorar el suceso y no hacer nada en absoluto al respecto.

A continuación, yo recomiendo la siguiente secuencia de pasos:

1) Hacer una lista de los conocimientos, competencias y responsabilidades diarias que tiene la persona que se marcha. Estimar cual es la curva de aprendizaje de los conocimientos y cuánto tiempo dedica la persona a cada tarea rutinaria a su cargo.

2) Decidir quién se hará cargo de las funciones asignadas a la pesona que se marcha. Puede que sea otra persona de la empresa, o un departamento, u otro empleado a contratar o un proveedor externo. O una combinación de todo lo anterior.

3) Enumerar y producir la documentación que será necesaria. Esta documentación debe incluir, cómo mínimo:

• Especificaciones funcionales.
• Arquitectura y diseño del sistema.
• Modelos y flujos de datos.
• Manual de operación diaria del sistema.
• Procedimientos de despliegue.
• Procedimientos de pruebas.
• Lista de defectos software conocidos y funcionalidades pendientes de implementar.

4) Recopilar todas las credenciales de las que dispone el causante de la baja. Y acordarse de cambiarlas o cancelarlas inmediatamente en cuanto se haya ido.

5) Diseñar un plan de transferencia de conocimiento. Este plan debe incluir, al menos:

• Producir toda la documentación necesaria.
• Llevar a cabo sesiones de formación con quien vaya a asumir la responsabilidad. Idealmente todas estas sesiones deben ser registradas y grabadas en video.
• Realizar ejercicios prácticos de mantenimiento del sistema con quien vaya a encargarse del mismo.

6) Hacer un inventario del código fuente. Debe haber un hito formal de traspaso del código. Conviene llevar a cabo este paso concienzudamente porque los programadores que llevan mucho tiempo trabajando en solitario tienden a ser nefastos en su sistema de control de versiones.

7) Informar a los compañeros de trabajo, inversores y clientes. Los compañeros necesitan saber que la persona que se marcha debe estar dedicada 100% al plan de transferencia de conocimiento y que, por consiguiente, durante la etapa de transición no puede asumir ninguna otra tarea. Los inversores necesitan saberlo para ajustar sus expectativas. Puede que tengan que poner más dinero debido a la pérdida temporal de eficiencia o que tengan que esperar más tiempo hasta la próxima release. Comunicárselo a los clientes puede ser bastante más peliagudo. Yo he visto clientes amenazar con cancelar un contrato si se iba una determinada persona. Es por eso que conviene notificárselo al cliente sólo cuando esté perfectamente definido el plan de transición.

8) Ofrecer al empleado una referencia profesional justa y equitativa con respecto al trabajo que ha realizado. Algunas empresas se niegan a proporcionar ningún tipo de información acerca del desempeño profesional de ex-empleados incluso a petición de este mismo. Yo no entiendo bien por qué hacen eso. Puede que piensen que así no proporcionan información de valor a la competencia, o que no quieran asumir responsabilidades. En cualquier caso, las referencias profesionales tienen un peso importantísimo en el mercado laboral. Por tanto, negárselas a un ex-empleado es un acto poco ético. Los ex-empleados pueden ser una fantástica fuente de buenos clientes. De hecho, una parte de la estrategia comercial de las consultoras es colocar gente en los clientes para que en el futuro pidan ofertas de servicio a la misma consultora que antaño les empleó.

9) En algunas ocasiones existen cláusulas de no competencia según las cuales un ex-empleado no puede irse a trabajar a una empresa competidora ni crear su propia empresa relacionada con el trabajo que tenía. Aunque algunas empresas son muy agresivas en sus amenzadas, estas cláusulas son difíciles de ejecutar en la práctica a menos que exista un robo muy claro de activos intelectuales o que el ex-empleado reciba una pingüe retribución por no trabajar en absoluto durante un tiempo.

10) Organizar una fiesta y regalarle algo al que se va es una buena idea. Todo fin necesita un funeral, preferiblemente alegre.

Bajas conflictivas

Los conflictos más comunes en las bajas voluntarias son la extorsión y los motines.

La extorsión más habitual es cuando el programador intenta secuestrar una parte del código o del conocimiento y pide un rescate al empleador. Esto simplemente es ilegal. Según la ley, a propiedad intelectual de todos los trabajos realizados por un empleado en horario laboral pertenece al empleador. Por consiguiente, un empleado o proveedor no puede exigir una cantidad de dinero adicional a cambio de entregar el código. Negarse a entregar el conocimiento es igualmente un acto delictivo ya que supone causar un daño económico premeditado a la empresa por el cual esta podría demandar una compensación.

El montín es una forma superlativa de extorsión. Se produce cuando un grupo de empleados amenaza con marcharse en bloque a menos que la empresa modifique sus condiciones laborales. No pretendo defender la explotación laboral. Las huelgas se inventaron por razones perfectamente justificables. Incluso en el sector informático que, teoricamente, debería ofrecer buenas condiciones para los trabajadores, hay empleados en condiciones bastante precarias e injustas. Pero una cosa es una huelga y otra considerar la oferta de un competidor hostil que pretende comprar un equipo entero a golpde talonario para liquidar a la empresa atacada. Este tipo de maniobras suelen terminar mal para todos. Para el atacante porque en definitiva está contratando a una banda de traidores. Y para los amotinados porque es muy común que una vez logrado el objetivo de defenestrar a la empresa atacada, el atacante pretenda reducir costes reemplazando a los amotinados por otros recursos humanos más baratos.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Bookmarks
Publicado en Entorno laboral, Tecnología y Empleo | Deja un comentario

Errores que comenten los programadores novatos

Llevo suficientes años programados cómo para acordarme de cuando había que escribir programas re-entrantes en ensamblador de 8 bits. Afortunadamente la programación ha progresado muchísimo desde entonces. No obstante, hasta las mejores herramientas pueden usarse mal, cómo cuando se pone un mono a los mandos de una excavadora. El agravante en desarrollo de software es que a la inexperiencia se suele sumar la inagotable arrogancia de muchos programadores la cual debería ser sorprendente en una profesión dónde se piensa que las opiniones son cómo los culos (todo el mundo tiene uno) hasta tal punto que es muy probable que cierren un comentario en Stackoverflow sólo por escribir «yo opino que…». Voy a enumerar algunas de las malas ideas que he ido viendo a lo largo del tiempo, no necesariamente en orden de importancia.

Errores de diseño

• Si te pones a desarrollar un sistema sin haber pensado previamente de forma concienzuda sobre su arquitectura entonces es que probablemente estás trabajando en algo que tendrás que tirar a la basura.

Si descubres una solución nueva a un viejo problema es que probablemente no has entendido bien todas las sutilezas del problema. En esto son legendarios los desarrolladores de frameworks JavaScript todos los cuales empiezan y terminan igual: con un “¡Hola Mundo!” que parece super güay pero que a la postre muta en un amasijo críptico de comportamiento oculto ad-hoc y mal documentado.

Los lenguajes de scripting con tipado dinámico no se inventaron para escribir sistemas de producción. Son cómo si un día se te rompe un bolígrafo y lo arreglas con pegamento. Entonces te maravillas de lo rápido y eficaz del resultado y decides que los ladrillos del nuevo tabique que estás poniendo en tu casa los vas a unir con pegamento también.

Los frameworks no son una solución mágica, con frecuencia acaban causando más problemas de los que solucionan. Un problema de sufren muchos programadores jóvenes es que no les interesa nada que no puedan aprender en un fin de semana. Ven un tutorial de Java y cómo no se aclaran con la configuración de Tomcat entonces deciden pasarse a Node.js porque es en apariencia más sencillo. Incluso si se quedan con Java, deciden usar Spring Boot porque todavía no saben cómo levantar un Tomcat embebido en el proyecto de desarrollo. Pero estos atajos sólo son una forma de diferir una curva de aprendizaje que tendrá que ser superada igualmente más adelante.

Problemas de rendimiento

La escalabilidad por diseño es un buen comienzo pero no se puede saber cómo de escalable es un sistema al menos hasta que se prueba un prototipo con una infraestructura y carga lo suficientemente similar a la del entorno de producción. Las pruebas de carga y rendimiento que no se pueden mapear a indicadores de negocio sirven de bien poco. En un benchmark lo que importa son las transacciones por segundo, el tiempo medio de servicio y la latencia en el peor caso.

Que una subrutina parezca muy sencilla y elegante no implica en absoluto que se ejecute de forma eficiente. Durante años la tendencia en los lenguajes de programación ha sido hacia incrementar la diferencia entre lo que el programador escribe y lo que la máquina ejecuta realmente. Últimamente parece ser que hay un cierto retorno a aproximarse de nuevo al hardware con lenguajes como Rust o Go.

Defectos de codificación

Ocultar la complejidad no la reduce. Si tu mando de la tele tiene 20 botones y metes 15 debajo de una tapa para que parezca más sencillo de usar, entonces no estás ayudando realmente al usuario, sólo estás haciendo que se pregunte dónde rayos está el botón que necesita. Análogamente, externalizar el comportamiento de un sistema en un fichero XML no reduce su complejidad, puede que aumente la distinción entre lo que es el algoritmo y lo que es su parametrización, lo cual es bueno, pero no simplica la solución al problema.

Lo más difícil cuando tienes que mantener código legado es averiguar qué tenia en la cabeza el programador cuando lo escribió. El código “autodocumentado” explica lo que hace pero no por qué lo hace así. Hay un consejo de Dave Carhart en el cual recomienda escribir código cómo si el que lo fuere a mantener sea un psicópata homicida que conoce la dirección de tu casa.

Los mejores programadores escriben código que es aburridamente narrativo. Cualquier programador puede escribir código que la máquina ejecute correctamente haciendo uso de las funcionalidades incluidas en la última version del lenguaje. Lo difícil es escribir código que un humano pueda “ejecutar” mentalmente. Hace un par de meses un programador veterano me dijo: “lo que no me gusta de los programas escritos en Java es que se componen de centenares de clases que indivicualmente no hacen prácticamente nada”.

Los mapeadores objeto-relacional no son excusa para que no aprendas SQL. La razón es que empezarán a generar el SQL por ti y cuando salgas a producción no tendrás ni idea de lo que está haciendo tu aplicación realmente con la base de datos.

Ponerse a refactorizar un código que no se conoce bien es un craso error. La razón es que ese horrendo código espagueti que te han asignado mantener no empezó siendo un espagueti. En realidad el programador que lo escribió originalmente era un tipo bastante capaz excepto que al principio no conocía bien los entresijos del problema, luego, según le llegaban incidencias y lo depuraba lo fue parcheando para cubrir todos los casos particulares pero nunca tuvo tiempo de refactorizarlo él mismo. Cada IF metido a capón en medio del código es una pizca de conocimiento que no figuraba en las especificaciones originales. Entonces si lo cambias de arriba a abajo por las buenas estás inexorablemente avocado a repetir todos los mismos errores que el programador que te precedió.

Fallos en las pruebas y monitorización

Los logs son una forma paupérrima de monitoriar el funcionamiento de un sistema. La trazablidad de un sistema debe ser parte de su diseño. No es que los logs sean supérfluos, todo lo contrario. Pero volcar todo lo que va pasando en un archivo de texto te acarreará muchisimo trabajo posterior de escribir y mantener expresiones regulares para extraer la información y mover los archivos de un lado para otro.

Ningún juego de tests puede reemplazar a la evidencia estadística de horas de funcionamiento libre de fallos en un sistema. Enhorabuena si eres un fanático del TDD, pues te ahorrarás muchas horas depurando tu propio código. Pero que un software pase un juego de pruebas no implica para nada que esté listo para ir a producción.

Sólo el mayor de los ingénuos espera que los usuarios proporcionen las entradas correctas al sistema. Las entradas no sólo no serán correctas sino que serán literalmente cualquier mierda.

Ninguna red es fiable. El protocolo TCP/IP está diseñado para trabajar con una tasa permanente de errores de transmisión. Si diseñas tu aplicación basándote en la premisa de que la red siempre estará en funcionamiento entonces sufrirás inexorablemente muchas desagradables e inesperadas paradas de servicio, o peor, corrupción de datos, etc.

Ideas erróneas en la gestión de proyecto

Agile es tu peor enemigo. ¿Te parece bien que el cliente te pueda cambiar las especificaciones cada dos semanas? ¿Tener que asistir a un daily todos los dias antes de las nueve de la mañana para explicar continuamente lo que estás haciendo? ¿Que te interrumpan por Skype o por teléfono dos veces cada hora? ¿Mirar de reojo cada vez que lees una página web que no está directamente relacionada con tu tarea en curso? ¿Tener que justificar al milímetro todo lo que haces y convertirte en una trituradora humana de tickets?

• Ninguna propuesta de mejora técnica supera el filtro gerancial si no puede ser explicada cuantitativamente en términos de retorno de la inversión.

Post relacionado: Hackers vs Space Cowboys.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Bookmarks
Publicado en Casos Prácticos, Organizando la Comunidad. Modelos de Desarrollo | Deja un comentario

Cómo saber cuándo hay que parar de hacer algo

Una de las decisiones más difíciles de tomar es la de cuándo parar de hacer algo. Es más difícil saber cuándo hay que detenerse que saber cuándo hay empezar con cualquier cosa. Algunas personas que han tenido éxito afirman que la clave reside en una obstinación empedernida hasta conseguir los objetivos. Pero es posible demostrar que esta no es la mejor estrategia en la mayoría de los casos. Es frecuente durante la revisión histórica de los casos de éxito el olvidarse del cementerio, de todos aquellos que intentaron lo mismo, o muy parecido, y no lo lograron. Otros piensan que para tomar buenas lo que hay que hacer es enumerar todas las opciones, sopesarlas detenidamente y elegir la mejor. Pero rara vez se dispone de tiempo, recursos e información suficiente para evaluar todas las opciones. La buena noticia es que para muchos desafíos concretos sí existe una solución óptima conocida para el problema de la detención, y de eso es lo que va este post.

Cómo elegir una pareja en un sitio de dating

Voy a empezar por un problema tipo, no porque sea el más importante o, bueno, para algunas personas a lo mejor sí, pero seguro que es el que despierta más curiosidad y se puede aplicar en múltiples situaciones. Los sitios web de dating son cómo cualquier otro proceso de recursos humanos: se busca un candidato óptimo para un perfil, pero se dispone de una candidad limitada de candidatos y de una cantidad limitada de tiempo para encontrar uno. Además, sobre el papel, muchos candidatos son muy similares y parecen igualmente adecuados para el puesto. Entonces no queda otro remedio que cribar a los candidatos entrevistándoles, lo cual tiene un coste en tiempo y dinero. Lo primero que hay que decidir para empezar a solucionar este problema de forma óptima es de cuánto tiempo se dispone y cuántos candidatos se pueden evaluar por unidad de tiempo. Por ejemplo, si el tiempo máximo son tres años y se pueden evaluar dos candidatos cada mes entonces el total de candidatos es treinta y seis. Obviamente esta no es la cifra total de perfiles en un sitio de dating, es la cantidad de los que han pasado una fuerte criba inicial por ubicación geográfica, nivel de estudios, ingresos, edad, altura, etc. La solución óptima no es ver a todos los candidatos en persona y luego elegir el mejor, para empezar porque si resulta que el mejor era el tercero o el cuarto probablemente ya no estará disponible en el mercado de intercambio horizontal tres años después cuando se termine de evaluar al trigésimo sexto.

La técnica óptima se compone de dos fases:

Fase 1: Recopilación de sujetos comparables. Durante esta fase inicial lo que hay que hacer es entrevistar candidatos y descartarlos a todos sistemáticamente sin importar lo buenos que parezcan. Pero al mismo tiempo se creará un criterio comparativo entre ellos.

Fase 2: Caza del mejor partido disponible. Tras la primera fase lo que hay que hacer es seguir entrevistando candidatos y elegir al primero que sea mejor que todos los vistos anteriormente.

Y ¿cuándo hay que pasar de la Fase 1 a la Fase 2? Pues resulta que matemáticamente se puede demostrar que lo óptimo es hacerlo tras haber visto al 37% de los candidatos. Es decir, en este caso concreto, con treinta y seis candidatos en total, habría que evaluar y descartar a trece y luego del decimocuarto en adelante escoger el primero que supere a todos los anteriores.

No voy a entrar en los detalles de dónde sale el porcentaje mágico del 37%. Intuitivamente, tiene que ver con que si hemos visto sólo un candidato entonces la probabilidad de que el segundo sea mejor que el primero es del 50%. Pero para el quinto la cantidad de ser mejor que todos los anteriores es sólo del 20%. Por supuesto podría ser que el candidato óptimo fuese el primero de todos. El procedimiento no garantiza encontrar al mejor candidato de todos, sólo maximiza la probabilidad de encontrar alguien realmente bueno.

El procedimiento anterior se conoce también cómo el Problema de Encontrar Secretaria. Fue publicado por Martin Gardner en Scientific American en 1960 aunque el primer descubrimiento de la solución se atribuye presuntamente a Merrill Flood en 1958. Está descrito con mayor detalle en el libro Algorithms to Live By the Brian Christian. Es lo mismo para reclutar una secretaria que para encontrar un apartamento de alquiler.

Hay dos salvedades que hacer al procedimiento anterior que tienen que ver con la psicología. La primera es cómo se hace la criba inicial desde los miles de candidatos que hay en un sitio de dating hasta sólo treinta y seis (o los que sean). La segunda es el factor aburrimiento.

Se sabe y es bien conocido que cuando la cantidad de opciones es abrumadora los humanos a menudo nos bloqueamos y no sabemos cual elegir. Esto sucede siempre ante la carta de un restaurante cuando es en exceso extensa. Y de ahí (entre otros factores) el éxito de sitios cómo Tinder que reducen drásticamente el número de opciones disponibles en cada momento.

Por otra parte, supongamos que debido a que elegir el cónyuge correcto es una de las decisiones más importantes en la vida entonces decidimos asignar una buena cantidad de tiempo, digamos diez años, y ponerlos realmente en la labor para no perdernos a Mister Perfecto entrevistado un candidato cada día. Aunque pudiera, es altamente improbable que una persona tenga la paciencia de entrevistar a tres mil seiscientos cincuenta candidatos para elegir al mejor de todos.

Cómo reclutar al que mejor sabe inglés

La estrategia de dos fases: recopilar + cazar, se aplica a problemas en los cuales se desconoce a priori la idoneidad absoluta del candidato. Si se puede especificar un criterio riguroso con un punto de corte entonces es posible parar en el mismo instante en que aparezca el primer candidato que supere el punto de corte del criterio. Para las pruebas de idiomas es posible usar una variante basada en percentiles. Los test de conocimiento están estandarizados de modo que es posible colocar a cada candidato dentro de un percentil. Entonces sólo hay que escoger el umbral de percentil a partir del cual escogeremos a un candidato.

Cómo vender la casa

Este caso es intermedio entre el desafío de encontrar secretaria, en el que no se dispone de ninguna información, y el de encontrar al que mejor sabe inglés, en el que se dispone de toda la información. La casa sabemos que está en un rango de precio de mercado, digamos entre 300.000 y 330.000. Las casas son un producto muy caro en Europa y por ello los compradores potenciales suelen mirar mucho antes de decidirse por una. A menos, claro que por casualidad aparezca el comprador que la considera la casa de sus sueños en cuyo caso estará dispuesto a pagar más, pongamos, hasta 350.000. En este supuesto, la clave está en el coste de la espera. Si la casa no está hipotecada y el precio de mercado no tiende a la baja y no necesitamos el dinero, entonces podemos esperar indefinidamente a que aparezca alguien dispuesto a pagar 350.000. Si, por el contrario, estamos pagando una hipoteca de 2.000€ al mes de los cuales 800€ son de intereses, entonces cada mes que pasa nos cuesta 800€

Cómo en el caso del dating, vender la casa puede estar sujeto a otros factores, por ejemplo la necesidad de mudarse en unas determinadas fechas. Puede que aparezca un comprador con una excelente oferta excepto que quiere entrar en la casa mañana cuando al vendedor le resulta imposible salir de ella.

Este mismo sistema donde la espera tiene un coste se aplica a buscar, por ejemplo, a buscar trabajo cuando cada mes desempleado supone falta de ingresos.

Cómo aparcar

Un problema algo más complicado de modelizar es el aparcamiento en zonas urbanas con tráfico denso. En el proceso hay que tener en cuenta el tiempo de espera hasta encontrar un hueco comparado con el tiempo caminando si el hueco está lejos del destino. Además pueden tenerse en cuenta otros factores cómo el coste del carburante versus el coste de un slot de pago y este coste varía si se divide entre el número de pasajeros. La variable principal que gobierna este proceso es la tasa de ocupación. Lo que sucede es que cuando el aparcamiento en una zona conveniente es gratuito todo el mundo intenta aparcar en ella y se produce un colapso. La solución habitual es instalar parquímetros para reducir la tasa de ocupación por debajo del 100%. Idealmente, los parquímetros deberían cambiar su precio en función de la demanda aunque las ciudades suelen aplicar un precio fijo por día y hora. En su libro The Cost of Free Parking el urbanista Donald Shoup muestra que cuando la tasa de ocupación pasa del 85% al 90% sólo acomoda un 5% más de coches pero al conductor le cuesta el doble de tiempo encontrar un hueco. La mejor técnica a seguir en este caso es determinar una distancia máxima y a partir de ella escoger el primer sitio que se encuentre disponible. La distancia de corte depende de la tasa de ocupación.

Cuándo dejar de robar

Para mi, un fenómeno socialmente y psicológicamente curioso es el de las personas quienes habiendo amasado una considerable fortuna por medios dudosos continúan exponiéndose al peligro de ser atrapados y encarcelados perdiéndolo todo. Supongo que la dinámica de obtener dinero se convierte en una adicción y no pueden parar. Pero también existe una métrica para calcular el número óptimo de fechorías. En este caso depende de la ganancia en cada golpe y de la probabilidad de ser atrapado. Si la probabilidad es del 50% lo mejor es no dar nunca un segundo golpe tras el primero exitoso. Pero si la probabilidad es del 10% entonces compensa dar otros ocho golpes más.

Cuantas veces intentar montar una empresa

El caso del emprendizaje no es estrictamente modelizable cómo los anteriores. El coste del fracaso es muy subjetivo y las ganancias potenciales son difíciles de predecir. Además la gente monta empresas por muchas razones que no son económicas. Aunque en realidad la única buena razón para montar una empresa es con el propósito de ganar dinero. Cualquier otra razón es equivocada ya que todas las empresas están sujetas a las implacables reglas del mercado que sólo les permite sobrevivir si son eficientes y rentables.

Los emprendedores en serie que he conocido pueden dividirse en tres grupos:

1) Los que montaron su primera empresa y tuvieron suerte, luego montaron otras con igual o peor suerte.
2) Los que montaron una empresa, fallaron y no les quedaron ganas de volverlo a intentar nunca.
3) Los que montaron una empresa, fallaron y luego decidieron montar otra y otra y otra. Este tercer grupo puede subdividirse en dos: los que a la postre triunfaron, y los profesionales en hundir empresas que van de una quiebra a otra con la más absoluta indolencia.

He escrito en el pasado sobre las consecuencias potencialmente devastadoras de un naufragio empresarial, en posts cómo No es país para viejos o El emprendedor descuartizado. Resumidamente, la primera cosa que hay que tener en cuenta antes de montar una empresa es la red de seguridad para evitar que el posible fracaso cause una catástrofe irreparable. Todos los emprendedores principiantes piensa en cuánto dinero ganarán pero los veteranos saben que el primer objetivo de una empresa de reciente creación es dejar de perder dinero.

Yo no siento gran admiración por las personas que montaron su primera empresa y les fue bien. La razón es que en la mayoría de los casos se trató de pura suerte y apenas aprendieron nada en el proceso. Los que sufrieron tribulaciones, en cambio, tienden a saber muchísimo más. La clave reside en crear un sistema y medir la tendencia. En su libro How to fail at almost everything and still be successfull, Scott Adams (el creador de Dilbert) dice que los objetivos son para perdedores y los sistemas son para ganadores. Puede que, como emprendedor, quieras ser el próximo Facebook. De acuerdo, ese objetivo no sirve para nada. Lo que sirve es tener un sistema para captar nuevos usuarios, medir su coste de adquisición, calcular su rentabilidad y minimizar la tasa de abandono. La tendencia es lo que determina si se deben seguir asumiendo pérdidas o no. En 2017 leí que las pérdidas trimestrales de Netflix eran algo así cómo de 500 millones de dólares cada trimestre. La cifra exacta no importa. Lo que importa es por qué Netflix seguía asumiendo pérdidas a pesar de que incrementar el precio de 9$ a 12$ mensuales les haría alcanzar de un plumazo el punto de equilibrio. El motivo es que la tendencia de Netflix era hacia liderar el mercado y destruir a sus competidores como Amazon Prime y las cadenas de televisión por cable. Muchos de los llamados «unicornios» de la actualidad están basados en la estrategia de perder una enorme cantidad de dinero mientras se destruye a toda la competencia para luego poder disfrutar de una cómoda posición inexpugnable en el mercado.

Como consecuencia de lo anterior, tras cada intento fallido de montar una empresa lo que hay que preguntarse es cual ha sido el progreso. ¿Cuánto hemos aprendido? ¿Qué viejos errores hemos evitado? ¿Qué nuevos errores hemos cometido? ¿Cuánto nos hemos acercado al objetivo? Si con cada intento nos acercamos más a la meta entonces merece la pena seguir intentándolo siempre y cuando el coste del fracaso no sea letal, en cuyo caso nos encontramos con un escenario similar al de los ladrones excepto que la probabilidad de que una empresa no sobreviva a sus primeros 5 años es del 80%

Cuánto hay que testear un software

En el desarrollo de software existen múltiples problemas de detención. Empezando por el problema de la parada para máquinas de Turing que es indecidible. Este es un problema de informática teórica muy técnico que no voy a abordar. Pero en el día a día los equipos de desarrollo se encuentran con problemas prácticos relacionados con la detención.

Uno de los desafíos más importantes es saber cuándo se ha probado suficientemente un software. Resulta que, por desgracia, se sabe que es imposible en la práctica demostrar por completo que un programa no trivial está absolutamente libre de errores. Entonces lo único que se puede hacer es un conjunto de pruebas lo bastante extenso cómo para poder esperar cierto grado de fiabilidad.

La fiabilidad de un software depende de cuántas horas haya estado funcionando sin errores. Siempre y cuando este funcionamiento sea en condiciones normales de uso, por supuesto, no cuentan horas de funcionamiento instrumentado con un robot que fuerza al programa a hacer exactamente lo mismo una y otra vez. Por consiguiente, lo que hay que medir es la cantidad de errores encontrados por hora de pruebas y establecer un criterio de cuántas horas queremos que el software funcione entre cada fallo. Es por esto que Facebook tiene un subconjunto de aproximadamente un millón de usuarios llamado Tier 1 que utilizan las nuevas funcionalidades por un tiempo antes de que estén disponibles para el resto de los usuarios. En este Tier 1 una vez apareció un bug que cambió el estado de la cuenta de Mark Zuckerberg a Muerto por un breve espacio de tiempo. Es sorprendente que la mayoría de los planes de pruebas en los equipos de desarrollo de software ignoren la métrica de errores encontrados por hora de testeo. Lo que se hace habitualmente es definir un plan de pruebas y si el software las pasa pues ya está: ¡a producción!

Cuándo nunca hay que abandonar

Por último, existe una clase de problemas donde, de hecho, se puede demostrar que la mejor estrategia es no detenerse nunca. Un caso trivial es la apuesta «doble o nada». Donde si se dispone de una cantidad infinita de dinero entonces es fácil comprobar que lo mejor es seguir siempre doblando la apuesta.

Otras veces uno simplemente no quiere dejarlo estar. La Humanidad también progresa gracias a avances imposibles y contra todo pronóstico llevados a cabo por personas que no eran conscientes o no les importaban sus probabilidades. En una biografía de Francisco Franco leí que el Caudillo dijo en una ocasión a sus soldados que «la vida no tiene sentido si no es para quemarla por una gran causa», supongo que ese es el único pensamiento razonable cuando estás a punto de correr colina arriba en dirección a un nido de ametralladoras.

Post relacionado: Dinámica social en los sitios de dating.

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

Cómo buscar trabajo o emprender en Inglaterra y Estados Unidos

Hace ya casi un lustro que inicié mi migración desde España a Inglaterra. Desde entonces han sido bastantes los españoles que me han preguntado sobre la emigración. En este post comparto mis lecciones aprendidas durante el proceso. Lo voy a contar desde la óptica de las necesidades de alguien que busca empleo fijo más que de las de quién pretende montar una empresa cómo ha sido mi caso. Mi experiencia es exclusivamente en el sector del desarrollo de software que tiene una gran demanda en países anglosajones y en el norte de Europa. Aunque, en general, la tasa de desempleo en Inglaterra y EE.UU. es muy inferior a la española, las condiciones para trabajos fuera del sector de tecnología pueden resultar mucho menos interesantes debido al mayor coste de vida y menor dinamismo del mercado laboral en otros sectores.

Prerequisitos

Antes de empezar a relatar nada, cualquiera que pretenda seguir los consejos descritos aquí debe cumplir al menos tres requisitos.

1º) La voluntad y posibilidad reales de emigrar. Algunas personas piensan en obtener un trabajo en remoto porque no quieren o no pueden salir de su pueblo. Esto es posible, pero, en general, la inmensa mayoría de los clientes buscan candidatos on-site y prefieren pagar más para verle a diario la cara y ojos al trabajador en persona. Es factible explicarle al reclutador y al cliente que no se es todavía residente, al menos en Inglaterra, porque para EE.UU. el empleador es consciente del coste de traslado desde Europa. Es decir, para buscar trabajo en Inglaterra no es imprescindible irse primero a vivir a Inglaterra, pero para EE.UU. es casi inevitable tener que mudarse previamente tras haber obtenido el permiso de trabajo.

2º) Un nivel aceptable de inglés hablado. Si no puedes mantener una conversación telefónica en inglés es mejor que te apuntes a clases antes de intentar siquiera conseguir un empleo.

3º) La elegibilidad legal para trabajar. Con un pasaporte de la Unión Europea no hay (ni probablemente habrá) absolutamente ningún problema para trabajar en el Reino Unido. Sin un pasaporte UE, el permiso de trabajo puede ser difícil o incluso prácticamente imposible de obtener en el Reino Unido. En Estados Unidos hay que aplicar siempre previamente a un visado mediante un proceso que describiré más adelante.

El curriculum vitae

Una de las primeras cosas que me encuentro cuando evalúo candidatos españoles es lo mal redactado que está su CV en relación a lo que los empleadores van buscando. Demasiadas personas cuentan un rollo macabeo acerca de su vida que no le importa a nadie. En cambio, lo único que se van a leer es cuales son las competencias técnicas y cuántos años de experiencia en cada una. Lo que hay que conseguir en primer lugar es pasar el triaje inicial y para eso lo único que importa es la primera página del curriculum. En la cuarta o quinta página se puede poner si quieres que eres un ludópata pervertido, al seleccionador le va a dar lo mismo quien seas porque sólo le importan tus competencias profesionales. De modo que puedes ahorrarte frases pomposas cómo «soy una persona proactiva y automotivada», etc. etc.

Es decir, el curriculum debe comenzar con TRES (3) líneas que digan: «Soy un programador junior/senior especializado en esto y aquello y busco un puesto de desarrollador/arquitecto/devops/CTO en …». Y nada más.

A continuación debe figurar un listado de tecnologías y años de experiencia en cada una tipo: Java (5 años), Python (3 años), JavaScript (2 años), etc. Hay que tener en cuenta que la mayoría de las empresas de reclutamiento usan máquinas para hacer la criba inicial de curriculums. Esto implica que el curriculum debe estar escrito para que lo lea en primer lugar una máquina. Las máquinas no entienden de explicaciones complicadas, tipos de letra bonitos o formatos originales. Las máquinas entienden de palabras clave que les han ordenado buscar. De modo que lo mejor es un curriculum en Arial o Times que ponga énfasis en las palabras que está buscando la máquina.

Por último, debe figurar la relación de proyectos en los que se haya trabajado y para cada proyecto las fechas y las tecnologías empleadas poniendo mucho cuidado en que no haya huecos en blanco entre un puesto y el siguiente.

El proceso de contacto

La búsqueda de clientes para una empresa es esencialmente la misma en Inglaterra que en cualquier otro pais. Ya he escrito varios artículos describiendo técnicas cómo venta guerrillera o venta por dominio, ergo no voy a repetir aquí cómo encontrar un cliente. Una ventaja es que tanto en Inglaterra cómo en Estados Unidos el canal de colocación es el mismo para empleados que para autónomos y microPyMEs. De modo que no es imprescindible aspirar a una nómina y, de hecho, probablemente es mejor no tener una, sino que se pueden encontrar proyectos por obra en los mismos sitios de empleo que publican ofertas de puestos fijos.

Cómo en cualquier mercado, el acceso a los clientes está acaparado por los intermediarios. Lo que hay que entender sobre los intermediarios es básicamente que no se comportan cómo seres humanos sino como cyborgs en una maquinaria. Y ellos no tienen la culpa. El reclutador sólo busca colocar a un candidato lo más rápido posible ya que su comisión depende de ello. Además, si no coloca rápidamente un candidato probablemente no lo coloque en absoluto ya que los clientes casi nunca otorgan un mandato de búsqueda exclusivo a una única agencia.

Si se dispone de tiempo y energías suficientes, es posible evitar a los intermediarios. Muchas empresas son receptivas a curriculums técnicos y pueden contratar directamente. Lo que no recomiendo en ningún caso es intentar puentear al intermediario una vez que se ha iniciado un contacto a través de él.

Si no se reside en el Reino Unido, yo recomiendo tener al menos un teléfono de contacto inglés ya que de lo contrario el reclutador tendrá dudas acerca de las intenciones reales del candidato. Un móvil de prepago o una línea de voz IP son suficientes para evitar sospechas infundadas. Es probablemente más barato viajar a Inglaterra para cada entrevista que vivir allí sin trabajo, debido a que se necesitan entre 2 y 5 entrevistas para conseguir una oferta. A 300€ de gastos por viaje eso supone entre 600€ y 1.500€, cantidades que son insuficientes ni siquiera para dejar una fianza de alquiler por un mes.

Las ofertas de empleo (y los candidatos) duran muy poco tiempo en el mercado, a menudo sólo algunas horas, de modo que hay que estar atento a las novísimas ofertas. Y cómo candidato hay que actualizar el currículum al menos una vez por semana. Yo recomendaría cambiarlo semanalmente en CV-Library, Monster, Jobsite y Reed. Los reclutadores tienen sistemas que les alertan sobre quién acaba de actualizar su curriculum. Y hay que estar preparado para recibir llamadas inmediatamente. Si el curriculum es bueno, es posible recibir entre seis y ocho llamadas en las cuatro horas siguientes su actualización.

Todo el proceso puede durar desde dos semanas hasta dos meses. No hay que desalentarse por oportunidades perdidas. Cómo ya he comentado, el mercado laboral es muy dinámico y es perfectamente normal ser descartado de un proceso por ningún buen motivo excepto que súbitamente ha aparecido otro candidato aparentemente más idóneo.

Las pruebas de selección

Para los técnicos, las pruebas de acceso pueden llegar a ser muy duras, mucho más duras que en España. Lo que sucede es que todas las empresas viven obsesionadas con reclutar al Top 1% de los candidatos. Entonces compiten de forma absurda por contratar a un perfil de empleado que realmente no necesitan. Casi siempre hay una entrevista telefónica con un programador o jefe de equipo. Algunas empresas envían un test para completar desde casa. Yo recomiendo no pretender que se tiene ninguna competencia que no se tenga realmente, porque lo van a intentar verificar. Recomiendo también evitar las entrevistas «de pizarra blanca» esas en las que ponen al desdichado candidato delante de una pizarra y entre tres programadores pretenden que escriba con un rotulador una aplicación distribuida en JavaScript. En general, cuanto más jóvenes son los interlocutores más duras son las entrevistas ya que, por alguna razón desconocida para mi, parece ser que experimentan algún tipo de placer sádico cuando cazan al candidato en algo que no se sabe, lo cual puede ser el más nimio u oscuro detalle de implementación de la última tecnología que salió anteayer al mercado.

Las referencias

Algunas empresas comprueban meticulosamente las referencias, otras no. En 2003 se creó una regulación llamada Conduct of Employment Agencies qué es un código ético opcional para los intermediarios. Los candidatos y los clientes pueden optar a liberar al intermediario de cumplir con código, porque, entre otras cosas, obliga a comprobar fehacientemente todas las referencias aportadas por los candidatos. Aunque a veces el opt-out no sirve para nada. A mi me ha pasado aceptarlo para luego descubrir que el intermediario estaba investigando meticulosamente todas las referencias de todos los miembros del equipo y creando un verdadero follón con llamadas telefónicas en frio a terceras empresas preguntando por consultores colocados por mi.

La negociación salarial

Para los programadores, el salario bruto anual puede ser muy variable, desde 30.000£ a 120.000£ (o más si se trata de dólares en Silicon Valley). Las tarifas por día oscilan entre 250£ y 700£ por día. Casi siempre el cliente echa un ancla de precio. Hay que ser muy agresivo negociando la paga al principio ya que a posteriori es prácticamente imposible renegociar el salario. El intermediario le cobra al cliente entre un 5% y un 20% del salario que percibe el empleado. Y para los autónomos un detalle importante es si el contrato está dentro o no del IR35 lo cual muy resumidamente quiere decir si lo que paga el cliente se considera fiscalmente cómo salario del autónomo o cómo ingreso de una sociedad mercantil. La legislación del IR35 ha creado un auténtico embrollo en el mercado laboral hasta el punto de que las propias empresas públicas están buscando formas de soslayarlo debido a que muchos de los mejores consultores no quieren trabajar dentro del IR35.

El neto que el empleado se lleva a casa a fin de mes es substancialmente diferente si trabaja como asalariado o cómo autoempleado. Cómo asalariado percibirá menos neto aunque tendrá otro beneficios: pensión, vacaciones pagadas, etc. Lo que en cualquier caso recomiendo evitar son los tax loans como medio de pagar menos impuestos.

Si no se sabe cual puede ser el mejor salario alcanzable ni el lugar más idóneo, hacer lo siguiente:

1. Autoasignar una cantidad límite de tiempo para encontrar empleo, por ejemplo, 3 meses, dependiendo de la urgencia y necesidad.

2. Durante el 30%-40% inicial del tiempo asignado, entre cuatro y seis semanas, aceptar ofertas preguntando las condiciones pero decir «no» a todas ellas.

3. Durante el 60%-70% del tiempo restante, aceptar la primera oferta que sea mejor que todas las recibidas durante la fase prospectiva.

4. Excepto, claro está, que en cualquier mmomento se reciba una oferta que sería claramente estúpido rechazar.

Certificaciones de seguridad británicas

Para trabajar para el gobierno británico se requiren una certificación de seguridad llamada Scotland Disclosure. La más básica es el Baseline Personnel Security Standard (BPSS) la cual es esencialmente un certificado de estar libre de condenas penales pendientes. Pero para muchos contratos con el gobierno se requiere una certificación de seguridad que es imposible de obtener a menos que se lleven al menos cinco años viviendo en el Reino Unido.

Green cards estadounidenses

Para trabajar en Estados Unidos primero hay que conseguir una Green Card. Las hay de cinco tipos E1…E5 por orden de prioridad y normalmente se require un patrocinador, pero incluso con una E5 por cuenta propia es posible obtener un permiso. Los visados se solicitan a través de la embajada. Se trata de un laborioso proceso burocrático en el cual hay que estar muy atento a los requerimientos y los plazos. En general, el Gobierno Estadounidense no da muchas facilidades pero sí cumplen estrictamente con sus propias regulaciones. De modo que obtener un permiso es posible si se cumplen todos los requisitos y se siguen a rajatabla todos los pasos.

El clima laboral

Creo que una de las cosas en las que coincidimos todos los que hemos trabajado para clientes en Inglaterra y EE.UU. es la mala onda que impera entre los equipos de trabajo. En general, los anglosajones viven obsesionados con que les pillen en un error o, equivalentemente con pillar a otro en un error. Las buenas maneras son una farsa y en el fondo la tripulación es un montón de gente con una expresión amable en la cara y un cuchillo escondido en la espalda. Soy consciente de que este párrafo suena cómo uno de esos escritos nacionalistas que proclaman la supremacía intrínseca de una tribu sobre otra. Pero no puedo evitar confesar que, en mi experiencia, la palabra de un inglés no vale nada a menos que esté respaldada por un contrato por escrito. Nunca cumplen con sus acuerdos de palabra y siempre intentan cambiarlos en su beneficio apalancándose en la más mínima oportunidad. En resumen, diría que las empresas anglosajonas no son un buen lugar para hacer amigos. La prueba es que los adultos tienden a organizarse socialmente más alredor de las actividades escolares de otros padres antes que con compañeros del trabajo.

El punto de vista del empleador

Desde el punto de vista del empleador, el mercado laboral anglosajón es la locura más absoluta. Los buenos candidatos escasean, duran poco tiempo en el mercado y carecen de fidelidad a la empresa. La diversidad cultural complica aún más las cosas ya que cada candidato tiene su propia idiosincracia según su procedencia.

Hay muchos candidatos mentirosos, yo he leído numerosos currículums que son imposibles desde el punto de vista técnico como combinar en el mismo proyecto Python y Java y autoproclamarse un experto en ambos. Si se dispone de un técnico cualificado la mejor forma de descubrir a los impostores es interrogarles. En caso de que el responsable de toma de decisión de contratación no tenga perfil técnico, yo creo que lo mejor es investigar los perfiles sociales del candidato. ¿Tiene endorsements en LinkedIn? ¿Buena reputación en StackOverflow? ¿Un buen percentil en HackerRank? ¿Un blog popular? ¿Una página con buenos proyectos en GitHub?

La escasez es especialmente intensa entre las posiciones de empleo fijo ya que con un talonario suficientemente abultado siempre es posible conseguir consultores mercenarios. Encontrar un candidato leal y competente en las últimas tecnologías es cómo buscar una aguja en un pajar.

Entre los contratistas independientes el ratio de bajas voluntarias es del 20% en el primer mes. Es decir, por cada 4 puestos que se deseen cubrir hay que contratar a 5 personas. La gran mayoría de los contratistas que permanecen pasado un mes tienden a completar el contrato de 6, 9 o 12 meses.

Entre los asalariados, el porcentaje de bajas iniciales es menor, pero su burn-out es bastante rápido e impredecible. Según mis propias observaciones, un proyecto pierde entre un 20% y un 25% de su plantilla fija en 12 meses debido a bajas voluntarias.

El período de notificación previo al despido es típicamente de un mes, pero para los contratistas no es raro que sea de tan sólo una semana (para ambas partes). Lo cual es equivalente a que cuando un empleado llega a trabajar un lunes nunca sabes si el próximo viernes será su último día de trabajo.

La reubicación familiar

Si se tiene familia, reubicarla será sin duda problemático. El Thames Valley y Silicon Valley son buenos lugares para trabajar y ganar dinero, no buenos lugares para vivir. Los transportes y las carreteras funcionan fatal en comparación con España. El precio de la vivienda es exorbitante. Y el Síndrome de Ulises puede afectar grandemente al cónyuge especialmente si éste no habla inglés, sobre todo porque el español, si puede, jamás se muda a más de un kilómetro de distancia de la casa de su madre.

En el caso de los niños su facilidad de adaptación depende de lo bien que hablen inglés. Los colegios públicos ingleses son totalmente multirraciales. Que el niño sea latino es lo de menos porque en la clase hay de todo: ingleses, escoceses, irlandeses, latinos, africanos, árabes, chinos, hindúes, etc.

Otro problema derivado de la familia es la reducción de movilidad. Para aprovechar las oportunidades hay que estar abierto a mudarse, lo cual es tanto más complicado cuanto más anclado se está a una casa y a un colegio. A menos que se tenga una oferta de empleo muy sólida y muy estable, yo recomendaría que sea el cabeza de familia quien emigre primero y tras uno o dos años, cuando el resto de los miembros de la familia hayan tenido tiempo de aclimatarse, que se reagrupen todos.

Londres o San Francisco no son ciudades para vivir, al menos con una familia, sino para medrar y ganar dinero. Sin embargo, existen pueblos a lo largo del Valle del Támesis y de la 101 Californiana que son bastante buenos como lugar de residencia.

Retorno al país de origen

Por último, hay que tener en cuenta el síndrome del expatriado, o yo diría más bien síndrome del indiano. El expatriado que regresa a su país de origen ya nunca lo ve con los mismos ojos que antaño. El indiano se ha vuelto más observador y más objetivo respecto del funcionamiento social y económico. Algunos trabajan expatriados contando los días que les restan para poder regresar a su país, pero para otros el regreso se torna prácticamente imposible por razones psicológicas.

Posts relacionados:
Consejos para elegir un candidato o un puesto de trabajo.
Cómo hacer entrevistas de selección.

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

Criptomonedas (2ª Parte. Blockchain)

BlockchainNo poca gente cree que Bitcoin es una moda pasajera, pero que su tecnología subyacente, Blockchain, será piedra angular de una nueva revolución en servicios digitales a través de Internet. Blockchain es una idea disruptiva, pero ninguna de sus implementaciones actuales prevalecerá tal cual. En este post explico las razones.

¿Qué es Blockchain?

Muy sucintamente y a los efectos prácticos que importan, Blockchain es una sucesión de apuntes en un libro compartido (general ledger). Los apuntes no se pueden alterar ni borrar una vez escritos y, además, es posible garantizar quién fué el autor de cada apunte.

La forma en la que esto se consigue para Bitcoin es la siguiente:

• A cada usuario de la red P2P de Blockchain se le asigna una dirección que está basada en un par clave pública/privada. No comentaré aquí los detalles de la encriptación asimétrica con clave pública/privada. Todo lo que importa con respecto a Blockchain es que el par de claves son dos cadenas de caracteres que identifican unívocamente a cada usuario y, además, le permiten encriptar mensajes con destino a otro usuario de manera que: a) se pueda garantizar quién ha sido el emisor del mensaje y b) nadie excepto el receptor puede descrifrar el mensaje.

• Los pares de claves se almacenan en una cartera/monedero (wallet). La elección del término wallet es desafortunada porque los wallets no almacenan realmente bitcoins sino que el saldo de cada monedero se calcula en función de del historial de transacciones de su dirección de Bitcoin asociada.

• Además de usuarios cada uno con su dirección de Bitcoin, puede haber nodos en la red P2P. Cada nodo contiene una copia entera del general ledger que a 28 de enero de 2018 ocupaba 150Gb creciendo aproximadamente a razón de 5Gb al mes.

Blockchain size 28/01/2018

• El general ledger está dividido en bloques, los cuales para Bitcoin son actualmente de 1Mb. Otras criptomonedas usan tamaños mayores de bloque y se está estudiando ampliar el tamaño de bloque a 32Mb por razones que expondré más adelante. En Bitcoin, la velocidad de generación de bloques está ajustada para que aparezca uno nuevo aproximadamente cada 10 minutos.

• Para cada bloque es necesario generar una signatura (hash) que lo identfica unívocamante. El proceso para generar esta firma está diseñado a propósito para ser computacionalmente muy costoso y, además, para Bitcoin, se vuelve más costoso a medida que pasa el tiempo.

• Un conjunto de “mineros” cada uno con su propia copia del general ledger compiten para hallar una firma válida para el último bloque que acaba de ser generado. La signatura de cada bloque depende de la su bloque inmediatemente anterior. Cualquier alteración en un bloque, por pequeña que sea, modifica su signatura (hash). Por consiguiente, para alterar cualquier bloque una vez escrito habría que alterar también todos los anteriores.

• A los mineros se les recompensa con bitcoins por su participación en la minería. Aunque no todas las criptomonedas se generan mediante minería.

• La confianza en la veracidad de la información contenida en el general ledger se basa en un sistema de consenso entre todos los nodos que contienen copias del mismo. La versión correcta del general ledger es la que creen ser correcta al menos el 51% de los nodos. Este sistema de seguridad ha probado ser bastante robusto sin que se hayan registrado ataques importantes a Bitcoin desde su aparición en 2009, aunque otras criptomonedas cómo Ethereum basadas en Blockchain sí han sido exitósamente hackeadas.

¿Para qué puede servir Blockchain?

Es fácil imaginar como consecuencia de las características anteriormente descritas que Blockchain sirve para almacenar cualquier mensaje intercambiado entre un emisor y un receptor de manera segura, garantizando la autoría, destinatario, fecha y contenido del mensaje. Esto se usa en la actualidad para registrar transacciones comerciales en criptomonedas, pero el uso de Blockchain no está en absoluto restringido a los pagos online.

Oro uso potencial de Blockchain es como sistema de gestión de identidad ya que cada par de claves pública/privada representa a un usuario. La identidad no está restrigida a usuario. Por ejemplo, Onename proporciona el equivalente a un sistema de registro de dominios de Internet.

¿Por qué es Blockchain disruptivo?

La razón principal es que se trata de un registro distribuido que puede registrar transacciones casi en tiempo real. El problema principal de las transferencias bancarias es que no existe una base de datos sino al menos dos: la del banco emisor y la del banco receptor. Ergo primero hay que hacer el apunte de transferencia en el banco emisor, seguidamente enviarlo al banco receptor lo cual puede ser un proceso por lotes, esperar a que el banco receptor confirme la recepción y, por si acaso, ejecutar procesos de conciliación entre las transacciones registradas por ambos bancos.

Con Blockchain, el dinero se transfiere directamente de la cuenta del emisor a la del receptor y queda confirmado para siempre en el general ledger tan pronto cómo uno de los mineros obtenga la signatura (hash) del bloque en el que está registrada la transacción.

Blockchain también proporciona un medio de identidad digital independiente de la asignación de ningún gobierno o empresa a través de los pares de claves pública/privada.

Con Blockchain es imposible la confiscación de bienes. A menos que se tenga acceso al monedero del propietario, el saldo no puede pasar de una cuenta a otra sin autorización. Blockchain no impidió que el FBI le confiscase en 2013 26.000 bitcoins a Ross Ulbricht, el operador de Silk Road, pero la confiscación se consiguió obligando a Ulbricht a entregar la clave privada de su monedero.

Por poner tan sólo otro ejemplo de intercambio de datos no económicos con gestión de identidad, examinemos el caso de la información médica. Legalmente el paciente es el propietario de su historial médico y puede decidir sobre su confidencialidad. Pero esto es sólo en teoría porque en la práctica son los hospitales quienes manejan los historiales y no es raro que intenten colarle a los pacientes cláusulas de cesión de datos. Con un sistema basado en Blockchain los laboratorios podrían enviar los resultados de cada prueba directamente al paciente en lugar de al médico. Entonces el paciente podría decidir con quién compartir dicha información. Además, si el médico re-enviase la información recibida a un tercero quedaría constancia de a quién se la enviado y cuando.

¿Cuales son los problemas técnicos de Blockchain?

Antes de entrar en la discusión sobre la sostenibilidad de Blockchain, es necesario tener en cuenta que existen los llamados Blockchain 1.0 (Bitcoin) y Blockchain 2.0 (Ethereum) y se está especulando sobre un hipotético Blockchain 3.0. Aunque los problemas de escalabilidad para Blockchain 1.0 y 2.0 son similares.

Problema Nº1: Máximo número de transacciones por segundo (throughput).

Por razones principalmente históricas, Bitcoin usa un tamaño de bloque fijo en 1Mb y se genera un bloque cada 10 minutos. Debido a estas restricciones intrínsecas en el diseño, el número máximo de transacciones por segundo que soporta el Blockchain de Bitcoin es alrededor de 6. Una cifra minúscula comparada con la velocidad de pico de Visa que ronda las 56.000 transacciones por segundo.

Este problema puede aliviarse incrementando el tamaño del bloque o la velocidad de creación de nuevos bloques. La propuesta actual es incrementar el tamaño de bloque a 32Mb. Pero incrementar el tamaño y frecuencia de los bloques no es una solución exenta de inconvenientes. Para empezar se requeriría que todos (o casi todos) los nodos de la red P2P de Bitcoin empezasen aceptar los nuevos tamaños de bloque simultáneamente haciendo uso de un «fork duro» de código. Cuanto más grande sea el tamaño del bloque más costoso es mantener un nodo, y, por consiguiente se reduciría el número de nodos. Hay que tener en cuenta también el ancho de banda requerido para replicar los bloques en todos los nodos. Y, no obstante cualquier ampliación, ningún tamaño de bloque podría acomodar cualquier número de transacciones por segundo. Es decir, siempre existirá una velocidad de pico de toda la red.

No todas las criptomonedas basadas en Blockchain usan tamaños de bloque de 1Mb. Ethereum usa un tamaño de bloque variable, pero en Ethereum todavía existe otra medida llamada gas que representa el consumo de recursos requerido por una transacción. El gas está limitado a 6,7 millones por bloque y aproximadamente 3 milliones (89Kb) por transacción. Con esos parámetros, el throughput de Ethereum tiene un pico máximo de 1.000 transacciones por segundo.

Problema Nº2: Tiempo requerido para completar una transacción (latencia).

La red actual de Bitcoin puede tardar hasta 10 minutos en confirmar una transacción. El problema es que cuantos más nodos participan en una red P2P más tiempo se tarda en alcanzar el consenso de un número suficiente de ellos. El tiempo requerido para alcanzar el consenso afecta especialmente a Ethereum por ser la red que más nodos tiene, más de 25.000 frente a los menos de 10.000 de Bitcoin.

Problema Nº3: Coste económico por transacción.

Debido a lo computacionalmente costoso que es el minado, el coste total por transacción debido al precio de la energía requerida ronda los 6,2 dólares. Las transacciones sólo son gratis (o muy baratas) para los usuarios porque los mineros reciben recompensas en forma de nuevos Bitcoins cuando son los primeros en encontrar una signatura aceptable para un bloque.

Minar Bitcoins es tan caro que sólo resulta rentable hacerlo con hardware especializado cómo circuitos ASIC y en paises cómo China donde la energía eléctrica se puede comprar por entre 3 y 6 centavos el kW/h (mucho más barata que en EE.UU. y Europa donde el precio ronda los doce centavos o céntimos el kW/h).

Bitcoin Power Consumption Evolution

Problema Nº4: Impacto medioambiental del minado.

Además del coste económico, según un estudio de PowerCompare, en 2017 el minado de Bitcoin consumió 29,05TWh y supuso el 0,13% del consumo eléctrico mundial. Si la red de Bitcoin fuese un país se encontraría en la posición 61 de consumo por encima de otros 159 países.

Problema Nº5: Vulnerabilidad de la red a la concentración de mineros.

Como ya hemos mencionado, la robustez de la red de Bitcoin frente a cambios fraudulentos en la cadena de bloques se fundamenta en el consenso entre los nodos, necesitando un atacante poseer al menos el 51% de la potencia de cálculo total de la red para persuadir a los otros nodos de que cambien su información sobre uno o varios bloques. Pero según un artículo de MIT Technology Review, las cuatro principales operaciones de minería de Bitcoin tenían más del 53% de la capacidad minera media del sistema; y en el caso de Ethereum la concentración es aún mayor con tan sólo tres mineros representando el 61 % de la capacidad del sistema.

En definitiva, Bitcoin no es seguro debido a Blockchain, es seguro debido a que la cantidad de recuros necesaria para hackear la red supera el valor de los Bitcoins que podrían ser robados. El teórico ataque del 51% proporciona una probabilidad de cambiar el último bloque generado, pero incluso con el 51% re-escribir la historia de los bloques antiguos es prácticamente imposible.

Problema Nº6: Redundancia del general ledger.

Otro problema es el crecimiento continuado del tamaño del general ledger. Debido a que el coste del almacenamiento tiende a disminuir rápidamente, el tamaño total del general ledger no parece un problema acuciante. Pero podría, por supuesto, incrementar el tiempo de arranque de un nuevo nodo, ya que tendría que descargar todo el general ledger antes de empezar a operar. Además, no es imposible pensar en algún proceso de consolidación de saldos que hiciese innecesario el mantenimiento de todo el histórico de transacciones en el general ledger. Podría limitarse a, por ejemplo, 5 o 10 años quedando el resto de transacciones en algún tipo de copia de respaldo que no fuese sistemática y constantemente replicada a todos los nodos.

Para lo que la redundancia sí supone una limitación importante es en el caso de que se desease utilizar el general ledger cómo almacén de archivos grandes. Supongamos, por ejemplo, que se desease utilizar una cadena de bloques para almacenar mamografía digitales. Cada mamografía ocupa 50Mb de modo que habría que trocearla en bloques y almacenarla en más de 50 fragmentos. No obstante, existen soluciones como Filecoin para el almacenamiento distribuido de ficheros empleando tecnología Blockchain.

Problema Nº7: Dependencia de las claves públicas/privadas.

Históricamente, ningún sistema con seguridad basada en encriptación asimétrica ha tenido aceptación generalizada entre los usuarios. Los pares de clave pública/privada se utilizan extensamente todos los días en los sistemas informáticos y casi cualquier programador tiene varios pares de claves para diferentes usos. Pero al usuario medio la gestión de claves no se le da nada bien. Aunque los pares de claves se pueden proteger con una contraseña adicional fácil de recordar, en definitiva perder el monedero equivale a perder todo el saldo sin posibilidad de recuperarlo.

Aunque, en teoría, Blockchain puede servir como fundamento a un sistema de gestión de identidad, en la práctica casi todos los grandes proveedores de servicios en Internet han intentado sin éxito convertirse en el estándar de gestión de identidad. Ni siquiera el ubicuo Facebook ha conseguido que sus usuarios sean el medio de facto para identificar usuarios en la red. Microsoft está apostando últimamente por su nuevo sistema biométrico Hello en el convencimiento de que los usuarios jamás aprenderán a gestionar adecuadamente sus contraseñas.

Post relacionado: Criptomonedas (1ª Parte. Bitcoin).

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Bookmarks
Publicado en Criptomonedas, Disrupción, Iniciativas que cambiarán el mundo, Tecnologías Emergentes, Tecnologías Libres | 1 comentario

El dilema de la transparencia informativa en desarrollo de software

Groucho sanity clauseUna de las obligaciones complejas para un líder técnico en un proyecto de desarrollo de software es la provisión de información a los gerentes de cuenta y a los clientes. En principio, las metodologías ágiles abogan por la transparencia total. Desafortunadamente, la transparencia total no siempre es factible en la práctica y hay que llegar a soluciones de compromiso que describiré a continuación.

Lo primero que un programador debe tener en cuenta cuando le piden una explicación detallada es que el interlocutor no puede entender detalles técnicos. En decir, si te pones a hablar en jerga informática acabarás hablándole a una persona que no sabe lo que le estás contando. Esto es así incluso cuando al técnico le piden una explicación pormenorizada porque tal petición realmente significa «una explicación suficientemente pormenorizada pero que aún resulte entendible sin conocimientos técnicos». El problema de una explicación real y sin edulcorantes es que cómo el que escucha no la entiende entonces empieza a imaginarse cosas. Puede que tú le hayas dicho que el viernes por la tarde recibísteis una alerta de que la cuota en disco estaba al 90% y, simultaneamente, los tiempos de ping a las máquinas virtuales empezaron a superar los quinientos milisegundos. Debido a que tal galimatías es imcomprensible para el receptor del mensaje, y a que la imaginación es una herramienta muy traicionera, inmediatamente el desdichado oyente empezará a imaginarse que lo que significa es que la Tierra dejará de girar y se propagarán terribles epidemias. La clave estriba en que la información hay que proporcionarla siempre en términos de negocio. Lo que a un gerente de cuenta o a un cliente le importa en el fondo es cómo va a impactar la incidencia en su negocio. En el ejemplo anterior lo que es entendible es algo estilo “durante unas horas entramos en riesgo de sufrir una parada de servicio y los clientes experimentaron una ralentización en los tiempos de respuesta del 50% respecto de lo habitual”. Todo lo demás sobra.

En el caso de que se trate de una explicación entre dos programadores, conviene tener en consideración que la informática se diferencia de otras ramas de la ingeniería en al menos dos aspectos importantes: 1º) un programador puede darle a otro una explicación que es –simultáneamente– perfectamente plausible y totalmente falsa; y 2º) no existe –en principio– la responsabilidad civil, el software se entrega “tal cual”, si te hunde el negocio y te arruina la vida, pues lo máximo que el programador hará es decirte que lo siente y que te acompaña en el sentimiento.

A veces los clientes designan a sus propios técnicos para controlar al proveedor y entonces sí puede ser posible proporcionarles justificaciones detalladas aunque incluso en esos casos con matices. Es posible que los acuerdos de nivel de servicio contengan cláusulas con penalizaciones económicas expresas que el cliente pueda intentar usar para no pagar incluso aunque el déficit del servicio no lo justifique realmente. O puede que simplemente la sensación de incertidumbre creada erosione la relación cliente-proveedor innecesariamente. Lo esencial es la honestidad. Hay que ser siempre honesto con los clientes, lo cual no implica necesariamente explicarles lo que sucedió en la cocina minuto a minuto especialmente si no se conocen las cláusulas contractuales.

Un caso particular es cuando el auditor/controlador de proyecto es otro subcontratista. Los subcontratistas puede tener su propia agenda oculta, que en algunos casos puede incluir intentar reemplazar al proveedor por otro más de su conveniencia. Y en casos menos extremos simplemente apretarle las clavijas al proveedor para comprar el máximo de trabajo por el mínimo precio para incrementar el margen de intermediación respecto del total de lo que paga el cliente.

Una situación especialmente compleja son las reuniones de chiriguito total donde algo ha salido mal y se ha organizado una caza de brujas. A los programadores habitualmente no se les permite asistir a ese tipo de reuniones porque incluso aunque no abran la boca se pasar todo el rato mirando hacia el lado izquierdo y derecho de su cerebro cómo si estuviesen buscando una solución sin encontrarla y eso pone muy nervioso al cliente. En los casos en los que al programador sí se le permite asistir, la primera regla es no puentear al jefe, no hablar a menos que se le pregunte y antes de responder mirar al jefe para ver si éste está de acuerdo con permitir una respuesta o prefiere alegar que es preciso demorarla. En determinados situaciones, es posible que al jefe le estén acribillando y le venga bien una mano espontáneamente. Lanzarse al ruedo a rescatar a un torero que está siendo corneado por el toro debe hacerse con gran cautela. En primer lugar, cómo ya he argumentado, hay que evitar justificaciones técnicas. En segundo lugar hay que evitar proclamar inocencia cuando ya se ha sido hallado culpable a menos que se disponga de una cantidad abrumadora e incuestionable de pruebas y a veces ni aún así porque no es buena idea culpar al cliente aunque no tenga razón. Cuando la bronca no está justificada suele ser mejor aceptar el balazo a priori y seguidamente enviar por escrito un relato con los hechos y la verdad de manera que la otra parte pueda dar su brazo a torcer sin resultar humillada. Muchas veces la forma más fácil y eficaz de poner fin a un conflicto es ofrecer una disculpa aunque no se sea realmente el culpable.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Bookmarks
Publicado en Casos Prácticos, Organizando la Comunidad. Modelos de Desarrollo | Deja un comentario

Criptomonedas (1ª Parte. Bitcoin)

CriptomonedasLlevo años pensando en escribir sobre criptomonedas, sería imperdonable que un blog cómo este ignorase Blockchain y Bitcoin. La primera revisión de este artículo es de 2011. Quizá debería haber publicado entonces cuando ya sabía que Bitcoin iba a ser un pelotazo. Me habría cubierto de gloria. No obstante, quizá aún no llegue demasiado tarde. Hay tanto que contar que lo voy a tener que dividir en varias entregas. No lo voy a escribir desde los fundamentos hasta las consecuencias. Sino más bien al contrario, empezando por lo esencial y luego explicando las razones, para que quien se llegue a aburrir pueda dejar la lectura dónde quiera.

Los cuatro puntos claves de este texto son :

1º) Cómo se crea el dinero.
2º) Cómo funciona la tenencia anónima de riqueza (si es que tal cosa debería existir).
3º) Cómo se registran transacciones de comercio y se regula la confianza entre partes.
4º) Quién y cómo regula la cantidad de moneda en circulación y el valor de la misma.

¿Cómo se crean los Bitcoins?

Una de las primeras preguntas de debate, es ¿qué es Bitcoin? ¿qué es una criptomoneda? ¿es una divisa? ¿es un activo? ¿es una inversión? ¿es un medio para transacciones de compra-venta? Mi opinión es que a efectos prácticos no importa demasiado la definición precisa de lo que es Bitcoin. Los dos elementos claves son: a) cómo se crean los Bitcoins y b) cómo funciona el registro de transacciones (general ledger) de Blockchain.

Los Bitcoins se generan mediante minería, cómo el oro. No es una minería física, pero es el equivalente digital, que para el caso es lo mismo (los detalles los explicaré más tarde). Por consiguiente, Bitcoin está diseñado para ser deflaccionario. Hay una cantidad máxima de Bitcoins que pueden existir: 21 millones. Lo mismo que existe una cantidad máxima de oro en la Tierra. Esta es a razón por la cual era fácil predecir que el precio del Bitcoin subiría.

El diseño deflaccionario de Bitcoin es su mayor debilidad. Hay otros problemas técnicos con Blockchain que comentaré en el siguiente capítulo del post, pero si en el Mundo sólo existiese el Bitcoin cómo moneda, tendríamos que crear otras monedas, lo mismo que hubo que abandonar el patrón oro.

No todas las criptomonedas se generan igual. Bitcoin está diseñado para que su velocidad de generación se reduzca a la mitad cada cuatro años mientras que Ethereum está diseñado para que se produzca una cantidad fija de nueva criptomoneda cada año.

Con Bitcoin, tarde o temprano se alcanzará la cantidad máxima de 21 millones de bitcoins en circulación. Entonces habrá que encontrar alguna otra forma de recompensar a los mineros que aseguran que las transacciones no pueden ser falsificadas. El caso es que, por razones técnicas que expondré en la siguiente parte de esta serie de artículos, el ancho de banda de Bitcoin está limitado a un bloque de 1Mb cada 10 minutos. Entonces, si no se cambia nada, llegará un momento en que los mineros tendrán que cobrar por verificar transacciones y los usuarios tendrán que pagar por priorizar sus transacciones.

Otro problema poco mencionado pero potencialmente letal para bitcoin es que su seguridad es vulnerable a avances en computación cuántica.

¿Cuales son los problema de las monedas deflaccionarias?

Bien, para empezar, debido al incremento de las fronteras de producción gracias al avance tecnológico, la riqueza global en el mundo aumenta constantemente. Es decir, cada día hace falta más dinero en circulación, para reflejar que, en conjunto, somos más gente y tenemos más capacidad para hacer cosas. Es, por consiguiente, indeseable que la velocidad de generación del dinero dependa de la velocidad a la que se pueda obtener un recurso mediante minería.

En siguiente lugar la deflacción dificulta que se mueva el dinero y favorece a los ricos. Si tienes un millón en el banco, y hay un 15% de inflacción interanual, en poco tiempo dejas de ser millonario. Por consiguiente, los ricos se ven forzados a invertir su dinero. Con una moneda deflaccionaria existen menos incentivos para el gasto y la inversión, y por consiguiente, la deflacción perjudica a la curva agregada de demanda.

Por otra parte, la deflacción perjudica a los que tienen deudas. Por ejemplo, el funcionamiento de una hipoteca es que el tomador recibe una cantidad X inicialmente. Y debe pagar por ella una cuota mensual fija C durante N años. La idea es que la cantidad mensual C dentro de unos años será mucho más fácil de pagar por el tomador debido a la inflacción, pero si hay deflacción, cada mes se vuelve más difícil que el anterior pagar la cuota. Este es, por cierto, el problema gordísimo actual de los fondos de pensiones, que se basan en lo mismo: el futuro pensionista paga hoy una cantidad C y recibe dentro de N años (más o menos) la misma cantidad C, siendo C dentro de N años teóricamente menos dinero debido a la inflacción, pero si hay deflacción persistente el fondo puede acabar teniéndole que pagar más dinero (en términos de poder adquisitivo) al pensionista del que éste aportó. Algunos argumentan que la deflacción sólo afecta a las economías basadas en deuda. Según algunos teóricos. La deflacción sólo es mala cuando el dinero se genera mediante deuda, tal y cómo se describe en el siguiente apartado, pero el Bitcoin no se genera mediante deuda. Aunque a mi no se me ocurre cómo podría crecer la economía sin algún tipo de mecanismo regulatorio de la deuda.

Por último, la deflacción puede ocasionar el problema de la división ya que existe una unidad mínima (céntimo, centavo, penique o lo que sea). El problema de la división también afecta al Bitcoin pues existe una unidad minima llamada Satoshi que es 0,00000001 BTC.

¿Cómo se crea actualmente el dinero?

En la economía capitalista el dinero lo crean, normalmente, los bancos privados, de la siguiente manera: Laura tiene 100€ y los deposita en un banco. Este banco está legalmente autorizado a prestar un elevado porcentaje de esos 100€, digamos 97€, entonces el banco le presta 97€ a María con un interés del 5% anual. Al cabo de un año María le devuelve al banco 101,85€ y entonces a partir de los 100€ iniciales de Laura se han creado 1,85€ nuevos. Este es, o debería ser, el mecanismo de creación del dinero. Es un mecanismo que otorga un gran poder a los bancos, pero durante un tiempo ha funcionado razonablemente bien. Durante un tiempo existen 197€, los 100€ de Laura más los 97€ de los que dispone María, ese crecimiento de la masa monetaria en circulación anima la economía. Cuando la demanda de créditos no es suficiente, los bancos pueden recurrir a prestarse dinero entre ellos. Y cuando ni siquiera el préstamo interbancario es suficiente entonces entran en juego los bancos centrales y ahí es donde empieza el problema social.

La misión principal de los bancos centrales es mantener el poder adquisitivo de la moneda, es decir, evitar que se produzca una hiperinflacción como la que sufrió la República Weimar y que es señalada por muchos como una de las causas de ascenso del nazismo. El Banco Central Europeo también es el encargado de definir y ejecutar la política monetaria de la zona euro, dirigir las operaciones de cambio de divisas, cuidar de las reservas exteriores del Sistema Europeo de Bancos Centrales y promover el buen funcionamiento de los sistemas de pagos e infraestructura del mercado financiero. Pero lo fundamental es el control de precios.

Lo que es esencial entender es que los bancos centrales distorsionan el proceso por el cual el «dinero de mentira» se convierte en «dinero de verdad». El «dinero de mentira» es aquel que se genera directamente de la nada. Lo crea un banco privado al otorgar un crédito o el Banco Central al prestar dinero a los bancos nacionales. Los encargados de convertir el dinero de mentira en dinero de verdad son los ciudadanos porque cuando el ciudadano toma un préstamo ese dinero es de mentira pero cuando lo devuelve es el fruto de su trabajo y entonces se ha convertido en dinero de verdad.

El BCE tiene prohibido, en principio, prestar dinero a los Estados, y por buenos motivos. El BCE posee un capital social de 10.760 millones de euros, sin embargo, ha prestado dinero por centenares de miles de millones de euros. Para rescatar a los estados lo que se hizo fue prestar grandes cantidades de dinero a los bancos nacionales aceptando como garantía deuda pública comprada por estos. De paso, los beneficios obtenidos por el diferencial entre el precio de compra del dinero en el BCE y el de venta al Estado proporcionaban un pingüe beneficio a los bancos cuando la prima de riesgo estatal era alta. El problema es que todo este dinero inyectado por el BCE es dinero de mentira y, por consiguiente, tendrá que ser convertido en dinero de verdad en algún momento por los ciudadanos mediante el pago de impuestos. Es decir, el incremento de la deuda pública priva a los ciudadanos del derecho a decidir sobre sus finanzas, les endeuda sin que ellos se den cuenta directamente y más allá del máximo que podrían endeudarse aunque quisieran.

¿Por qué es arriesgado invertir en Bitcoin?

El riesgo principal está en la volatilidad. Actualmente, las fluctuaciones de valor de las criptomonedas se comportan cómo las de las acciones de una compañía en bolsa en lugar de cómo las de una moneda tipo dolar o euro. No es que las criptomonedas no vayan realmente nada. George Soros dijo en una ocsión que las burbujas financieras no crecen alimentadas por la brisa marina sino que tienen sólidos fundamentos en la realidad excepto porque se trata de una realidad distorsionada. Recientemente la agencia de calificación estadounidense Weiss Ratings publicó una clasificación de 74 criptomonedas en la cual otorgaba categoría B a Ethereum, EOS, Cardano, NEO y Steem y categoría C a Bitcoin y Bitcoin Cash.

Se sabe que existen botnets para inflar el precio de las criptomonedas.

En enero de 2018 hay unos 16,5 millones de Bitcoins cada uno valorado en 17.850$ es decir 294.525 millones de dólares. Se cree que el creador de Bitcoin (Satoshi Nakamoto) tiene un millón de Bitcoins, y, según Bitcoin Rich List, las 100 primeras direcciones acumulan el 17% de los Bitcoins. En decir que, básicamente el reventón de la burbuja podría producirse un día que el Sr. Nakamoto se levante por la mañana y se diga a sí mismo: «¡voy a hacer caja!».

¿Por qué son necesarias las criptomonedas?

Las criptomonedas pueden cumplir funciones que las monedas clásicas no pueden cumplir, o pueden hacerlo sólo difícilmente. Principalmente:

1. Proporcionar una infraestructura descentralizada de pagos al servicio de las necesidades del mercado. Sin que esté bajo el control de ninguna institución financiera.

2. Permitir transacciones rápidas y fiables entre compradores y vendedores que no se conocen mutuamente sin pagar comisiones a un intermediario.

3. Servir potencialmente como moneda no controlada por ningún gobierno y, por consiguiente, independiente de las decisiones arbitrarias de ningún régimen político o banco central.

4. Servir cómo medio de tenencia anónima de riqueza.

De todas estas funciones, la que puede tener potencialmente más impacto a medio-largo plazo es la desintermediación de los bancos y entidades de tarjetas de crédito. El problema con el registro de transacciones bancarias es que no existe un registro único sino varios uno en cada banco o institución financiera. Por tal motivo las transferencias no son instantáneas y es necesario ejecutar procesos por lotes de conciliación.

Pero la más controvertida funcionalidad de las criptomonedas es la posibilidad de poseerlas sin que se pueda determinar quién es el propietario real. Según algunos estudios, hasta el 25% de todas las transacciones económicas en Bitcoin son para actividades ilegales.

Es discutible si se deberían permitir almacenes opacos de dinero, que de hecho ya existen. En el reino Unido, por ejemplo, están intentando ilegalizar la compra venta de Bitcoins a personas no identificadas lo cual es un poco cómo el vano intento de regular la venta de armas en Estados Unidos.

Mi opinión personal es que, a pesar de los potenciales usos delictivos, sí debería existir algún medio para poseer riqueza sin la obligación de informar al Estado y al Mundo-Mundial. Ya sea manteniendo la riqueza en Bitcoins, en oro debajo de la cama o en el siempre socorrido calcetín, debido a que los Estados han demostrado sistemáticamente a lo largode la historia ser mucho más peligrosos para el bolsillo del ciudadano que cualquier ladrón. De hecho si uno se lee la Declaración de Independencia de los Estados Unidos en 1776 queda claro que lo que en aquel entonces entendían por «libertad» era la libertad para que el Estado no tuviese derecho a fiscalizar ni confiscar nada. La Declaración de Independencia no trataba de la esclavitud o los derechos de las mujeres (eso vino después en forma de enmiendas constitucionales) La declaración original iba de de poder gastar todo tu dinero como quisieses (los Republicanos Estadounidenses siguen pensando de la misma forma hoy en día).

Continuación: Criptomonedas (2ª Parte. Blockchain).

Recurso Relacionado: Bitcoin: Un Sistema de Efectivo Electrónico Usuario-a-Usuario (Satoshi Nakamoto).

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Bookmarks
Publicado en Criptomonedas, Disrupción, Tecnologías Emergentes, Tecnologías Libres | 2 comentarios

El Ingeniero Comecocos

Pac-Mac SuperBrosUna de las personas que definitivamente quieres en tu equipo es el Ingeniero Comecocos. Se trata de un perfil difícil de encontrar y raramente demandado a los reclutadores. En este post explico los rasgos de este tipo de trabajor esencial en cualquier proyecto informático.

El rasgo fundamental del Ingeniero Comecocos es que en el día a día opera como el Pac-Man de los años 80: lo sueltas en el tablero de juego y él mismo se encarga de comerse todos los puntos esquivando a los fantasmas. Aunque se mueve de forma aparentemente aleatoria por los pasillos, tiene una idea global de dónde estan los fantasmas y de cómo esquivarlos para completar la misión. Este tipo de trabajador es más o menos lo que predican las metodologias ágiles, basadas en que antes que decirle a los programadores lo que deben hacer es mejor preguntárselo y pedir su consejo.

Lo que sucede es que frecuentemente no se fomenta en exceso la proactividad, los jefes la piden a gritos, pero tales peticiones a menudo caen en saco roto o la gente no puede ser proactiva simplemente porque se lo impiden las normas. Se supone que el objetivo de Agile es maximizar el valor aportado al cliente con la mejor eficiencia operativa posible. Pero en la realidad la practica diaria ágil se convierte en una sucesión de monótonos y anodinos stand-ups matinales aderezados por retrospectivas que tampoco se traducen en cambios tácticos importantes. Al final, cada programador trabaja con sus tickets y a poca gente le importa lo que suceda cuando el ticket pase a la etapa de testeo, o si deberia haber otros tickets que ni siquiera están en la herramienta de seguimiento del proyecto.

Los rasgos identificativos del Pac-Man son pues los siguientes :

• Se da cuenta de lo que falta en el Backlog, el Kanban Board (o lo que sea que se utilice), lo añade a su propia lista de tareas y lo acomete.
• Se percata de cuando se esta apilando trabajo sin terminar en la cola de otro programador y toma medidas para desbloquear las historias de usuario atascadas.
• Tiene conciencia de lo que sucederá cuando los testers, devops, técnicos de atención diaria de sistemas y usuarios reciban el producto. Es capaz de proporcionar documentacion e instrucciones sobre cómo probar, claves para diagnosticar fallos leyendo los logs y advertencias sobre funcionalidades difíciles de entender para los usuarios.
• Avisa cuando los contratos (explícitos o implícitos) o los protocolos con un proveedor no son los adecuados y se deberían cambiar.
• Puede visualizar cómo serán el rendimiento y la estabilidad del sistema cuando pase del entorno de desarrollo a un entorno de producción con gran carga de datos y usuarios.
• No espera a que le sea asignada una tarea, escoge la más prioritaria del backlog y se pone con ella.
• Nunca deja solo a otro programador que está enfrascado en un problema de difícil resolución.
• Nunca entrega código «autodocumentado» sin instrucciones de despliegue y mantenimiento.
• Es psicológicamente resiliente a cambios súbitos o soluciones subóptimas de compromiso impuestas por el mercado, o por clientes o gerentes que no saben realmente lo que quieren.

La necesidad de este tipo de conducta en el equipo surge debido a que tan pronto cómo un proyecto alcanza un tamaño mediano se vuelve complejo saber exactamente que es lo que está sucediendo. Por mucho que se intente mantener al minimo el WIP (Work In Progress) no es raro tener mas de un centenar de tareas abiertas incluso en un proyecto relativamente pequeño. Y en un proyecto grande puede haber miles de tareas en curso. En tales circunstancias es difícil mantener un control centralizado de la situación. Los militares conocen bien este fenomeno cuando la radio de campaña se satura de gente gritando todos al mismo tiempo porque estan en contacto con el enemigo. En esos casos, si la estrategia esta bien diseñada, lo mejor puede ser dejar que las unidades operativas tomen decisiones sobre el terreno y se coordinen entre ellas sin pasar por un mando central. De esta forma en algunas ocasiones es posible ganar un batalla sin saber ni siquiera cómo se ha logrado la victoria.

Quizá una de las primeras referencias bibliográficas que se pueden encontrar sobre el problemas de la coordinación en proyectos grandes es la historia del desarrollo de Office por parte de Microsoft. En los 90, Microsoft puso en prática exitósamente una estrategia de «estabilizar y sincronizar» (tras muchas tribulaciones narradas por Joel Spolsky y otros gerentes de proyecto de la época).

No obstante lo anterior, no todo son ventajas y un camino de rosas con el miembro del equipo «tipo Comecocos». En algunas ocasiones el estilo maverick puede conducirles a ir en exceso por libre, esquivando tareas que les desagradan. Algunos se desmoralizan cuando no consiguen avanzar durante cierto tiempo debido a restricciones impuestas externamente. Puede que se equivoquen en la asignacion de prioridades o que se obsesionen con algo que creen que debería tener o hacer el producto. Algunos son hiperactivos y sólo pueden trabajar de forma errática saltando de una tarea a otra sin completar realmente ninguna. Y si no saben informar correctamente pueden volver loco al gerente de proyecto.

Post relacionado:
El perfil del empleado perfecto.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Bookmarks
Publicado en Entorno laboral, Organizando la Comunidad. Modelos de Desarrollo, Sin categoría | Deja un comentario

Porqué hay que evolucionar desde Agile hacia el Autoservicio

Hace unos días mantuve una interesante conversación con Nito Martínez, uno de los gerentes de Qindel. Hablamos sobre por qué muchos proyectos ágiles son tan caros a pesar de estar (aparentemente) bien gestionados. Nito me contó algo que de alguna forma yo ya sabía, pero él me lo explicó con una lucidez que yo no había sido capaz de conceptualizar. Este artículo contiene partes de la conversación y extensiones adicionales mias.

Actualmente casi todos los proyectos se gestionan con algún tipo de Metodología Ágil. Con estas metodologías, la fuente principal de retrasos y sobrecostes son los tiempos de espera y las tareas que están bloqueadas. Cuando no se hacía Agile sino que los proyectos eran subcontrataciones waterfall a precio y plazo cerrado, curiosamente los bloqueos no eran tan importantes porque el proveedor típicamente tenía varios proyectos en curso y cuando una persona se quedaba bloqueada en un proyecto simplemente se ponía con una tarea de otro proyecto. El uso de recursos compartidos entre proyectos generaba impredictibilidad sobre su disponibilidad y eventualmente los clientes acabaron exigiendo exclusividad y dedicación plena de los recursos. Por consiguiente, en lugar de ofrecer precio cerrado, los proveedores tuvieron que cambiar a cobrar por hora con el taxímetro puesto (time & materials). El time & materials es más barato para el cliente sólo si todo el mundo está ocupado todo tiempo. Pero más caro si los recursos están ociosos, ya que el cliente tiene que pagarles por hora igualmente.

Lo que sucede es que si se mira el estado de un proyecto ágil en una herramienta como JIRA (o la que sea…) es habitual encontrar que no menos del 25% de las tareas están bloqueadas y no se pueden acometer. Como otro de los principios del agilismo es reducir el número de tareas de curso (Work In progress – WIP) entonces un 25% de tareas bloqueadas implica que hay un considerable porcentaje de gente cruzada de brazos. Las metodologías ágiles ponen énfasis en la necesidad de evitar los bloqueos pero no explican operativamente cómo desbloquear tareas.

En el desarrollo de software, una tarea puede estar bloqueada esencialmente por cuatro motivos:

1º) porque depende de otra tarea previa que no ha sido completada.
2º) porque una etapa en la cadena de producción está saturada y la tarea está esperando a que haya recursos disponibles.
3º) porque el programador no sabe cómo realizarla.
4º) por motivos políticos, gerenciales, legales, etc.

A continuación enumeraré algunas tácticas posibles para evitar cada uno de estos tipos de bloqueo.

Desbloqueo por autoservicio

En software, la forma más fácil de desbloquear una tarea que está esperando por otra es que la persona a la espera pueda completar la tarea anterior. Por ejemplo, si un documento de arquitectura técnica está incompleto, el programador debería ser capaz de completarlo él mismo. Si hay que abrir un puerto en un firewall para conectarse con un servicio externo, el programador debería poder hacerlo por sí mismo (e informar al administrador del sistema, por supuesto). La evolución de la programación es hacia entornos donde todo, incluída la infraestructura, es programable. Así, el programador puede crear una máquina virtual o definir una topología de red, todo por software sin necesidad de depender de un administrador de sistemas. Excepto en el entorno final de producción, los programadores deben tener el máximo grado posible de libertad para moverse. Para que esta “anarquía de los programadores” sea factible han de cumplirse dos requisitos ineludibles: 1º) todos los cambios deben ser fácilmente trazables y 2º) debe ser posible revertir fácilmente un cambio.

Desbloqueo por redistribución de recursos

La tendencia actual para evitar que las tareas se bloqueen en un tablero Kanban es crear equipos multifuncionales integrados en lugar de departamentos cada uno encargado de una etapa. Esto sólo funciona cuando el espectro de habilidades de cada miembro del equipo es amplio. Si existe un equipo de front-end y un equipo de back-end y los de back-end bloquean a los de front-end, o viceversa, no sirve para nada crear un equipo mixto con un programador de front-end y otro de back-end pues será aún peor debido a que con los departamentos al menos existe un pool de recursos pero en una cadena de producción con sólo dos personas es facilísimo que una acabe esperando por algo que tiene que hacer la otra.

Desbloqueo de los tiempos muertos de los programadores

Un tipo de bloqueo que no se suele tener en cuenta es el tiempo que pasan los programadores averiguando cómo hacer algo, ocupándose por WhatsApp de alguna cosa no relacionada con el trabajo o consultando el menú del restaurante antes de salir a comer.

En ingeniería aplicada la inteligencia es menos útil de lo que podría parecer a primera vista porque muchos de los problemas en los que se pierda más tiempo son de descubrimiento de funcionalidad y parametrización. Basta hacer un pequeño estudio de la cantidad de horas que los programadores pasan en StackOverflow para percatarse de que sus desafíos diarios tienen bien poco que ver cón su capacidad para definir abstracciones o implementar algoritmos, sino que la mayoría del tiempo se pierde en averiguar qué valores de entrada necesita una herramienta, o dónde hay un defecto software, o cual es la forma correcta de la cadena de conexión a una base de datos.

La programación por pares es la forma más eficaz de reducir los tiempos muertos de los programadores, principalmente por los siguientes motivos:

1º) Cuando dos programadores trabajan juntos en la misma tarea es menos probable que se queden bloquedas en un punto ciego.

2º) Cuando dos programadores trabajan juntos en el mismo diseño e implementación es menos probable que haya que cambiarlo a posteriori.

3º) Cuando dos programadores trabajan juntos es más difícil que se distraigan con su Whatsapp o saliendo a fumar.

4º) Cuando dos programadores completan un entregable juntos no es estrictamente necesario llevar a cabo una revisión posterior que tendría que esperar a que un tercer programador, que en principio no sabe nada del entregable, esté disponible.

La programación por pares es un arte en sí mismo. Pocos equipos la hacen porque pocos gerentes creen realmente en ella y porque pocos programadores están psicológicamente preparados para programar en pareja. Además yo no me he encontrado dos equipos que la hagan igual. Y para colmo, algunas de las recomendaciones de su práctica ortodoxa, como por ejemplo que el controlador y el navegador cambien de rol con frecuencia, en mi experiencia resultan en un puto desastre.

Desbloqueo de motivos políticos

Nada se puede hacer en un proyecto donde no hay voluntad política de hacer algo. Esto no es algo que se pueda solucionar a nivel operativo o táctico. Normalmente lo que sucede es que la gente tiene miedo de ser hallada culpable de haber cometido algún error o haberse saltado algún procedimiento. Por lo que sé, esto es especialmente cierto en los países anglosajones donde los compañeros de trabajo se pasan el día buscanndo dónde pueden pillar a otro. Microsoft llegó a hacerse tristemente famosa por su nefasta política de recursos humanos basada en un «diezmo romano» mediante el cual los programadores que no alcanzaban el nivel del equipo eran sistemáticamente despedidos. Esto condujo a grupos de programadores que estaban más preocupados por no quedar los últimos de la lista que por hacer nada producitivo y muchísimo menos arriesgarse ha hacer algo que pudiere fallar.

CAPEX vs OPEX en la asignación de recursos

Casi todas las empresas tienen dos tipos de costes informáticos: los costes fijos operacionales mes a mes (OPEX) y los costes variables soportados por una contrapartida de ingreso de un cliente (CAPEX). En servicios informáticos, el coste variable no importa siempre y cuando se le pueda aplicar un margen de al menos un 40%. Es decir, si se lo pueden repercutir al cliente final entonces a los proveedores les da igual cuánto se tengan que gastar en proveedores y subcontrataciones. Lo que no le da igual a los proveedores de informática (ya sean externos o departamentos internos) son sus costes fijos de operaciones. Entonces tratan de minimizar los costes fijos.

Esta razón financiera ha creado dos grandes grupos de informáticos: la «tropa regular» (OPEX) y los «mercenarios» (CAPEX). Como los esfuerzos para ahorrar costes se concentran en OPEX, frecuentemente los servicios de operaciones y administración se convierten en un cuello de botella porque están infradimensionados con respecto a las necesidades que los equipos de desarrollo cuyo coste es directamente repercutible a un cliente.

Conclusiones

La autogestión de equipos ha sido un salto cualitativo hacia adelante en la productividad y la predictibiliad, pero no basta por sí misma. Es preciso evolucionar de los equipos autogestionados a los equipos verdaderamente autosuficientes. La forma más sencilla de conseguir esto es eliminar dependencias de terceros. Los tiempos muertos que afectan a la productividad no sólo se encuentran en las uniones entre eslaboles de la cadena de producción sino que pueden estar dentro de alguno de los eslabones. Por consiguiente, es necesario optimizar tanto a nivel global como microgerencial.

Post relacionados:

Teoría de Restricciones aplicada al desarrollo de software.
Las zonas grises de Agile.
Muerte por agilismo.
Metodologías basadas en la gestión de expectativas.

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

Los siete grandes errores cometidos durante la búsqueda de talento real

Chuck Norris Cada vez que escucho la palabra “talento” en boca del responsable de recursos humanos de una empresa tengo que agarrarme la barriga para no partírmela de la risa. La razón es que en más de 20 años de ejercicio profesional con más de un centenar de empresas todavía no he encontrado ninguna compañia que disponga de la cultura y procedimientos para gestionar a personas verdaderamente excepcionales.

Primer error: Buscar una persona para cubrir un puesto.

No se puede buscar una persona excepcional para cubrir un puesto ordinario. La única forma razonable de contratar a una persona que se sale por completo de lo común es crearle un puesto totalmente a medida. Pero estos puestos simplemente no existen en las empresas ni hay normalmente posibilidad alguna de crearlos.

Segundo error: Pensar que encontrar el candidato correcto empieza por un riguroso proceso de selección.

La moda actual es puntuar el curriculum mediante palabras clave y años de experiencia y hacer pasar a los candidatos por una serie de absurdas pruebas previas seguidas de cuatro o seis entrevistas. De entrada, puntuando el curriculum una empresa nunca contrataría a alguien como Steve Jobs debido a que los genios en tecnología casi nunca tienen un expediente académico brillante. Seguidamente, puedo afirmar por experiencia propia que los mejores profesionales senior se burlan de los test mientras comparten un café. Y por último, cuantas más entrevistas tenga que superar un candidato excepcional mayores son las probabilidades de que algún idiota vete su contratación. A los candidatos excepcionales hay que contratarles con el hígado y el corazón, no con la cabeza, pues ellos tienen mucha más cabeza que cualquiera que les entreviste.

En mi experiencia, la técnica más eficaz es la “criba de becarios”. Consiste en identificar de forma temprana a gente joven que se sienta motivada por hacer algo en la empresa sin importar demasiado la pinta que tenga cada uno a priori. Por cada puesto a cubrir, lo ideal es incorporar entre 4 y 10 becarios durante 3 o 6 meses y darles una oportunidad para obrar con cierto grado de libertad. Seguidamente, dejar que la selección natural señale cuales de ellos son los más idóneos y descartar al resto.

Tercer error: Tratar de motivar con stock options y medallitas del Niño Jesús.

Las personas inteligentes pueden llegar a hacerse muy ricas, pero rara vez están motivadas en primer lugar por el dinero. Si el candidato es lo bastante listo, sabrá que las stock options la mayoría de las veces son una trampa para ratones. Por otro lado, a mi hijo, quien tiene actualmente 7 años, le dan con frecuencia gold badges y otras chucherías como recompensa en el colegio, y funcionan muy bien, con un niño de 7 años, pero es ingénuo pensar que las palmaditas en la espalda y una foto en la puerta como «empleado del año» servirán para motivar a alguien excepto a quien tenga una necesidad de reconocimiento público más allá de lo mentalmente saludable.

Las personas excepcionales lo que suelen desear es poder dedicarse a aquello que les apasiona. Es posible que este deseo esté alineado con los intereses de la empresa y exista una sinergia. Pero ningún genio se sentirá motivado de contribuir a crear un producto que considera una birria, ni tampoco le entusiasmará la idea de trabajar para que con el incremento de valor de las opciones sobre acciones de su jefe éste se compre un descapotable.

Cuarto error: Pensar que los mavericks tienen alguna cabida en las empresas.

A los norteamericanos les encantan los mavericks en la gran pantalla. Los tipos como Chuck Norris, Steven Seagal o Silvester Stallone que se pasan las reglas por el forro son sus héroes. Sin embargo, en la vida real alguien enloquece cada vez que otra persona se salta un procedimiento, sin importar lo nimia que sea la infracción, y entonces el jefe del enajenado se pone de los nervios también, y todo termina en una reunión para explicarle al díscolo por qué hay que seguir en todo momento las normas. Y así no se inventa ni se conquista nada. Las grandes empresas pueden permitirse el lujo de funcionar de esa manera porque son apisonadoras que no producen innovación sino que la compran a golpe de talonario. Tampoco la intolerancia al fracaso ayuda en nada, en general, un solo error lo bastante grave es suficiente para ser despedido, pero no es posible descubrir cosas nuevas sin cometer errores en el proceso. Entonces los empleados están más preocupados de que nunca les puedan acusar de haberse equivocado que de arriesgarse a hacer aportes significativos.

Quinto error: Poner la inteligencia emocional por encima de la competencia profesional.

Winston Churchill creo que el caso más notorio en la historia moderna sobre lo nocivo que puede llegar a ser el paradigma de la inteligencia emocional. Según sus biógrafos, Churchill era un alcohólico que pensaba que había que asesinar a Hitler antes de que se alzase con el poder en Alemania. Con 25 años (siendo corresponsal del Morning Post) Churchill se llevó a Sudáfrica 36 botellas de vino, 18 botellas de whisky y 6 botellas de brandy para cubrir la guerra de los Boers, y en sus últimos años parece ser que bebía una botella entera de champán para comer y otra más para cenar. Y eso es beber demasiado, sin ningún género de dudas, pero ciertamente hubiese sido muchísimo mejor para el conjunto de la Humanidad asesinar a Hitler en 1932. Análogamente, vivimos en una época en la cual el conflicto se intenta evitar a ultranza en las empresas, incluso aunque la ausencia de conflicto sea precisamente lo que está matando lentamente la empresa por inacción.

Sexto error: Creerse todo lo que dice el candidato que parece más seguro de sí mismo.

Un rasgo inequívoco de la ignorancia es la sensación de certeza. Las personas más inteligentes viven permanentemente llenas de dudas, los tontos en cambio siempre creen estar seguros de todo. Hay gente especilizada en el arte de superar entrevistas de selección, y reclutadores lo bastante inexpertos e ingénuos como para tragarse el cuento. En mi experiencia, al candidato que parece perfecto sobre el papel y durante la entrevista hay subrayarlo con un lápiz rojo y ponerlo en cuarentena porque normalmente es sólo un embaucador. Como mínimo, el candidato excepcional tendrá un pésimo sentido de la moda, sólo hay que ver cómo se vestía Bill Gates en sus años mozos o cómo viste actualmente Mark Zuckerberg, quizá por eso tuvo que acabar montando Facebook tras presentarse varias entrevistas vestido con una camiseta agujereada.

Séptimo error: Ignorar las necesidades holísticas del candidato.

Cualquier comercial verdaderamente bueno sabe que para vender con éxito hay que pasar un 80% del tiempo hablando de las necesidades y de la vida del cliente y sólo un 20% del tiempo hablando del producto que va a comprar. De igual forma, a la hora de reclutar un candidato excepcional hay que tener en cuenta que no es la empresa quien está evaluando al candidato sino el candidato quien está evaluando a la empresa. Sin embargo, durante el proceso de reclutamiento normalmente se omite por completo preguntarle al candidato cuales son sus necesidades. Se le pregunta por sus aspiraciones, eso sí, no sea cosa que sólo quiera calentar una silla o, peor aún, ocupar la silla de su jefe. Pero lo que pueda necesitar el candidato al reclutador le importa un bledo.

En conclusión

No se puede poner a una persona «anormal» en un puesto normal. Estas personas siempre provocarán un follonazo terrible, diciendo que es la Tierra la que gira alrededor del Sol y no al revés. Y habrá centenares de otras personas interesadas en quemar al hereje en la hoguera de las vanidades.

Las empresas no están preparadas para esta situación, porque carecen de un protocolo de actuación adecuado. Se basan en una cadena de mando que por su propia naturaleza esteriliza la innovación.

Y cómo contrapunto voy a dejar el problema que suponen los mavericks para el primer enlace de los post relacionados, sobre lo cual ya escribí casi diez años atrás.

Post relacionados:
El problema con los superhéroes.
Porqué el talento no importa en las empresas.
El perfil del empleado perfecto.
Cómo hacer entrevistas de selección.
Consejos para elegir un candidato o un puesto de trabajo
10 formas de matar las buenas ideas.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Bookmarks
Publicado en Emprendizaje, Entorno laboral, Organizando la Comunidad. Modelos de Desarrollo, Tecnología y Empleo | 2 comentarios