Saber abrir: lecciones de Emilio

He trabajado un tiempo con o para un jefe de proyecto de un cliente, llamémosle Emilio. Emilio no es un tipo de grandes aproximaciones metodológicas (es de los que piensa que las metodologías las escribió alguien que no estaba en el cliente), no toma muchas notas y tiende a intervenir por excepción en los procesos de trabajo. Es casi transparente, parece que no está… casi siempre. Sin embargo, si uno observa lo que hace y lo que no hace sólo puede aprender lecciones de veterano y de profesional de raza. Ya me lo habían dicho, gentes que trabajaron con él antes.

Emilio se concentra principalmente en los dos momentos que para mí son la clave de cualquier proyecto, los más complicados de gestionar bien y donde casi siempre nos jugamos el éxito del trabajo (si éxito quiere decir hacer razonablemente lo que tocaba, en calidad, en tiempo y en coste): saber abrir y saber cerrar el proyecto. Hablaremos hoy de las lecciones sobre “abrir” y otro día de las lecciones sobre “cerrar”.

Una de las cosas que más cuesta que entiendan los informáticos es que el proyecto comienza mucho antes y acaba un poco después de la producción de unos determinados entregables. Emilio intenta conocer lo mejor posible los procesos de negocio, las costumbres de trabajo y los equilibrios de poder de los clientes (internos) para los que trabaja y, si puede ser, anticiparse a sus necesidades. Intenta establecer una red de contactos y referentes, que le serán de ayuda en muchos momentos, y conocer lo que se cuece en el mercado, lo que están haciendo los fabricantes y proveedores de servicios y la competencia. Sabe que desarrollar, aumentar las capacidades y conocimientos de clientes y proveedores será una clave de los trabajos que vengan y una tranquilidad para su corazón grande.

Emilio sabe también que hay proyectos que no hacen falta, peticiones compulsivas de usuarios estresados, y cambios y vaivenes que se pueden evitar. Sabe también que la informática no puede resolver problemas que son de gestión o de cultura o de organización. Sabe que lo más caro no es lo más útil casi nunca y desconfía de los vendedores de ilusiones. De manera que lo primero que se pregunta e intenta trabajar con los clientes son cosas como: ¿Hay que hacer esto? ¿Hay que hacerlo así? ¿Hay que hacerlo ahora? Y lo hace con prudencia, con humildad, casi excesiva, en mi opinión.

Otra de las cosas que también complica la vida de los informáticos son las definiciones de alcance, o sea, lo que se hará y, sobre todo, lo que NO se hará dentro del proyecto. Lo que necesitamos saber para empezar un proyecto es qué queremos que el cliente (normalmente de un cierto nivel, el “amo” del proceso de negocio) pueda hacer con el sistema, lo que ahora no puede hacer o hace mal, y una estimación aproximada del tiempo y del esfuerzo requeridos para construirlo o implantarlo. No necesitamos una definición detallada de los requisitos de usuario final. Esto quiere decir análisis y reflexión, pero quiere decir también experiencia y capacidad para asumir riesgos. Para el cliente, su tiempo de proyecto (el lead time) va desde que pide algo hasta que se lo entregan, cosa que los departamentos de informática suelen medir poco.

Por lo tanto, Emilio consume también tiempo en la cocina, agilizando los contratos, buscando los recursos, trabajando el enfoque con los proveedores o, si es el caso, con los analistas que tendrán que desarrollar o implantar el producto. También trastea en la cocina de los interesados, alineando los intereses de las partes, confirmando el compromiso del sponsor, la dedicación de los equipos internos y la organización del trabajo. Emilio es un poco paranoide, lo son casi todos los jefes de proyecto de verdad, obsesionados con los riesgos, los peligros de fallar.

Finalmente, para Emilio es muy importante la reunión de lanzamiento, el kick-off, la prepara a conciencia y la negocia en los pasillos con unos y con otros. Coincidiría probablemente con una cita que me gusta de Snyder y Parth: “Cuando la gente entra en la reunión es parte de un grupo; cuando la gente sale de la reunión, es parte de un equipo. Esta es la mejor manera de empezar un proyecto”. Pero no pasa siempre, es difícil, también para Emilio.

Referencias:

Rodríguez JR, García Minguez J, Lamarca I (2007). Gestión de Proyectos Informáticos: Métodos, Herramientas y Casos (Editorial UOC).

Snyder C, Parth F (2007). Introduction to IT Project Management (Management Concepts).

5 Comments

  1. Yo quiero un jefe así……………me gustaría conocer a uno.

    Reply
    • Y yo, pero yo creo que no existen… Son como las modelos de los anunciones de la tele: están hechas con el Photoshop.

      Reply
    • Y yo, pero yo creo que no existen… Son como las modelos de los anunciones de la tele: que están hechas con el Photoshop.

      Reply
  2. Yo quiero un jefe así……………me gustaría conocer a un Emilio.

    Reply
  3. Emilio, o como se llame, existe! He trabajado con el. Y hay mas Emilios en este mundo, por fortuna. Es un tipo humilde y timido, que huye de los focos. Por eso no os lo puedo presentar…
    Gracias por vuestros comentarios.

    Reply

Trackbacks/Pingbacks

  1. Bitacoras.com - Información Bitacoras.com... Valora en Bitacoras.com: He trabajado un tiempo con o para un jefe de proyecto de un cliente,…
  2. ¿Necesitan los jefes de proyecto saber gestionar proyectos? | iNFoRMáTiCa++ - […] de grande es el problema? ¿Cuáles son sus consecuencias si no hacemos nada?”. Yo sugerí aquí otra pregunta igual…

Comentar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Leer entrada anterior
“El canon ahora lo paga hasta mi abuela”

En virtud del Real Decreto Ley 20/2011, de 31 de diciembre de 2011, el cual entró en vigor el día...

Cerrar