Presupuestos ágiles en el desarrollo web: ¡Lo que nadie te cuenta!

Presupuestos ágiles en el desarrollo web: ¡Lo que nadie te cuenta!

Presupuestos ágiles en el desarrollo web drupal

Dicen que el dinero es energía, que por tanto ni se crea ni se destruye, sólo se transforma. Así que la energía que entregamos con nuestro trabajo se nos devuelve en la forma física de dinero.

Si es tan sencillo ¿cómo el tema de los presupuestos se hace a veces tan complejo?

Hace poco tropecé con este hangout en diferido donde varios profesionales del desarrollo de software y metodologías ágiles debaten sobre la mejor forma de presupuestar un servicio de desarrollo web.

En concreto, Carlos Iglesias, el impulsor del encuentro, propone debatir sobre la mejor manera de afrontar un presupuesto ágil.

Presupuestar es un arte no reconocido

Si la programación ya me parece muchas veces un arte (recuerdo con cariño aquella frase que tanto repetíamos en la facultad: «esto ayer funcionaba» :-)), presupuestar un servicio de desarrollo web es sumarle un doble salto mortal con doble voltereta.

Una parte del «problema», que creo que no se puede pasar por alto, es nuestra relación con el dinero, que por lo general se mueve en una especie de amor-odio, originado por la educación, el sistema económico y social, etc.

¿Dónde está la escuela para aprender a presupuestar un desarrollo web?

Los programadores hemos tenido que ir aprendiendo a base de prueba y error (¡uy, esto también me suena!)

Cómo valorar el trabajo

Un servicio de desarrollo web se puede valorar de distintas formas:

  • Precio por hora: es el método más común en la prestación de servicios. Aparentemente, da la seguridad al desarrollador de que sus horas de trabajo van a ver recompensadas, y por el lado del cliente, cree saber a qué atenerse ya que conoce la tarifa/hora del proveedor.
  • Precio por componente: en el desarrollo web con drupal puede ser útil dividir el trabajo en funcionalidades, tareas y/o componentes (tipos de contenido, vistas, desarrollo de módulos, etc.) y valorarlos desde nuestra experiencia en el desarrollo de esos componentes.
  • Precio por valor: parecido al anterior, pero tomando como referencia no los componentes en sí, sino el valor del resultado final.

¿Valor para el desarrollador o para el cliente?

¡Muy buena pregunta! En el vídeo del que hablo se trata este tema, y es que el valor que sobre una funcionalidad tiene el desarrollador, puede ser muy distinta de la que tiene el cliente.

Hay que tener esto en cuenta en todo el proceso, y estar cercanos a las necesidades del cliente para poder ajustar lo más realmente posible un presupuesto.

Presupuesto tradicional: precio fijo a plazo fijo

Por lo general, y a lo que estamos acostumbrados tanto clientes como proveedores, es a ofrecer un servicio X a un precio Y en un plazo Z. Es el famoso «siempre se ha hecho así».

Ya sea que lo hayamos valorado por hora, componente o valor, el resultado es un tanto en un plazo.

¿Qué pueden hacer por mí los presupuestos ágiles?

Una forma distinta de valorar un trabajo de desarrollo web es mediante presupuestos ágiles, en principio, como forma de estimar desarrollos con metodologías ágiles.

Este tipo de presupuestos intenta valorar el trabajo, y los recursos necesarios para realizarlo, combinando varias de las fórmulas tradicionales vistas anteriormente (hora/componente/valor) y añadiendo alguna/s variable/s más:

  • Acuerdo en cada sprint: no hay un presupuesto fijo para todo el proyecto, sino que éste se divide en sprints (de 2 ó 3 semanas como mucho) donde cada uno tiene su propia estimación.
    Esto permite que el desarrollo integre más fácilmente los cambios que van surgiendo durante el proceso, y que la estimación en coste se vaya ajustando a esa realidad cambiante.
  • Semáforo: comentaban en el vídeo un tema interesante como es el de implementar una especie de semáforo en el que tanto cliente como desarrollador pueden ir cambiando a verde (si todo está yendo según lo esperado), amarillo (si existe algún desajuste al que hay que prestar atención) y rojo (si existe un problema grave en el proceso de desarrollo).

¿Presupuesto tradicional o presupuesto ágil?

Como casi siempre la respuesta no es única ni fácil. Hasta ahora, yo me he decantado por el presupuesto tradicional, pero combinando varios factores: horas y componentes.

Difícilmente un presupuesto es exactamente fiel a lo que finalmente sucede en la realidad de un desarrollo web, pero es lo que mejor me ha servido para ajustarlo.

Creo que el futuro está en un mayor acercamiento a las necesidades del cliente, y los presupuestos ágiles pueden ser una ayuda en este sentido, y es probable que empiece a probar su implementación en futuros trabajos.

¿Cómo afrontas tú los presupuestos? ¿Cuál te parece la fórmula más satisfactoria para todos los implicados?

Compartir: 
Come up