Entonces, está diseñando un nuevo sitio web o una tienda en línea, y necesita un desarrollador web. Es posible que los necesite para desarrollar un sitio desde cero. O tal vez solo los necesite para trabajar en algunos ajustes, cambios, problemas o funcionalidades adicionales.
De cualquier manera, su relación con su desarrollador web puede ser difícil de manejar. Soy desarrollador, así que sé que hay tantas formas en que la relación puede desmoronarse:
- plazos incumplidos
- Falta de comunicación
- Comunicación lenta
- Sin comunicacion
- Desarrollador sobre-promesas
- El desarrollador entrega por debajo de lo esperado
- El desarrollador desaparece
- Alcance vagamente definido
- Falta de protocolo para pequeñas suposiciones/decisiones
- Los errores o problemas no se solucionan
Prácticamente todos los diseñadores con los que trabajo han compartido una historia de terror que involucra una de esas cosas. Para evitar convertirme en una historia de terror, he desarrollado una lista útil de elementos de discusión previos al lanzamiento para ayudarnos a evitar este tipo de problemas.
Antes de entrar en materia, seamos claros: esta no es una panacea para todas las relaciones diseñador/desarrollador. Al final del día, sigue siendo una relación humana, es complicada. Pero descubrí que una conversación abierta sobre estos elementos puede iniciar un proyecto con el pie derecho.
1. ¿Cómo nos comunicaremos?
¿Cómo te comunicarás mientras trabajas en el proyecto? ¿Flojo? ¿Llamadas telefónicas? ¿Textos? ¿Correos electrónicos? software de mantenimiento preventivo? Igual de importante: ¿Con qué frecuencia se comunicará? ¿Todos los días? ¿Una vez por semana? ¿En el inicio, y luego no de nuevo hasta el control de calidad? Si está haciendo un registro diario, ¿será un correo electrónico de dos oraciones o una llamada telefónica de 15 minutos? ¿Cuál es el plan en caso de emergencias?
Más comunicación no siempre es igual a mejor comunicación
No hay respuestas incorrectas aquí, siempre que establezca expectativas al principio. Pero recuerde: más comunicación no siempre es igual a mejor comunicación.
Por qué esto es importante
Desea tener una buena relación con su desarrollador y, para lograrlo, necesita un modo de comunicación establecido. Por lo general, una llamada telefónica es útil para desarrollar una conexión personal inicial y para asegurarse de que se ajuste bien a la personalidad.
Durante el desarrollo, trabaje para lograr un equilibrio entre verificar demasiado y demasiado poco. Demasiado y estás microgestionando. Demasiado poco y el desarrollador podría no mantenerse en el camino. Lo mejor es establecer las expectativas en la parte superior y atenerse a ellas.
2. ¿Cómo gestionará el proyecto?
¿Dónde están los archivos y las credenciales de inicio de sesión que necesitará el desarrollador? ¿Dónde realizará un seguimiento de las tareas, los hitos y los plazos? ¿Qué software usarás? ¿Campamento base? Trello? ¿Asana? ¿Una hoja de cálculo o Google Doc? Básicamente, definir el eje central para todo lo relacionado con el proyecto.
Por qué esto es importante
Durante el proyecto, la gestión y la comunicación del proyecto deben ser centralizadas y rastreables. Se puede perder mucho tiempo en el ir y venir de buscar archivos, registros, actualizaciones, progreso, preguntas, decisiones, etc. Por eso es importante establecer dónde el desarrollador puede encontrar todo lo que necesita.
3. ¿Quién está tomando las decisiones?
¿Es usted quien toma la decisión final sobre el proyecto? ¿Hay un equipo de UI/UX involucrado? ¿Hay alguien más que pueda opinar sobre las decisiones? ¿Hay un equipo de marketing o un gerente que quiera opinar sobre las decisiones? ¿Alguien más aparte de usted va a dar instrucciones directamente al desarrollador? ¿Cuándo entra el cliente y cuántas decisiones puede tomar? ¿El cliente tendrá comunicación directa con el desarrollador?
Por qué esto es importante
No desea retroceder en el desarrollo o que su desarrollador rehaga el trabajo. Para evitar eso, es importante que cada parte interesada esté al tanto de todas las decisiones relevantes, y que cada decisión se registre en una única ubicación central.
4. ¿Cómo debe manejar el desarrollador las suposiciones y las pequeñas decisiones?
¿Cuánta libertad tiene el desarrollador al interpretar los diseños? ¿Deberían construir el sitio web con píxeles perfectos de acuerdo con los diseños, o deberían hacer pequeñas suposiciones sobre la consistencia y la reutilización de las secciones? Si ha diseñado un sitio receptivo, ¿lo ha diseñado para todos los puntos de interrupción? ¿Ha proporcionado notas sobre animaciones, transiciones y efectos de desplazamiento? ¿Ha diseñado estados de validación para los campos? (es decir, las ventanas emergentes: «Contraseña no válida» o «Nombre de usuario no existe»). Si no lo ha hecho, ¿tiene el desarrollador libertad para tomar decisiones o sugerencias?
Por qué esto es importante
Muy a menudo, los diseñadores se sienten insatisfechos cuando un sitio web no coincide con los diseños o, por el contrario, cuando el sitio sigue demasiado de cerca los diseños, en detrimento de su rendimiento o del cronograma del proyecto. Al principio, defina su nivel de detalle previsto. Hace que el proceso de control de calidad sea mucho más fluido.
5. ¿Cuál es la línea de tiempo?
¿Cuál es el plazo límite para el proyecto y cuál es el plazo flexible? ¿Se está produciendo un gran éxito de prensa para el que se deba lanzar el sitio? Si el plazo es ambicioso, ¿hay forma de lanzarlo por fases? ¿Cuál es la expectativa para responder a cambios rápidos? Entrega de una semana? ¿Menos de una hora?
Por qué esto es importante
realmente no ayuda crear plazos estrictos artificiales… la honestidad es la mejor política
Si hay una fecha límite difícil, infórmele al desarrollador y asegúrese de dejar tiempo para las pruebas adecuadas. Después de que se lance el sitio, sepa que la mayoría de los desarrolladores no pueden estar disponibles a todas horas para realizar cambios. Esperar a que un desarrollador realice una solución puede ser frustrante, pero incluso las solicitudes pequeñas requieren mantener el control de la versión, iniciar el entorno de desarrollo, conectarse al servidor, implementar en el sitio de producción, etc. Determine con anticipación cuánto tiempo espera realizar las correcciones y los cambios. tomar, y evaluar el nivel de prioridad de cada tarea.
Además, realmente no ayuda crear plazos estrictos artificiales. Solo sea transparente con su desarrollador y confíe en que cumplirá en consecuencia. Una vez más, estás construyendo una relación, aquí. La honestidad es la mejor política.
6. ¿Cuál es la estructura del alcance, el contrato y la estructura de pago?
¿Cuál es la tarifa del proyecto? ¿Cuál es el punto de referencia para el final del proyecto? ¿Qué se incluye en el alcance del proyecto? ¿Cuándo sale el pago? ¿Está contratando al desarrollador para que haga el proyecto a una tarifa fija o por hora?
Por qué esto es importante
Lo último que desea es que un desarrollador obtenga un sitio el 95% del camino y luego no inicie el proyecto debido a una discrepancia en el alcance/contrato/pago.
Conclusión
En general, establecer expectativas y la comunicación son las cosas críticas aquí. Puede parecer un poco tonto discutir cómo se van a hablar durante un proyecto, especialmente si ya tienen una buena relación. Pero siempre es bueno establecer expectativas con anticipación, para que no termines dentro de tu propia historia de terror.
Foto principal a través de Unsplash