Agile Project Management

Hace unos años, en 2018, Jonathan Smart y Morag McCall dieron una charla en la DevOps Enterprise Summit de Londres. Jonathan es el responsable de Ways of Working en Barklays y Morag trabaja en el equipo de gestión de portafolio de productos del mismo banco. Allí defininieron una serie de antipatrones que deberíamos evitar cuando gestionamos las peticiones de desarrollo a un equipo software. Aquí las resumo:

Comprometerse en exceso

O over-commitment. Se trata de cuando le decimos a todo que sí al cliente, pero en realidad no tenemos ni idea de cuanto producimos en cada sprint.

Ante la pregunta de si me puedes hacer esto y aquello para el próximo mes, la respuesta siempre es sí. El caso es que nos comprometemos a 7 u 8 funcionalidades al mes, pero en realidad nuestro equipo solo produce 3 o 4.

El backlog no para de crecer y la desesperanza de nuestro cliente tampoco. Se han creado unas expectativas que no se van a poder cumplir y que crean frustración al que pide, pero también estrés y agobio al que entrega.

No olvidemos tampoco otra problema importante con esto: como la presión aumenta, se intenta que el equipo pueda hacer todo al mismo tiempo y que esté ocupado a un 120%. Ya sabemos los problemas que traen la multitarea y el estar siempre ocupados. Aquí unos tips para solucinarlo: Cómo manejar la presión y Estoy muy ocupado, pregúntame la semana que viene I y II.

Hambruna y sobreproducción

Esto sucede cuando el cliente, o el product owner/product manager que lo representa, no son capaces de entregar cosas con el ritmo suficiente para el equipo de trabajo. Tardan demasiado en analizar lo que necesitan, en prepararlo y detallarlo para que puedan acometerlo o, lo que suele ser más habitual, no se deciden a autorizar el trabajo una vez creado.

Esto crea una situación en la que al equipo de trabajo no llegan las suficientes peticiones, creando una «hambruna». Ante la indecisión y la falta de trabajo, ellos mismo deciden qué hacer. Comienzan entonces a desarrollar features que, posiblemente nadie necesite, y que no van alineadas con la estrategia del producto o de la empresa. Se crea entonces una sobreproducción.

El atracón y la hambruna

Smart y McCall llaman con este nombre al problema que se da cuando al equipo de trabajo le llega un atracón de tareas y se indigesta con ellas. Lo pasa fatal para terminarlas tardando mucho tiempo.

Se da en esas situaciones en las que se tiene un proyecto clave para la empresa al que se le dan muchas vueltas antes de entregarlo al equipo de trabajo. Se analiza y se perfila mucho, ya que grande y muy importante para la empresa. Cuando finalmente se le da el visto bueno se quiere tenerlo ya.

El equipo de trabajo recibe todas esas tareas de golpe y comienza a trabajar urgentemente en ellas. Lo pasa mal y las horas extra y el estrés son habituales.

Cuando por fin lo entrega, queda casi de brazos cruzados: el cliente está preparando otro gran hito que va a tardar unos meses en tener listo. Mientras, está casi sin trabajo. Es otro momento de hambruna.

Cuando llega el nuevo atracón, todo vuelve a comenzar. Nuevos sudores para digerir todo el trabajo pendiente para luego llevar a un valle de inactividad.

Si te gustaron estos contenidos, probablemente te gusten también los de mi último libro con Anaya: Gestión de proyectos – Agilidad en la práctica. Puedes encontrarlo en Amazon, la Casa del Libro, la FNAC o en las librerías cerca de tu casa.

Referencias:

• The PMO Is Dead. Long Live The PMO by DevOps Enterprise Summit
• The PMO is Dead, Long Live the PMO – Barclays en Youtube.

Se te ha ocurrido una gran idea, una que va a resolver todas las inquietudes de tu empresa y resolver tu futuro próximo. Será el nuevo producto estrella de la compañía y habrá que apostar fuerte por él. Será difícil y se necesitarán al menos dos años de inversión, pero merecerá la pena, se venderá mucho.

De acuerdo con John Gall, teórico de sistemas y pediatra retirado, es mejor que no se te ocurra acometer ese tremendo proyecto. Va a fallar si no parte de una solución más sencilla que ya esté funcionando.

Gall formuló una ley para el diseño de sistemas que nos viene a decir que un sistema complejo que funciona ha evolucionado siempre a partir de uno previo, más simple que ya funcionaba. Un sistema diseñado desde la nada nunca echará a andar y no podrá ser parcheado hasta hacer que funcione. Tienes que comenzar uno nuevo con uno simple que funcione previamente.

Esta ley explica las ingentes cantidades de dinero gastados en proyectos gigantescos, que pretendieron ser la solución a mil y un problemas, pero acabaron siendo inútiles y excesivamente complejos. Por más dinero que se le añada para intentar arreglarlo no hace sino acrecentar el problema.

En cambio, soluciones menos ambiciosas y más sencillas hicieron fácilmente su camino hasta la cartera de los clientes. Eran más eficientes.

Los diseños complejos nunca estuvieron expuestos las selección natural del entorno o del mercado mientras se diseñaban. Cada una de las cientos de ideas que lo componen no fueron validadas y probadas con el usuario final o el cliente potencial que las iba a usar. Simplemente alguien pensó que lo mejor era que el aparato vuele, hable, ande y nade.

Construye mejor un pequeño prototipo con una o dos funcionalidades: pruébalo, enséñalo, haz que lo usen. Gusta? Construye un producto mínimo viable y trata de vénderlo. Funciona? Demandan más cosas? Hazlo ahora un poco más complejo.

Ponerlo en el mercado, enseñarlo a clientes potenciales te permitirá validar tus supuestos. No esperes a tener invertido un millón de euros en él. Quizás tu producto sea el ornitorrinco de las especies. Deja que la evolución y la selección natural intervengan y te digan si es mejor ponerle pico de pato o cola de castor.

Si el mercado, en cambio, te muestra su indeferencia, pivota e intenta darle una vuelta a tu producto. Quizás haya más suerte con otra orientación o dirigiéndote a otro nicho. Si aún así, las masas no se muestran entusiasmadas por sacar su VISA, quizás sea el momento de apostar por otro proyecto. No hay un gran problema, solo habrás perdido un sistema sencillo y unos cuantos prototipos.

Referencias:

• MBA Personal, de Josh Kaufman
• John Gall en la Wikipedia.

A más de uno le sonará esta situación:

• Tienes muchas tareas entre manos, muchas otras pendientes de hacer y otro tanto que deberías estar haciendo.
• Estás tardando mucho en entregar cualquier cosa. Desde que te lo piden hasta que lo entregas pasan semanas, incluso meses.
• Algunas no llegan a hacerse hasta que alguien no pone el grito en el cielo y te obliga a aparcar todo lo demás para hacer lo suyo.

A todo eso le sigue otra cadena de pensamiento:

• Quizás si retrasas la hora del almuerzo hasta las 16:00 o las 17:00 puedas sacar algo de tiempo. Te quedarás hasta las 19:00 y este fin de semana (y el próximo) aprovecharás para adelantar trabajo.
• Esto es culpa de tu jefe que te manda todo el trabajo a tí.
• Esto es culpa de tus compañeros que se pasan el día haciendo el vago. Si ellos trabajaran también todos los días hasta las 21:00, tú no estarías así.

Trabajas y trabajas, incluso se contrata a alguien más, pero no consigues cambiar la situación. El trabajo se sigue acumulando y cada vez tárdas más en entregar lo que te piden.

¿Cómo nos hemos metido en este lío? o mejor ¿cómo podemos salir de él? Pues con algo tan fácil (o tan difícil) como darte un respiro. Reservar un margen, un hueco para levantar la cabeza y coger resuello, pensar cómo mejorar o para hacer hueco para terminar esas cosas que tardaron un poco más de lo previsto.

En la Teoría de Colas, el matemático británico John Kingman definió una fórmula que predice el tiempo de espera medio en una cola. Sí, una cola como las que se forma ante la caja en un supermercado, pero también la cola espera por una cama en una UCI en estos días de coronavirus.

Cómo no, del mismo modo predice el tiempo que tendrá que esperar la gerente por tu informe semanal, por el registro de horas y por los tres análisis a los que te comprometiste. Todavía nos has terminado los primeros, pero ya llegan las fechas comprometidas para el siguiente.

Esa fórmula de Kingman viene a ser algo como esto:

E = [ V ] * [ u / (1 – u) ] * [ T ]

Donde «E» es el tiempo de espera medio hasta que nuestro trabajo es procesado, «V» es el coeficiente de variación de las tareas, «u» es el porcentaje de que estamos ocupados y «T» es el tiempo medio que tardamos en terminar cada trabajo.

Esto divide la fórmula en tres partes que aumentan, cada una de ellas, el tiempo medio que tardamos entregar lo que nos han pedido. Ese tiempo de espera será más alto si:

• «V» es alta: es decir, hay una desviación media alta entre lo que terminamos en terminar unas cosas y otras. Por ejemplo, si para unos informes tardamos 2 horas, pero para otros 10 días.
• «T» es alta: si tardamos mucho tiempo en terminar cada tarea. Lógico que tengamos que esperar mucho, no?
• «u» es alta: Si estamos muy ocupados.

Fijémonos ahora en este último punto. Tardaremos mucho si estamos muy ocupados, eso es claro a todas luces, pero ¿cuánto más tardaremos? Mucho, de hecho si estamos casi un 100% ocupados, el tiempo de espera tenderá a inifinito.

Veámoslo con un ejemplo: Si estamos un 80% ocupados, tardaremos solo 4 unidades de tiempo (horas o días) en responder con el trabajo hecho, pero si estamos ocupados un 98% del tiempo (0,98/(1-098)), tardaremos 49 unidades de tiempo. Diez veces más!

El libro The Phoenix Project nos lo pinta así:

Bloquea en el calendario dos horas cada día, o un día a la semana, sin reuniones, sin tareas prefijadas. Úsalas para acabar con tranquilidad lo que lleva tiempo arrinconado, o lo que ayer no pudiste terminar. Úsalas para esas mejoras que te permitirán ir más rápido otro día o para estudiar el lío en el que andas metido.

Si llega algo nuevo ese día, apárcalo, anótalo y trátalo como lo demás en tu lista de cosas pendientes. No dejes que el día a día te convierta en un hamster en su rueda. Bájate, bebe agua y come algo de alpiste. Ya te subirás a la rueda luego, cuando tengas todo algo mejor organizado. Bajará, y lo hará mucho, el tiempo que tardas en terminar las cosas.

Referencias:

• The Phoenix Project de Gene Kim et al.
• Don’t Let Planned Work Ignite With Incandescent Fury — Takeaways from «The Phoenix Project» de Yordi Verkroost.
• Muri and Mura: Kingman’s Seven Lessons de Rob van Stekelenborg.
• Fórmula de Kingman en la Wikipedia.
• Slacking off at work is a demostration of your time management skill prove by maths por Chris Choy.

O la otra. Mejor a finales de mes, pero quizás te vuelva a decir lo mismo. Con suerte después del verano… Te suenan frases como esta? Sabes que si está terminado para fin de año serás afortunado.

Si es a un compañero al que le tienes que pedir un rato de su tiempo, te volverá loco dándote largas, pero no harás más que incrementar su estrés si se lo recuerdas cada poco. Al cliente de este tipo de servicios le podrán los nervios y la frustración. Quizás decida buscarse a otro proveedor que le dé tiempos de respuesta más cortos.

Quién se encuentra en esta situación en su trabajo se encontrará agobiado por la carga de trabajo, pero también por un sentimiento de impotencia: sabe que no está dando tiempos de respuesta razonables, y más de una vez se habrá llevado una bronca de un cliente por ello.

En cambio no se sentirá mal por su trabajo. Está haciendo todo lo que puede y más. Trabaja al 100%, no se toma un minuto de descanso y es habitual que trabaje 1 o 2 horas más cada tarde. Algún fin de semana que otro también cae. Sencillamente, no ve que pueda hacer otra cosa. Desde luego, no se le puede reprochar nada ¿o sí?

Weinberg, en uno de sus libros, nos dice: «Busy managers, means bad managers». No podemos estar ocupados al 100%, debemos tener un minuto libre para reflexionar si lo que estamos haciendo tiene sentido, si puede mejorarse o simplificarse, incluso si merece la pena que lo hagamos.

Debe haber un margen (una holgura o slack como se diría en eXtreme Programming) para escuchar lo que nos están diciendo, para estar atentos a los problemas, o para llegar a las fechas comprometidas asegurándonos de que cumplimos con la calidad necesaria. Para lo que no debe haber tiempo es para los gabinetes de crisis por haber incumplido las fechas o una nueva reestructuración de planes y Gantts aún más ajustados que los anteriores.

Kahneman y Tversky, los autores de Piensa rápido, piensa despacio, dicen esta frase en su libro: «El secreto para llevar a cabo una buena investigación es siempre no tener mucho trabajo. Se pierden años por no perder una horas.»

Permítete estar centrado en tu trabajo, en lo importante, y no en todo lo que tienes pendiente de hacer para esta tarde, mañana y toda la semana. Simplifica tu trabajo, rechaza tareas no relevantes. Recorta sin pudor, no tengas miedo de meter la tijera, delegar o decir simplemente «no».

Si estás 100% ocupado, asegúrate de que es porque un 10% o 20% de tu tiempo lo estás dedicando a mejorar los procesos, a estudiarlos o como colchón para cuando venga algo urgente. También a aprender cosas nuevas. Un simple truco en Excel o en tu Mac, podría haberte salvado decenas de horas a la semana, pero tú estabas demasiado ocupado «trabajando».

¿De dónde saco que es un 10 o un 20% lo que tienes que mantener como margen? Pues al libro The Phoenix Project y a la fórmula de Kingman. Lo contaré la próxima semana. Stay tuned!

Si te gustaron estos contenidos, probablemente te gusten también los de mi último libro con Anaya: Gestión de proyectos – Agilidad en la práctica. Puedes encontrarlo en Amazon, la Casa del Libro, la FNAC o en las librerías cerca de tu casa.

Referencias:

• Pág. 235 del libro The Phoenix Project de Gene Kim et al.
• Pág. 276 del libro Quality Software Management de Gerald Weinberg.

La figura del jefe de proyectos está cada vez más denostada en las organizaciones ágiles. Suele vérseles como a aquella persona encargada de los plazos, la fechas y los compromisos del cliente y estos cada vez son menos importantes (o eso creemos) en un proyecto ágil.

Era el middle manager, el encargado de echar las broncas si íbamos retrasados, el que daba excusas al cliente y luego pedía más compromiso al equipo para trabajar, esa tarde también (como toda la semana), unas horas extra más.

Pero ¿solo hacían esto? ¿solo valen para apretar tuercas y buscar responsables? Recientemente, leyendo el libro Managament 3.0 de Jurgen Appelo, pude ver que, desde opiniones autorizadas dentro del mundo de la Agilidad, hay también versiones diferentes. En contreto decía:

• «Project managers are there to serve the teams, not to control them. (…) Are there to manage, projects, not people.»
• «Position of project manager should be no different that of software architects and QA manager.»

Lo definía como un rol más dentro del equipo, alguien que tiene que lidiar con el cliente o registrar las horas realizadas, pero que trabaja codo con codo, y al mismo nivel que los demás. Simplemente aportan su grano de area, igual que el desarrollador, el arquitecto software o el diseñador. Cada uno tiene su función dentro del mismo y nadie está por encima de nadie.

Pero no fue el único sitio donde lo leí. También se defiende a capa y espada a los jefes de proyecto en el libro The Unicorn Project de Gene Kim (el spin-off de The Phoenix Project). En concreto, cuando Maggie piensa en despedir a todos los jefes de proyecto para ahorrar costes y tener más fuerza productiva de desarrolladores, Erik, el gurú de la gestión Lean, le dice:

• «Those middle managers are your interface between strategy and execution (…) They are your prioritizers and your traffic cops.»
• «We all have this ideal of small teams working independently, but who manages the teams of teams? It’s your middle managers.»
• «(…) properly developing this layer of people is critical to execute strategy.»

Si los equipos son autoorganizados en tu empresa ¿Tienes quien cuide de hacer ejecutar la estrategia de la empresa? Pero lo más importante, ¿hace falta que haya quién lo haga o basta con una holocracia?

Josh Kaufman, en su libro MBA personal, habla de ocho síntomas que indican que las cosas se están haciendo mal en una organización o en un equipo de trabajo. Probablemente no todas sean aplicables a la vez en un mismo caso, pero seguro que identificas alguna de ellas en alguna de las empresas en las que hayas trabajado.

Si en tu trabajo las cosas no están funcionando bien, probablemente se deba a al menos un par de estas causas. Si te parece que no aplican, que no sabes lo que es, pero en tu situación ninguna de estos problemas es el culpable, piénsalo dos veces, quizás estén ahí, delante de ti y no te estás dando cuenta. Aquí van:

1. El trabajo incompleto: Se empiezan muchas tareas, pero muy pocas llegan a concluirse. Siempre llega una más urgente e importante que todas las anteriores y se para todo para comenzar con la nueva. Esta sí que es importante ahora (hasta dentro de un par de semanas que llegará una tarea nueva y más urgente aún).
2. La parálisis de la coordinación: no puede hacerse nada sin consensuar con gran cantidad de responsables de departamento, líderes de proyecto y la firma o el email con la autorización de un par de jefazos.
3. Los pseudoproblemas: se magnifican los problemas menores hasta perder el sentido de la proporción. Se crea un estado de alarma continuo en el que el menor desvío o la más pequeña equivocación (si es que es una equivocación real) se convierte en un drama al que hay que prestar toda la atención. Se interrumpen los esfuerzos a los proyectos y tareas importantes para apagar ahora este fuego, consiguiendo con esto solo que el avance real no haga más que dar saltos atrás y adelante.
4. Las fechas límite negativas. Las fechas límites son más importantes que la calidad del trabajo. No importa lo que haya que hacer, solo se piensa en terminar. Esto hará que construyamos productos débiles, que fallan mucho o que demos servicios sin el mimo que requiere el trabajo bien hecho.
5. Todas las decisiones tienen que ser aprobadas por toda la estructura de la empresa. El producto toma la forma de ella: Ley de Conway. Vemos esto fácilmente en webs institucionales en las que se dedican un número fijo de páginas para que lo rellene cada departamento y cada uno lo convierte en un escaparate de su trabajo. Se construye de todo excepto una página en la que el ciudadano encuentre fácilmente lo que necesita.
6. Para no perder 100€ que valdría un portátil de segunda mano que se pierda o se robe al año, se invierten miles de euros en la creación de software de inventario, supervisión, control, seguimiento o tiempo para el de registro.
7. La información se proporciona con cuentagotas. No se cuenta por qué se necesita lo que se pide ni se justifica. Pocas cosas hay tan desmotivadores como trabajar en algo que no se sabe para qué se necesita ni si le será útil a alguien.
8. No se quiere que las personas tomen contacto entre sí. Podrían saltarse la cadena de mando y el supervisor se sentiría menos importante. Alguien podría preguntarse para qué sirve su puesto y tiene que justificarlo de cualquier manera.

Referencias:

• Ocho síntomas de crisis burocrática en el libro MBA Personal por Josh Kaufman.

Si alguien nos lo hubiese dicho hace solo algunas semanas, le habríamos dicho que estaba loco, que cosas así solo pasaban en las películas. Pero aquí estamos, en medio de un estado de alarma, medidas de confinamiento y gentes con bolsas en la cabeza en metro y supermercados.

A pesar de todo lo que estamos viendo a nuestro alrededor, yo soy optimista, creo que en unas pocas semanas empezaremos a ver cifras más positivas y aplanar la curva de contagiados. Y solo unas pocas semanas después empezarán a flexibilizarse las normas y volveremos poco a poco a nuestros trabajos y a la normalidad.

Sin embargo, todos no podremos recuperar tan rápido los empleos. Los puestos de trabajo son fáciles de destruir en un ERTE, pero la vuelta a la normalidad en la economía después de un susto así, no es tan rápida ni efectiva. ¿Qué hacer en caso de apocalipsis profesional? ¿Cómo podemos recuperarnos los más prónto posible? Aquí van un par de ideas:

• Fórmate con Coursera, Edx o MíriadaX. Tienes cursos, minicursos y másters de prestigiosas universidades e instituciones para casi cualquier cosa que puedas imaginar en tu sector o para la vida en general. Muchos en inglés, pero otros tantos en español. Puedo recomendarte estos, independientemente del tipo de trabajo que hagas:
  • Aprendiendo a aprender (Más me hubiese valido contar con este curso antes de empezar la Universidad).
  • Successful Negotiation (después de todo, todo en la vida es una negociación).
• Aprende un idioma como el inglés, el alemán, o el francés (especialmente el primero, que te permitirá el acceso a contenidos, formación y lecturas que con solo el castellano no podrás acceder). En España contamos con una red de Escuelas Oficiales de Idiomas que ofrecen cursos y profesores de un altísimo nivel, por un precio que no llega ni al 10% de lo que te costaría una academía privada.
• Hazte un ciclo medio o superior de formación profesional (ver TodoFP.es). Cuentas con múltiples opciones presenciales, online y semipresenciales que te permitirán formarte muy bien, mejorar tu empleabilidad o obtener un título para eso que siempre has sabido hacer, pero no tenías un certificado que te lo reconociera.
• Hazte tu propio máster personal, buscar lecturas en Amazon sobre la «carrera» que te quieras hacer y selecciona dos o tres libros buenos y clásicos sobre la materia. Una vez terminados y con más conocimiento sobre la materia. Encarga ahora otros dos o tres, esta vez más específicos. Sigue así en el plazo de un año, que es lo que dura un máster.
• Lee, lee y lee. Ponte una meta: 45 minutos al día deberían darte para leer una 30 páginas, eso son 210 páginas a la semana, unos dos libros al mes. No está mal, ¿no? Aquí van algunas sugerencias:
  • Peopleware, de DeMarco y Lister.
  • Managemente 3.0, de Appelo.
  • The Phoenix Project, de Kim et al.
  • The Unicorn Project, de Kim.
  • Fuera de serie, de Gladwell.
  • Pensar rápido, pensar despacio, de Kahneman.
  • Scrum, de Sutherland.
  • Lean startup, de Ries.

Si te gustaron estos contenidos, probablemente te gusten también los de mi último libro con Anaya: Gestión de proyectos – Agilidad en la práctica. Puedes encontrarlo en Amazon, la Casa del Libro, la FNAC o en las librerías cerca de tu casa.

Hace tan solo unos días he tenido la oportunidad de ser entrevistado por OnTranslation.es, una empresa que proporciona servicios de traducción a, entre otros, el Ajuntament de Barcelona o al Institut Ramón Llull, y a la que pronto le darán el premio a mejor empresa de traducción desde una agencia de UK.

Todo un honor verme entre la lista de entrevistados por el blog de OnTranslation, viendo que entre ellos hay gente como Marta Galligó, Ferran Barbará o Miguel Noguera.

Aquí tienes el enlace a la entrevista, espero que te parezca interesante: Antonio Martel y la gestión de proyectos SCRUM.

Uno de los clásicos de la literatura de la industria del software, Gerald Weinberg en su libro Quality Software Management cuenta en uno de los capítulos de ese libro: «Durante una época de crisis, la mayor parte de la gente está haciendo malabares con muchas tareas al mismo tiempo. De hecho, un síntoma de sobrecarga es el número de gente asignada la mitad del tiempo al proyecto A, 1/7 al proyecto B, 1/23 al proyecto C, y así sucesivamente. Las tareas continúan llegando, y los mánagers simplemente añaden más tareas al personal existente».

A simple vista, vemos que una dinámica así no nos puede llegar muy lejos, pero cuando estamos en medio del jaleo, no es tan sencillo de ver. No queremos añadir más gente, porque esto tiene un coste obvio y porque, de acuerdo a la Ley de Brooks, añadir gente a un proyecto retrasado solo lo retrasaría aún más.

Weinberg indica en su libro que, cuando nos dedicamos a hacer mil cosas a la vez, no lograremos avanzar nada. Es más, iremos mucho más despacio que si solo tuviéramos que hacer una o o dos. Las razones que señala para este fenómeno son muy parecidadas a las que Brooks explica para su ley. En esta serie de pasos Weinberg explica cómo nos vemos metidos en esa espiral:

1. Tenemos una cantidad alta de trabajo por hacer.
2. Encontramos una falta relativa de progreso.
3. Aumentamos la carga de tareas.
4. Con las nuevas tareas necesitamos:
   1. Tiempo para aprenderlas.
   2. Tiempo para los cambios de contexto al saltar entre unas y otras.
   3. Tiempo para la coordinación entre las viejas y las nuevas tareas.
5. Vuelta al paso número 1.

De nuevo, según Weinberg, el único factor que impide que esta táctica nos lleve a peores resultados, es que la gente más sobrecargada simplemente ignore las nuevas tareas que le van llegando. O ignore las antiguas. O ambas.

Parece radical, pero ¿no te has visto alguna vez en una situación similar? Es tal la sobrecarga y te ves tan abrumado con las nuevas tareas que te acaban de llegar que simplemente cierras los ojos y dices: «Al diablo, haré como que no he visto nada. Iré a casa, colgaré el teléfono y cerraré el Skype. Terminaré de una vez eso que debía haber entregado hace dos semana, y a lo que solo le he podido dedicar 3 minutos cada 4 horas».

Una tabla sencilla que Weinberg ha calculado para estimar los efectos perjudiciales de intentar la multitarea cuando nos enfrentamos a varios proyectos al mismo tiempo es:

A poco que lleves algunos años trabajando, seguramente lo habrás vivido alguna vez: tienes mucho trabajo y todas las tareas son importantes. Te interrumpen cada día con una nueva que es aún más urgente que la de ayer. Intentas hacer todo al mismo tiempo y sacas un rato para cada una, pero apenas notas algún avance. No me extraña, según Weinberg, si repartes tu tiempo entre 5 tareas a la vez, de cada jornada de trabajo, solo lograrás un 5% para cada una de ellas. Un 25% de efectividad total de tu día de trabajo.

Desde luego, así es imposible sacar nada adelante y la situación no hará más que empeorar. Plántate y sal de ese bucle. Aprovecha la Ley de Secuencias Homogéneas de Carlson y dedica todo el tiempo que te sea posible a solo una de las tareas pendientes. Ignora las demás. Serás productivo un 100%, cuatro veces más. Ahora solo te quedan 4 tareas.

Aborda la siguiente sin distracciones antes de que llegue una nueva y lograrás avanzar. Solo hay que mantener la cabeza serena e ignorar los cantos de sirena que te dicen que todo es urgente. Como diría Kipling: «Si puedes mantener la cabeza cuando todo a tu alrededor pierde la suya y te culpan por ello; (…)».

Si te gustaron estos contenidos, probablemente te gusten también los de mi último libro con Anaya: Gestión de proyectos – Agilidad en la práctica. Puedes encontrarlo en Amazon, la Casa del Libro, la FNAC o en las librerías cerca de tu casa.

Daniel Kahneman, el conocido psicólogo y premio Nobel, especializado en la economía conductual, nos explica que las metas que nos marcamos son puntos de referencia a partir de ese momento. Todo lo valoramos hasta llegar ahí, pero lo que pase de ese punto, deja de tener nuestro interés.

En su libro, Piensa rápido, piensa despacio, Kahneman nos explica el caso de los taxistas de Nueva York. Se fijan ellos mismos una meta diaria del dinero en carreras que tienen que hacer y dan vueltas y vueltas hasta que lo consiguen y se van a casa. En los días malos esto se traduce en jornadas agotadoras que no acaban nunca, pero en los días lluviosos la gente usa mucho más el taxi en lugar de caminar. Durante esos días de fuertes precipicitaciones, consiguen llegar a su meta pronto y se van pronto a casa a descansar (lo que hará que dejen de haber taxis disponibles y estos sean más escasos y demandados).

Si nos paramos a pensar un poco, veríamos que sería mejor hacer jornadas largas durante los días lluviosos, donde conseguiríamos dinero rápido, pero podríamos irnos a casa temprano durante los días de poco movimiento. Estaríamos «comprando» así ratos de ocio a bajo precio.

La meta diaria que se ha fijado el taxista y la aversión a la pérdida hará que le horrorice quedar por debajo de la media que se ha propuesto y trabaje a destajo durante los días de pocas carreras. En cambio, no le preocuperá lo más mínimo que pueda estar dejando de ganar el dinero de todo una jornada en solo para de horas de un día lluvioso.

Fíjate metas para tus sprints, metas ambiciosas, no demasiado altas de forma que se convierta en ridículo intentar alcanzarlas, pero sí que supongan un reto, un buen logro si lo conseguimos. Si el trabajo sale bien y conseguimos rápido el objetivo principal del sprint, siempre tendremos algo más ahí por hacer y que nos ayudará a sumar todavía más puntos.

No lo conviertas tampoco en un drama si de vez en cuando el sprint sale mal y durante esas dos semanas no conseguimos gran cosa. No pasa nada, es uno de esos días lluviosos. Seguramente hubo algo complejo que se atravesó en nuestro camino. Una vez resuelto, durante las dos semanas siguientes, seguro que podremos sumar mucho más con el camino, ahora sí, más allanado.

Si te gustaron estos contenidos, probablemente te gusten también los de mi último libro con Anaya: Gestión de proyectos – Agilidad en la práctica. Puedes encontrarlo en Amazon, la Casa del Libro, la FNAC o en las librerías cerca de tu casa.

Referencias:

• Kahneman, D. (2017, enero). Pensar rápido, pensar despacio. Barcelona: Penguin Random House.

No lo rellenes por rellenar, por parecer ocupado. Supones que algo productivo debes estar haciendo, pero ¿el qué?. Buscas un tarea sencilla por hacer hasta que comience el próximo sprint y te dispones a hacerla. Después de todo, no vas a estar de brazos cruzados, ¿no? Además, siempre puedes sumar un punto fácil en el sprint actual.

El problema es que casi cualquier cosa que hagas, por pequeña que sea, tiene un coste de mantenimiento, de desarrollo, de errores inesperados, de cambios solicitados después. Tiempo para mostrala en la demo, para revisarla, para corregirla y un largo etcétera. ¿Y si no la entendiste bien o no era tan fácil como parecía? ¿Por qué abrir ese melón?

Parecerás estar ocupado, pero si lo que haces no aporta valor, ¿para qué lo haces? Cada línea de código que produces tiene un coste, son inventario que hay que mantener, que actualizar si otra parte cambia,… Es como el material que produces en una fábrica, para qué lo produces ¿para mantenerlo guardado en el almacén? Eso cuesta dinero. Y Producirlo también.

Comenzar cosas hará que se empleen tiempo y recursos en algo que probablemente quede a medio, que se oxide con el paso del tiempo, que pierda valor y que nadie recuerde cuando se vuelve a retomar. Es como comenzar a abrir fruta, pero solo comer un poco. Luego abres otra y otra, pero no terminar ninguna.

Podrías además estar causando un cuello de botella en un sección diferente u obligando a que otro departamento dedique su tiempo o sus recursos a manejar eso que produces (como al departamento de Calidad o de Operaciones). Si nadie tiene verdadero interés en lo que has hecho, mantener a los «obreros» ocupados te hará sentir mejor, pero te estará causando perjuicio. Es mejor que estén holganazeando, suena mal, incluso es contraintuitivo, pero realmente te costará menos.

Siempre podrás dedicar ese tiempo a un spike, a estudiar lo próximo que vas a comenzar, o a preparar el terreno para lo que necesites. Seguro que encuentras un montón de cosas por hacer. Aunque no vayan a sumar puntos en el sprint actual, ganarás tiempo para el próximo, dónde sí que podrás avanzar mejor con el camino ya asfaltado.

Seguro que conoces esa alegoría popular en las redes sociales, sobre un profesor que enseña a sus estudiantes que un tarro lleno de piedras de diferente tamaño, incluso con arena, siempre puedes terminar de llenarlo con un par de cafés (aunque ya pareciera abarrotado).

Ese símil también nos vale para estas situaciones: si rellenas el tarro con las tareas pequeñas, la arena, nunca habrá hueco para las piedras grandes y de valor. Siempre se retrasa el inicio de la tareas importantes: se está distraido con los pequeños detalles. Para los grandes proyectos nunca se encuentra tiempo. Su slot está ocupado por asuntos diminutos que no están, ni de lejos, entre los objetivos de tu empresa.

Rellenar tu tiempo con cualquier cosa hará que engordes inutilmente tu producto. Haz dieta y evita caer en la tentación de mantenerte ocupado con tareas de poco valor.

Si te gustaron estos contenidos, probablemente te gusten también los de mi último libro con Anaya: Gestión de proyectos – Agilidad en la práctica. Puedes encontrarlo en Amazon, la Casa del Libro, la FNAC o en las librerías cerca de tu casa.

Si has trabajado alguna vez con Scrum, el más popular de los frameworks ágiles, probablemente te hayas dado cuenta de que los equipos trabajan algo más deprisa. Incluso cuando solo se han puesto unos sprints en marcha, el equipo entrega más cosas en esas dos semanas que si no hubiese meta alguna.

A veces, hasta puede llegar a ser un problema: los equipos comienzan a trabajar demasiado rápido ignorando la calidad o si están aportando valor o no (bendito problema, cuando se viene de un equipo bloqueado que no consigue entregar nunca nada).

Achaco ese incremento de la velocidad al simple hecho de que tenemos una meta que cumplir cada dos semanas. Una serie de puntos a los que nos hemos compremetido y que, en menos de lo que canta un gallo, ya tenemos que entregar de nuevo, y así continuamente, semana tras semana. Hemos fijado unos objetivos y alcanzarlos supone un pequeño estrés (pequeño o medio si lo has hecho bien, grande o insoportable si conviertes el proceso en un Scrum del Terror) .

Esto nos los explicaba ya Parkinson hace unas décadas en una de sus conocidas leyes: «El trabajo se expande hasta llenar el tiempo de que se dispone para su realización». Si hubiésemos entregado todo el proyecto al final del mismo, un año después de haber comenzado, probablemente nos habría quedado todo el trabajo para el final (la fase de pruebas se ejecutaría después de entregado, si quedase presupuesto).

El estrés parece que también es lo que hace que los árboles crezcan más (o que su fruto sepa mejor): a Simcha Blass un ingenerio en Israel, uno de los capataces de una plantación en el desierto de Negev, le llamó la atención sobre un árbol más grande que los demás que estaba creciendo «sin agua».

Estuvieron excavando alrededor del árbol para saber cómo podía ser esto y de donde sacaba el agua. Descubrieron que, efectivamente, el árbol estaba fuera del circuito del agua, pero una tubería cercana goteaba suministrándola del poco que le permitía sobrevivir. El estrés por la falta de agua estaba haciendo a este árbol crecer más que los demás. Así se inventó el riego por goteo en Israel que tanta agua ha ayudado a economizar por todo el mundo.

Es bueno ponernos metas, intentar alcanzar objetivos y
hacer un esfuerzo extra para conseguirlos cada poco tiempo. Deja que los estresores saquen lo mejor de nosotros mismos para llegar a lo que aspiramos.

Establezcamos pequeñas metas, un poco exigentes, algo ambiciosas, para forzarnos a adaptarnos y no dejar que se nos acumule el trabajo. Se trata de sobrevivir lean, sin grasa ni agua en exceso que nos haga ser insípidos. Permite que el estrés te ayude a encontrar soluciones de bajo coste e ingeniosas para los problemas de cada día en tu producto.

Huye también de la financación a espuertas o márcate objetivos como si no contases con ellos. Lo agradecerás cuando tengas que devolver todo ese dinero o dar explicaciones sobre lo gastado.

Sobre los efectos negativos del estrés, o del exceso de este, ya hableremos más adelante.

Si te gustaron estos contenidos, probablemente te gusten también los de mi último libro con Anaya: Gestión de proyectos – Agilidad en la práctica. Puedes encontrarlo en Amazon, la Casa del Libro, la FNAC o en las librerías cerca de tu casa.

Referencias:

• Colaboradores de Wikipedia. (2019, 19 de julio). Ley de Parkinson. Recuperado de https://es.wikipedia.org/wiki/Ley_de_Parkinson
• DripWorks (2015, 28 de mayo). The History of drip irrigation. Recuperado de
  https://www.dripworks.com/blog/drip-tubing-and-the-history-of-drip-irrigation

No así el problema que están intentado medir (por lo menos, no siempre).

Durante los años 90, en Europa, a alguien se le ocurrió una solución para reducir los excedentes de leche y mantequilla en la Unión. Demasiados productores de leche estaban haciendo bajar mucho los precios en los mercados. La idea era compensar a los granjeros por cada vaca llevada al matadero.

Para comprobarlo y así poderse garantizar la subvención, el propietario de las vacas sacrificadas debía enviar por correo una oreja del animal. Cuantas más orejas enviaba, más subvención recibía.

Todo fue bien al principio. Imagino la cara de sorpresa del promotor de la idea. Estaba funcionando de maravilla. Miles de vacas lecheras estaban siendo sacrificadas. Pronto se reduciría la capacidad de producción y los precios volverían a la normalidad para todos.

No tardó mucho en verse el problema: la gente comenzaba a informar sobre prados llenos de ganado sin orejas. Estaban cometiendo una atrocidad con los animales, y encima cobraban dos veces por cada vaca, una por la oreja izquierda, y otra por la derecha.

Piensa ahora en lo qué ocurriría si decides premiar a tu equipo con un bono por mejorar las estadísticas que da tu Sonar. Hay bastantes probabilidades de que alguien copie y pegue el Quijote para añadir más comentarios al código. También puede suceder que se pongan a crear tests unitarios por doquier, pero que no prueban nada real, solo mejoran el porcentaje de cobertura. Después de todo, esto es más fácil de hacer que cortar la oreja de un animal.

Pero esto no va a pasar solo si pagas un bono. Si echas la bronca por no tener un código suficientemente comentado, o por no haber terminado suficientes historias este sprint, también de va a pasar. Probablemente pase incluso si simplemente los felicitas por haber sumado más estas dos semanas. Sabrán que lo estás midiendo y están siendo

Corres el riesgo de entrar en un Scrum flácido, uno en el que solo se escogen las historias más fáciles de terminar, aquellas de menos riesgo y menor coste. Solo se apuesta por sumar puntos de forma sencilla. Si el cliente las necesita o si le aportan valor es algo totalmente secundario, lo importante es terminar cuantas más mejor. Así el jefe no se enfada.

Todo pintará muy bien. Las cifras no hacen más que darnos buenas noticias: mejoramos de forma clara el número de puntos completados, cada vez terminamos más historias. Siempre supimos que echar una bronca al equipo iba a funcionar. Desde que los hicimos las estadísticas claramente nos dan la razón (igual que el general israelí que pensó que las broncas funcionaban mejor que los halagos. Ver Regresión a la media tuit de Joan Tubau).

No está mal medir, siempre es bueno saber hacia donde vamos o qué necesitamos mejorar. Pero no te dejes engañar fácilmente, es bastante probable que, tan solo observando, ya estés alterando el resultado (ver Paradoja del Observador en Wikipedia).

Si te gustaron estos contenidos, probablemente te gusten también los de mi último libro con Anaya: Gestión de proyectos – Agilidad en la práctica. Puedes encontrarlo en Amazon, la Casa del Libro, la FNAC o en las librerías cerca de tu casa.

Referencias:

• The Professional Product Owner, por McGreal y Jocham (Value neutrality/Perversion of metrics).
• Paradoja del Observador en la Wikipedia.
• Tuit sobre el sesgo cognitivo de Regresión a la Media, por Joan Tubau.

Sí, esto es cierto, no sabemos lo que queremos. Tu cliente, el que compra tus productos, tampoco lo sabe. El ser humano no es racional. Tomamos decisiones irracionales que luego justificamos bastante bien.

Ante la pregunta de por qué nos compramos ese coche tan grande o esa casa tan lejos de todo, siempre encontramos una excusa plausible. A toro pasado siempre justificamos, y nos autoconvencemos, de nuestras decisiones de compra
(aunque nuestro interlocutor nos mire con cara de incredulidad).

Suele atribuírsele a Henry Ford, inventor del mítico Ford T y la producción de coches en cadena, la frase en la que supuestamente aseveraba que, sí hubiese preguntado a la gente qué quería, le habrían dicho que deseaban carruajes con más caballos. En realidad no tenemos que irnos tan lejos; Mercedes Benz, en los 90 hizo caso a lo que decían los estudios de mercado. La gente quería coches fáciles de aparcar y que consumieran menos, por lo que diseñó el Smart. Mientras, las ciudades se llenaban de 4×4 capaces de tragar tanto diesel como un camión.

No vas a acertar a la primera con lo que coloques en el mercado. Probablemente te hayas enamorado de tu idea y creas ciegamente que ese nuevo proyecto tuyo te convierta en millonario. Puede pasar, pero me temo que con tanta probabilidad como la de que te toque la lotería de Navidad: con suerte recuperarás lo que invertiste.

Escoge una opción. Prueba pronto, falla barato. Aprende con lo invertido y selecciona una nueva alternativa. Adáptate y mejora tus probabilidades de tener éxito. No inviertas hasta los muebles en la primera idea que se te pasó por la cabeza.

Alex Cowan, de la Universidad de Virginia, en su curso para Product Managers en Coursera, señala que no preguntemos a nuestros potenciales clientes si nos comprarían nuestro producto o si les incluimos esa otra funcionalidad a nuestro producto. La mayoría nos dirá que sí, que lo hará, pero solo quiere terminar la reunión e irse a casa. No quiere herir nuestros sentimientos y dejarnos con una sensación amarga. Conseguirá algo peor, que invirtamos miles de horas de nuestro tiempo y una cantidad similar de dinero en algo que no nos llevará a ninguna parte.

Se sabe que en las catas de vino a ciegas no acierta prácticamente nadie. La gran mayoría de los asistentes no tiene idea de qué uva, cosecha o región procede el vino. Mucho menos de si la barrica era de roble o de haya, pero estarán dispuestos a pagar una cantidad de dinero mucho mayor por unas botellas o añadas que por otras (aunque no puedan diferenciarlas). Sencillamente, no saben lo que quieren.

Hace muchos años, un compañero de Taiwan, estudiante de inglés, me decía que en su tierra, la carne de perro era un alimento habitual y que allí se valoraban más a los que tenían un solo color en su pelaje que a aquellos que tenían varios. De entre los que tenían un único color, los perros de color blanco eran más los más sabrosos, le seguían los negros y, por último, a gran distancia, lo de color marrón. También nos decía que en Inglaterra, las palomas tenían mucha suerte.

¿Crees que el consumidor taiwanés sabe lo que compra? ¿Lo sabemos nosotros consumiendo callos, caracoles o piernas de cerdo que cuelgan por decenas en un bar? Nuestros potenciales clientes no saben lo que quieren. Ni siquiera lo sabemos nosotros. A todas luces, tomamos decisiones irracionales.

Acudimos a una feria, exponemos nuestras ideas y un par de entusiastas nos felicitan por el trabajo realizado. Nos llenamos de orgullo y vamos repitiendo esos halagos como credenciales que avalan nuestro producto: «El director de marketing de ACME SA y el de operaciones de Parts Unlimited (viejos amigos) me han dicho que les encantó y que me comprarían un par cada uno». Previamente habremos ignorado a aquellos que nos dijeron que era caro o lento. Después de todo, sabemos que no podemos gustarle a todo el mundo.

Una vez en el mercado y comprobado el escaso éxito, podemos tender a seguir metiendo más y más dinero en él. Parecemos pensar: «Si le añadiésemos esto o esto otro, seguro que, ahora sí, superará a la competencia. Solo necesitamos una par de meses de trabajo y 100 000€ más». Habrá aversión a la pérdida, temor al coste hundido, y lo que es peor, un orgullo herido.

Sondea el mercado con el menor riesgo posible. Rellena un Business Canvas Model, utiliza el Hook Framework, realiza un producto mínimo viable (Concierge, Mago de Oz o de Ventas) y mide las respuestas. Vas a necesitar unos meses y pivotar más de una vez, pero no corras el riesgo de perderlo todo.

Si te gustaron estos contenidos, probablemente te gusten también los de mi último libro con Anaya: Gestión de proyectos – Agilidad en la práctica. Puedes encontrarlo en Amazon, la Casa del Libro, la FNAC o en las librerías cerca de tu casa.

Ángela Padrón (@AngMartina) ha resultado ser la nueva ganadora en el sorteo de un ejemplar de mi libro, Gestión de proyectos – Agilidad en la práctica.

Se han recopilado todos los likes/comentarios al anuncio del sorteo en Twitter y LinkedIn, y se han añadido los nuevos suscritos a mi blog. De entre todos ellos ha salido Ángela ganadora con el número 170.

Enhorabuena!

Entre todos aquellos que me sigan en twitter (_antoniomartel) o se suscriban a este mi blog entre hoy y el próximo domingo 17 de noviembre, participarán en un nuevo sorteo de mi libro Gestión de proyectos: Agilidad en la práctica. Si haces las dos cosas, tendrás dos participaciones en el sorteo.

Para suscribirte a mi blog, puedes acceder a la columna derecha de antoniomartel.com y dejar tu correo en la casilla de suscripción, pero también puedes aprovechar para obtener una copia gratis del libro Curso práctico de Scrum. Además de obtener el pdf, estarás suscribiéndote a este blog y participando en el sorteo.

No dejes de pasarte por la sección de artículos del blog o el enlace al curso para la certificación Professional Scrum Master I.

¡Suerte en el sorteo!

Forma parte de la cultura popular el trol en los juegos de rol y películas de ficción que no te deja pasar el puente si no le respondes adecuadamente su acertijo. Si no hay respuesta correcta, no hay manera de cruzar al otro lado.

Ya desde la Antigua Grecia, existía el convencimiento de que a los muertos había que enterrarlos con una moneda bajo la lengua. De esta manera podrían pagar a Caronte, el gruñon barquero que los cruzaría al otro lado del río Aqueronte, evitando así que su alma vague durante cien años por el infierno.

También en la mitología griega, el monstruo Esfinge, un ser con rostro de mujer, cuerpo de león y alas de pájaro, mataba a todo aquel que no respondiera correctamente a su pregunta: «¿Cuál es el animal que cuando es joven camina a cuatro patas, a dos cuando es adulto y a tres cuando es mayor?».

¿No te has sentido así alguna vez cuando recurres a algún profesional para pedirle algo y actúa como la Esfinge? «Debes pedírmelo con tres semanas de antelación, para que pueda prepararlo», te dirá molesto por tus prisas.

Cuando la próxima vez, preocupado por no incomodar, acudas a él o ella con tiempo suficiente, probablemente te diga con evidentes signos de enfado: «¡Pero si no me has puesto el nombre del solicitante en el formulario!»

En situaciones similares, después de hacerte esperar las tres semanas de rigor, te manifiesta: «Esto no puedo hacerlo, no es seguro. Necesito la aprobación de tu responsable, el mío y el de la directora de esta cuenta». Aún así cree que no debería hacerse y que sería mejor dejar las cosas como están. Por lo menos tiene la tranquilidad de que la responsabilidad no será suya. Y así lo hará saber a todo el mundo.

Todo es un riesgo demasiado grande y requiere de innumerables controles. El responsable de seguridad, el de compliance, el auditor de cuentas o el fiscal, todos los que son consultados tienen alguna pega que poner. Deben tener en cuenta cada minúsculo detalle, aunque con ello vuelvan de revés toda la empresa. Despues de todo, ¿para qué si no están allí? Algo tendrán que decir.

En algunos casos parece ser una necesidad de sentirse importantes o valorados por sus aportaciones. ¿Dónde estaría ahora la empresa si no estuviesen ellos allí para advertir del grave riesgo que se corre a cada paso que se da? En otros es más parecido al miedo al cambio. Todo debe permanecer igual, ¿para qué cambiar si puede haber algún riesgo?, «La manera en que se ha hecho todo en los últimos veinte años no ha ido tan mal, ¿por qué cambiar?».

Algo podría no ir bien, y entonces estarán ellos allí para recordárnoslo. Resaltarán solo esa parte, lo que funcionó y nos llevó por nuevos derroteros, no será algo que destaquen tanto.

Si quieres leer más historias como esta, puedes encontrarla en mi nuevo libro Gestión de proyectos: Agilidad en la práctica o en mi blog antoniomartel.com.

Referencias:

• Caronte en la Wikipedia
• Esfinge en la Wikipedia

Cómo seguramente ya sabrán, estuve el pasado miércoles y jueves, 30 y 31 de octubre, impartiendo unas charlas en al ciudad de Valencia, España, y presentando mi último libro con Anaya: Gestión de proyectos, Agilidad en la práctica.

Muchas gracias a la Cátedra Sothis de Transformación Digital de la Universidad Politècnica de València y a Mobiliza Academy por invitarme a sus instalaciones y abrirme las puertas al público valenciano.

Comparto con ustedes los enlaces a las dos presentaciones que realicé:

• Reacción en cadena de la Agilidad, impartida el día 30 en Las Naves.
• Cómo sobrevivir a la implantación de Scrum, facilitada el día 31 en el Parc Científic de la Universidad de València.

Dejo aquí también algunas fotos de las dos charlas para que se hagan una idea de cómo fue:

Si te saltaste todas las páginas de este libro para acceder a este capítulo, tienes un problema, quizás tú seas el incompetente.

De esta forma, más o menos, comienza el libro de Gabriel Ginebra, Gestión de incompetentes[1]. Fue una frase que me chocó cuando la leí nada más comenzar el libro. Reconozco que cuando vi el título del libro me llamó la atención inmediatamente y lo compré para leerlo.

El libro me hizo pensar si era yo el verdadero incompetente, el que no podía sacar los proyectos adelante. Todos tenemos nuestra forma de hacer las cosas, una forma que nos llevó a que nos colocaran en puestos de responsabilidad, pero no estaba seguro de que supiese llevar equipos de trabajo o si lo estaba haciendo realmente mal y encima les culpaba.

Cuando te toque trabajar en equipo o ayudarles a que sean más productivos, vas a tener que colaborar con todo tipo de compañeros; quizás unos más hábiles que otros, pero no tan exhaustivos como otros en su trabajo. Tendrás toda una gama de colores dentro de la productividad, calidad del trabajo, rendimiento, facilidad de trato o actitud. Nunca tendrás al equipo perfecto que trabaja sin desmayo y lo resuelve todo en minutos.

Tu empresa no es Google: no podrá tirar de talonario y dar condiciones de jeque árabe para contratar solo a los mejores. Aun así, aunque tuvieses muchísimo dinero, no podrás contar con todos ellos, nunca serán suficientes. Siempre habrá quien prefiera seguir trabajando donde está porque ya le pagan bien. Gente que va a la oficina cada día porque está contento con su jefe o con lo buena que es la comida en el bar de abajo y las charlas que tiene allí con sus compañeros.

Lamentablemente, el talento no crece debajo de los árboles. En cada rincón del país, en cada zona del mundo, alguien tiene la genial idea de crear un nuevo Silicon Valley. Se construye un campus enorme, se crean varios edificios muy modernos y se subvenciona fuertemente a las empresas que allí se sitúen. Sin embargo, pocas de estas iniciativas llegan a tener cifras de relevancia. Simplemente, no hay tanta gente con talento e iniciativa como para tener un Silicon Valley en cada ciudad del mundo. El talento está limitado.

Pero tu trabajo no es ese, trabajar con los mejores puede hacerlo cualquiera. Lo difícil es obtener el mejor rendimiento de los colaboradores y ese rendimiento solo se obtiene si se facilita la cooperación, la armonía, la tranquilidad y la productividad. Quejarse amargamente de que tus compañeros no son unos genios de la ingeniería o el diseño, no te va a ayudar.

Este es un extracto del libro Gestión de proyectos: Agilidad en la práctica. Si quieres conocer más sobre este o algún otro de mis libros. Haz clic en la imagen para dirigirte a Amazon:

[1] Ginebra, Gabriel: Gestión de incompetentes, Libros de Cabecera, 2012

Quién no quiere trabajar con colaboradores brillantes y expertos en su campo, alguien que resuelva todas las papeletas difíciles. Desafortunadamente, cuando colaboramos con alguien así tenemos que contar con muchos más factores de los que se indican en su expediente académico o en su currículum vitae.

Hay auténticos divos en la oficina que creen estar en posesión de la verdad absoluta y que cualquier objeción a su propuesta la toman como algo personal. Algunos menosprecian la calidad del trabajo de sus compañeros o las ideas que proponen porque no las consideran a su altura. Se crea un mal ambiente de trabajo donde los demás no se sienten valorados, ni siquiera el genio incomprendido, al que nada consigue llenar su ego.

Lo que parece ideal, no siempre lo es, y trabajar con un genio no garantiza nada. Hay quien tiene ideas geniales y grandes conocimientos en diversas técnicas o tecnologías, pero no utiliza todo eso de forma eficaz. Se dedica a añadir todas las características del mundo al producto, solo porque piensa que el cliente las necesitará, o porque le hace parecer más inteligente. Llega a rehacerlo todo continuamente porque cree que solo a su manera están bien construidas las cosas.

He visto casos en equipos en los que todas las decisiones se veían entorpecidas por el miembro del equipo más brillante, para quien ninguna propuesta era lo suficientemente buena: siempre era necesario parar máquinas, volver atrás y rediseñar el sistema completo para que, ahora sí, estuviese bien construido. No les gustaba reconocer sus errores tampoco y nunca admitían estar equivocados. Por muchas que fueran las evidencias, solo se conseguía que se enfadasen. El error está siempre en las indicaciones que les han dado, en el cliente, que no sabe lo que quiere o en los usuarios que no saben usar el producto.

A veces no están contentos con el trabajo de los colaboradores más inexpertos o novatos en el proyecto. Las quejas son frecuentes: «No sé para qué lo tenemos, que me den su sueldo a mí. Yo lo hago todo». Y así se lo hacen saber a esos compañeros, haciéndolos sentir infravalorados o inútiles.

Tras la salida de estas personas del proyecto, todo comienza a fluir mejor. Aquellas partes que nadie se atreve a tocar porque eran complejas resulta que sí podían encargarse a otra persona. Se resuelven muy bien y se sigue adelante sin tanto tiempo perdido en reuniones. Además, los miembros del equipo que quedan se sienten ahora más importantes y realizados. Su trabajo no está ahora siempre en duda, ni están dedicados solo a tareas menos relevantes.

Por muy buenos que sean estos gurús, nunca podrán hacer las cosas tan bien o tan rápido como tres o cuatro de sus compañeros, si están bien preparados o coordinados para hacer el trabajo. La falta de brillantez puede estar compensada con la rigurosidad, la calidad, el buen análisis o la sensatez. Y aunque así fuera, estas personas también toman vacaciones, se ponen enfermas o dejan la empresa. Todo el trabajo no puede parar por eso.

No todo es tan malo cuando se trabaja con genios, por supuesto, no todos son así. Hay auténticos genios del mundo laboral con los que es una delicia trabajar (aunque a veces se desesperen cuando los demás no les comprenden). Si encuentras uno de estos, no lo dejes escapar. Asegúrate de que sus superiores tienen claro lo mucho que está aportando al trabajo y que se lo reconocen. Si no, antes o después, buscará otro lugar donde sí valoren justamente sus aportaciones.

Este es un extracto del libro Gestión de proyectos: Agilidad en la práctica. Si quieres conocer más sobre este o algún otro de mis libros. Haz clic en la imagen para dirigirte a Amazon: