¿Se está sobrepasando la estructura de alambre?

Question

37 Getting Real de Signal me convenció de que la estructura de alambre y la escritura de documentos de especificaciones funcionales son pasos intermedios innecesarios para construir aplicaciones web y sitios web dinámicos.

¿Vale la pena la sobrecarga de estos pasos? ¿Es la creación de prototipos en HTML / CSS o incluso documentos de PhotoShop (para que los diseñadores puedan trabajar en ellos directamente) una mejor opción que usar un software como Visio? Personalmente, me estoy inclinando hacia lo último, pero no estoy seguro.

Answer 1

" No planear es planear fallar " - o algo así.

Wireframing no se limita a las aplicaciones web; se usa de manera generalizada siempre que se necesite una descripción general de alto nivel de cualquier sistema (simplemente se llama algo más).

Especificaciones funcionales, cuando sabes lo que hay que hacer & amp; cómo hacerlo sería exagerado. Un diagrama de alto nivel de sus intenciones sería suficiente. Y nunca será innecesario . Principalmente le ayuda a centrarse en el alcance y la intención / objetivo de lo que quiere hacer.

El enfoque debe estar en prevenir el esfuerzo desperdiciado: descubrir a mitad de camino que algo esencial, que impacta en todos los demás objetos, no es lo que desea descubrir. Wireframing en este caso ayudaría a detectar las necesidades funcionales más importantes. Solo necesitaría elaborar especificaciones funcionales donde sea absolutamente necesario. El uso de Photoshop para diseñar su voluntad también será un 'esfuerzo desperdiciado' - Mucho mejor usar prototipos evolutivos (técnica RAD) con CSS / HTML - pero todavía hacer pen & amp; maqueta en papel de tus intenciones.

Answer 2

37Signals recomienda omitir incluso Photoshop e ir directamente a HTML. Consulte http://www.37signals.com/svn/posts / 1061-why-we-skip-photoshop . Estoy de acuerdo con su evaluación de la planificación previa. No creo que valga la pena el tiempo a largo plazo cuando podría dedicar tiempo a construir un prototipo que funcione en HTML / CSS / JS.

Answer 3

En la vida real, debes evitar buscar el " ideal " forma de hacer las cosas. En su lugar, utilice lo que entiende con un propósito claro y específico.

Las maquetas pueden ahorrarle TONELADAS de tiempo y esfuerzo. Como pueden ser solo un tiempo extra que dedicaste a crearlos y mantenerlos.

Ejemplo de la vida real # 1: Las maquetas salvaron el día. Gran sistema para el gobierno, la fecha límite es ridícula.

Motivo: Han pasado meses en la producción de todo tipo de documentos de arquitectura que de hecho son completamente innecesarios porque tanto la arquitectura HW como la SW están fijadas en piedra hasta el más mínimo detalle, y de hecho ya existen.

Solución: 20 días frenéticos de creación de maquetas junto con el cliente, hasta que simplemente entreguemos las pantallas con nuestras notas a los desarrolladores. Los desarrolladores tuvieron que pedir algunas aclaraciones, pero con una arquitectura fija y requisitos claros y visualizados pudieron producir toneladas de características en muy poco tiempo.

Ejemplo de la vida real # 2: Las maquetas arruinaron el día. Gran sistema de gobierno que '' reconoció '' la necesidad de maquetas.

Este muestra la capacidad humana (¿o corporativa?) de convertir lo mejor del mundo en una pesadilla.

La gran agencia gubernamental le pidió a la gran empresa consultora que liderara a la gran empresa de TI para resolver un problema. La agencia gubernamental también estableció un gran cuerpo ad-hoc de expertos gubernamentales en temas para ayudar y acelerar el proceso.

Los meses han pasado en grandes palabras y al decidir sobre las metodologías apropiadas para usar y las formas adecuadas de usarlas. Se hicieron todo tipo de compromisos, por supuesto, para no herir los sentimientos o la importancia de nadie.

Resultado: la arquitectura Sw debía ser la fuente de todo, incluidas las maquetas. Que debían ser diseñados primero y dibujados en segundo lugar Mapeando las acciones de OOAD y diagramas de secuencia, se hicieron diagramas UX, luego se reconocieron los objetos lógicos de UI y los paquetes de contenido, se dibujaron pantallas reales y se incorporaron en casos de uso formales, se presentaron UC a los usuarios en talleres formales una vez al mes, esos talleres se duplicaron como reuniones de aceptación de requisitos ya que alguien descubrió que el tiempo se está escapando.

En esos talleres, incluso por la fuerza, no se podía hacer que los clientes entendieran (altamente formal, con muchas tablas que describen atributos de datos y tales) UC, cada una de aproximadamente 30 páginas. Cuando los clientes tenían algún comentario, estaba en las maquetas. Pero se desaconsejó la retroalimentación, porque cualquier cambio en la maqueta resultó en el cambio de los diagramas de secuencia, diagramas de componentes, modelo operativo, diagramas UX, verificación de las matrices de trazabilidad, actualización de textos UC, etc. Y solo para obtener más comentarios. ("Malditos sean los clientes, nunca están satisfechos", fue la moto). Después del lanzamiento de v1.0 con funcionalidad limitada, a nadie le importó más la documentación, había mucha de ella. Los desarrolladores estaban luchando por sus vidas, haciendo una miríada de pequeños cambios diarios, solo para poner en funcionamiento el sistema (después de ayer, un lote de cambios hizo que algo más se rompiera).

Esta NO es la forma de usar maquetas. El proyecto duró casi 2 años más de lo planeado.

En otras palabras, no busque la metodología ideal. O cualquier metodología que no entiendas. ¿Cuál es tu objetivo en este momento? ¿Cuál es la forma más rápida que sabes (otras formas no cuentan) para lograr ese objetivo? Ve a por ello.

Answer 4

Probablemente depende de con quién estás trabajando. Si eres tú y un diseñador, entonces una especificación funcional podría ser demasiado problemática. Pero, en mi trabajo, los ejecutivos quieren saber con precisión qué obtendrán al final de un proyecto, por lo que hemos tenido dificultades para implementar el desarrollo iterativo. Por lo general, las iteraciones se definen con wireframes, especificaciones funcionales y maquetas ... :)

Answer 5

El propósito principal de hacer tramas de alambre es aclarar los requisitos. Siempre es aconsejable documentar claramente los requisitos y no hay mejor manera que visualizar un requisito. Wireframes ayuda de manera excelente aquí, le da al propietario del producto (cliente) una idea clara de qué esperar del producto final. Con la aprobación del propietario del producto, también le da una imagen más clara al equipo de desarrollo de lo que debe desarrollar. De esta manera, ahorra mucho tiempo de desarrollo y evita conflictos. En mi opinión, los marcos de alambre siempre son útiles para la ejecución sin problemas del proyecto, incluso cuando el proyecto es pequeño.

Answer 6

Creo que depende de qué tan bien entiendas lo que estás tratando de hacer. Si está trabajando para un cliente y no ha expresado mucho en cuanto a los requisitos, es posible que desee un enfoque con iteraciones extremadamente rápidas. Si ya tiene una buena comprensión y puede producir algo más sustancial sin tener que preocuparse por tirarlo a la basura porque era la dirección incorrecta, entonces puede dedicar más tiempo. De cualquier manera, un prototipo en el que se puede hacer clic puede ayudar mucho a determinar cuál debe ser el sitio real al final. Si puede llegar a un acuerdo sobre el prototipo, cuando su solicitud coincida con el prototipo, sabrá que está completo.