Muchas empresas, al prepararse para crear su sitio web oficial, elaboran un documento del proceso de construcción del sitio. Sin embargo, si el documento está lleno de términos técnicos o detalles de desarrollo, los clientes suelen quedar confundidos y necesitan explicaciones repetidas. La clave para que el proceso sea más comprensible para los clientes es usar un lenguaje familiar para ellos, transformando el proceso de construcción en una hoja de ruta clara de "qué hacer primero, qué después y qué se obtiene al final". A continuación, desde la perspectiva del cliente, presentamos un conjunto de pasos para redactar un proceso de construcción de sitio web que sea adecuado para mostrar a los clientes.
Dividir las etapas en hitos perceptibles para el cliente
Al cliente no le importa qué framework se usa en el backend ni cómo se diseña la base de datos; lo que le importa es "¿cuándo podré ver el primer borrador?", "¿cuándo podré agregar contenido?" y "¿cuánto tiempo hasta que esté en línea?". Por lo tanto, el proceso debe dividirse según los hitos de entrega, no según los pasos internos. Generalmente, se puede dividir en las siguientes etapas:
- Confirmación de requisitos y definición del plan: Ambas partes discuten los objetivos del sitio, la estructura de las secciones y los requisitos funcionales, y se genera un documento de plan acordado por ambas partes.
- Entrega y aprobación del diseño: El diseñador crea maquetas de la página de inicio y páginas internas según el plan. El cliente ve el estilo visual y da sugerencias de modificación hasta que se aprueba.
- Desarrollo frontend y backend: Los desarrolladores convierten el diseño en páginas interactivas y construyen el sistema de gestión del backend. Durante esta etapa, el cliente puede no ver cambios evidentes, pero puede recibir actualizaciones periódicas del progreso.
- Llenado de contenido y carga de materiales: El cliente proporciona contenido como presentación de la empresa, imágenes de productos y artículos de casos, que el equipo de operaciones o desarrollo sube al sitio.
- Pruebas y correcciones: Ambas partes revisan funciones como visualización de páginas, enlaces, envío de formularios, etc., y corrigen problemas encontrados.
- Lanzamiento y publicación: El sitio se despliega en un servidor de producción, se vincula un dominio y se completa el registro o las revisiones necesarias antes de que esté accesible al público.
Usar cronogramas en lugar de descripciones técnicas
En el documento del proceso, cada etapa debe incluir un rango de tiempo aproximado. Por ejemplo, "la etapa de confirmación de requisitos suele tomar de 3 a 5 días laborables" o "las revisiones del diseño generalmente se limitan a 2 rondas". Esto ayuda al cliente a tener expectativas realistas sobre el cronograma general y evita que presione constantemente durante las etapas intermedias. El cronograma puede mostrarse con una tabla simple o un diagrama de Gantt, pero evite palabras como "absoluto" o "garantizado"; use "estimado" o "generalmente".
Definir claramente las responsabilidades de cada parte
Muchos clientes, después de leer el proceso, aún no saben qué deben hacer ellos. Por lo tanto, debajo de cada etapa, se pueden incluir dos columnas: una para las responsabilidades del proveedor de servicios (la empresa de desarrollo o el equipo interno), como crear el diseño o desarrollar las páginas; y otra para las tareas del cliente, como aprobar requisitos, proporcionar textos e imágenes, y revisar el diseño. Así, el cliente puede preparar los materiales necesarios y saber cuándo debe actuar.
Usar analogías cotidianas para explicar pasos técnicos
Algunos pasos pueden ser desconocidos para el cliente, como "registro del dominio", "despliegue en servidor" o "interacción frontend". Se pueden usar analogías para facilitar la comprensión:
- Registro del dominio: Es como obtener un DNI para el sitio web; se deben presentar documentos para su revisión y generalmente toma unos días laborables.
- Despliegue en servidor: Es como colocar una casa construida en un lugar con electricidad las 24 horas, para que los visitantes puedan acceder en cualquier momento.
- Desarrollo frontend: Convertir el diseño en páginas que se puedan hacer clic en el navegador, como decorar una casa según los planos para que sea habitable.
Estas analogías no son necesarias en todos los artículos, pero pueden incluirse cuando el cliente pregunta frecuentemente sobre ciertos pasos.
Incluir instrucciones sobre comentarios y modificaciones
Lo que más preocupa al cliente suele ser "¿qué pasa si no estoy satisfecho?". Por lo tanto, en el proceso se debe explicar el mecanismo de modificación: se pueden hacer sugerencias de cambio antes de aprobar el diseño; después del desarrollo, se pueden corregir problemas funcionales; pero cambios estructurales importantes o nuevas funciones pueden afectar el tiempo y el costo. Explicar las reglas claramente ayuda a reducir disputas posteriores. Evite promesas como "modificaciones ilimitadas" o "satisfacción garantizada"; en su lugar, use frases como "modificaciones dentro de lo razonable" o "ajustes según la situación real".
Incluir una lista de verificación previa al lanzamiento
Al final del documento del proceso, se puede adjuntar una lista de verificación simple antes del lanzamiento, como:
- ¿Todas las páginas se cargan correctamente?
- ¿La información de contacto, dirección y mapa son correctos?
- ¿Las imágenes de productos son nítidas?
- ¿Las secciones de noticias/casos tienen contenido de demostración?
Esta lista permite que el cliente participe activamente en la verificación antes del lanzamiento, reduciendo la probabilidad de encontrar problemas después. También demuestra la atención y profesionalismo del proveedor de servicios.
Consejo: El documento del proceso no debe ser demasiado detallado. Para empresas pequeñas y medianas, mantener el proceso en 6-8 hitos, explicando claramente los resultados y las tareas de cada etapa en un lenguaje sencillo, es suficiente para que el cliente lo entienda y confíe. Si el cliente está interesado en detalles técnicos, se puede incluir un apéndice o explicar verbalmente, sin saturar el proceso principal con contenido técnico excesivo.