Cinco formas en que la burocracia destruye Equipos de Alto Rendimiento

Desde la primera edición de Peopleware, en el año 1.987, sabemos que la burocracia es una de las causas de destrucción de Equipos de Alto Rendimiento. Es de obligada lectura el capítulo Teamicide, que describe los efectos de dedicar una parte de tu tiempo a empujar papeles. En este post vamos a ir un paso más allá y vamos a analizar las causas de este fenómeno.

Nuestro argumento es que, si solo existen cuatro leyes para la gestión de proyectos IT, los procedimientos empresariales tienen que entrar en conflicto con alguna de ellas. Voy a apoyarme para el estudio en cinco casos representativos que he vivido en primera persona como coordinador de Novanotio.

Caso 1. Carlos solicitó una mochila para su ordenador portátil porque la bandolera que le había proporcionado su empresa le hacía daño en la espalda, entonces le explicaron el procedimiento: Debía aportar un justificante médico de su problema de espalda a la dirección de RRHH. En resumen, no confiamos en ti.

Caso 2. Nico necesitaba crear un entorno de pruebas y nuestro cliente le explicó el procedimiento: Debía solicitar una máquina virtual a la central de Alemania, que se encargaba de su conectividad, configuración y mantenimiento. No podía desplegar el entorno según las necesidades del nuevo proyecto ni hacer pruebas para optimizar el rendimiento, debía usar la configuración estándar. En resumen, no te pagamos para que pienses.

Caso 3. Isaac necesitaba pagar mediante tarjeta de crédito un servicio web de 50 € al año y su empresa le indicó el procedimiento: Debía tramitar un pedido a través de la plataforma de compras y, por cierto, los pagos se hacían exclusivamente por transferencia. En resumen, la dirección ya ha pensado en cómo hacer esto.

Caso 4. Jorge tenía problemas para avanzar con el desarrollo. Las especificaciones eran imprecisas y algunas sentencias SQL no tenían sentido. Podía resolver sus dudas hablando unos minutos con el cliente, pero había un procedimiento: El Solutions Architect, que era quien conocía el sistema, pasaba la consulta al Account Manager, que era quien conocía al cliente, y organizaban una reunión junto con el Business Analyst, que era quien conocía el problema. En resumen, eres tonto.

Caso 5. Éste nos afecta en primera persona. Hace unos años, un consultor de Novanotio se llevó el equipo informático cuando cambió de trabajo, así que ahora nuestros consultores deben firmar un recibí cada vez que les entregamos material. En resumen, una vez pasó algo y no queremos que se repita.

En definitiva, un procedimiento significa cinco cosas: Para que no se repitan ciertos hechos (1), desde la dirección hemos creado un procedimiento que es la mejor forma de hacer las cosas (2). Ahora estamos tranquilos porque puedes hacer tu trabajo sin necesidad de pensar (3). No confiamos en ti (4) porque eres tonto (5).

Si recordamos las cuatro leyes:

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

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

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

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

Vemos que los procedimientos entran en conflicto con la tercera ley; no confiamos en ti porque no tienes Talento.

No es viable reinventar la rueda cada vez que realizamos una actividad, así que 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, y sin embargo refuerza la tercera ley, ya que se apoya en el Talento de los consultores.

Si te interesa el tema, te aconsejo acudir a las fuentes, en este caso ‘El japonés que estrelló el tren para ganar tiempo’ de Gabriel Ginebra, ‘Rework’ de Jason Fried y ‘Scaling lean & agile development’ de Craig Larman. También es interesante cualquier libro sobre el modelo Toyota.

Si quieres ayudar a la comunidad IT, comenta por favor algunos de los procedimientos de tu empresa y como te han afectado en tu trabajo.


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

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

Tan solo cuatro leyes gobiernan la gestión de los proyectos tecnológicos:

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

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

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

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

La primera ley asume que no disponemos de una herramienta para transmitir las instrucciones técnicas. La comunicación se hace mediante sucesivas iteraciones soportadas en relaciones personales. Corolario: Especifica menos y relaciónate más.

La segunda ley nos indica cómo fomentar las relaciones personales; los equipos de diseño, desarrollo, pruebas, integración y delivery están en una única oficina y cada consultor trabaja para un único proyecto. Las software labs y las organizaciones matriciales son ineficientes.

La tercera ley anticipa que si incrementas la presión de trabajo, obtienes menos producto. El desarrollo tecnológico es más inspiración que transpiración. Deja que el equipo encuentre su ritmo y gestiona las expectativas del cliente.

La cuarta ley nos propone cómo gestionar las expectativas del cliente. Dado que las especificaciones son infinitas, uno de los tres parámetros debe degradarse y lo habitual es fijar Alcance y Plazo, degradando la Calidad. La propuesta de SCRUM es fijar Plazo y Calidad mientras el Alcance se determina con el cliente en sucesivas iteraciones. La propuesta de TIME & MATERIAL es fijar Alcance y Calidad, sin plazo cerrado y facturando por el tiempo dedicado.

Son pocas y son fáciles, y sin embargo buena parte de las organizaciones, como consecuencia de la herencia cultural de la ingeniería industrial, trabajan contra ellas preparando extensos documentos funcionales, deslocalizando parte de los equipos, trasladando la presión del cliente a los desarrolladores y fijando en los contratos alcance y plazo de entrega.

Quizás la magia no está en conocer las cuatro reglas, están ahí a disposición de cualquier gestor que quiera aplicarlas. Lo difícil es comprender la psicología que hay detrás de cada una de ellas, de forma que puedas adaptarlas a tu organización. Las referencias básicas son ‘Introducción a la PNL’ de Seymour,The mythical man-month’ de Brooks, ‘Peopleware’ de DeMarco y ‘Drive’ de Pink.

Por eso cuando hay retrasos en los proyectos, se forman silos dentro de las organizaciones o los resultados se evaporan sin razón aparente, algunas empresas contratan un análisis estratégico y otras invitan a su coordinador de Novanotio a tomar un café y le preguntan la forma más sencilla de aplicar las cuatro reglas a su caso particular.

Si quieres ayudar al desarrollo del sector, puedes compartir experiencias sobre proyectos en los que se trabajó a favor o en contra de las cuatro leyes. También puedes proponer nuevas leyes y abrir un debate sobre por qué son necesarias y por qué tienen un carácter universal.