Archivos de Categoría: Blog

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.

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.

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).

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.

Referencias:

• Quality Software Management: Systems Thinking de Gerald Weinberg.

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.