Existe una concepción general entre muchos usuarios y clientes comerciales de que cuando parece completa, está casi completa. Como probablemente sepa, esto está lejos de la verdad. Uno puede hacer que se vea bien, pero sin backend y algunos usuarios piensan que hacer que se vea bien es el 80% del trabajo, no el 20% ( o el otro 80% ).
Innumerables desarrolladores pueden contar historias de horror sobre esto: obtener una maqueta de las páginas en Microsoft Word utilizando capturas de pantalla de alguna otra herramienta, y el cliente dice "¿casi lo has hecho?"
Debe ajustar el ritmo para que todas las partes estén listas cuando esté hecho. Intentar hacer todo el backend primero y luego todo el front end hará que el usuario final piense que no está haciendo nada y le pregunte por qué le pagan cuando no hay nada que mostrar. Por otro lado, el front end primero y encontrará al usuario final haciendo cambios insignificantes y consumiendo todo nuestro tiempo.
El peor de los casos con un 'uno primero y el otro' es cuando llegas a la otra parte, descubres que no encaja en absoluto con el diseño.
Por lo tanto, construye ambos. Muestre el progreso en el front-end, haga que el back-end funcione con lo que está construyendo. En muchos casos, es una buena idea entregar compilaciones incrementales y asegurarse de que está haciendo lo que el cliente quiere (esto entra en Ágil). Pasar demasiado tiempo sin 'avances visibles' puede dañar la relación con el cliente (esto es para ambos casos de 'todo parece hecho temprano' y 'nada se hace hasta el final' - es difícil para el cliente ver que se está escribiendo el marco o las pruebas unitarias o la desinfección de datos como progreso).
Joel escribió sobre esto en The Iceberg Secret, Revealed :
Corolario importante dos. Si le muestra a un no programador una pantalla que tiene una interfaz de usuario que es 100% hermosa, pensarán que el programa está casi listo.
Las personas que no son programadores solo están mirando la pantalla y viendo algunos píxeles. Y si parece que los píxeles forman un programa que hace algo, piensan "oh, Dios, ¿cuánto más difícil podría ser hacer que realmente funcione?"
El gran riesgo aquí es que si se burla primero de la interfaz de usuario, presumiblemente para poder mantener algunas conversaciones con el cliente, entonces todo el mundo pensará que ya casi ha terminado. Y luego, cuando pasas el próximo año trabajando "encubierto", por así decirlo, nadie verá realmente lo que estás haciendo y pensarán que no es nada.
Esto se reitera nuevamente en la publicación del blog No haga que la demostración se vea Listo, que tiene este útil gráfico:
Tenga en cuenta que las dos opciones generalmente reflejan el "hacer la interfaz de usuario" (y luego la expectativa es que terminará pronto) y "hacer el backend" (y luego el cliente está preocupado de que no cumpla con la fecha límite).
Cómo se ve "hecho" algo debe coincidir con cómo se "hace" algo.
Cada desarrollador de software ha experimentado esto muchas veces en su carrera. Pero las herramientas de publicación de escritorio generan el mismo dolor de cabeza para los escritores de tecnología: si le muestra a alguien un borrador que está perfectamente redactado y formateado, lo ven como más hecho de lo que desea. Necesitamos una coincidencia entre dónde estamos y dónde otros perciben que estamos.
Este artículo también presenta un punto importante sobre el tipo de comentarios que recibe con diferentes niveles de cocción de la interfaz de usuario. Si tiene algo que parece completo, es más probable que reciba comentarios acerca de "¿podría cambiar la fuente" que "este diseño no funciona? Hay demasiadas pestañas".
Para aquellos que luchan con esto en el mundo de Java Swing, hay un aspecto llamado Napkin que hace que la interfaz de usuario no se vea completa (incluso si lo es).
La clave aquí es hacerlo para que no parezca hecho. Hacer que la interfaz de usuario se vea completa es una señal para muchos usuarios comerciales de que la aplicación está completa (incluso si son solo unas pocas páginas estáticas sin ninguna lógica detrás o algo integrado en un generador de interfaces).
Lecturas adicionales (y enlaces del artículo):
