Resultado del Lean Coffe

Meetup «Ventajas y desventajas de Sylius como solución e-commerce PHP»

A english version of «Advantages and disadvantages of using Sylius as PHP e-commerce solution» is available at the end of the post.

Introducción

La semana pasada organizamos nuestro primer evento dentro del grupo de Meetup de Sylius. Antes de nada, agradecer la presencia de todas las personas que nos brindaron de su tiempo, vinieron a nuestras oficinas y aportaron sus puntos de vista enriqueciendo el evento, esperamos que pasaran un buen rato y se fueran con nuevos conocimientos y ganas de volver.

A modo de introducción, Sylius es, y cito la definición que aparece en su página web, «el primer framework adaptado a soluciones e-commerce». Desarrollado sobre Symfony y siguiendo los mejores estándares de calidad, contiene una serie de bundles que trabajan conjuntamente para facilitar el desarrollo de aplicaciones de comercio electrónico para programadores que estemos familiarizados con Symfony.

Sylius lanzó recientemente su primera versión (aunque ya lleva un tiempo entre nosotros en forma de beta), y nosotros decidimos realizar el primer proyecto con él para ver cómo es la experiencia, y aunque puede ser tema de otro post, adelantaré que ha sido un desarrollo muy interesante donde hemos aprendido y mejorado, y aunque aún es un MVP, os invitamos a que visitéis nuestro proyecto de cursos y formación: gravita.academy.

El evento

Volviendo al evento del grupo de Meetup, una vez más adoptamos el formato de mecánica Lean Coffee, que se adaptó bien en nuestro anterior evento, así que tras la ronda de presentaciones, dispusimos unos minutos para saber qué temas trataríamos durante la hora/hora y media que duró el debate, siguiendo un timebox marcado de 5 minutos con votación silenciosa de si seguíamos con el tema o pasábamos al siguiente.

 

Resultado del Lean Coffe

Temas que todos quisimos tratar

Temas

Temas priorizados

Temas tras la votación priorizados

Tras realizar la votación y priorización, hablamos sobre los siguientes temas:

¿Cómo va la generación de temas?

Una de las grandes ventajas que tienen otras soluciones de e-commerce son sus tiendas de temas, la facilidad de implantación y las ventajas que aportan con el consecuente ahorro de tiempo por la funcionalidad que tiene. Sylius tiene su propia página de temas y es interesante saber cómo desarrollar nuestro propio tema. Explicamos entonces nuestra experiencia desarrollando nuestro primer tema para nuestra tienda.

¿Disponemos de API para aplicaciones?

Con la división que estamos viviendo entre la parte frontoffice y backoffice de nuestras aplicaciones, surgió la duda de si el framework estaba preparado para que existiera una forma fácil de entablar comunicación si desarrollamos aplicaciones cliente con frameworks javascript como React, Angular, etc. La respuesta es que Sylius nos provee de las operaciones CRUD de nuestras entidades a través de una API si seguimos su forma de trabajar, además de permitirnos el uso de OAUTH ante operaciones que queremos blindar.

¿Qué ventajas tenemos con respecto otros frameworks?

Entramos en la comparación directa con soluciones que ya están más que consolidadas en el desarrollo de plataformas e-commerce. Aquí hablamos sobre nuestra experiencia, qué echamos de menos (YOAST SEO…), y las ventajas comparadas con los demás (disponemos de una base de código de muy buena calidad).

¿Cómo se integra con otros bundles (FOSUserBundle, SonataAdminBundle, …)?

Una de las grandes dudas es si el conjunto de la aplicación que desarrollemos dejará de funcionar en caso de sustituir o integrar otro Bundle externo. Una de las grandes ventajas de Sylius es la modularidad de la que dispone. Nos permiten trabajar con cualquiera de los bundles de los que se forma de manera individual para soluciones que no tienen por qué ser una tienda, además de poder sustituir uno de sus bundles por otro que deseemos, pero como siempre, con posterior trabajo de adaptación y seguramente pérdida de automatización por el camino.

¿Cómo configuramos despliegues automáticos?

La automatización del pase a los distintos entornos de nuestras aplicaciones siempre es un tema que suele ser interesante. Aquí describimos un poco nuestra experiencia al integrar, configurar dentro del proyecto el EasyDeployBundle, que es la alternativa que estamos usando tras pasar por Capifony y Deployer. Surgió también la necesidad de disponer de un modo de puesta en mantenimiento de Sylius.

¿Es fácil editar el proceso de compra?

Es algo muy común que desde el cliente nos soliciten que todo el proceso de compra se realice en un paso, o tener que adaptar nuestras aplicaciones a las distintas formas de pago y/o configuración de distintos TPV de bancos. El proceso de configuración básica para la puesta en marcha de una tienda es fácil gracias a que Sylius integra el PayumBundle.

 

¿Qué tal la comunidad? ¿Tendrá versiones LTS garantizadas?

Lamentablemente, no dio tiempo a tratar este tema, pero consideramos que es algo muy interesante que estaría bien discutir. Invitamos en cualquier caso a quien quiera que comente en este post.

 

Próximos pasos: Talleres

A modo de conclusión del evento, solicitamos a los presentes que decidieran el formato del siguiente evento (charla, debate, taller…), y el tema del que le gustarían que tratase, así que cada uno escribió en un post-it su apuesta para no influir en la opinión de los demás, y más tarde, entre todos, realizamos una votación para acordar el tema:

Claramente, existía una alineación en el formato, y tras la votación, acordamos que el siguiente evento será un taller sobre cómo desarrollar nuestro primer tema en Sylius.

Si quieres estar al tanto de próximos eventos y quieres formar parte del grupo, aquí tenéis el enlace del Meetup para poder registraros.

 


Meetup «Advantages and disadvantages of using Sylius as PHP e-commerce solution»

Introduction

Last week we had our first Sylius’s Meetup event. In order to introduce Sylius, is, and I only copy and paste the definition from his web, «The first framework for tailored e-commerce solutions». Developed over Symfony and following the best quality coding standards, Sylius contains bundles that works together to make easy the development of e-commerce applications for developers that are familiar with Symfony.

Sylius’s guys just launched his 1.0.0 version (although Sylius have been a long time between us as beta), so we decided to develop our first project using it, and, even though it is material for another post, the first impressions are very good. The development process was very interesting and we’ve learned and improved our skills, and, though is an MVP yet, we invite you to visit our learning and courses platform project: gravita.academy.

 

The event

Returning to the Meetup’s event, another time we use the Lean Coffee format that fits very well in our last event, so, after the presenting round, we let a bit of minutes to know what topics people want to talk about the hour / hour and half that remains of the event, so following a 5 minutes timebox with simple vote about if we discuss about the next topic or continuing with the current topic.

Lean Coffee topics

Lean Coffee topics that people wanted to discuss

 

Topics

Temas priorizados

Prioritized topics after the vote

After voting and prioritization, we talked about the next topics:

How about theme management?

One of the advantages of other e-commerce solutions are his themes shops, the ease of implantation and the shortion of cost for functional development. Sylius has his own theme page and is interesting to know how to develop a custom theme. We talked about our experience developing our first theme for our shop.

Is there an API for client applications?

Some of we are used to develop client side applications with JS Frameworks like React, Angular, etc., and they wonder about if Sylius manages this communication. The answer is that Sylius allows to use CRUD operations of our entities if we work following the Sylius’s way. In addition, we have OAUTH for secure API functions.

What advantages has Sylius against other frameworks?

We put Sylius in front of other e-commerce solutions. Talked about our experience, what we would like to have in Sylius (YOAST SEO…), and the advantages compared with the others (we will have a great quality base code using Sylius).

 

How works other bundles integration (FOSUserBundle, SonataAdminBundle, …)?

One of greatest doubts is about the functionally lost in case we change or integrate third party Bundles in Sylius. One of the greatest advantages of Sylius is the modularity. We can use individually each Sylius bundle in our projects even if it’s not a shop. Also, we can change one of them with other of our preference, but like always, we need to adapt it a bit, losing part of its automatization.

How we automatize the deploy?

The deploy’s process automatization to each environment always is an interesting topic. Here we described a bit our experience installing and configuring the EasyDeployBundle inside our Sylius’s project, the tool we’re using after try Capifony and Deployer. We talked about the needs of a «maintenance mode» in Sylius too.

 

Is easy to edit the checkout?

Is ordinary that our clients needs to change the default checkout process, for example, using one step checkout, or to make our applications capable of using a variety of payment methods and / or setup any bank payment gateway. The basic configuration process for a standard shop is easy thanks to Sylius’s PayumBundle integration.

 

How about the community? Will exists an LTS version?

Although this is a great topic to discuss, we finished the meetup time without talk about it. But we invite to comment on the post to anyone.

 

Next steps: Workshop

At the end of the event, we asked everyone to decide the next event format (talk, discuss, workshop…), and the topic they would like to learn, so everyone wrote in a post-it his bet to not change the thoughts of the others, and later, between all, voted his preferences:

We can see everyone was interested in a workshop, and the votes made the topic will be about how to develop our first theme in Sylius.

If you are interested in next events and want to be part of the group, here is the link to Meetup.

Invitamos a Juan Vázquez, desarrollador Ruby y cofundador de Sociack, a que nos cuente sus sensaciones en su visita desksurfing a nuestras nuevas oficinas.

No fue mi primera vez, ni tampoco será la última que haga desksurfing. Si aún no sabes de qué va el tema, te sugiero que des una vuelta por Google y mires qué cosas más chulas ocurren en torno a este movimiento.

Como te decía, hace unas semanas los chicos de Elemento115 me invitaron a que pasara los días que me iba a quedar en Madrid, trabajando desde sus oficinas en Pirámides.

La idea era redonda: tenía sitio para trabajar como si se tratase de mi oficina, rodeado de “compañeros del metal” como diría Bonilla, internet, risas y lo más importante, aprender cómo funciona otro equipo aunque solo fuera por 2 días y medio. Fue un win-­win.

Yo estoy ahora mismo en Dublin, trabajando en un equipo similar en características pero con un entorno y una historia muy distinta.

Ellos son un estudio que da servicios de desarrollo mientras que yo estoy en el lado de la empresa de producto único.

El poder contrastar qué y cómo llevan a cabo el día a día te da un punto de vista de qué hay en común y qué se puede mejorar/cambiar en tu propio equipo.

Lo mismo en el sentido contrario.

El desksurfing es un win-win

Si tienes un equipo con oficina física (nada de remoto, este es otro tema), deberías unirte a ofrecer un puesto a visitantes como yo.

Piensa lo barato que sale el hecho de tener a un profesional que puede ver el funcionamiento de tu equipo y darte una idea que te permita mejorar tus procesos ahorrando costes, que ahora puedes invertir en algo que te haga falta y todo por el uso de una silla, un escritorio y acceso a tu wifi.

Como dije un win-­win.

Foto de la visita desksurfing de Juan Vázquez con el equipo de Elemento115

Un selfie de Juan con el equipo de Elemento115

Tanto si eres nuevo en esto del desksurfing como si eres veterano, si estás o pasas por Madrid tienes que hacerles una visita a los compañeros de Elemento115 para vivir el buen rollo que tienen siempre (mira que son majos los joios) y por descubrir que hay formas de vivir tranquilos y sin presiones, si se tiene todo planeado cómo debe ser.

¡Nos vemos en la siguiente visita a Madrid!

__

Juan Vázquez, desarrollador Ruby y cofundador de Sociack
@jnillo9

Últimamente en Elemento115 estamos revisando nuestras rutinas en cuanto a productividad personal se refiere.

En la última retro, al estar quejándonos de la «falta de tiempo» para hacer todo lo que nos gustaría, nos dimos cuenta de que primero tendríamos que meter en eficiencia nuestra propia productividad personal.

Ser parte de un equipo ágil no conduce por arte de magia a la mejora de la productividad a nivel personal.

Un equipo está concentrado en su propia productividad y eficiencia como entidad, en el aporte de valor a los clientes como conjunto, en la mejora continua a lo largo de los sprints… y aunque eso repercute a la larga en la mejora «personal», he pensado que lo mejor es que tratemos las claves para acelerar esa mejora.

Vamos a empezar con una serie de charlas internas, que iré trasladando a posts.

La primera charla, la de hoy, fue una introducción, un rápido acercamiento a los temas y trucos que considero importantes cuando hablo de productividad personal.

¿Cómo elaborar el plan de acción del día?

La planificación personal del día o «mi plan de acción del día» es la lista de tareas o cuestiones que he preparado para resolver en ese día, y es la clave más importante a tener en cuenta cuando hablamos de productividad personal.

Las entradas en esa lista son los trabajos que tengo pendientes en mi agenda que priorizo según estos criterios:

  • Urgente e importante: primero si es urgente e importante.
  • Complejidad: primero lo más difícil y laborioso (lo más susceptible de complicarse)
  • Aporte de valor: primero lo que más valor aporte al equipo, al proyecto, cliente, etc.

Hacer esa lista es un trabajo personal. Yo la hago cada día, y he ido aprendiendo varias cosas:

  • Las tareas que me apunto, no suelen ser muy grandes. Y si lo son, trato de despiezarlas para hacerlas más pequeñas hasta que me quepan en ratos de 45 minutos o una hora.
  • Me gusta tener muy claro qué objetivo busco y cuándo sabré que la he acabado. Si no tengo esas dos cosas bien claras, se despierta un disparador interno.
  • Tengo que dejar un hueco para cosas imprevistas, interrupciones, despistes, etc. No conviene llenarse la previsión del día completamente.

En la lista debe haber cosas que podamos acabar en un día, por supuesto, a veces no es tan fácil «despiezar» una tarea para que quepa en un día máximo. No deja de ser una recomendación general.

Al final del día, tendrás una lista con algunas cosas tachadas, otras que te han quedado pendiente, y otras nuevas que has ido añadiendo.

Como sugerencia, en ese mismo momento, pasa a limpio la lista en una hoja nueva y así ya tienes algo de trabajo hecho para el día siguiente.

¿Cómo cumplir el plan del día?

A pesar de mis mejores intenciones, cumplir con mi propia lista de tareas, es una tarea que requiere de cierto esfuerzo.

Antes de nada tengo conocidos graves ladrones de tiempo, adoradores de la procastrinación, que en la medida de lo posible trato de combatir.

  • No tengo guardadas las contraseñas en el navegador de ninguna de mis redes sociales. Eso hace que cuando me da alguna tentación, me lo piense dos veces.
  • No tengo abierto el correo electrónico. Solo lo consulto cuando lo decido para en esos momentos actuar, responder, archivar o delegar los temas que aparezcan.
  • Tengo apagado el volumen del móvil, y boca abajo, aunque sí dejo activa la vibración de las llamadas.
  • Tengo apagadas las notificaciones en el móvil. Todas.

Esto me ayuda a mucho a mantener un alto nivel de concentración, a mantener el foco en la resolución de la tarea y nada más en ese momento. A estar presente en ese instante.

Además, el haber definido claramente los objetivos de una tarea, me ayuda a entender cuándo se han cubierto, y cuándo darla por terminada. Recuerda: lo perfecto es enemigo de lo bueno.

Otros factores clave que me ayudan a cumplir con el plan son:

  • Saber decir que no a imprevistos. A veces basta con un «ahora no puedo», para darle prioridad a la tarea en la que estamos y atender el imprevisto si es más urgente e importante que una de nuestras tareas pendientes cuando corresponda.
  • Saber delegar. Mientras estamos trabajando en una tarea, o cuando surge un imprevisto, si es delegable, lo debemos delegar.
  • Saber pedir ayuda. Lo llamo el comodín de la llamada o el comodín del público. A veces, una simple llamada a un cliente o una pregunta a un compañero resuelve y desbloquea una duda, una decisión o una tarea.
  • Saber tomar decisiones  que conduzcan al término de la tarea en el menor tiempo posible.

Por último, hay que planificar y disfrutar de los descansos, entre los bloques de concentración de 45 minutos o una hora, conviene relajar la vista, la mente y el cuerpo unos minutos para poder retomar la concentración máxima a continuación, es un buen momento para procastrinar, qué diablos: Comer y beber algo, abrir el mail y revisar el correo, escribir un tuit, hacer una llamada…

Disfrutaremos más de ese momento así y además seremos más productivos después.

 

¿Cómo cumplir con la productividad todos los días?

Ya es difícil cumplir con nuestro plan de acción del día un día.

Hacerlo todos los días requiere de una fuerza de voluntad y disciplina extraordinarias. Esto es así. No hay atajos.

A mi personalmente me ayuda mucho convertir en hábito las cosas que se me hacen difíciles para hacerlas fáciles, para hacerlo cotidiano.

Y las mecánicas que explicaba en los puntos anteriores son un buen ejemplo.

Conseguir hacer todo a la vez la primera vez es difícil. Pero podremos conseguirlo si vamos añadiendo a la rutina diaria poco a poco las cosas.

Y quiero terminar hablando de dos cosas, de las que he sido consciente hace relativamente poco tiempo, y que influyen de forma determinante en mi concentración y capacidad física y mental, y por tanto en mi capacidad para mantener mi productividad a tope:

  • Las cosas que me quitan energía: reuniones, charlas públicas, presentaciones, negociaciones… son algunas de las cosas que necesitan y consumen mi energía, me gustan, pero soy consciente de que me agotan.
  • Las cosas que me aportan energía: escribir, leer, dibujar, pensar, resolver problemas, analizar algún proyecto… son algunas de las cosas que me refrescan, que me cargan las pilas.

Trato de tener muy en cuenta esto a la hora de planificar. Sé que si por la mañana tengo una reunión, después más vale que haga algo que me recargue las pilas o que no requiera de demasiada concentración, ya que estaré bajo de energía, y estaré arrastrándolo toda la semana.

Lógicamente estos factores son diferentes para cada persona, así que te recomiendo que busques qué te quita y qué te aporta energía a ti, para que puedas planificar tu día a día también en base a eso.

En próximos talleres y charlas internas iremos profundizando en todos estos temas, y os aquí os lo iremos contando :·)

Dejadnos algún comentario, nos gusta mucho recibir feedback =)

Manuel Barroso Parejo.
Comandante de la misión Elemento115.
mbarroso@elemento115.es
@manubarpar

jQuery vs JavaScript

Planteadas en nuestro artículo anterior las ventajas e inconvenientes de utilizar jQuery, llega la hora de decidir qué hacemos con él. Y para ello el primer paso es responderse a una pregunta:

¿Qué necesidades de JavaScript tengo como desarrollador?

Es difícil encontrar una respuesta que no requiera una explicación de miles de píxeles de longitud, así que vamos a tomar el caso de un estudio como Elemento115, y pensar en los proyectos más recientes que tengamos. Eso nos permitirá limitar los casos de estudio.

Para empezar debemos distinguir entre proyectos de webs puramente comerciales, como microsites o páginas clásicas de empresa tipo «quiénes somos-productos-servicios-contacto«, y web apps, que son algo más complejas, en funcionalidad, evolución y tecnología. La definición del tipo de proyectos que encontramos en internet es bastante más poliédrica que está simple categorización, pero como primer acercamiento nos puede servir.

Pueden servir como ejemplo, en nuestro caso, Titanio Estudio y Zio Rød Brand Consultants.

En el primer caso nos encontramos con unas necesidades de JavaScript muy básicas: mostrar/ocultar elementos, plegar/desplegar secciones, añadir algún efecto visual, validar formularios… en general acciones que tienen mucho que ver con el filtrado y manipulación de elementos del DOM, y la aplicación de animaciones sobre ellos.

Moviendo elementos en el DOM

¿Y lo bien que lo pasamos moviendo cosas por el DOM?

En el segundo, a lo anterior se le unen peticiones AJAX, preparación, envío, recepción y procesado de datos (que pueden llegar a ser bastante grandes y complejos), almacenamiento local de información, gestión dinámica del contenido, exportación del código a Mobile App… en definitiva, un conjunto de funcionalidades que requieren de una buena estructura del código que permita que sea robusto, escalable y testeable.

Código de un fichero JSON

El JSON. ese gran amigo

Definidas las necesidades, hay que pensar cuál es la mejor opción para satisfacerlas.

¿Es jQuery la alternativa que más me conviene?

Esta es la pregunta del millón, y el motivo de estos dos artículos. Y la respuesta es… depende.

Para proyectos muy sencillos, las ventajas de jQuery se ven potenciadas pues nos permiten alcanzar resultados muy óptimos en muy poco tiempo, y por la propia naturaleza del proyecto será raro que nos encontremos algunos de sus inconvenientes, o al menos no de forma que nos afecte demasiado. Por estos mismos motivos podemos llegar a plantearnos usarlo si es que seguimos una metodología en la existe una entrega rápida de prototipos funcionales de forma recurrente.

En el caso de web apps, podemos empezar a dudar, y con motivo. Si bien es cierto que muchos de ellos serían abordables y correctamente resolubles con una buena arquitectura basada en jQuery, puede que no sea lo más óptimo, pues nos obligará a hacer un trabajo extra para llevar la librería a los límites que queremos al no estar diseñada para ello, cuando usando Vanilla JS podríamos obtener los mismos resultados de forma más natural y con un código más fácil de testear y exportar.

Si a esto se le unen otros factores como el equipo de desarrollo con el que cuentes, el tiempo del que dispongaslos navegadores a los que tengas que dar soporte, la deuda técnica que seas capaz de asumir… hay tantos factores con tantas posibles alternativas que resulta imposible elaborar una respuesta absoluta. Para cada caso habrá que tener en cuenta las conclusiones anteriores y analizar, según los factores externos, qué es lo mejor.

¿Entonces?

Como hemos visto, el escenario que se nos presenta no es sencillo: multitud de situaciones iniciales distintas, y variedad de ventajas e inconvenientes de cada decisión, lo que nos lleva a la imposibilidad de encontrar una respuesta clara a la pregunta que nos hacíamos al inicio: ¿qué hacemos con jQuery?

Existiendo alternativas a muchas de las cosas para las que veníamos usándolo, quizá la mejor opción sea la de casi siempre: no tomar ninguna decisión radical, empezar a probar desde ya mismo a hacer proyectos sin jQuery y evaluar el proceso. Y poco a poco, sin abandonarlo del todo, ir añadiendo a nuestro repertorio técnico el Vanilla JS de la misma forma que en su momento hemos hecho con otras tecnologías, hasta llegar al punto de disponer de un elemento más con el que decidir cómo abordamos los proyectos.

Porque, que no se nos olvide en medio de esta vorágine tecnófila, lo importante en nuestra profesión es resolver problemas de la mejor forma posible. La herramienta que utilicemos para ello no importa.

La semana pasada llegaba, de la mano de Firefox 52, la primera versión definitiva en producción de Grid Layout. Dos días más tarde le seguía Chrome 57, y es de esperar que Safari lo haga en breve, incluso han publicado ya un artículo en su blog con una introducción a Grid. A Edge de momento no se le espera, salvo soportando la anterior especificación.

La importancia, posibilidades e impacto que tendrá en la forma de trabajar, la poco habitual simultaneidad en el soporte de los principales navegadores, así como el largo y tortuoso camino seguido hasta llegar aquí, hacen de este lanzamiento uno de los eventos más importantes en la historia reciente de CSS.

Pese a que no han faltado los primeros bugs en Chrome, con extraño diagnóstico incluído, parece el momento adecuado para leer el estupendo tutorial de Rachel Andrew, esta guía tan completa o tal vez prefiramos empezar con el sencillo inicio que propone CSS-Tricks, en donde nos encotramos una cita de Jen Simmons que convendría no perder de vista:

We need to explore CSS Grid until we understand what it wants to do, what it can be forced into doing, and what it refuses to do. Many designers may not ever learn to code CSS, but you need to understand CSS well enough to understand our artistic medium.

No sería la primera vez que la llegada de una nueva tecnología, o incluso una forma totalmente nueva de abordar el trabajo, nos lleva a forzar los límites y caer en un uso incorrecto de la misma. Leamos, aprendamos, pongamos en práctica y disfrutemos. Se nos acaba de abrir un nuevo horizonte 🙂

En Elemento115 tratamos de hacer reuniones demo con la frecuencia que los diversos proyectos necesitan, como trabajamos con varios a la vez a lo largo de un sprint, puede haber varias demos, de varios proyectos distintos y no siempre coincidentes con el final nuestro sprint.

Sin embargo, nos consta que no hacemos las suficientes y las hacemos algo apresuradas a veces, o a veces se nos pasan, las aplazamos… se nos juntan varias… lo que provoca que perdamos oportunidades de obtener feedback temprano valioso.

Hace poco descubrimos que nos hacía falta fortalecer los «por qués» y los «cómo» hacer demos.

A continuación, os cuento lo que puse en común con el equipo en una charla formativa interna.

 

¿Qué es una demo?

Las «demos», o demostraciones que hacemos, son pequeñas presentaciones que ayudan a trasladar al equipo, al cliente, o a otros interlocutores el grado de avance en un proyecto, fundamentalmente para la obtención de feedback.

Por supuesto, la presentación en sí no tiene por qué ser de software funcionando, puede ser cualquier estado previo, y sobre cualquier formato…

  • unas ideas dibujadas en unos wireframes en papel,
  • unas ideas dibujadas con sketch o photoshop,
  • un prototipo navegable funcionando en InvisionApp,
  • una maqueta HTML de una serie de interfaces,
  • y por supuesto, software funcionando, ya sea en local, integración, pre o pro.

Como recomendación, es necesario que se de un ambiente relajado, que fomente la escucha y la participación.

Objetivos de la demo

  • Mostrar el resultado del trabajo y esfuerzo realizados.
  • Dar a conocer grado de avance y estado actual de proyectos.
  • Contrastar y conciliar expectativas.
  • Obtener aprobación, validación o feedback.
  • Consensuar siguientes pasos.

Quién hace la presentación

Nadie mejor que la persona que ha realizado el trabajo,  y si ha sido realizado por varias personas, cada una puede contar una parte. Es importante que todas participen de la exposición.

Al inicio de la demo es necesario recordar qué diferentes funcionalidades se van a tratar, qué se espera de los participantes durante y al final de la misma y qué timebox está reservado.

También es importante que haya alguien encargado de dinamizarla, y asegurarse de que se respeta el timebox cumpliendo los objetivos de la demo.

Antes de la demo

  • Preparar la sala o la zona y los materiales donde se va a realizar la presentación.
  • Todo el mundo debe estar cómodo, ver bien el monitor o los materiales que se vayan a presentar.
  • Preparar los datos de prueba y asegurarnos de que la funcionalidad que vamos a enseñar está disponible, y funcionando correctamente en el entorno en el que vamos a presentarla.
  • Convocar a los diferentes asistentes, trasladándoles qué se va a presentar y qué se va a requerir de ellos en la demo.

Guión orientativo

Para presentar cada funcionalidad, lo ideal es seguir estos tres pasos:

  • Contar en términos de aporte de valor a negocio y a los usuarios, cuál es el propósito de lo que se cuenta en la demo.
  • Enseñar qué aspecto tenía el sistema, o cómo se solucionaba el problema o atendía la necesidad antes del cambio o mejora.
  • Por último, enseñar en qué consiste el cambio o mejora y cómo ha quedado el sistema ahora.

Conclusiones y siguientes pasos

Es imprescindible que se recoja el feedback de los participantes y se acuerden los siguientes pasos. Además, En muchos casos puede ser reunir una lista de mejoras y cambios sobre la funcionalidad presentada.

La propia demo es una reunión de dos o más partes donde se busca la comunicación, no es una simple exposición.

Recordad preguntas como las siguientes, que ayudan a obtener feedback:

  • ¿Qué opináis?
  • ¿Os chirría algo?
  • ¿Qué es lo que más os ha gustado?
  • ¿Lo consideráis una buena solución?
  • ¿Qué mejoraríais?

 

 

Manuel Barroso Parejo.
Comandante de la misión Elemento115.
mbarroso@elemento115.es
@manubarpar

Elemento115-La-hipotesis-de-la-Reina-Roja

Lo que es aquí, como ves, hace falta correr todo cuanto una pueda para permanecer en el mismo sitio.

-Dijo la Reina Roja.

 

Es una frase que hace años me obsesiona, y que describe muy bien la exigencia que me impongo, y el cómo siento y vivo el crecimiento personal y profesional.

Para mí significa el esfuerzo constante, por evolucionar y aprender, para poder estar a la altura de los retos que se nos presentan.

Desde que fundamos Elemento115, es una idea que también aplico en la empresa.

Nos dedicamos fundamentalmente al desarrollo de aplicaciones web B2B y eso, creedme, requiere una actualización, tensión competitiva y evolución constante.

En nuestro sector, la investigación y uno de sus frutos, la innovación, son inherentes al trabajo, y partes imprescindibles del mismo.

Básicamente, nos permiten, como empresa, conocer mejor al problema que nos enfrentamos, dotarnos de herramientas para resolverlo y mejorar el proceso para hacerlo más competitivo.

Resolver problemas que no se conocen en profundidad, con las mismas herramientas y método, volviendo a la Reina Roja, no solo nos limita como empresa, nos dejaría atrás en pocos meses.

 

Problemas y obstáculos

Sin embargo, dedicar el tiempo adecuado a la investigación es complicado, nos enfrentamos a dos obstáculos muy importantes: la inercia por permanecer en la zona de confort, y la necesidad de atender a tareas urgentes.

En las últimas retrospectivas, hemos ido tratando el problema, buscando un sistema para superar esos obstáculos, y eso nos ha conducido hasta aquí.

No os puedo decir que el camino hasta este post haya sido agradable o fácil, pero sí que ha merecido la pena, por que hemos aprendido y hemos llegado.

I+D Tortilla – Buffer I+D+i

En la última retro, acordamos abordar el problema de una forma más sistemática, obligándonos a incorporarlo en nuestras rutinas, y compartiendo el proceso y los resultados.

Primero, somos gordos. Qué mejor que relacionarlo con la comida. Los viernes, haremos una pequeña parada para comer Tortilla de Patata, será el momento I+D Tortilla.

Durante una media hora o cuarenta y cinco minutos, tendremos una charla en la que abordaremos los siguientes temas:

  • Recopilación de tecnologías, herramientas, procesos, etc… que puedan merecer una investigación en profundidad.
  • Priorización de esa lista, para incorporar lo que nos parezca más interesante y relevante para el estudio, lo que se incorporará al «buffer» o planificación de investigaciones.
  • Repaso del estatus de las investigaciones en curso.
  • Presentación de las conclusiones, cuando toque, de una investigación concreta.

Para incorporar un tema al buffer de I+D+i, son necesarios definir, a día de hoy, los siguientes aspectos:

  • Objeto de la investigación, ya sea una técnica o tecnología, una herramienta, un proceso, etc.
  • Líder o responsable de llevarla a cabo.
  • Objetivos de la misma, qué hipótesis o preguntas debe responder.
  • Método, herramientas y personas que participarán.
  • Entregables que requiere y dónde queda documentado el proceso.
  • Fechas marco o fechas límite.

¿Y si no funciona?

Ya os contaré, muy pronto empezaremos a ver los resultados, o en todo caso, detectaremos que no funciona el método y tendremos que buscar otro.

La cuestión es seguir corriendo todo lo que podamos. =)

Recursos y referencias

Wikipedia: La hipótesis de la Reina Roja

Wikimedia: Alicia en el país de las maravillas

Youtube: La metáfora de la Reina Roja en la teoría evolutiva

 

Manuel Barroso Parejo.
Comandante de la misión Elemento115.
mbarroso@elemento115.es
@manubarpar