Project Guardrails: diseño por comité
Cuando te contratan para crear una solución para otros, principalmente en la web, ya que esa es el área en la que trabajo, creo que hay una serie de factores que son importantes para un proyecto :
- No debe haber un "diseño por comité".
- Nadie más que el equipo central de desarrollo debería poder proporcionar el desarrollo, la puesta en escena y la producción.
- Nadie debería poder escribir en producción excepto el equipo de desarrollo (e incluso entonces, debería haber un proceso de implementación).
Siempre dudo en hacer afirmaciones como esta, ya que parecen dogmáticas, pero encuentro que cuanto más tiempo trabajo en esta industria, más creo que estas tres reglas son importantes.
O tal vez en realidad son solo pautas. Después de todo, hay decisiones tomadas antes de que realmente terminemos las cosas.
Independientemente de si son más sugerencias o reglas, realmente no importa. Hay razones por las que todos llegamos a las conclusiones que hacemos, ¿verdad? Y así, en las próximas publicaciones (en lugar de una publicación larga), compartiré las razones por las que he encontrado que estas tres reglas son importantes.
Diseño por comité
Cuando uso este término, no quiero decir que una sola persona deba ser responsable de diseñar un sitio. Solo quiero decir que una agencia o un grupo de los que se enfocan en el diseño debería ser responsable de ello.
Diseño por comité es un término despectivo para un proyecto que tiene muchos diseñadores involucrados pero ningún plan o visión unificadora.
Entonces, un "comité" en este caso es cuando un grupo de personas, o los clientes o aquellos relacionados con los clientes en cierta medida, vienen a ver el resultado de la implementación (o incluso solo el diseño), envían sugerencias por correo electrónico de lo que harían. gusta ver y esperar que suceda.
Es decir, la pericia si se sacrifica un determinado diseñador por las opiniones de otro grupo.
La princesa Leia no era un comité.
Y, tal vez en casos extremos (aunque nunca he experimentado esto personalmente), use el pago como palanca para salirse con la suya.
El caso es que las personas que se contraten para diseñar la solución para el cliente deben ser, como se ha dicho, expertos en la materia. Entienden la tipografía, los colores, las resoluciones de pantalla, la accesibilidad, etc.
Dejarlos en su área de especialización siempre es una buena idea.
Cuidando el Proyecto
Nada de esto tiene que ver con que alguien tenga más control sobre el proyecto que cualquier otra persona.
Se trata de asegurarse de que todas las partes interesadas del proyecto trabajen en conjunto y no crucen áreas de responsabilidad. (Imagínese, digamos, los GIF que se usarían para publicidad si los desarrolladores fueran responsables de los comerciales. 😏)
La conclusión es que un proyecto exitoso es solo eso cuando todos permanecen en su rincón y trabajan juntos en su propia área de especialización.
De lo contrario, terminará con cosas que no estarán sincronizadas y, básicamente, creará más problemas cuando no había ninguno (bueno, al menos en un área en particular) con los que comenzar.
¿Que sigue?
En la próxima publicación, cubriré la idea de entornos de aprovisionamiento, lo que esto significa y cómo juega en el rol general de la gestión de proyectos. Pero entraré más en detalle sobre eso en la publicación.
En última instancia, se trata de asegurarse de quién tiene acceso de lectura y escritura a las diversas áreas en las que se puede implementar la aplicación o el proyecto. Claro, para algunos que leen esto, esto puede sentirse un poco como contenido para "principiantes" o no como contenido relacionado con el "desarrollo".
Pero si está en el negocio de trabajar con otros para construir una solución, entonces es probable que se encuentre con estas cosas y es más fácil tener un plan basado en los errores que otros han cometido (es decir, yo 🙂) que aprender cosas. el camino difícil.