The error of choosing the cheapest supplier

A common mistake in projects is choosing the cheapest supplier to save on costs. There is a risk that it will be because it cannot compete on quality with other suppliers and will have to compete on price. The other solution providers are probably better at managing uncertainties, and choosing this one adds uncertainties and delays to the project.

A 20% discount in the choice of the supplier can represent only 2% in the total cost of the project. Is it worth putting at risk the delivery of the entire project, the costs due to delays, or the extra costs due to quality or errors for a supposed 2% savings?

Read in the book “Critical Chain” by Eliyahu M. Goldratt.

Publicado en Blog 1 | Deja un comentario

When everything is a priority, nothing is a priority

I remember when I read the book “Prioritizing the Product Backlog” by Roman Pichler. He wrote: “I’ll never forget the day when I suggested to the product manager of a new health-care product to prioritize the use case pile in front of her. She looked at me, her eyes widening, and replied, ‘I can’t. They are all high-priority’”.

Quoting to Karen Martin: “When everything is a priority, nothing is a priority”. I have faced this issue too. I tried to solve it by telling the manager that the team couldn’t be working on five tasks at the same time and asked her what she wanted to obtain first. She didn’t hesitate a second and pointed to one of the user stories. “No doubt,” she said, “this one, definitively”.

Publicado en Blog 1, English | Deja un comentario

How does Agile help you to deliver?

Have you ever wondered why Agile is so widely adopted? How does it help companies to deliver sooner and better? Here are some tips:

  • Releasing frequently improves customer satisfaction and allows the client to decide how the product is evolving.
  • Sprints are small milestones. They help you to overcome the Parkinson laws and avoid feared deadlines at the end of the project, when little can be done if something went wrong.
  • The Kanban board, the backlog and the sprint backlog make visible the pending work and how we progress (have a look at the Checklist Effect by Atul Gawande).
Publicado en Blog 1, English | Deja un comentario

Deadline Driven Development

I have recently read the article «Deadline Driven Development» from Simón Muñoz. Quite a captivating one.
As in TDD, we create tests before developing the solution, he suggests setting a deadline before estimating, and then doing only what can be done until that deadline.
There are multiple perks to that approach: product managers avoid scope creep, and adding unnecessary features to the product being built. Other than that, developers will reduce the overengineering or creating too complex solutions, far beyond what is needed.
We will be reducing waste by building applications or services with just the two or three most important uses cases . Then, we can release our service, and see what was useful, what our clients require now, when they can use the product. From that point we can make more informed decisions on investing more, and better (or to cancel the product).


See the link to the original blog post (in Spanish): Deadline Driven Development by Simón Muñoz.

Publicado en Blog 1, English | Deja un comentario

Mi experiencia con SAFe

En muchas empresas de tamaño grande han estado teniendo problemas con la adopción de Scrum. Tienen múltiples equipos trabajando en diversos productos interconectados y cada vez que tienen que acometer un desarrollo en el que hay dependencias distribuidas entre esos equipos, los tiempos de entrega se alargan indefinidamente.

Es por eso que un porcentaje alto de esas empresas han decidido adoptar SAFe (Scaled Agile Framework Enterprise) buscando escalar la agilidad al tamaño de sus proyectos. Cuando me enfrenté a esta forma de trabajar por primera vez, lo hice algo preocupado porque fuera un monstruo demasiado grande de digerir y se tragara la posible agilidad que pudiéramos tener.

Lo cierto es que tiene algunas cosas buenas: el Product Owner debe aprobar cada desarrollo (lo que suele implicar que todo el mundo revise bien su trabajo para evitar un rechazo) y los Planning Interval cada tres meses te fuerzan a tener en mente los objetivos a largo plazo que tiene la empresa.

Por otro lado, esa planificación tan a «largo» plazo puede hacer que se pierda algo de flexibilidad. Además de que las reuniones de coordinación entre todos esos equipos de trabajo hacen que el tiempo empleado en reuniones (y la multidud que asiste) se multiplique por varios órdenes de magnitud.

Desde luego, no ha estado mal la experiencia. Quizás, cuando la vea dentro de unos meses, valore haber ganado, o perdido, otras cosas de las que ahora no me doy cuenta.

Publicado en Blog 1 | Deja un comentario

¿Sprints de solo una semana?

Hace algún tiempo me preguntaron por la duración de los sprints en los equipos en los que trabajaba, y les contesté que eran habitualmente de dos semanas. Habíamos hecho alguno de solo una semana, pero nos parecía demasiado overhead de reuniones y eventos de Scrum. También alargábamos a tres semanas durante las vacaciones de verano y Navidad, pero teníamos la sensación de perder de vista en qué semana del desarrollo estábamos.

Ya no veo tan mal los sprints de una semana. Con los de dos vemos siempre que la gráfica de burndown se mantiene plana durante todo el sprint, y baja solo durante los dos últimos días de la iteración (ya conocemos la Ley Parkinson: el trabajo se expande hasta que ocupa por completo el tiempo destinado para su realización).

Con solo una semana por sprint, la gráfica sufre el mismo problema, pero en la mitad de tiempo. Además es más fácil acertar en la velocidad del equipo y lo que puede comprometerse: tienes una mejor idea de lo que puedes hacer en solo cinco días (y reaccionar si surge algo imprevisto). Cuestión de seguir probando.

Publicado en Blog 1 | Deja un comentario

Features versus bugs

Cuando ponemos una nueva features en producción o liberamos nueva release, aparecerán inevitablemente algunos errores de cuando en cuando. Si no los solucionamos sino que seguimos desarrollando nuevas features, seguirán habiendo un porcentaje nuevo de bugs. Llegará un momento en el que dedicaremos más tiempo a poner parches y solucionar errores urgentes en producción que a desarrollar nuevas features o historias de usuario, que es lo que mantiene a nuestro producto en el mercado.

Si llegamos a una nueva empresa, revirtamos esa tendencia. Enfoquémonos en solucionar deuda técnica eligiendo una lista de los principales dolores de cabeza y dediquemos un par de historias de usuario cada sprint a solucionarlas. Una vez solucionado, ataquemos el siguiente problema según el tormento que nos cause.

Cuando haya pasado un tiempo veremos que ya no hay tantas llamadas urgentes, que los desarrolladores no están todo el día apagando fuegos y tienen disponibilidad (además de concentración, foco, y menos interrupciones) para desarrollar nuevas funcionalidades, que ahora sí, aportarán valor al producto.

Pasado un tiempo, confiemos en que no mucho, deberíamos ver una gráfica como esta (si no la tienes, deberías creártela, te podría sorprender lo mucho que estás dedicando a waste, en lugar de a nuevo valor).

Publicado en Blog 1 | Deja un comentario

Si tu trabajo es comerte una rana

Mark Twain dijo una vez: si tu trabajo es comerte una rana, es mejor hacerlo a primera hora de la mañana. Y si tu trabajo es comerte dos ranas, es mejor comerse la más grande primero. Si quieres ser productivo y no dejarte las cosas esenciales detrás, haz las cosas más importantes o difíciles primero. Verás si eres capas, si el proyecto es viable. Luego tienes el resto del día (o del proyecto) libre para mejorar y con la tranquilidad de haber resuelto los principales problemas primero.

Al principio de la mañana, el proyecto o de la tarea, estás más despierto, más animado, más concentrado. Todavía tienes recursos por delante para reaccionar si es más difícil de lo esperado o se requieren otras acciones. Al final el mismo, estarás comprometido con las fechas de entrega, más estresado y con más prisas. No harás las cosas importantes bien o las dejarás a medio cerrar. Puede sucederte como en ese clásico meme de las redes sociales en las que se ven los cuartos traseros de un caballo dibujados con gran exactitud y precisión, pero a medida que el dibujante avanza hacia la parte delantera, debido a la presión por entregar, va eliminando trazos y simplificando los detalles hasta entregar solo una caricatura de la cabeza del caballo.

Siempre hay cosas en el trabajo que nos resistimos a hacer. Son más difíciles, requieren de más dedicación, o tenemos miedo de hacerlas mal y que seamos criticados por ello. Asegúrate de que en el equipo de trabajo hay «coraje» para enfrentarse a ellas y acometerlas de una vez. Coraje, entendido como en Extreme Programming, surge donde se ha creado un ambiente en el que no hay miedo a ser castigado o criticado por cometer un error.

A todos nos cuesta comernos las «ranas» de nuestro trabajo. Es algo completamente normal. ¿No has visto alguna vez, que cuando en el backlog hay diversas tareas y una de ellas es un trago más amargo que las demás, todas las historias de usuario se terminan excepto la más compleja? Pasará una y otra vez al siguiente sprint casi sin tocar donde volverá a suceder lo mismo con las nuevas tareas añadidas. Hasta que no eliminas las «distracciones» y los hitos fáciles de conseguir del sprint backlog, no conseguirás que se decidan a atajar el problema.

Una vez has acabado con sapos y culebras, todas las nuevas tareas en tu To-Do list te parecerán un plato mucho más fácil de digerir.

Publicado en Blog 1 | Deja un comentario

Por qué estudiar inglés

Hace algún tiempo quería actualizar un poco mi CV. Llevaba un par de años de añadir nada significativo y creo que todos debemos ir mejorando poco a poco nuestros conocimientos y habilidades. Si no me equivoco, era Asimov el que decía «Education isn’t something you can finish«. Por otro lado, los recruiters tienen lo que ellos llaman «un detector de gente poco motivada» y si ven perfiles que llevan dos años al paro sin hacer nada o actualizar su inglés, quizás consideren que vas a mostrar el mismo poco entusiasmo por aprender o mejorar en un nuevo puesto.

Me decidí a no hacerlo a tontas y a locas, y sumar el enésimo curso de introducción a Inteligencia Artificial o Ciberseguridad. Traté de realizar un estudio para ver qué conocimientos, certificados, o frameworks eran los más demandados en las ofertas de trabajo Indeed, LinkedIn o Glassdoor. También pregunté a varios colegas por la skill que me hiciese más valioso en una entrevista de trabajo. Después de repetir el estudio varias veces llegué a las siguientes conclusiones: en primer lugar debía mejorar mi inglés, tras eso, insitir con el inglés, y por último continuar mejorando el inglés. Todos los caminos me llevaban a que esa era la habilidad más demandada para mis circunstancias (y probablemente para la de muchos).

A lo largo de mi vida profesional, he tropezado varias veces con este idioma: en mi primer trabajo con clientes alemanes, el segundo ingleses, luego han venido americanos, suecos o luxemburgueses (en la mayoría estaba trabajando desde Canarias). No lo habría pasado tan mal intentando chapurrearlo si el inglés hubiese sido mi prioridad desde hace un par de décadas, además del gran número de puertas que se me habrían abierto a trabajar con salarios europeos.

Si realmente quieres marcar la diferencia, estudia inglés. Apúntate a alguna de las escuelas oficiales de idiomas que tenemos repartidas por las islas (y por el resto de España). En casi cada pueblo grande hay una sede abierta para estudiar por las mañanas o por las tardes, y por alrededor de 74€ al año puedes tener clases dos veces a la semana con profesores de alto nivel. Además podrás certificarte al final del curso en alguno de los niveles del marco europeo de referencia de las lenguas (A1, A2, B1, B2, C1 y C2). Certificados que, por otro lado, son muy valorados en el sistema de puntuaciones de múltiples oposiciones a gobiernos y ayuntamientos.

Ten en cuenta que los certificados no son lo más importante. Suponen un hito y una prueba de nivel que hará que te esfuerces para llegar a estar a la altura. Quizás incluso te consiga alguna entrevista si el recruiter ve tu certificado en el CV, pero será realmente en la entrevista donde tendrás que demostrar que entiendes y te haces entender bien. Y si no hablas el nivel requerido para el trabajo, ya puedes tener un C2 en tu currículum, que no serás contratado (ten por seguro que un hiring manager en una empresa americana o irlandesa no sabe qué carajo significa «C1». Él o ella solo sabe hablar inglés).

Para niveles altos, las 150-175 horas anuales de la EOI no son suficientes. Tendrás que complementarlas:

  • Viendo series de televisión en inglés en cualquiera de las plataformas online (Netflix, HBO, Prime Video).
  • Viendo la televisión o noticias en canales extranjeros (TVMucho).
  • Escuchando la radio o podcasts (RadioGarden, BBC Sounds).
  • Leyendo todo lo que puedas en el idioma de Shakespeare (si es posible, lee en alto para practicar la pronunciación). Compra todos tus libros en la versión original, y no en su traducción al español.
  • Seguramente necesites encontrar un profesor particular para las clases de conversación (la asignatura eternamente pendiente para los hispanohablantes) y qué más difícil es de practicar por tu cuenta. Puedes probar en preply.com o encontrando alguna profesora online que te ayude y te cobre por sus clases a través de Zoom o similar.

Ánimo. Poco a poco todo te irá sonando. Lleva años y mucho esfuerzo mejorar el inglés, pero no abandones el curso de la EOI en diciembre, cuando se acerquen los primeros exámenes y se te haga cuesta arriba. Insiste que merecerá la pena. Persistence is paid off!

Publicado en Blog 1 | Deja un comentario

Número 64 en Internet y Web

Hoy recibo una notificación de Google Alerts indicando que Amazon está mostrando mi libro, Gestión práctica de proyectos con Scrum, en la posición número 64 de los libros (ebooks y libros convencionales) más vendidos en la categoría de Internet y Web. Además está en la posición número 10 en ventas para la clasificación de ebooks sobre Programación y desarrollo de software.

Muy contento de que, después de más de siete años de haber sido publicado, siga alcanzando buenos puestos en la lista de ventas, pero aún más contento de las 288 opiniones y comentarios que el libro tiene. Leerlos siempre me supone un subidón de ego, pero hoy aún más al saber que el libro forma parte de la bibliografía de una de las asignaturas de la Universidad de Buenos Aires, una universidad con más de 200 años de experiencia formando a sus alumnos.

Aquí algunos de los ejemplos de las reseñas del libro:

Publicado en Blog 1 | Deja un comentario

Programar sin ego (II): el equipo de 10 programadores

Hablábamos la semana pasada de cómo entregar tu trabajo para ser revisado, curado, y hasta vapuleado por tus compañeros de equipo, logran grandes piezas de código. Líneas de texto que formarán parte de módulos capaces de resistir casi una década sin generar errores.

Vuelvo esta semana a comentar sobre el concepto de egoless programming de Gerald Weinberg y otro de los ejemplos reales de su libro: el incorruptible equipo de 10 programadores en una empresa aeronáutica.

Se trataba de un equipo que rechazó mudarse cuando su empresa anterior cerró sus instalaciones en la zona para moverse a otro lugar del país. Aunque tenían buenas ofertas individuales, ellos decidieron irse solo con quién los contratase a los diez a la vez.

Fue una el departamento de desarrollo de una empresa de fuselajes de avión la que los contrató y allí continuaron trabajando un tiempo. Cuando el director de desarrollo de esta empresa se encontró en una conferencia con el antiguo mánager de este grupo, le preguntó extrañado: «¿De dónde sacaste a esta gente? ¿Tienes a más gente como ellos? ¿Cuál es su secreto?». Le explicó que siempre que necesitaba que algo se hiciese bien y a tiempo, solo tenía que encargárselo a uno de estos diez. Deben ser algún tipo de genios, exclamó.

Nada había de particular en ellos, le contó, una de ellas era una recién graduada en italiano, otro había enseñado matemáticas en un instituto, un tercero era un ingeniero profesional y otra más se graduó en empresariales, trabajando después como secretaria ejecutiva y contable.

No eran seres sobrenaturales, simplemente, cuando uno de ellos recibía un trabajo, los diez trabajaban sobre él y lo revisaban entre todos hasta dejarlo perfecto. Cuando trataron de explicarle sus métodos, su nuevo mánager entendió que solo uno o dos hacían todo el trabajo y protegían al resto, que quedaban escondidos detrás de los genios de verdad.

Este director no fue tan obtuso como para llegar a disolver este grupo, pero no supo ver la eficacia de estas técnicas, y mucho menos aplicarlas al resto de sus 300 programadores. Un tiempo después estos diez programadores se volvieron a mover, otra vez en bloque, a una empresa más comprensiva con sus métodos.

Apuesta por los pull request, el pair programming, collective ownership, peer reviews y por los tests por todo el equipo. Es una de esas inversiones a largo plazo que se verán recompensadas cuando poco a poco empiezas a salir del caos, las prisas y de las llamadas de clientes enfadados por un bug en producción.


Si quieres saber más sobre egoless programming, echa un vistazo a mi post de la semana anterior: Programación sin ego.


Referencias:

  • The Psychology of Computer Programming por Gerald Weinberg, Nueva York, Van Nostrand Reinhold, 1971.
Publicado en Blog 1 | Deja un comentario

Programar sin ego

Gerald Weinberg, en su libro The Psychology of Computer Programming, nos habla de la Egoless Programming o Programación sin ego. Se refiere con este término al hábito de no considerar el código que hacemos como solo «nuestro» y de nadie más, sino artefactos que pertenecen al equipo y que seguramente contienen errores y que pueden ser muy mejorables.

Es una disonancia cognitiva habitual la de no reconocer nuestros propios fallos, y considerar nuestros programas como verdaderas genialidades. Si alguien encuentra un bug, lo negaremos rotúndamente y echaremos la culpa al análisis que estaba mal hecho, al cliente que no nos dijo que lo quería así o que alguien «tocó» nuestro código.

Weinberg cuenta la historia de alguien llamado Bill al que, consciente de poder tener un mal día, pidió a su compañera Marilyn que revisara el importante trozo de código que acababa de escribir. Marilyn fue capaz de encontrar 17 bugs. Pero para ella esto no era suficiente, sabía que donde se habían encontrado 17 errores, seguramente podría encontrarse alguno más. Entregó una copia a otros compañeros, y entre todos, aún encontraron 3 errores más.

Este código estuvo en producción durante 9 años sin que ningún nuevo error fuese nunca encontrado. Bill, lejos de sentirse herido por las tremendas correcciones hechas a su software, contaba divertido la historia a todo el que la quería oir: le habían encontrado 17 errores en 13 líneas de código!!

Además, ahora no solo Bill sabía cómo funcionaba ese trozo de código, Marilyn y los otros compañeros entendían también de qué iba y cómo mejorarlo cuando las inevitables modificaciones llegasen. El equipo al completo estaba al tanto de esa librería, y además de ser una pieza limpia de errores, cualquiera podía integrarse con ella o ampliarla, si fuera necesario.

Por esto funcionan prácticas como las peer reviews, tests por otros miembros del equipo de desarrollo o el pair programming. Tendremos un código más caro, y lento en producirse, pero más fiable y seguro. Más económico a la larga. Menos estresante también: no será tan habitual las sesiones maratonianas un viernes hasta las 2 de la mañana intentando encontrar un bug o las llamadas de clientes por una caída en producción.


Referencias:

  • The Psychology of Computer Programming por Gerald Weinberg, Nueva York, Van Nostrand Reinhold, 1971.
Publicado en Blog 1 | Deja un comentario

Yo gano si tu pierdes

Solemos verlo así, como un juego de suma cero, pero en raras ocasiones lo es. Lo hacemos con casi todo en la vida, el dinero que ganamos, las amistades que tenemos o los méritos que recibimos o dejamos de recibir.

Pensamos que, si nosotros nos llevamos 100 en un acuerdo, pero por su colaboración con nosotros, nuestros partners se llevan 150, es que hemos salido perdiendo, hemos negociado mal o nos han engañado. Saldríamos mucho más contentos si nos hubiésemos llevado 80, pero nuestros partners solo 60.

No se trata de llevarte el trozo más grande de una tarta (dejando solo migajas para los demás). Se trata de que todos ganen en el acuerdo actual, para que sigan contando contigo en las tartas y contratos que vendrán. Ahora estamos cegados con el proyecto que tenemos delante y no podemos ver más allá de las cifras del trimestre y el balance anual, pero después de este negocio, vendrán otros y luego otros más. Queremos participar en todos, aunque no sea con el trozo de tarta más grande, ¿no?

Intenta hacer la tarta más grande para todos. Busca acuerdos, sinergias y ventajas en la colaboración. Preocúpate de ganar tú, pero piensa también en lo que ganarán los otros. Intenta que ganen lo más posible. Con una buena disposición, serás el primero en llamar cuando haya otro negocio a la vista.

Lo mismo sucede con los clientes, haz que ganen mucho contratándote. Entrégales un gran producto y no racanees en exceso con lo que te piden. Recuerda que si ellos ganan mucho con el acuerdo, tú también lo harás. Si tú pierdes 20 haciendo ese esfuerzo extra, pero ellos ganan 100, tú también terminarás ganando.

El teléfono no parará de sonar cuando hayas acabado el contrato. Serás el primero que tendrán en cuenta cuando quieran buscar a un proveedor de nuevo. Se crean más contratos, y se abren oportunidades que de otra manera irán hacia otro lado o no se crearán. Nadie decide dedicar dinero porque solo augura problemas, discusiones o chapuzas en el trabajo. Ten siempre presente que después de este proyecto deben haber más, este no es el último que vas a hacer.

Tampoco son un juego de suma cero los elogios en el trabajo o el reparto de méritos. Si premian a un compañero de tu equipo por su gran trabajo, también ganas tú. Si tu equipo ha hecho una labor estupenda, pero nadie te menciona, sigues ganando aún más. Los elogios y las buenas consideraciones, si son sinceras, no se gastan, no se pierden, solo se multiplican. Solo pueden sumar.


Referencias:

  • Curso de Coursera Successful Negotiation: Essential Strategies and Skills de George Siedel.
Publicado en Blog 1 | Deja un comentario

De nuevo en Kindle Flash

Amazon ha escogido de nuevo uno de mis libros en formato electrócnico para su promoción Kindle Flash. El próximo martes, 30/6, el libro Gestión práctica de proyectos con Scrum va a ser enviado en una newsletter, junto a otros 3 o 4 libros en español, a todos los usuarios de Amazon suscritos.

Estés suscrito o no, el libro estará solo durante las 24 horas del martes con un 70 u 80% de descuento. Anímate a comprarlo, normalmente no participan ahí libros de gestión, software o informática.

Y si lo compras, no lo dejes luego entre tu lista de lecturas pendientes, léelo cuando tengas un rato. Son solo unas 120 páginas que se leen casi del tirón y que seguramente encontrarás muy entretenido.

Te dejo en la imagen un enlace a Amazon España, pero puedes encontrarlo también en Amazon México y Amazon.com (aunque solo participará en la versión española de Kindle Flash).

antoniomartel.com
Publicado en Blog 1 | Deja un comentario

Empezar por lo más fácil significa acabar por lo más difícil

Lo hacíamos desde nuestra época de estudiantes. Teníamos un montón de cosas por repasar y deberes por hacer. Desde Dibujo a Matemáticas, pasando por Lengua o Sociales. Desde luego no empezábamos por los complejos ejercicios de Química que siempre nos resultaban tan difíciles. Cogíamos primero los sencillos problemas de la clase de Ética que siempre aprobábamos con nota.

Esto tenía un claro inconveniente: las horas pasaban muy rápido y con alegría dedicadas a hacer muy bien lo que nos gustaba y resultaba fácil, pero pronto se nos hacían las 9 de la noche. Ese era el momento de comenzar, ya sin fuerzas ni capacidad de concentración, con las páginas de la 298 a la 315 del libro de ejercicios de Matemáticas.

Procrastinábamos como hacemos ahora en el trabajo. Nos engañamos manteniéndonos ocupados haciendo las tareas más sencillas y de recompensa fácil. Pensamos que, de esa manera, nadie puede decirnos nada, estamos trabajando mucho.

Vamos postergando las tareas ingratas y con alta incertidumbre. Las sencillas las tenemos resueltas muy pronto. Que hay 10 pequeños errores que corregir, no hay problema, para mañana estarán resueltos todos. Que hay que lidiar con ese complejo problema que ya nos tuvo 3 días atascados con poco avance, quizás mejor la semana o el mes que viene, cuando tenga tiempo suficiente. El caso es que ese momento nunca llega y el cliente comienza a desesperar sin una resolución a su caso.

Si se trata de un proyecto en el que estamos trabajando, tardamos en abrir el melón de los asuntos serios, los que necesitan de análisis y revisión cuidadosos. Para el resto no hay problemas, comenzamos rápidos con ellos. Así entrenemos nuestro tiempo y nuestra conciencia. Después de todo estamos trabajando duro en el proyecto y sin tiempo que perder.

Para cuando ya no haya más remedio que atajar los problemas graves o las tareas complejas, ya se habrá consumido casi todo el tiempo del proyecto. Le habremos dicho además al manager que está finalizado al 90%. Al fin y al cabo, todas las tareas están resueltas (excepto esas dos o tres que estamos siempre evitando)

¿Y si vemos que en esas labores con alta incertidumbre había problemas escondidos? ¿Y si no podemos resolverlos? ¿Qué hacemos ahora con el presupuesto y el tiempo del proyecto consumidos?

Ataca los problemas desde el inicio. Nos producirá rechazo y nuestra mente tenderá a evitarlos. Tendremos que dar malas noticias y comunicar que nos enfrentamos a problemas. Tendremos que decir que solo llevamos un 10% del proyecto completado, cuando ya hace meses que comenzamos. Siempre será mejor esto que autoengañarnos, con avances irreales, comunicar un optimismo infundado, o lo que es peor, fracasar del 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.

This image has an empty alt attribute; its file name is unnamed1-1.png
Libro Gestión de proyectos: Agilidad en la práctica de la colección Manuales Imprescindibles de Anaya Multimedia

Referencias:

  • Quality Software Management: Systems Thinking de Gerald Weinberg.

Publicado en Blog 1 | Deja un comentario

No trabajes por trabajar

Evita las situaciones en las que te has quedado sin objetivos claros y no sabes qué hacer en el próximo sprint. Buscarás algo que darle al equipo para que no se quede parado, pero no se encuentra nada que hacer. Se ha terminado lo que han pedido y, por entretenerlos con algo, se deciden desarrollar funcionalidades que no se ha estudiado su viabilidad o su valor.

El resultado será código y funcionalidades que habrá que mantener, y mantenerlas tiene un coste, muchas veces oculto, pero un coste. Es el equivalente a los almacenes o estanterias llenas de stock de artículos que a nadie le interesan, ni secompran (son un desperdicio). Nos engañamos a nosotros mismos pensando que el trabajo que le damos tiene algún valor.

Podemos estar meses así, añadiendo funcionalidades al producto que no son más que un lastre o un coste adicional. Si a un producto le añadimos 40 000€ de coste, pero las ventas solo aumentan en 4 000€, solo habremos conseguido gastar diez euros por cada euro ganado.

Es mejor que dediquemos al equipos a investigar, a hacer spikes, a probar o crear MVPs. Con suerte encontraremos algo que aporte valor al cliente y que quiera comprar. Si el resultado de todas las propuestas que probaste no fue bueno, no apuestes tampoco por el MVP menos malo o por la idea que más te gusta a ti o más bonita te suena. La menos mala sigue siendo una mala idea.

Si no hay ideas o se han intentado todas las razonables, quizás sea el momento de abandonar tu producto, de apostar por otro. Si el equipo está unas semanas parado, investigando, o no haciendo nada productivo, probablemente sea mejor que desarrollando stock que vas a arrimar en una esquina de tus almacenes o repositorios virtuales.

No te cases con una idea solo porque es tuya o porque abandonarlo supone darte cuenta de que invertir ahí no fue buena idea. No te ciegues: todas las ideas no son grandes ideas. Busca otra, mejórala, mide y refínala, y quizás esta sí, sea la gran estrella de tu empresa. No dejes que un producto te deslumbre y te lleve a apostar todo por él, a hundirte con él.

No tienes por qué tener una sola bala para acertar en la diana, cuenta con varias opciones, con varios productos o varias funcionalidades. Tendrás más posibilidades de dar con la buena. ¿Prefieres contar con cinco flechas para acertar en la diana o tener un solo intento? Seguramente, a la tercera o cuarta flecha te hayas acercado más al blanco. Habrás aprendido lo que le gusta al cliente, lo que vende, lo que cuesta poco hacer, y tendrás ideas mucho más centradas en el mercado.

Publicado en Blog 1 | Deja un comentario

La clave de los proyectos que están completados al 90%, pero les falta aún el doble de tiempo para terminar

Seguro que lo ha vivido alguna vez: le preguntan por cómo va el proyecto que tiene entre manos y usted les indica que está al 90%, pero lleva diciéndoles esto tres meses ya. Mucho se teme que estará otros tres meses más señalando el fatídico 90%.

Los primeros avances fueron rápidos. Se paso del 10 al 30% y luego del 50 al 70% muy rápido. Pronto indicó usted que solo faltaba un 10% para completarlo, pero completar ese 10% le está llevando el 90% del tiempo, ¿por qué pasa esto?

Imagine que tiene diez tareas en el diagrama de Gantt. Una de ellas es la de cadena crítica, la que definirá la duración total del proyecto, el resto se pueden ir haciendo en paralelo y tardarán menos. Cuando tenemos las 9 tareas menores al 100% y la crítica solo al 50%, decimos que el proyecto está al 90%. Después de todo, la mayoría de tareas está terminada. Lamentablemente, la cruda realidad es que está solo al 50%. Solo cuando acabemos la cadena crítica acabaremos el proyecto.

Es esta tarea crítica la que en realidad nos define la duración del proyecto. Las otras son auxiliares y de menor importancia. Por esto nos ha llevado un año para llegar al 90%, que en realidad es solo el 50%, pero tardamos otro año completo cuando solo quedaba, supuestamente, el 10%.

Otro error habitual es el de comenzar las diez tareas al mismo tiempo al inicio del proyecto, aunque no sean especialmente importantes para el avance. Queremos marcar como terminadas cuantas más tareas mejor.

Por desgracias, si intentamos hacer esto, podemos perder el foco gestionando diez cosas a la vez, en lugar de enfocarnos en que la cadena o tarea críticas sean resueltas lo más pronto posible y sin obstáculos. Estas serán las que nos definan la duración del proyecto (y probablemente su coste final).

Publicado en Blog 1 | Deja un comentario

El tremendo coste de la indecisión

Existe una teoría, llamada Teoría de la Latencia de las Decisiones (Theory Decision Latency), que nos viene a decir que la duración del intervalo, o tiempo que tardamos en tomar una decisión, es más importante que la calidad de la decisión. Esta teoría presupone que, para el éxito de nuestro proyecto, más vale tomar decisiones de forma rápida aunque algunas puede que no sean las mejores posibles.

El Standish Group en su informe CHAOS Report de 2018 ha querido probar, midiendo en centenares de ejemplos reales, si esta hipótesis está fundamentada o no. Clasificó los proyectos entre los que tardaban 1 hora de media en tomar cada pequeña decisión del proyecto (baja latencia y equipos Highly Skilled), 2, 3, 4 y hasta 5 horas por decisión (alta latencia o equipos Poor Skilled).

Los investigadores del Standish Group pudieron comprobar que simplemente bajando el nivel de latencia, o el tiempo medio que se tarda en tomar decisiones, podía lograrse una mejora del 25% en el rendimiento del proyecto.

Aquí algunas de las cifras del informe:

Standish Group CHAOS Report 2018 y la teoría de la latencia de la decisión.
Standish Group CHAOS Report 2018 y la teoría de la latencia de la decisión
Cifras económicas del Standish Group CHAOS Report 2018 y la teoría de la latencia de la decisión.
Cifras económicas del Standish Group CHAOS Report 2018 y la teoría de la latencia de la decisión

Ahora ya tenemos datos que avalan esta teoría y confirman lo que ya intuíamos: dejar todo para después, que la decisión la tome otro, y la burocracia o el exceso de jerarquía, perjudican mucho más de lo que ayudan.

Todos conocemos esos proyectos en los que nada se mueve si no lo aprueba el consejero delegado de la empresa o un comité formado al efecto para tomar cada una de las decisiones (como en The Unicorn Project). Hay demasiado miedo a equivocarse y, si algo pasa, nadie quiere ser tomado como el reponsable de haber dicho: «Sí, adelante».

A veces, no es tanto cuestión de miedo o de cubrirse las espaldas, sino una mal entendida forma de «Hacer las cosas bien». Se quiere tomar siempre la mejor entre las mejores opciones disponibles, no importa si para encontrarla hay que invertir decenas de horas o cientos de euros (aunque la diferencia entre una opción y otra no implique sino un par de clics más en una escondida opción de pantalla).

Un Product Owner hábil que conozca bien el mercado y el producto puede ayudar mucho con esto. Si hay dudas, sabe a quién preguntar. En cambio, si lo conoce él, resuelve rápido. Si es una cuestión de diseño o estética, no va a lanzar la pregunta a todos los stakeholders, simplemente toma una decisión y continúa con su trabajo.

Estará accesible al equipo y cuenta con datos que le permitirán tomar decisiones. Si no tiene herramientas suficientes, planeará acciones que le permitan medir y tendrá siempre en cuenta el coste que tenga esa medición, pero también el coste de retrasar la decisión. Decide, prueba y mide ¿salió mal? Siempre será mejor que la parálisis por análisis. Por lo menos no habrá apostado todas sus cartas en este juego.


Referencias:

Publicado en Blog 1 | Deja un comentario

Si quieres ser productivo no hagas varias cosas a la vez

Hace unas semanas comentaba en el blog sobre el que llamaba el mayor asesino de la productividad: la multitarea. Si quieres ser efectivo o que lo sea tu equipo, no les pidas que hagas varias cosas al mismo tiempo, que dediquen un 50% a esto, y luego a lo otro. Solo conseguirás que tarden una eternidad en terminarlo todo.

La presión podrá contigo, te reclamarán cosas de aquí y allá y todo será importante, pero contente y tratar de terminar lo que tienes entre manos. No inicies otras 10 cosas para dejarlo todo abierto y a medio terminar.

Los cambios de contexto y de preparación entre una tarea y otra se comerán todo el tiempo disponible. Pero, incluso sin tener estos tiempos en cuenta, hay una forma clara de ver cómo te va a afectar si intentas la multitarea: con una imagen.

Imagina que tienes tres proyectos o tareas por hacer, las que tienes en la parte superior de la gráfica. Cada una dura 10 unidades de tiempo (10 días o semanas, por ejemplo). Si trabajas en ellas de forma secuencial, sin distracciones, comenzando una solo cuando está terminada la otra, terminarás en 30 días.

El cliente de la tarea A, que llegó primero, o al que se le atribuyó como cliente o tarea de máxima prioridad, se le terminará su trabajo en 10 días, igual que todos los demás. El tiempo medio para entregar los trabajos es de 10 días.

Imagina ahora que los intentas hacer todos a la vez. Comienzas con A y luego presiona B. Dejas lo que estás haciendo y comienzas con él. Pero más trabajos llegan y aparece C a la que también le dedicas su slice de tiempo.

El resultado es que ahora tardas 20 unidades de tiempo, el doble, en terminar cada una de ellas. Eso sin contar los tiempos de latencia, preparación de los trabajos y los cambios de contexto o el estrés del equipo. Merece la pena estar centrado en un solo trabajo a la vez, no?


Más sobre multitarea en mi blog:


Referencias:

  • Libro Cadena crítica de Eliyahu M. Goldratt.
Publicado en Blog 1 | Deja un comentario

5+5 = 13 y el problema con los márgenes de seguridad

Todos hemos aplicado alguna vez un margen a nuestras estimaciones. Son los conocidos «colchones» de seguridad. No queremos fallar y llevarnos una bronca, así que cuando nuestra jefa nos pregunta que cuánto podemos tardar en hacer algo, rápidamente le decímos que 5 semanas.

En realidad pensamos que con 2 o 3 semanas estaría resuelta, con suerte quizás solo en una, pero no queremos ver caras largas si fallamos. Después de todo, sabemos que las estimaciones siempre se equivocan.

El otro equipo también indica que tardará 5 semanas. Su jefe de proyecto ha añadido también un 100 o 200% de colchón.

Cuando nuestra responsable recoge ambas estimaciones, la suma le sale 10, pero añade otras 3 porque ella también sabe que las estimaciones se equivocan. Lo ha visto multitud de veces, ha puesto nuestras estimaciones, y siempre hemos tardado un 30% más (cuando menos).

Se ha acostumbrado a añadir también un margen de seguridad, pero a pesar de eso, está comprobando, que aún así, fallamos en cumplir los plazos de entrega ¿Cuánto más tiene que añadir de colchón? Está empezando a dudar. Está segura de que si hubiese añadido un 100% en lugar del 30%, también habríamos incumplido los plazos.

Una de las explicaciones para que esto suceda es el síndrome del estudiante, muy relacionadas con las Leyes de Parkinson. Como tenemos tiempo lo dejamos todo para el final. Nunca juzgamos el tiempo que nos queda como muy corto para comenzar. Como el mal estudiante, se nos queda toda la materia a estudiar para el día antes del examen.

Como cada equipo sabe que tiene margen, empieza tarde a trabajar en el proyecto por el síndrome del estudiante: «Total, tengo tiempo. ¿Para qué apresurarse?», parecemos pensar. Llegaremos al final apurado como siempre.

Nos habremos comido todo el colchón. Si pudimos haber entregado el trabajo en la semana dos, los habremos hecho en la cinco, impidiendo así que el otro equipo comenzase tres semanas antes y las ganase a la fecha de entrega.

Otra cosa que suele pasar, y aquí en donde entra la sabiduría de Cyril Northcote Parkinson, es que si algún equipo termina antes, no avisa, dedica el tiempo a hacer pequeñas mejoras, a pensar que se podía hacer mejor de otra manera. De nuevo pensamos «Qué más da! Tengo tiempo para darle otra vuelta!».

El resultado es que los adelantos no pasan a la siguiente fase, los avances se pierden. Siempre nos comemos todo el colchón. El proyecto irá al ritmo de la tarea que más atrasada vaya, adelantos posteriores o anteriores no adelantarán en nada al proyecto (los retrasos se acumulan, pero los avances no).

Pero siempre habrá una tarea crítica en el proyecto, aquella donde todo margen siempre es poco, donde el equipo está más ocupado o la dificultad y la incertidumbre la hacen más difícil y ajustada a plazos. El equipo encargado de ella es el que recibe todas las peticiones de ese tipo en la empresa. Están siempre trabajando al 120% y no paran de llegarles trabajos. No pueden con todos y terminan siempre saltando entre tarea y tarea.

La prioridad en esos equipos se decide según el jefe de departamento peticionario que más levante la voz en las reuniones con dirección o el que demuestre más mala leche. El namedropping es habitual en esas discusiones. Es aquí cuando entra en juego el mayor asesino de la productividad, la multitarea. Pero eso será tema de otro post.


Referencias:

  • Libro Cadena Crítica de Eliyahu M. Goldratt.

Publicado en Blog 1 | Deja un comentario