Ha pasado un tiempo desde la ultima publicación, y realmente el tiempo se hace menor cuando emprendemos negocios propios, así que, por exceso de trabajo, lo que considero una bendición, no he tendió suficiente tiempo para escribir, además de mis tareas como catedrática, y CIO consultora para dos empresas por horas, y no olvidemos mis tareas como deportista, mama y esposa
Pero siempre hay tiempo para lo importante, y hoy quiero publicar un poco sobre mi experiencia personal trabajando en planeación de proyectos agiles y su costeo, antes desde el punto de vista de cliente, y ahora desde el punto de vista de proveedor.
La filosofía ágil y los diferentes frameworks que la representan, son en su mayoría de alta adopción hoy en día en el mundo, con buenas y malas implementaciones, pero definitivamente en la baraja de cartas de casi todas las compañías de desarrollo de software (Y otras también), sin embargo es difícil encontrar un punto mas allá de lo académico en la titánica tarea de presentar un plan de trabajo, unos costos y realizar un contrato en donde ya no se costea por horas, en donde, según estos frameworks, el alcance es variable y desconocido, y por lo tanto, un riesgo financiero y de tiempo tanto del proveedor como el cliente.
1. El método del taxímetro, altamente usado por los proveedores de la región, basa sus estimaciones en horas, lo que significa para el proveedor que entre mas tiempo se tarde, mas dinero cobrara por el proyecto, algo realmente contraproducente para el cliente, y contra producente contra la filosofía ágil en general, pues este tipo de contrato y costeo dificulta el cambio de alcance. Este método es justamente el que inicia las discusiones, eso no fue lo que yo pedí, el producto no es lo que esperaba, cancelemos el proyecto. Como cliente, siempre me sentí estafada con este método, sobre todo porque me cobran por horas de recursos con ciertos perfiles, que ni siquiera se si en realidad fueron asignados a mi proyecto las horas que reclaman.
2. El método de tiempo y materiales es interesante, pues motiva definitivamente el modelo del alcance variable, en este, se cobra por equipos, no personas, lo cual esta de la mano con los frameworks agiles, por ejemplo SCRUM, pero no maneja la incertidumbre, pues por mas flexibles que seamos, puede que el tiempo no se calcule bien, en beneficio o daño de alguna parte. Terminamos generando miles de cambios de alcances o modificaciones.
En la teoría del agilísimo existen dos famosos métodos que también vale la pena describir antes de darles mi opinión y como lo aplico actualmente de forma real mas allá de la academia:
1. Modelo Cockburn: En este modelo, se define un costo por hora de los recursos mucho menor a lo que en realidad le cuesta al proveedor, pero además se estiman unas historias de usuario y unos puntos de usuario basado en los raleases (mediano nivel de detalle), y se asigna un costo por cada punto de historia de usuario. De esta manera:
· Tarifa horaria base baja, menor que el costo (50 usd), por ejemplo (15 usd)
· Se define una tarifa por punto de historia de usuario para cubrir el presupuesto del punto 1. (160.000 – 15* 3200) / 1000 = 112 USD
· Si el proveedor se tarda dos semanas mas del tiempo planeado (320 horas mas), el sobre coste se limita, pues siempre seran las mismas 1.000 historias de usuario, y el costo de las horas adicionales sera a la tarifa base baja = 164.800. En un proyecto tradicional con tarifa de 50 usd, el cliente habria pagado = 176.000 usd
· Si el proveedor termina antes, Y ESTE METODO LO MOTIVA, por ejemplo termina las 1.000 puntos de historia en 18 semanas, entonces su costo disminuye, originalmente era de 160.000 usd y se reduce a 144.000 usd
Este modelo es muy completo, pero en mi experiencia, complejo de explicar a clientes y proveedores, la medida de la cantidad de puntos de historia sigue siendo un voto de confianza. Es teóricamente muy completo, pero personalmente no he podido aplicarlo a proyectos de la vida real.
2. Modelo money for nothing and changes for free: Este modelo supone que la creación de dos clausulas en el contrato, la clausula de money for nothing en donde si el cliente quiere acabar el proyecto antes de tiempo (super alineado con agilísimo) puede hacerlo y se pacta un porcentaje que se pagara al proveedor por el tiempo adicional pactado que ya no se trabajara, y una clausula de changes for free en donde, el cliente puede cambiar cualquier orden de trabajo, puede hacerlo por otra así sea nueva, siempre y cuando tenga las mismas historias de usuario de la que se reemplaza. En mi experiencia, el modelo de money for nothing and changes for free es complejo de pactar pues cliente jamas puede imaginarse un producto con menos de lo que quiere al principio, al contrario, normalmente termina siendo mas que el alcance inicial.
Mi recomendación y practica para la estimación de costos y contratos agiles es la siguiente:
1. Definir un alcance básico, lo que se llama en los niveles de planificación de agilísimo, una VISION.
2. Definir un ROADMAP con las características de valor y problemas a solucionar en cada uno de los releases.
3. Con estos dos puntos, crear un costo y tiempo base del proyecto sobre un contrato de tiempo y materiales, por el equipo completo, no por horas, ni por personas individuales.
4. Durante los ajustes de alcance de realease, trabajar la clausula de Changes for Free para dar flexibilidad al cliente.
5. Posterior al ultimo reléase, si aun existen requisitos del cliente que se desean cumplir, evaluar si se lanza un nuevo contrato de tiempo y materiales por esos releases (si es algo grande), de lo contrario, y al ya tener métricas de este equipo de productividad, definir cuanto costara al proveedor y definir un precio por entregable, no por hora.
Pero siempre hay tiempo para lo importante, y hoy quiero publicar un poco sobre mi experiencia personal trabajando en planeación de proyectos agiles y su costeo, antes desde el punto de vista de cliente, y ahora desde el punto de vista de proveedor.
La filosofía ágil y los diferentes frameworks que la representan, son en su mayoría de alta adopción hoy en día en el mundo, con buenas y malas implementaciones, pero definitivamente en la baraja de cartas de casi todas las compañías de desarrollo de software (Y otras también), sin embargo es difícil encontrar un punto mas allá de lo académico en la titánica tarea de presentar un plan de trabajo, unos costos y realizar un contrato en donde ya no se costea por horas, en donde, según estos frameworks, el alcance es variable y desconocido, y por lo tanto, un riesgo financiero y de tiempo tanto del proveedor como el cliente.
1. El método del taxímetro, altamente usado por los proveedores de la región, basa sus estimaciones en horas, lo que significa para el proveedor que entre mas tiempo se tarde, mas dinero cobrara por el proyecto, algo realmente contraproducente para el cliente, y contra producente contra la filosofía ágil en general, pues este tipo de contrato y costeo dificulta el cambio de alcance. Este método es justamente el que inicia las discusiones, eso no fue lo que yo pedí, el producto no es lo que esperaba, cancelemos el proyecto. Como cliente, siempre me sentí estafada con este método, sobre todo porque me cobran por horas de recursos con ciertos perfiles, que ni siquiera se si en realidad fueron asignados a mi proyecto las horas que reclaman.
2. El método de tiempo y materiales es interesante, pues motiva definitivamente el modelo del alcance variable, en este, se cobra por equipos, no personas, lo cual esta de la mano con los frameworks agiles, por ejemplo SCRUM, pero no maneja la incertidumbre, pues por mas flexibles que seamos, puede que el tiempo no se calcule bien, en beneficio o daño de alguna parte. Terminamos generando miles de cambios de alcances o modificaciones.
En la teoría del agilísimo existen dos famosos métodos que también vale la pena describir antes de darles mi opinión y como lo aplico actualmente de forma real mas allá de la academia:
1. Modelo Cockburn: En este modelo, se define un costo por hora de los recursos mucho menor a lo que en realidad le cuesta al proveedor, pero además se estiman unas historias de usuario y unos puntos de usuario basado en los raleases (mediano nivel de detalle), y se asigna un costo por cada punto de historia de usuario. De esta manera:
· Tarifa horaria base baja, menor que el costo (50 usd), por ejemplo (15 usd)
· Se define una tarifa por punto de historia de usuario para cubrir el presupuesto del punto 1. (160.000 – 15* 3200) / 1000 = 112 USD
· Si el proveedor se tarda dos semanas mas del tiempo planeado (320 horas mas), el sobre coste se limita, pues siempre seran las mismas 1.000 historias de usuario, y el costo de las horas adicionales sera a la tarifa base baja = 164.800. En un proyecto tradicional con tarifa de 50 usd, el cliente habria pagado = 176.000 usd
· Si el proveedor termina antes, Y ESTE METODO LO MOTIVA, por ejemplo termina las 1.000 puntos de historia en 18 semanas, entonces su costo disminuye, originalmente era de 160.000 usd y se reduce a 144.000 usd
Este modelo es muy completo, pero en mi experiencia, complejo de explicar a clientes y proveedores, la medida de la cantidad de puntos de historia sigue siendo un voto de confianza. Es teóricamente muy completo, pero personalmente no he podido aplicarlo a proyectos de la vida real.
2. Modelo money for nothing and changes for free: Este modelo supone que la creación de dos clausulas en el contrato, la clausula de money for nothing en donde si el cliente quiere acabar el proyecto antes de tiempo (super alineado con agilísimo) puede hacerlo y se pacta un porcentaje que se pagara al proveedor por el tiempo adicional pactado que ya no se trabajara, y una clausula de changes for free en donde, el cliente puede cambiar cualquier orden de trabajo, puede hacerlo por otra así sea nueva, siempre y cuando tenga las mismas historias de usuario de la que se reemplaza. En mi experiencia, el modelo de money for nothing and changes for free es complejo de pactar pues cliente jamas puede imaginarse un producto con menos de lo que quiere al principio, al contrario, normalmente termina siendo mas que el alcance inicial.
Mi recomendación y practica para la estimación de costos y contratos agiles es la siguiente:
1. Definir un alcance básico, lo que se llama en los niveles de planificación de agilísimo, una VISION.
2. Definir un ROADMAP con las características de valor y problemas a solucionar en cada uno de los releases.
3. Con estos dos puntos, crear un costo y tiempo base del proyecto sobre un contrato de tiempo y materiales, por el equipo completo, no por horas, ni por personas individuales.
4. Durante los ajustes de alcance de realease, trabajar la clausula de Changes for Free para dar flexibilidad al cliente.
5. Posterior al ultimo reléase, si aun existen requisitos del cliente que se desean cumplir, evaluar si se lanza un nuevo contrato de tiempo y materiales por esos releases (si es algo grande), de lo contrario, y al ya tener métricas de este equipo de productividad, definir cuanto costara al proveedor y definir un precio por entregable, no por hora.
