Expirado

Así que estás diseñando un nuevo sitio web o tienda en línea, y necesitas un desarrollador web. Es posible que los necesite para desarrollar un sitio desde cero. O tal vez simplemente los necesita para trabajar con algunos ajustes, cambios, problemas o funcionalidad adicional.

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

  • Plazos perdidos
  • Falta de comunicación
  • Comunicación lenta
  • Sin comunicacion
  • Desarrollador promete demasiado
  • Desarrollador bajo entrega
  • Desarrollador desaparece
  • Alcance poco definido
  • Falta de protocolo para pequeños supuestos / decisiones
  • Errores o problemas no se solucionan

Prácticamente todos los diseñadores con los que trabajo han compartido una historia de terror relacionada con una de esas cosas. Con el fin de evitar convertirme en una historia de terror, he desarrollado una lista práctica 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 un remedio para todas las relaciones entre diseñadores y desarrolladores. Al final del día, sigue siendo una relación humana, es complicada. Pero he descubierto 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 mensajería privada? Igual de importante: ¿ Con qué frecuencia se comunicará? ¿Todos los días? ¿Una vez por semana? En el kickoff, y luego no otra vez hasta QA? 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 mejor comunicación

No hay respuestas incorrectas aquí, siempre y cuando establezca expectativas al comienzo. Pero recuerde: más comunicación no siempre es 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 sea una buena personalidad.

Durante el desarrollo, trabaje para lograr un equilibrio entre registrar demasiado y muy poco. Demasiado y tu eres micro-gestor. Demasiado poco y el desarrollador podría no mantenerse en el camino. Es mejor establecer las expectativas en la parte superior y atenerse a ellas.

2. ¿Cómo manejará el proyecto?

¿Dónde están los archivos y las credenciales de inicio de sesión que necesitará el desarrollador? ¿Dónde realizará el seguimiento de las tareas, los hitos y los plazos? ¿Qué software utilizarás? ¿Campamento base? Trello? Asana? ¿Una hoja de cálculo o Google Doc? Básicamente, define el hub 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 ser centralizadas y rastreables. Se puede perder mucho tiempo en la búsqueda de archivos, registros, actualizaciones, progreso, preguntas, decisiones, etc. Es por eso que es importante establecer dónde el desarrollador puede encontrar todo lo que necesita.

3. ¿Quién toma las decisiones?

¿Eres tú quien toma la decisión final sobre el proyecto? ¿Hay un equipo de UI / UX involucrado? ¿Hay alguien más que tenga una opinión sobre las decisiones? ¿Hay un equipo de marketing o un gerente que quiera tomar en cuenta las decisiones? ¿Hay alguien más aparte de usted que va a orientar directamente al desarrollador? ¿Cuándo entra el cliente y cuántas decisiones toma 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 hacer que su desarrollador vuelva a trabajar. 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 el desarrollador manejar las suposiciones y las pequeñas decisiones?

¿Cuánta libertad tiene el desarrollador al interpretar diseños? ¿Deberían construir el sitio web de píxeles perfectos de acuerdo con los diseños, o deberían hacer pequeños supuestos sobre la consistencia y la reutilización de las secciones? Si ha diseñado un sitio receptivo, ¿ha diseñado para todos los puntos de interrupción? ¿Ha proporcionado notas sobre animaciones, transiciones y efectos de desplazamiento? ¿Has diseñado estados de validación para campos? (es decir, las ventanas emergentes: "Contraseña no válida" o "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 se sienten insatisfechos cuando un sitio web no se corresponde con los diseños, o, a la inversa, cuando el sitio sigue muy de cerca los diseños, en detrimento de su rendimiento o la línea de tiempo del proyecto. Al principio, define el nivel de detalle deseado. Lo hace para un proceso de control de calidad mucho más suave.

5. ¿Cuál es la línea de tiempo?

¿Cuál es la fecha límite difícil para el proyecto y cuál es la fecha límite blanda? ¿Se está produciendo un gran éxito de prensa para el cual se debe lanzar el sitio? Si la fecha límite es ambiciosa, ¿hay una manera de lanzarlo en fases? ¿Cuál es la expectativa de responder a los cambios rápidos? ¿Una semana de vuelta? ¿Menos de una hora?

Por qué esto importa

realmente no ayuda a crear plazos duros artificiales ... la honestidad es la mejor política

Si hay un plazo límite, haga que el desarrollador lo sepa y asegúrese de dejar tiempo para realizar las pruebas adecuadas. Después de que se inicie 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 haga 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 durante cuánto tiempo espera que se realicen correcciones y cambios Tomar y hacer un balance del nivel de prioridad de cada tarea.

Además, realmente no ayuda a crear plazos duros artificiales. Solo sea transparente con su desarrollador y confíe en ellos para que lo entreguen 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 el costo 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 importa

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

Conclusión

En general, establecer las expectativas y la comunicación son las cosas críticas aquí. Puede parecer un poco tonto discutir cómo se hablarán entre ellos durante un proyecto, especialmente si ya tiene una buena relación. Pero siempre es bueno establecer expectativas antes de tiempo, para que no termines dentro de tu propia historia de terror.

 

Fuente: https://www.webdesignerdepot.com/2019/03/6-things-to-discuss-with-your-web-developer-before-kickoff/