archivo

Archivos diarios: diciembre 8, 2011

El ciclo de vida en cascada tiene como consecuencia que las primeras versiones utilizables del producto software se dilaten en exceso en el tiempo. El mismo problema lo podemos tener en enfoques iterativos e incrementales si se tarda en tener una primera versión operativa de algún módulo o componente del sistema (más allá de los esqueletos andantes).

Cuanto menos tiempo pase en que el usuario (o el cliente) empiecen a ver el resultado de los trabajos, mejor, ya que no pierden el enfoque en el proyecto. Cuanto menos tiempo pase en obtener su feedback, más pronto se podrá tener un producto acorde a sus expectativas.

Sun Tzu, pensaba algo parecido: “Una victoria rápida es el principal objetivo de la guerra. Si la victoria tarda en llegar, las armas pierden el filo y la moral decae. Si las tropas atacan ciudades, su fuerza se desgasta. Cuando un ejército se implica en una campaña prolongada, los recursos del estado disminuyen rápidamente”.

Una de las causas que puede dar lugar al fracaso en un proyecto de desarrollo de software consiste en no dedicar tiempo a hacer una evaluación o gestión inicial del riesgo. Afrontar un trabajo sin tener en cuenta ese factor te puede meter en un campo minado, cuando lo mismo se podía haber elegido otro camino o, por lo menos, si se adivinan los problemas que puede haber, tienes recursos para intentar salir con éxito del mismo.

Otra de las causas y sobre la que he escrito bastantes artículos, consiste en evitar no solo Death March Projects, que digamos que son la situación extrema, sino en establecer unas condiciones de partida que proporcionen un contexto a partir del cual un proyecto tenga posibilidades de ser ejecutado con éxito (presupuesto y plazos adecuados, stakeholders implicados de verdad, conocimiento y reconocimiento de la estrategia y/o metodología que se va a seguir para realizar el proyecto, etc…).

Una cita de Sun Tzu que complementa a otra de este mismo y sobre la que ya he tratado en el artículo: “Sun Tzu. El proyecto y las condiciones necesarias para la victoria“, es la siguiente: “Si las estimaciones realizadas antes de la batalla indican victoria, es porque los cálculos cuidadosamente realizados muestran que tus condiciones son más favorables que las condiciones del enemigo; si indican derrota, es porque muestran que las condiciones favorables para la batalla son menores. Con una evaluación cuidadosa, uno puede vencer; sin ella, no puede. Muchas menos oportunidades de victoria tendrá aquel que no realiza cálculos en absoluto”.

¿Cuál es el precio de la calidad del software? Resulta complicado ponerle un valor a algo que para cada uno tiene un significado diferente. Para mi la calidad del software puede significar una cosa y para ti otra y probablemente ambos tengamos razón.

Sin embargo, probablemente estaremos de acuerdo en que la calidad estará muy relacionada con el cumplimiento de las expectativas del usuario (y ese aspecto está por encima de la ejecución técnica del desarrollo), con el hecho de que su deuda técnica y mantenibilidad (estos aspectos sí que son puramente técnicos) superen un umbral acorde al presupuesto del proyecto, los plazos y todas las contingencias que se han producido en su desarrollo y también estará relacionada a la cantidad de errores críticos o bloqueantes que lleguen a producción.

También estaremos de acuerdo en que la calidad requiere método o proceso, que podrá ser más artesanal o más reglado, pero método o proceso al fin y al cabo. Requerirá iterar versiones en las cuales el feedback del usuario permitirá ir adaptándolo cada vez más a sus expectativas. También requerirá de un equipo de proyecto experimentado (por lo menos en número suficiente) que crea en la calidad del software, que tenga el enfoque en ese objetivo y no en simplemente quitarse el marrón lo antes posible.

La calidad vale dinero, sin embargo su ausencia o su falta vale mucho más.

Sobre este aspecto, la siguiente reflexión de Tom de Marco y Tim Lister resulta muy esclarecedora: “La calidad es gratis pero solo para aquellos que están dispuestos a pagar un precio muy alto por ella”.

Comenta un desarrollador con mucha más experiencia que yo que la aplicación debe entrarle por el ojo al usuario ya que de lo contrario manifestará rechazo desde el primer momento y será complicado hacerle cambiar de opinión. Si nos ponemos a pensar ejemplos, no está muy lejos de la realidad, ya que en las aplicaciones para smartphones los primeros segundos o minutos de uso de las mismas determinarán el éxito que tendrán las mismas en nuestro terminal.

No se trata exclusivamente de interfaces de usuario, sino también de la dinámica o lógica de funcionamiento de la misma. En resumidas cuentas, se trata de la usabilidad.

En la usabilidad hay buenas prácticas, sin embargo, hay que tener en cuenta un factor importante y que influye mucho a la hora de que un usuario exprese rechazo o no en primera instancia al sistema y no es otra que el tipo de aplicación o sistema que venía utilizando hasta ahora, ya que será la referencia con la que van a comparar el nuevo sistema.

Me he encontrado con casos donde los usuarios ponen por las nubes, sistemas que meses antes pisoteaban. Y no ha sido necesariamente porque el nuevo sistema empeore al anterior, sino porque les ha cambiado la rutina con que hacían sus tareas y existe otra nueva.

Los criterios de usabilidad son importantes, sin embargo, al final la práctica con el uso de la herramienta es la que rompe determinadas barreras que la propia aplicación ha puesto al usuario, ya lo dice la siguiente cita: “con suficiente práctica, cualquier interfaz es intuitiva”.