El IT Management es una de las cosas más desafiantes por las cuales he pasado en esta vida. Luego de duros choques contra paredes me he dado cuenta que hay simples hechos a los cuales hay que prestarles atención para evitar catástrofes de entregas, relación con el cliente, relación con tu equipo y simplemente no tener un nivel de stress desgastante.

Es posible que algunas cosas que lean les pueden parecer básicas, pero me he encontrado con innumerables casos en donde había desconocimiento de esta docena de aspectos.

1. Inicio del Proyecto

El inicio del proyecto es una instancia tan clave como bastardeada. Dentro de la metodología Agile se suele hacer una reunión estéril en donde se presentan a los integrantes del equipo, el rol que tienen, un poco su experiencia, presentar la metodología, setear expectativas y con un poco de suerte armar un plan de comunicación que se ejecutará durante el proyecto.

Todo lo anterior muy bien, pero ¿qué tal si el inicio del proyecto es la instancia en donde el cliente tiene que especificar cual es el valor de negocio que quieren conseguir con ese desarrollo, cuál es el win que quieren obtener haciendo esa inversión y qué software/proceso/manejo están dejando de lado?
Este simple mensaje logra que el equipo (y nosotros mismos) entendamos por qué vamos a hacer el esfuerzo que vamos a hacer y que en el momento de dudas, recurramos a nuestra memoria para entender qué necesita el negocio.

Por eso, antes del inicio del proyecto, es conveniente hablar con el cliente y que el mismo cliente entienda que tiene que dar este mensaje.

2. Conocer el valor de negocio que vas a agregar en tu próxima entrega

Estar atrás de una fecha como loco, perseguir un deadline y perderse en el día a día, logra solamente que le pases stress a tu equipo. Como Manager, debemos estar por encima de eso, ver cuál es el valor que estamos agregando en la entrega; y haciendo esto, nos vamos a sorprender que de toda una serie de iteraciones, hay iteraciones que son cruciales y otras no tanto.

Entender ese concepto a la hora de armar el plan para ejecutar la iteración es importante, ya que sabés perfectamente dónde debe estar el foco y qué cosas podrían ser postergables en el caso que ocurran bloqueantes no previstos.

3. Saber qué hiciste y qué te falta hacer para tu próxima entrega/entrega final

Increíblemente me he topado con Project Managers que ante la simple pregunta de “¿Llega el equipo?” no saben contestar con hechos. Saber qué se hizo y qué falta es lo único que nos va a dar el impulso que necesitamos para gestar cambios a tiempo.

Hoy en día hay miles de herramientas de manejo de proyectos que nos ayudan con lo que es el tracking del mismo, como por ejemplo Rally, Jira, Pivotal Tracker, Trac o hasta un mismo Excel.

Entender cuanto te falta (con su esfuerzo asociado) es lo único que te indica si estás bien posicionado para la fecha de entrega. El trazo de esto debe ser diario y ante el más mínimo desvío debes actuar buscando acciones y alternativas para ponerte de nuevo en línea con la fecha de entrega.

Comunicar esto al equipo es casi tan valioso como saberlo tú mismo. El equipo a quien lideras debe conocer si está haciendo las cosas bien, mal, regular o si se le viene una tarde negra en donde tiene que pensar acciones de recuperación. Comunicar es bueno, que todos sepan lo que tú sabes.

4. Escalando los problemas

Infinidad de veces tenemos bloqueantes que impiden que nosotros desarrollemos por cuestiones del cliente. Lo que termina pasando es que nosotros no sabemos pedir ayuda y terminamos siendo culpables del bloqueante que el mismo cliente generó.
Yo a mis equipos siempre se los transmito de la siguiente forma:
El Project Manager le dice al cliente “Tengo Hambre”. Se lo dice una, dos, tres, mil veces hasta que un desarrollador se muere de inanición y eso impide que podamos completar el entregable.

Una forma más efectiva de comunicarle al cliente el problema sería: “El equipo tiene hambre, si tú (nombre de una persona) no le traes cuatro cajas de pizzas a las 14:00 hs del miércoles, uno de los desarrolladores morirá de inanición y eso va a estar retrasando la entrega o afectando el alcance de la siguiente manera …”

El hecho de poner un dueño al problema, una fecha y una consecuencia es clave para que todos entendamos de qué estamos hablando.

5. Involucrar a todos los interesados de manera activa

Hay una mala costumbre que cuando el cliente se desentiende del proyecto, nosotros tomamos su rol y lo peor, es que empezamos a tomar decisiones por ellos, llegando a un resultado que puede ser nefasto.

Nos topamos con situaciones en donde el cliente te dice que no tiene tiempo para revisar lo que tú tienes que hacer. ¡Y si no es el cliente quién lo va a revisar! Como Manager, debemos involucrar y exigir al cliente que participe y de la creación del producto que ¡ellos necesitan!

Si la persona que nos ponen para “ayudarnos” no lo hace, no lo dudemos, busquemos otra. Veo muchos Project Managers con temor de plantear este tipo de cosas cuando en realidad es lo esperable, que nosotros tengamos control de lo que estamos haciendo y si hay algo que no funciona, no importa qué, lo pongamos en curso.

6. Todos los interesados (cliente / equipo) deben entender la metodología de desarrollo

Aclarar la metodología de trabajo a todos los integrantes del equipo es fundamental. El proceso debe estar documentado y al alcance de todos. Deben haber sesiones cerca del kick off inclusive con capacitaciones si no es conocido por todos.

Debemos también pedir que la metodología sea desafiada con nuevas propuestas para que pueda mejorar. No permitamos que la metodología, aún cuando la sentimos imperfecta arrastre a todo el equipo y al producto a la deriva. Proponer mejoras y aún más, ejecutarlas te hacen mejor.

7. Medios de comunicación entre cliente/equipo

La comunicación. Siempre que entrevisto Project Managers me detengo en el tema de comunicación y la verdad es que se hace pésimo. Con las tecnologías que hay hoy en día no comunicar bien es directamente porque no sabes cómo hacerlo.

Es común hoy en día tener equipos en distintas locaciones y lo que es mejor, en distintos husos horarios y para complicarla más, podemos tener distintos idiomas nativos en un equipo.

Lo mejor sin lugar a dudas es la comunicación cara a cara, pero como las condiciones de presupuesto pueden evitarlo, para mi la mejor opción es video conferencia. Hay herramientas que permiten hacerlo de manera muy natural (sin ir a costosos equipos Polycom o Teleconference) como Skype, Hangout (Google), Webex o GoToMeeting. Presupuesto de nuestro proyecto tiene que estar destinado en comunicaciones, si necesitamos comprar licencias, ¡hazlo! Una mala comunicación agrega riesgo al proyecto.

8. Seniority del equipo – Regla del 10%

Este ítem es clave y se refiere al armado del equipo. No puedes tener un proyecto exitoso si no tienes un 10% del equipo que sea Clase A. Me refiero a Clase A cuando tienes un integrante que no sólo tiene un gran conocimiento tecnológico o de negocio sino que aparte está dispuesto a darlo todo para que el proyecto sea un éxito.

Muchos Managers se apuran por conseguir el equipo y lo completan con gente “que está disponible” sin revisar si realmente aplican para lo que se necesita. El precio que terminan pagando es altísimo. Entregas demoradas, mal humor en el equipo, rotación y poca predisposición para trabajar ahí.

Sin ese 10% es realmente un milagro que un proyecto salga bien y no sólo eso, sino que cuando vemos que hay integrantes que no sólo que no están aportando a la causa, sino que están restando, debemos sacarlos aunque sea un momento que nadie quiere atravesar. El equipo es la materia prima del proyecto, si eso está mal, el proyecto, consecuentemente, sale mal.

9. Reporte hacia el cliente

Decirle al cliente qué pasa es una de las tareas que más complejidad tiene. Me vi rodeado de gente que solamente cumple con el formalismo de poner riesgos/bloqueos, qué se hizo, qué se va a hacer y con suerte, cómo está conformado el equipo.

No es suficiente. El reporte, debe ser conciso, siempre enviamos reportes a Managers del lado del cliente que no están dispuestos a leer informes largos o que no tengan de un vistazo general qué es lo que pasa.

Yo utilizo una serie de prácticas que quiero compartir, que obviamente dependen del cliente, pero que a mi, en su gran mayoría me dan resultado.

  • El correo en donde se manda el reporte, debe tener un dashboard que llame la atención. Utilicemos colores de semáforos para los indicadores (Presupuesto / Equipo / Entrega / Riesgos o Bloqueantes / los que tú quieras). En el caso que exista algún amarillo o rojo debes mencionar el porqué y qué vas a hacer para remediarlo.
  • Si hay riesgos o bloqueos severos, no mandemos el reporte y esperemos a que el cliente lo solucione, inmediatamente después de mandar el reporte debemos comunicarnos con el cliente y pedir debatir para ver cómo solucionar los bloqueantes.
  • Midan todo lo que puedan. Los números hablan por sí mismos y siempre son una gran herramienta para la mejora contínua. Mostrar métricas a los clientes de nuestra performance como evolución, directamente genera confianza, y si tenemos malos números, muestrenlos igual y pongamos que vamos a hacer para mejorarlos.
  • Siempre hagan una reunión de seguimiento en donde se toma como entrada el reporte semanal, y fuera de revisarlo, vean si quedaron cosas pendientes del reporte anterior.
  • El formato del reporte y de la revisión, tiene que ser coordinado con el cliente. No todos los clientes entienden lo mismo ni todos los proyectos brindan la misma información. Modifiquemos el template para que tengamos valor en la información.
  • Esto puede ser naif, pero el reporte, debe ser lindo. Si tú le estás vendiendo UX o UI al cliente y le das un PDF que es feo, no demuestra lo que vendes.

10. Los equipos siguen los ejemplos

Este punto es tan simple como efectivo. Si nosotros como Managers pretendemos que el equipo dé su milla extra, tenemos que darla nosotros primero. Si nosotros cumplimos la regla del 10% con gente de buen seniority, el equipo lo va a seguir. Va a tener sed de aprender y va a nutrirse de los conocimientos de la gente más experta.

El esfuerzo que nosotros ponemos, ya sea quedándonos a altas horas mientras el equipo desarrolla, siempre es tomado bien. Jamás deberíamos irnos antes que el último integrante del equipo (sobre todo, en momentos de crisis).

11. Contención

La gente IT requiere contención y es importante que se haga. Contención implica ver qué quiere hacer cada persona con su carrera, escucharla, ver cuales son las mejores aptitudes de esa personas y buscar el lugar para explotarlas.

Contención también es reconocer el buen trabajo hecho, no sólo monetariamente sino poniendo de ejemplo a esa persona/equipo adelante del resto de la compañía para que no se sientan simplemente un número de legajo.

Contención es generar sinergia en los equipos y que esa sinergia exista aún fuera de la oficina, llevándolos a tomar una caña o tener momentos hablando de sus vidas personales.

Contención también es dar espacio a la gente para que tenga su vida, sus problemas personales y sus dificultades. Trabajamos con seres humanos que tienen problemas y que algunos son realmente complejos.

12. Los proyectos se entregan, no se terminan

Si un Manager entiende que su trabajo es en donde dice el contrato, de principio a fin, está equivocado. El Manager debe involucrarse en las raíces del cliente, entender el negocio y lograr que el proyecto en el cual primero se involucró, sea sólo el comienzo de la relación y que luego el cliente vea que somos de fiar y nos de más y más iniciativas de trabajo.

Ganar la confianza del cliente haciendo buenas entregas y mostrándole que somos capaces de maniobrar ante los problemas, pero que siempre tenemos en mente su negocio, hará que ese cliente no nos quiera dejar y quiera seguir trabajando con nosotros.

Crear esa relación es un arte, pero es consecuencia casi inmediata de seguir los 11 puntos anteriores.



El management es complejo porque está hecho por personas y consiste en “administrar” personas. Y las personas tienen su historia, su cultura, su idioma, su experiencia, sus vicios asociados, sus valores y sus propios intereses, con lo cual, encontrar la media en todas esas cosas y hacer que la maquinaria funcione es todo un desafío.



Imagen destacada cortesía de darkmatter via photopin cc


Unadocenade también está en Google Currents. Suscríbete.
Los post de Unadocenade se pueden republicar siempre que respetes nuestras condiciones de republicación.

Sobre Diego Varela


IT Program Manager hace algunos años y trabaja en operaciones hace tantos otros. Hice cualquier cosa en el mundo IT, desde programar, testear, administrar bases de datos, administrar servidores y analizar requerimientos por más de 18+ años. Argentino en muy buena ley, aunque he vivido por acá y allá. Los recepcionistas de los hoteles ya me reconocen de la frecuencias que tienen mis viajes.