Desarrollo de software. Hacia el minimalismo
Si los usuarios no toman responsabilidad sobre los requisitos que solicitan y sobre los cambios que piden, si el equipo de proyecto decide explotar su creatividad cuando no conviene o cuando no interesa y si los responsables técnicos y funcionales no imponen racionalidad a la hora de desarrollar o mantener el software tendremos al final un sistema de información similar a un mando a distancia: lleno de funcionalidades, pero de las cuales solo se utilizarán un 20%.
El objetivo no es llenar un sistema de utilidades que no se van a usar nunca o que su uso vaya a ser residual, el objetivo debe ser que el sistema cuente con las funcionalidades precisas para realizar su actividad, todo lo demás ha sido una pérdida de dinero, de tiempo, que probablemente ha impactado, además, en la calidad de lo que sí resulta necesario y en el coste de la propia evolución del sistema de inforamación.
Pingback: Enlaces de interés: 21/11/2011 | Los Links de Félix
Pingback: Desarrollo de software. Correr con una carga en la espalda « Jummp
Pingback: Desarrollo de software. Tom DeMarco. Timothy R. Lister. Las pérdidas de tiempo « Jummp
Pingback: Desarrollo de software. Antipatrón. Ancla de barco « Jummp
Pingback: Desarrollo de software. Antipatrón. Lava seca « Jummp
Pingback: Desarrollo de software. Antipatrón. Complejidad no indispensable « Jummp
Pingback: Desarrollo de software. Antipatrón. Complejidad no indispensable « Jummp
Pingback: Desarrollo de software. Antipatrón. Funcionalitis acechante « Jummp
Pingback: Desarrollo de software. Antipatrón. Software inflado « Jummp
Pingback: Desarrollo de software. Antipatrón. Los arquitectos no programan « Jummp