Guido Durazzo - Gestión de proyectos de diseño
•Als PPT, PDF herunterladen•
1 gefällt mir•724 views
Guido Durazzo (Director Creativo y Co-Fundador de GFDD Group) nos transmite una visión práctica de la gestión del diseño en grandes proyectos.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Empfohlen
Empfohlen (20)
Guido Durazzo - Gestión de proyectos de diseño
Hinweis der Redaktion
- Guido Durazzo: trabaja en GFDD Group desde hace 7 años, cuando la fundó con su hermano. GFDD arrancó como un estudio de diseño gráfico y web, convirtiéndose con el tiempo en un proveedor de soluciones a medida a problemas de marketing y de gestión de negocios, con un centro en Internet y con un énfasis especial en la experiencia de usuario y usabilidad.
- Qué somos quienes nos reunimos bajo este título de IxD? Diseñadores gráficos, de interacción, diseñadores web, diseñadores de información, etc. Hacemos de todo. El gran problema y la verdad incómoda #1 es que nadie nació para esto. Nadie nación con un Gantt en la mano, pero sobre todo nadie nació con un iPhone! Estamos solucionando problemas que nosotros mismos nos inventamos, en una disciplina que nació espontáneamente para resolver problemas de un mundo abstracto, que es aire que tenemos que organizar.
- Entonces… qué problemas solemos ver en los proyectos de diseño?
- El primero que vemos es que nunca son sólo de diseño! Suele haber desarrollo, marketing, estrategia de negocios, contenidos, hasta psicología para entender al cliente y a nosotros mismos!
- Problemas de Alcance: las especificaciones suelen ser nulas o muy malas. Suele haber enormes puntos TBD (to be defined). Demasiadas voces y tomadores de decisión involucrados. Muchas veces hasta se define el proyecto sin definir el problema que éste debe resolver.
- Problemas de Recursos. Muchas veces no hay planificación, o es a la fuerza, o se olvida por la mitad cuando las cosas ya no salen tanto como se planeaban. Acá también interviene un problema inherente en la mayoría de los humanos: llenamos el tiempo que tengamos disponible para cumplir con una tarea, por eso una idea de progreso y compleción clara es importantísima. Y uno de los grandes problemas de las empresas que manejan múltiples proyectos a la vez: proyectos que se frenan o retrasan (por falta de input del cliente, por cambios de alcnace) y después hay que retomar cuando ya no hay nadie para hacerlos, por estar dedicados los equipos a otras tareas que surgieron en el interín.
- Emociones. Es fácil olvidar que estamos tratando con personas, que le pasan cosas por fuera del proyecto (presiones personales, laborales).
- Problemas de Aleatoriedad. Choques de geografía, cultura, desaciertos al inferir lo que el cliente está buscando, acciones de la competencia y partners estratégicos.
- Soluciones. Cómo lo solucionamos? Hay distintas escuelas: está la de la revolución industrial, la de la industria del petróleo y construcción con sus interminables Gantts a mano de Rotrings, la escuela de Joel Spolsky (“las specs no sirven”), la de 37 Signals (simplicidad al extremo)… La triste pero obvia realidad: ninguna escuela es mágica y definitiva. Hay que elegir una, o armar una propia en base a lo que nos sirva más, y darle para adelante, aplicarla a rajatabla por el tiempo mínimo necesario para saber si funciona o no. [Apunta Jorge Silva de 10pines.com: ”en Argentina es blanquear procesos que ya teníamos, en EEUU hacía falta formalizar un cambio porque la forma de trabajo era otra, más estructurada.”]
- En GFDD Group usamos un proceso derivado del SCRUM. El proyecto no es interminable, sino que se divide en sprints con alcances claros. En cada proyecto hay reuniones fijas todos los días a las 11 AM que no deben durar más de 15 minutos, en las cuales todos se ponen mutuamente al tanto de qué se hizo el día anterior, qué se va a hacer ese día, y qué impedimentos hay para ello. Previenen problemas y ponen a todo el mundo frente a la información. En general no más de 4 o 5 personas forman parte del equipo de un proyecto. [Apunta Jorge Silva: “está bueno hacerlas parados para que la gente se quiera ir rápido”.] En GFDD tenemos el problema de que hay pufs, a veces se complica un poco eso! Si salta un tema de discusión que no es para el Scrum, y esa discusión se extiende, el resto de la gente no involucrada termina presionando para que se vuelva al tema original y se respete la duración de la reunión (esto al principio cuesta, pero debe hacerse).
- El relevamiento y el diseño func ional de un proyecto deben ser planificados como sprints en sí mismos. Los diseñadores participan de los Scrums para ayudar a los desarrolladores y para intervenir (o conocer) decisiones de diseño que, bajo otra metodología, podrían hacerse sin su conocimiento. Aún en proyectos en los que los diseñadores no tengan una participación horaria significativa, el invertir tiempo en esas reuniones evita muchos problemas, ayuda a la integración, y redunda en una mejor calidad final del proyecto y en detectar puntos de conflicto con anticipación.
- Alinear ventas con producción. Si trabajás en scrums, intentar vender y cobrar scrumms. Si trabajás sin estimar, cobrar por hora. No desatender las prioridades del cashflow y de la calidad del trabajo entregado.
- En este sentido, las horas de IxD se tienen que presupuestar y presentar transparentemente al cliente, no esconderlas y prorratearlas en los costos. Explicar que entregables habrá durante ese tiempo (que el cliente entienda que no es un retraso caprichoso) y que es un proceso que es necesario para que el proyecto salga bien. Si el cliente tiene una restricción presupuestaria y busca recortar costos, muchas veces lo primero que quiere recortar es QA y etapas previas de diseño de interacción. Desde GFDD tratamos de educar y convencer al cliente de analizar si realmente es la mejor decisión a tomar, o si conviene modificar el alcance del proyecto y concentrar los esfuerzos en un proyecto más pequeño pero con un proceso apropiado y completo. Pero claro… cuánto se tarda en hacer un diseño? Muchas veces los diseñadores no lo saben, y erróneamente se describe como algo imposible, pero no queda otra que estimar y después aprender de eso. Es importante no sólo medir tiempos, sino usar eso para aprender para la próxima vez, asegurarte de que no estás perdiendo plata. El diseño lleva un tiempo, en promedio, más o menos constante. La experiencia ayuda a mejorar estas estimaciones. Cuando una tarea se va al demonio por los tiempos, si vas por la mitad y eso va mal, pará y charlalo con tus colegas o con el Project Owner con tiempo. Evitar dolores de cabeza, o al menos que se entere todo el mundo antes. (Sugerencias de sistemas web con herramientas para medir tiempos: ClockingIT, ActiveCollab. BaseCamp es muy bueno pero no tiene la parte Tiempos implementada de la mejor forma).
- QA: llevar checklists para errores que sabemos que suelen pasar en todos los proyectos. Muchas veces pasa ver algo y decir “esto ya pasó 5 veces”. Cuando llega el momento de testear el proyecto, regirse por esa checklist. Es clave reservar en la planificación del proyecto tiempo para testing y arreglos, y vender esta etapa como un diferencial que garantiza una mejor calidad, no como un costo.
- Hay que incluir en QA alguien de diseño y usabilidad. No sólo los “errores de PHP” son errores, también los de interfaz. Contemplar al menos un análisis heurístico estándar (accesibilidad, organización de interfaz, etc.) y un enfoque especial basado en los objetivos del proyecto (un usuario puede cumplir fácilmente aquello para lo que el proyecto existe?).
- Comunicación: dar confianza al cliente y al equipo. Aunque parezca lo contrario, se puede estar disponible 24/7 en la percepción de los demás sin que realmente te molesten todo el día. Vale la pena hacer esfuerzos en el corto plazo para ganar la confianza de otros en la comunicación a futuro.
- Aplicando esto al diseño, además, debemos poder comunicar en términos simples y claros las ventajas de hacer un proceso hecho y derecho de diseño centrado en el usuario, y que un proyecto mal encarado en este sentido hace perder plata. Si en algún momento no podemos fundamentarlo, entonces el cliente tiene razón. No siempre el contacto con el cliente es el que toma la decisión: ponerse del lado del cliente, educarlo y darle las herramientas para vender el proceso y el proyecto dentro de su organización.
- Resumiendo. Hay lugar para romper moldes. Probemos nuevos procesos, siempre que se los analice, aplique consistentemente y luego se contrasten sus resultados. No hay que tener miedo a escalar, a ser más eficientes , a aprender de proyectos pasados. No hay que perder el foco de nuestras prioridades. Hagamos las cosas sólo si siguen un objetivo, no por moda o inercia de que “todos lo hacen”. De vez en cuando hay que parar la pelota, pensar fríamente y determinar si estas cosas se están cumpliendo y si, en definitiva, estás mejor que la semana pasada.