De todas formas lo más importante son las personas, si pones gente incompetente tendrás un churro de producto o servicio. La metodología es importante pero no tanto como gente que sepa de qué va la vaina.
En eso estoy completamente de acuerdo: sin personas competentes no hay posibilidad de viabilidad alguna.
Aún así, he visto alguna vez la sensación de frustración y de hastío en gente muy válida cuando ha desarrollado la mejor de las soluciones posibles a un problema concreto, ajustándose perfectamente a las especificaciones dadas, y tiene que volver a rehacer la funcionalidad porque el problema viene de que esas especificaciones se establecieron antes de que el cliente conociera el software.
La jovenlandesal también hace mucho, como en cualquier trabajo. Y no hay nada que toque más las narices a un desarrollador eficiente que tener que rehacer un trabajo que estaba bien hecho por motivos ajenos a su trabajo...
Como a cualquier creador o artesano (por decirlo de alguna forma...), al desarrollador también le da seguridad, confianza y ánimos ver que el proyecto va avanzando. Y por tanto le suele dar asquito volver una y otra vez a partes del proyecto que ya daba por zanjadas.
---------- Post added 13-feb-2016 at 12:13 ----------
L
En el último proyecto rellenito del que tengo noticia, se estuvo un par de años con ux, maqueta, después en unos meses con distintos equipos, se desarrollo, los tiempos de desarrollo me dejaron con la boca abierta.
Ya te he comentado que me parece una estupendísisima idea que el cliente pueda 'ver' como será el programa, y una forma de evitar rehacer un código ya hecho.
Pero veo un inconveniente en hacer toda la parte visual de un proyecto medianamente grande y luego hacer el desarrollo 'de tirón'.
Que el cliente comprenda cómo será el flujo evita muchos, muchísimos problemas. Pero no olvidemos que eso no significa que lo esté usando.
Mi concepto (al menos el que tengo en la cabeza, aún estoy desarrollándolo, jeje...) es que hubiera un core de funcionalidades mínimas usables, teniendo en cuenta las dependencias, que pueden ser una parte bastante pequeña del software. Dependerá si ese software sustituye a otro, necesite importación, etc etc, el que ese core pueda ser pequeñito o medianamente grande.
Ese core se podría validar mediante los métodos que tu propones, para asegurar el tiro al máximo. Que el cliente pueda hacerse una idea de cómo sería su UX y matizar al máximo su necesidad.
Y entonces, para mi importante, se desarrolla y se libera. Y es el uso constante (no siempre será posible, pero sí en muchos casos...) el que marcará el orden de prioridades siguiente o nuevas necesidades no contempladas.
Si se desarrolla todo del tirón, tener el OK del cliente a una maqueta evita muchos problemas. Pero si el software es bastante amplio, al final puede estar lleno de funcionalidades que se terminarán no utilizando, o carecer de otras importantes que surgen con el uso...
Por eso me parece importante (siempre que se pueda, repito...) que en cuanto haya un mínimo usable el cliente pueda utilizarlo, para a partir de ahí seguir dándole forma con el mismo procedimiento: el cliente establece prioridades, se preparan pantallas para su revisión, etc etc.
