Ajedrez - antoniomartel.com

Archivos de Categoría: Blog

Trabajando con genios

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:

Gestión de proyectos. Agilidad en la práctica.
Gestión de proyectos. Agilidad en la práctica.

Ya en preventa mi libro Gestión de proyectos – Agilidad en la práctica

Si acudes ahora a Amazon.es, puedes encontrar en preventa mi nuevo libro Gestión de proyectos: Agilidad en la práctica. Si reservas ahora tu copia, recibirás el libro impreso dentro de unos 25 días: el 10 de octubre (aún se está imprimiendo y pronto comenzará la distribución a las librerías).

No es un libro sobre teoría de Scrum, Lean o Extreme Programming, aunque haya un breve capítulo explicando sus principios para los no iniciados. Si ya conoces los puntos básicos de los principales marcos de trabajo de la Agilidad, puedes saltarte esa parte. De hecho, el libro funciona bastante bien si no conoces nada de Scrum.

Desde luego, no es un libro solo para informáticos, gente de IT, o aquellos profesionales ya iniciados en Scrum. Pretende ser un libro ágil, de fácil lectura, con pequeños apartados de dos o tres páginas cada uno donde se explica cada concepto. Cada uno casi totalmente independiente del otro.

Este libro es para ti si trabajas a diario en un equipo, si tienes responsabilidades gestionando, o si simplemente tu trabajo diario se atasca y no sabes qué hacer para cumplir, esta vez sí, las fechas de entrega.

No trata solo de gestión de proyectos. También explica cómo gestionar equipos de trabajo, sacar mejores productos al mercado, o mejorar tu productividad personal (por lo menos entender en qué se te van las horas o cómo usarlas mejor).

Tienes más información sobre el índice y los contenidos en mi blog antoniomartel.com.

Reserva ya tu copia antes de que se agote (la tirada no es infinita). Haz clic en la imagen para acceder a Amazon:

 Gestión de proyectos. Agilidad en la práctica.
Gestión de proyectos. Agilidad en la práctica.

Posdata: De momento, la preventa parece ir bien. Si buscas simplemente por las palabras «Gestión de proyectos» en Amazon España, este libro aparece ya en 6º lugar (el 5º es mi primer libro, y el primero, un libro editado por la Harvard Business Review).

Todo el mundo tiene derecho a equivocarse

Si quieres construir un equipo sólido deberás ser tolerante con los fallos, con las peculiaridades de cada uno y animarlos a que prueben e intenten cosas. Deben saber que pueden hacerlo de forma tranquila, que no les va a pasar nada si algo sale mal, que están respaldados por todo el equipo.

Existe una especie de cultura en muchas empresas, a veces en la sociedad en general, en la que, cuando algo pasa, y se comete un error, todo el mundo busca un culpable. Se le busca, señala y encuentra para luego decidir que él o ella son los culpables de todo lo sucedido. A partir de ahí siempre quedará una mancha en la confianza en esa persona que la estigmatizará por mucho tiempo.

Esto crea un sistema en el que todo el mundo está más preocupado de no tener que tomar decisiones importantes, y no tan importantes, a menos que se lo ordene alguien y lo ponga además por escrito. Se escriben documentos y emails a todo el que pueda pintar algo en la decisión para que estén al tanto y manifiesten su visto bueno, pero estos no quieren comprometerse tampoco. Como resultado de todo esto, no se toman decisiones, nada se mueve, nada avanza y los departamentos legales o los consultores de seguridad, protección de datos o auditores en la empresa tienen un montón de consultas en sus despachos.

A esto en inglés se le llama la cultura del CYA (cover your ass). Si se usa una mano para cubrirse las espaldas, solo queda una disponible para trabajar. El equipo estará más ocupado buscando confirmación de los superiores, escribiendo documentos y correos con justificaciones, que en pensar la mejor forma de hacer el trabajo.

No se trata de que todo se tome a la ligera, siempre hay que adoptar alguna precaución, pero debemos admitir que, a pesar de eso, los problemas ocurren, los errores se cometen. Si cuando esto sucede, comenzamos a preguntar y preguntar sobre quién decidió esto, quién lo hizo o por qué, y así seguimos hasta sacar los colores a alguien, vamos a causar más problemas que beneficios. Nadie hará ni propondrá nada, solo se hará lo que el jefe haya indicado expresamente, pero ¿para qué hay un equipo entonces si cada pequeña acción la decide elgerente?

Si algo pasa, no hay problema, los errores se comenten todos los días. Todo el mundo se equivoca. Sí, tú también te equivocas. Por acción o por omisión ¿seguro que no cometes ningún error? Ya te aseguro que alguno cometes, si no fuera así, tu equipo o tu empresa serían líderes mundiales o irían camino de ello. Seguramente no es el caso.

Ayudará mucho si, cuando surge un problema, comienzas diciendo «Me equivoqué, es culpa mía ¿Me echan una mano?». Si eres el responsable del equipo, animarás a otros a que lo digan cuando ellos hayan metido la pata (y evitará que el problema se agrave porque lo están escondiendo). Crearás un clima de confianza y naturalidad que se notará en la productividad y el rendimiento, pero no solo eso, estarán más dispuestos a hacer un esfuerzo, ayudarte a solucionar el problema y sacarte del apuro.

Scrum y la Prisa, esa inflexible anciana

La Prisa, la exigente viejecita que domina nuestras vidas, no solo nos hace escoger las tareas más fáciles para acabar pronto, también nos presiona para que le demos algo rápido, lo que sea, incluso si no está bien terminado. No tiene tiempo que perder, quiere algo y lo quiere ya.

Los nervios por perder nuestro cargo o nuestro empleo acuden a la Prisa para que presione al equipo. Quiere que le entreguemos nuestro trabajo cuanto antes. Ya habrá tiempo para florituras después, no puede esperar más. Si no está bien probado o terminado, ya lo haremos después; con suerte no pasará nada cuando alguien esté usando nuestro producto. Si esto sucede, le pondremos un parche rápido y ganaremos algo más de plazo para una futura corrección. Qué lejano parece siempre el futuro, pero solo está a un segundo de distancia.

Después de entregado, respiramos aliviados. ¡Hemos sobrevivido! Han surgido algunos problemas en la reunión de demo, pero en los próximos sprints le dedicaremos tiempo a corregirlo.

Pronto nos damos cuenta de que la corrección de esas incidencias nos consume más recursos de los previstos. Además, no paran de aparecer nuevas: a las de la semana anterior se suman las de sprints previos.

Cuando decidas ignorar un aviso o esconder problemas debajo de la alfombra, ten por seguro que volverán a aparecer. Y lo harán exigiendo al menos tres veces el tiempo que en su momento habría sido necesario: primero necesitará volver a reconocer el problema, después recabar datos y ponerte en la situación necesaria para corregirlo, y por último, tendrás que solucionar todos los problemas que el error haya generado en el tiempo en que estuvo en producción. Todo esto tener en cuenta que puede que tengas que aplacar la ira del cliente, devolver dinero o responder las quejas de los usuarios.

Pero la Prisa no permite que te olvides de ella. Sigue demandando cosas nuevas, aunque apenas has podido hacer algo; los últimos sprints los has estado dedicando a corregir problemas anteriores. «Bueno, entregaremos lo que tenemos hasta ahora, aunque no esté bien, pero saldremos así del paso», pareces pensar. En algún momento, no sabes cómo, saldrás de este círculo vicioso.

Entregas algo, lo que sea, esté como esté. Una solución rápida para escapar y volver a coger resuello. Crees con esto, encontrar algo de paz, pero así no aplacas a clientes y usuarios. Solo creas una situación que se asemeja al famoso meme del dibujo de un caballo que, con las prisas por terminar, acaba siendo garabateado. Empiezas a ir rápido, pero acabas yendo cada vez más despacio. En cada recodo del camino coges una nueva piedra que echas a tus alforjas. Llega un momento en el que apenas puedes avanzar más.

No sucede solo cuando estás preocupado por tu puesto de trabajo o por contentar a un cliente que se puede marchar. A la Prisa, también recurren el Orgullo y la Vanidad. Queremos mostrar lo rápidos y ágiles que somos con nuestro reluciente Scrum; comenzamos a medir la velocidad y a mostrar a todos los Stakeholders todo lo que hemos podido acabar esta semana.

Cuatro funcionalidades nuevas esta semana, seis la próxima, y ocho la siguiente. Insistimos al equipo para que termine ya esto que están haciendo, no importa cómo. Tenemos que entregar más cosas. «¿Cómo podemos enseñar en la reunión de demo solo dos funcionalidades nuevas?», pareces pensar. Pronto tendremos que parar para corregir problemas mal resueltos en sprints anteriores. A menos que sigamos con esta carrera de la rata, y para continuar con este ritmo, continuemos entregando trabajo aún a medio cocer.

Cuando la velocidad y las reuniones de demo de Powerpoints comienzan a importar más que la calidad y el trabajo bien hecho, es cuando comenzamos a caer en un Scrum que hace más daño que bien. Un Scrum hueco, que solo es una cáscara que esconde un producto defectuoso y un estrés que perjudica al equipo de trabajo. No nos pagan por trabajar rápido. Nos pagan por un producto o servicio útiles que resuelve los problemas del cliente.

Algunos, cansados de estos Scrum flácidos, se han orientado hacia el movimiento Software Craftmanship[1]. Sobre esta tendencia, el conocido Uncle Bob, indica lo siguiente en uno de sus artículos (solo por mencionar algunos puntos).

  • Estamos cansados de escribir mierda.
  • No vamos a crear un desastre solo para cumplir un calendario.
  • No aceptamos esa estúpida idea de ya «limpiaremos» las cosas luego.
  • No aceptamos la opción de hacer las cosas mal.
  • No permitiremos a nadie que nos fuerce a hacer cosas de forma poco profesional.
  • Cumpliremos los calendarios porque sabemos que la única manera de ir rápido es hacerlo bien.
  • Si algo merece la pena hacerse, merece que se haga bien.
  • El paso lento y constante gana las carreras.

[1] Martin, R. Software Craftsmanship: What it’s all about [en línea]. The clean coder. Disponible en http://thecleancoder.blogspot.com/2011/01/software-craftsmanship-what-it-all.html.

Si el cliente gana, tú ganas

Sucede con frecuencia. Nos dejamos llevar por la ceguera de las cifras y los presupuestos de nuestro proyecto. Vamos mal (siempre vamos mal) y queremos recortar esa sangría de horas que le estamos dedicando a la construcción de nuestro producto. El cliente nos pide cambios y mejoras, pero no podemos dedicarle un minuto más: «Nos vamos a salir del presupuesto, no me van a pagar el bono este año y no conseguiré que me den proyectos más grandes».

Es aquí cuando pensamos que lo que nos falta es ponernos firmes con el cliente y decirle muy claro que tenemos que dejar el proyecto tal y como está. «Después de todo, el contrato dice que hay que hacer un control de stock y un inventario de artículos, y eso es lo que hemos hecho», piensas. «Si aún es lento o quedan cosas que arreglar, tendrá que contratarnos de nuevo. Que busque presupuesto, y nos llame, que le pasaremos una estimación conveniente».

Ponte por un momento en los zapatos del cliente. Ha invertido una importante suma de dinero en el proyecto, y después de meses de trabajo, aún no tiene nada que le funcione. Te ha contratado a ti y a tus compañeros para que le aporten una solución a su problema, y lo único que tiene desde hace semanas son disputas sobre esta o aquella línea del contrato.

Puede que te vuelva a contratar para que termines el trabajo, pero mucho me temo que lo hará a regañadientes, y no por voluntad propia. Habrás ganado esta batalla y salvarás temporalmente el proyecto, pero este cliente no contará contigo para proyectos futuros. Tampoco hablará bien de tu empresa a sus colegas. La visión de túnel y el cortoplacismo te impiden ver más allá de los próximos meses o el presupuesto de este año, pero ¿qué vas a hacer cuándo termines ese trabajo y no suene el teléfono?

Intenta asegurarte de que resuelves el problema del cliente. Para eso te paga, para que pienses en cómo mejorar sus procesos, no para que luches por tu presupuesto o dediques tu tiempo a interpretar el contrato de la forma que te es más propicia. Colabora con él e intenta entender dónde puedes aportar más valor. Probablemente estará encantado de quitar otras cosas de la lista si puedes ayudarlo con su principal dificultad.

Entrega también tu trabajo poco a poco y ponlo a funcionar. Deja que lo usen. Los usuarios pronto verán qué les es útil y qué no. Todas esas funcionalidades que pintaban bien sobre el papel, quedarán pronto olvidadas cuando puedas resolverles sus principales inconvenientes. Las negociaciones son mucho más sencillas si la otra parte sale claramente beneficiada.

Suscríbete