Libro: La economía WTF

 

wtfeconomia

Título: La economía WTF. El futuro que nos espera y por qué depende de nosotros.
Autor: Tim O’Reilly
Editorial: Deusto

El propio O’Reilly dice en el capítulo de agradecimientos que su libro es “una peculiar combinación de memorias, libro de negocios y polémica”, pero no hace justicia a las ideas que pueblan sus 404 páginas.

Sin duda es el mejor libro de no ficción que he leído en todo el año, y ha resultado una inspiración en un momento en que creo que la necesitaba. A veces un buen libro es el mejor compañero.

Aunque contiene masivas dosis de información para hablar de ideas sobre sistemas masivos y complejos como la economía global, se trata de un libro de fácil lectura pero se agradece leerlo poco a poco para ir reposando ideas.
La idea central en torno a la que gira toda la narrativa del autor, es que vivimos en un futuro asombroso que cada vez va a avanzar más rápido y de formas más inesperadas. Algo que nos va a afectar a todos positivamente… a la larga. O eso esperamos.

Justamente la huelga del sector del taxi días atrás me ha permitido ver como O’Reilly parece tener razón en muchas de sus posiciones y eso da peso al resto de ideas radicales (sí, radicales) que proclama.
De hecho, argumenta tan eficazmente sus ideas, que me ha convencido de que algunas cosas que veía como “disparates” merecen un cuidadoso debate y quizá una oportunidad. Entre ellas están la idea de poner impuestos a Google (y otras empresas), poner un impuesto a los robots, generar un nuevo tipo de empleo entre el trabajador autónomo y el asalariado, y por último tener diferentes tipos de dinero para poder comprar o vender diferentes cosas. Ideas extrañas en este momento pero que ahora creo que veremos implementadas de una forma u otra en los próximos años o de forma inminente.

A continuación algunas citas que me gustaría tener a mano:

[Acerca de las tecnologías que nos “aumentan”] Una vez que te acostumbras a cada nuevo superpoder, la vida sin el es como si tu varita mágica se hubiera vuelto a convertir en un palo.

-o-

Jeff [Bezos, de Amazon] me explicó por qué el 1-click era suficientemente original para ser patentado. No tenía nada que ver con la implementación, que él admitía que era fácil de reproducir, sino con el replanteamiento del problema. Cuando se le ocurrió lo del 1-Click, todo el mundo estaba estancado en la metáfora del carrito de la compra, porque eso es lo que haces en el mundo real. Coges un producto y lo llevas al mostrador para comprarlo. Él se dio cuenta de que en la web podía ocurrir algo totalmente distinto: lo único que tenías que hacer es señalar un artículo y ya era tuyo. […]
Camp y Kalanick [de Uber], también se dieron cuenta de una innovación clave en el pago, que iba más allá de la compra con 1-Click de Amazon: entendieron que, en un mundo dotado de sensores conectados, el mismo acto de consumir un servicio podía dar lugar al pago. Una aplicación como la de Uber sabe cuándo empieza y termina un viaje, calcula el coste en tiempo real y carga el importe a la tarjeta de crédito en cuanto termina la carrera. El poder de esta innovación aun no ha sido asimilado del todo por otros que podrían hacer uso de él.
[Por último señala que Apple Pay, 5 años después de Uber, se limita a reproducir un proceso del mundo físico en lugar de repensarlo como Amazon o Uber].

-o-

La innovación de Uber, sin embargo, fue simplificar radicalmente la experiencia de la compra. Poder pagar sin una acción visible de tal pago, igual que la capacidad de tener un coche disponible al momento, es lo que hace que la primera vez que alguien viaja con Uber en un momento WTF.

-o-

La interfaz de entrada común [las páginas dinámicas basadas en CGIs], el truco de Rob McCool para dejar que la web hablara a una base de datos back-end una tecnología instrumental para el comercio electrónico, no salió a la luz hasta finales de 1993. eBay y Amazon se fundaron 2 años después. Esto suele pasar: Steve Jobs se opuso originalmente a la idea de las aplicaciones creadas por terceros para iPhone.

-o-

Estas empresas (de la nueva economía como Uber o Lyft) usan su tecnología para eliminar los puestos de o que solía ser una enrome jerarquía de gerentes (o una jerarquía de empresas individuales que actúan como proveedores), reemplazándolos por una red relativamente horizontal gestionada por algoritmos, sistemas de reputación basados en redes y dinámicas de mercado. Estas compañías también se basan en su red de clientes para controlar la calidad de su servicio.

-o-

Lo que hizo posible el logro de AirBnB, por supuesto, no fue solo la fotografía digital, que facilitaba que los arrendadores mostraran sus viviendas, sino la WWW, el pago en línea con tarjeta de crédito, y haber utilizado otros sitios que habían creado sistemas para ganarse una reputación y hacer valoraciones que ayudaban a los usuarios a establecer una relación de confianza con desconocidos.

-o-

Gene Kim describe lo que ocurre en una organización DevOps de alto rendimiento: “En vez de que unos grupos de desarrollo iniciales provoquen el caos para que después los que se encuentran en los centros de trabajo finales (por ejemplo, control de calidad, operaciones […] y seguridad […]) lo solucionen, desarrollo emplea el 20% del tiempo en ayudar a garantizar que el trabajo fluya sin problemas […] a acelerar los test automatizados, a mejorar las infraestructuras de despliegue y a garantizar que todas las aplicaciones creen telemetría útil en producción. […] No se trata solo de una práctica técnica […] Ejerce una presión continua sobre el sistema de trabajo para permitir el aprendizaje y la mejora de la organización.

-o-

Como describe Benjamin Treynor Sloss, quien acuñó el término, “básicamente, la SRE [la disciplina de Ingeniería de Fiabilidad de un Sitio web] realiza el trabajo que históricamente llevaba a cabo un equipo de operaciones, pero utilizando ingenieros con experiencia en software y contando con que estos estén inherentemente capacitados y predispuestos a diseñar e implementar automatización mediante software para reemplazar el trabajo humano”.

-o-

En los años siguientes [a 2011 cuando se fundó Code for America] ayudamos a gobiernos locales a crear una serie de aplicaciones que, como dijo Scott Silverman, participante de primer año y antiguo diseñador de Apple, eran “sencillas, bonitas y fáciles de usar”. Un sitio para elegir colegio en Boston; un sistema para localizar inmuebles abandonados en Nueva Orleans; una app de crowdsourcing para despejar la nieve de las bocas de agua que, al estar hecho con código abierto, se propagó a muchas otras ciudades y fue utilizada para otras formas de participación ciudadana.

-o-

Gracias a este proyecto [en que iteraban con prototipos de procesos en lugar de con procesos finales completos], nos dimos cuenta de tres cosas importantes. La primera: que las apps del siglo XXI solo podían ayudarnos hasta cierto punto si se creaban sobre una plataforma gubernamental del siglo XX inservible. Limitarse a poner una fachada digital sobre un sistema burocrático inútil a menudo solo empeora el problema, porque el sistema digital duplica los procesos existentes sin desarrollarlos desde cero. Antes de poder construir aplicaciones […][que mejoren el sistema] hemos de mejorar las operaciones subyacentes de los servicios de la administración. […] Lo tercero de lo que nos dimos cuenta se expresa estupendamente en un ensayo de Jake donde explica el proyecto, publicado en Medium, titulado “People, Not Data”: la empatía, no solo la tecnología, es la clave para reinventar con éxito los servicios gubernamentales. El diseño y la experiencia del usuario, no solo el big data y la programación, son destrezas esenciales. Sobre todo, los que toman decisiones gubernamentales deben ponerse en la piel de aquellos a quien se supone que han de servir.

-o-

[Sobre IA y Machine Learning y los sesgos en los datos] Las características de los datos de entrenamiento son mucho más importantes para el resultado que el algoritmo. No comprender esto es en sí mismo un sesgo que aquellos que han estudiado mucha informática previa al aprendizaje automático superarán con dificultad.

-o-

Las leyes de Estados Unidos, y de la mayoría de los países, se han hecho sobrecogedoramente complejas. La Ley de Asistencia Asequible tenía casi dos mil páginas. En comparación, la Ley de Autopistas Nacionales de 1956, que llevó a la creación del Sistema de Autopistas Interestatales de Estados Unidos, el mayor proyecto de obras públicas de la historia, contaba tan solo con veintinueve. La Ley Glass-Steagall de 1933, que reguló los bancos después de la Gran Depresión, tenía treinta y siete páginas. Su desmantelamiento llevó a la crisis financiera de 2008; esta vez, la respuesta reguladora, conocida como la Ley Dodd-Frank de 2010, tiene 848 páginas y requiere más de 400 promulgaciones adicionales, que suman en total unas 300.000 páginas de regulaciones.

-o-

En el fondo, el escritor de ciencia-ficción David Brin acertó en 1998 en su profético libro de no ficción The Transparent Society. En una era de una masiva vigilancia comercial […], la clase de privacidad que disfrutamos en el pasado se ha extinguido. Brin arguye que la única manera de responder es hacer que la vigilancia se dé en ambos sentidos a través de la transparencia. A la pregunta del poeta romano Juvenal “¿Quién custodia a los custodios?” Brin responde: “Todos nosotros”.

-o-

Ser extremadamente específico sobre los objetivos de cualquier regulación permite una discusión más franca y productiva, pues los dos extremos pueden centrarse en debatir los objetivos correctos. Y cuando llegan a un acuerdo, pueden empezar a buscar formas alternativas de alcanzar dichos objetivos, así como medir si han tenido éxito o no. También deberían definir un proceso para modificar la regulación en respuesta a lo averiguado a través de las mediciones. Y ha e haber un mecanismo para resolver conflictos entre regulaciones superpuestas.

-o-

El coronel de la Fuerza Aérea John Boyd, “padre del F-16”, introdujo el término loop OODA (el bucle “observa-orienta-decide-actúa”) para describir por qué en un combate es más importante la agilidad que la pura potencia de disparo. Ambos combatientes intentan entender la situación, decidir qué hacer, y luego actuar. Si puedes pensar más rápidamente, puedes “entrar en el bucle OODA de tu enemigo” e interrumpir su toma de decisiones.
“La clave es esconder tus intenciones y hacerlas impredecibles para tu oponente mientras que al mismo tiempo determinas sus intenciones -escribió Harry Hillaker en el panegírico a su colega, Boyd-. Es decir, opera a un ritmo más veloz para generar condiciones rápidamente cambiantes que hagan difícil que tu adversario se adapte o reaccione a dichos cambios y que repriman o destruyan su percepción. Por tanto, un batiburrillo de confusión y desorden provoca que reaccione en exceso o insuficientemente a las condiciones o actividades que parecen ser inciertas ambiguas o incomprensibles”.
Esto es muy difícil de hacer cuando tu adversario es una máquina capaz de actuar millones de veces más rápidamente que tú. […] “Para entrar en el bucle OODA de una máquina es necesaria otra máquina”.

-o-

[Margaret Levi comenta que] “incluso cuando las redes sociales ayudan a que la gente se implique en una acción colectiva coordinándose [como en la Primavera Árabe de Egipto], eso es algo muy distinto a una organización y movimiento continuados”. [Wael Ghonim aún no tiene respuesta] sobre cómo transformar una acción coordinada y dirigida en un movimiento sostenido y una comunidad dispuesta a trabajar para resolver problemas de calado. Especialmente cuando empiezan como un conjunto de personas heterogéneo con metas contrapuestas. Puede que estén de acuerdo en deshacerse del dictador, pero ¿luego qué?

-o-

[Hablando sobre la IA y sus peligros pero concluyendo que el mercado, la economía, es el problema de base, que actúa como algoritmos sin control ni supervisión] Ya somos cautivos de una vasta máquina extendida por todo el mundo que, debido a errores en su programación fundamental, ha desarrollado un desprecio por los seres humanos, se dedica a hacerlos irrelevantes y resiste todos los intentos de controlarla. Aun no es inteligente ni autónoma, y sigue dependiendo de su asociación con los humanos, pero cada día que pasas es más poderosa e independiente. [Los mercados financieros] se han convertido en una máquina que sus creadores ya no entienden en toda su complejidad.

-o-

Si la tecnología se está usando para reducir costes en lugar de para empoderar a la gente y alcanzar el éxito, no es porque eso sea lo que quiere la tecnología, sino porque lo exige el sistema jurídico y financiero que hemos creado.

-o-

Los ejecutivos no pueden limitarse a protestar porque no sin capaces de contratar a la gente adecuada. Tienen que asumir la responsabilidad de capacitar a la gente que necesitan para los empleos del futuro.

-o-

Tim Hwang, un programador que también está formado como abogado, me dijo que cuando trabajaba en un bufete de abogados se propuso demostrar que su labor estaba obsoleta: “Todos los días, se me daban una serie de tareas y todas las noches me iba a casa y escribía programas para que hicieran dichas tareas por mí la siguiente vez que las encargaran. Cada vez fui más eficaz a la hora de hacer el trabajo más rápidamente, y empezó a convertirse en un problema para el bufete, porque su modelo empresarial depende de las horas facturables. Renuncié justo antes de que me despidieran”.

-o-

Incluso los lenguajes e interfaces “modernos” son solo una etapa intermedia [hacia la IA]. Google, que emplea decenas de miles de los ingenieros de software más solicitados del planeta, se está dando cuenta de que necesitan volver a formar a esas personas en los nuevos campos del aprendizaje automático, que utilizan un planteamiento totalmente diferente de la programación: capacitan modelos de IA en lugar de escribir un código explícito. Y no lo logran enviándolos de nuevo a la universidad sino a través de una formación.
Esto destaca un punto que he observado una y otra vez a lo largo de mi carrera: la tecnología se mueve más rápidamente que el sistema educativo. […] Este desfase fue la clave del éxito de O’Reilly como editorial oficial de las tecnologías emergentes. Nadie enseñaba lo que la gente necesitaba saber.

-o-

El acceso a un mundo ilimitado de información es un aumento poderoso de la capacidad humana [como aprender un idioma, que multiplica la cantidad de fuentes de información], pero aun así tiene requisitos previos. Antes de que pudiera aprender a preparar el exquisito postre mirando un vídeo de YouTube, mi hijastra tenía que saber utilizar un iPad, tenía que saber cómo buscar en YouTube y conocer que había a su disposición un mundo entero de contenido. En O’Reilly, llamamos a esto alfabetismo estructural. […] Alguien con instrucción estructural conoce lo que está buscando, pues dispone de un mapa funcional de cómo deberían funcionar las cosas. Los que no tienen ese mapa están indefensos.

-o-

[Bessen observa que] La práctica común de los economistas de definir a los “trabajadores cualificados” como aquellos con cuatro años de universidad es especialmente equívoca. Las destrezas necesarias para trabajar con una nueva tecnología a menudo tienen muy poco que ver con los conocimientos adquiridos en la universidad”.

-o-

Para muchos tipos de programación, la gente necesita el equivalente de la formación profesional en lugar de una ingeniería de software avanzada o un grado en matemáticas. Y eso es exactamente lo que vemos con el auge de las academias y campamentos de formación de programación.

-o-

Trabaja en algo que te importe más que el dinero. […] Deberías ver el dinero como combustible para lo que realmente quieres hacer, no como un objetivo en sí mismo […], debes prestarle atención o acabarás en la cuneta, pero un negocio exitoso […] no debe convertirse en una gira por todas las estaciones de servicio. […] Piensa en lo que realmente valoras […][como emprendedor] te ayudará a construir una mejor empresa. Si vas a trabajar para otra persona, el tiempo que pases entendiendo tus valores te ayudará a encontrar la clase de compañía o institución para la que trabajar, y cuando la encuentres, para realizar un trabajo mejor. […] No temas pensar a lo grande. […] Resuelve el problema más grande que puedas. […]
Crea más valor del que captures. […] Piensa a largo plazo. […] Aspira a ser mejor mañana de lo que eres hoy.

-o-

Hay una disciplina de gestión diseñada específicamente para abordar [la planificación del un futuro incierto]. Se llama planificación de hipótesis [y] da por sentado que el futuro es incierto, pero también destaca que hay tendencias profundas que conforman el futuro que podemos observar y tener en cuenta. Algunas son casi seguras -crecimiento de la población y demografía, por ejemplo […]- mientras que otras, como elecciones políticas, innovaciones tecnológicas y ataques terroristas, nos sorprenden constantemente. [Esta disciplina] da por sentado que a los seres humanos les resulta difícil imaginar un futuro radicalmente diferente del presente.

Anuncios

Generalistas, Especialistas y Cynefin Framework

IMG_20180422_160246218

Barbie™ es especialista-general. Es (entre otras cosas) astronauta, informática, médico y cocinera. Es especialista en todo, pero desafortunadamente no es real: los seres humanos tenemos que conformarnos con ser, o bien especialista en un conjunto muy reducido de áreas, o bien generalistas en varias.

Dando vueltas a las dinámicas de trabajo de personas con diferentes experiencias, esperaba poder escribir un post que me ayudase a identificar cuándo es mejor ser un generalista o un especialista, o cuando conviene contar con más o menos de unos y otros en un equipo.

El tema podría estirarse mucho y existe una gran cantidad de información sobre muchos de los temas relacionados, pero creo que lo que he escrito en este post es suficiente para mi propósito.

Empleo el término “especialista” en lugar de “experto“, como he visto hacer en otros artículos, porque creo que la diferencia fundamental entre “generalista” y “especialista” es cómo distribuyen su experiencia: el generalista tiene mucha experiencia distribuida en muchas áreas; el especialista también tiene experiencia, pero enfocada en un solo área o nicho. Es decir, no se trata de tener mucha experiencia, sino del tipo de experiencia y conocimientos que acumulamos. Es una diferencia cualitativa.

Es importante entender que no existen los generalista o especialistas puros, todos tenemos un poco de ambos. Y también hay que tener en cuenta que nuestros conocimientos varían con el tiempo en base a experiencias pasadas, situación personal, etc. Lo que impide encasillar a alguien en uno u otro perfil de manera indefinida.

Cómo son Especialista y Generalista

El especialista puede actuar sobre algo en particular en su área de conocimiento. Cree saber mucho o todo de su área y extrapola (generalmente mal) al resto. Tiende a no saber que no sabe. Tiende a intentar actuar en solitario. Tiene seguridad en lo que hace y desconfía de lo que no conoce o se sale de sus mecánicas de trabajo. Tiene una visión parcial y busca optimizaciones locales. Evita los grandes cambios.

El generalista puede dirigir y llegado el caso actuar al tener una imagen del contexto y una base de conocimientos, pero ejecuta de forma menos eficiente que un especialista. Sabe que sabe “poco” y tiende a trabajar desde hipótesis que hay que validar. Intenta actuar en equipo. Duda de todo y tiende a anteponer las pruebas a los argumentos. Tiene una visión holística y sistémica.

Cuándo ser o emplear uno u otro

El generalista será más efectivo al ver la foto completa (o al menos una foto amplia) del problema, su contexto y ramificaciones.

El especialista será más eficiente cuando actúe en su campo, resolviendo un problema concreto y definido de forma rápida y limpia aunque tenderá a ignorar el contexto, generando eficiencia local a costa de la del sistema.

Cómo funcionan los grupos de Generalista y Especialistas

1. Equipo de generalistas. Efectivo pero lento. Dales suficiente tiempo y te resolverán los problemas para siempre. Incluso puede que problemas que ni sabías que tenías. En entornos con muchos interrogantes o cambios, o entornos con mucha integración con terceros, posiblemente funcione mejor que otros.
2. Equipo de especialistas. Eficiente pero inefectivo. Dales problemas concretos y acotados a su área y te los resolverán en poco tiempo. Si no les das instrucciones detalladas de lo que quieres, probablemente te generen problemas nuevos. En entornos estables y bien conocidos y planificados (sota, caballo y rey) posiblemente funcione bastante bien.
3. Equipo con más generalistas que especialistas. Frustración de los especialistas ante la falta de velocidad o exceso de “charla”. Efectivo pero lento. Habrá fricción entre unos y otros y puede que sobrecarga de los especialistas en determinados momentos. Parálisis por análisis en según qué casos.
4. Equipo con más especialistas que generalistas. Tendencia a actuar antes de pensar. Frustración de los generalistas al disparar antes de apuntar. Fallos de coordinación e integración. Tendencia a mantener la gente ocupada y a obtener resultados técnicos en lugar de obtener resultados de negocio.

El contexto es importante

Hace tiempo que quería hablar del marco de trabajo Cynefin tras leer sobre él en los blogs de Jerónimo Palacios y Javier Garzás. El post de Garzás me parece el más claro y simple para quien quiera echarle un ojo, pero en la Wikipedia (en inglés) hay toda una entrada el respecto para profundizar.

Este framework nació en 1999 y actualmente se emplea en ejercicios de formación de Scrum para “entender y explicar por qué distintos enfoques de trabajo y de hacer las cosas, funcionan bien en un entorno y en otro no“.

En esencia es un método de toma de decisiones, y creo que puede servir para identificar cuándo es mejor tener (o comportarse) como generalistas o como especialistas.

En mi opinión, cuando estamos en los dominios Obvio o Complicado, los especialistas son necesarios (quizá en solitario, quizá liderando un grupo o quizá siendo mayoría en el grupo). Sin embargo, para los dominios Complejo, Caótico y la zona Desordenada, parece mejor contar con generalistas.

En mi caso, puedo decir que me gusta el dominio Complejo y tiendo a automatizar todo lo que esté en el Obvio para no tener que hacerlo. La zona Desordenada es algo que detesto, por lo que trato de orientar mi trabajo para salir de ella lo más rápidamente posible. Supongo que todo esto me identifica como generalista.

Conclusiones

En el mundo del software (y todo va camino de ser software), los cambios se suceden con velocidad de vértigo, y por lo tanto la mejor opción parece ser el contar con generalistas para poder adaptarse con agilidad a lo inevitable.

Sin embargo, para poder resolver los problemas más típicos de manera eficiente y que una empresa pueda funcionar en el día a día, es necesario tener al menos un especialista en la operativa o problema más común de la empresa. Por ejemplo, merece la pena tener especialistas en gestión de proyectos si tu negocio se basa en proyectos, o en contar con un especialista de bases de datos SQL si muchos de tu trabajos usan bases de datos SQL.

Todos los trabajos que encajan en el dominio de los Obvio van a ser automatizados, así que es mejor evitar esa zona como la peste.

Para terminar

Como decía al principio, no hay perfiles puros, por lo que mi apuesta es tratar de ser especialista en al menos uno de los problemas más comunes de mi empresa y emplear el resto de mi tiempo y esfuerzo en aprender y experimentar cosas diferentes de esa especialidad. O como dicen los libros de autoayuda: salir de mi zona de confort.

Esto me ha permitido realizar una transición ordenada de algo de decadencia a algo en crecimiento y consolidación. En mi caso he realizado me he ido especializando en desarrollo .NET, despues en desarrollo y adminstración de SharePoint. Desde SharePoint a desarrollo y administración en Office 365 y de Office 365 a Azure, donde el perfil de arquitecto te exige ser un generalista.

Pero eso es otra historia. Y aun me quedan más de 40 años de trabajo. Espero.

 

 

 

Paradigmas de organización y estrategias de rentabilidad

Hace un par de días estuve consultando (en papel) el “Manual de la sociología del trabajo y de las relaciones laborales” (H.-D.Köhler y A. Martín Artiles) donde me topé con un capítulo titulado “Paradigmas de la organización del trabajo” que llamó especialmente mi atención.

En el capítulo se habla de diferentes paradigmas, entre ellos “taylorismo” y “lean”, muy relacionado con el mundo de la fabricación industrial y las cadenas de montaje pero también con el desarrollo ágil de software.

El libro es descriptivo, no prescriptivo, es decir: solo enumera, describe y comenta contexto, ventajas y críticas de los diferentes paradigmas y sus implementaciones. Pero aun así me ofreció una visión diferente de la que solemos ver en talleres y charlas de desarrollo ágil. Una visión más coherente con la realidad de los equipos que he conocido.

Algunas de las cosas que se comentan son:

  1. Que “ninguno de estos modelos ha funcionado según ‘el libro de texto’ de las escuelas de negocio, ni siquiera los casos de Ford, GM o Toyota”. Esto cuadra con la discusión sobre si hay que adaptar Scrum a la organización/equipo o si no funciona porque “no se está haciendo Scrum de verdad”. En la realidad ningún paradigma se ha seguido de forma “pura”, sino en formas híbridas para adaptarse al contexto.
  2. Las metodologías “lean” derivaron en un ultra-taylorismo. Aun peor que el taylorismo al que pretendía sustituir, debido al control absoluto que establece a base de visibilidad y transparencia. Este control generó diversas críticas en los entornos industriales de los ’90 por el estrés que provocaba en los trabajadores. Cuadra con el sobre nombre de “Hacienda Scrum” que he llegado a oír: Scrum vista como esclavos recogiendo algodón de sol a sol, día tras día.
  3. Existe otro paradigma (el último que comenta) denominado “sistema de producción reflexivo”, también llamado Volvoismo o Kalmarismo por la empresa (Volvo) y lugar (Kalmar) en que nació: la planta Volvo-Udevalla. Al parecer quedó solo en un experimento por diferentes motivos, entre los que están las operaciones contables en que se le imputaban costes ajenos (un clásico de muchas empresas). Al parecer los equipos eran muy autónomos, permitían una flexibilidad enorme en la producción y se asemejaban más a talleres “neoartesanos” que a naves industriales. Un modelo no exento de críticas en cualquier caso.
  4. Se pueden distinguir paradigmas de organización en función de sus “estrategias de rentabilidad”, es decir: según como buscas ganar dinero tiendes a organizar las cosas de una u otra forma. Una empresa que gana dinero por volumen (paradigma fordista) o por reducción de costes (paradigma toyotista), harán cosas diferentes y le irá mal aplicando cualquier otro paradigma. Esto cuadra muy bien con mi experiencia y sé que sin entender esto es fácil aplicar cosas que dañarán a la empresa.
  5. Parece claro que el éxito o fracaso de cualquier organización depende de muchos factores y el paradigma que emplee puede ser tanto una consecuencia como una razón de éxito o fracaso. Los contextos en que se mueven las organizaciones cambian constantemente. La política, el mercado laboral y el estado de la economía influyen y condicionan completamente los resultados y la evolución de las empresas.

Un libro interesante. Como mínimo para consultar algún que otro capítulo.

Para terminar, he generado una hoja de cálculo para tener a mano la matriz de comparación que contiene, sobre paradigmas y estrategias. Porque espero poder darle uso tarde o temprano, pero igual alguien más quiere echarle un ojo:

Paradigmas de organización y estrategias de rentabilidad

Libro: Sapiens. De animales a dioses.

sapiens

Título: Sapiens. De animales a dioses. Una breve historia de la humanidad
Autor: Yuval Noah Harari
Editorial: Debate

Recuerdo haber visto recomendaciones sobre este libro en varios sitios y por diferentes personas. Las suficientes como para resultarme atractivo. Y pensando en que sería un libro parecido a “Una breve historia de casi todo” de Bill Brison, “La cuchara menguante” de Sam Kean, o “La historia del mundo en 100 objetos” de Neil MacGregor,  lo compré con idea de tener entretenimiento para varias semanas.

Sin embargo, me he encontrado con algo más interesante. No se trata de una breve historia de la humanidad, sino de una visión alternativa a la historia que se suele contar sobre la evolución de la humanidad y la cultura. Esta visión alternativa puede llegar a ser interesante, incómoda u ofensiva dependiendo de quien lo lea y muchos de los puntos de vista que expone pueden resultar extraños o extravagantes para mucha gente. Esto último lo sé porque yo mismo he mantenido opiniones similares acerca de varios de los temas del libro durante años y siempre se han sido considerados radicales. Quizá ahora que alguien ha escrito un best seller bien trabajado al respecto, empiecen a convertirse en ideas mainstream, pero no sé si eso es algo bueno o malo.

Probablemente las ideas más interesantes que he sacado del libro han sido: 1) que la humanidad solo puede ser efectiva si comparte fantasías comunes como los derechos humanos, la democracia o el capitalismo. Y 2) que la única forma en que la humanidad evoluciona y “mejora” es colaborando de forma más efectiva en grupos cada vez mayores. La primera idea es una bofetada a varios niveles para cualquier persona moderna criada en los valores de occidente, la segunda es una idea que permite pensar de nuevas formas sobre todo tipo de temas.

De todos modos, aunque el libro es muy entretenido y en general estoy de acuerdo con las conclusiones, hay bastantes puntos de la argumentación que me parecen forzados o retorcidos para apoyar las ideas del autor. En algunos casos, por ejemplo, usa correlaciones para señalar causalidad, en otros usa las fuerzas capitalistas para explicar (a mi juicio) de manera simplista todas las expediciones marítimas desde Colón y me parece que, aunque la narrativa que ofrece es muy entretenida, mezcla tanto datos reales como deseos para sostener lo que dice, lo que resta credibilidad al libro.

Dicho esto, sigo pensando que es un libro muy entretenido con ideas poderosas e interesantes y que bien merece una lectura si te interesa la historia, la humanidad y el futuro. No creo que compre la segunda parte “Homo Deus” porque no veo qué puede aportar sobre las novelas de ciencia ficción, pero quizá busque alguna obra anterior y tendré en cuenta nuevos libros del autor.

Dado que el libro está narrado hilvanando ideas simples y normales en ideas complejas y radicales, no he visto nada citable de corta extensión, pero creo que merece la pena recomendar algunos libros comentados anteriormente en el blog que creo que pueden aportar algo antes o después de leer este libro. La lista es larga, pero creo que eso ayuda a entender la gran extensión de temática de este libro y el que no me haya cogido tan de sorpresa. Ahí va, categorizados en 4 grandes categorías:

  1. Pasado
    1. La historia del mundo en 100 objetos
    2. 1177 a.C
    3. Sociedad y cultura en la antigua Mesopotamia
    4. Innovación y tradición. Historia de la tecnología moderna
    5. El sueño del neandertal
    6. El príncipe
    7. El plan maestro
    8. El fantasma del ingeniero asesinado
  2. Mente, individuo y modelos mentales
    1. Pensar rápido, pensar despacio
    2. No pienses en un elefante
    3. El hombre en busca de sentido
    4. Las grandes revoluciones del management
    5. Capitalismo caníbal
    6. Antifrágil
    7. La tabla rasa
  3. Futuro
    1. Seveneves. Siete Evas (novela)
    2. Numerati
  4. Inclasificable
    1. El espejismo de Dios
    2. Trilogía Paralaje Neandertal: Híbridos, Humanos, Homínidos. (Novela)
    3. El cálculo de Dios (novela)

Developer Timeline 1996-2016

pope-john-paul-ii-and-fidel-castro-watching-time

Hace unos meses intenté convencer a algunos desarrolladores de que necesitaban aprender Git. Algo que desde mi perspectiva parecía obvio y urgente se tornó, pese a mis esfuerzos por argumentarlo, en imposible. Desde entonces he estado dándole vueltas al tema de la obsolescencia de las herramientas, técnicas y servicios que los desarrolladores usamos a diario y a como alternamos entre lo malo conocido y el hype del momento.

Esto me llevó a pensar en cómo “de-mostrar” a determinados perfiles técnicos de la necesidad de actualizarse, lo cual me condujo a confeccionar una “línea de tiempo” o mapa de tecnologías y herramientas de desarrollo .NET para poder observar el avance en determinados ámbitos como el control de versiones de código.

Gracias al intercambio de ideas de los Meetups en SwCraftersCLM GDG Toledo y los ánimos que me han dado desde esta comunidad para publicar el “timeline de desarrollo”, he terminado una versión 1.0 1.2 que he colgado en Google Sheets para uso y adaptación de otros equipos de desarrollo, incluso de otros stacks tecnológicos. O aprovechando que acabamos el año, para pararse a pensar qué aprender en 2017 2018.

El Excel es el siguiente: Developer Timeline 1996-2017

¿Para qué sirve?

La idea es poder usar la hoja como herramienta de 4 formas diferentes para varios objetivos:

  1. Para poder revisar en qué punto estamos de actualización técnica y ayudarnos a decidir si aprender o no una tecnología en concreto.
  2. En grupos de desarrollo. Para poder argumentar con datos objetivos frente a nuestros compañeros sobre la necesidad, o no, de reciclarnos tecnológicamente. Como mínimo debería facilitar el diálogo sin caer en el flame.
  3. En charlas. Para poder hacer una introducción simpática para todos los públicos sobre determinadas tecnologías como Core o SharePoint Framework añadiendo un contexto tecnológico más amplio que facilite el entendimiento de los problemas que resuelve.
  4. En organizaciones. Para poder establecer el nivel de actualización de una organización (la nuestra u otras) de una forma más o menos objetiva. En última instancia podría ayudarnos a decidir si embarcar en una empresa o desembarcar de la actual.

¿Qué contiene?

La hoja contiene varias categorías (eje vertical) y eventos relevantes para cada una de las categorías, repartidos por año (eje horizontal).

Me pareció adecuado empezar en 1996 por tener un intervalo amplio y “redondo”: 1996-2016. El año 1996 sirve además para poder establecer una línea base de “desarrollo viejuno”.

La información que contiene está orientada por mi experiencia y entornos de trabajo a lo largo de los años por lo que hay bastante de Microsoft, pero he tratado de mantenerlo flexible para poder adaptarlo a otros entornos aglutinando la mayoría de elementos específicos de Microsoft en su propia categoría.

Sobre las categorías, los datos y la selección

Hay muchos elementos que podría haber metido pero que finalmente he eliminado por claridad (versiones, irrelevancia…) y simplicidad.

Muchas fechas son aproximadas y en algunos casos discutibles. En general he tratado de tomar las más importantes como por ejemplo productos release en lugar de beta.

Hay bastante tecnología Microsoft debido a mi propio background y el público al que lo he enfocado, pero he tratado de mantenerlo flexible para otros stacks.

Este documento no pretende ser canónico, sino una herramienta ilustrativa de la evolución y periodos que vivimos los desarrolladores de software. Está pensado para ser modificado de forma sencilla por lo que he desistido (de momento) de hacer un gráfico SVG interactivo con D3 y JSON.

Las categorías en que he agrupado los eventos son las siguientes:

  1. Papas: Los papas de la Iglesia Católica Apostólica y Romana que hemos tenido desde el 96. Me parece interesante mostrar que hasta las organizaciones más antiguas y tradicionales experimentan más cambios que algunas personas o empresas.
  2. Efemérides: Evento de relevancia nacional o mundial. Permite replantearse la cantidad de tiempo que ha pasado entre tecnologías y los grandes cambios que han sucedido en la sociedad.
  3. Películas: Estrenos de cada año. Me parece un detalle simpático para tratar de poner en contexto el tiempo que ha pasado, en particular entre fans de Marvel como yo, y la cantidad de proyectos que pueden llevarse a cabo en 5 o 10 años.
  4. JavaScript: Aun hay gente que no quiere saber nada de JavaScript o quiere quedarse en la versión del ’99. Visibilizar la cantidad de hitos que ha tenido debería facilitar el NO poder ignorarlo.
  5. Autenticación y Autorización: Todavía tengo que explicar las diferencias entre autorizar y autenticar. En el panorama actual y dado que es necesario conocer estos temas para realizar cualquier aplicación moderna, me parece grave y por eso le he dado su propia categoría.
  6. Servicios web: Esta categoría trata de servicios web y trata de poner de manifiesto que la diferencia entre SOAP y REST en realidad son pequeñas y que deberíamos mirar más allá del hype al evaluarlas. También pone en el mapa los webhooks, que parece que son grandes desconocidos a pesar de su utilidad y antigüedad.
  7. Formatos de datos: Me pareció apropiado añadir esta categoría tras la de servicios web para señalar que son dos cosas independientes y que ya va siendo hora de aprender a usar JSON. O usar Markdown en lugar de HTML en según que contextos.
  8. Front End: Esta categoría podría ser una hoja aparte, pero he tratado de incluir estándares de facto y orientarme a desarrolladores back o full stack. He añadido asteriscos a temas de W3C para recordar que… “es complicado” asegurar en qué estado están.
  9. Gestión de código: Esta es la razón por la que comencé a confeccionar el Excel y por eso tiene un componente “fuerte” de productos Microsoft, pero dejando claro que el estándar a día de hoy es Git. De hecho, es importante mencionar que Microsoft lleva años migrado todo su código abierto a Github.
  10. Servicios de terceros: Incluyo una lista de servicios de terceros relevantes para perfiles técnicos. Estos deberían contrastar con la antigüedad de algunas de las herramientas de algunos técnicos. Si, por ejemplo, alguien usa Dropbox (2008) o Google Drive (2012), no podrá argumentar que Git es demasiado moderno (2005).
  11. Microsoft Stack: categoría específica para los que usan el stack de Microsoft, por lo que en adaptaciones a otras empresas debería adaptarse. El “baseline” es Outlook porque me pone nervioso ver que no se sabe usar a nivel básico (carpetas, convocatorias, respuestas automáticas…) y es una herramienta que todos usamos a diario para trabajar en empresas, en particular con el stack Microsoft.
  12. S.O.: Sistemas operativos desde el ’96. Con especial detalle en el ámbito Windows, claro. Porque todavía hay quien quiere volver a W7 por pura resistencia al cambio.
  13. Dispositivos Móviles: He tratado de sintetizar el panorama en dispositivos móviles. Al estar tan unidos hardware y software he mezclado ambos elementos. Evidentemente Windows Phone/Mobile se queda fuera.
  14. Lenguajes: Es interesante ver que los lenguajes de back-end son bastante estables, pero no inmutables.
  15. Entorno de ejecución: Parece que todo es alguna variedad de la máquina virtual de Java o el que tiene que funcionar sobre el CLR de .NET y no solo no es así, sino que el panorama parece que va a cambiar cada vez más. Estuve tentado de introducir Docker también, pero los contenedores son otra historia y aun me parece pronto para añadirlos, quizá el año que viene o quizá en otra categoría de DevOps.

Como nota curiosa no he notado nada interesante en 2003 pero si muchos eventos importantes en 2009: el embrión de Azure y Office 365 (BPOS), Android 2.0 (la primera versión buena), Windows 7 (el más querido), ECMAScript 5 (el JavaScript de la nueva web), Bitcoin (y la explosión del blockchain), GO (del que Javier nos dará una charla pronto) y Node JS (¿el nuevo Java/PHP?) del que vimos como se usaba en producción en las Lambdas del AWS de BrainSINS en el último Meetup.

En resumen

Como decía el personaje de Will McAvoy en The Newsroom: El primer paso para resolver un problema es reconocer que hay uno (minuto 5:00, pero el speech completo es impresionante).

Mi intención inicial era mostrar como Git es una herramienta indispensable para el desarrollador de .NET de hoy, comparándola con eventos relevantes del pasado reciente de forma objetiva y amigable.

Aunque parece que he conseguido construir esa herramienta, creo que he generado algo más potente, una especie de minicuadrante de Gartner del desarrollador .NET (y en general) que podría servir para animar a algunos técnicos a reciclarse, y que me ha ayudado a ampliar mi visión estratégica para 2017 así como a mejorar mi planteamiento como arquitecto de soluciones y líder técnico. O como mínimo me ha aclarado panorama bastante ahora que parece que todos andamos perdidos de stack en stack y de framework en framework especialmente en el mundo Microsoft.

Para terminar

Al revisar mis propios artículos me parece reconocer que en el universo Microsoft, 2016 es una repetición de 2012. Da para otro artículo, pero si estás más o menos al día creo que podrás ver las semejanzas entre el panorama actual (Azure, Office 365, Hololens, ARM, Open Source…) y el que describí en 2012 en: El desembarco de Normandía.

Y si te ha interesado este artículo, es muy probable que te interesen mis artículos: Breve historia del desarrollo de software de 2012 y mi predicción sobre el futuro de Blackberry, iPhone y Palm en 2007: La muerte de Blackberry.

Este año, sé un héroe

En 2012 no me decidí a publicar esto debido a su escasa longitud. Se trata de un texto que traduje de Philip Zimbardo acerca de las acciones heroicas en el contexto de su proyecto Heroic Imagination. De cómo podemos mejorar la sociedad.

Creo que el inicio de este año y dada la situación actual nacional y mundial, es un buen momento para recordarlo.

Una acción heróica es:

  1. Iniciada voluntariamente;
  2. Realizada en servicio de una o más personas o de la comunidad como conjunto;
  3. Involucra un riesgo al comfort físico, estatus social, o calidad de vida;
  4. Se inicia sin la expectativa de una ganancia material

Los heroes reactivos son personas que actuan en el momento, usualmente de manera espontánea. Tras lo cual, un heroe reactivo a menudo dirá algo como “no tuve tiempo de pensar, simplemente lo hice.”

Un heroe proactivo es alguien que realiza continuos esfuerzos a lo largo del tiempo para exponer operaciones de fraude, montajes, o corrupción. Tales heroes son más efectivos cuando forman redes con otros que comparten sus valores, atenuando por tanto las críticas (de defensores del sistema malvado) de que son fanáticos o están equivocados.

Texto original:

Heroic action is:

  1. Engaged in voluntarily;
  2. Conducted in service to one or more people or the community as a whole;
  3. Involving a risk to physical comfort, social stature, or quality of life; and
  4. Initiated without the expectation of material gain

Reactive heroes are people that act in the moment, usually spontaneously. Afterwards, a reactive hero will often say something like “I didn’t have time to think, I just did it.”

A proactive hero is someone that makes continual efforts over time to expose the operation of fraud, deception, or corruption. Such heroes are more effective when they form networks with others who share their values, thereby lessening the criticism (by defenders of the evil system) that they are fanatics or misguided.

Libro: La eficiencia en el sector público. Un enfoque sistémico.

seddon

Titulo: La eficiencia en el sector público. Un enfoque sistémico. El fracaso de las reformas y un manifiesto para una alternativa mejor.
Autor: John Seddon
Editorial: Triarchy Press Ltd

Este es uno de los libros escritos por John Seddon, al que conocí vía Hermanni Hyytiälä y que empezó a llamarme la atención a base de citas de este y otros autores.

Aunque las ideas que defiende Seddon son ideas que yo mismo defiendo desde hace tiempo (el sistema sobre el individuo, la responsabilidad de la dirección de entender sus organizaciones, etc.), me temo que este libro no resulta demasiado convincente inicialmente y parece quedarse a medio camino entre la crítica a la Administración Pública inglesa y la propaganda de la empresa de consultoría de Seddon, Vanguard.

Sin embargo, una segunda lectura y algo de reflexión me han dejado pensando en el alcance del cambio de paradigma que propone. Uno que incluso a mi (que ya estoy convencido del fondo de la idea), me cuesta aceptar. Así que aunque el libro me haya resultado inicialmente decepcionante (respecto a la idea que traía) y aunque la edición española esté plagada de erratas, los casos de éxito de Seddon y las ideas que va plantando resultan interesantes y radicales tanto desde el punto de vista de alguien interesado en diseñar mejores servicios, como desde el punto de vista de un usuario de servicios.

Supongo que aunque no lo parece, el libro contiene ideas y conceptos demasiado diferentes a los manejados actualmente en las organizaciones como para dejar al lector bastante desconcertado, incluso conociendo de antemano el poder de un sistema.

Así que si el futuro lector entiende lo tóxico que pueden llegar a ser los objetivos, la diferencia crucial entre “propósito” y “objetivo” o si quiere ver los problemas que tiene la Administración Pública inglesa, y por qué llamar a un call center suele ser traumático, te recomendaría leer este libro, pero cuidado con las expectativas. Y recomendaría una lectura pausada, casi un estudio, con repaso incluido.

PD: inicialmente esta crítica iba a ser muy negativa, ha sido la relectura de las notas que he ido tomando para añadir las citas, las que me han hecho cambiar de opinión. La verdad es que me ha sorprendido mucho.

Algunas citas para el recuerdo:

Solo existen dos grupos en la sociedad que se comportan de una manera racional motivada por el propio interés en todos los experimentos. Uno son los economistas, el otro los psicópatas.

-o-

El programa de arrendamientos basado en la libre elección del gobierno partió de una idea que se había desarrollado en Holanda, se modificó para adaptarla a las prácticas existentes y, como resultad, la despojó de su valor fundamental. Este es un clásico ejemplo de copiar sin conocimiento, sin haber entendido previamente el concepto y los principios del diseño original. Posteriormente se han utilizado investigaciones insuficientes para apoyar el programa, como si la prioridad de la investigación fuera la de lograr el apoyo a la medida política en vez de aprender lo que funciona. Es una característica recurrente de la Administración.

-o-

Los directores tienden a negar los hechos o buscan una explicación racionalista a las conclusiones no deseadas. […] Los directores son un producto del propio sistema. Para sobrevivir en el actual régimen de las Administraciones Públicas, necesitan aprender lo que es lícito según la normativa, que será también deformada para evitar problemas; después de todo, serán juzgados por sus objetivos. A los directores de áreas les sorprende el hecho de que el rendimiento está enteramente bajo su control, pues son ellos los que dirigen el sistema. Les causa aun más conmoción aún descubrir que aquello que se les ha ordenado hacer, en realidad es lo que causa de manera inevitable que el rendimiento sea deficiente.

-o-

Existen dos tipos de consulta que interesan a un pensador sistémico: las consultas de valor y las consultas por errores del servicio (demanda fallo). La consulta de valor es una consulta que deseamos, una demanda para cuya resolución se ha creado el servicio. En el caso de las subvenciones a la vivienda, existen solo dos consultas de valor: “¿Puedo hacer una solicitud?” y “mis circunstancias han cambiado”.
La consulta por errores del servicio, la demanda fallo, son las preguntas causadas por algo que no se ha hecho o un fallo cometido a los ojos del cliente. El seguimiento del progreso (“¿qué pasa con mi solicitud?”, “no se como rellenar el formulario”), tener que presentar documentos ya entregados anteriormente, tener que hacer varias visitas; todos estos casos representan consultas y, por tanto, más trabajo causado por un fallo del servicio desde el punto de vista del solicitante.
[…]
Quizá no es sorprendente que la mayoría de consultas por errores se hacen por teléfono, que es el medio más accesible para solicitantes de hacer el seguimiento. Estudiar las consultas que se hacen personalmente (lo que requiere que los directores se sienten en el lugar en el que se presta el servicio y desarrollen una tipología de consultas por clientes) sirve para darse cuenta de lo malo que es el servicio desde la perspectiva del cliente. En una cola típica de una ventanilla de subvenciones se verán solicitantes que vuelven allí por quinta, sexta e incluso décima vez. A menudo se les dice que tienen que traer un documento que ya habían entregado, puesto que se ha perdido o se encuentra en un montón de expediente esperando ser procesado electrónicamente. En un ejemplo, el 20% de los documentos que se guardaban en un sistema electrónico estaban duplicados. Nótese que el problema no es una falta de diligencia por parte del personal; la pérdida de documentos es un problema del diseño del sistema. [más adelante se menciona que el “objetivo” de atender en menos de 15 minutos al solicitante obliga al empleado a quitarse de encima a la gente pidiendo formularios, etc.]

-o-

En 1990, escribí por primera vez sobre el fenómeno de las consultas motivadas por errores (demanda-fallo). Me alegra comprobar que la idea se extiende, pero también me preocupa el hecho de que se haya introducido en el pensamiento de mando y control (existe actualmente un objetivo para reducir las consultas por errores) en vez de llevar a los managers a darse cuenta de que el fenómeno es sistémico. Las consultas por errores solo pueden eliminarse al cambiar la manera en la que se organiza y gestiona el trabajo.

-o-

Al descubrir que su bondad o maldad se juzga según las estadísticas de cumplimiento de la actividad, aprenden con frecuencia la manera de falsear las cifras para eludir el foco de atención. Los trabajadores se centran en la supervivencia y no en contribuir a la mejora; el sistema los motiva a agudizar su ingenio para trabajar por sus objetivos. [Los directores] encuentran pruebas de engaño y argumentan que, como se ha comprobado, es necesario el control (o más controles). Los directores desarrollan una visión desdeñosa de su personal.

-o-

El pensamiento sistémico prescinde de toda esta planificación […] no se presupone nada, excepto que no sabemos con certeza cuál es el rendimiento. Los pensadores de mando y control tienen un problema con este punto. Creen que la idea de emprender un cambio sin predeterminar los resultados es estrafalaria. Sin embargo, pregúnteles y le contestarán que sus planes raramente, si alguna vez, han conseguido sus resultados; le contarán cómo se han ocultado los desastres, cómo se han alargado los plazos y cómo se han creado situaciones extenuantes. […] Aun así, prefieren tener un plan. Y yo les digo que el único plan es obtener conocimiento [el qué y el por qué de actual rendimiento del sistema].

-o-

Solo después de entender la demanda y medir el logro del propósito desde la perspectiva del cliente, es posible pasar al estudio del flujo de trabajo. Hago hincapié en este punto porque muchos directores quieren pasar directamente a la tarea de planificar el proceso, ignorando dos fuentes vitales de información: la demanda, que nos dice lo que se debe incluir en el plan, y la medición del rendimiento según los objetivos, que nos indica las prioridades.
Cuando estudie el flujo, no pregunte a la gente lo que hace, no meta a la gente en una sala y les haga escribir el flujo en post-its pegados en las paredes, no lea los manuales de procedimientos y no pregunte a los directores; probablemente sean los que menos sepan.

-o-

En las empresas de servicios, el derroche se produce de formas distintas [al que se produce en las empresas de fabricación y sus siete tipos de derroche]. Las herramientas entorpecen el pensamiento.

-o-

[Citando a W. Edwards Deming] Sin un propósito claro solo podemos cavar más profundamente el foso en el que estamos metidos. El trabajo duro y nuestros mejores esfuerzos no van a sacarnos del foso.

-o-

Esto me lleva a mencionar las ideas de Ohno [padre del sistema de producción de Toyota o Lean como se ha puesto de moda ahora y el kanban] sobre las mejores prácticas. Consideraba que este concepto era peligroso e inducía a equivocaciones. El calificativo de “mejores” tiene una connotación estática, es decir, se trata de algo “bueno” que debería ser copiado. Ohno afirmaba que, cuando alguien escucha el término “las mejores”, debería pensar en “mejores que”, porque todo puede mejorarse. En segundo lugar, todo lo que uno necesita saber para mejorar lo encontrará en su propio sistema. Si busca en otro lugar, estará buscando en el lugar equivocado.

-o-

Ohno demostró que lo importante no es maximizar la producción de cada máquina, sino tener la máquina a punto para cuando llegue el flujo de trabajo. […] El error está en la suposición de que estar activo quiere decir ser productivo.

-o-

La mejor manera de introducir la informática [como herramienta en una organización] es mediante la comprensión del trabajo como un sistema, mejorando su funcionamiento sin cambiar el sistema informático (que es tratado como una limitación o se desconecta en esta fase) y, cuando el nuevo diseño se estabilice, entonces tiramos (pull) de los recursos informáticos necesarios en el nuevo diseño.

-o-

Los gestores públicos no pueden ser culpados por hacer lo que se les dice; los responsables de las especificaciones no pueden ser culpados por hacer su trabajo, que consiste en crear especificaciones dictadas por los ministros; estos últimos se justifican apuntando a las consultas llevadas a cabo y al consejo de los consultores que, a su vez, culparán a los que se encargan de la implantación. Es un sistema que se asegura de que nadie sea responsable. Necesita una reforma radical.
El actual régimen de la Administración Pública es sistémicamente incapaz. No puede aprender. Hacen lo incorrecto porque la forma en que deciden lo que debe hacerse no se basa en el conocimiento y cuando llegan los problemas los agravan al tratar de corregirlos. Incluso si el régimen de la Administración Pública supiera lo que hay que hacer correctamente, cometería el error de promulgarlo como “la solución”, y trataría nuevamente de obligar a un cumplimiento, poniendo la responsabilidad en un sitio equivocado. Necesita responsabilizar a alguien.

-o-

La conducta de las personas es un producto del sistema, solo cambiando el sistema podemos esperar un cambio de conducta.

-o-

Este es un libro de pensamiento; no se trata de un libro de recetas, ni tampoco promete cosas que no pueden prometerse. Me solicitan con frecuencia que formule propuestas para clientes potenciales, donde incluya una previsión de los resultados a conseguir. Siempre me niego. Después de todo, a pesar de que este método puede conseguir que todas las flechas a la diana, el trabajo de los lideres es el de liderar, es decir, lanzar las flechas a la diana. En segundo lugar, es su deber estudiar su propio sistema, no el de aprender el pensamiento sistémico, sino establecer ellos mismos el margen y ámbito de mejora y retar su pensamiento para conseguir las mejoras. Además, el pensamiento sistémico se ocupa del aumento de capacidades. Como nos enseñó Deming, una mejor calidad reduce el precio, a la vez que produce una cuota mayor de mercado, un crecimiento y, por tanto, más puestos de trabajo. Aquellos que buscan la reducción de costes fracasarán; sin embargo y lo que es paradójico, las reducciones de costes son una consecuencia, un subproducto, del diseño sistémico.