Las cuatro leyes de la gestión de proyectos tecnológicos

Las cuatro leyes de la gestión de proyectos tecnológicos

Las cuatro leyes de la gestión de proyectos tecnológicos.

Estas cuatro sencillas reglas son la base de la gestión de proyectos tecnológicos.

Son solo 35 palabras, pero necesitarás algunos años para dominarlas y aplicarlas correctamente. Si deseas convertirte en un buen Jefe de Proyecto, serán tu credo. Apréndetelas de memoria y practícalas cada día.

1ª ley. Las especificaciones son inciertas, imprecisas e infinitas.

La primera ley es la responsable de que fracase el 80% de los grandes proyectos informáticos en todo el mundo. Esta cifra se mantiene estable desde los años 60 hasta hoy. Las nuevas herramientas de desarrollo y las diferentes metodologías no han conseguido mitigar este desastre.

Nos avisa de que el cliente no puede saber lo que quiere. Los sistemas informáticos son demasiado complejos. La especificación siempre estará incompleta. Por eso son inciertas.

Nos advierte de que no existe un lenguaje de alta precisión para comunicar las instrucciones técnicas. Los arquitectos disponen de los planos, un lenguaje de muy alta precisión. Los ingenieros informáticos sin embargo usamos el lenguaje natural, que es interpretable. Por eso son imprecisas.

Nos alerta de que un proyecto nunca termina. Siempre quedan errores que corregir y mejoras por implementar. ¿Alguna vez has puesto la última línea de código de un programa? Por eso son infinitos.

Cómo usar la primera ley:

  1. Especifica menos y haz más prototipos.
  2. Relaciónate más con tu cliente.
  3. No discutas el significado de un párrafo.
  4. ¡Haz que abone las facturas cuando todavía queda mucho por hacer!

2ª ley. One project, one team, one site.

Como el cliente no puede saber lo que quiere, y no disponemos de un lenguaje de alta precisión, las relaciones personales cobran especial relevancia.

La especificación se construye según avanzan los desarrollos, y los vínculos emocionales son la clave para distribuir ese conocimiento.

La segunda ley nos indica cómo construir esos vínculos. Los analistas funcionales, programadores, testers e incluso el cliente deben estar en la misma sala. Y mucho mejor si cada consultor trabaja en exclusiva para el proyecto.

Las software labs, las organizaciones matriciales y los equipos distribuidos son ineficientes.

Un apunte de Franz Hassmann, CTO de BBVA Next. Mejor si los equipos son pequeños, de entre 5 y 9 componentes.

3ª ley. Presión x Talento = Constante.

Durante miles de años hemos dirigido organizaciones gestionando la presión. Con el nacimiento de la informática necesitamos, por primera vez en la historia, gestionar el talento.

La tercera ley anticipa que si incrementas la presión de trabajo, disminuye el talento y los desarrollos se retrasan.

Así que olvídate de los bonus por objetivos y de exigir horas extras. Esas son herramientas de gestión de la presión.

Debes gestionar el talento. Ofréceles retos. Usa el feedback positivo. Bloquea la presión del cliente y deja que el equipo encuentre su ritmo de trabajo.

4ª ley. Alcance, Plazo y Calidad. Si fijas dos de ellas, la tercera se degrada porque es la variable de ajuste.

Recuerda, las especificaciones son infinitas.

Así que algo tienes que sacrificar. Puede elegir entre el alcance (entregar menos producto), el plazo (retrasar las entregas) o la calidad (entregar algo sin apenas pruebas).

La cuarta ley nos propone que alcance, plazo y calidad están interrelacionados. Si fijas dos de ellos, el tercero se degrada.

Nunca, nunca, nunca sacrifiques la calidad. Nunca fijes alcanzo y plazo.

SCRUM por ejemplo fija plazo y calidad, el alcance queda indeterminado. Se factura por cada sprint.

TIME & MATERIAL, los servicios profesionales de toda la vida, fijan alcance y calidad, y es el plazo el que queda indeterminado. Se factura mensualmente por el esfuerzo dedicado.

Si haces PROYECTOS CERRADOS, perderás dinero en el 80% de los contratos.

Enlaces de interés

Son solo cuatro reglas sencillas de aprender. Sin embargo, muchas organizaciones todavía preparan extensos documentos funcionales, deslocalizan parte de los equipos y trasladan la presión del cliente a sus desarrolladores.

Os dejo los enlaces a las fuentes de las cuatro leyes. Si comprendéis los fundamentos de cada una de ellas, os será más sencillo  adaptarlas a vuestra organización.

La primera ley tiene su origen en ‘The mythical man-month’ de Brooks. Quizás el primer libro sobre ingeniería del software. Escrito a finales de los sesenta y una referencia obligada a día de hoy. Se complementa con Introducción a la PNL’ de Seymour, un libro sobre psicología del lenguaje.

La segunda ley procede del fantástico libro ‘Peopleware’ de DeMarco. Posiblemente el primer ensayo sobre programación y productividad. Muy entretenido.

La tercera ley procede de un clásico sobre la motivación. ‘Drive’ de Daniel H. Pink. Igualmente divertido y ágil.

La cuarta ley procede tanto del libro de Brooks como de ‘Agile Software Requirements’ de Dean Leffingwell. No son fáciles ninguno de los dos, pero merece la pena el esfuerzo.

Te animo a compartir con todo nuestro sector tus experiencias en los proyectos en los que has participado. ¿Se han cumplido las cuatro leyes? ¿Añadirías alguna más?

¡Suerte en tu carrera de gestión de proyectos tecnológicos!


Los procedimientos transmiten cinco mensajes muy potentes que destruyen el talento

La burocracia destruye los equipos de alto rendimiento

La burocracia destruye los equipos de alto rendimiento.

Construir Vs destruir

La burocracia destruye los equipos de alto rendimiento.

Construir equipos de alto rendimiento (EAR) es una tarea compleja. Existen varias aproximaciones para que personas con diferentes intereses trabajen con confianza y consigan resultados sobresalientes.  Pero ninguno de estos métodos garantiza el éxito.

Sin embargo, destruir equipos de alto rendimiento es una tarea sencilla que las empresas suelen dominar. Existen al menos diez efectivos EARicidas. Y la burocracia es uno de los más poderosos.

Desde la primera edición de Peopleware, en el año 1.987, sabemos cómo la burocracia afecta a los grupos de desarrollo. Os recomendamos leer el capítulo Teamicide, que describe los efectos de dedicar tu tiempo a empujar papeles.

Un procedimiento tiene cinco significados

Con cada procedimiento la empresa nos transmite cinco mensajes:

  1. Una vez pasó algo, que tuvo un impacto negativo en la empresa, y no queremos que se repita.
  2. Los más listos de la empresa, es decir, la dirección, hemos ideado este procedimiento. Es definitivamente la mejor forma de hacer las cosas.
  3. No te pagamos para pensar, te pagamos para que trabajes. Sigue el procedimiento.
  4. No confiamos en ti.
  5. Porque no tienes talento.

Algunos ejemplos de Burocracia en acción

Estos son algunos casos que he conocido de primera mano.

Hace unos años, un consultor se quedó con el equipo informático cuando cambió de trabajo. Ahora todos los consultores deben firmar un recibí cada vez que les entregamos material. Una vez pasó algo y no queremos que se repita.

Antonio necesitaba pagar con tarjeta de crédito un servicio web de 50 € al año. Su empresa le explicó el procedimiento. Debía tramitar un pedido a través de la plataforma de compras, pedir tres ofertas  y los pagos se hacen a noventa días mediante transferencia. Ya hemos pensado la mejor forma de hacer esto. (Por supuesto lo pagamos nosotros y resolvimos el problema en diez minutos).

Carlos necesitaba una mochila para transportar su ordenador portátil. La bandolera que le había proporcionado su empresa le hacía daño en la espalda. Prepararon un procedimiento ad-hoc para su caso, debía aportar un justificante médico. No confiamos en ti.

Pablo necesitaba urgentemente un entorno de pruebas, pero había un procedimiento: Debía solicitar a la central de Alemania una máquina virtual con una configuración estándar. No podía instalar nuevo software ni hacer pruebas para optimizar el rendimiento. No te pagamos para que pienses.

Jorge tenía problemas para avanzar con el desarrollo. Las especificaciones eran imprecisas y algunas sentencias SQL no tenían sentido. Solo necesitaba hablar unos minutos con el cliente, pero había un procedimiento: El Solutions Architect trasladaba la consulta al Account Manager, y el Business Analyst se reunía con el cliente. Tu no tienes talento.

La burocracia incumple la tercera ley

Hemos hablado en varias ocasiones de las cuatro leyes, esas 35 palabras que guardan casi todo lo que debes saber para gestionar proyectos informáticos.

La tercera ley dice Presión x Talento = Constante. Es decir, debes elegir entre maximizar la presión o maximizar el talento.

Mientras en buena parte de las actividades empresariales es conveniente gestionar la presión, en el ámbito de la tecnología necesitas maximizar el talento.

Y la burocracia, ¿mejora la presión o mejora el talento? Si has leído con atención hasta aquí, la respuesta es sencilla.  La burocracia genera una carga de trabajo innecesaria (presión) porque asume que no tienes talento. La burocracia es por tanto similar a los bonus por objetivos o a los incrementos de jornada laboral. Formas de presión que destruyen el talento.

Las Buenas Prácticas

Sin embargo, no es económicamente viable reinventar la rueda cada vez que realizamos una actividad. Es necesario un mecanismo que busque la eficiencia pero que se apoye en el talento de los profesionales. Y la respuesta son las Buenas Prácticas.

Las Buenas Prácticas tienen el siguiente enunciado: ‘Ésta forma de hacer las cosas se ha demostrado que funciona y recomendamos su uso. Eres libre de buscar formas más eficientes de hacer el trabajo porque no eres tonto y confiamos en tu talento. Junto con nuestra confianza te damos el derecho a equivocarte de vez en cuando y la obligación de trasladar tu conocimiento al resto de la organización‘.

Este enfoque persigue el mismo objetivo que los procedimientos, realizar el trabajo de forma homogénea y eficiente. Sin embargo refuerza la tercera ley porque se apoya en el Talento de los consultores.

Las fuentes

Si te interesa el tema, te aconsejo acudir a las fuentes. Además del mencionado Peopleware, te recomendamos ‘El japonés que estrelló un tren para ganar tiempo’ de Gabriel Ginebra y ‘Rework’ de Jason Fried.

Si quieres ayudar a la comunidad IT, puedes comentar algunos de los procedimientos de tu empresa y cómo te afectan en tu trabajo.