 Bueno, muy buenas a todos. Muchísimas gracias por la organización, por darnos este espacio, por dejarme venir. Quiero deciros que es mi primera work-up, también mi primera ponencia. Ahora también quiero deciros que es la primera vez que paso una vergüenza como ésta, porque me da igual WordPress, me da igual la comunidad, me da igual todo. Yo venía solo a la cena de ponentes y me puse malo y no pude ir. Lo de que me da igual es mentira, pero lo que me puse malo es verdad. Me perdí la cena de ponentes, fui al postre para ver a la gente lo bien que se lo había pasado. Y bueno, pues esto significa que la siguiente vez, dentro de tres años, tendré que estar por aquí porque está siendo una venta maravillosa. Muchísimas gracias. Todos los que lleve las camisetas y las rojas, estés haciendo genial. Bueno, vengo a hablar de todo lo que he aprendido coordinando equipos de diseño y de desarrollo. Me gustaría preguntaros primero, porque bueno, ahora somos un poquito menos personas que en otros momentos del día, porque ya estamos al final. ¿Quiénes de las personas que estáis aquí trabajáis como freelance? Por ahí. ¿Dentro de estos freelance que trabajáis en diseño o en desarrollo? ¿Sí? ¿Hay personas que trabajáis en agencia o que seáis agencias como tal? Empresas de servicios, fenomenal. ¿Y empresas que tengáis dentro de vuestros equipos diseño y desarrollo? Vale, bueno, dentro de lo que cabe, veo que hay bastante gente que cumple uno u otro requisito. Espero que os sirva todo lo que os voy a contar al final. Creo incluso que si no estuviesis trabajando específicamente en diseño y desarrollo vamos a hablar del proceso de trabajo. Espero conseguir hacerlo suficiente, venta a menos. Así que vamos a por ello. Lo primero me gustaría presentarme, que aparte de perderme la cena de ponentes, me llamo Miguel Sanz. Soy fundador de Visiesto Studio. Visiesto somos una agencia que nos dedicamos a crear marketing memorable, diseño y desarrollo de productos digitales y a branding estratégico. Tenéis aquí mi Twitter, arroba Miguel Visiesto por si queréis contactar conmigo en cualquier momento o la web Visiesto.es y voy a empezar hablando de todo el proceso de trabajo que se sigue a lo largo de un proyecto de diseño y desarrollo de un producto digital. Dentro de la compañía casi siempre trabajamos con huerpes, un 75-80% de los trabajos que hacemos llevan implicaciones de huerpes de una u otra manera. Solen ser proyectos relativamente sofisticados y muy muy personalizados. Por lo tanto, cuando empezamos el proyecto empezamos con un nivel de incertidumbre muy alta. No sé si es pasa, las freelance, las empresas, incluso que tenéis producto interno que trabajáis, no siempre sabéis ni lo que queréis. Él no sabemos ni lo que quiere el cliente. Estamos en un nivel de incertidumbre altísimo. Entonces, esta frase que os pongo aquí en la área positiva, no soy un desastre, no sé a quién se la escuché, así que seguro que hay alguien por ahí autora de esta frase que se estará tirando de los pelos porque en este momento no estoy diciendo su nombre, pero la calidad del servicio es directamente proporcional a la expectativa que tiene el cliente. Y es curioso, dependiendo de quién sea el cliente y qué es lo que está esperando, así mostraremos el servicio, así lo construiremos. Entonces, si la calidad del servicio es muy relativa, es relativo a qué. Bueno, pues hay varias cosas que tenemos que tener en cuenta, seguramente. La primera es entender cuál es el servicio que vamos a prestar, cuál es su alcance, desde dónde hasta dónde va lo que vamos a hacer. Parece una absoluta tontería, pero es clave a la hora de trabajar un proyecto. A la vez, tendremos que saber cuál es la metodología de trabajo, cómo vamos a operar, qué vamos a... para llegar al punto, al punto de qué cosas vamos a tener que hacer. Y para hacer este trabajo, sabemos la metodología que vamos a emplear, sabemos de dónde estamos, a dónde queremos llegar, tendremos que, de alguna forma, documentarlo. Esta parte de documentación es algo que es muy habitual, que falle en los proyectos. Y para nosotros, dentro de nuestra compañía, por ejemplo, es de lo más importante. Hay muchas personas que me dicen que dedico demasiado tiempo a documentar el proyecto antes de empezar a trabajar. Muchas personas que dicen que dedicamos demasiado tiempo a establecer qué es lo que vamos a hacer antes de haber lanzado el presupuesto. Normalmente, todo el tiempo que dedicamos a minimizar la incertidumbre del proyecto es beneficio que nos llevamos más adelante. Esta hojita que aparece en la diapositiva que va de lado a lado puede ser una octava o décima parte de una documentación de un proyecto web, para que os hagáis una idea del nivel de detalle que alcanzamos en la definición. ¿Por qué? Porque la calidad del servicio va a ser proporcional a las expectativas que tenga el cliente. Necesitamos entender, fabulosamente bien, cuáles son las expectativas del cliente. Bueno, vamos a intentar ver cuál es el camino del proyecto. Una vez entendemos qué es lo que tenemos que hacer, cómo lo vamos a hacer, y tenemos bien especificado cuáles son los pasos que vamos a dar y las cosas que vamos a tener en cuenta. Creo que ya lo dijo Ana Cilujano en su charla, cuando hablaba también del trabajo de diseño y desarrollo, hablaba mucho de la comunicación. Comunicación, comunicación, comunicación, comunicación. ¿No os recordáis el tipo de Windows que decía developers, developers, developers? Bueno, pues igual, comunicación, comunicación, comunicación, comunicación. Muy importante que, a medida que va pasando el proyecto por los distintos tramos, todas las personas que forman parte de ese proyecto tengan absolutamente claro todo lo que hemos hablado antes. ¿Cuál es el alcance? ¿Cuál es la metodología? ¿Y sepan perfectamente dónde está la documentación a la que tienen que acudir? Parece una tontería, pero es clave. Dentro de esto, los primeros conceptos que quiero introducir con vosotros es que en esta labor de comunicación y definición del proyecto, es muy importante saber qué equipo va a trabajar. De nuevo, parece una cosa trivial, pero qué personas del equipo van a emplearse a fondo para conseguir que este proyecto que entra en la compañía salga siendo un completo éxito. Luego, ownership, es un concepto, es que en inglés queda mucho más cookie, pero es decir, ¿quién es la persona a la que hay que tirar de las orejas si esto sale mal? ¿Quién es la persona a la que hay que hacerla ola si esto sale bien? Este concepto de ownership es una persona normalmente que va a acompañar al proyecto de principio a fin entendiendo perfectamente cuáles son las implicaciones de ese proyecto y todas las partes, digamos, a nivel global. Y por último, stakeholders de nuevo, la palabra así cookie, porque en inglés es que de verdad, de verdad, que mola más, los stakeholders son todas las personas que pintan algo en el proyecto. Pueden ser el cliente, pueden ser personas de otro departamento, lo que sea. Aquí, ese pintado, no sé qué tal se ve, así que voy a intentar pasar por ello suficientemente detallado, pero a la vez rápido. Por un lado, tenemos el proceso de venta en el que, como ya os he hablado, creo que es muy interesante detenerse un poco a definir muy bien qué es lo que vamos a hacer y cómo lo vamos a hacer. Para que todas las personas sepamos que nos vamos a encontrar y que tengamos muy claro cuáles son los entregables que va a haber durante todo el ejercicio. Una vez el proyecto, digamos, que se ha vendido, mejor dicho, nos lo han comprado, bien, qué es lo primero, como os decía, la parte de equipo. Vamos a crear un equipo. En este caso, veis las bolitas. Cada bolita es un tipo de profesional. En este tipo de proyectos, en los que se incorporan distintos tipos de disciplinas, también incorporamos distintos tipos de profesionales. Esta persona que hay aquí con una O, que se la veis gris durante todo el proyecto, es lo que llamamos ownership. Es la persona que va a estar como dueña del proyecto y que va a asegurar, va a ser garante de que el proyecto va a ir rodadísimo y va a tener toda la información de qué tipo tiene las herramientas adecuadas para trabajar. Dentro de este equipo, no solamente está esa persona que se hace dueña de todo, sino que incorporamos personas de distintas disciplinas. Es lo que tenemos que definir en este momento. Si sabemos qué tenemos que hacer, cómo lo tenemos que hacer y cuál va a ser la forma, entonces, también sabemos qué personas necesitamos, qué nivel de profesionales vamos a necesitar para incorporar en el proyecto. De hecho, lo normal es que cuando hayamos hecho el presupuesto, por lo menos en nuestro caso, ya sepamos qué nivel de implicación de qué tipo de profesionales no se hacen falta para llevar el proyecto adelante. Entonces, en este caso, poste una bolita de cada color, perdonad que me he equivocado, una bolita de cada color, para definir, por ejemplo, imaginad que en la lanja fuera el diseño, que el verde fuera la gente que sube el contenido y que el morado fuera la gente de desarrollo, por ejemplo. En este caso, en un squad sencillito, habría una persona de cada tipología de perfil, de cada tipología de rol, pero en el caso de que sea un proyecto más grande, más complejo, puede que haya más de una persona de cada una de las áreas. ¿Has seguido bien? Genial. Una vez tenemos definido el proyecto, tenemos el equipo preparado, lo primero que vamos a hacer es un kickoff. Reunión de lanzamiento. Primero hacemos un interno y, en este caso, imaginad, suelo ser yo, la persona que toma los datos del cliente, coge todos esos datos y les cuento la película a mis compañeros y compañeras. Bueno, chicos, esto es lo que hay que hacer, repasamos la documentación, ellos ya se han leído previamente, ya lleva un ratito y, con esa documentación, intentamos transmitir fabulosamente bien qué es lo que hace falta para el proyecto. Cuando terminamos, no empezamos a trabajar. ¿Por qué? Porque con esta idea que teníamos, comunicación, comunicación, comunicación, comunicación no es hacer como está haciendo yo, hablar. Comunicación es ver si la gente se está enterando. Para ver si la gente se está enterando, lo que hacemos es que hacemos un segundo kickoff. Todavía no hemos empezado a currar y ya llevamos hechas un porrón de horas. Pero este segundo kickoff es un kickoff con el cliente. Se presenta a las personas que están dentro del equipo de trabajo y, ya con dudas definidas de haber hecho esta primera presentación interna, vamos a atacar, vamos a hacer que el cliente nos lo cuente de nuevo, aunque parezca un poco redundante, para asegurar que todos estamos entendiendo muy bien lo que teníamos en la mesa. A partir de ahí, vamos a marcar en esa misma reunión cuáles son los sitios que vamos a seguir. Nos vamos a ver cada semana durante el proceso de diseño, va a ser cada dos semanas, va a haber experiencia de trabajo, una vez al mes, qué va a pasar cuando llegue el desarrollo, qué día vamos a quedar, aseguramos que nos entendemos y que todos tenemos claros cuáles son los siguientes hitos. A partir de ahí, iniciamos una fase de diseño. Voy a recorrer las fases en general, tenemos una fase de diseño donde damos forma al producto digital, en este caso con WordPress, una fase de desarrollo donde convertimos todo lo que hemos hecho en diseño en algo accionable dentro de una página web o incluso como un backend de una aplicación, una fase de subida y contenido y Q&A, que es la parte en la que revisamos, aseguramos que la calidad y las funcionalidades ruedan como la seda y por último, una fase de feedback para ver qué te ha leído el trabajo. Durante estas fases, como veis, digamos que el squad, ese equipo formado por personas de distintas disciplinas se mantiene durante todo el proyecto y algo que se mantiene durante todo el proyecto también es ese ownership, esa persona que de nuevo insisto va a ser garante del proyecto. Es muy fácil de transmitir, por lo menos a mí no me lo resulta, no me resulta tan sencillo. Es muy importante que las personas del equipo que ocupan este papel sepan perfectamente que se espera de ellas. A partir de ahí, también hay otra cosa que va a acompañar todo el proceso de trabajo y es la documentación. ¿Os acordáis que ha comentado que hemos hecho un porro en horas para hacer una documentación para un presupuesto, para entender qué personas tenían que trabajar en el proyecto? Nos va a servir también como columna vertebral del proyecto. El caso de los freelance está claro que trabajáis separados de las empresas que os contratan, por lo menos a menos que no estéis cumpliendo la ley esas empresas que os contratan. Pero en el caso de compañías, dependerá de si sois compañías híbridas, remotas o trabajéis en una oficina. En nuestro caso, en el trabajo absolutamente remoto es fundamental que todas las personas estén superalineadas en los conceptos de trabajar. Esta documentación, de nuevo, se convierte en una columna vertebral que asegura que todas las personas que estamos en el equipo, estamos suficientemente alineadas. Y lo que hacemos, casi por un ejercicio interno egoísta para ver que estemos todos bien alineados, nos sirve también para alinearnos con el cliente, porque el cliente también está en su casa. Así que esta documentación va a estar viva, va a acompañar todo el proyecto. Si hay cambios en algún punto de insisto, todo el recorrido del proyecto desde el inicio hasta el final. En este proceso de cambio de distintas fases dentro de la fase de diseño tomará importancia el perfil o los perfiles de diseño que estén trabajando durante el proyecto. La fase de desarrollo tomarán importancia los perfiles de desarrollo. En la parte de contenido, los perfiles de contenido. Pero como veis, las bolitas no se van y luego entran. Todas las personas del equipo están presentes durante todo el proyecto. ¿Por qué? Comunicación, comunicación, comunicación, comunicación. Porque si no la peña, no se entera de lo que está pasando. Llegás a la fase final y ahí es que yo no le dije, ahí es que yo no supe y hay una documentación, pero como la documentación está en exhaustiva, por muy bien ordenada que esté, es difícil que todo el mundo siga alilo si no está atentado durante el proyecto. Veréis que durante todos los pasos, hay una, lo que llamamos revisión de Handoff, que es que aunque durante todo el proyecto las personas han estado atentas a lo que estaba sucediendo durante un cambio de un tipo de persona de un tipo de perfil a otro perfil, hacemos un proceso de revisión exhaustivo y una reunión de entrega de un equipo a otro equipo. ¿Hasta aquí bien? Genial. Venga, pues voy a pasar rápido para intentar contaros en estas fases en profundidad qué es lo que hacemos, voy a intentar hacerlo lo más ágilmente posible y es dentro de la fase de diseño me extiende un poco más porque mi background viene por ahí, no voy a poder contaros detalles específicos en la parte de desarrollo, los que os dedicáis a esto, pero estoy seguro de que estas cosas que os cuento pueden servir también para cuando trabajéis con los equipos. Lo primero que hay que hacer en un trabajo cuando abordamos un proyecto complejo es intentar entender el contexto y para ello empezamos con una fase inicial de investigación, por lo menos cuando el proyecto lo permita, hay veces que los proyectos son muy sencillitos, el presupuesto es más reducido y a lo mejor es más complicado o incluso el cliente ya tiene una idea de las cosas que necesita, pero si no es así en esta fase de research o de investigación como se usan inmersión en la analítica del cliente cuáles son tus problemas, cuáles son las páginas más visitadas cuáles son tus dolores, cuáles son las cosas que hay que mejorar o trabajamos la parte de experiencia de usuario haciendo entrevistas de usuarios para ver cómo funciona qué es lo que hacen los usuarios en las distintas páginas del cliente hacemos un análisis eurístico que es básicamente explicado muy rápido recorrer la página del cliente por parte de expertos para ver dónde encontramos problemas o baches que podrían ser solucionados e investigamos la competencia todas estas imágenes que veis son resultados de análisis de este tipo de revisiones analíticas de eurísticos y cómo se presentan al cliente con diferentes capturas explicando pues cuáles son los puntos en los que puede haber una cierta fricción o demás que nos ha servido internamente y nos sirven para presentar al cliente luego vamos a la parte de moodboard ya entendemos el contexto y ahora vamos a intentar hacer un pequeño tablero sobre todo si el cliente no tiene marca si el cliente tiene una línea de marca fabulosamente recogida en la que nos cuenta cuáles son sus colores, cuáles es su tono cómo se expresa, cuáles son las herramientas que tenemos que utilizar para comunicarnos todo va rodado pero si no es así decidme que no se ha pasado nunca que un cliente os diga que quiere una web con efecto wow quiero una web cool con efecto wow, que impresione que sea dinámica, que resalta en los demás dime algo que tenga un poco de significado por favor y como es imposible que te lo digan lo que hacemos es conseguir averiguarlo ¿cómo? vamos a buscar referencias de otras páginas de otros sitios, de algún otro tipo de respuesta que ya se haya dado antes y ver si el cliente identifica con ellas esos conceptos que nos están dando y que al principio eran abstractos una vez tenemos este moodboard tenemos ese trabajo investigado inicial tenemos un contexto fabuloso sabemos lo que Narices nos pedía al cliente entendemos cuál es su contexto de mercado cuáles son sus problemas y además ya hemos dicho que teníamos un equipo bien formado de documentación a seguir vamos a enfrentarnos a un mapa del sitio a crear un mapa del sitio y unos wireframes o prototipos esto lo he llamado hacianzando pasos porque básicamente lo que estamos intentando es minimizar la incertidumbre nuestra propia incertidumbre de trabajo es muy difícil trabajar cuando al presentarle algo al cliente, antes preguntaba Ana Cilujano en su ponencia si había gente que desarrollaba sin haber diseñado primero esto lo que ocurre es que a veces desarrollas luego el cliente lo ve y te pide un cambio primero habiendo hecho un diseño, a lo mejor no tendrías ahora que dar la vuelta, vamos a intentar ir hacianzando pasos ¿Qué hacemos en este punto? es un proyecto que requiere estrategia de negocio para entender hacia dónde vas, qué necesitas, qué objetivos tienes fabuloso, que necesita SEO porque es crucial para el negocio tiene que posicionarse una serie de verticales de contenido que hay que crear fabuloso, los tendremos en cuenta aquí hemos detectado que algún tipo de carencias o de experiencia de usuario que podemos mejorar en el negocio, fabuloso también hay que tenerlo en cuenta aquí porque vamos a definir cuáles son los flujos de navegación, de dónde va a ir un usuario y cuál es la estructura de la página una vez el cliente nos ha dicho que sí a esto podemos pasar a lo siguiente decirle que ya no nos puede cambiar lo anterior que es esa idea de ir hacianzando pasos y nos vamos a crear los wireframes o prototipos wireframes o prototipos para mí es llamándolo así sencillito vais a un bar, cogís un rotulador de punta gorda y pintáis en la servilleta de papelera que la tinta se borrona cuando lo pintas cuáles son las cosas que debería ver en cada una de las páginas ¿por qué es así? porque un prototipo lo explica es diferente si os cuento lo que quiero puede ser que acierte muy bien a la hora de contaroslo y que entendáis fabulosamente lo que se estoy pidiendo pero puede que no si lo dibujo fabulosamente bien para que luego el equipo de diseño lo ponga en marcha puede que haya profesionales maravillosos que lo dibujarían de otra manera las distintas a las que yo estoy aportando y que como yo ya se lo he dado demasiado dibujado no aportarían su creatividad y su saber hacer entonces hay un poco de dificultad a la hora de utilizar el dibujo para expresar las ideas en las que no quiero ni contarte demasiado poco ni contarte demasiado mucho porque quiero que hagas tu trabajo y puedes aportar soluciones como diseñador pero no quiero que te falte contexto por eso lo de dibujar con un rotulador de punta gorda en la servilleta de papel de un restaurante suficiente como para que de manera esquemática tengamos muy claros cuáles son los diferentes elementos que vamos a tener en la arquitectura recomendación libro shape up para los que sois de la loxe como yo shape up lo podéis descargar como pdf gratuito en la web o lo podéis pedir si sois un poquito freaky de abrir el papel como es mi caso súper interesante para procesos de diseño y desarrollo para que lo tengáis en cuenta developers todos mirando por las rendijas a ver qué narices está haciendo el equipo de diseño y esto es obligado que durante todas estas partes del trabajo no se esté apartando el equipo de desarrollo de esto el equipo de desarrollo tiene que saber cuál es la estructura cuáles son las partes y estar muy atento una vez tenemos definidos estos dos puntos iniciales vamos a intentar trabajar la parte visual y el sistema de diseño aquí sí vamos a intentar trabajar el diseño seguramente como la mayoría de vosotros y vosotros lo conocéis que es la parte de pinta y colorea porque hasta ahora estamos utilizando el diseño para solucionar problemas, para entender estructuras para colocar el producto dentro de este proceso de diseño vamos a trabajar tanto la estética como las animaciones lo que veis en la diapositiva son distintos ejemplos de trabajo de un programa como Figma que también contaba Ana Cirujana esta mañana y vamos a trabajar siempre con filosofía MOILFIRST no es que mi empresa recibe más visitas de ordenador bien, pero a que si resolvemos los problemas más complicados que son aquellos que están en un espacio más pequeño una vez resueltos va a ser más fácil llevarlo al escritorio pues nos enfrentamos a los problemas difíciles siempre primero y luego vamos a por lo que venga cuando hacemos este trabajo de diseño no solamente vamos como decíamos al pinta y colorea no solamente creamos las páginas como secciones página home, página de quiénes somos no sé qué, no lo que vamos a intentar es pensar desde el propio proceso de diseño cuáles son las piezas del puzzle cuando desarrollemos vamos a desarrollar bloques que se van a poder llevar de un lugar a otro de WordPress nosotros trabajamos siempre en base estándares siempre con el plugin con la funcionalidad Gutenberg nativa de WordPress y hacemos bloques personalizados cuando es necesario por lo tanto es muy importante que desde el equipo de diseño estén pensando cuáles son las piezas del puzzle cuáles son esas piezas del rompecabezas que luego podría sacar como sección o como bloque de un lugar a otro y minimizar el trabajo ¿por qué digo minimizar el trabajo? no es lo mismo que cada vez que vaya a hacer una página me tenga que inventar todos los bloques que si yo está pensando que en tres páginas tengo un bloque de preguntas frecuentes ya haya hecho ese bloque para que me pueda llevar las tres páginas, por poner un ejemplo que se me ocurre así a lo bruto mientras tanto el equipo de desarrollo de nuevo, fichando que está pasando porque si no, cuando llegue todo a la mesa por mucho que hagamos una reunión en la que pasemos el diseño del desarrollo ya será tarde, el cliente ya habrá visto lo que le hemos mostrado ya le estaremos dando opciones para hacer cosas que en realidad no se pueden hacer porque el equipo de diseño se ha puesto muy creativo y es muy importante que el equipo de desarrollo esté presente durante todo el proceso a partir de ahí, por aquí paso un poquito más rápido lo que decía aparte de desarrollo vamos a hacer el setup del sitio, su instalación vamos a desarrollar un tema personalizado con bloques de Gutenberg y aquí quería hacer hincapiéndose apartados que es el trabajo en base a estándares y el honrar a la comunidad creo que es fundamental no solamente no escupir al yo del futuro a los nosotros del futuro sino incluso también pensando en que cuando trabajamos para un cliente si ese cliente quiere seguir trabajando con nosotros que sea porque hacemos un trabajo iba a decir una palabra brota, fabuloso y si no hacemos un trabajo fabuloso que se vaya con cualquier otro profesional que sea capaz de darle servicio y que no se encuentre con un problema de narices porque no hemos sido capaces de ordenar el código porque no hemos sido capaces de documentarlo o peor aún porque no hemos trabajado en base a estándares nosotros siempre solemos decir y lo digo con mucho orgullo que cualquier persona si de repente un día le quedamos mal se puede ir con cualquier empresa que trabaje en base a estándares del mundo que hay gracias a Dios un montón creo que es absolutamente importante que todas las personas que trabajemos en un sistema se aguerpe o sea el que sea trabajemos en base a los estándares de ese sistema para facilitarnos la vida al dios del futuro a los demás profesionales del sector especialmente hablando de WordPress con la comunidad que tenemos tan rica mientras tanto el equipo de diseño como la vieja del visillo está observando para ver que hace el equipo de desarrollo porque hay que comprobar lo que se está haciendo hay que comprobar lo que se está haciendo hemos diseñado una serie de cosas el equipo de desarrollo podría haber tomado determinadas decisiones de manera unilateral y el equipo de diseño estoy seguro de que si lo va revisando es que todo encaja con el diseño aprobado con el cliente y nos minimiza problemas iríamos a la parte que os he contado antes de subir el contenido, una revisión interna y ya que os pongo que hay que ir a hacer daño y es porque cuando vamos al cliente el desgraciado con todo el amor que les tenemos va a encontrar ese problema va a ver lo que sea que nos haya fallado lo va a ver mamá, mamá, no encuentran los calcetines 10 minutos buscando los calcetines en el cajón y están los puñeteros calcetines justo en la punta del cajón es exactamente lo que va a hacer el cliente con ese ojo clínico que tiene como talento especial y como punto final decía todo lo que he aprendido en estos años de trabajo coordinando equipos de diseño y desarrollo, creo que lo único que he aprendido es que no tengo ni puñetera idea y que lo más importante cuando nos enfrentamos a proyectos con alta incertidumbre es hacerse muchas preguntas cuando se trata de tener las respuestas se trata de hacerse cada vez mejores y más adecuadas preguntas muchísimas gracias y hablando de preguntas ¿alguien se anima a hacer alguna preguntita? una preguntilla, tranquilos hay tiempo para todos por los chicharrones he estado viendo tu ponencia me ha gustado muchísimo he visto ahí que tenías algunos procesos del SEO pero el SEO no va controlando todo no va controlando algunas partes hablaba que sobre todo al principio digamos que hay varios puntos no está bien representado en la diapositiva así que voy a intentar explicarlo lo mejor posible cuando hacemos un proyecto en el que el SEO está muy involucrado que es mucho de ellos, gracias a Dios normalmente el SEO se involucra desde el punto inicial es lo que quería representar al principio desde la propia definición de cuál es la arquitectura del sitio tanto a nivel de páginas y estructura cuáles son sus verticales como van ordenados qué lugares ocupan los diferentes menús como luego en la definición de los wireframes pero otros tipos en los que vemos cuál es la arquitectura y información de cada una de las páginas fundamental que el equipo SEO pueda marcar la pauta de esto, pero luego durante el diseño sí que pueden estar atentos para ver que esto se va cumpliendo en principio debería haber quedado definido serían otra diapositiva más con alguien mirando entre las cortinas y por supuesto al final en el momento de subida de contenido absolutamente crucial entender que se está subiendo etiquetando el contenido correctamente, metadatos y bueno todo lo que haya que tener en cuenta no soy SEO de profesión, pero bueno todo lo que de los que sois SEOs aquí sabéis hacer bien y por supuesto en la parte de subida ver si en la, digamos la respuesta técnica tiene el sitio es la adecuada tanto a nivel de carga que sí que el SEO tiene un acompañamiento absolutamente crucial durante todo el proyecto pero es verdad que donde lo he querido marcarse en el inicio porque es donde se marcan y se tengan las pautas incluso esas pautas a nivel técnico que se marcan inicialmente, luego se comprueba que estamos cumpliendo con ellas ¿Te quería hacer otra pregunta si puede ser? A mi me encantaría, me encanta hablar de nuestro ombligo Vale, el tema de la documentación la recicláis para un cliente para otro o es única de un cliente? Bueno esto es un tema por el que hay gente que de verdad que me critica mucho sí que es cierto que tengo algunas partes que están ya preparadas para todos los clientes pero también tenemos que tener relativas a nuestra metodología de trabajo tenemos ya e incluso por ejemplo esta metodología que os acabo de contar la tenemos quedada incluso en una documentación incluso con un vídeo con capturas también, o sea lo puedes leer o ver sale un servidor contando todo esto y creo que es muy interesante tener la metodología ya recogida para poder incorporarla de manera directa incluso como normalmente las webs al final cuando hablamos de webs en concreto suele haber bueno puede haber muchos tipos para algunas cosas que son comunes por ejemplo todas las webs normalmente tienen una página 404 si hay un blog no normales que todos los blogs tienen una página categoría, una página de portada una página de artículo, una página de autor y así con muchas partes entonces sí que es verdad que tenemos estos bloques ya hechos como una plantilla base pero es muy básica y esto lo aplicamos también al desarrollo pero es una manera de trabajar que tenemos en concreto no es la más eficiente pero hay un trabajo de personalización muy alto estoy seguro de que podría mejorar lo presente a medida que hagansemos el tiempo o ganar en calidad de vida incluso es probable que me crezca el pelo porque lo paso muy mal lo paso muy mal haciendo este trabajo tan minucioso y tan manual pero las realidades que aprendemos mucho y creo que a base de ese aprendizaje podremos estandarizar en el futuro muchas gracias y si te queres hacer pelo avisa porque aquí alguno no hace falta bueno, creo que hay formas luego hablamos muchas gracias, está muy bien ¿Cómo gestionáis o gestionas las expectativas o las prisas de ciertos clientes porque, o sea, yo entiendo desde mi lado desde el lado de los que estamos aquí que vemos necesarias toda esa cantidad de horas pero seguro que hay veces que hay clientes y dice ya pero quiero ver el resultado ya o enseñame cosas, deja de preguntarme más o menos bueno, digamos que la respuesta corta sería mal ¿Cómo gestionáis las expectativas del cliente a nivel de tiempos? mal ¿Cómo lo intentamos hacer bien? lo primero es intentando que en esas reuniones iniciales se entienda muy claramente lo que vamos a hacer lo segundo es que probablemente a esto en nuestro caso concreto no podemos abarcar todo tipo de proyectos los proyectos que abarcamos requieren cierta dedicación en tiempo eso es así si no, se le da otra solución se coge un editor de bloques y se arrastra y se sueltan cosas se monta un landing en un tiempo que sea y a correr, en nuestro caso digamos que la respuesta es un poquito más sofisticada y requiere tiempo creo que ese sería el punto clave pero insisto yo creo que lo llevamos mal otra de las cosas que hacemos y que hemos ido aprendiendo es que probablemente si esperamos para que el cliente ve algo esperamos a llegar al final de cada una de las fases el cliente ya lo está pasando mal entonces trabajamos continuamente en este proceso que os he contado entender cuáles son las maneras de hacer llegar al cliente el valor lo antes posible me explico si en la fase de diseño trabajamos semana a semana es muy fácil que el cliente vaya viendo los avances semana a semana el cliente entiende que estamos trabajando y además de manera conjunta con lo cual no suele haber mucha queja pero cuando llega al equipo de desarrollo y nos ponemos a trabajar y de repente el proyecto se demora tres meses tranquilamente y nos pone un poco tenso que estamos haciendo aunque no sea quizás la forma más óptima de trabajar en desarrollo entender que la forma más óptima para el cliente no es entregar los tres meses es entregar cosas cada X tiempo porque además venía acostumbrado de los procesos anteriores entonces estamos intentando y digo estamos intentando porque a veces no sale bien y a veces no tanto hacer entregas volantes durante los proyectos para que el cliente pueda haber zonas construidas y poder dar su validación nos ayuda a validar pero sobre todo a minimizar y mitigar la incertidumbre del cliente el año que viene te cuento más cosas espero seguir aprendiendo nos daría tiempo a una más rápida rápida Miguel lo primero muchísimas gracias porque has hecho una exposición increíble a mi me ha resonado mucho lo de la documentación del proyecto enhorabuena por hacerlo porque a mi me parece súper difícil sobre todo en todas las fases documentar el proyecto desde el inicio si hay un cambio en cualquier fase se recoge en documentación cuéntanos esto desde el primer momento lo habéis hecho así cuesta, no cuesta a quien le cuesta más gracias nos cuesta a todos en este momento absoluto no es fácil de cumplir hace falta estar con la vara de Avellano golpeando a las personas para que rellenen la documentación pero una vez has dado un par de golpes las siguientes veces solo con amenazas normalmente conseguimos que se cumpla bueno, aparte de la broma hay una fase inicial crucial que es la definición previa en esa definición previa o bien participan las diferentes personas y disciplinas que van a formar parte del proyecto que vende todas esas fases creo que ese punto inicial es crucial para que desde el principio la definición sea clara luego en lo que tiene que ver con participación como hay varios momentos hay un no-ner del proyecto ya hemos quedado que había alguien a quien podíamos tirar de las orejas para asegurar que el proyecto iba bien el proyecto también es la documentación ese o-ner tiene entre sus misiones asegurar que la documentación se mantiene y luego no lo he comentado pero en este caso está hablando de una documentación en Notion como la hojita que os mostraba antes que es básicamente documentación escrita en la que se cambian pues oye como teníamos las funcionalidades que hay que tener si hay una nueva se añade funcionalidad añadida y la fecha pero luego aparte cuando hablaba también de respetar los estándares de trabajar para la comunidad de ser serios en nuestro trabajo hay una documentación propia digamos en este caso del código cuando se trabaja el código se trabaja de una manera estructurada, ordenada y comentada y luego guide al cliente con el proyecto terminado el proyecto del entregable de la web es tu web en un servidor sí colega tu web en un servidor y tu código bien documentado, conectado y con una wiki explicando cualquier punto que se salga de esos estándares lo más mínimamente o que requiere explicación esta parte no es tan difícil es más difícil durante el mantenimiento pero una vez terminas el proyecto como uno de los hitos de los entregables es crear esta documentación desde esa parte inicial más compleja esta parte final que ya cierra un poco el círculo y la vara de Avellano que lleva el responsable la responsable de proyecto más o menos vamos salvando la situación muchas gracias nos divertimos mucho muchas gracias un gran apaso a Miguel