Los cinco significados de un procedimiento

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.

2017-10-02T10:50:27+00:00 2 octubre 2017 |Categorías: Noticias|Sin comentarios

Deje su comentario