Casi todos los proyectos, las ofertas, las reuniones iniciales de desarrollo software comienzan con la típica y clásica pregunta de “-¿Esto cuánto va a costar?-“ Pero, quizá, como cada vez estamos debatiendo más, pensemos un momento si la pregunta correcta no debería ser… “-¿De cuándo presupuesto dispones?-“.
Este debate es una vuelta de tuerca más al problema de buscar requisitos cerrados en etapas del proyecto demasiado tempranas, para buscar, entre otros, una estimación de tiempo – dinero inamovible y exacta (recuerda que tienes pocas probabilidades de estimar un proyecto software con una fecha… y acertar al 100%). Inamovible en un momento tan temprano que esos requisitos, base de todo este modelo de gestión de proyectos, probablemente estarán inacabados o cambiarán, pero el tiempo y el dinero previsto serán “inamovibles”. Todo ello es una de las combinaciones explosivas que más daño ha hecho (hace) al sector des desarrollo software.
La anterior manera de trabajar es la típica, un clásico, ya hablamos de ello en contrato cerrado, ¿el peor enemigo del software o mal necesario? (esto te interesa mucho, más que cualquier cosa en la ingeniería software) y en ¿Tiene sentido estimar? Quizá no deberíamos estimar proyectos #NoEstimates explicado
Pero, aunque te suene a ciencia ficción, imaginemos por un momento otro escenario, arriésgate a pensar durante unos minutos de otra manera (total esto es un post, cuando lo termines de leer ya tendrás tiempo de volver a la realidad, al verdadero y duro día a día) démosle la vuelta a la situación, pensemos algo más ágil.
Frente a exigir una fecha inamovible de finalización, lo que a ti cliente te implica cerrar unos requisitos para que un equipo de desarrollo estime tiempo y dinero, lo que te implica a su vez que lo que te van a entregar es lo que pusiste en esos requisitos, te guste o no, faltasen cosas o no, cambies de opinión con el tiempo o no… ¿por qué no te liberas de las cadenas de la estimación, que te obligan a encadenarte a requisitos cerrados, que frenan que puedas cambiar requisitos a lo largo del proyecto y… pones un presupuesto?
Dado un presupuesto, es decir, el dinero que tienes para invertir en ese proyecto software, obtén el compromiso del equipo de desarrollo de hacer el máximo (y bien) en el tiempo que te de ese presupuesto, y gánate la alegría de poder modificar los requisitos a lo largo del proyecto (al final de ciertos periodos de tiempo, al final de cada iteración).
“-Es que si trabajo con un presupuesto me van a engañar, ya que los de desarrollo van a trabajar más despacio para intentar alargar el tiempo-”.
Si vienes y o vives en el mundo clásico sé que puedes estar pensando: “-Es que si trabajo con un presupuesto me van a engañar, ya que los de desarrollo van a trabajar más despacio para intentar alargar el tiempo-”.
Existiendo el riesgo anterior, pon en la balanza si prefieres cerrar requisitos y tiempo, obteniendo al finalizar tu proyecto un alto porcentaje de funcionalidades que no quieres o no valen (esas de las que según avanzaba el proyecto te fuiste dando cuenta de que eran incorrectas, o faltaban, pero que el modelo requisitos cerrados no te permitió cambiar), un software malo (funcionalmente y en calidad interna, ya que cerrar fechas imposibles lleva a software malo que te va a costar a ti cliente la vida el tener que mantenerlo en el futuro), o si quieres correr el riesgo de tener un 100% de funcionalidades correctas, las que realmente necesitabas, si bien el equipo de desarrollo podría haberme desarrollado algunas más.
Pero incluso te voy a decir mas, ¿y si trabajas por presupuestos, te llevas el regalo de poder modificar requisitos según avanza el proyecto, de poder así hacer software con la funcionalidad que realmente se necesita en vez de la que ponía en un papel y, además, trabajas con un buen equipo de desarrollo bueno, que no te va a engañar? (Customer collaboration over contract negotiation)
Sí claro, a lo mejor te toca dejar de trabajar con esos proveedores de software de toda la vida, esos gigantes, y buscar equipos de desarrollo de calidad, más que comerciales que te prometan todo lo que quieres oír y que luego te entregarán lo que se pueda.
“-Es que si trabajo con un presupuesto no se cuanto tiempo van a tardar-”
Sí, sí, si vienes y o vives en el mundo clásico sé que puedes estar pensando: “-Es que si trabajo con un presupuesto no se cuanto tiempo van a tardar-”. Desde luego que si te llevas el regalo de ir cambiendo requisitos, sino está claro que hay que hacer porque se descubre según avanza el proyecto, estará poco claro cuándo se va a terminar.
¿Te crees que con requisitos cerrados sabías seguro cuándo se va a terminar?
Y, no obstante, en la realidad si que vas a tener una previsión de finalización ya que vas a ir viendo los requisitos que el equipo va complentando por periodo de tiempo, lo que te dará lo que llamamos la media de velocidad, que te valdrá para hacer previsiones de finalización.
Piensa lo que quieres, necesitas y por lo que pagas
Piénsalo, porque pasar de estimación a presupuesto puede cambiar tu empresa, la competitividad de tu negocio, que se basa en software, te puede disparar frente a la competencia, si te valen las razones de responsabilidad social, puede ayudar ostensiblemente a mejorar el maltrecho sector del desarrollo software (poniendo calidad por encima de promesas comerciales), etc.
Y si tu no lo haces, “-Porque ya sabes Javier, esta empresa trabaja así de siempre, aquí las cosas no son fáciles de cambiar-“, no te preocupes que en breve, si no lo hizo ya, alguien de la competencia lo hará.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Hola Javier, me gustaría saber como es el proceso para trabajar con un presupuesto. De repente en un post podrías explicar un poco como funciona ese método porque me parece muy interesante el enfoque.
Saludos
Ok, a ver si en un siguiente seguimos profundizando en el tema.
Javier me gustaría saber mas de como es el trabajo por presupuesto, esta muy interesante