fbpx Skip to content

6 cosas que debe discutir con su desarrollador web antes del inicio del proyecto

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 sólo los necesites para trabajar con algunos ajustes, cambios, problemas o funciones adicionales.

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

  • Fechas límite incumplidas
  • Falta de comunicación
  • Comunicación lenta
  • No hay comunicación
  • Promesas excesivas de los desarrolladores
  • Entregas insuficientes de desarrolladores
  • Desaparece el desarrollador
  • Ámbito de aplicación poco definido
  • Falta de protocolo para pequeñas suposiciones/decisiones
  • Los errores o problemas no se corrigen

Prácticamente todos los diseñadores con los que trabajo han compartido una historia de horror sobre una de esas cosas. Con el fin de evitar convertirme en una historia de terror, he desarrollado una lista útil de temas de discusión previos al inicio del juego para ayudarnos a evitar este tipo de problemas.

Antes de entrar en detalles, seamos claros: esto no es una cura para todas las relaciones entre diseñadores y desarrolladores. Al final del día, sigue siendo una relación humana, es complicado. Pero he descubierto que una conversación abierta sobre estos temas puede iniciar un proyecto con el pie derecho.

1. ¿Cómo nos comunicaremos?

¿Cómo se comunicará mientras trabaja en el proyecto? ¿Slack? ¿Llamadas telefónicas? ¿Textos? ¿Mensajes de correo electrónico? ¿Software PM? Igual de importante: ¿Con qué frecuencia se comunicará? ¿Todos los días? ¿Una vez a la semana? En el momento del saque inicial, y luego no de nuevo hasta que QA? Si está haciendo un check-in diario, ¿será un correo electrónico de dos frases o una llamada telefónica de 15 minutos? ¿Cuál es el plan en caso de emergencia?

Más comunicación no siempre equivale a mejor comunicación

No hay respuestas erróneas aquí, siempre y cuando se establezcan expectativas al principio. Pero recuerda: Más comunicación no siempre equivale a mejor comunicación.

Por qué es importante

Usted quiere 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 es un buen ajuste de la personalidad.

Durante el desarrollo, trabaje para encontrar un equilibrio entre un exceso y un defecto de facturación. Demasiado y estás microadministrando. Demasiado poco y es posible que el desarrollador no se mantenga en el camino correcto. Es mejor 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á el seguimiento de las tareas, los hitos y los plazos? ¿Qué software va a utilizar? ¿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é es importante

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 está llamando a los disparos?

¿Es usted la persona que toma la decisión final sobre el proyecto? ¿Hay un equipo de UI/UX involucrado? ¿Hay alguien más que pueda dar su opinión sobre las decisiones? ¿Hay un equipo de marketing o un gerente que quiera influir en las decisiones? ¿Alguien más, aparte de usted, va a dar instrucciones directamente al desarrollador? ¿Cuándo entra el cliente y cuántas decisiones tiene que tomar? ¿El cliente tendrá comunicación directa con el desarrollador?

Por qué es importante

Usted no quiere dar marcha atrás en el desarrollo, o hacer que su desarrollador vuelva a trabajar. Para evitarlo, es importante que todas las partes interesadas sean conscientes de todas las decisiones relevantes, y que cada decisión se registre en un único lugar central.

4. ¿Cómo debe manejar el desarrollador las suposiciones y las pequeñas decisiones?

¿Cuánta libertad tiene el desarrollador a la hora de interpretar los diseños? ¿Deben construir el sitio web con píxeles perfectos de acuerdo con los diseños, o deben hacer pequeñas suposiciones sobre la consistencia y la reutilización de las secciones? Si ha diseñado un sitio con capacidad de respuesta, ¿ha diseñado para todos los puntos de ruptura? ¿Ha proporcionado notas sobre animaciones, transiciones y efectos de flotador? ¿Ha diseñado estados de validación para los campos? (es decir, los popups: “Password invalid.” o “Username doesn$0027t exist”.) Si no lo ha hecho, ¿está el desarrollador libre de tomar decisiones o hacer sugerencias?

Por qué es importante

Muy a menudo, los diseñadores no están satisfechos cuando un sitio web no se ajusta a los diseños o, por el contrario, cuando el sitio sigue demasiado de cerca los diseños, en detrimento de su rendimiento o de la línea de tiempo del proyecto. Al principio, defina el nivel de detalle deseado. Esto hace que el proceso de control de calidad sea 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? ¿Hay un gran éxito de prensa para el cual el sitio necesita ser lanzado? Si el plazo es ambicioso, ¿hay alguna forma de lanzarlo por fases? ¿Cuál es la expectativa para responder a los cambios rápidos? ¿Un plazo de entrega de una semana? ¿Menos de una hora?

Por qué es importante

realmente no ayuda a crear plazos artificiales difíciles….la honestidad es la mejor política

Si hay una fecha límite difícil, informe al desarrollador al respecto y asegúrese de dejar tiempo para realizar las pruebas adecuadas. Después del lanzamiento del sitio, sepa que la mayoría de los desarrolladores no pueden estar de guardia en todo momento para hacer cambios. Esperar a que un desarrollador haga una corrección puede ser frustrante, pero incluso las peticiones pequeñas requieren mantener el control de versiones, lanzar el entorno de desarrollo, conectarse al servidor, desplegarse en el sitio de producción, etc. Determine de antemano cuánto tiempo espera que se lleven a cabo las correcciones y los cambios, y haga un balance del nivel de prioridad de cada tarea.

Además, no ayuda mucho crear plazos artificiales difíciles. Simplemente sea transparente con su desarrollador y confíe en ellos para que le entreguen la información en consecuencia. De nuevo, estás construyendo una relación, aquí. La honestidad es la mejor política.

6. ¿Cuál es la estructura del alcance, del contrato y de la estructura de pago?

¿Cuál es la cuota 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 promotor para que realice el proyecto a una tarifa por hora o fija?

Por qué es importante

Lo último que usted quiere es que un desarrollador obtenga un sitio en el 95% del camino, y luego no lanzar 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 van a hablar entre ustedes 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 horror.

Imagen destacada a través de Unsplash