---

En Blue, pasamos mucho tiempo pensando en la gestión de proyectos. Es fundamental para lo que hacemos y el éxito de lo que entregamos a nuestros clientes. Sin una comprensión sólida de la gestión de proyectos, ¿cómo podríamos construir software de gestión de proyectos?

Cada vez que comenzamos un nuevo proyecto, ya sea una nueva función, una actualización de ingeniería de backend, una campaña de marketing o una iniciativa de reclutamiento, comenzamos analizando el proyecto en sí y cómo se está gestionando. Así que, con una gran cantidad de experiencia y conocimientos, hemos decidido comenzar a formalizar algunos primeros principios de gestión de proyectos.

Aunque es común (y aceptable) navegar un proyecto utilizando una sensación más informal y personal, difícilmente es un enfoque escalable — y no está exento de inconvenientes.

Un Proyecto

Comencemos definiendo un proyecto.

Un proyecto es un esfuerzo temporal con un inicio y un final definidos para producir un producto, servicio o resultado único. Así es como la mayoría de las personas piensan en los proyectos. Pero también hay algunas otras propiedades más formales de los proyectos que son importantes considerar:

• Un proyecto tiene recursos finitos (tiempo, dinero, personas);
• Un proyecto se lleva a cabo para lograr objetivos específicos;
• Un proyecto tiene un alcance definido (por lo que hay claramente cosas que no hará);
• Un proyecto está sujeto a incertidumbre y riesgos.

Ahora que tenemos una mejor comprensión de lo que es un proyecto, podemos pasar a los primeros principios — los bloques de construcción fundamentales que un proyecto necesita para tener éxito. Estos incluyen:

• Un gerente de proyecto;
• Un objetivo;
• Una lista de cosas por hacer — esto a menudo se llama un plan;
• Alguien asignado para hacer cada cosa;
• Cronogramas para cada cosa;
• Una estrategia de comunicación con una cadencia regular de actualizaciones y reuniones, y un plan para dónde se almacenará la información.

Hemos encontrado que estas cosas suelen aplicarse a todos los proyectos y, si se hacen bien, eliminan el 99% de todos los problemas dentro de los proyectos.

Un Gerente de Proyecto

Lo primero que necesita un proyecto es alguien a cargo de completarlo con éxito. Esto puede parecer una afirmación obvia, pero vale la pena enfatizarlo.

Esta persona es el gerente de proyecto. Es responsable de garantizar que se cumplan los objetivos del proyecto y que se complete a tiempo, dentro del presupuesto y con los estándares de calidad requeridos. A menudo, muchos de nosotros nos convertimos en gerentes de proyecto de facto sin ser gerentes de proyecto capacitados. Si ese eres tú, entonces tienes suerte, escribimos una guía para eso!

Vale la pena considerar lo que un gerente de proyecto debería y no debería hacer. Después de todo, tienen mucha responsabilidad, y deben tomarse esta responsabilidad en serio.

A menudo, la gestión de proyectos puede llevar una parte significativa del presupuesto de un proyecto — típicamente entre el 2% y el 10% de él, dependiendo de cuán arriesgado sea el proyecto. Cuanto más riesgo, más gestión de proyectos se requiere para garantizar que las cosas se mantengan en el camino correcto y el proyecto no falle.

Debido a que son un gerente, el gerente de proyecto debe centrarse en cómo lograr objetivos a través de otras personas. Necesitan asegurarse de que el equipo del proyecto sea efectivo y que trabajen juntos de manera armoniosa hacia el objetivo común. El gerente de proyecto es quien necesita asegurarse de que todos estén haciendo su trabajo y que lo estén haciendo bien.

El gerente de proyecto también es responsable de comunicarse con los interesados del proyecto y mantenerlos actualizados sobre su progreso.

Al igual que discutimos en Priorización para Líderes, los gerentes de proyecto deben estar constantemente enfocados en el punto de restricción. Si obtener la aprobación de los interesados para algo toma demasiado tiempo, entonces necesitan concentrarse intensamente en obtener ese compromiso. Deben preguntarse constantemente: “¿Qué nos está deteniendo para completar los objetivos del proyecto y cómo puedo desbloquear el problema lo más rápido posible?”

En cierto modo, la gestión de proyectos es sinónimo de comunicación. Escribir ideas detalladas es una habilidad valiosa para un gerente de proyecto, ya que reduce drásticamente el número de reuniones requeridas — los miembros del equipo pueden autoabastecerse de la información necesaria.

Un Objetivo

Otro bloque de construcción fundamental de un proyecto es que necesita un objetivo claro y medible. Una vez que el proyecto ha terminado, debería ser trivial mirar los resultados y saber si el proyecto logró sus objetivos o fracasó.

Los objetivos deben publicarse para que cada miembro del equipo tenga acceso a ellos. Esto es importante porque significa que la toma de decisiones puede ser distribuida y descentralizada, ya que cada miembro del equipo puede mirar su pequeña parte del trabajo y vincularla a los objetivos generales del proyecto. Luego, pueden plantear problemas si hay un desajuste o cambiar su enfoque en su pequeña área del proyecto para servir mejor a los objetivos más grandes.

Los objetivos de un proyecto deben ser SMART:

• Específico. Los proyectos a menudo tienen objetivos de alto nivel que suenan más como declaraciones de misión o visión. Un ejemplo de un mal objetivo es “mejorar el soporte al cliente”. Esto no es lo suficientemente específico. Algo como “Nuestro objetivo es responder el 90% de los clientes dentro de los 30 minutos para el final del Q4” es mucho más específico.
• Medible. Cuando estableces objetivos específicos, generalmente resuelves el problema de medición simultáneamente porque es fácil evaluar si se ha alcanzado el objetivo.
• Alcanzable. Los objetivos solo tienen sentido si se pueden alcanzar. Pero esto no es una excusa para crear objetivos fáciles. Un buen objetivo debe tener un elemento de desafío — lo suficientemente desafiante como para poder alcanzarse, pero no imposible o muy poco probable.
• Relevante. Esto puede sonar muy evidente, pero te sorprenderá cuán a menudo sucede. Los objetivos del proyecto deben poder alcanzarse haciendo el proyecto. No puedes establecer objetivos que no puedan ser controlados por el equipo del proyecto que está realizando el trabajo específico del proyecto. Por ejemplo, los equipos que trabajan en la división de fabricación de una corporación pueden no influir en la experiencia de compra en la tienda de los clientes.
• Limitado en el tiempo. Los buenos objetivos necesitan tener algún tipo de tiempo adjunto a ellos. Esto puede ser difícil, especialmente con proyectos de software modernos donde el trabajo a realizar no siempre está claro, por lo que los cronogramas pueden ser extremadamente difíciles de estimar. A veces puedes estar equivocado por múltiplos, y no es culpa específica de nadie. Dicho esto, tener cronogramas asegura que el alcance general del proyecto se mantenga dentro de ciertos límites. Si tienes un mes para resolver un problema frente a un año, llegarás a soluciones muy diferentes.

Los objetivos deben repetirse a todos los miembros del equipo ad nauseam: deberían estar (figurativamente) enfermos de que el gerente de proyecto discuta constantemente los objetivos. Algunos tableros en tiempo real (o tan cerca del tiempo real como sea posible) que rastreen el progreso también pueden ser invaluables para asegurar que todos estén alineados hacia los objetivos y sepan cómo se está desarrollando el proyecto.

Una Lista de Cosas por Hacer

Sugerimos encarecidamente llamar a un plan “una lista de cosas por hacer” en su lugar, porque desmitifica el proceso de planificación.

Los planes son a menudo conjeturas, pero aún así son valiosos. Esto se debe a que el proceso de planificación en sí ayuda a arrojar luz sobre lo que sabemos y lo que aún no sabemos.

No planear es planear para fracasar.

La esencia de un plan es obtener una lista detallada de todos los pasos para ir desde el inicio del proyecto hasta su finalización exitosa. Algunas acciones requerirán que se completen pasos previos, por lo que podrías terminar con una serie de tareas vinculadas, a menudo llamadas dependencias. Otras acciones se pueden realizar en paralelo y no se bloquean entre sí.

El gerente de proyecto siempre debe centrarse en las acciones más importantes que están bloqueando otras acciones, ya que esto define lo que se conoce como el camino crítico del proyecto. Es decir, la cantidad mínima de tiempo en la que el proyecto puede completarse si todas las dependencias están alineadas de extremo a extremo.

Trabajar en el plan desde ambos extremos del proyecto puede ayudar enormemente a construir un plan efectivo. Esto significa que comienzas desde el principio y vas hasta el final, pero luego también comienzas desde el final y retrocedes para entender qué se requiere para terminar el proyecto y alcanzar los objetivos.

Esta última parte de invertir el proceso de planificación generalmente descubrirá tareas pasadas por alto.

Pero, el proceso de planificación no está completo hasta que entendamos quién es responsable de cada tarea y cuánto tiempo tomará completar cada tarea.

Estos puntos deben abordarse simultáneamente porque están tan estrechamente vinculados. No puedes crear estimaciones para el trabajo sin involucrar a los expertos que conocen los detalles de esas tareas, y aun así, debes mantener un ojo en tus recursos. Un individuo rara vez puede trabajar de manera efectiva en múltiples cosas al mismo tiempo, por lo que necesitas entender si el plan del proyecto es probable que tenga cuellos de botella. Aquí es donde una persona no puede completar todas las tareas asignadas porque simplemente no tiene suficiente tiempo disponible.

Alguien Asignado para Hacer Cada Cosa

Cada tarea en un proyecto necesita tener un individuo específico que se le asigne la responsabilidad de completar esa tarea. Si descubres que necesitas múltiples individuos asignados a la misma tarea, a menudo no has llegado a un nivel lo suficientemente granular para distinguir las tareas.

Por ejemplo, en muchas industrias, habrá fases de diseño y construcción; esto podría ser en fabricación, construcción o incluso software. Debes desglosar esto para que puedas asignar las tareas específicas del diseñador y las tareas específicas del constructor. A menudo encontrarás un intercambio entre las dos disciplinas, que puedes tener en cuenta. Un ejemplo podría verse así:

1. Fase de Diseño 1 por Diseñadores
2. Verificación de Viabilidad 1 por Constructores
3. Fase de Diseño 2 por Diseñadores
4. Verificación de Viabilidad 2 por Constructores
5. Revisión por Parte de un Interesado Senior
6. Finalización del Diseño por Diseñadores
7. Revisiones Finales por Constructores
8. Aprobación por Interesados

Esto muestra un realista vaivén entre las diferentes partes involucradas, en lugar de tener una “Fase de Diseño” sola asignada al equipo de diseño hasta la finalización de la fase de diseño.

Cronogramas para Cada Cosa

Esta puede ser la parte más desafiante de crear un plan — ¿cómo medimos cuánto tiempo tomará cada cosa? Como se discutió anteriormente, los cronogramas no deben hacerse de arriba hacia abajo, sino de abajo hacia arriba. Esto significa que cada elemento es estimado por la persona que va a hacer el trabajo (o al menos un colega conocedor) y que todas estas estimaciones se suman y se calculan en un cronograma general.

Dicho esto, es útil tener un cronograma general de alto nivel antes de que se hagan las estimaciones detalladas porque estimar cuánto tiempo tomará algo y decidir sobre el enfoque específico para resolver la tarea son esencialmente lo mismo.

Así que si un proyecto tiene cronogramas generosos de alto nivel, entonces los expertos individuales pueden tener eso en cuenta en sus estimaciones y tratar de optimizar soluciones a largo plazo en lugar de recortar esquinas para garantizar que se cumplan los cronogramas. Si el proyecto tiene un cronograma apresurado, entonces cada experto sabe que puede necesitar hacer concesiones.

Una cosa que a menudo se olvida durante la creación de planes de proyecto es que los interesados necesitarán revisar el progreso y confirmar decisiones que deben tenerse en cuenta. La mejor manera de hacer esto es mirar el proyecto anterior que incluye el mismo conjunto de interesados y entender cuál es un tiempo de respuesta típico para que ellos proporcionen comentarios.

Otro peligro aquí es que si hay reuniones mensuales del comité directivo con interesados clave, ¿qué sucede si un entregable del proyecto no puede ser presentado a tiempo para una de esas reuniones? ¿El proyecto se pausa hasta el próximo mes cuando los interesados se reúnan de nuevo, o se tratará y aprobará (o se devolverá con comentarios) entre los comités directivos mensuales?

Una Estrategia de Comunicación

Cuando surgen problemas como este, confirman que el enfoque de las comunicaciones dentro de un proyecto es de suma importancia.

Por lo general, el problema no es que haya una mala estrategia, sino que no hay estrategia en absoluto. Así que los canales de comunicación se abren de manera informal y ad hoc, y “suficientemente bueno” se convierte en el estándar.

El problema con esto es que las cosas no siempre salen según lo planeado. Las personas cambian, se pierde conocimiento, y a medida que el proyecto se vuelve más extenso y más personas se unen, la sobrecarga de comunicación puede explotar rápidamente.

Así que, claramente, las herramientas en sí no son tan importantes; es un hecho que a medida que escalas más allá de un número no trivial de personas (digamos, 10), el trabajo en equipo se vuelve cada vez más difícil.

Eso se debe a que la comunicación del equipo no escala de manera lineal en comparación con el número de personas en el equipo.

Por ejemplo, si tienes un equipo de 2 personas, hay un hilo de comunicación (entre los dos individuos). Si agregas otra persona a la mezcla; ahora tienes tres hilos de comunicación. Así que, mientras el tamaño del equipo ha aumentado en un 50%, los hilos de comunicación han aumentado en un 300%.

Veamos cómo crece esto:

• 2 miembros del equipo = 1 hilo de comunicación
• 3 miembros del equipo = 3 hilos de comunicación
• 5 miembros del equipo = 10 hilos de comunicación
• 8 miembros del equipo = 28 hilos de comunicación
• 10 miembros del equipo = 45 hilos de comunicación
• 15 miembros del equipo = 105 hilos de comunicación
• 20 miembros del equipo = 190 hilos de comunicación
• 30 miembros del equipo = 435 hilos de comunicación
• 50 miembros del equipo = 1,225 hilos de comunicación
• 100 miembros del equipo = 4,950 hilos de comunicación

Esto se puede expresar mediante la siguiente ecuación:

n(n-1)/2

Donde n es el número de personas que necesitan estar involucradas en el proyecto.

Como puedes ver, este número crece exponencialmente a medida que aumenta el tamaño del equipo. Si tienes un equipo de 10 personas, se deben gestionar 45 hilos de comunicación potenciales. Pero si tienes un equipo de 50 personas, hay 1,225 hilos de comunicación potenciales — ¡eso es 27 veces más! Y si tienes un equipo de 100 personas, hay 4,950 hilos de comunicación posibles — ¡eso es 110 veces más!

Es importante señalar que este no es solo un problema con equipos más grandes, sino con cualquier equipo donde los individuos no están en la misma ubicación. Esto se debe a que el número de hilos de comunicación posibles no está limitado por la proximidad física de los miembros del equipo.

Por ejemplo, tienes un equipo de 10 personas, pero todas están ubicadas en diferentes partes del mundo. En este caso, todavía hay 45 hilos de comunicación potenciales que deben gestionarse — a pesar de que los miembros del equipo no están físicamente próximos entre sí.

Y puede empeorar. El cálculo anterior asume solo un método de comunicación. Si queremos tener en cuenta diferentes métodos de comunicación, tendríamos que reescribir la ecuación de la siguiente manera:

n(n-1)/2

Donde n es el número de canales de comunicación.

Volvamos a tomar el número de hilos de comunicación anterior, pero esta vez asumamos que n está compuesto por:

• Correo electrónico
• Chat grupal
• Chat personal
• Comentarios en un sistema de gestión de proyectos
• Llamadas
• Notas/Comentarios en documentos

Al introducir los números, esto es lo que obtenemos:

• 2 miembros del equipo = 6 hilos de comunicación
• 3 miembros del equipo = 18 hilos de comunicación
• 5 miembros del equipo = 60 hilos de comunicación
• 8 miembros del equipo = 168 hilos de comunicación
• 10 miembros del equipo = 270 hilos de comunicación
• 15 miembros del equipo = 630 hilos de comunicación
• 20 miembros del equipo = 1,140 hilos de comunicación
• 30 miembros del equipo = 2,610 hilos de comunicación
• 50 miembros del equipo = 7,350 hilos de comunicación
• 100 miembros del equipo = 29,700 hilos de comunicación

Es aterrador cómo crece rápidamente el número de hilos de comunicación — y si el trabajo remoto permite más fácilmente reuniones más grandes que no serían prácticas en la vida real, entonces es una espada de doble filo.

Así que, en resumen, una estrategia es crucial para evitar la explosión de comunicación que puede ocurrir incluso con un número relativamente pequeño de miembros del equipo.

Y aunque la idea de una “estrategia de comunicación” puede sonar compleja y grandiosa, no tiene que serlo. Lo clave es establecer algunos principios, declarar los canales de comunicación clave y quizás también decirles a las personas qué no hacer.

Algunos principios fundamentales a considerar:

• Mantener la información abierta. Supón que todo necesita ser fácilmente encontrable y compartible meses/años a partir de ahora. Asegúrate de que todos en el equipo del proyecto tengan acceso a toda la información requerida, y ten cuidado de nombrar archivos y documentos con esto en mente.
• Errar en el lado de la claridad. Imagina que alguien nuevo se une al equipo del proyecto. Documenta la información de manera clara y concisa para asegurar que puedan entender fácilmente decisiones críticas.
• Mantener actas de las reuniones. Asegúrate de que todas las reuniones significativas sean registradas y fácilmente encontrables.

En términos de canales de comunicación, cuantos menos, mejor. Sugeriríamos reducirlo a lo siguiente:

• Un software de gestión de proyectos para tener discusiones específicas sobre tareas.
• Reuniones (en persona o remotas) con actas de reuniones y un lugar para encontrar todas las actas de reuniones del proyecto en un solo lugar.
• Documentos: esto podría ser comentarios y discusiones dentro de Google Docs o herramientas específicas (es decir, Figma para diseño UX) que permitan comentarios.

También es aceptable agregar chat grupal a esta lista — pero entonces debe ser gestionado cuidadosamente, ya que puede convertirse en una enorme reunión de todo el día (¡y todos los días!) sin un objetivo o agenda clara.

El gerente de proyecto necesita establecer estas reglas claramente y ser un brillante ejemplo de cómo colaborar mientras ocasionalmente utiliza un palo (metafórico, no literal) para hacer que los miembros del equipo del proyecto se comuniquen correctamente.

Reflexiones Finales

Independientemente del nivel de experiencia de uno, siempre es valioso dar un paso atrás y ver un tema o proceso a nivel fundamental. Así que, al profundizar en el tema de la gestión de proyectos, hemos identificado los principales primeros principios requeridos para ejecutar un proyecto con éxito.

Cada proyecto debe tener un gerente de proyecto: ellos aseguran que el proyecto tenga objetivos claros, que se desglosan en tareas que deben completarse para alcanzar el objetivo final. El gerente de proyecto luego necesita asignar un miembro del equipo a cada tarea. Juntos, el equipo puede identificar los cronogramas para cada tarea individual y para todo el proyecto.

A menudo, son las cosas que parecen evidentes las que pueden causar problemas, en lugar de los temas avanzados, que tienden a recibir más atención — por ejemplo, la comunicación. Por eso debería haber una estrategia de comunicación bien definida tanto dentro del equipo del proyecto como externamente, con los interesados.

La gestión de proyectos es un tema complejo, así que esto no es de ninguna manera una guía exhaustiva. Aún hay algunos factores a considerar que no hemos cubierto en esta visión general inicial, como presupuestos, métodos para resolver conflictos entre opciones y hasta dónde llevar la delegación dentro de un proyecto.