El blog de ASPgems

Siguiendo el día a día de ASPgems

La paradoja de las horas hombre y los proyectos cerrados

La paradoja de las horas hombre y los proyectos cerrados

Siempre que doy una charla sobre como hacer un proyecto de tecnología cuento lo que aprendí en la universidad hace muchos años:

“Hacer un proyecto en plazo y coste es tan fácil como andar sobre el agua, siempre y cuando me dejes poner una condición: el agua y las especificaciones del proyecto deben estar congeladas”.

Con este modelo mental muchos, pero muchos, clientes se aproximan a empresas como nosotros con una especificación que parece congelada, pero que nunca lo está de verdad. Y además, aunque lo estuviera, el proyecto va cambiar por el camino, pero eso es otra historia…

Con la especificación aparentemente cerrada el cliente espera de nosotros un precio y un plazo de entrega, como no hay una relación de confianza entre el cliente y el equipo (la confianza no está de moda ;-) ), los procesos de compras piden a los equipos que detallen las horas de trabajo que se van a dedicar a un proyecto, así como los curricula de los desarrolladores que van a trabajar en el proyecto.  Es decir, el cliente contrata un proyecto cerrado, pero espera los detalles como si lo que contratase fuera un servicio con un número de horas y personas dedicadas al mismo.

Aunque me ha tocado aceptar esta práctica del sector, al fin y al cabo no se puede luchar contra todo el mercado, es una práctica que esconde una inconsistencia:

Si el proyecto está bien especificado, y el equipo le ha dado un precio, a ti como cliente te debería dar igual si yo lo hago en 10 o 1000 horas, y solo debería preocuparte que el proyecto que entrego cumpla las especificaciones.

Pero claro, como el cliente (y también el proveedor) saben que las especificaciones no están cerradas, ambos saben que el proyecto acabará con una negociación sobre lo que estaba o no estaba incluido en las especificaciones, y para esa negociación a ambas partes les interesa tener una medida del presupuesto con conversaciones del tipo:

  • El cliente dirá que ya sabe que esto no estaba incluido, pero te quedan horas porque la propuesta incluía X horas.

  • El proveedor dirá que no puede hacer esto que estaba incluido porque se le han ido las horas en hacer aquella funcionalidad que no estaba prevista, o porque la especificación de tal otra funcionalidad no incluía una opción que hubo que hacer y era demasiado complicada.

Yo no lo entiendo. No entiendo quién sale beneficiado de todo esto, porque esto acaba en proyectos mal ejecutados, en los que al final el criterio fundamental de compra no es la aportación de valor, sino únicamente el precio por hora.

Nosotros pensamos que las especificaciones nunca están cerradas, que por tanto el proyecto debe abordarse fijando en primer lugar la fecha de entrega, luego el presupuesto de horas disponible y durante el proyecto gestionar el alcance funcional.

Añadir nuevo comentario

Desarrollo con Drupal

Desarrollo con Drupal
Equipo de desarrollo de drupal 7 y drupal 8.

Desarrollo en Ruby on Rails

Desarrollo en Ruby on Rails
Más de 8 años de experiencia en Rails.

Desarrollo Web

Desarrollo Web
Co-creamos con nuestros clientes las mejores soluciones ágiles.

Etiquetas

Artículos relacionados

Nuestra revista

View my Flipboard Magazine