Krypton Solid

6 cosas para discutir con su desarrollador web antes del inicio

6 cosas para discutir con su desarrollador web antes del inicio

Entonces, está diseñando un nuevo sitio web o 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 solucionar algunos ajustes, cambios, problemas o funciones adicionales.

De cualquier manera, su relación con su desarrollador web puede ser difícil de administrar. Soy desarrollador, así que sé que hay tantas, tantas formas en que la relación puede desmoronarse:

  • Fechas límite incumplidas
  • Falta de comunicación
  • Comunicación lenta
  • Sin comunicacion
  • Promesas excesivas del desarrollador
  • Desarrollador no cumple
  • 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 inicio para ayudarnos a evitar este tipo de problemas.

Antes de entrar en esto, seamos claros: esto no es una panacea para todas las relaciones entre diseñador y 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 se comunicará mientras trabaja en el proyecto? ¿Flojo? ¿Llamadas telefónicas? ¿Textos? Correos electrónicos ¿Software de PM? Igual de importante: cómo a menudo te comunicaras ¿Diario? ¿Una vez por semana? ¿En el saque inicial, y luego no de nuevo hasta QA? Si realiza 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 equivale a una mejor comunicación

Aquí no hay respuestas incorrectas, siempre que establezca expectativas al principio. Pero recuerde: más comunicación no siempre equivale a una mejor comunicación.

Por qué esto importa

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 encaja bien con la personalidad.

Durante el desarrollo, esfuércese por lograr un equilibrio entre registrar demasiado y muy poco. Demasiado y estás microadministrado. Demasiado poco y el desarrollador podría no seguir el rumbo. Es mejor establecer las expectativas en la parte superior y ceñirse 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 un documento de Google? Básicamente, defina el eje central para todo lo relacionado con el proyecto.

Por qué esto importa

Durante el proyecto, la gestión y la comunicación de su proyecto deben estar centralizadas y ser rastreables. Se puede perder mucho tiempo en la búsqueda de 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 manda?

¿Eres el tomador de decisiones final sobre el proyecto? ¿Hay un equipo de UI / UX involucrado? ¿Hay alguien más que participe en las decisiones? ¿Existe un equipo de marketing o un gerente que quiera influir en las decisiones? ¿Alguien más además de usted le dará instrucciones directamente al desarrollador? ¿Cuándo entra el cliente y cuántas decisiones puede tomar el cliente? ¿El cliente tendrá comunicación directa con el desarrollador?

Por qué esto importa

No desea dar marcha atrás en el desarrollo o que su desarrollador rehaga el trabajo. Para evitarlo, es importante que todos los interesados ​​conozcan 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 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 coherencia 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 «El nombre de usuario no existe»). Si no lo ha hecho, ¿el desarrollador es libre de tomar decisiones o sugerencias?

Por qué esto importa

Muy a menudo, los diseñadores no están satisfechos cuando un sitio web no coincide con los diseños o, por el contrario, cuando el sitio también sigue de cerca los diseños, en detrimento de su desempeño o del cronograma del proyecto. Al principio, defina su nivel de detalle deseado. 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 la fecha límite estricta para el proyecto y cuál es la fecha límite flexible? ¿Se está produciendo un gran éxito en la prensa por el que es necesario lanzar el sitio? Si el plazo es ambicioso, ¿hay alguna forma de lanzarlo por fases? ¿Cuál es la expectativa de responder a cambios rápidos? ¿Retorno de una semana? ¿Menos de una hora?

Por qué esto importa

realmente no ayuda crear fechas límite estrictas artificiales … la honestidad es la mejor política

Si hay una fecha límite estricta, avísele al desarrollador y asegúrese de dejar tiempo para las pruebas adecuadas. Después del lanzamiento del sitio, sepa que la mayoría de los desarrolladores no pueden estar disponibles en todo momento para realizar cambios. Esperar a que un desarrollador haga una corrección puede ser frustrante, pero incluso las solicitudes pequeñas requieren mantener el control de versiones, iniciar el entorno de desarrollo, conectarse al servidor, implementar en el sitio de producción, etc. Determine con anticipación cuánto tiempo espera para las correcciones y cambios. tomar y hacer un balance del nivel de prioridad de cada tarea.

Además, realmente no ayuda crear plazos rígidos artificiales. Simplemente sea transparente con su desarrollador y confíe en él para que se entregue 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 hacer el proyecto a una tarifa fija o por hora?

Por qué esto importa

Lo último que desea es que un desarrollador obtenga un sitio al 95% del camino y luego no lance el proyecto debido a una discrepancia en el alcance / contrato / pago.

Conclusión

En general, establecer expectativas y 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 tiene una buena relación. Pero siempre es bueno establecer expectativas con anticipación, para que no termines en tu propia historia de terror.

Foto principal vía Unsplash

Deja un comentario