Cuando un arquitecto diseña un plano de construcción, debe establecer todas las especificaciones por adelantado, sin posibilidad de modificarlas posteriormente. No es posible simplemente colocar los cimientos y luego decidir si construir cinco o doce pisos. De lo contrario, todo el proyecto podría literalmente derrumbarse.
En el sector TI ocurre exactamente lo contrario. Si bien al inicio de un proyecto desarrollamos los términos de referencia y creamos prototipos, todo puede cambiar durante la implementación; por ejemplo, el cliente puede comenzar a ofrecer un nuevo servicio que requiera crear una sección adicional en el sitio web. Por eso en TI, nunca se sabe realmente qué puede surgir en términos de gestión de proyectos.
El gerente de proyecto es el responsable de todo el proceso desde la primera reunión con el cliente hasta la entrega final. Sus responsabilidades incluyen:
- Comunicación con el cliente
- Planificación del flujo y presupuesto del proyecto
- Asignación de tareas
- Control de implementación
- Aceptación y entrega del proyecto
Todos estos procesos dependen en gran medida de la metodología de gestión de proyectos elegida. Y aquí es donde comienza la incertidumbre, ya que es difícil predecir de antemano qué método funcionará mejor.
Elección de metodología
Existen diferentes enfoques para la gestión de proyectos, pero los más comunes son Waterfall y Agile. Aunque Agile surgió originalmente como una metodología independiente, se ha convertido en una especie de término general para todos los modelos flexibles que difieren del tradicional Waterfall, como scrum, kanban, scrumban, etc.
La metodología Waterfall es un modelo de gestión clásico con una secuencia lineal de etapas, donde una sigue a la otra en cascada (de ahí su nombre). Este enfoque implica una lista predefinida de tareas que no deberían cambiar significativamente durante la implementación. En otras palabras, todo va según lo planeado.
En Toimi, utilizamos Waterfall para proyectos estándar con presupuesto fijo donde la lista de tareas y los plazos aproximados están más o menos claros desde el principio; por ejemplo, este es el caso de las tiendas online y los catálogos de servicios.
Sin embargo, los proyectos grandes y poco convencionales son muy difíciles de predecir con anticipación. En estos casos, es mejor utilizar métodos más flexibles donde el contenido de cada etapa puede variar de mes a mes. Es decir, mientras trabajamos en un conjunto de tareas (en scrum, esto se llama "sprint"), simultáneamente discutimos el tiempo y contenido del siguiente sprint. En el enfoque scrum tradicional, cada sprint dura dos semanas, pero en realidad las empresas suelen establecer sus propios plazos según la carga de trabajo.
Este enfoque ofrece mayor flexibilidad y permite adaptarse a factores externos. Por ejemplo, si el cliente quiere lanzar un servicio de entrega mientras trabajamos en su sitio web, solo necesita priorizar esta tarea. Así comenzaremos a trabajar en el servicio durante el siguiente sprint, no seis meses después de completar todas las otras etapas.
Además, las metodologías flexibles de gestión de proyectos son ideales para proyectos con un largo proceso de autorización. Esto es relevante para grandes empresas, donde cada cambio necesita ser aprobado por varios ejecutivos. En el modelo tradicional, este proceso puede extenderse durante mucho tiempo, pero con el enfoque flexible puedes trabajar en un conjunto de tareas mientras discutes simultáneamente la siguiente etapa.
Negociación
En muchos casos, la elección de la metodología de gestión de proyectos depende del cliente. Si el cliente tiene conocimientos de TI y está profundamente involucrado en el proyecto, puede participar en la gestión de procesos y priorización de tareas, es decir, trabajar bajo un modelo ágil. Pero las empresas suelen solicitar tarifas fijas, lo que implica el enfoque tradicional. Generalmente hay una buena razón para ello: el gerente debe informar a los accionistas o al CEO y planificar el presupuesto. Y como el contratista no puede insistir en una metodología diferente, ambas partes deben encontrar juntas las soluciones más óptimas.
En la gestión de proyectos, la comunicación con el cliente generalmente requiere buenas habilidades de negociación por parte del gerente. La visión del proyecto por parte del cliente suele ser muy diferente de cómo la ve el equipo técnico. Al cliente le importan los resultados, el presupuesto, las ventas y los leads, mientras que el equipo de desarrollo necesita un conjunto claro de tareas. Y es responsabilidad del gerente de proyecto unir estas dos visiones. Su objetivo no es imponer su punto de vista, sino encontrar puntos en común y ayudar a comprender el valor del proyecto, permitiendo a las partes buscar las mejores soluciones posibles.