 Bueno, en primer lugar, dar la gracias a la organización de Work and Chiclana por haber confiado en nosotros, por habernos propuesto la posibilidad de participar en esta oponencia y sobre todo también felicitarlos por como están organizando en estos dos días todos los eventos y toda la work, y también por supuesto dar las gracias ya llevamos un par de días intensos y a todas las personas que habéis querido venir aquí a escucharnos. A escuchar una ponencia sobre cómo utilizar WordPress en la consultoría y un cambio en la mentalidad y la estrategia que hemos implementado en nuestra empresa. Nosotros empezaremos hablando, obviamente, haciendo una presentación, seguiremos contando el punto de partida desde el escenario inicial que nos encontramos y sobre el que empezamos a trabajar y luego qué estrategia hemos implementado para encajar un herramiento, un producto como WordPress, dentro de la consultoría. Y luego, mi compañero Jesús hablará sobre la ejecución de proyectos tanto a pequeñas como a gran escala porque consideramos que eso es uno de los grandes fuertes que tiene WordPress. Acto seguido, hablará de un caso muy concreto en el que estuvimos participando que es con Telefónica y finalmente, daremos una pincelada sobre algunos casos de éxito que nos hemos encontrado en este tiempo. Bueno, mi nombre es Francisco Lobato, soy ingeniero técnico informático de sistema, aunque llevo más de 10 años, en concreto entre 14 y 15 dedicándome al desarrollo y actualmente soy responsable de la comunidad de desarrollo open source en Babel sistema de información. Bueno, yo soy Jesús Jiménez, soy compañero de Apache en la comunidad de open source and content solution. Soy el Tesla, y bueno, también llevo unos 10 años de experiencia en el mundo de comer y web. Empecé mi carrera como frilan con una empresa abierta después cerrada y después me pasé aquí al lado oculto de Babel y ahí seguimos, más de 6 años. Bueno, ¿cuál es el punto de partida? Nosotros partimos de la necesidad, como empresa consultora y empresa que se debe, a proporcionar servicios a los clientes con la necesidad de estos clientes de la creación de sitio web de distintas tipologías, bien portales informativos, páginas de venta online en las que nos hacen llegar la necesidad de tener una herramienta en la que implementar y en la que dar esta información. Nosotros actuamos con ello muchas veces en plan proactivo y otras veces en plan reactivo, es decir, hay veces que ellos nos hablan y nos proponen directamente usar un WordPress, porque es una tecnología que ellos conocen, porque es una tecnología que se siente cómodo, y luego también es cierto que ya conforme vamos cogiendo experiencias, lo que hacemos nosotros mismos en función de los requerimientos que ellos nos hacen llegar es proponerle una herramienta WordPress porque pensamos que es lo que más se adapta a la necesidad de que ellos tienen. ¿Qué es lo segundo que nos encontramos? Pues nos encontramos con la necesidad de tener gente formada, con tener gente experta, con tener gente que tenga la capacidad de resolver esos problemas a la hora de ejecutar los proyectos. Al final, yo creo que, sino la gran mayoría, todos los que estamos aquí nos debemos darle un buen trabajo a nuestros clientes y darle un producto de calidad. Eso se consigue con gente que proporciona valor, con gente que haga un trabajo lo más cercano a la excelencia posible. Entonces, a partir de los puntos anteriores, ¿qué es lo que nosotros hacemos? Nosotros consideramos importante definir una serie de pautas metodológicas, de gestión, de ejecución de proyectos. Es decir, vamos a plantear una estrategia que, a partir de un herramienta o pensarse cómo es WordPress, nos permita dar o sea cubrir la necesidad desde nuestro cliente con la gente que tenemos experta en ello. ¿Cómo hemos hecho? Y ahora nosotros vamos a contar aquí el caso concreto de cómo hemos implementado estas estrategias en nuestra compañía, pero nosotros pensamos que es completamente extrapolable a cualquier empresa de tipo consultoría, de mediana o quizás gran tamaño que se parezca a la nuestra, porque está definido por una serie de pasos bastante lógicos y que consideramos bastante interesantes. En primer lugar, unificación del expertise. ¿Esto qué quiere decir? Nosotros llegamos y nos encontramos que tenemos varios grupos de trabajo bien en proyectos cerrados, bien en servicios gestionados, trabajando con WordPress, bien creando nuevos portales, bien dando mantenimiento. Nos encontramos con que están dispersos en distintas áreas de negocios para distintos clientes y en realidad trabajando cada uno a su forma, sin tener tampoco contacto entre ellos. Entonces nosotros hacemos una unificación del expertise, es decir, creamos una comunidad de desarrollos de gente especializada de modo que tenemos a toda la gente que tiene capacidades en WordPress bajo un mismo paraguas, de modo que nos vamos a segundo punto una vez que hemos recogido a toda esta gente, somos capaces de hacer una definición de metodología, pero una metodología en muchos ámbitos. Primero, una metodología de desarrollo, vamos a trabajar utilizando el IDTAL, con los plugins TAL, haciendo las cosas de esta manera, una también metodología para la gestión de los proyectos, tenemos una herramienta corporativa de gestión de tareas, bien giras, bien RedMind, la que cada uno utilice. Vamos a educar a la gente en trabajar con esta herramienta de trabajo, y luego también pues a la hora de coordinarnos con otras comunidades, porque nosotros trabajamos en el desarrollo, pero necesitamos también QA, necesitamos también maquetación y demás que eso lo derivamos en la otra parte. Aprovechamiento de recursos, en el momento en el que empezamos, que ya tenemos una metodología, en el momento en el que empezamos a hacer desarrollos interesantes, utilizamos plugins, compramos plugins, desarrollamos plugins, muchas veces intentamos trabajar en proyectos que se parezcan, bien por el área de negocio, bien por la tipología que tienen unos entre otros, que ocurre que la capacidad es la que yo tenga de reaprovechar trabajo que yo he hecho me va a permitir recibir más beneficios porque mi trabajo es mucho más justifico. Entonces, generamos un repositorio con plugins, documentación y demás que se reaprovechable. Importante la formación, en el momento en el que ya tenemos un recorrido nos damos cuenta de que los equipos van creciendo, la comunidad va creciendo, la gente que ya lleva unos años de experiencia, pasa por todos los ciclos de becario, desarrollador junior, desarrollador senior, entonces, que hacemos que la gente que tiene ya un expertis sea capaz de ese expertis proporcionárselo a los perfiles más junior, es decir, hacemos que los seniors trabajen, que es la creación de formaciones, identificando problemas que a futuro se pueden encontrar y esa experiencia, ese conocimiento se lo hagan llegar a los perfiles más juniors. Evolución del desempeño, ¿qué es la evaluación del desempeño? Nosotros tenemos un proceso anual, obligatorio, semestral, opcional en el que cada persona de la compañía recibe feedback y ese feedback en que consiste, por una parte, en hacer una evaluación, es decir, una evaluación no numérica, es decir, se trata de contarle a la persona que ha hecho bien, que ha hecho mal, identificar debilidades, identificar fortalezas, darle feedback, potenciar las fortalezas y, en la medida de lo posible, intentar mitigar las debilidades. Aparte de eso, estableciendo un plan de desarrollo, es decir, un plan de acción, definir unos objetivos que durante el año permitan desarrollarse en las tecnologías que a él le gusta o por la línea de desarrollo que a él prefiera, en este caso estamos contando el caso concreto de Warpre para Warpre. Y de aquí que sale de la evaluación del desempeño, porque es cierto que es una evaluación en el que un responsable le da feedback a la persona en cuestión, pero esa persona tiene la posibilidad de decir, oye, a mí me gustaría desarrollarme por esta parte, por esta tecnología, y de ahí sale el último punto, que es decir, oye, nos encontramos con que hay mucha gente que en su día a día está trabajando y está desarrollando con Warpre y a nosotros nos dicen, oye, estoy trabajando con Warpre para la compañía X, pero podíamos utilizar este conocimiento que nosotros tenemos para colaborar con la comunidad de Warpre, hay un evento, no, como no podemos llamar, programa, iniciativa, que es el del 5%. Entonces hay una serie de gente, mucho de ellos aquí presenten, que se sienten partícipes de esa comunidad, que quieren colaborar con esa comunidad, que quiere, digamos, devorberle a la comunidad lo que Warpre le ha proporcionado, entonces es aquí que sale, sale que nosotros, digamos, vale, pues igual que nosotros tenemos la capacidad como responsable de exigir en vuestro trabajo, vosotros, como desarrolladores, tenéis también la responsabilidad de exigiros a nosotros. Entonces, ¿qué ha salido aquí? Porque en realidad que nosotros estemos aquí hoy, que empecemos un planning para colaborar de forma activa con la comunidad de Warpre. Y esto me parece muy interesante y lo voy a leer tal cual, el resultado final debe tender a un cambio de paradigma para dejar de entender Warpre como una herramienta de necesidad de clientes, recordad cuando hacíamos la introducción hablábamos de que nuestro punto de partida es la necesidad que nos hacen llegar nuestros clientes, que llegado al momento también podemos reconvertirla, que nosotros le hagamos ver que tienen una necesidad de eso y promoverlo como un proyecto que participa activamente, es decir, pasamos, hemos pasado, cronologicamente, desde la necesidad del cliente a el plan de contribución establecido en el que ya estamos trabajando. Bueno, y este ha sido, digamos, el proceso de encajar Warpre dentro de la consultoría. ¿Qué? Ah, vale, va a tener las manos muy cargas. Bueno, y ahora yo os voy a explicar un poco cómo esta parte teórica la llevamos a día a día a la práctica, ¿vale? En nosotros los proyectos tanto a gran como a pequeña escala lo dividimos en la siguiente fase. La primera, como siempre, es un estudio y una estimación. Se estudia, nos dividimos en las diferentes comunidades tecnológicas, los diferentes responsables, test leads y los senior disponibles, pues nos dividimos para estudiar y hacer el funcional y técnico de la oferta y así poder plantear una oferta, una presentación y mandársela al gerente y, en este caso, al cliente. Si al cliente y al gerente le encajan, pues ya pasamos a la siguiente fase, que es la ejecución del proyecto. Para ello, tenemos dos tipos de proyectos. Los proyectos más simples lo hacemos con equipos multidisciplinares, de forma que tenemos equipos más pequeños con perfiles que desarrollan diferentes partes, tenemos full-stack, gente de maquetación que también se encarga de contribuir el contenido y otros equipos más especializados, ya para proyectos más complejos, con pues ya su analista, gente de backend, gente de front especializada, gente de contenido, SEO y los demás perfiles que sean necesarios. En los proyectos simples, pues lo hacemos de una manera bastante sencilla y conocida por nosotros seguro, que es un WordPress base con unos plugins que solemos utilizar, tema comercial y un repositorio de plugins, típicos plugins que todos usamos y todos conoceremos por aquí, los que ya la comunidad sabe bastante bien cómo llevarlos a cabo y cómo ejecutarlo. Y ya en proyectos más complejos y proyectos más grandes, partimos de ese mismo WordPress base y, aparte, con un tema propio y una factoría de plugins. Muchos clientes quieren y apuestan por opensource, pero siempre dicen eso de vale, pero los plugins van a ser míos o porque son servicios demasiado específicos que si te tiene que conectar con una API de clientes no hay ningún plugin que conecte comercial, entonces los creamos desde cero. Así también hacemos una factoría y un repositorio de plugins propio del cliente. Vale, la diferencia entre una empresa mediana y nosotros a nivel de consultoría, pues es el siguiente departamento de nuestros compañeros de calidad. Aquí tenemos un departamento que se encarga de diseñar y automatizar todas las pruebas para cumplir con todos los requisitos técnicos y funcionales del proyecto, de forma que lo testean todo, tanto la parte front como la parte de desarrollo, BAC, y si hay que cumplir con el AA o AAA que es imposible, pues también lo testan. Y por último, una vez que tenemos ya el proyecto listo y ha implementado, nuestros compañeros de arquitectura se encargan de implantarlo ya sea en la infraestructura propia del cliente, en temas cloud, Amazon Web Services, Docker o lo que tengan. Y hasta aquí el tema de cómo llevamos nosotros los proyectos. Aparte de proyectos, también hacemos consultoría. Os voy a explicar un caso en el que tuve la suerte de poder participar y es que Telefónica nos invitó con una RFAI que nos solicita información para resolver uno de los problemas que tienen o una de las necesidades. En este caso querían hacer un proyecto piloto de emigrar y crear todas las web corporativas que tienen actualmente en Telefónica.es pasarlas a WordPress. Para esto los requisitos eran bastante grandes, había que cumplir con la AA, teníamos multitud de tipologías web, hasta unos 25 portales diferentes, con API y red propia y al final se trataba de emigrar esos 25 portales distintos con unas 19.000 páginas. Todo esto venía en un documentillo de unas 80 páginas donde nos pedían todo lo que querían y una carta los Reyes Magos, bastante bonita. Al final nosotros, pues, tras unos meses de estudio junto con diferentes compañías y colaboradores, pues creamos una identidad corporativa propia, un tema propio, factoría de plug-in, temas con vizdata y con inteligencia artificial para la emigración y los patrones y todo esto se tradujo en un documento de unas 100 típicos páginas con el funcional y el técnico de cómo llevaríamos a cabo este proyecto. Sólo era eso, el estudio. Se lo entregamos a Telefónica, ahí se quedó, por ahora no nos han dicho nada, pero bueno, pasa una pandemia por medio, así que lo mismo se le quito las ganas. Pero vamos, esto viene a demostrar que una empresa como Telefónica bastante quería hacer un piloto de emigrar al open-source con su propia factoría de plug-in, con su propio repositorio y bueno, hay bastantes futuros con el WordPress en las grandes empresas, tal y como nosotros estamos planteando y proponiendo. Y bueno, por último aquí un poco los casos de éxito que tenemos y para las empresas que colaboramos. Por un lado tenemos WordPress Medios, tal es como el de Massesa, que es la empresa metropolitana de Aguas de Sevilla o el consorcio de Aguas de Bilbao. También trabajamos para el BVVA con la Fundación Microfinanzas y con un par de revistas digitales. También en SABIA, que era ellos un proyecto de máfres, de temas de seguros y asistencia. Ahí empezamos con un WordPress que se junta con un eCommerce. Ahora mismo todo evolucionó a un WordPress con un fron en Angular y en RIA y también una aplicación móvil conectada. Y bueno, el último que tenemos y tenemos un compendio de bastantes web ahí es el proyecto de Ferroviar, que en estos días está bastante en un red. Está en boca de todo. Aquí es interesante que se ponen de manifiesto algunas cosas de las que ya hemos comentado. Es decir, fijaros cuando hablamos del reaprovechar conocimiento, de reaprovechar un desarrollo que se había hecho. Partimos de una compañía como GEMACESA, que es la empresa metropolitana de agua y saneamiento de Sevilla. Imagina las capacidades que hemos tenido a la hora de hacer la del consorcio de Aguas de Bilbao que más o menos es lo mismo. Es decir, hemos entrado con la misma herramienta en el mismo área de negocio, lo cual nos permite hacer mucho reaprovechamiento. Y estamos hablando de compañías no tan grandes y compañías más grandes. Es decir, yo creo que hay un estigma que la tiene incluso la propia gente de WordPress, que cree que al final el WordPress es para hacerle un desabio a tu cuñado o a la empresa de no sé cuál que te ha pedido el favor y no. O sea, la potencia de WordPress está en que para eso está bien, lo cual me parece bien, pero para implementar la web de una empresa del IBS35 también. Entonces, aquí yo creo que es responsabilidad de todo hacer valer mucho más las capacidades que tiene WordPress y en eventos de este tipo yo creo que ayudan bastante. Y dicho esto, no sé cómo vamos de tiempo, yo yo mirando el reloj, vamos bien. ¿Qué qué? ¿Bien minutos quedan? Si empezamos a seguir cuarto y son menos veinte. ¿Alguna pregunta entonces? Mucho tiempo. Yo estoy mirando el reloj. Ha dejado mucho tiempo para preguntar. Tenemos aquí la primera fila. Bueno, ella es tarde, van dos días y tampoco es plan de machacar al personal. Pero bueno, alguna pregunta, señor Dario tiene el micro, se lo tiro yo a la gente. Hola, muchas gracias por compartir vuestra experiencia como consultoría de trabajo. Ahora mismo también una empresa en la que estamos empezando en plan consultoría, aunque llevamos tiempo con WordPress y eso. Y queremos considerarnos consultoría, porque en el fondo hacemos todo ese stack que planteáis, pero está muy bien que hayáis compartido la reflexión. Y una de las cuestiones que precisamente estamos discutiendo recientemente entre nosotros es esa diferencia, qué criterios usamos para la diferencia entre proyectos complejos y proyectos básicos. Y la sonrisa desde suya me anima a escuchar la respuesta con más ánimo. Gracias. El te dará su opinión, yo te voy a dar la mía. La básica es, entre el complejo y el, la he llamado básico, ¿no? Básico o simple. Es que el simple no tiene una carga de desarrollo ad hoc que puede tener el complejo. Es decir, puedes tener un WordPress, la realidad es que lo puede montar cualquiera. Pero darle un acabado profesional, no. Y el acabado profesional como se consigue, se consigue con un buen diseño, se consigue con una buena maquetación, se consigue generando buenas funcionalidades. Entonces, las buenas funcionalidades hay que consiguen de dos modos distintos, pagando buenos plugins o si necesitas implementar una funcionalidad que no te la da ningún plugin, pues implementarla tú. Entonces, la complejidad donde viene es de la necesidad que tú tengas de implementar nuevos plugins que no satisfagan las necesidades del proyecto. ¿Hay dónde está la complejidad de mi punto de vista? Sí, básicamente, justo como ha dicho mi compañero, y la necesidad de ese desarrollador backend, el tiempo que tenga que invertir en ese proyecto pasa de simple a complejo. Es verdad que al principio de nuestra andadura con esto hace unos cinco o seis años, la mayoría de los proyectos se consideraban complejos, ya mucho se considera, gran parte se consideran simples por todo el conocimiento que ya tiene la comunidad, por todo el conocimiento que tiene los compañeros y las formaciones y cursos que hemos ido implementando a lo largo de la compañía con las diferentes comunidades. Y ya hay pequeños desarrollos que los de equipos de maquetación o de front son capaces de hacer y no necesitan de nosotros de back. Ahí es la diferencia. Al final, eso depende mucho del equipo que tengas. En mi opinión personal, el coste de desarrollo propio siendo muy alto lo que sea, no es nada comparado con el mantenimiento en el tiempo de ese código que ha generado public y no habéis contado un poco eso, cómo afrontáis el mantenimiento de un sistema complejo que habéis desarrollado nosotros mismos durante el tiempo. A ver, en los proyectos complejos donde desarrollamos código, normalmente solemos tener un contrato después de mantenimiento de ese mismo desarrollo y de esa serie de plug-in con la empresa. Si ese contrato se mantiene, pues vamos desarrollando y actualizando o haciendo volutivos. La otra manera que hay es yo te lo entrego, le pongo el acito te lo doy y dentro de dos años cuando haya cambiado todo, pues me vuelves a llamar y montamos otro volutivo para ir actualizando, pero no es más que lo que ya conocemos y al mismo nivel, que se puede llamar ferro vía al telefónica, pero funciona igual que mercería a Juan y que todo le funciona bien hasta que deja de funcionar y te vuelven a llamar. Ten en cuenta de que hay muchas veces te encuentras cuando, sobre todo en los mantenimientos, cuando una empresa va cambiando su proveedor, pues si cada proveedor pone su granito de arena, al final de aquello no hay por donde cogerlo. Entonces, para esto es importante, si nosotros seguimos trabajando en el mismo mantenimiento, como ya tenemos una metodología establecida, lo que persigue esa metodología es que cuando una persona sea capaz de moverse de un proyecto a otro, ya tenga automatizado ciertas cosas. Es decir, documento, vistas en Gira, un plug-in que utiliza luego de este modo, etcétera. Entonces, la idea es que haya una buena documentación y que si nosotros los seguimos llevando, la forma de trabajo no difiera de la que establece esa metodología. Pero sí, normalmente, como un proyecto de mantenimiento haya pasado por más de un proveedor, llega un momento en el que hay que decir, oye, paremos y vamos a analizar esto bien, porque no hay por donde cogerlo, porque al final cada uno, el programa de su padre, son adecuados a la realidad. Venga, última. Es Juanma, ánimate. ¿Lo te ha tocado claro? Maria, no, quiero repetir. Yo hago otra que tenía, pero no quiero acá para, pero sí, hay otras cosas. Tenéis, aunque así es cosa mi idea, tenéis una curiosidad. Plug-in que haya en el repositorio, que sean famosos o que os gusten, como están hechos, por lo que sea. Esa pregunta, seguro, sería más buena que era en contestar a algunos de los que están aquí sentados delante, que son los que al final trabajan en el día a día con estos plug-ins. Sí, justo eso es lo último que ha comentado mi compañero y lo que hemos iniciado de un año para acá, que es la colaboración y la publicación de plug-in. Por ahora no tenemos ninguno, todos están desarrollados, cara a cliente y por el compromiso de venta a cliente, confidencialidad y demás. No lo publicamos, pero es el objetivo que tenemos para este año, de compartir con la comunidad y de publicar plug-in y hacerlo de forma gratuita. Claro que tenéis en cuenta que si nosotros tenemos un proyecto cerrado con un cliente y les hacemos un plug-in a medida, eso no lo podemos… La realidad es que para participar en la contribución tiene que ser necesidades que nosotros vayamos detectando que nos van pidiendo los clientes adelantándose a esa necesidad. Es decir, si nos damos cuenta de que entre clientes en concreto nos están pidiendo… Me invento una gestión de vacaciones por ejemplo, y determinamos que no hay ningún plug-in, que el plug-in que hay no lo hace bien, pues estamos en procesos de este tipo de cosas, de que hacer de forma interna, no imputable o cargable al desarrollo en un proyecto en concreto de desarrollar ese tipo de plug-in que podamos luego subir al repusitor y que no solo porque somos muy buena gente y queremos contribuir en workmen, porque sabemos que eso a futuro nos va a tener un retorno de la inversión. Muchas gracias.