¿La mejor motivación?

La sensación de urgencia.

Esa es una buena receta o un buen disparador para la transformación, para el trabajo duro, para la productividad. Sin embargo, con ser cierto, esa sensación de urgencia, quizá por constituir una frase hecha, por sonar a consultor o directivo de gran empresa, quizá no resulta todo lo acuciante que realmente es.

En su libro 'The startup way', Eric Ries, nos ofrece, sin darle ese nombre, una forma muy concreta, muy tangible, de sensación de urgencia. Y es que ya es algo más que urgencia. Se trata de supervivencia.

En concreto, hablando de startups, ésto es lo que nos dice:

There's really no substitute for being able to say "Listen, we only have enough cash to stay in business for another six weeks. I know there are lot of things we'd love to be able to do, but if we don't make at least one of these things work before then, we're doomed". It sounds stressful - and it is! - but is also liberating. It's the highest productivity way of working I've ever seen.  

Quizá este tipo de sensación de urgencia sea algo extrema. Quizá no sea tan útil para llegar a una innovación disruptiva, o para establecer una estrategia de largo plazo pero, sin duda, fuerza a poner foco, a esforzarse, a ser eficaz y productivo, al menos en el corto plazo.

Es algo así como el viejo dicho, hacer de la necesidad virtud.

Ante necesidades extremas, probablemente necesitemos foco, decisión y una productividad también extrema.

El impacto de la digitalización en la economía de un país

Como complemento al artículo anterior, en que resumía la propuesta de McKinsey para medir la digitalización de un país, y basándome en el mismo informe, 'La reinvención digital: una oportunidad para España', paso revista a otro aspecto relevante que se menciona en el informe: qué aporta la digitalización a un país.

El informe nos habla de mejoras en la productividad, la eficiencia del mercado laboral y el uso del capital y menciona cinco puntos. Son estos:

• Mejoras de procesos y operaciones habilitado por Internet de las Cosas: Se refiere la optimización, por ejemplo, de cadenas de producción especialmente mediante monitorización o también control en tiempo real de rutas. También se incluye aquí el uso de Big Data para control de inventarios. Para el caso de España valora el impacto de esta palanca en 91 mil millones de euros.


• Utilización de las tecnologías digitales para mejorar en I+D: En esta palanca se incluyen cosas como la mejora en las habilidades y velocidad para el análisis de datos (Big Data) para incrementar descubrimientos o también el uso de diseño asistido por ordenador o la impresión 3D por ejemplo para reducir el peso de aviones. En España esto se cuantifica en una oportunidad por valor de 64 mil millones de euros.


• Mejoras en la gestión de recursos: por ejemplo, gestión energética y de residuos y se ejemplifica con la aplicación de redes neuronales por una química. Esto podría suponer para España un crecimiento de hasta 4 mil millones de euros.


• Mejoras en la eficiencia del capital y uso de los activos: se habla, por ejemplo, de mejoras en mantenimiento preventivo mediante aplicaciones que indiquen el momento adecuado para realizarlo, e incluso aplicando un mantenimiento predictivo que actúe sólo cuando realmente se necesita en lugar de hacerlo de forma rutinaria. Para España se estima en una oportunidad de 24 mil millones de euros


• Uso de las herramientas digitales en el mercado laboral: permitiendo emparejar oferta y demanda en plataformas de empleo y optimizar la búsqueda de talento, lo que influye, a nivel macro, en más días trabajados y, por tanto, más productividad. También se menciona, de una forma algo genérica, la productividad de los empleados en el puesto de trabajo por el uso de herramientas digitales.

Según el mismo informe, la suma de todas estas oportunidades suponen para España, y hasta 2025, una oportunidad de entre 150 y 225 mil millones de euros, es decir, entre el 1,3% el 1,8% del PIB

La verdad es que veo los cinco puntos algo simplificados, y echo en falta  quizá una visión más amplia de las tecnologías y sus aplicaciones (se concentra mucho en Internet de las Cosas y Big Data) auqnue puede que ese presunto defecto sea más la forma de expresarlo que el análisis en sí (que no se detalla). Lo que no me cabe duda es de que las posibilidades son inmensas y que tenemos una oportunidad, y casi una obligación, de aprovechar esta oportunidad que supone la digitalización.

Efectos esperados e inesperados de la robotización

La generalización de la robotización y la inteligencia artificial, pensamos que nos va a traer una muchísima mayor productividad y, probablemente, una mucho mayor fiabilidad y calidad de lo producido. Es muy lógico y muy probable.

También pensamos que puede traer consigo desempleo o, al menos, la desaparición de muchos empleos actuales que, eventualmente, pueden compensarse con nuevos puestos de trabajo, ya sea por necesidad de nuevos perfiles o porque el aumento de productividad y riqueza genere nuevas necesidades, por ejemplo, en sector servicios. La desaparición de empleo tradicional es más que probable. Si el saldo neto de empleo es positivo o negativo parece estar más en discusión.

Sin embargo, hay una consecuencia de la robotización que no se me había ocurrido tener en cuenta hasta leer el libro 'The inevitable' de Kevin Kelly cuando cita a Rodney Brooks, antiguo profesor del MIT e inventor de la aspiradora Roomba.

Nos dice el señor Brooks:

Right now we think of manufacturing as happening in China. But as manufacturing costs sink because of robots, the costs of transportation becmome a far greater factor than the cost of production. Nearby will be cheap. So we'll get this network of locally franchised factories, where most things will be made within five miles of where they are needed.

Todo un cambio de la macroeconomía y casi de la geoestrategia. Al contrario de lo que ha sucedido en las últimas décadas, la fabricación podría volver en gran medida a los países desarrollados e, incluso, atomizarse, para minimizar costes de transporte. El razonamiento está claro: la robotización produce una tan grande disminución de los costes de producción que, en comparación, los costes que marcarán el precio serán los de transporte., Por tanto, es preferible acercar la producción hacia los centros de consumo, es decir, una polarización hacia los países desarrollados. 

Y, adicionalmente, una eventual atomización de la producción, en el sentido de que, en esa misma línea de disminución de costes de transporte, sea preferible factorías más pequeñas pero más cercanas a los principales núcleos de población.

Todo ello, por supuesto, siempre que no se produzca una disrupción en el transporte, disrupción que ahora mismo no creo atisbar, y que pudiera cambiar de nuevo el balance entre costes de producción y transporte.

La organización jerárquica como gestión de la comunicación

Muchas son las ideas que se nos pueden ocurrir para explicar el por qué las organizaciones tradicionales presentan una estructura jerárquica, una especie de árbol de poder.

Pero en el libro 'The mythical man-month' su autor, Frederick P. Brooks, Jr. nos ofrece una en que a lo mejor no habíamos pensado: la gestión de la comunicación.

La explicación es la siguiente: a medida que el número de integrantes de un proyecto u organización se multiplica, los canales de comunicación, las posibles interacciones, crecen exponencialmente. Esto hace que las organizaciones no puedan escalar porque los costes de comunicación y coordinación en seguida se convierten en inasumibles.

¿La solución?

La organización y, en concreto, la organización jerárquica.

En una organización jerárquica establecida por motivos funcionales, con criterios de división de trabajo, los trabajadores se comunican fundamentalmente con los de su misma unidad y reportan a sus responsables directos, éstos a los suyos y así sucesivamanente.

El resultado es una espectacular reducción de interacciones y, por tanto de los costes de coordinación.

Así nos lo explica el propio Brooks:

If there are n workers on a project, there are (n² - n )/2 interfaces across which there may be communication, and there are potentially 2n teams within which organization must occur. The purpose of organization is to reduce the amount of communication and coordination neccessary; hence organization is a radical attack on the communications problem.

y sobre la organización jerárquica:

The means by which communication is obviated are division of labor and specialization of function. Tree-like structure organizations reflects the diminishing need for detailed communication when division and specialization are applied.

Simple, ingenioso y casi inapelable.

Eso sí, me pregunto cómo enfocar entonces los nuevos modelos de organización, las de naturaleza matricial, y no digamos nada las organizaciones en red....

Ingeniería de software: ¿por qué es tan difícil pasar del garaje a la factoría?

Los fenómenos que se observan en el mundo del software, y en concreto, en lo relativo a la productividad, son a veces sorprendentes.

Tengo una experiencia que me demuestra claramente que la productividad entre persona y persona puede variar en órdenes de magnitud dependiendo sobre todo, creo, del conocimiento y el talento. A diferencia de muchos otros campos, conocimiento y talento (sobre todo este último) son mucho más relevantes incluso, que la motivación. Sea como fuere, las diferencias de productividad son enormes.

En otra escala, sorprende no solo la capacidad de innovación sino también la rapidez y productividad con que pequeñas empresas, a veces núcleos reducidísimos de programadores, son capaces de producir software de extraordinaria calidad, complejidad y funcionalidad y cómo, sin embargo, con frecuencia, las grandes compañías de consultoría, desarrollo o integración son lentas y producen resultados inferiores.

¿Por qué se produce esto? ¿No es contradictorio?

En su libro 'The mythical man-month', Frederick P. Brooks, Jr. analiza este fenómeno y llega a interesantes y clarificadoras conclusiones.

Primero parte del producto típico de 'garaje' y es lo que denomina un programa. Dicho programa es autocontenido y se ejecuta en la máquina de su autor y el sistema en que fue desarrollado. En este ámbito es donde suele producirse ese fenómeno de garaje, esa innovación y esa aparente productividad superior.

A partir de aquí, el autor distingue dos ejes en que ese software puede evolucionar

La primera forma de evolución es hacia un producto. Un producto es un un programa que puede ser ejecutado, probado, reparado y extendido por cualquiera. Puede usarse en muchos entornos y con diferentes juegos de datos. Para pasar del programa al producto, se debe producir una generalización, tiene que ser extensivamente probado  y debe ser documentado. Esto hace que, en estimación del autor (muy versado en el mundo del software), el producto sea tres veces más costoso que el programa.

La segunda forma de evolución es hacia lo que denomina un sistema. En un sistema los programas interaccionan de una forma coordinada y según una disciplina. Para que el programa pase a ser un componente de un sistema, debe ser escrito de forma que cada entrada y cada salida respete una sintaxis y una semántica precisas. Además, debe hacer un uso limitado de recursos, puesto que éstos son compartidos. Finalmente, debe ser probado en conjunto con el resto de componentes, lo que lleva a la aparición de errores debidos a interacciones insospechadas. De nuevo, el autor estima que un componente de un sistema es, como mínimo, tres veces más costoso que el programa aislado.

Finalmente, podemos mezclar ambas evoluciones para obtener un sistema producto que añade las complejidades de las dos evoluciones anteriores y que proporciona un resultado realmente útil... pero cuesta nueve veces más.

Es cierto que nos estamos fiando de las estimaciones del autor...pero también es cierto que sus argumentos son sólidos y las problemáticas que expresa reconocibles.

Ciertamente, pueden existir otros motivos para la menor productividad en las grandes empresas (burocracia, actividades colaterales no directamente productivas o menor motivación) pero aún así, los argumentos de Brooks parecen dar una buena explicación a por qué es tan costoso pasar de la programación más amateur o tipo startup, a una producción realmente industrial, por qué es tan difícil, en definitiva, pasar del garaje a la factoría. 

¿Por qué nueve mujeres no pueden tener un niño en un mes?

Por supuesto, se trata de una explicación no literal sino a lo que la metáfora significa.

Cuando un proyecto, un trabajo, va retrasado, el plan de acción que primero se nos ocurre para recuperar el tiempo perdido es incrementar el número de recursos, de personas asignadas a ese proyecto.

Sin embargo la experiencia enseña que frecuentemente esta medida no sólo no mejora la situación  sino que incluso puede llegar a empeorarla.

La sabiduría popular lo explica diciendo que aunque una mujer tiene a un niño en nueve meses, nueve mujeres no pueden tener un niño en un mes.

Pero ¿podemos encontrar una explicación algo más rigurosa? ¿Hay alguna regla que nos enseñe cuándo añadir recursos puede ser útil para mejorar tiempos y cuándo no?

En su famosa obra 'The mithycal man-month', Frederick P. Brooks analiza desde varios puntos de vista, aunque siempre circunscrito al desarrollo del software, esta problemática. En ese análisis ofrece ideas y razonamientos muy interesantes, pero hay una directriz muy sencilla que nos ayuda a discriminar. Nos dice:

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. 

De lo que de alguna manera Brooks nos está hablando es de los costes de comunicación y coordinación, costes que crecen a medida que aumenta el número de recursos. Por ello, añadir más recursos ('men') no siempre ayuda a disminuir de forma equivalente el tiempo ('months').

¿Y qué pasa con las mujeres y el niño?

Es evidente que la metáfora es sólo válida hasta un cierto punto. Es evidente que un niño no es software y que existen otros condicionantes de tipo biológico muchísimo más relevantes pero todavía parcialmente podemos aplicar la teoría de Brooks. Así, ya que para hacer un niño entre varias mujeres se necesitaría una cierta colaboración y coordinación, nueve mujeres nunca conseguirían disminuir  un mes el tiempo para tener un niño. 

Tengámoslo en cuenta la próxima vez que por retraso en un proyecto, o por ansia de satisfacer a un cliente o mejorar un caso de negocio tengamos la tentación de añadir recursos indiscriminadamente con el ilusorio propósito de mejorar los tiempos de disponibilidad.

Jugar para ganar productividad

Falta de productividad...

Un cáncer que asola muchos trabajos de oficina (bueno, probablemente no sólo de oficina) y algunas de cuyas manifestaciones más típicas son las innumerables e inacabables reuniones sin objeto ni conclusión, o la invasión multimedia de nuestro tiempo fundamentalmente en forma de correos electrónicos y llamadas telefónicas con una cada vez mayor y desagradable presencia también del whatsapp.

Muchas pueden ser las explicaciones, pero algunas las podríamos encontrar en la incapacidad para organizar correctamente las reuniones o, más aún, en la incapacidad para conducir a resultados dichas reuniones, especialmente cuando hablamos de tareas creativas u opinables.

Luke Hohman, conocido por su libro 'Innovation games' en el prólogo a otro libro, 'Gamestorming', describe de esta forma la situación:

Although the loss of productivity caused by these kinds of mistakes is considerable, these mistakes result in more than that. They generate frutration among the team as work must be redone. They result in inncessary meetings, because once mistakes are realized, yet another meeting must be called to figure out what to do. The mistakes clog up our email inboxes, because instead of being comfortable in knowing whom I must email about what, I instead just CC: or even more insidiously, bcc; everyone.

Entonces, el papel moderador, las habilidades de dirigir la reunión, de elicitar ideas y requisitos, y de gestionar la dinámica de forma que se obtengan conclusiones es capital.

Una reunión bien conducida obtiene conclusiones, establece consensos y define planes de acción. Más aún, una reunión bien gestionada evita muchas otras reuniones y comunicaciones cruzadas.

Existen muchas técnicas de gestión de reuniones y de elicitación, pero gozan de creciente predicamento las técnicas basadas en juegos, la conducción lúdica de un grupo humano a la obtención de ideas y conclusiones sobre las mismas.

Sorprendentemente, los juegos, quizá por su capacidad para obtener y fijar nuestra atención e interés, cuando son utilizados sabiamente pueden ser unas técnicas muy eficaces para la realización de reuniones productivas, interesantes y, sobre todo, concluyentes.

Vale la pena entonces explorar este campo ¿no?

Eso es lo que vamos a hacer en siguientes posts basados en reflexiones y comentarios sobre el libro 'Gamestorming' de Dave Gray, Sunni Brown y James Macanufo.

Será divertido... al fin y al cabo, se jugar se trata...

Un punto de encuentro entre Agile y GTD

Tal vez se trate sólo de una ocurrencia. Tal vez los puristas o mayores conocedores de ambos conceptos puedan poner objeciones a mi reflexión, pero hace un par de días se me vino a la mente una conexión inesperada, una explicación común a la eficacia de ambas técnicas.

Agile es una filosofía, y un conjunto de metodologías, de Ingeniería Software que, siguiendo los principios del Agile manifesto, pone el foco en ciclos muy cortos de especificación, desarrollo y prueba de software, en permanente contacto con el cliente y con amplia libertad por parte de los programadores que son más bien liderados que dirigidos en el proceso de conseguir el sistema.

Entre las técnicas de actuar típicas de estas metodologías, y aún existiendo diferencias y variantes entre las diferentes implementaciones como Scrum, eXtreme Programming, Crystal Clear, etc se encuentran:

• Interacción continua con el cliente/usuario


• Requisitos recogidos en forma de 'user stories'


• Alcance global del sistema expresado como un conjunto de 'user stories' (el backlog)


• Iteraciones muy cortas (Sprints, en terminología Scrum)


• Coordinación diaría mediante reuniones cortas, al inicio del día, de una duración de unos 15 minutos y generalmente de pie


• La figura del jefe de proyecto se convierte más en un facilitador o coach que un auténtico mando

GTD (Getting Things Done) es, por el contrario, una metodología orientada a la productividad personal en cualquier tipo de ámbito. Una metodología que permite registrar y seguir tareas y proyectos personales, planificarlos y negociar esa planificación con uno mismo. Entre los elementos caracterizadores de GTD se encuentran:

• Recopilación y registro de todas 'las cosas' (tareas) por hacer


• Agenda con las tareas planificadas


• Definición de proyectos para los casos en que conseguir un objetivo precisa un conjunto de acciones, en lugar de una sola


• Revisión semanal de todos los temas

Aparentemente, son temas completamente diferentes pero, preguntándome acerca de por qué ambos conceptos son efectivos en sus campos respectivos, y utilizando en la reflexión mi experiencia en la aplicación personal que hago de una versión, cierto que algo descafeinada, de la metodología GTD para mi propia organización personal, he creído identificar un factor común y esencial, que justifica la productividad de ambas técnicas.

Ese factor, ese punto de encuentro, es el registro exhaustivo, la revisión periódica y la toma de decisión sobre lo que se debe hacer en el corto plazo.

Como se puede observar, hablo de un punto de encuentro, pero en realidad este punto de encuentro tiene tres elementos comunes

• Registro exhaustivo: en el caso de 'agile' hablamos del backlog, el repositorio de 'user stories'. En el caso de GTD se trata del censo de tareas, especialmente lo que se denomina el 'archivo de seguimiento', pero también los proyectos y el 'archivo de consulta'. Cada uno en su campo, en ambos casos recogemos 'todo' lo que sabemos que tenemos que hacer.


• Revisiones periódicas: en el caso de 'agile' nos referiríamos sobre todo a las reuniones diarias donde se repasa lo que se ha hecho el día anterior, lo que se tiene que hacer en el día actual y las dificultades actuales y, en menor medida, a la definición y seguimiento sprints. En el caso de GTD hablaríamos de la revisión típicamente diaria del 'archivo de seguimiento' y la revisión semanal del conjunto.


• Corto plazo: en 'agile' las decisiones se toman de forma muy rápida, en las reuniones diarias pero tambiñen por la autonomía y capacidad de decisión que se otorga a los programadores. En el caso de GTD durante las revisiones frecuentes del Archivo de seguimiento y en las revisiones semanales. En ambos casos, se realiza el agendado o re-agendado de tareas, se ejecutan algunas sobre la marcha, etc.

Y ¿dónde está la virtud de estos tres elementos¿ ¿Por qué conducen a la productividad?

El registro evita el olvido. La revisión periódica sirve también de recordatorio e impulsa la decisión y el corto plazo lleva a la concreción y refuerza la decisión.

En resumen: consciencia y decisión/acción. Por un lado somos conscientes de todo lo que tenemos pendiente y, por otro, se impulsa a la acción inmediata, en el corto plazo, en acciones pequeñas y concretas.

En el caso de agile tenemos la visión completa en el 'backlog' pero, por otra parte esa visión completa se estructura en sprints y user stories. Las user stories son de tamaño relativamente reducido. Además, al existir reuniones diarias en que se repasan las tareas de un solo día, de lo que se habla son de temas de pequeño alcance y acción inmediata, programadas para el propio día o para un espacio de tiempo corto.

En GTD tenemos un conjunto de tareas. Cuando el objetivo se va haciendo grande toma la forma de proyecto, pero cada proyecto se descompone en tareas o, al menos, sabemos las siguientes tareas que tenemos que hacer para continuar con el proyecto. Y las decisiones se toman diariamente o, como mucho, en la revisión semanal. Además, las tareas se agendas,no son inconcretas, no son cuando 'me apetezca' sino en un instante concreto.

Esa consciencia de lo que hay que hacer y cuándo, y esa concreción e impulso a la decisión y a la acción, ejecutando acciones pequeñas, definidas, planificadas y en corto plazo, creo que constituyen la base de la productividad y realismo de ambas disciplinas.

Ambas son vacunas efectivas contra la ambiguedad, la divagación y la procastrinación.

¿Tiene sentido para el lector esta ocurrencia?

Jeff Bezos contra la comunicación en los equipos

¿Suena duro y sorprendente, verdad?

Estamos acostumbrados a valorar el trabajo en equipo, a enaltecer la comunicación y la colaboración, a hablar de inteligencia colectiva y comportamientos emergentes... ¿y resulta que el líder de una de las empresas más representativas del mundo de Internet está en contra de la comunicación y la colaboración?

La cita que da pie a este post es una que aparece en el libro 'The everything store' de Brad Stone.

La 'acción' se sitúa a finales de los 90, en una reunión en que un ejecutivo junior proponía a Jeff Bezos, fundador y máximo ejecutivo de Amazon, una serie de técnicas para aumentar y mejorar la comunicación e interacción entre equipos y en el seno de éstos.

Sin embargo, las propuestas no fueron bien recibidas. Esto es lo que contesta el CEO de Amazon:

Communication is a sign of dysfunction. It means people aren't working together in close, organic way. We should be trying to figure out a way for teams to communicate less with each other, not more.

Bezos está pensando en la productividad y en la efectividad y ve la comunicación como una pérdida de eficiencia. En el fondo, está pensando en una mayor autonomía, una mayor capacidad de decisión de los empleados de primera línea, los más cercanos a los problemas, sin necesidad de discusión, consulta o debate.

Visto así, la cosa parece adquirir sentido ¿no?

Probablemente hemos mitificado tanto la comunicación y la colaboración que nos hemos olvidado de que la comunicación, por sí misma, no es productiva. Y, sin embargo, la comunicación puede servir como excusa para la inacción o la falta o ralentización de la decisión 

Probablemente todos los mitos sean falsos... y el de la comunicación también 

La comunicación es necesaria, a veces ayuda a resolver problemas y fomenta la creatividad...pero la comunicación por sí misma no produce, y el exceso de comunicación perjudica la eficiencia.

A lo mejor Bezos no está tan equivocado... ¿no?

¿A qué dedican su tiempo los programadores?

Cuando intentamos estimar trabajos intensivos en mano de obra es fácil errar... y generalmente por el lado del optimismo.

En entornos muy industriales, puede que aún tengan validez técnicas taylorianas de medida de tareas y tiempos pero ¿qué pasa con los trabajadores de cuello blanco?

Una disciplina que es especialmente elusiva, difícil de gestionar y planificar por las técnicas de carácter industriales es el de la ingeniería sofware y más específicamente la programación.

Diferencias en la experiencia, formación, habilidad, motivación o inteligencia entre diferentes programadores, puede dar tasas de productividad sorprendentemente diferentes.

Pero más allá de esto, hay un error mucho más básico, y más fácilmente enmendable,  a la hora de estimar la duración de un proyecto de software: sobreestimamos la dedicación efectiva de los programadores a escribir líneas de código o probar lo que han programado.

Lo cierto es que un programador, como cualquier otro trabajador, dedica una parte de su jornada laboral a tareas que no están directamente relacionadas con su puesto de trabajo o con aquello que se supone es su labor: reuniones, cafés, asuntos personales, distracciones...

En su libro 'Going Agile' Gloria J. Miller aporta referencia de dos estudios.

Menciona por un lado un estudio llevado a cabo en 2001 por Booch y Brown. Según este estudio, los programadores dedican:

• 3% de su tiempo a llamadas telefónicas
• 7% de su tiempo leyendo
• 17% de su tiempo en reuniones

Si suponemos que el resto se dedica a programar o probar, nos queda un 73% de tiempo productivo. Si realmente ese 73% se dedicara completamente a su labor, no me parece una mala cifra, especialmente teniendo en cuenta que el 7% dedicado a leer, si es en relación con su trabajo, es un potenciador y podríamos considerarlo como parte de la formación y desarrollo profesional, algo que redunda en la productividad futura.

Sin embargo, en 1995 Brook daba una estimación algo más grosera... y bastante más pesimista, estimación que atribuía sólo un 50% de dedicación a programar y depurar mientras el resto se perdía en reuniones, burocracia, bajas por enfermedad, etc.

Dos conclusiones creo que se obtienen.

Por un lado, que es conveniente vigilar la productividad y establecer medidas para mejorarla porque si Brook tuviera razón, la cosa parece preocupante.

Por otro, que no es realista planificar un proyecto de sofware suponiendo una dedicación 100%. Incluso siendo moderadamente optimistas, deberíamos suponer que, por ejemplo, un 25%  de la capacidad de trabajo en horas se va hacia tareas que no se planifican y que no tienen que ver directamente con la producción de software.

Muy relevante es hacer notar que en este artículo tratamos con el caso de la programación pero que, si pensamos en planificación en otros campos, siempre debemos partir con esa dedicación inferior al 100%. Por ejemplo podemos, de forma quizá conservadora, reservarnos un 20% para actividades no planificadas y difícilmente planificables.

Una virtud del director de proyecto es el realismo...y esta receta añade, creo, realismo a las planificaciones.

El trabajo individual también es ágil

Siempre he sido decidido defensor del trabajo individual. Siempre he pensado que la productividad mejora cuando hay una dosis relevante de trabajo concentrado en soledad. 

No sólo eso, también pienso que el trabajo individual previo es un factor de éxito de los equipos y un ingrediente para que los equipos en su conjunto sean productivos. Y James Surowecky, el gurú de la inteligencia colectiva, en su libro 'The wisdom of crowds' confirmaba esta mi intuición acerca del 'Trabajo en grupo y aportación individual'.

Y ahora, quizá en el último sitio donde pensaba encontrar esa idea, en un libro sobre metodologías agile, que se caracterizan precisamente por la colaboración y altísima interacción del equipo me encuentro la misma idea.

En concreto, en 'Going Agile' de Gloria J. Miller se afirma'

Individual work is used to encourage the active participation of each individual and to avoid groupthink. By performing individual work first, it gives the people the opportunity to establish their own opinion of a topic and document it before group discussions begin. This method also avoids individuals taking on a spectator role rather than actively contributing.

Es la misma idea: el trabajo individual favorece la opinión propia y la diversidad, la participación y la aportación...y ello redunda en bien del equipo y su productividad.

Así que el trabajo individual, no sólo es productivo. También es ágil.

Redes sociales en el entorno profesional: acerca de la productividad y la creatividad.

El debate es de sobra conocido.

¿Deben las empresas permitir el uso de redes sociales en horas de trabajo? ¿Distraen a los profesionales o les mantienen actualizados? ¿Son útiles para la compañía las relaciones que en ese entorno se establecen? ¿Se deben permitir sólo por 'humanidad'? ¿Son una versión digital del tiempo del bocadillo o el cigarro?

Probablemente haya opiniones para todos los gustos y, probablemente también el resultado dependa, siquiera parcialmente, del tipo de actividad del empleado, de su responsabilidad, de su motivación, etc

Pero hay voces que claman que las redes sociales son muy útiles en el entorno profesional como una forma de estimular las relaciones, de compartir conocimiento, de obtener nuevas ideas e informaciones, de potenciar, quizá, una inteligencia colectiva. 

En esa línea, resulta interesante la cita que de un artículo de Brendan Koerner en la revista Wired en 2010 hace Brian Solis en su libro 'The end of business as usual'.

Esta es la cita:

Studies that accuse social networks of reducing productivity assume that time spent microblogging is strictly wasted. But that betrays an ignorance of the creative process. Humans weren't designed to maintain constant focus on assigned tasks. We need periodic breaks to relieve our conscious mind of the pressure to perform- pressure that can lock us into a single mode of thinking. Musing about something else for a while can clear away the mental detritus, letting us see an issue through fresh eyes, a process that ccreativity researchers call incubation.

La línea de razonamiento de este autor es muy básica, muy simple, y quizá por ello muy convincente. Las personas necesitamos periodos de descanso, de un cierto cambio de contexto. Por eso se recomiendan duraciones limitadas en las clases, pausas entre largas horas de estudio, áreas de expansión en las oficinas y... si, por qué no, acceso a redes sociales, especialmente al microblogging.

Ese tiempo de asueto, esa liberación mental, aunque de forma directa parezca una pérdida de tiempo, aumenta tanto la productividad como la creatividad en su conjunto. En lo relativo a ésta última, me atrevo a recordar, de nuevo, cómo las redes sociales nos ponen en contacto con otras personas, con ideas, con noticias, con fuentes de información, con lo cual aparte del descanso mental que suponen, pueden añadir el plus del estímulo por nuevas informaciones.

Quizá lo intangible de la mejora de creatividad juegue en desventaja, en el aprecio de gestores y gerentes, frente a la evidente dedicación de tiempo de la jornada laboral a actividades no estrictamente profesionales..

Pero vale la pena concederle al menos el beneficio de la duda ¿no? Vale la pena dar oportunidad a los profesionales de demostrar que son capaces de un uso responsable y creativo de las redes sociales en el trabajo.

¿Nos atrevemos?

Uso 'estratégico' del tiempo

Aplicar el adjetivo 'estratégico' al empleo del tiempo puede parecer exagerado y estrictamente hablando, tal vez lo sea, pero aprovecho la fuente que me inspira el artículo, una frase en el libro de Rafael Martínez Alonso, 'El manual del estratega', para apropiarme de ese adjetivo. El autor, en un momento dado, afirma:

En la empresa, la gente se queja a menudo de que falta tiempo, pero lo que falta saber es qué es lo importante.

Y no puedo estar más de acuerdo.

Supongo que dependerá de la experiencia práctica de cada uno, supongo que dependerá de las funciones desarrolladas, de las características de la empresa como su tamaño y su cultura, pero lo cierto es que no puedo dejar de sentir que con frecuencia el tiempo se emplea inadecuadamente, que el trabajo central se ve constantemente interrumpido por solicitudes poco relevantes pero que actúan como distractores, que las reuniones son excesivamente frecuentes, excesivamente numerosas, carentes de preparación y faltas de conclusiones, que con frecuencia en las labores grupales e individuales no se definen objetivos ni se planifican los trabajos para conseguir esos objetivos...precisamente porque no se han definido.

La matriz de Eisenhower de gestión del tiempo

En ese contexto adquiere todo su sentido la frase de Rafael Martínez que, sin mencionarla, remite a la conocida matriz de Eisenhower, que se muestra en la figura, y en la que se estructuran las tareas en dos dimensiones, la importancia y la urgencia, con recomendaciones básicas sobre cómo actuar en el caso de las tareas de cada cuadrante.

Para el lector interesado en aspectos de productividad personal, recomendaría igualmente explorar la metodología GTD de David Allen que resumía hace un tiempo en esta presentación.

La conclusión sería, en cualquier caso, la urgente necesidad de mejorar nuestra gestión del tiempo, de saber identificar lo realmente importante, de atrevernos a liberarnos de tareas presuntamente urgentes pero que poco aportan a los verdaderos objetivos, de elevar, en definitiva, nuestra productividad personal... y por vía indirecta la de la empresa.

Y este último detalle es relevante. La agregación de una mejor gestión del tiempo por los empleados de una organización, la suma de mejoras de productividades individuales, debe conducir a un aumento de la productividad de la empresa en su conjunto. Por expresarlo de otra forma, para unos mismos ingresos menores costes, o para los mismos costes mayor producción y, eventualmente, mayores ingresos. En cualquier caso mejores márgenes... y quizá una mejor posición competitiva comparativa con la competencia.

La adecuada gestión del tiempo es difícilmente medible, difícilmente planificable, y seguramente ausente de las discusiones de consejos de administración o comités de dirección, inexistente en los planes a cinco años o la memoria anual. Pero a la luz del párrafo anterior, se vislumbra un impacto en cuenta de resultados y en posición competitiva. Y, visto así, el adjetivo 'estratégico' aplicado a la gestión del tiempo comienza a parecer algo menos exagerado ¿no?.

Espacios para la creatividad y productividad personales

No es realmente su objetivo, pero en su empeño de hacer entender las diferencias entre introvertidos y extrovertidos, y la aportación de los primeros al mundo de la empresa, Susan Cain, en su libro 'Quiet' repasa muchos puntos que tienen que ver con la productividad y creatividad de personas y equipos.

Y quizá por mi interés personal en el asunto, y por el, en general acuerdo o al menos interés con las observaciones, no puedo dejar de desgranar en este blog algunos de sus apuntes.

Ya hemos hablado, y puesto en tela de juicio, asuntos como el brainstorming, las reuniones o los comités.

En este artículo, y en una línea parecida, nos centramos en la necesidad de reservar espacios para el trabajo individual como un medio para la productividad y la creatividad.

Cita la autora un estudio realizado entre 38.000 trabajadores de diferentes sectores, según el cual:

the simple act of being interrupted is one of the bigget barriers to productivity.

Parece que este resultado no nos sorprende, no a mi, al menos, aunque tal vez le prestemos más valor e importancia al verlo como resultado de un estudio en principio de carácter científico y riguroso.

En la misma línea, aunque quizá menos evidente, se desafía la idea de la capacidad para trabajar en varias cosas a la vez. No, los humanos no somos multitarea, no somos como los computadores:

Even multitasking, that prized feat of modern-day-office warriors, turns out to be a myth. Scientists now know that the brain is incapable of paying attention to two things at a time.

Parece, pues, que nuestro cerebro, nuestra capacidad humana, precisa poder dar continuidad a las tareas, concentrarse en ellas (y sólo en una de ellas) para poder lograr la máxima productividad y, no sólo productividad sino, quizá más interesante y atractivo aún, para lograr una mayor creatividad.

Unos párrafos más adelante remacha la idea ejemplificando con el publicista Alex Osborn (curiosamente, el creador del brainstorming), el siguiente aserto:

If personal space is vital to creativity so is freedom from 'peer pressure'

Concentración, ausencia de interrupciones, ausencia de presión de pares y colaboradores... No sólo suena atractivo, al menos para mi, sino que además, al parecer, garantiza creatividad y productividad.

¿Por qué no lo intentamos entonces?

El brainstorming en entredicho

El brainstorming es una tradicional herramienta para fomentar la creatividad y es muy utilizada en las empresas como un medio de encontrar soluciones o propuestas.

Según descubro leyendo 'Quiet' de Susan Cain, esta técnica fue inventada por Alex Osborn, un ejecutivo de publicidad, hace ya varias décadas. En concreto, lo documentó en su libro 'Applied Imagination' publicado en 1953.

Osborn defendía que la generación de ideas en grupo era más efectiva que esa misma producción a nivel individual.

No cabe duda de que el brainstorming ha sido una técnica exitosa y ampliamente utilizada. Sin embargo, Susan Cain, que parece no dejar 'títere con cabeza' en cuanto a ciertos mitos sobre la productividad, también critica esta técnica como parte de su defensa del valor que los introvertidos, más tendentes a la reflexión y a la escucha, aportan a las empresas. Y así, afirma rotunda:

There's only one problem with Osborn's breakthrough idea: group brainstorming doesn't actually work.

Apoya este hecho en diversos estudios y citas de varios autores, como aquella atribuida a Adrian Furnham quien afirma, con no menos rotundidad:

The 'evidence' from science suggets that business people must be insane to use brainstorming groups.

y aporta una evidencia:

Studies have shown that performance gets worse as the group size increases: groups of nine generate fewer and poorer ideas compared to groups of six, which do worse than groups of four.

Pero ¿qué sucede con el brainstorming para que, a pesar de su buena fama, conduzca a esos resultados y descalificaciones?

Susan Cain aporta, mencionando estudios de psicólogos, tres factores:

• holgazanería social: cuando se encuentran en grupo, algunos individuos tienden a sentarse retirados y dejar que otros hagan el trabajo por lo que no aportarán ideas.


• bloqueo de la producción: sólo una persona puede hablar o generar una idea en cada momento, mientras el resto del grupo se ve obligado a permanecer pasivos.


• aprehensión a ser evaluado: es decir, el miedo a parecer estúpido frente a colegas y compañeros...lo que evita que se propongan ideas por si son descabelladas.

Lo cierto es que los tres factores los podemos comprobar empíricamente...y probablemente en cualquier dinámica de grupo profesional, no sólo el brainstorming. 

¿Invalida esto al brainstorming como técnica?

Probablemente no de forma absoluta. Probablemente siga tendiendo sus entornos y contextos donde pueda ser una excelente técnica de creatividad. Pero eso sí, no es una técnica universal para todas las situaciones y contextos. Quizá, baste con un poco de sentido común, con atrevernos a bajar a esta técnica de su pedestal, a ponerla en entredicho...

#macrotweet: responsabilidad sobre resultados

It's pointless to worry about the way people spend their time, but rather hold people accountable for the end results.

Michelle Golden

'Social media strategies for professional and their firms'

#macrotweet: La ley de Parkinson o el trabajo como gas perfecto

el trabajo se expande para que se ocupe todo el tiempo disponible para terminarlo.

C. N. Parkinson

Citado por Ted Klastorin en 'Gestión de proyectos'

 

Cohesión versus hostilidad en los equipos de proyecto ¿Dónde está la virtud?

Si nos preguntaran, y no pensáramos mucho la respuesta, seguramente apostaríamos siempre por la armonía de los equipos de trabajo, las buenas relaciones interpersonales, la fuerte cohesión del grupo.

Seguramente pensaríamos que esas características conducen, no sólo al bienestar de las personas, sino también a una más alta productividad del grupo...

...y nos equivocaríamos, al menos en lo que a productividad se refiere.

Si lo pensamos bien, la reflexión que Ted Klastorin hace sobre el particular en su libro 'Gestión de proyectos', es más acertada que esa primera y simple impresión. Nos dice:

"es razonable concluir que cierto grado de equilibrio entre la cohesión y la hostilidad del grupo es deseable. Es evidente que demasiado conflicto reduce una comunicación efectiva y entorpece la capacidad de los miembros del equipo para trabajar juntos. Por otra parte, miembros del equipo con [...] una cohesión alta tienden a evitar plantearse unos a otros preguntas difíciles, necesarias para mantener el proyecto en el camino correcto."

Ya se ve. Como en tantas cosas, en el equilibrio está la virtud. Ni la cohesión es la perfección ni un cierto grado de hostilidad resulta, paradójicamente, negativo, sino todo lo contrario. Un buen ambiente de trabajo es saludable, pero si en aras de esas buenas relaciones se sacrifica la exigencia o el feedback, estamos caminando en la dirección de la falta de productividad.

Difícil equilibrio, sin duda.

La ley de Brook y otras consideraciones sobre tamaño y productividad de equipos

Soy un firme defensor de los equipos reducidos, de los equipos integrados por pocos componentes pero plenos de talento y motivación. Esa es, creo, la mejor receta para la productividad, al menos en los trabajos de tipo creativo, intelectual o de gestión, trabajos muy dependendintes del rendimiento de las personas y no tanto de procesos, procedimientos, sistemas o maquinaria.

Los equipos grandes tienen necesidad de importantes refuerzos en materia de comunicación y coordinación, son más difíciles de alinear y motivar, y son más susceptibles de malos entendidos, solapes o gaps en la asignación y cobertura de actividades. Igualmente, se hace más difícil mantener en tensión creativa a un equipo de grandes dimensiones.

No debe ser esta una concepción extraña.

En su libro 'Gestión de proyectos', Ted Klastorin nos recuerda la conocida Ley de Brook que reza:

"agregar personal a un proyecto de software retrasado lo retrasa aún más"

Y no es esta la única ley o el único estudio al respecto.

El mismo autor nos menciona el estudio "Why projects fail: The effects of ignoring the obvious" (1986) de M.W. Hughes y cómo éste concluye que "ningún equipo falla por tener muy pocos miembros pero muchos fallan por tener demasiados miembros".

O el artículo de R.T. Keller "Predictors of the Performance of Project Groups in R&D Organizations" (1986) en que, por su parte, no observó ninguna relación significativa entre el tamaño del grupo y el rendimiento en el proyecto.

Parece, pues, que los estudios teóricos confirman mi percepción basada en la intuición y, sobre todo, en la experiencia: en lo que a proyectos y equipos de trabajo se refiere, el tamaño sí importa...pero es preferible el tamaño reducido.

No son, en el fondo, malas noticias para una época de recortes, crisis, y una casi angustiosa necesidad de austeridad y uso eficiente de recursos.

Paradójicamente, esa austeridad de recursos nos puede hacer mucho más productivos.

Presentación: La metodología Getting Things Done (GTD) de David Allen

Inaguro la sección de presentaciones con una sobre un tema que hemos tratado en este blog no hace demasiado tiempo: la metodología GTD de David Allen recogida en su libro 'Organízate con eficacia'.

Se trata de un método exhaustivo y sistemático para el tratamiento de todas las 'cosas' que tenemos en mente y queremos o tenemos que realizar, tanto en el plano profesional como personal. Una metodología que no sólo pretende aumentar la productividad personal sino también aliviar el estrés.

Si quieres leer el texto que explica la teoría, puedes encontrarlo en mi página personal pinchando aquí.