6.1. Contratación

6.1.1 - Roles del proyecto

Las personas ocupan un papel clave en la gestión de proyectos ágiles, su participación se da a través del conjunto de responsabilidades que les son asignadas, es decir, su rol en el proyecto. En un proyecto Scrum se consideran 2 categorías de clasificación para los roles:

6.1.1.1 - Comprometidos

Los comprometidos son los roles que obligatoriamente se requieren para producir el producto del proyecto, por ende, son los responsables del éxito de cada iteración del proyecto y del proyecto en sí.

Los roles comprometidos son:

El Product Owner.
El Scrum Master.
El Equipo de Desarrollo.

6.1.1.2 - Involucrados

Los involucrados son los roles que no son obligatoriamente necesarios para el proyecto Scrum. Ellos pueden interactuar con el equipo, pero NO son responsables del éxito del proyecto.

Los roles involucrados son:

Clientes.
Usuarios.
Proveedores (Ej: Freelancers; Proveedores de servicios; etc).
Oficina de Gestión de Proyectos Ágiles (APMO).

6.1.2 - Contratación del equipo (Personal)

A continuación, se describen algunas de los requisitos que se deben considerar para la asignación/contratación de las personas que ocuparán los distintos roles en un proyecto Scrum.

Product Owner	Scrum Master	Equipo de Desarrollo
- Experto en Scrum	- Experto en Scrum	- Conocimiento básico de Scrum
- Amplia experiencia y dominio del negocio	- Capacidad para resolver problemas	- Expertos técnicos
- Buen negociador	- Habilidades de coordinación	- Multifuncionales
- Organizado	- Líder servicial	- Proactivos
- Experiencia en dirección de proyectos
- Líder servicial

6.1.2.1 - Los líderes serviciales

Los líderes serviciales tienes varias características que les permiten apoyar al Equipo de Desarrollo:

Capacidad de escuchar: Escuchan con atención y son receptivos a lo que se dice y no se dice para comprender y reflexionar sobre la situación.
Empatía: Aceptan y reconocen a los individuos por sus habilidades y destrezas únicas.
Persuasión: Logran el consenso del Equipo en la toma de decisiones.

6.1.2.2 - Matriz de competencias

La matriz de competencias le permite a la organización identificar las competencias necesarias en los miembros que hacen o harán parte de los distintos equipos y así encontrar cualquier brecha que pueda existir en los miembros del Equipo Scrum, y así también poder identificar los miembros que necesitarán capacitación adicional en un área o competencia específica.

Nota: Esta matriz está basada en el Modelo de desarrollo de habilidades de Dreyfus explicado más adelante

dibujo

Aunque generalmente para la contratación de los miembros del equipo se realiza con base en el conocimiento o habilidades técnicas, en Scrum se reconoce que también es necesario que los miembros del equipo cuenten con otro tipo de habilidades que le permitan desarrollar mejores interacciones, mejor comunicación y mayor cohesión. Las necesidades del equipo Scrum, se toman como criterios adicionales a tener en cuenta para la adecuada contratación de los miembros.

Los elementos necesarios para el buen desempeño de un equipo son:

Habilidades técnicas: Son las habilidades especificas que requieren los miembros que desarrollarán los entregables del proyecto. (Ej, Diseño – Desarrollo de Software – Conocimiento de una herramienta específica, etc)
Habilidades esenciales: También llamadas habilidades blandas, son las habilidades que permiten lograr la empatía y buenas relaciones entre todos los Stakeholders del proyecto.
Procesos y prácticas: Las personas deben conocer los entregables, eventos, o herramientas a usar dentro del proyecto. Scrum, por ejemplo, describe 17 prácticas aplicables a los proyectos.
Herramientas: Para desarrollar los entregables del proyecto siempre será indispensable el uso de herramientas, por ejemplo

dibujo

6.1.2.3 - Roles del Equipo de Desarrollo

Se suele pensar que en los equipos multifuncionales no pueden existir roles ni especialistas, siendo esta afirmación totalmente falsa, por lo general un equipo está compuesto por distintos especialistas tales como:

Analistas.
Desarrolladores.
Probadores.
Integradores.
Diseñadores.
Arquitectos.
Etc.

¿Contratar Novatos o Expertos?

Si el objetivo es terminar el proyecto en poco tiempo y con muy alta calidad deberás contratar expertos técnicos, considerando que esto tendrá un impacto significativo en el costo; por otro lado, se podrían contratar solo novatos, pero el proyecto tardará bastante en desarrollarse debido a la curva de aprendizaje, además la calidad podría verse comprometida.

Realizar una combinación entre novatos y expertos, puede desmotivar a los expertos, aunque también puede darse la situación en la que los novatos crezcan rápido y se logre el equilibrio esperado.

6.1.3 - Tipos de contratos

Contrato de precio fijo

Se define un precio total fijo para todo lo que se desarrolle en el proyecto.
Mayor riesgo financiero si no se da cumplimiento a todo el proyecto en función del contrato.
Los entregables son fijos y definidos al inicio del proyecto.
No son ideales para el uso de Scrum.

Contrato de Unión Temporal

Generalmente se utiliza cuando dos o más socios ejecutan un proyecto.
El ROI (ingresos o beneficios) será compartido entre todos los socios.
Es importante definir los % de participación y las responsabilidades en el proyecto.
Es ideal centralizar los equipos o dividir el proyecto en componentes.

Contrato de desarrollo en fases

Se considera el concepto de Producto Mínimo Viable.
Se “fragmenta” el proyecto en varias fases, donde al final de cada fase se hacen pagos.
Cada fase genera un conjunto importante de entregables.
Útil para proyectos de gran tamaño.
Se reduce el riesgo monetario, ya que los despliegues sin éxito no son financiados.

Contrato de entrega incremental

El cliente/patrocinador puede tomar decisiones sobre el proyecto en cada inspección: Puede aceptar el entregable, Detener el desarrollo o Solicitar modificaciones.
Cada Sprint debe generar un incremento por lo general es una épica o componente completo.
El pago/facturación se hace con cada Iteración (se utiliza generalmente en proyectos internos).
También se le llama “Contrato por Sprints”.

Contrato de tiempo y materiales

Este tipo de contrato cuenta con un componente fijo: el precio, el cual puede estar definido por (horas, unidades, metro cuadrado…, etc.,) y, un componente variable, el cual se refiere a cantidades, es decir, (número de horas, número de unidades y/o metros cuadrados, etc.,) invertidos finalmente en el desarrollo de un trabajo.

Este tipo de contrato es usado cuando no es preciso especificar durante el desarrollo de un trabajo, la cantidad requerida de trabajo a ejecutar.

6.1.4 Contratación de proveedores

Para garantizar que se trabaja con los mejores proveedores, la selección se realiza considerando las opiniones de todo el Equipo Scrum. Algunos de los criterios que se pueden considerar para la selección de los proveedores son:

Precio.
Curva de Aprendizaje.
Facilidad de uso.
Velocidad de la Solución.
Soporte.
Seguridad.
Complejidad para la migración de Datos.
Tiempo de Implementación.
Reputación.
Facilidad de Pago.
Referencias.

6.1.6 – Los “Freelancers”

En algunos proyectos, podría ser necesario el apoyo de personal no disponible en el Equipo de Desarrollo, por ejemplo “Arquitectos”, “Diseñadores”, “Administradores de Bases de Datos”, etc.

Este tipo de personal es considerado como proveedor, y normalmente solo se contrata por días, y en momentos muy específicos del proyecto.

dibujo

Las finanzas del proyecto son una de las consideraciones más importantes en la gestión de un proyecto (sobre todo en proyectos externos a la organización), ya que, de no realizarse una adecuada gestión financiera, el proyecto podría generar pérdidas, comportamiento no deseados, e incluso la cancelación total de un proyecto.

Las finanzas del proyecto se ven reflejadas principalmente en los siguientes momentos:

Inicio del proyecto: En la definición del presupuesto inicial del proyecto, que permitirá evaluar la viabilidad de iniciar un proyecto, además de asegurar los recursos financieros del proyecto, e incluso identificar posibles riesgos financieros.
Ejecución del Proyecto: Al final de cada Sprint, podría realizarse seguimiento y control financiero del proyecto, para así evitar desviaciones o la ocurrencia de posibles problemas, al ser realizada de forma iterativa, supone menor desgaste para la persona que asuma esta responsabilidad (normalmente es el Product Owner), además de garantizar que siempre se encuentra actualizada la información.
Cierre del Proyecto: Por lo general, las organizaciones solicitan a los equipos de proyecto un reporte final que describa los costos del proyecto, en relación al presupuesto solicitado. En Scrum la función encargada de analizar dicha información se conoce como la APMO (Agile Project Management Office). Además esta información servirá para alimentar el portafolio de proyectos.

dibujo

6.2.1 - Presupuesto inicial del proyecto

Una de las prácticas clave en Scrum es la construcción del Presupuesto inicial del proyecto, para lo cual se deben tener en cuenta como mínimo los siguientes elementos:

Personas que harán parte del proyecto.
Materiales.
Servicios.
Infraestructura.
Capacitación del equipo.
Reservas.
Otros gastos que afecten el desarrollo del proyecto.

Nota: Es responsabilidad del Product Owner y el Patrocinador del proyecto, discutir, negociar y aceptar el presupuesto para asegurar que haya suficientes fondos disponibles para el proyecto.

Algunas de las técnicas y herramientas que se pueden utilizar para gestionar las finanzas del proyecto son:

6.2.2 - Retorno de la Inversión

El ROI (Return of Investment) es el cálculo de las utilidades (o valor financiero) generado por un proyecto. Esto sirve a muchas organizaciones para determinar si los proyectos externos son exitosos o no.

dibujo

Nota: No todos los proyectos están diseñados para generar utilidades (ganancias), así que en estos proyectos lo que se mide es el valor entregado (beneficios) en algo llamado VOI (Value of Investment)

6.2.3 - Estimación basada en históricos

Los datos históricos del mismo proyecto o de otros proyectos serán de gran utilidad para lograr mejores estimaciones de los elementos que hacen parte del Product Backlog.

Dependiendo de la información disponible en la organización, se puede utilizar:

Históricos reales de proyectos anteriores: Esta técnica funcionará siempre y cuando la organización mantenga el registro del esfuerzo y duración reales del proyecto (la técnica más recomendable en Scrum).
Históricos planeados: En los que se cuenta con un estimado original, aunque no se haya tenido un seguimiento a los datos reales (la técnica más común). Esto es por ejemplo el histórico de cotizaciones de proyectos externos o casos de negocio de proyectos no ejecutados o no aprobados.

6.2.4 - Coeficiente de conocimiento del negocio

Esta técnica está basada en la idea de que a mayor conocimiento del negocio/proyecto, más precisa será la estimación del presupuesto. A menor conocimiento del negocio/proyecto, habrá mayor riesgo y menor precisión en la estimación.

El objetivo de esta técnica es calcular en una escala porcentual el grado de conocimiento sobre el negocio y a partir de allí calcular la reserva financiera o presupuestal.

Algunos factores para el cálculo del coeficiente de conocimiento sobre negocio son:

Experiencia en proyectos similares.
Calidad de requerimientos iniciales del proyecto.
Grado de riesgo al que está expuesto el proyecto.
Desviación (%) en las estimaciones de proyecto.