Un Buen Proyecto (2)

Anterior Post 
Siguiente Post 


Ya tratamos el principal tema que nuestro proyecto tiene que cumplir para ser un buen proyecto: solucionar el problema al cliente. Puede que sea sólo un colaborador, entre otros proyectos, para llegar a esa solución. Por ejemplo, me pasa muchas veces que el proyecto que me toca es de programación de una aplicación, pero la solución total del problema implica su instalación, mantenimiento y adopción. Otras veces no: nuestro proyecto abarca toda su ciclo de vida, por lo menos de la primer versión.


Puede suceder algo que muchas veces se nos pasa por alto:


- No podemos estar seguros de que lo que entregamos es un buen proyecto al terminarlo y entregarlo.


Hay que ver si realmente funciona en el campo, en la vida real.


Pongamos un ejemplo. Sea nuestro cliente es una compañía de seguros y su problema es que está perdiendo clientes porque los productores de seguros tardan mucho en otorgarle una póliza o no. La solución evaluada es: poner una aplicación en línea que reduzca el tiempo de aceptación o rechazo de un día a quince minutos. Hacemos la aplicación, pero al llegar a desplegarse y ser usado se muere cada media hora por la presión de uso, y la causa es el código de nuestro proyecto. O peor, trabaja bien, soporta la carga, pero otorga aceptaciones a cualquier caso. En ambos casos, nuestro proyecto no habrá sido un “buen proyecto”.


Es por eso que en nuestro proceso es importante las pruebas de carga y las pruebas funcionales. A lo que voy, es que muchas de las actividades que realizamos terminan teniendo su origen en la necesidad de cumplir con ser un buen proyecto. Un proyecto puede parecer “bueno”: tener todo “en regla”, haber sido programado con todos los patrones, ante las entradas correctas dar el resultado correcto, pero fracasar en su implementación porque no revisamos que, así como lo tenemos programado, no soporta más de diez usuarios simultáneos.


Aparece la cuestión de la calidad de nuestro entregable. Podemos discutir luego si la calidad es responsabilidad del equipo ágil, o si hace falta un equipo aparte de QA (Quality Assurance). Pero vemos que todo esto es motivado por la necesidad de cumplir con lo que espera el cliente: la solución de su problema.


Para poner un ejemplo “al revés”: al cliente no le importa que lo que entregamos sea escalable como Facebook, si su problema y solución (digamos, un sistema de compras) necesita solamente atender a veinte usuarios (los representantes de sus proveedores principales).


En próximos posts: si una solución es exitosa, hay que mantenerla; el aporte de TDD y el proceso de desarrollo.


Nota personal: lo de no poder ver si es un buen proyecto al terminarlo, me fue sugerido por Aristóteles. No encuentro la cita ahora, pero cuando habla de “eudamonia” en su “Etica a Nicómaco”, habla de lo que yo traduzco como “buena vida”, “con los dioses a favor”. Dice Aristóteles que muchas veces, un hombre al morir no puede estar seguro de haber llegado a la “buena vida”: puede que el resultado dependa de su influencia en otros hombres, aún luego de su muerte. (me temo que Aristóteles hablaba de “hombres”, ciudadanos con derechos, y no de “seres humanos”; mujeres abstenerse, era el Borat de los filósofos ;-).


Nos leemos!


Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 10549, 3463. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>