 Tenemos doble ración de Pablo, Pablo López y Pablo Pobeda. Hola, Pablo López, desarrollador en PHP, especializado en WordPress desde 2011. Loutor del blog DesarrolloWP.com y comparte noticias, tutoriales, truco, consejos. Pablo Pobeda, ingeniero informático, lleva más de 10 años, dedicado al desarrollo y programación de motores web, basado en tecnología. A él le gusta la buena práctica y el trabajo bien hecho como no mundo. Los dos hablarán sobre cómo salvar y gestionar las dificultades del trabajo en equipo y cómo algunas herramientas pueden hacer que todo funcione perfectamente como un reloj. Su charla, trabajo en equipo, cuando cada maestrillo tiene ese librillo. Vamos a despertar un poco al... Se ha quedado cargado. Bueno, no vamos a repetir la presentación porque ha estado muy bien. Pablo López y este soy yo. Los dos ahora mismo hemos coincidido en la misma empresa y llevamos un año creo más o menos trabajando juntos. Y estamos metidos ahora mismo en un proyecto bastante interesante. Hace medio año por ahí. Y venimos un poco a contar los cambios que hemos hecho desde los últimos meses aquí para poder ser más productivos trabajando en equipo. Vamos a hacer un pequeño clamor, porque sí que es verdad que hay una pequeña curva del cambio que hay que gestionar. Y voy a empezar un poco contando el problema o lo que creemos que fue nuestro problema. Al principio estábamos Pablo y yo como desarrolladores únicos del proyecto. Estos aquí arriba son compañeros nuestros que nos ayudan con la parte estética de la web. Toda la parte frontal. El proyecto empezó a crecer. Y empezó pues con suerte la empresa nos permitió contratar en este caso en remoto a un primer compañero que nos ayudaba en modo freelance a hacer más cosas. Y empezamos a detectar pequeños problemas de comunicación, de formas de hablar, de no entendernos a la hora de programar o yo lo hago de una forma, yo de otra. Las dos son buenas, pero perdíamos mucho tiempo llegando a acuerdos. Entró David Navia que estaba aquí antes contando librería multimedia y pasaba otra vez lo mismo, a que yo empezaba un poco a complicar porque ya no solo teníamos el problema de Manuel, sino de David también. Entonces queríamos seguir manteniendo la misma calidad, una forma de trabajar o digamos alguna forma de trabajar que nos alineara a todos de la misma forma. Y la gota que conmo el vaso fue cuando entró nuestro compañero Javi y empezó a detectar el mismo problema que nosotros y empezamos a poner soluciones encima de la mesa porque aquello ya era un poco inmanejable. Vamos a primero a contar los problemas que hemos detectado de forma común quizás a todos los equipos para luego contar las soluciones que hemos propuesto. Voy a quedar aquí porque lo veo más fácil. Tengo que contar los problemas. Cuantos de aquí sois desarrolladores o trabajáis en algún equipo de desarrollo. Me imagino que muchos estareis familiarizados con las virtudes del programador, que son tres, la pereza, la impaciencia y el orgullo del medido. No reéis porque son virtudes, es la pereza porque nos gusta hacer programas que automaticen cosas para el día de mañana, trabajar menos. Impaciencia porque nos gusta que esos programas estén optimizados, vayan rápido para, además, trabajar menos tiempo. Y orgullo del medido porque no nos gusta que el día de mañana hereden un proyecto de nuestras personas y hablen mal de la chapuza que hemos hecho. Como decía, lo primero que detectamos al trabajar tanta gente en un equipo de trabajo fueron los vicios y manías que teníamos cada uno. No solo en todos los aspectos de lo que es una jornada laboral, es decir, desde la comunicación, los canales de comunicación que usábamos y sobre todo a las horas que lo usábamos, a fines de semana y tal. Problemas de organización y también problemas a la hora de código de desarrollar. Cada uno tenemos nuestra forma de hacerlo, digamos. Como sabéis, el Google Press está basado en PHP y PHP te permite hacer o programar de diferentes maneras y detectábamos cosas tan simples como esta, que había gente que programaba poniendo la llave abajo en una línea y gente con la llave en la misma línea o gente que declara una RAI con la palabra RAI y otra gente que lo declara con un corchete. Funcional funcionan en los dos casos, pero éramos capaces de detectar código, de leer un código y saber quién lo había hecho y que cada código o cada snippet tenía la huella o la firma de alguien. Aquí ya os pongo un ejemplo un poco más claro de cómo encolar una script de tres maneras diferentes, poniendo la función directamente en el hook, enganchando el hook a una función por fuera o haciéndolo orientado objetos. El resultado es el mismo, pero como veis, si lo leéis, digamos, se nota que esto ha sido hecho por tres personas diferentes y es un poco lo que nos pasaba, que teníamos este problema, no había una consistencia, no había una integridad en el desarrollo. El orgullo, como decíamos antes también, tuvimos el problema de que cada uno pensaba que lo que hacía era lo mejor o la mejor manera de hacerlo y otra persona lo hacía de otra manera, entonces esto desembocó en un poco de fricción y un poco de lucha pues hacer lo mismo de diferentes maneras. Entonces este orgullo nos hacía preguntarnos si lo hago yo, o sea, yo estoy haciendo lo correcto y tú lo estás haciendo de otra manera que no la correcta. Todo esto nos generó o nos fue generando poco a poco una deuda técnica. La deuda técnica es el coste que vas a pagar el día de mañana por las niapas que estás haciendo al día de hoy. Entonces al ser tantas personas y cada uno tirar un poco por un camino diferente, pues íbamos generando deuda técnica, nos íbamos dando cuenta de que el día de mañana tendríamos que ir refactorizando. También la importancia en cualquier fase de un proyecto pues la posibilidad y la gravedad de encontrar un bug depende del estadio del proyecto pues fue creciendo cada tiempo que iba pasando pues era más probable y más grave el encontrar un bug por no hacer las cosas de una manera concreta. Esto es un ejemplo real que nos encontramos por ejemplo en un proyecto, no sé si lo leéis bien los de atrás pero dice si esto sí que vacío no tenemos dónde ir hay que dejarlo en manos del señor y con un poco de suerte las cosas se arreglarán solas y simplemente es que llega vacío una variable que se llama new URL. Entonces, el no pensar las cosas, el no tener una idea clara o pues podéis llegar a encontrar las cosas de estas y no sabéis qué hacer lo tenéis que dejar en manos del señor y esperar a que esto nunca reviente. Os dejamos aquí a modo de links una sección librería con libros de todo esto que estamos hablando que realmente no es que nos pase a nosotros se pasa a todo el mundo, hay libros sobre ello luego compartiremos la charla. Otra cosa que nos dimos cuenta también es que externalizar está bien y a lo mejor delegar en otras personas ciertas partes de trabajo pues está muy bien que lleva a una pérdida de saber del know-how llegas a tener partes del código y Google bien solo que sea a modo de caja negra es decir sabes qué hace una cosa pero no sabes cómo lo hace entonces pierdes el control entonces está bien en algún momento dado pero te puede llegar al día de mañana pues a tener una sorpresa porque no controlas lo que está ahí y el último punto que nos llevo es a mucho reacción entre nosotros porque muchas discusiones algunas constructivas otras eran un poco más filosóficas de cómo hacer las cosas y otras incluso alguna bronca llevado quizá a un punto un poco más personal que no hay que llegar a tomárselo así pero nos ocurrió y simplemente es porque cada uno tenemos un punto de vista y es la misma cosa pero desde eso dos personas que piensan que su forma de hacerlo o de tomar una decisión para conseguir algo pues es la mejor y estamos hablando de lo mismo sabíamos cuál era nuestro destino pero cada uno vivimos por caminos diferentes vale, entonces pues dado estos problemas empezamos a preparar un plan de solución que nos permitiera seguir evolucionando ese plan de solución durante el tiempo lo primero que establecimos fue flujos de trabajo algo empezando desde lo más simple para ir evolucionando mucho después esto te permite que todo el mundo tenga la misma guía de trabajo y la misma forma de trabajar a la hora de ejecutar y de planificarse si tú tienes un equipo de cinco personas y todos trabajamos de la misma forma no hay ningún problema y sobre todo vais a ser mucho más productivo al final lo dividimos en planificación y ejecución y organización siempre va de la mano de las dos porque es como y en qué momento haces cada cosa y sobre todo con un plan de mejora continua la mejora continua no es más que pararte cada poco para ver si lo estás haciendo bien o tu planificación y ejecución necesitan de algún ajuste voy a comentar por encima herramientas que son solo herramientas las que nosotros hemos elegido para solucionar estos problemas hay muchísimas herramientas empiezo por trelo trelo si lo conocéis es una herramienta bastante sencilla de usar pero mucha gente la utiliza solo para mover tarjetas de una columna a otra sin ningún sentido nosotros hemos establecido una serie de flujos entre columnas que nos permite a todo el mundo saber en qué estado están las cosas y quién las tiene que hacer y en qué momento las tiene que hacer hemos establecido un calendario muy simple donde todo el mundo puede ver enseguida si alguien va a estar de vacaciones y cuando son las reuniones más importantes luego hablaremos un poco de reuniones importantes hemos introducido la como forma de trabajo nos permite clasificar y canalizar todas nuestras conversaciones en pequeños hilos de conversaciones por ejemplo cada canal para hablar de una tarea en concreto que luego se cierra o se archiva ese canal hemos aprendido a hablar mucho mejor entre nosotros es decir a ponerle nombre a las cosas el mismo nombre a todas las cosas así cada uno cuando dice una palabra el resto sabe de qué está hablando y sobre todo hablar mucho más entre nosotros a la hora de trabajar por ejemplo cuando estamos programando con sesiones de compartir código y demás una herramienta tan simple como apiarim, zoom o cualquiera te permiten cinco segundos estar hablando con otra persona en remoto y sobre todo darle uso al email pero darle un buen uso al email no utilizarlo de cualquier manera y repetimos el proceso y mejor a continuación voy a mostrar algunos pantallazos de la implementación de todo esto son solo herramientas para conseguir un medio y lo mismo para la ejecución antes hemos visto que teníamos planificación y ejecución hemos empezado a meter mejores prácticas de código sobre todo en PHP puro y sobre todo en la parte que nos toca de WordPress estableciendo y jugando con la guía de estilos de programación de WordPress y sobre todo hemos puesto Codernifer que para quien no sepa qué es es un chivato de si tu código va por buen camino o no te permite establecer unas reglas que tu código debe pasar trabajamos con Git mucho mejor hemos establecido una especie de flujo tipo Gitflow pero con nuestras necesidades y GitLab como servidor de repositoria hemos empezado a trabajar con una wiki que desde luego está muy bien porque es una documentación muy rápida de entender muy rápida de escribir y que todo el mundo puede acceder a ella de forma rápida hacemos tareas de code review hay una persona encargada siempre de revisar el código de los demás simplemente revisar si el código es correcto o no, no se trata de cazar a nadie ni decirles si ha hecho mal las cosas o no, simplemente revisar si falta algo si va a dar algún error o lo que sea y sobre todo automatizar ciertas tareas que nos permitan desplegar código mucho más rápido y volvemos otra vez al proceso de mejora continua voy a ir un poco más rápido para que nos dé tiempo a hacerlo todo básicamente vamos a compartir estas diapositivas pero básicamente estos son de nuestro tablero de trelo que trabajamos mucho antes lo simplificamos y trazamos estas columnas que iremos evolucionando a medida que vayamos necesitándolo pero cada una de las columnas tiene su descripción y cómo se mueve entre ellas ¿vale? esto es una captura de la guía de estilos de PHP sacada de la documentación de warpers de cómo tienes que programar tu código esta es una captura de nuestra guía de estilos por ejemplo una guía de estilos simplemente te dice cómo tienes que programar partín correcta y cuál es la parte correcta de hacerlo esto es el code es un chibato te va diciendo los errores que tienes en tu código y cómo se solucionan si esto pasa sin errores entonces tu código es correcto pues un poco trabajar git meter etiquetas de revisiones hacer mucho mejor los comits nuestra forma de trabajar con git flow que vamos añadiendo muchas mejoras cada x aquí tenemos por git branching policy pero abajo git atomic de cómo hacer los comits que es toda una herramienta muy potente sobre todo para mantener tu histórico limpio y por ejemplo esto es algo que ayuda muchísimo que es una daily que dura 15 minutos te plantas siempre a la misma hora y siempre se hace siempre hay que hacerla porque siempre vas a sacar algo y simplemente es para recordar al equipo que hiciste ayer que hay hoy y si hay algo que no te impida a seguir trabajando y lo mismo con las retrospectivas que son muy potentes para sacar una crítica constructiva de todo el trabajo que has hecho por ejemplo durante un sprint de un mes básicamente cada uno se prepara su trabajo para decir si ha habido algo que corregir todo lo que hemos hecho bien y las acciones que hacer para las cosas que hemos hecho mal que entra dentro del proceso de mejora continua y vamos ahora un poco a hablar de todas las conclusiones que hemos sacado después de introducir estas soluciones primera conclusión es tener unas reglas y seguirlas muchas gente yo también entre ellos pensaba que al principio estamos perdiendo mucho tiempo en generar toda esta documentación toda esta guía de estilo y demás pero no es una pérdida de tiempo es una inversión esto a medio largo plazo es rentable porque de verdad que nos pone a todos en la misma línea y remamos todos en la misma dirección hay una frase muy famosa que es que los buenos programadores utilizan sus cerebros pero unas buenas directrices nos ahorran tener que hacerlo en cada caso porque si tenemos definido cómo tenemos que hacer ciertas cosas pues no hace falta ni pensarlos allá nos va a salir automático otra cosa muy importante también es en este caso somos un equipo de 7 o 8 personas es importante hacer equipo y no sólo con que des a tomar una birra o hacer un timbil del 9 en cuándo sino ser parte activa ser constructivo crítico cuando hay que serlo siempre desde el respecto evidentemente y siempre intentando pues no todos tenemos todos los días el mismo buen humor o el mismo feeling y a veces hay gente también nos vamos conociendo de quienes más potente en un área, quienes más póneten otra nos echamos una mano si hace falta cuando uno está agobiado pues otro le intenta tal y al final te ríes porque lo sabes y total que al final somos un equipo y el resultado si es bueno es mérito de todos también hay una frase muy famosa de Marcelo Olipi que decía Marcelo Olipi es el Vicente del Bosque Italiano para quien no lo conozca que el mejor jugador es el que pone el talento a los servicios de más al final que pues un trabajo de equipo y vale que alguna vez alguno marca los goles pero al final que ganase el equipo trabajamos mucho con ciertas filosofías en principio con estas tres nos cubre mucho de las mejoras que hemos ido metiendo don repeat yourself cada vez que detectamos tareas repetitivas una de dos o mejoramos el código porque lo tenemos repetido o hacemos algo que nos automatice esa tarea la de keep it simple que es la de quiz nos ayuda a mantener las cosas simple por ejemplo el ejemplo del trelo de mucho flujo a mucho menos partimos de mucho menos y lo vamos mejorando a medida que lo vamos necesitando hay que simplificar las cosas para mejorarlas y luego sobre todo esta que duele en el alma pero hay veces que no hay que hacer ciertas cosas porque no la necesitamos a los programadores tenemos tendencia a mejorar cosas que nadie nos ha pedido mejorar entonces ahí tenemos que frenar un poco y esperar a que alguien nos la solicite de verdad por ejemplo la parte de negocio chicos hay que hacer esto si no hay que hacerlo no lo hagáis porque estáis perdiendo el tiempo y puede ser algo más perjudicial que beneficioso hemos introducido ratos de pay programming que no es más que compartir horas de programación con nuestros compañeros en este caso la técnica consiste en que uno le dice a la otra persona lo que tiene que escribir uno es la mente y el otro es el que ejecuta las teclas aquí se comparte conocimiento entre las dos personas y se puede revisar el código mucho mejor porque cuatro ojos ven mucho más que dos una pequeña frase de la madre de Teresa de Calcuta yo hago lo que usted no puede y usted hace lo que yo no puedo juntos podemos hacer grandes cosas y esto habla de defiende tus ideas pero también acepta las críticas si hay alguien del equipo una crítica constructiva sobre un trabajo que has hecho tú porque se podría mejorar de alguna forma o simplemente hay otro método de hacerlo que quizás sea más eficiente pues lo bien lo puedes defender o bien lo puedes acertar lo que no puedes hacer es quizá tomártelo un poco al lado personal porque no dejamos de estar trabajando en una empresa cuando se termina nuestro aerolaboral lo vemos a ser personas pero en algún momento cambiaste dejaste de ser tú permitiste que te señalara ni que te dijeran que nos sirves y cuando empeoró todo buscaste a quiere echarle la culpa a una sombra alargada voy a decirte algo que tú ya sabes el mundo no es todo alegría y color es un lugar terrible y por muy duro que seas es capaz de arrodillarte golpe sin tenerte sometido permanentemente si no se lo impides y nadie golpea más fuerte que la vida pero no importa lo fuerte que golpeas sino lo fuerte que pueden golpearte y lo aguantas mientras avanzas hay que soportar sin dejar de avanzar así es como se gana si tú sabes lo que vales ve y consigue lo que mereces pero tendrás que soportar en los golpes y no puedes estar diciendo que no estás donde querías llegar por culpa de ella ni de nadie eso lo hacen los cobardes y tú no lo eres tú eres capaz el vídeo este motivante de Rocky viene a decir un poco lo que estábamos pasando en muchas reuniones en muchas decisiones que teníamos que tomar está bien que todos defendamos nuestras ideas y que las argumentemos pero también hay que saber recibir golpes es decir nos pueden criticar nuestra forma de hacer las cosas y tenemos que ser capaces de levantarlo y de aceptarlo a veces porque muchas veces tienes que ser consciente de que estás haciendo lo tu mal luego sobre todo basarte aquí en muchas cosas que hacer tú tienes poco de exponer vale focalízate en tu trabajo pero también el resto de compañeros tiene que digamos proteger las distracciones de los demás interrumpir cuando se tiene que interrumpir acumular dudas y después resolverlas todas de golpe y así un poco respetamos el tiempo de cada miembro del equipo cuando sabemos que vamos a estar entretenidos resolviendo algún problema interesante y sobre todo insistimos mucho en el feedback porque es un el feedback es algo que te está diciendo si vas bien o si tienes que hacer algún ajuste lo que estás haciendo tanto feedback instantáneo por ejemplo implementamos una herramienta que directamente personas que están trabajando sobre la herramienta pueden enviarnos feedback instantáneo y acaba en un tablero nuestro que después priorizamos un criterio y ese feedback es instantáneo es en mero formulario que en un segundo en cinco segundos se rellena y nos puede decir si hay un error en la página si falta un campo si no se ve cualquier imagen es muy muy muy impotente esta herramienta que hemos hecho y luego aquí para digamos ver cómo impacta esto en las personas pues realmente no es tan sencillo no es tan sencillo de asimilarlo vale empiezas a trabajar te das cuenta de que hay nuevos cambios como mola voy a aprender un montón de cosas y te empiezas a dar cuenta de que lo que has establecido te empiezas a frustrar incluso te desanimas porque no te sale las cosas o no te gusta esa forma de trabajar que todos hemos decidido por cierto pero luego te vas a adaptando un poco a esa nueva metodología y te vas dando cuenta que si sale las cosas que eres mucho más productivo en final todo se traduza que trabajar en equipo es bastante bueno este es el equipo que tenemos actualmente Pablo, Juan Carlos, este soy yo, Marta, Elena, Javi y dos personas que trabajan con nosotros en remoto que es Manuel y David Navia que ha estado aquí antes con nosotros vale y os dejamos una pequeña canción vamos a saltar, debería sumar no suena un poco muchísimas gracias por la charla porque ha sido mollón de inspiradora y además nos hace ver los errores que cometemos y aquellas cosas que hacemos un poquito bien yo quería hacer una pregunta a vosotros a los dos entre trabajar en el remoto o trabajar viendo las caras todos los días que elegiríais o que elegiríais de cada una de las partes te voy a contestar yo que he trabajado de la todas formas si pudiera elegir iría lunes y jueves a la oficina y martes, miércoles, viernes en casa porque necesito ver a mis compañeros porque el feeling físico no es el mismo que el feeling remoto desde luego pero también hay veces que te puedes permitir el lujo de no ir a la oficina porque no te hace falta haciendo unas tareas en concreto que a menos que requieran algo específico que lo puedes hablar a través de la pantalla no hace falta yo creo que para mi el modelo ideal sería un par de veces a la oficina y tres en remoto pero bueno aquí esto ya también entra en lo personal yo creo que sí en mi caso vale, yo te digo que esto es personal es decisión de cada uno pero yo haría un misto de dos días en la oficina lunes, jueves sería para mí el ideal y martes, miércoles y viernes en casa si yo opino un poco el tener contacto físico en una oficina te hace trabajar más y en mi caso particular estuve de freelance hace 6 o 7 años y tener la nevera al lado en gordo de 20 kilos y no nos he vuelto a perder prefiero estar en la oficina que no tengo ahí el friffico al lado y si hay veces que cuando trabajas en casa no sabes dónde está el límite de separar el trabajo del hogar porque por lo menos el camino que tienes de casa a la oficina te permite desconectar yo voy en moto, me da el aire y desconecto desde la oficina a casa pero cuando estás en casa sales de tu despacho y estás en tu casa no tienes ese trayecto que te desconecta al final en fin muy interesante en cuanto a la revisión de código creo que has dicho que una persona se encarga de revisar el código de otro que siempre la misma persona o va esturnando voy vamos esturnándonos porque a veces acumula mucho trabajo a la hora de revisar entonces nos vamos esturnando por eso porque es mucho mejor y sobre todo una persona no se puede revisar su propio código evidentemente pero sí que nos vamos esturnando porque te refresca la mente un poco de descansar y como nos podemos permitir ese lujo porque al final los que revisamos código somos tres personas nos podemos dar el lujo de ir digamos intercambiando los roles tenemos roles establecidos durante un sprint por ejemplo durante un sprint hay una persona que se encarga de los code review y de alguna otra cosa más y esa es su tarea principal después ejecutar tarea como cualquier otra persona del equipo pero su principal tarea es revisar ese código nuestra experiencia que llevamos poco practicándolo es que es productiva pero a veces depende mucho de la buena conexión a internet que tengas por ejemplo eso es un problema que a veces se da porque digamos no transmites todo lo que quieres transmite y a lo mejor le estás diciendo una frase y llevas hablando un minuto y la otra persona te ha perdido volver otra vez atrás para contarle lo mismo a lo mejor puedes equivocarte ahí y tiene ese pequeño margen de error pero bueno en general las sensaciones son bastante buenas al principio te transmite perdiendo tiempo porque no deja de estar dos personas en la misma tarea en paralelo pero es una inversión como ha dicho Pablo a medio largo plazo la verdad es que invierte porque además alineáis vuestras formas de programar de alguna manera sí que dos personas al final tienen que buscar una solución vas más a tiro hecho porque lo piensas entre los dos o sea muchas veces a ti te viene una tarea y tiras millas y ya te das cuenta de que te ha fallado ese camino vuelves para atrás y tal cuando trabajas dos personas no es un program en estricto pero sí que es cierto que al final antes de hacer cualquier cosa llegáis a un acuerdo entonces vas llegando a un acuerdo y aunque pueda parecer en el inicio que es más lento o que hay dos personas en una tarea a la larga es bastante mejor la experiencia que tenemos que es poco tiempo que llevamos haciéndolo os quería preguntar hay veces cuando varias personas trabajan y cada uno tiene un estilo diferente no pensáis que a veces es mejor hacerlo al estilo de uno y que los demás le sigan o al estilo de otro y que los demás los siguen variando en vez de tener un largo debate asambleario de qué estilo mejor o llegar a un punto común contesto sí a ver las discusiones estas filosóficas que hemos tenido han tenido que pasar porque tenían que pasar pero todo eso nos ha llevado a crear nuestra propia idea de estilos que aquí habéis visto un cacho pero realmente es una hoja enorme donde tenemos definido cualquier cosa desde cómo declarar una clase como los espacios que tienen que ir entre hasta las cosas más pequeñitas están declaradas y luego con el code sniffer es el validador de esa idea de estilos y hemos tenido muchas discusiones y muchos debates filosóficos porque PHP te permite hacer cosas de dos maneras diferentes como lo que contaba antes de la RAI o sea éramos cinco tíos que hacemos a RAI con contexto y uno que lo hacía con corchetes ahí no ganan la mayoría pero hay otras que estábamos un poco más empatados y eran discusiones de si es mejor usar una ternaria poner un if pero bueno ya pasa por ese por ese punto y más o menos tenemos ya una idea clara y ahora el código que hacemos ahora hoy en día con el que hace tres meses que se veía que parte había desarrollado cada uno porque nos leíamos el código o sea tenía la firma de cada uno O sea que las respuestas que sí merecen la pena tener ese proceso y unificar el trabajo al final acabo luego también depende de tus plazos y tu el cliente te apriete de más pero llevamos seis meses hemos tenido la oportunidad de poder hacerlo y creo que sí merece la pena y añadiendo a lo que dice Pablo un poco más allá una vez que ya el código, digamos, cumple las normas la forma de implementar una solución evidentemente si es evidente que esa solución que ha hecho una persona es la correcta porque es escalable porque es solid por lo que sea quizás establece esa forma de trabajar porque evidentemente es la buena o se le matiza ciertas correcciones y se trabaja sobre esa base directamente ¿Alguien más quiere preguntar? La verdad que todo lo que habéis contado cuando trabajas en equipo me siento muy identificada y nosotros estuvimos estudiando nuestra forma jurídica de cooperativa estuvimos en un curso nos enseñaron a hablar un poco de lo que es trabajar junto y demás las tomas de decisiones y nos dijeron que tuviéramos cuidados con el acuerdo de medio el ejemplo era 50% de personas quieren 140 en la carretera y otros 50% quieren que vayan a 100 quieren que bajen el límite, o van a 120 y eso a quien contenta a ninguno, o sea, ni a los que quieren ir más rápido ni a los que quieren ir más lentos entonces creo que muchas veces hace falta un un líder o alguien que rompa ese tipo de pero vosotros parece que es un poco más muy horizontal, como se afronta ese trucos que somos impares, entonces siempre ganan a bien ¿qué? que somos impares, entonces siempre ganan a bien pero respondiendo a tu pregunta al fin y al cabo, eso que dices es verdad todavía no se nos ha dado algo tan crítico como un 50% no por lo que dice él que también es verdad pero no se nos ha dado en cualquier caso a todas las personas que están en remoto son clientes, o sea, son proveedores es decir, que la empresa les está pagando para que nos ayude pesa más, digamos, la opinión de los que trabajan en plantilla que los que son proveedores evidentemente escuchamos a todo el equipo pero dado un escenario en el que te toca elegir al final elige, digamos, el cliente pero bueno todavía no se nos ha dado un caso tan crítico como que un 50% y saber qué solución tomar a la de un lado o la del otro o, digamos, hacer algún acuerdo intermedio aunque se llegara a dar yo creo que la mejor solución al final es probar, investigar y medir y realmente ver, oye, mira, pues con esto un empate técnico entre algo sería muy difícil que se diera si somos capaces de demostrar o lo que decíamos antes de defender la idea nuestra de, oye, esto es mejor por esto, por esto, por esto o sea al final acabo el objetivo es hacer algo lo mejor que podamos o lo mejor que sepamos y creo que como el fin es el mismo nos ponemos de acuerdo para de alguna manera llegar a ese consenso Bueno, pues ya no hemos quedado sin tiempo para más preguntillas ahora vamos a pasar al café, por favor, un segundillo un segundillo que me gustaría que me escucharais después de que vengamos del café tenemos a Juan Manuel Cívico era un presupuesto que venda pero sin quedarte vendido en esta sala tenemos metodo 30 para ostimización de radio conversión de Pablo Moratino un aplauso para estos dos sitios