archivo

Archivos diarios: febrero 8, 2013

El impacto de las deficiencias funcionales tiene unas consecuencias similares a los bugs. Estas deficiencias son provocadas por especificaciones incorrectas por parte del área usuaria y/o por una mala interpretación de ellas por parte de los desarrolladores. En el caso de los bugs el peso recae principalmente sobre éstos.

Tanto unas como los otros impactan sobre el producto y sobre el proceso.

Siempre suponen un problema en la implantación de una aplicación, si se sitúan en funcionalidades críticas y/o son muy numerosos el sistema tendrá rechazo por parte del área usuaria y la presión que ejercerán los mismos no ayudará precisamente a crear el clima más adecuado para hacer las correcciones oportunas lo antes posible.

Pero no es solo eso, si la aplicación es crítica se podría poner en riesgo la seguridad de las personas o incluso la propia continuidad de una organización si el mal funcionamiento afecta a sus ingresos (ventas y/o imagen) o a procesos críticos.

En cualquier caso, una sistema que no va bien impacta en la productividad y eso se traduce en dinero que se deja de ganar o que se gasta de más.

El impacto en el proceso de desarrollo es evidente. Puedes tener una planificación a medio/largo plazo o un sprint y quedar devastados por la aparición de estas incidencias, muchas de las cuales requerirán ser corregidas con celeridad.

Recordemos que si aplicamos sprints y nos basamos en prácticas de Scrum tenemos como objetivo cumplir con lo comprometido (otra cosa es que haya causas justificadas que hagan que alguna historia de usuario no se haya podido llevar a cabo), en un contexto inestable por la aparición continua de incidencias es imposible que el equipo pueda coger un ritmo salvo que se apliquen medidas como por ejemplo crear una línea de desarrollo independiente que se encargue de tratar las incidencias que bien podría aplicar sprints, enfoques similares a Kanban o sincronizarse con el sprint de desarrollo cuando éste termine. En cualquier caso, estas medidas tienen un coste.

Ante esta perspectiva resulta no ya una situación aconsejable, sino de verdadera necesidad, minimizar el número de incidencias funcionales y bugs que llegan a producción, intentando que su detección sea lo más temprana posible.

El enfoque clásico y su gestión de proyectos asociada está orientada principalmente a controlar y gestionar las desviaciones en costes y plazos. Es decir, para que el proyecto tenga éxito no solo debe satisfacer las expectativas puestas en el mismo sino que también es necesario que las desviaciones sobre costes y plazos sean mínimas.

Por mucha habilidad que se tenga gestionando estos proyectos, por muy bueno que sea el equipo de proyecto y por muy implicados que estén el resto de stakeholders, si el cálculo inicial de costes y plazos es deficiente no se podrá evitar desviaciones en costes y plazos, además de comprometerse el producto final.

Y lo normal es que ese cálculo inicial sea deficiente porque se realiza valorando un producto que no deja de ser una idea abstracta. La calidad del cálculo de costes y plazos mejorará conforme se vayan conociendo más detalles del sistema a desarrollar por lo que si se quiere gestionar un proyecto siguiendo un enfoque y gestión de proyectos clásica se debería partir de unos requisitos de calidad.

Después se requerirá de un entorno de proyecto estable, sin cambios de contexto, para intentar gestionar adecuadamente la agenda, de lo contrario tocará hacer juegos malabares para intentar minimizar desviaciones en costes, plazos y calidad del producto y cuando esto pasa lo normal es que el proyecto no salga bien.

En mi opinión, lo realmente importante es el valor del producto. No digo que cumplir la agenda no lo sea, pero si las circunstancias golpean (y lo hacen casi siempre), la misma no debe condicionar el valor final del producto. Si no hay posibilidades de varias costes y plazos el producto se resentirá.