En esta sesión me gustaría exponer dos maneras de gestionar un proyecto: agilismo y predictivo. Dentro de estas dos maneras de trabajar, es imprescindible plantear el cómo realizar presupuestos, ya que estos pueden implicar que la relación con el cliente sea fluida y que el proyecto sea un éxito, o por el contrario, encontrarnos en un callejón sin salida con un proyecto sobredimensionado y mal pagado. Hablaré sobre las diferentes formas de hacer presupuestos, algunos consejos prácticos, así como dar importancia a la responsabilidad que tenemos al firmar un acuerdo.

1. Contratos y presupuestos en proyectos Drupal
Drupal Camp Spain Valencia 2014
Siddharta Navarro – 17/06/2014

2. Pequeña BIO
Me llamo Siddharta Navarro y soy el co-fundador de Atenea
tech, una Drupal Shop basada en Barcelona.
• Empresa creada en 2007
• 5 desarrolladores y 1 diseñador
• 60+ proyectos desarrollado con Drupal
• 1500+ horas de consultoría
• 10+ Cursos de formación Drupal
www.ateneatech.com

3. ¿Cómo podemos definir un proyecto?
• Metodología de gestión de proyecto
• Forma de pago y entregas
• Tipos de contrato
www.ateneatech.com

4. ¿Qué metodologías de gestión de proyecto existen?
• Agile (SCRUM)
• Clásica (Cascada)
• Otras.. Derivadas de las dos anteriores
www.ateneatech.com

5. Características
• Requisitos pueden cambiar (muy flexible)
• Sprints
• Aumentar el valor en cada Sprint
www.ateneatech.com
Agile (SCRUM)

6. Ventajas
• Flexibilidad
• Producto adaptado a la realidad del cliente
• Los resultados pueden ser inmediatos –sobretodo con
Drupal-
www.ateneatech.com
Agile (SCRUM)

7. Inconvenientes
• No conocemos con exactitud cual será el
resultado final
• No conocemos la duración final del proyecto
• No conocemos el coste total del proyecto
www.ateneatech.com
Agile (SCRUM)

8. Características
• Requisitos claros
• Planificación del proyecto desde el inicio
www.ateneatech.com
Clásico (cascada)

9. Ventajas
• El resultado está claramente definido
• Podemos conocer los costes finales
• Podemos predecir el tiempo de desarrollo con exactitud
• Como desarrolladores tenemos más control sobre el
proyecto
www.ateneatech.com
Clásico (cascada)

10. Inconvenientes
• Menos flexibilidad
• Mucho tiempo dedicado a la planificación del proyecto
• El resultado final quizás no es lo que el cliente esperaba
www.ateneatech.com
Clásico (cascada)

11. www.ateneatech.com
Agile vs Clásico

12. ¿Qué formas de pago existen?
• Precio fijado para la realización de un proyecto
• Precio por hora / iteración
www.ateneatech.com

13. ¿Qué tipos de contrato existen?
• Contrato clásico con un precio fijo marcado
• Contrato basado en tiempo
• Ninguno!
www.ateneatech.com

14. Características
• Resultado final está claramente definido
• Cualquier funcionalidad extra supone un sobrecoste
• Tenemos seguridad ya que el precio y el resultado está
definido
• Podemos tener conflictos debido a los cambios en los
requisitos
www.ateneatech.com
Contrato con precio fijo

15. Características
• Sólo trabajamos el tiempo contratado
• No podemos asegurar ningún resultado
• El cliente contrata un equipo de desarrollo para realizar su
idea
• El cliente tiene dudas ya que no sabe si su proyecto se
llevará a cabo en un tiempo determinado
www.ateneatech.com
Contrato basado en tiempo

16. www.ateneatech.com
Variantes
Precio fijo Clásico
Ágil
Precio por hora
/ iteración

17. www.ateneatech.com
Precio fijo Clásico
Cliente: Presupuesto fijo
Proveedor: Proyecto bien
planificado y con opciones
reales de cobrar al finalizar
el desarrollo.
Desarrollar un producto bien definido con un tiempo y un
presupuesto fijo
Cliente: Mucho esfuerzo
dedicado a la planificación del
proyecto. No hay posibilidad de
cambios ni flexibilidad en el
desarrollo.
Proveedor: Mucho riesgo si no
se hace una especificación muy
específica.

18. Ágil
Precio por hora
/ iteración
www.ateneatech.com
Desarrollar un producto “ideal” respetando los posible
futuros cambios durante el desarrollo
Cliente: Puede realizar cambios
durante el desarrollo. El producto
final será más parecido a lo que
él tiene en mente.
Proveedor: Tiene la seguridad de
que cobra todas las horas que
trabaja en el proyecto
Cliente: No sabe cuánto le
costará su proyecto.
Proveedor: En cuanto a
planificación, no sabe cuantas
iteraciones va a durar el
proyecto.

19. www.ateneatech.com
Precio fijo
Ágil
Los cambios están
incluidos en el precio
fijo.

20. www.ateneatech.com
Precio fijo
Ágil
¿Cuándo se acaba el proyecto y cobramos?
El proveedor acepta hacer cualquier cosa que el cliente
necesite tanto tiempo como el cliente desee..

21. www.ateneatech.com
Precio fijo
Ágil

22. www.ateneatech.com
Precio fijo
Ágil

23. www.ateneatech.com
Precio fijo
Ágil
Aunque parezca imposible,
es POSIBLE realizar este
tipo de contratos siendo algo
positivo para ambas partes.

24. www.ateneatech.com
Precio fijo
Ágil
¿Cómo funciona?
Requisitos con estimaciones pueden ser cambiados por
requisitos con la misma estimación

25. www.ateneatech.com
Precio fijo
Ágil
¿Qué necesitamos?
Requisitos bien planificados y estimaciones para poder
intercambiar funcionalidades con la misma estimación.

26. www.ateneatech.com
Precio fijo
Ágil
• Somos flexibles en la
priorización de tareas
• Tenemos un precio
fijado para un conjunto
de funcionalidades a
realizar.
• Es necesaria una
especificación
detallada
• Cambios de requisitos
sólo con el acuerdo de
ambas partes

27. www.ateneatech.com
Clásico
Precio por hora
/ iteración

28. www.ateneatech.com
Conclusiones y
recomendaciones
• Precio fijo = Requisitos claros y específicos
• Es importante especificar pruebas de aceptación
• Dejar claro cómo proceder en el caso de cambios de
funcionalidades en el proyecto
• Incluir en el contrato los procesos de gestión utilizados
en el desarrollo

29. www.ateneatech.com
Errores comunes
• “No necesitamos un contrato”
• “Te pagaremos una vez nos hayas entregado el
proyecto”
• “El diseño te lo daremos posteriormente”
• “No pagamos nada por adelantado”

30. www.ateneatech.com
Casos reales
• Trabajo por horas, pero al realizar muchas horas querer pasar a
precio fijo.
• Cambios de funcionalidades manteniendo el mismo precio y tiempo
de entrega.
• Intentar pagar el 100% una vez se haya realizado todo el proyecto.
• Ofrecer ser socio del proyecto a cambio del desarrollo –pero sólo el
1er año-.
• Aceptar que el proyecto sea flexible en cuanto a funcionalidad pero
no en cuanto al número de horas.
Es mejor sacar todos los problemas al principio, antes de empezar. A la
mínima hay que plantarse.

31. Y ahora, como buenos hermanos...
Os invito a compartir vuestras batallitas.
www.ateneatech.com