 Hola, buenas tardes. ¿Qué tal? ¿Cómo vamos? ¿Qué tal con la Qualcomm? ¿Os va gustando las ponencias? Bien. Hoy tenemos el lujo de tener hoy a Vicente... Perdón, Vicente. Victor, Victor Sainz. Victor Sainz con nosotros, que es desarrollador con más de 15 años de experiencia. Bueno, casi 15, ¿no? Un poquito menos, no sé, tan mayor. Y sobre todo coordinando equipos, ¿no acuerdo? Que es un poco de lo que está charlado hoy, ¿verdad? Pues nada, ¿vistos? Gracias a todos. Bueno, pues bienvenido a todos. Yo soy Victor Sainz, como bien me ha presentado mi compañero. Soy CTO y desarrollador en Mogomo.com, una agencia donde nos encargamos de hacer desarrollo a medida, sobre todo especializado en Google e ecomer en estos últimos años. Y bueno, yo empecé como desarrollador y poco a poco pues fui cogiendo más proyectos, fui cogiendo más responsabilidades dentro del estudio y al final, bueno, pues me encargo de la gestión de los diferentes equipos, la gestión de los proyectos y un poco la comunicación entre ellos. Y bueno, esta charla para mí es bastante especial porque normalmente siempre doy charlas de desarrollo en las que los trabajan y esta es la primera vez que voy a contar algo de este estilo y sobre todo lo primero que tengo que decir es que no soy un coach, porque he buscado un poco de, bueno, a ver quién más ha hablado de este tema y todas las charlas que he encontrado de comunicación, de coach motivacionales, gestiones de equipo a nivel emocional, donde se habla de energías y todo esto y bueno, no es que, bueno, que no crean esas cosas, pero yo no soy coach, vale, yo lo que voy a transmitir hoy y lo que os voy a contar es la experiencia de haber gestionado en estos cuatro últimos años 235 proyectos, es una captura del repositorio de código de MoBom y eso es lo que yo me encargado de gestionar. Entonces una experiencia de extraída de ahí es una muestra un poquito grande y bueno, espero que más o menos os pueda transmitir este conocimiento. En la charla de hoy lo que vamos a ver son las claves de comunicación que han llevado a que los proyectos que he ido gestionando hayan llegado un buen puerto. Eso no significa que haya sido un camino de rosa y que siguiendo esas claves no haya habido ningún tipo de problema al revés. Han surgido muchísimas cosas, muchísimos problemas y estas claves han sido un poco el resultado de haber solventando todos estos problemas según nos iban ocurriendo. Yo cuando empecé a gestionar el proyecto lo hacía de una manera muy basado en la teoría que había aprendido de un master que hice en el MIT y escrum, agil, tal cual, todo el mundo sube claro lo que tenía que hacer, se revisione constante, todo muy controlado, muy acotado y poco a poco se va dando cuenta de que la vida real es una mierda y que es complicado. Es muy complicado, no todo se arregla con un tablero de trelo ni porque defina mejor las tareas en Asana el proyecto que va a seguirlo. Es importante, es una parte muy importante, pero eso no significa que esos pasos que puedes aprender un tutorial de YouTube te lleve al éxito del proyecto. Antes de nada, vamos a hablar de comunicación y hay que identificar diferentes elementos claves dentro de la comunicación porque voy a usar varias veces esas palabras y aunque esto es súper básico, lo veíamos en primaria, en el colegio, son cosas que a veces se nos olvidan, estamos tan metidos en nuestro día a día que es una cosa tan sencilla como hablar y transmitirle algo a otra persona, es una cosa trivial, lo hacemos constantemente y se nos olvidan conceptos básicos y esos conceptos, bueno, pues os lo dejo ahí. Otra cosa me ha costado muchísimo en contra imágenes en repositorio de las cosas que quería ir mostrando y he puesto algunos comentarios porque me ha hecho mucha gracia, buscaba equipo de trabajo y me aparecían solo fotos así de gente hablando una mano encima de la otra, los ordenadores con tres gráficos diferentes puestos que no significan nada y claro, es una muestra curiosa de lo que la gente tiene por concepto de un equipo de trabajo o luego un diseñador huevo, parece mentira pero estas fotos las he ido sacando porque es que era lo que había en todos lados, supongo que si lo había es porque la gente lo coge y lo venden, así que más o menos te hace que puedas darte cuenta de lo que la gente que nos ha metido en nuestro sector ve de nosotros y eso es curioso. Entonces, elementos clave que hay, los elementos que están dentro de una comunicación, el emisor y el receptor, eso lo tenemos bastante fácil de entender, la persona que quiere transmitir el mensaje o el equipo que quiere transmitir el mensaje, el receptor, el que lo va a recibir, hasta ahí no hay complicación alguna, el código y el canal ahí es donde suele ocurrir siempre los fallos, el código es la manera en la que el formato en el que se transmite ese mensaje, del tirón pensamos idioma, código y idioma, pero que va mucho más porque dos personas que hablan el mismo idioma tienen código de comunicación totalmente diferente, yo soy una muestra clara de ellos, yo soy de Cádiz, yo con un gallego, si yo me pongo a Blagaditano y él se pone a Blagaditano, aunque los doblemos español, podemos no entendernos y estamos hablando lo mismo, pero nuestro código es bastante diferente y ya no solamente es eso, sino que ese código se ve afectado por nuestra formación y por toda esa experiencia que teníamos detrás, porque a veces se nos olvida que la gente no sabe lo que nosotros sabemos y damos muchas cosas por ello y alteramos ese código de comunicación en base a nuestra experiencia previa, solo vamos a ver más adelante. Luego el canal, la manera en la que ese mensaje llega de un lado a otro, una reunión presencial, una videollamada, un grupo de Telegram, Slack, Discord, lo que vayas a usar y hecho debido a la pandemia, bueno antes si era reunión importante era presencial, aquí no había mucha flexibilidad, si queríamos una reunión de un proyecto importante, trae al equipo de desarrollo hasta Madrid, vamos a hablar con ellos, otra es al equipo lo que haga falta. Bueno estos canales han ido cambiando y debido a la pandemia hemos dado la importancia y realmente adaptándonos a que canales están válidos como otros y a lo mejor ya no es necesario una reunión presencial para ciertas cosas, pero sí para otras y eso también lo vamos a ver. Y bueno luego tenemos el mensaje en sí que lo que queremos transmitir, que también es muy importante y otro como referente, situación, el ruido y demás. Nos vamos a centrar sobre todo el código del canal porque son las cosas más importantes que vamos a tener en cuenta cuando estemos trabajando varios equipos y para ello voy a poner un ejemplo de un caso, vamos a imaginaros un caso, voy a poner un poco en situación, imaginaros que empezamos un proyecto, nos han mandado un equipo de diseño, nos ha mandado un diseño ya terminado, un archivo Figma, nos ha enviado un diseño listo y nosotros como desarrolladores tenemos que sacarlo adelante, pero no hemos recibido y esto pasa muchísimo y es que no hemos hecho nada previo, simplemente hemos recibido diseño, lo hemos presupuestado, se ha aceptado y empezamos a trabajar. Y ese proyecto puede tener muchísimas complicaciones, que es lo que vamos a ver. El caso uno diseñador web puse diseñador web, pizabai, pexel, todo lo que podáis imaginar. Solo me parecía gente, si tumbamos una cama con un montón de colchones o en un sitio super chill out, ostia, yo los diseñadores que conozco no trabajan así, bueno, sino porque estarían con unos problemas de espalda, brutal. Y es curioso, es curioso buscar diseñador web, tal, no sé qué, siempre te aparecen gente así. Entonces, es curioso. Y bueno, para que os pongáis un poquito en situación vamos a definir un poco el perfil, lo he estereotipado muchísimo, vale, los perfiles para que quede muy representativo y muy exagerado, vale, pero un perfil de diseñador web súper estereotipado, sabe mucho de diseño, es capaz de detectar cada pilsen descompensado en la web, o sea, ve una web y dices, esto no va aquí, esto hay que subirle un poquito. Sabéis la situación en la que estoy planteando. Se ha ocurrado un archivo de firma increíble con todos los prototipos, todas las posibilidades, se lo ha ocurrado un montón y ya ese diseño está validado por el cliente y ya cuando nos pasa a nosotros, ya tiene su archivo de firma perfecto. Luego tenemos desarrollador web, he puesto la foto de mi compañero Pedro, porque si ponía desarrollador web, solamente me parecía gente encapuchada con código de traje. Entonces, es lo más separado de la realidad que he visto, o sea, no Pedro, una persona encantadora que no va con capuchas por su casa ni nada de esto, vale. Entonces, está bien, trabaja una mala postura, lo que pasa es que Pedro tiene una silla cara que todavía es peor que trabaja en un coin, pero bueno, eso ya es una cosa de Pedro. Y un poquito, lo de Pedro no lo estereotipado tanto y siendo mi colega me puedo permitir un poquito definir su perfil, sabe mucho de desarrollo web y no le gusta las reuniones. Esto creo que más o menos lo había escuchado alguna vez, no le gusta mucho reunirse, intenta evitarlo. Abre el firma al principio, lo ve, hace la estructura HTML, lo trabaja y ya cuando eso está terminado, lo cierra, se pone a prueba en PHP y a lo mejor no lo veré nunca más. Hace muy bien su trabajo, vale, pero también habla en unos códigos que no lo entiende nadie, o sea, habla en unos códigos que incluso dentro de su propio equipo a veces es complicado entenderlo, ¿no? Lo es estereotipado mucho para que cojagáis una idea. Pues este proyecto nos va a poner en situación de que nos ha venido así, tenemos estos perfiles, puede ser Pedro, pero puede ser cinco personas, vale, cinco desarrolladores, imaginaros varios equipos. Y ya no solamente diseño, también puede pasar del equipo de marketing al equipo de diseño, el equipo de negocio, directamente que opongo este caso, pero esto se puede extrapolar a diferentes situaciones. Y bueno, con estas situaciones que os he definido, pues pueden darse y podemos ya detectar una serie de cosas que a mí me gusta llamar grietas, ¿vale? Estas grietas son pequeñas cosillas, esto es sumo que ahora ha pasado todo, que cuando no os ha pasado que alguna vez habéis recibido un proyecto y hacéis, no sé, o lees el correo y dices, aquí no sé, me falla algo, ¿vale? Entonces son las posibles grietas que solamente por el contexto del proyecto, o sea no hemos visto nada, no sabemos de qué es el proyecto o sea nada, pero ya son cosas que pueden fallar. Pueden fallar porque no hemos dejado claro esas claves de comunicación que se deben detener y que debemos de poner encima de la mesa antes de empezar el proyecto, ¿vale? Esta grieta os pongo algunos ejemplos, ¿vale? Y la primera sé que a lo mejor nos choca, pero está en eso conocimiento en ambos campos. Esto después de trabajar con diferentes empresas y diferentes equipos de trabajo, sobre todo que están localizados en diferentes puntos, contra más experiencia y más nivel de conocimiento, tienen las personas que se encargan de esa comunicación, suelen surgir más fricciones, porque hay una cosa, bueno, esto pasa mucho en el desarrollo, que se llama lego del desarrollador, ¿vale? Cuando más experiencia tiene y más expertise, más conocimiento posee a esa persona, más complicados rebatirle, ¿vale? Aunque quizá puede que haya llevado, aquí no vamos a hablar de quién lleva la razón, sino que simplemente con una conversación normal saltan chispas y sobre todo cuando hay perfiles súper expertos, esto hay que tratarlo con cuidado. Una de las claves que os transmito directamente es que cuando definamos la comunicación en este tipo de casos y si sabemos cómo son los perfiles y nosotros estamos en medio, los que vamos a recibir las hostias somos nosotros. Entre ellos normalmente a lo mejor ni llegan a hablar nunca, ¿vale? Pero esto de proyecto, la persona que está en medio, es el que se va a encargar de transmitir información de un lado a otro y de controlar qué cosas se piden y qué necesidades hay en todo el proyecto, entonces tú eres el que te vas a llevar las hostias y pasa algo. Bueno, si no pasa, también te las vas a llevar, pero eres la persona que está ahí ubicada en medio, entonces es el sitio de frisión donde vas a estar. Entonces hay que definir una cosa y es que cuando entramos en reunión o cuando entramos a trabajar juntos, aquí hay que dejar muy claro que el objetivo es que el proyecto salga bien y hay que definir muy bien esos objetivos y los pasos que tenemos que seguir para que se consiga. No depende de nuestra serviduría, nuestra serviduría, nuestra experiencia, la vamos a implementar en el trabajo que vamos haciendo, no en quién es mejor qué equipo lo está haciendo bien o mal, aquí no vamos a entrar en eso. De hecho, como habrás eso, eso es una caja de bandora que cerrarla, cuesta mucho y probablemente el proyecto puede que se acabe, porque en el momento que ya los equipos no trabajan bien y realmente esas grietas se abren, es complicado volver a unirlo y que los proyectos salgan fluiditos. Eso es lo que a todo no gusta, que tú diga, uy, ni me he enterado de este proyecto, ha entrado y se ha entregado. Es complicado, pero bueno, estas grietas son las que hay que intentar parchear antes de que salgan. Entonces, si tenemos dos súper expertos, pues a lo mejor lo que hay que hacer es rebajar un poquito. Tienen otra persona dentro del equipo que nos puede transmitir lo mismo. Oye, pues vamos a poner estas dos personas, vamos a confiar en ellas, que delequen una persona que no tenga tanto conocimiento y sean ellas las encargadas. Esto va a reforzar la confianza dentro de los trabajadores que están en sus equipos, porque van a asumir un cargo de responsabilidad o llegan a lo mejor no quieren, pero eso va a potenciar mucho y simplemente nos estamos centrando en comunicación, no en hacer el producto, sino en comunicar los uno los otros, reportes se mandan a leto, este tipo de cosas. Intento de perfeccionismo excesivo, esto tanto por el lado del equipo de diseño como por el lado del equipo de desarrollo. Todos los proyectos tienen un presupuesto que ojalá fuera infinito, pero no lo es y hay que se consciente de eso y un objetivo es alcanzar y no es necesario que esté perfecto para alcanzar su objetivo y eso es complicado de entender y yo entiendo que a todo el mundo le gusta que su proyecto esté perfecto, que no tenga ningún fallo. No estamos hablando de errores de código, estamos hablando de perfeccionismo, estamos hablando de cosas que ya no importan o que importan o tienen un impacto muy pequeño en el resultado del proyecto. Este perfeccionismo tremo normalmente siempre se echa para atrás a las malas, porque cuando empezamos con este perfeccionismo tremo al final uno de los dos equipos planta un presupuesto de antes y dice espero que esto no se va a incluir y ahí otra vez una grieta que hace y se abre. Vale eso no se va a incluir y tal y tal y tal y hay que aprender a hacer es. Pues antes de que pase eso vamos a intentar que ambas partes entiendan que lo importante es que el proyecto salga. Estoy todo el tiempo diciendo lo mismo, pero es que esto es muy importante que se tenga claro, pero lo importante es que el proyecto llegue a un punto, ese punto hay que definirlo y no puede ser dentro de un año lanzamos la versión beta, hay que definir un objetivo dentro de tres semanas, aunque sea una tontería, aunque sea un template de página, pero hay que empezar definiendo eso, por muy grande que sea el proyecto hay que definir pequeños objetivos y alcanzando esos objetivos y poco a poco y trabajándolo. Si solamente nos centramos en ese objetivo que está dentro de seis, siete meses, un año, dos años, este tipo de grietas cada vez se van a ver agrandando más, porque normalmente siempre surgen y siempre estallan en las últimas dos semanas o cuando se tiene que se deploy o cuando el proyecto ya está en su fase final, porque claro la grieta todo al principio no lo nota, qué guay, qué bien va todo, qué me gusta trabajar con esta gente. Empieza las friciones, cositas y tal, un correo que está sentado mal porque ese día te ha levantado un poquito así y ese correo no está sentado muy bien, otro día que otra cosa, eso va sumando, eso va sumando, eso va sumando y cuando ya lleva seis meses y tú mira yo ya no cuanto más, yo no me reúno contigo y ya explotan las cosas, a veces los desarrolladores explicamos mucho de que no nos gusta afrontar esas cosas, entonces intentamos no acudir una reunión, aplazarla, no sé qué, yo soy desarrollador, yo estaba ahí y me ha costado, pero es importante que si tienes una persona en medio que gestiona eso, porque ponga solución y sea capaz de transmitir estos problemas, la sinceridad en estas cosas es lo más importante. Archivos de figma, Xd, la herramienta que uséis, por favor, Photoshop y esas cosas, no, estamos avanzando, bueno, los compañeros que están aquí, lo pueden, vamos, vamos a intentar que sean cositas apropiadas para trabajar en estas cosas. Un archivo de figma demasiado complejo, ¿por qué os digo esto? Porque ese archivo super guay con un prototipo increíble con los estados, con las animaciones de todos los elementos, para que lo valide un cliente, eso puede estar genial, pero para que el equipo de maqueta entienda lo que tiene que hacer, a lo mejor no está tan bien, porque el equipo de maqueta no puede pararse tampoco a ir poco a poco durante todo el prototipo de un sitio web, viendo qué pasa, cosas, sino que para hecho hay que hacer otro otro tipo de reuniones, el prototipo está genial porque se puede hacer una idea de cómo funciona la web, pero lo importante es que haya una fase, nosotros la llamamos el inventario de contenido, que hecho, bueno, lo inventamos hace unos años y le dábamos una importancia a nivel 1%, o sea, 0,5%, y ahora mismo es casi el 33% del proyecto, se le dedica al inventario de contenido casi un tercio del tiempo total del proyecto y qué es el inventario del contenido, pues el inventario de contenido es definir en un documento todo lo que se va a hacer, pero todo, hasta el punto de definir qué custom fills va a ir dentro de una taxonomía, o sea, qué elementos, qué campos va a ir dentro de una taxonomía, parece una tontería o qué elementos de maquetación son importantes que tenga en cuenta el maquetador, oye, ¿cómo vamos a hacer la maquetación de este atemplate? Todo, o sea, vamos a definirlo todo, ¿vale? Es que suena como, ya, pero es que yo no puedo dedicar todo este tiempo a planificar. Bueno, pues lo vas a tener que hacer, porque si tú no planificas bien, ese tiempo luego lo vas a ver multiplicado por 2, o por 3 fácilmente, es la fase final del proyecto. ¿En qué forma ajustes, cosas que no habíamos tenido en cuenta, reportes de errores, que a lo mejor no son errores, simplemente es que cuando se planteó este prototipo no tenía sentido, 20.000 pequeños fallos que luego nos va a venir y dice, hay que ver, es que tenemos la web terminal de hace 4 semanas y es que no paran de enviar no cambio. No, no, a ver, que sí, que a lo mejor habéis cumplido con todo lo que se veía, pero no era lo que se esperaba, que lo importante. Entonces, esa fase de inventario os va a permitir antes de empezar con el proyecto, incluso cuando pasas del equipo de marketing al equipo de diseño, también está muy bien que, vale, yo te diseño esto, pero ¿cuáles son tus necesidades? Porque a veces tienes en la cabeza una idea de una cosa que realmente no es lo que necesitas, es lo que quieres, pero no es lo que necesita. Entonces, es importante ese toma de requisitos y esa necesidad de que queden clarísimas antes de empezar a trabajar, porque cuando ya hemos trabajado, cuando duele mucho, quita de trabajo hecho. Entonces, si ese inventario lo tenemos muy claro y luego lo validamos por ambas partes, oye, todo genial. ¿Y este inventario cómo se hace? Pues es muy sencillo, realmente no tiene mucha complejidad, es que nos sentemos juntos en una reunión, videoyamada, física, como ustedes prefieren hacerlo y veamos el proyecto. Por ejemplo, si nuestra misión es pasar un archivo de firma a un tema de huelpre, vamos a vernos y lo vamos a juntar y si nos tenemos que reunir cuatro veces, cinco veces, seis veces, para que entendamos todos cada elemento, lo vamos a hacer. Y si veas que eso es el presupuesto que me hace falta a mí para eso, yo pondría la mano en el fuego de que si te pones a calcular ahora haciendo eso y sin hacer eso, al fin hachas lo mismo, porque luego lo vas a tener que invertir en preguntas al diseñador, ya el diseñador del equipo de diseño está trabajando en otro proyecto, estás parando en medio de un proyecto y empieza a ver problemas. O no, no me puedo reunir, porque claro, ya el diseñador entregó ese diseño hace un mes y medio o hace dos meses. No puede requerir que ahora con urgencias te solucionan estos problemas. Entonces, simplemente reunirnos y documentar toda esa parte. Los desarrolladores normalmente estamos muy acostumbrados a documentar. Pues hacer lo mismo, pero antes, tomarlo como una guía de lo que vayas a tener que trabajar después, pero no me refiero a una listita de tariana sana. No, no, que habrá un documento, yo lo hago a papel, me cojo una libreta y escribo lo que tiene que hacer la página web, ¿vale? Y luego eso ya en vuestramente solo se vayan traducir, los desarrolladores solo los vayan traducir a elementos de programación. Ah, mira, sí, esto es, esto es un kutopostai con esta 7 tazonomía y esto tal, tal, vale, pero eso el diseñador no lo sabe, transmití, porque no tiene por qué saberlo. Si lo sabe, genial, trabajo cojado raro, pero el equipo, yo al menos creo que el equipo de diseño no tiene por qué conocer toda la complejidad y todo el sistema de plantilla y toda la estructura en la que funciona el golpe. Es muy positivo que lo sepa, pero no podemos tener una ilusión de que el proyecto pase perfecto, porque no va a ser así. Poco conocimiento en el campo del compañero, esto es otro elemento clave que suele fallar, y es que no podemos tener empatía con el otro equipo porque no sabemos lo que hace, o sea, sabemos cuál es el producto final, pero no sabemos lo que es lo que se está trabajando, tanto por el equipo de desarrollo como equipo de diseño, porque he escuchado en infinidad de reuniones, bueno, esto pintamelo y dentro una semana lo veo, bueno, ya pintamelo, lo estás diciendo como si yo esto y te hiciera un diseño, no sé, en un momentito y hago así, abro el firma y te lo pinto, no, es que eso lleva un proceso y por la otra parte igual, bueno, esto lo desarrolla en un momento porque ya me la había arreglado en otro lado, bueno, cada cosa tiene su complejidad y esa empatía nos falta muchas veces porque no sabemos cómo es el trabajo de los demás, entonces esa pequeña formación, eso es como se arregla, pues muy sencillo, oye, vamos a hablar antes, es que todo se arregla hablando, de verdad, a veces nos olvidamos de que somos personas, necesitamos comunicarnos y lo máximo que conocemos de las personas es un e-mail que nos envía cada dos semanas para saber cómo va el proyecto, pero es que somos personas y tenemos nuestros problemas y evidentemente eso no puede afectar al proyecto, pero al final afecta, entonces vamos a ser conscientes de ello, al final los proyectos son personas, vale, entonces pueden ir bien y pueden ir mal y un día te puedes levantar inspirado y en una semana adelantar el diseño increíble y a la semana siguiente que oye, no sale, no sale, bueno pues tiene que haber una fórmula de comunicación para que esas cosas la detenemos y no haya problema, vale, porque al final el cliente también tiene que entender que esto va de persona, vale, y esto es una cosa que se tiene que transmitir en todas las fases, yo sé que suena mucho a coach, porque sabía que iba a sonar a coach, pero es que es la verdad, o sea es que es la verdad, es que al final los equipos somos, los trabajos somos personas y los proyectos estamos hecho así y están hecho por nosotros y tienen fallos porque nosotros fallamos y tienen cosas excelentes porque a veces somos brillantes y somos excelentes, pero hay que ser conscientes de ello, muchas veces se nos olvida, a cada error su solución, esas reuniones imposible de que termina, te levantas y dice este don no va a llegar a ningún lado, te puedes levantar, te lo puedes permitir, pero a cada error hay que dar una solución, el objetivo es que el proyecto salga adelante, no es que tú como desarrollador o como diseñador salves tu ego porque yo le lluvio bien y los demás lo han hecho mal, no, si al final esto es que el proyecto salga adelante y vamos a tener que ceder por ambas partes, vamos a tener que ceder todos, pero es para que el proyecto acabe, y una vez acabe y lo veamos con perspectiva diremos ah, se hizo un buen trabajo, porque nos vamos a olvidar normalmente de lo malo y si no volvemos a trabajar nunca, no pasa nada, pero que la relación entre los diferentes equipos no quede totalmente dañada porque un proyecto salió un desastre, porque al final depende de nosotros, que somos los que tenemos capacidad de hacer, hombre siempre estoy poniéndome en la situación de que sepamos a hacer y de que seamos profesionales a ambos equipos, vale, esto ya puede haber casos personales de que bueno, habéis trabajado con gente que no era capaz de hacer un proyecto, bueno, pero eso ya no es el caso, no es lo que he tocado hoy, y bueno, básicamente estas cuestiones que pongo aquí pues eran eso, unas posibles soluciones a los errores que os he puesto antes, pero simplemente son recomendaciones por mi parte y un poco basado en la experiencia que he tenido todos los años, quizá pues penséis, bueno, sí, es muy fácil decir eso, sí, pero es que también es fácil, no es tan complicado aplicar, probar, probar, oye, cuando a próxima vez hay un presupuesto, ponen el presupuesto, cinco horas de reunión en las primeras tres semanas, o las primeras dos semanas, para conocer el proyecto, para que me conté, para que lo conozcamos todo y es que esto parece, hombre, no, pero si yo lo hago, vamos a hacer un poquito de introspecibles y cuántas veces me he reunido yo con una persona para explicarle todo lo que tiene que hacer, bueno, yo ahora tengo una niña pequeña y claro, yo muchas veces digo, recoge los juguetes, una niña de 16 meses y claro, yo digo, recoge los juguetes, no entendé que recoge un juguete, o sea, la complejidad que hay en esa frase, ve allí, coge eso, mételo aquí y por qué eso está bien, porque es un concepto que, claro, que tú lo entiendes, pero esa niña, eso no es como lo va a entender, porque claro, tenemos tan asumido todo lo que hacemos en nuestro día a día, en nuestro trabajo, que lo vemos fácil y no nos ponemos en la situación de los demás y más o menos me queda un minuto, el minuto de reflexión de un andaluz pueden ser 15, pero voy a intentar que sean 30 segundos, simplemente después de haberme pegado, me gusta decirlo así, porque después de haberte peleado con diferentes personas, en diferentes idiomas, de diferentes disciplinas, todos, todos, cuando se acaba el proyecto, normalmente al tiempo, sea un mes, dos meses, cuatro años, tres años, lo que sea, vuelves a hablar con ellos si el proyecto acaba bien, o si el proyecto lleva un buen puerto y dice, tío, pues mira, aquí lo hicimos mal, no pasa nada por asumir los errores, yo lo digo abiertamente, errores comete todo el mundo, y no es el estudio perfecto que nunca comete errores, todos cometemos errores, porque somos humanos, somos personales, lo importante es que tengamos disposición de terminar el proyecto y tengamos disposición de que las cosas lleguen a un buen puerto y que todo, bueno, pues podamos acabar bien, somos personas y normalmente queremos tres cosas, tiempo libre, ser feliz y dinero, para ser feliz y normalmente contener tiempo libre y dinero y salud también nos va bien, entonces por lo menos salud no lo controlamos mucho, pero el tiempo y el dinero vamos a intentar optimizar nuestro proceso, que la comunicación no sea el fallo más importante, porque suele ser la tarea pendiente que tenemos todos, y oye, todo el mundo no podemos permitir una persona que solamente se encargue de comunicar a los demás, que por ejemplo, es mi perfil, yo al final lo único que estoy haciendo habla tordía, y bueno, yo lo entiendo, pero vamos a intentar que una parte en estos tiempos se dedica a eso, a comunicarnos con las diferentes personas, que todo el mundo esté contento trabajando, y que el proyecto se acabe bien, empatía y esfuerzo y seguro que el proyecto será un éxito, y nada. Muchas gracias, pasamos al turno de preguntas, alguna pregunta, vayan levantando la mano. ¿Qué haces? Yo tengo una consulta con esto, lo que dijiste del inventario de contenido. Primero, si en ese inventario intervienen todos los integrantes del grupo, y si utilizas una herramienta o algo para gestionarlo. Vale, te explico, depende del proyecto en el que esté y de los equipos que formen parte de la realización del proyecto, si soy dos o tres equipos y cada uno tiene 15 integrantes, no, no, no vamos a reunirlo todo porque eso puede ser, bueno, iba a decir una cosa que no se puede, eso puede ser un lío, y no, no, vamos a definir, de hecho lo suyo es que los propios equipos definan pues quién quiere que lleve la comunicación ese aspecto, no tiene porque tenerse el jefe del equipo ni el líder, sino la persona que quiera transmitirlo porque a lo mejor lo que más funciona es que lo transmita el tío o la tía que se esté pegando con ese proyecto todo el día, es el que mejor te lo va a transmitir y el que mejor le va a transmitir al otro la necesidad de que tiene. Entonces, yo normalmente siempre hago la reunión, yo porque tengo que estar, porque al final soy la persona que tiene que hacer un análisis y un registro de todo eso y luego los diferentes miembros de equipo, si son cuatro equipos, por ejemplo marketing, diseño de desarrollo y luego el lanzamiento, esto es una cosa que aquí no lo he visto mucho, pero en empresa del extranjero siempre hay un equipo que se dedica solamente a pensar en cómo se va a hacer el lanzamiento del producto cuando salga, eso pensará muchas veces que es marketing, pero claro la parte de negocio de marketing suele ser la que define la necesidad de al principio y luego la parte de lanzamiento es lo que define toda la campaña, parece que es lo mismo, pero normalmente aquí la verdad es que muchas veces no hay ni de marketing, simplemente estamos diseñados, desarrollados y el cliente que bueno está ahí, pero el cliente nunca, normalmente no viene a estar reuniones, que estaría guay si pudiera extraer al cliente, pero no, pero no. Y ese inventario yo, por ejemplo, uso un odio, pero oye puedes usar la herramienta que quiera, de ellos yo empecé con una libreta, o sea una mole esquina, una libreta mole esquina pues ahí y ahí apunta todo y una vez que tienes toda esa toma requisito, esas reuniones suelen ser un poquito tediosa porque se comparten muchas ideas y demás, pero bueno, luego haces análisis y de eso saca lo que pueda positivo y sobre todo lo analizas para poder transmitir eso como tareas a los diferentes miembros del equipo, eso es muy típico de luego te mando un email con lo que mejor lo en la reunión, vale pues no me mandes el email, mientras que estamos hablando no pasa nada porque tú te vayas tomando notas, analices y luego hagas un reporte a ambas partes de las cosas que tienen que hacer o oye de lo que voy a hacer o de lo que va a hacer a otra parte, que todo el mundo esté informado de lo que va a pasar en lo siguiente, en el próximo tiempo que sea. Normalmente nosotros hacemos semanalmente, depende de la cantidad de proyecto que lleguemos con el mismo equipo, pero semanalmente o bismanalmente y se van a hacer. Gracias. Miedos me da. Hola, buenas. Bueno, súper interesante la charla. Quería preguntarte si estamos hablando por ejemplo de un proyecto a lo mejor que tiene una complejidad alta a nivel técnica y quizás incluso al principio no está claro lo que se puede llegar a hacer técnicamente, cómo gestionas luego esa comunicación entre diseño y desarrollo para que diseño no pinte una cosa, que luego desarrollo dice que eso no se puede hacer y tiene que cambiar y entonces vuelva y no vuelve donde desarrollo se lo inventa. Sí, sí, sí, sí, te he entendido, te he entendido, te he entendido. Claro, pero ahí hay un fallo de base, es el no saber qué tienes que hacer. O sea, eso no puede ocurrir. Cuando tú estás haciendo un proyecto, siempre tienes que saber lo que vas a hacer. Ahora, aunque sea una fase muy corta de tiempo, tú tienes que saber lo que es lo que se tiene que hacer. Por muy corto, aunque sea un día, tienes que saber lo que vas a hacer mañana, por fuerza. Bueno, pues eso es lo que vamos a intentar medir. Lo demás son suposiciones. O sea, que no, no, tú no puedes antes, tú no puedes poner previsión a una cosa que no sabes cómo tienes que hacer. Entonces, vamos a intentar controlar lo que sí sabemos y que eso salga bien. Ahora, la parte que tú has dicho de, bueno, es que el equipo de diseño puede pintar una cosa que luego desarrollo no. Vale, pues que no la pinte. Cuando el equipo de diseño detecte esas necesidades, tiene una reunión con el equipo de desarrollo y le dice, oye, necesito pintar esto, ¿lo veis viable? Sí, no. Vale, pues entonces tengo que hablar con marketing o con el cliente para, oye, dibujar una alternativa. Pero siempre antes de que ambas partes se pongan a trabajar. Aquí lo que no tiene sentido es que uno pinte como un loco y el otro programé como un loco. No, no, no, no. Vamos a pararnos, vamos a estar muy claro lo que tenemos que hacer y entonces nos ponemos. Entonces, esto pasa muchas veces y a mí me ha pasado entrar al proyecto y empiezas a programar como loco, porque quieres terminarlo, porque quieres entregarlo, porque quieres cobrar, porque necesitas ese dinero y al final, oye, cuando llega al punto y dice, no, han cambiado la necesidad de ahora te he pintado estos cuatro templates y tu dios, mío de mi vida, ¿ya lo que hago? Bueno, pues que eso no tiene que llegar a pasar, no tienes que poner este programa como un loco, ni el otro va a pintar como un loco. Tenéis que tener esa conversación antes. Y si el diseño ya está aprobado, aunque esté aprobado, vaya a tener esa conversación, porque tienen que explicar eso. Y si luego cambia, pues entonces ya iremos y diremos, vale, bueno, pero sin un principio se definió así, porque ahora es así. Y te van a explicar el motivo y seguramente lo entiendas. Y, oye, el proyecto tiene que llegar a su final. Si necesitas ampliar presupuesto, porque te va a llevar en más horas, pues, oye, es que no puedo trabajar, es que necesito comer. Es que no hay más, se definió de una forma y ahora lo necesitas de otra, necesito ampliar un poco presupuesto. Si os encaja en ese presupuesto, que siempre, oye, un 1.2, os voy a poner esto, un 1.2, o sea, multiplicar con un 1.2 el presupuesto para que tengáis ese corchoncito, pues, si lo podéis hacer, está bien, y no tenéis que, oye, en la primera ya hacer eso, sino, bueno, asumimos, pero, oye, en los siguientes cambios de estrategia, vamos a tener que replantear el presupuesto. Lo avisa ahí. Esto son cosas que, oye, poco a poco, y hay proyectos que esto encaja y proyectos que no. O sea, proyectos que vas a gustar, oye, esto es lo que es ahí, vamos a ver cómo lo hacemos. Y siempre, siempre que las dos partes estén con una comunicación buena, se llega a un acuerdo. Yo nunca me he encontrado un diseñado que le haya dicho, tío, no puedo. Tengo que ajustarme a 15, 20 horas de desarrollo, no puedo hacerte 80. Y me haya dicho, pues, lo que hay. Bueno, pues, si pasa eso, pues, oye, tío, entonces ya se aplican otros métodos, ¿no? Pero normalmente, si tú le explicas los motivos, te van a entender. Ahora, somos todos, somos personas, y hay gente que es un poco intransigente, pero ya ahí, oye, tiramos de presupuesto, tiramos ese tipo de cosas, ¿no? Pero que siempre se hacía la última oción. Y bueno, espero más o menos haber contestado tu pregunta. Buenas, Victor. Uy, perdón. Bueno, lo primero, muchas gracias por la charla. Ha sido maravillosa. Existe una idea que tenemos todos los que gestionamos de cierta forma a distintos niveles proyectos, ¿no? Que es hacer participe al cliente del proyecto en cada fase. Como digo, existe la idea, porque luego, llevar eso a la realidad, todo bien sabemos que puedes conseguir la primera reunión de darnos a conocer, o sea, de conocer lo que es las necesidades de cliente, y después otra reunión para afinar conceptos. ¿Cómo trabajáis con el cliente en Movumu, en este caso? ¿Intentáis hacer participe en esa idea bonita de, en cada fase del proyecto? A ver, yo aquí aplico la técnica de ser un pesado. Te explico. Yo siempre transmito que es lo que me encantaría. Y lo invito a todas las reuniones. Normalmente asiste a dos. A la tercera ya me va a decir, no, ustedes, tranquilo. Me fío de ustedes, vale. Pero esa persona va a recibir el feedback completo de lo que se haya hecho la reunión toda la semana. Y le vas a dar, le vas a insistir hasta que te diga, OK, lo he leído. Me parece bien. Si no, todos los días me escribo, o sea, hasta que no responda Gmail todos los días, enviar el mismo, el mismo que, se pesa. Porque quiero que esa persona entienda que nos estamos reuniendo, que para nosotros es importante que si él está, se lo agradecería, entiendo, que no sé, porque tiene otras cosas que hacer. Pero, oye, esto es lo que se ha hablado. Dedica cinco minutos de tu tiempo para ver si te quiero decirme. OK, estoy de acuerdo. No, no, no, no. Estáis tirando por un sitio que no es. Vale, pues entonces lo vemos en una semana. Lo vemos en un intervalo de cinco, seis días. No lo vemos en un intervalo de cuatro meses de desarrollo. Entonces, yo uso la técnica de ser pesado. También te digo, me ha pasado cliente que directamente me han metido en expand. O sea, eso bien lo sabes, Pedro. O sea, yo he recibido cliente que dicen, mira, Víctor, no me envíen más email porque es que no los voy a leer. Me da igual. Vale, bueno, pues ya sabes lo que estás asumiendo. Yo estoy haciendo mi trabajo. Estoy intentando que tú lo entiendas. Pero ya contra eso no puede hacer nada. Muchas gracias. Sí, gracias, Víctor. Y yo quería preguntarte, ¿es alguna herramienta de diagrama de flujos que usábamos nosotros antes con la arquitectura clientes servidor y tal? Me quiero porque es la mejor forma de definir el trabajo, los bloques de diagrama que además es visual, con tiempos de ejecución y tal. ¿Qué herramienta usáis ahora? Nosotros diagrama de flujo te podrían dar unes a la completa. Mi compañero, Pedro, que está por allí, porque lo usa. Bueno, para todo se monta su mind map, con su mapa de flujo totalmente definido y perfecto. Pero claro, eso yo me encuentro con el problema de que yo lo entiendo porque, bueno, llevé, yo estaba antes ahí. Pero yo eso voy a la reunión con el cliente y le enseñó un diagrama de flujo y... No, no, yo me refiero para el equipo. Sí, claro, pero de manera interna, yo lo que hago es que dejo que cada equipo se gestione, ya no de manera interna, incluso de manera personal, dejo que cada equipo se gestione como ellos quieran, ¿vale? Yo antes era muy intransigente en esto de, venga, todo el mundo, clica, todo el mundo, formación de clica, vaya a aprender a usar clica. Y vaya, así, así, así, así, así. ¿Qué pasa? Los tres primeros meses, perfecto. En cuántito uno, ¿empeces a usar Tuduiz? Tuduiz, ¿empeces a usar? ¿Qué cómodos es esto? Yo voy a usar clica y Tuduiz, ¿vale? Vale, no, y al final no me acaba usando ninguno de las dos, se empieza a... No, no, mira, a mí me da igual, aunque te lo apuntes en una libreta. Yo voy a llevar a mi sistema de gestión, tú con tu equipo, llevas el tuyo, pero lo que vamos a tener son dos sistemas de gestión de proyectos sincronizados. Yo, mediante reportes, te voy a decir cómo tenéis que actualizar tuyo y tú el mío, es cuestión de hablar, es cuestión de hablar. Pero es eso, los diagramas de flujo, o sea, Pedro con su equipo lo usa, pero no, yo eso no puedo exportarlo al resto, porque entonces me meto, por ejemplo, en que un diseñado tenga que entender un diagrama de flujo que él lo entiende, porque estudia ingeniería y lleva tal, pero no puedo pretender que el diseñado lo entienda, ni debe entenderlo, porque es que no... Pero si se le puede traducir eso, en un lenguaje que se entienda, que es haciendo unos bocetos, haciendo un gráfico más sencillo y por la parte contraria igual. No puedo pasarle quizás un brainstorming de un equipo de marketing a Pedro, porque va a verlo y va a decir, bueno, yo aquí veo palabras grandes, para la brashica, pero yo aquí no tengo ni idea. Claro, claro, pues eso. Entonces, vamos a buscar el código en el que nos comunicamos y vamos a adaptarlo dependiendo de la circunstancia. Yo me refería más que nada a ti como director del... Sí, no, no, yo dejo, yo dejo que cada uno... O sea, yo voy por objetivo. Yo soy muy pesado todos los días, voy viendo cómo van avanzando esos objetivos y bueno, al final, oye, yo entiendo que eso no lo puede hacer todos los equipos y necesito una inversión de tiempo grande, pero yo voy revisando los objetivos todos los días. Entonces, en el momento que veo una desviación, tal, no sé qué, pues ya lo organizo, pero dejo que ellos se organizen como quiera. Perfecto, gracias. Tiene que ser muy, muy breve. ¿Puede ser? ¡Guau! Organízalo, es por favor. O sea, la cláusula de recessión mismo como es cara, no lo sé. Bueno, pues entonces, olvídate porque no lo van a apagar. No, pero bueno, todo se puede hablar, pero no contrataba, pero oye, que te puedo decir, vos he hecho una mano y lo que haga falta. O sea, que hablamos luego, sin problema. Muchas gracias, Víctor.