Más pronto que tarde te llega un proyecto diseñado por otro equipo y te toca afrontarlo sin echarte la soga al cuello, o echándotela solo lo justo.
Más pronto que tarde te llega un proyecto diseñado por otro equipo y te toca afrontarlo sin echarte la soga al cuello, o echándotela solo lo justo.
En Space Nomads acabamos de hacer una pausa para revisar procesos y pensamos que estaría genial no guardarse todo esto para uno mismo y compartir, que me han dicho que es vivir.
Presupuesto y valoración del proyecto
Para valorar un proyecto vamos a necesitar algo más que un mail del cliente con un número indeterminado de páginas adjuntas. Tras revisar el material entregado pide siempre una reunión con el cliente en la que expliquen su diseño y la funcionalidad; página a página, módulo a módulo.
Esta reunión es fundamental para ver el proyecto en conjunto, comprobar que estamos todos mirando al mismo sitio y detectar posibles puntos flojos o ese componente que va a necesitar un desarrollo personalizado y podría consumir él solo un porcentaje importante de tiempo.
¿A quién buscamos? Pues a los de siempre.
Diseños
Aquí está todo el tema porque es con lo que vas a trabajar y la revisión no se puede quedar en abrir los archivos y mirar por encima:
- Las fuentes
Abres los .AI/.PSD/.SKETCK/.LOQUESEA y ahí están, de tapadillo y sin licencia, un par de DIN, una Helvética Neue, la Gotham a precio de oro o esa fuente gratuita para proyectos personales pero que para comerciales cuesta 28 € y nadie los va a pagar. Para dejar las cosas claras, que hace falta, esto es ilegal. De acuerdo que es muy raro que busquen al diseñador por ello, pero ¿merece la pena? Tu trabajo no es solucionarle la trampa a nadie. Si no quieren pagar por la fuente que revisen concienzudamente su diseño con una fuente alternativa y te lo vuelvan a enviar; no es obligatorio usar una fuente de pago sin pagar. - El archivo en sí
Hacer las cosas de cualquier manera puede tener diferentes justificaciones pero que los elementos estén nombrados y ordenados no es un capricho, ahorran un tiempo que nadie te va a pagar a la hora de organizar tu html y tu css. Además traen como consecuencia:- Un diseño consistente: al tener una estructura ordenada el diseñador tiene una visión más global del proyecto de diseño evitando títulos iguales a diferentes tamaños, márgenes diferentes para cada elemento y los típicos 15 grises casi iguales.
- Un responsive bastante más realista: Cuando tienes tus bloques agrupados y ordenados evitas el típico bloque que en desktop está en la cabecera pero en móvil está dentro de la sección de noticias del pie. Todo esto influye positivamente a la hora de generar un html semántico y coherente, y por supuesto, a la hora de generar los css que se necesitan aprovechando lo más importante de las hojas de estilos.
- Las imágenes
¿Podemos usar las imágenes o las hemos pillado de “google”? ¿Las tenemos a suficiente resolución? Luego todo el mundo quiere que se vea guay en pantallas retina. Personalmente me parece bien ver las imágenes integradas en los diseños pero prefiero tenerlas también por separado y a bastante resolución para generar las versiones que necesite para el proyecto. - Iconos
Pasa un poco igual que con las imágenes. En nuestro mundo “retina” tener los iconos en png a 1x es un mal menor pero si lo revisamos antes no nos llevaremos sorpresas o se incluirá una partida para rehacerlos, esperemos, en vectorial. - Interacción
El comportamiento de los diferentes módulos es de lo más complicado de mostrar en un archivo que principalmente es estático, por eso la revisión con el cliente es fundamental. Hay que revisar desde las interacciones más elementales (hovers y estados de botón) hasta ese comportamiento del módulo de cabecera donde la imagen tiene que estar siempre separada –200px de una caja de texto dinámico y que se va a comer un porcentaje del presupuesto. Para que luego no haya sorpresas.
Vale, ahora que lo hemos revisado todo y estamos conformes con esfuerzo, plazos y pagos. Ahora el contrato.
¿Contra... qué?
Que sí, que es un proyecto muy pequeño, que los plazos son muy cortos… sí, que vivir al límite mola; pero es vivir al límite de la inconsciencia.
Si todo va como tiene que ir es solo una formalidad, si algo se tuerce, ahí está tu amigo y vecino el contrato para salvar el día.
El contrato es donde junto con tu cliente os comprometéis cada uno a su parte del proyecto definiendo el alcance, plazos, pagos y requerimientos.
No se tarda tanto en preparar uno y hay mucha documentación al respecto como por ejemplo: Contract Killer
Al turrón
Una vez que estamos todos conformes, con el contrato firmado y sabiendo que no hay sorpresas escondidas nos podemos poner a ello; Seguro que estás listo para abrir tu editor y picar html como un jabato, no? Pues no, vamos a montar un pequeño workflow de trabajo como los señores, con su repositorio y su tablero en trello con el cliente y su calendario de entregas y revisiones. Claro que sí.
¿Por qué? Porque se acabó el trabajar como animales, que se pierdan los cambios de ayer y que nadie sepa si al final la página de contacto lleva el feed de instagram o no.
Repositorio
Lo de tener los archivos solo en tu carpeta local se acabó, tenemos maravillas como GIT que te permiten llevar un control de versiones sobre el trabajo, cambiar de máquina con tranquilidad, desarrollar en paralelo con tu equipo y volver a versiones anteriores sin mucho quebradero de cabeza. Igualmente puedes darle acceso a tu cliente para que revise directamente sobre el proyecto y/o haga ajustes si se considera oportuno.
Actualmente tienes varias opciones para hacer esto: GitHub y Bitbucket son de las más populares. Te voy a recomendar bitbucket porque incluye repositorios privados en su plan gratuito para equipos pequeños y puedes usarlo con una cierta tranquilidad.
Si no te manejas bien con GIT hay infinidad de tutoriales para echarle un rato razonable y empezar a usarlo bien.
Trello
¿Recuerdas la lista de páginas y componentes de la valoración del proyecto? Pues es hora de sacarle provecho y te propongo montar un tablero de Trello con tu cliente (siempre con el cliente).
En Space Nomads estamos usando unos tableros que nos están dando muy buen resultado:
4 Columnas:
* Tareas
* A revisar
* Revisado
* Completado
- Todo el mundo pone tareas en la columna de Tareas, desde las páginas que hay que hacer hasta tareas intermedias, como por ejemplo los componentes. Cada miembro del equipo se asigna la tarea que vaya a empezar de manera que todo el mundo sabe qué se está haciendo y quién lo está haciendo (y nadie se pisa).
- Una vez terminada una tarea se pasa a la columna de A revisar donde el cliente revisa que todo está correcto. Si lo está se pasa a Revisado. Si falta algo se incluye un checklist con todo lo que haya pendiente para esa tarea añadiendo los comentarios y adjuntos pertienentes (pantallazos, documentos), y se devuelve a la columna de Tareas.
- Una vez las tareas llegan a la columna de Revisado debería ser el equipo de desarrollo quien las pasase a Completado.
Aprovecha el listado de tareas para planificar un poco y pactar un pequeño calendario de entregas de manera que todos estéis prestando atención al proyecto durante su duración. Tu cliente estará tranquilo porque podrá ir revisando y solucionando las cosas tal como se terminan, y nosotros vamos más seguros porque vamos cerrando temas que luego no nos van a estallar en la cara.
Todo esto influye en la experiencia de trabajar junto a tu cliente y seguramente queráis repetir.
Esto es una forma relativamente económica de afrontar un proyecto de este tipo involucrando a tu cliente desde el minuto cero y dejando atrás las entregas el último día a última hora.
¿Qué más queda?
Bueno, detalles quedan mogollones y si alguien quiere que echemos un rato me tenéis por twitter/mail/aquí o con unas cervezas pero sí me gustaría apuntar algunas ideas que se me han quedado por el camino:
- Aunque todos lo sabemos, un presupuesto se hace sobre material que podemos valorar. De bocetos, conceptuales y primeros diseños se pueden sacar presupuestos aproximados, nunca uno definitivo.
- Responsive no es algo exclusivo de los dispositivos, responsive también es alguien trabajando con dos ventanas en la misma pantalla, por ejemplo: un 1336x768 con Chrome a 639px de ancho y Word a 681px.
- No necesitas tener todas las páginas diseñadas en versión móvil, tablet y escritorio, pero hay una serie de módulos que sí los vas a necesitar.
- De 320 a 2650 hay mucha vida, revisa que esté suficientemente contemplado el comportamiento del diseño y no solo las versiones de 320, 768 y 1500.
- Habla con tu cliente, revisa y avisa cuando corresponda porque el trabajo hay que hacerlo igualmente, pero ¿por qué sufrir?