La agencia nos envió las pantallas de desarrollo del CRM: ¿en qué debo fijarme exactamente en estas maquetas y diagramas?

Tras diez años gestionando proyectos te digo: los diseñadores suelen crear pantallas pal 'caso ideal'. Te ponen nombres cortos perfectos y números de pedido de dos dígitos. Pregúntales: '¿cómo se ve esto cuando el cliente tiene 8 sucursales y 40 pedidos pendientes?'. La vida real es caótica, si los bocetos no aguantan esa complejidad, el proyecto se cae al salir a producción.

Esos diagramas con cajitas pueden ser el modelo de la base de datos. Aunque no seas técnico, mira esto: ¿la línea de la caja Cliente a la caja Pedido tiene sentido? ¿Un cliente puede tener varias direcciones de entrega? Si la dirección aparece fija en una sola casilla, mañana no podrás agregarle una segunda dirección a un mismo cliente. No te trabes con los detalles, revisa las relaciones.

Corrección: recordaba mal la cifra, era un poco más baja.

Pon todas las pantallas en orden sobre la mesa y sigue el ciclo de vida de un pedido. El cliente llamó le cotizaste, se volvió pedido, se emitió el albarán. ¿Hay pantalla para cada uno de esos 4 pasos? Si falta alguno, la agencia cree que es un módulo estándar o se lo saltó. Pide por escrito los pasos que falten de una.

nosotros cometimos ese mismo error el año pasado, solo miramos el panel principal y los graficos q se veian geniales. resulta q en la pantalla de facturacion no habian diseñado el campo de descuento.. y despues nos cobraron desarrollo extra. miren bn los botones de filtro y el scroll en las tablas.

edit: he corregido unas erratas.

¿La agencia te mandó las pantallas como imágenes estáticas o te dio un enlace a un prototipo interactivo? Si no hay prototipo donde hacer clic, es imposible saber a dónde te lleva cada botón. Y ojo, ¿hay maquetas para la versión móvil o solo te entregaron pantallas de escritorio?

Cuando mandamos a hacer un panel similar por 24.000 dólares, dimos la aprobación visual en tres días; después, durante 4 meses enteros nos rechazaron peticiones diciendo "pero esto no lo habían dibujado". Por dos pantallas de reportes que faltaban tuvimos que pagar 3.200 dólares de presupuesto extra más tarde. La aprobación visual se considera legalmente como condición de entrega, no se apuren.

Es muy común que las agencias de software bajen capturas de pantalla de sitios con plantillas hechas y las vendan como "diseño exclusivo". ¿En las pantallas que les mandaron figuran los términos reales de su empresa o hay palabras genéricas? Si no usaron datos reales, no es algo personalizado para ustedes, es un borrador sacado de la repisa.

Gracias por escribir. El calendario de pagos debe vincularse a las fases del proyecto, no a fechas fijas.

Gracias por escribir. Que todo el mundo haga algo no significa que sea lo correcto.

Si tenéis dudas, escribid os responderé en la medida de lo posible.

Soy una pequeña empresa, os lo cuento desde mi lado. La gente no defiende el proceso, defiende la costumbre. La resistencia viene de ahí.

Empezad con una pequeña prueba, no lo integréis todo de golpe. Si tenéis dudas, escribid, os responderé en la medida de lo posible.

le agradecería que compartiera el resultado.

Buen trabajo. La gente no defiende el proceso, defiende la costumbre. La resistencia viene de ahí.

Cada "lo miramos luego" en una reunión es trabajo no presupuestado. También me gustaría saber si alguien lo hace de otra manera.

Permíteme resumir lo que se ha dicho hasta ahora. Establecer un proceso de solicitud de cambios no ralentiza el trabajo, lo agiliza.

Un informe semanal por escrito funciona mucho mejor que preguntar por fechas. Por supuesto, cambia si tu situación es diferente.

Aquí hay que hacer una distinción. La respuesta varía mucho según el sector, no hay una regla general.

La mayor parte de la pérdida de tiempo se acumula en los trabajos pendientes de aprobación.

soy una pequeña empresa, os lo cuento desde mi lado. bueno si intentas cambiarlo todo a la vez nada termina de asentarse.

preguntad quién ha prepardao la oferta y quién hará el trabajo. lo dejo como nota por si sirve.

Este hilo es para archivar. El código sin documentación de instalación aunque lo tengas, no es tuyo.

Antes de decidir, mirad qué datos tenéis en la mano. Si tenéis dudas escribid os responderé en la medida de lo posible.

Yo también estaba pensando en lo mismo. Si no lo pones por escrito desde el principio, luego surgen discusiones.

Esta es mi opinión, no lo escribo como una verdad absoluta.

Han surgido tres opiniones distintas, todas se complementan. Establecer un proceso de solicitud de cambios no ralentiza el trabajo, lo agiliza.

Si escribís el resultado aquí, también servirá de ayuda a otros.