Blogalia

"En el arte marcial como en la vida diaria. En la vida diaria como en un arte marcial."

Aikido

Sígueme en Twitter

<Junio 2017
Lu Ma Mi Ju Vi Sa Do
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
             


Todas las Historias

VELOCIDAD DE ESCAPE

Inicio > Historias > ANATOMÍA DE UN FRACASO

2004-12-01

ANATOMÍA DE UN FRACASO

Excelente artículo de WillyDev (en PDF) titulado

"PORQUÉ LOS PROYECTOS DE DESARROLLO INFORMÁTICO SE CONVIERTEN EN UNA PESADILLA? ANATOMÍA DE UN FRACASO"

De lectura obligada si sois responsables de gestionar, diseñar o analizar proyectos de software.

En mi caso me he sorprendido porque el enfoque propuesto ("Diseño del programa en función del Modelo de Usuario") es el que he aplicado siempre que hago un análisis o genero un nuevo programa.

De mi trabajo en la consultora junto a psicólogos y gente de semejante ralea me quedó muy claro que una cosa es lo que el programador piensa sobre una aplicación y otra cosa muy distinta es lo que el usuario tiene en mente cuando piensa sobre la misma aplicación. Y desde entonces programo según el modelo mental del usuario. Hacedlo así y ahorraréis quebraderos de cabeza.

No uso UML(aunque lo conozca) ni avanzadas herramientas conceptuales de este tenor, sino que cuando tengo que hacer un programa me voy a hablar directamente con la gente que lo va a usar y vamos definiendo las pantallas una a una. Ojo, hablar con el que lo va a usar, no con el jefe del departamento que lo va a usar.

Programación | jomaweb | 5 Comentarios | Enlace


Referencias (TrackBacks)

URL de trackback de esta historia http://jomaweb.blogalia.com//trackbacks/23825

Comentarios

1
De: jomaweb Fecha: 2004-12-01 15:01

Dado que el usuario que trabaja con el programa conoce sus debilidades y puntos mejorables, es la mejor opción.
Y como dice el artículo: he programado aplicaciones enteras de nuevo para evitar revisar el código de otros y adaptar la aplicación al modelo mental del usuario.

Os lo recomiendo.



2
De: F Fecha: 2004-12-01 16:45

acabo de tener una experiencia muy frustrante al respecto, pero claro, yo solo soy el programador. hice el programa (avise mas de una vez "esto quien lo va a usar", mi jefe decia "ellos lo quieren asi"), cuando fuimos a instalarlo los operarios ni siquiera sabian de su existencia... ni que decir tiene que, literalmente, "no les servia para nada".



3
De: mig21 Fecha: 2004-12-01 16:50

Bueno.... yo creo que una metodología basada (solo) en el "diseño" y el "modelo conceptual" va también directa al fracaso.

Tan importante es saber lo que el usuario quiere como escribir el código que el usuario quiere (pero no sabe que quiere)

Escribir un "modelo conceptual" completo sin escribir una sola linea de código me parece igual de desastroso que lo contrario.
Además dicho "modelo conceptual" maravilloso se verá transformado seguramente por cualquier modificación por "trivial" que parezca.

Desde mi punto de vista hay que tener un modelo, pero hay que convertirlo rápidamente en algo que vaya funcionando y que vaya encajando con las piezas restantes. Y hay que codificarlo sabiendo que va a sufrir cambios. Y hay que estar testeando periodicamente si lo que "comienza a funcionar" se parece en algo a lo que esperan los que lo van a usar...

Pero esa es mi opinión :)

Saludos



4
De: jomaweb Fecha: 2004-12-01 17:25

Claro, no todo es centrarse en el diseño. Lo que creo es que el diseño de la aplicación debe superar con creces el desarrollo de la misma. Y si ese diseño está dirigido por la experiencia de usuario pantalla por pantalla, mejor que mejor.

El modelo de programación, el entorno, las herramientas, las bases de datos, la arquitectura que usemos, y hasta el lenguaje es ya decisión nuestra.
Aquí es donde entra la OOP, el UML, los Patrones, y todo lo que quieras.

Sólo hice una vez un programa diseñado desde dirección con unos requisitos específicos muy claritos, muy útil y muy bonito en el papel....

Os puedo asegurar que lo usaron una sola vez (tras la presentación) y lleva dos años implementado sin que nadie lo haya vuelto a tocar ni siquiera por lástima.



5
De: Jose Fecha: 2004-12-03 09:24

Voy a cambiar el tercio de los comentario. Creo que la mejor idea del texto es la forma de calcular el tiempo total de duración del proyecto y que "features" entran al final dentro del programa final y cuales se quedan fuera. La situación que describen en el artículo es real; en mi trabajo (analista, no programador) cuando terminamos un diseño esperamos a que los programadores nos digan el tiempo que van a tardar en realizar cada "feature" del mismo. La forma de calcular esos tiempos se parece mucho a lo que indica el autor del artículo: me gusta esta "feature", creo que sirver, pongo poco tiempo, no me gusta, no la entiendo (¿porqué pedirán esto, tan raro?) dura más tiempo. La clave esta en tener claro que el programador debe hacer lo que el usuario quiere, no lo que él cree que es lo mejor. Mi problema es que he estado en las dos partes de la barrera (de hecho sigo estándolo en otro trabajo, donde soy más bien programador) y reconozco que es la forma mental de trabajar el programador. Luego la solución, no es tanto hacer un diseño completo antes de pasar a codificar, como tener claras las "features" imprescindibles y que éstas deben incorporarse a pesar de lo que diga el programador.
Termino con un ejemplo, en el proyecto más grande que dirigí no conseguía que los programadores me incluyesen unos módulos que estaban pensados para reducir en más de 10 minutos por operación el tiempo que el usuario necesitaba para completar una tarea (tarea que por cierto se realizaba más de 500 veces al día entre todas las Oficinas de la empresa). Por más reuniones que teníamos los programadores decían que aquello era muy difícil, que las bases de datos no lo soportarían... hasta que un día, sin avisar veo el módulo que esta en preproducción ¡¡¡; pregunto y al final me entero, que el programador jefe del proyecto había estado el fin de semana anterior comiendo con su hermano (que trabaja en como usuario en la estructura comercial) y que éste último le había dicho el tiempo que perdían porque la aplicación no tenía esa "feature", así que la programó. Durante los siguentes meses me dedique a enviar los análisis antes al hermano del programador. Eso es lo que no se puede consentir.



Nombre
Correo-e
URL
Dirección IP: 23.20.130.128 (e24f3034b4)
Comentario