Presupuestos y análisis web

Presupuestar un proyecto de desarrollo software es una tarea muy compleja, en la mayoría de los casos diría que se trata de magia¹. Tal y como dicen en Extreme Programming for Web Projects,

¡La estimación es alquimia! No podemos calcular el número de documentos y funcionalidades y simplemente multiplicarlos por algún factor que nos dé una respuesta mágica.

Y no podría estar más de acuerdo. Hay demasiadas variables en juego como para poder hacer una estimación más o menos precisa. Interoperabilidad, accesibilidad, SEO, diseño gráfico, diseño de interfaces, programación en el servidor, programación de interfaces, optimización del código, calidad, seguridad, documentación, gestión del proyecto, etc. Además, distintas personas/equipos pueden trabajar puntualmente juntos en determinadas secciones, como el diseñador gráfico junto con expertos en márketing y usabilidad.

Si bien es cierto que en páginas corporativas sencillas todo el trabajo puede condensarse en pocas horas y es fácil calcular el plazo de entrega, cuando el desarrollo es complejo y requiere de un equipo de personas trabajando en paralelo, el número de horas puede dispararse de forma dramática, arruinando un proyecto, incumpliendo plazos y perdiendo clientes.

¿Entonces cómo se suelen estimar los proyectos? Existen numerosos métodos. Sin embargo, la mayoría de ellos se basan en fórmulas que utilizan como premisa prever el número de líneas de código que tendrá el proyecto, lo cual en mi opinión nos puede llevar a una situación incluso peor. No es lo mismo una línea de código en Perl que en un framework como Ruby on Rails, ni todos los programadores codifican igual. Además, hay muchos factores implicados en la creación de software aparte de la programación.

En mi opinión lo que mejor funciona es conocer de forma precisa todos los hitos semanales del proyecto, y basándonos en un histórico, podremos hacer una estimación bastante más precisa. Pero surge el gran problema: Necesitaríamos un análisis detallado de la aplicación, y cuando hacemos presupuestos tenemos que ser ágiles, no debemos hacer esperar al cliente.

Para explicar el problema utilizaré la clásica analogía de la construcción de edificios. Supongamos que un cliente desea una vivienda, acude al equipo de albañiles y les dice “Quiero algo muy sencillo. Una vivienda con 3 dormitorios, salón y cocina. ¿Por cuánto me saldría?”. Lógicamente le exigirán muchos más detalles. ¿Sobre qué tipo de suelo se trabaja? ¿Qué tipo de construcción quiere? ¿Cuál será la disposición final de las habitaciones? ¿Cuántos baños tendrá? ¿Dónde irán estarán los interruptores? ¿Hace falta conexión telefónica en los dormitorios? ¿Querrán garaje? En definitiva, es necesario que un arquitecto haya definido previamente y de forma precisa todos los detalles de la vivienda.

En el desarrollo web esto prácticamente nunca sucede. Bajo unas sencillas premisas se presupuesta algo tan versatil como una página. Pongamos un ejemplo sencillo: El cliente quiere añadir a su actual página un módulo para añadir noticias que se puedan comentar. Para ello desea que los usuarios se autentiquen. Existen muchas formas de realizar esto. Podríamos crear un usuario maestro que se autenticara mediante HTTP. Otra opción sería tener varios usuarios preestablecidos creados en una base de datos o en un fichero, que ingresaran mediante un formulario HTML y se usara una cookie para manejar sesiones. O bien podría tambien permitirse que cualquier persona se registrara para así poder firmar comentarios con su usuario, y que desde un panel de control el administrador pueda actualizar sus permisos para permitirles poder publicar noticias. Además, se podría añadir confirmación por correo electrónico, códigos de seguridad captcha tras un determinado número de intentos de acceso fallidos, recuperación de contraseña, o numerosos campos que poder rellenar, como localidad, usuario de mensajería instantánea, fecha de último acceso o firma en sus comentarios.

Partiendo de una premisa sencilla hemos llegado a soluciones muy distintas. Es posible definir brevemente estos detalles en el presupuesto, pero en proyectos medianos/grandes nunca llegará a ser suficientemente preciso como para asegurarnos un error en la estimación asumible. Necesitaríamos de un riguroso análisis y diseño previo, para posteriormente realizará la codificación, pruebas e implantación.

De este modo, la creación de proyectos software disfrutarían de una notable mejora en la gestión si se dividiera al menos en dos etapas:

1. Análisis y diseño
2. Codificación, pruebas e implantación.

No sólo sería sano para el sector de desarrollo, sino que nos obligaríamos a seguir un orden, unas pautas de trabajo, que repercutirían notablemente en la calidad del producto, con lo que el cliente estaría mucho más satisfecho.

Cuando una persona quiere construir una vivienda, proporciona a los constructores los planos y detalles de ésta. Cuando el Estado saca a concurso la construcción de un nuevo tramo de autovía, facilita toda la información necesaria de su recorrido y de la calzada de forma precisa. La ingeniería del software es una disciplina aun adolescente. Quizás deba aprender de sus mayores.

---

¹ Aun tengo muy poca experiencia en gestión de desarrollos software. Habré realizado unos 20 presupuestos, y desarrollado unas 12 páginas, la mayoría de ellas poco complejas. Estáis invitados a ponerme a caldo si suelto barbaridades