El enfoque correcto para diseñar una aplicación web (software de diseño, no gráficos)

Question

Recientemente recibí solicitudes de clientes potenciales para aplicaciones web muy complejas.
Querían que escribiera una especificación antes de que comience el trabajo "real".
Las especificaciones, como ven, deberían ser solo palabras que describan la aplicación y DB.
Donde encontré que el mejor enfoque es "pintar" o "construir" un prototipo de las pantallas que la aplicación tendrá (html es más fácil que escribir un libro, especialmente si usa WYSIWYG solo para esta fase ... los estándares no son importante en este punto).

Cuando se tiene una pantalla delante de sus ojos, se hace inmediatamente claro qué elementos deben ser (calendario/foto galerías/qué enlaces principales, cuadro de búsqueda, etc.)

Por lo tanto, estoy mal en mi enfoque? ¿O los clientes están mal informados sobre la forma correcta de hacer las cosas?

Answer 1

Si bien estoy de acuerdo en que necesita tener un amplio acuerdo con respecto al alcance y el costo del sistema que se está construyendo, creo que está aferrado a la idea de que puede especificar completamente un sistema antes de incluirlo en el las manos del cliente. Como ha descubierto, el cliente muchas veces no sabe lo que quiere hasta que realmente lo ve. Una forma de abordar esto es con maquetas, como está acostumbrado a hacer. Los uso también durante el diseño y la planificación.

En la mayoría de los casos, sin embargo, debe obtener el producto real en las manos del cliente para obtener la retroalimentación inevitable sobre lo que funciona y lo que no funciona. Es mejor hacer esto antes que tarde, ya que los cambios que ocurren tarde en el desarrollo son mucho más difíciles y costosos, al menos en los métodos tradicionales. El uso de un método ágil que entrega software en funcionamiento temprano y con frecuencia, junto con suficiente planificación y documentación, mejora la retroalimentación del cliente que iterar sobre montones de especificaciones para un producto que el cliente puede encontrar que no quiere (o al menos quiere forma en que dijeron).

Le sugiero que necesite algunos documentos que describan, en términos generales, el alcance del proyecto. Suficiente para que pueda ponerse de acuerdo sobre qué es parte del sistema y qué no. Si está creando una aplicación de gestión de inventario, no deberían esperar obtener también un sistema de gestión de relaciones con el cliente, por ejemplo. Luego, aplique las técnicas de los métodos de desarrollo ágiles para, de una manera ligera, rastrear la funcionalidad deseada y obtener un código de trabajo en sus manos tan pronto como sea posible y de forma regular a partir de entonces. Esto requerirá la confianza de todas las partes, por lo que es posible que desee comenzar con proyectos pequeños y cronogramas y desarrollar esa confianza.

Answer 2

Todos tienen un enfoque diferente para el desarrollo de software. Su método es tan viable como el de su cliente. Sin embargo, dado que su cliente es el que le paga, le sugiero que se ajuste a sus estándares O sugiera su método y vea cómo reaccionan.

Answer 3

La especificación es la parte más importante (más larga para hacer) del proyecto. Le dice a usted (y a su cliente) lo que está construyendo y lo que le están pagando por.

No hay una buena conseguir abajo de la línea con la construcción y luego encontrar el cliente tenía una idea diferente en mente. Las especificaciones garantizan Todos están leyendo del mismo libro. Agrupar algunas ideas GUI allí también es una buena idea.

El fondo es, tanto usted como el cliente necesita saber qué esperar antes de comenzar el trabajo. Sus pantallas y maquetas deben ser parte de una especificación más amplia

Su enfoque parece un poco roto por una gran aplicación. Sus expectativas me parecen correctas.

Answer 4

utilizo maquetas de pantalla en Balsamiq. Esto demuestra la experiencia en general aspecto y el usuario, sin conseguir el lado seguido con la estética del diseño

Answer 5

Usted puede encontrar los siguientes artículos útiles en sus comunicaciones:

• The Iceberg Secret, Revealed
• Painless Functional Specifications - Part 2: What's a Spec?
• Painless Functional Specifications - Part 3: But... How?

Recuerde que usted todavía puede burlarse de HTML por sí mismo si le ayuda a pensar el resto. En gran medida, el diseño HTML será tu decisión.

Personalmente, soy fan de FIT y Fitnesse para las especificaciones. Hacen que sea más fácil mantenerse actualizado e incluyen algunas pruebas para verificar que el código cumpla con las especificaciones.

La otra cosa a recordar es que, como regla el cliente no del todo saben lo que quieren, por lo que incluso con una especificación completa no lo consideran completamente fijo.

Answer 6

La interfaz de usuario no es la parte más importante de la aplicación, centrándose en esta parte tan pronto podría dar lugar a suposiciones falsas e imponer opciones basadas en la interfaz, no en la funcionalidad.

Sugiero centrarse primero en la funcionalidad, para acordar qué se espera que haga la aplicación, no cómo se verá en la pantalla. La interfaz cambiará en el tiempo, el cliente querrá este botón a la izquierda no a la derecha, de color azul, no amarillo, este cuadro de texto más grande y una fuente diferente, estos son detalles para más adelante, si proporciona una interfaz con las especificaciones corre el riesgo de discutir esos detalles menores en lugar de las funcionalidades importantes.

Echa un vistazo a Applying UML and Patterns, creo que podría ser útil. Uno de los libros de la serie "Extreme Programming" también fue bueno, veré luego cuál exactamente.

Answer 7

Es posible que desee echar un vistazo a las respuestas a la siguiente pregunta, si la pregunta es de tamaño mediano, que todavía podría ser bastante complicado:

What are the basic questions to ask a person who wants his Medium sized website done?

¿Le ha pedido el cliente qué diagramas o se desaconsejan las capturas de pantalla prototipo? Pueden tener sus propias razones para esto, como tratar de limitar la cantidad de trabajo realizado antes de que comience el trabajo "real". Como idea, eso no es tan malo, suponiendo que hayan pasado antes por hacer una especificación con otras personas y se sientan cómodos con ese proceso. Si esto es nuevo para ellos, puede valer la pena discutir por qué quieres tener esos prototipos, p. a veces las palabras están abiertas a la interpretación y esto se resuelve más fácilmente con una imagen que las mil palabras que la imagen muestra con facilidad.

Answer 8

En primer lugar, tiene su terminología incorrecta. En el título de su pregunta, pregunte "El enfoque correcto al diseño una aplicación web", pero tenga en cuenta: su cliente le pidió que escriba especificaciones para la aplicación.

La especificación no es igual al diseño. Es peligroso intentar igualarlos.

Como dijo otra respuesta, una especificación es para que usted y su cliente sepan que está construyendo el. El diseño es el arte de cómo para construirlo.

Las especificaciones generalmente no incluyen maquetas. En pocas palabras, incluyen declaraciones que describen exactamente lo que el software debe hacer. Tenga en cuenta que esto es muy diferente de cómo debería hacerlo. Para las aplicaciones web, yo diría que las maquetas deberían hacerse en la fase de diseño. Entonces sí, para responder a su pregunta, usted es incorrecto en su enfoque.

Le sugiero que consulte this article en Wikipedia para obtener más información sobre las especificaciones.

Editar: Si bien lo que he dicho es técnicamente correcto, como tvanfosson señala, es difícil a las especificaciones completamente fuera un sistema antes de comenzar el desarrollo. Le recomiendo que lea el his answer y hable con sus clientes sobre la adopción de un enfoque más realista.