Model View ViewModel

En un mail reciente de MSDN apareció un artículo que toca un tema de diseño interesante.
Y es el patrón Model-ViewModel-Model, en el artículo se hace referencia a su implementación en WPF/Silverlight, sin embargo es un tema con el que seguramente muchos se topen al incursionar en Asp.Net Mvc, y en realidad es imposible de esquivar en cualquier implementación de MVC, ya sea en Asp.Net, WinForms, Ruby o Haskell.

ViewModels

Cuando trabajamos con un modelo MVC, especialmente si elegimos algún mecanismo de DataBinding entre M y V (y en un sentido amplio de la palabra consideremos los templates (como las vistas de Asp.Net Mvc) como un caso particular de DataBinding), resulta inmediato que cualquier aplicación que escape de lo elemental necesita algun tipo de transformación entre un Modelo y su Vista, ahi es donde llegan al rescate los ViewModels.

Para hacerlo menos abstracto, pongamos un ejemplo, imaginemos que nuestros amigos de Facebook® quieren construir la pagina de perfil de un usuario:

Perfil de Usuario

 supongamos también que utilizan MVC y construyen su "Model" de la siguiente forma:

Nota: el modelo real de Facebook® podría ser más complejo

La duda es como obtener los datos resaltados en amarillo en la captura de ejemplo

• Antigüedad del mensaje de estado ("lunes pasado").
• Ubicación ("Villa Devoto" en lugar de el GUID correspondiente)
• Amigos en común (con el usuario logueado actualmente)

Para esto podemos "envolver" estas entidades del modelo con otras más emparentadas a la vista que queremos construir:

Estas clases extienden a las anteriores con campos calculados, listas filtradas, consolidaciones, u otro tipo de transformaciones sobre el modelo original.
Para ilustrar ésta sería una versión (muy naive) de la nueva propiedad "CommonFriends" en UserVM:

public IList<UserVM> CommonFriends
        {
            get
            {
                return this.Friends
                    .Where(f => f.Friends
                      .Any(ff => ff.UserID == User.CurrentUserID))
                    .ToList();
            }
        }

Si usted ya estuvo agregando este tipo de campos calculados y transformaciones, y se sentía culpable por haber violado la prístina pureza de su modelo MVC

 siéntase liberado de la culpa!, esto ya tiene nombre y se llama ViewModel!

Separación Model-ViewModel-Model

Por supuesto en esto podemos imaginar un gradiente de creciente complejidad:

• Propiedades agregadas directamente a las entidades de nuestro modelo
• Algunas clases nuevas y propiedades agregadas a entidades que descienden de las de nuestro modelo
• Una capa de ViewModels que se interpone y separa completamente View de Model.

Volviendo un poco al principio, el artículo de MSDN trata sobre la última opción, implementada como assemblies separados para View, Model y ViewModel, en el que no existen referencias entre View y Model.

Véase este gráfico explicativo que tomé prestado de un artículo que resume muy bien el tema

Rápidamente puede verse el problema burocrático en que nos pone este enfoque, ya que implica tener para casi todas las clases del modelo, una equivalente en ViewModel, con wrappers para todas las propiedades visibles. Imagínense la flagrante violación al principio DRY que supone crear páginas y páginas de código como este:

public string Fullname
        {
            get
            {
                return InnerEntity.Fullname;
            }
            set
            {
                InnerEntity.Fullname = value;
            }
        }

Tiene que haber algo mejor!

Dynamic Proxies

Como dice la máxima "El mejor código es aquel que no se escribe", y el artículo al que hice referencia propone generar estos ViewModels como proxies dinámicos, implementar esos "gets" y "sets" automáticamente con el nuevo tipo dynamic en .Net 4.0, un poco de Reflection y unos atributos muy elegantes para declarar dependencias entre propiedades (ej: Edad <-depende de-> FechaDeNacimiento).

Existen también librerías muy famosas para la creación de proxies dinámicos (que funcionan con .Net 2.0), como por ejemplo las que son usadas en NHibernate (para crear proxies que soporten lazy loading):

• LinFu
• Castle Project

que hacen fácil agregarle a estos proxies interceptores en getters y setters (u otros métodos) que implementen notificación de cambios, logging, autorización y otras cosas por el estilo.

Y finalmente...KISS! es importante recordar que puede resultar más que suficiente con mantener las clases en el modelo accesibles a las vistas, y las clases "ViewModel" mezcladas con el "Model", o separadas simplemente por namespace.

Sitecore, otra opción que ofrecer

Algunas semanas atrás, uno de nuestros clientes más importantes, nos invitó a participar junto con otros proveedores de un curso intensivo de una semana sobre Sitecore.
Sitecore es un CMS que proporciona software de gestión de contenidos web y portales a organizaciones que requieran funciones empresariales, integración y escalabilidad a la hora de administrar sitios web.

Sitecore fue desarrollado en Dinamarca, y tiene su mayor mercado actualmente en Estados Unidos y Europa. Nuestro cliente vio interesante, la posibilidad de que sus proveedores de mayor confianza, se puedan instruir en esta herramienta para que en el futuro los acompañen en la integración de Sitecore con otras aplicaciones, puedan agregar nuevas funcionalidades o colaboren en la implementación de la herramienta.

Como en Tercer Planeta estamos acostumbrados a realizar nuestros propios desarrollos, la primera reacción a la invitación fue “y no sé, ¿te parece que tengamos que aprender Sitecore?”, pero rápidamente comprendimos que la mejor respuesta a esa pregunta con un , “claro que sí”, y hoy en día vemos los beneficios de haber participado en ese encuentro.

Más allá que nuestro fuerte esté en los desarrollos a medida, siempre es enriquecedor poder conocer cómo otros pueden encarar una determinada solución. En este caso puntual, Sitecore nos pareció un producto muy completo, que tiene cubiertas muchísimas funcionalidades, muchas de las cuales todavía no pudimos explorar, pero en las que sí pudimos indagar descubrimos que están resueltas de manera muy diferente al enfoque que le hubiéramos dado nosotros, simplemente porque fue pensado por otras personas, en otro contexto, con otra experiencia y otras costumbres.

Con lo cual la posibilidad de poder salir, tomar distancia de nuestros tareas diarias, y ver cómo piensan otros, nos resultó más que interesante.

El curso fue dictado por Craig Nelson, un instructor técnico especializado en Sitecore, que viajo especialmente desde Estados Unidos. Cada día estaba orientado a diferentes perfiles (Usuarios Finales, Diseñadores, Desarrolladores, etc.), constaba de partes teóricas y prácticas, las cuales resolvíamos en grupos, esta interacción con otros colegas fue también una experiencia que valió la pena.

Este curso nos sirvió para conocer una nueva herramienta, y fundamentalmente para ver otra forma de hacer las cosas, e independientemente del uso que la vayamos a dar en el futuro, hoy en día, sentimos que tenemos una posibilidad más, otra opción que ofrecer, o tener en cuenta, y eso creo que es lo más importante, para nosotros y para nuestros clientes.

Cómo entendemos el crecimiento

Cuando en diciembre del 2009 nos reunimos con Jose a definir los objetivos del 2010 decidimos que teníamos que poner el foco en madurar.

Pero, qué significaba en ese momento “madurar” para nosotros ? Para el tamaño de organización que tenemos y por los lineamientos que seguimos, lo que buscábamos era lograr un crecimiento de la empresa pero no medido en este caso en cantidad de integrantes o en monto de facturación, sino en base al crecimiento profesional y desarrollo personal de todos los integrantes del equipo de Tercer Planeta.


Help, I need somebody!

Para quienes no somos especialistas en coaching y tenemos un perfil más técnico, el objetivo se presentaba como un gran desafío y sabíamos también que nos embarcábamos en un trabajo de largo plazo que implicaba grandes cambios individuales y en el grupo.

Estaba claro que para poder llevar a cabo esta tarea necesitábamos contactar a especialistas en el tema y fue así que acudimos a Pablo Fondevila y su empresa “Nuevas Miradas en Organizaciones”, quien junto con Carola Herrscher y Marisa Bergés se dedican al Coaching Ontológico . Con ellos empezamos a transitar este camino desde hace 6 meses.


Algunos caminos a seguir

Uno de los aspectos que comenzamos a abordar es tratar de lograr una convergencia entre la vida personal y la laboral ¿cómo pensar que con la cantidad de horas que compartimos en la oficina ambos entornos marchan cada uno por un “carril exclusivo” sin tocarse en ningún momento?
Es lógico entender que estas dos “vidas” se cruzan en varios puntos pero no nos resultaba tan lógico hacer visible y poner un esfuerzo claro y público en juntarlas y complementarlas.


Y para qué querríamos hacer esto? Una de las respuestas que encontramos a esta pregunta es que creemos que la realización de las personas debe ser algo integral, el desarrollo personal y profesional implica poder mostrar los logros, tomar nuevos compromisos, cerrar etapas, explorar nuevos caminos, descubrir y explotar nuestras habilidades.

Por otro lado, aceptar la influencia que las emociones tienen en nuestras vidas es fundamental para entender algunos comportamientos: por ejemplo, aclarar que estamos viviendo un momento difícil o que tenemos algo importante que resolver puede evitarnos conflictos de comunicación si encontramos un ámbito donde nos sintamos cómodos para declararlo y los demás entiendan el por qué de ciertas actitudes.

Entender cuán valioso es el esfuerzo de alguien por terminar una carrera o por emprender nuevos retos, por ejemplo, nos anima a fomentar ese tipo de logros, que sin duda, redundarán en valor para los objetivos de la empresa.

Cómo hacer entonces para acercar estos dos mundos y lograr que se retroalimenten ? O que el trabajo sea un medio más a través del cual alcanzar objetivos personales ?
Cómo hacer que la "vida de la oficina" no genere trabas en la vida privada ? O que la vida privada (logros, alegrías, tristezas) puedan ser, de alguna manera, compartidos, apoyados y comprendidos por la empresa?

Estas fueron algunas de las dudas que empezaron a surgir. Dudas que, gracias a las herramientas que nos van dando quienes nos acompañan (talleres, entrevistas individuales periódicas, consejos para la organización de eventos internos y externos, etc.), empezaron a disiparse.

Puede asombrarnos pensar que con pequeños cambios o con la creación de ámbitos de discusión de cosas simples y concretas, es absolutamente posible y realizable encarar el tema.

De la misma manera las charlas individuales para desarrollo personal nos están abriendo los ojos a nuevas posibilidades de solución de conflictos, de aprovechamiento de las capacidades de cada uno, de alineamiento con los objetivos y visión de la empresa, de comunicación, de roles, etc.


Esfuerzo vs. Beneficios

Según mi opinión, el mayor desafío en este emprendimiento está en saber incorporar y mantener estos valores. Lo cual implica un trabajo de replanteo individual, de delegación de tareas, de acompañamiento, de promoción de la creatividad, de generación de espacios de intercambio, entre otras cosas.

Creo que el entender que estos procesos implican pensar a largo plazo, esfuerzo y modificaciones en la mentalidad, en las costumbres, en las estructuras y en la mirada con que enfocamos las cosas, es una de las principales claves para obtener buenos resultados.

Ahora, sin dejar de lado un enfoque más “empresario”, qué beneficios veo en estos cambios en relación con la organización y la productividad ?

• Mayor compromiso de todos
• Mayor motivación
• Mejoramiento del ambiente laboral
• Mayor confianza entre los miembros del equipo
• Mejoras en la comunicación
• Hacer que los objetivos y la visión de la empresa sean sostenibles en el tiempo

Me animo a decir también que todo este “movimiento” trasciende los límites de la empresa y repercute en la relación con nuestros clientes, quienes, en definitiva, se benefician con los resultados que un equipo de trabajo motivado y “en sintonía” es capaz de producir.


Vale la pena?

Considero que para empresas como la nuestra, donde el capital humano es considerado uno de los puntos más importantes, la inversión en este tipo de emprendimientos está más que justificada y muestra sus frutos en muchas áreas.

Finalmente, creo que para “poner a rodar la maquinaria” en todo esto, el principal motor es ver y reconocer la importancia que tienen estas cuestiones en nuestra vida cotidiana, cualquiera sea el carril por el que marche.

¡Qué comience la sesión!

Resulta común que durante el almuerzo o en esos 5' que lleva batir el café o preparar el mate surjan temas o ideas interesantes que son para "discutir entre todos", o al menos entre muchos; y, por lo general, se hace difícil buscar y encontrar el tiempo necesario para hacerlo, por lo que esas ideas quedan sin transmitir ni impulsar.
Esto nos sucedió a nosotros, hemos de reconocerlo. Pero encontramos la solución y, como era lógico, la misma surgió en esos momentos de "recreo laboral".
La propuesta fue tener reuniones cortas para charlar y debatir acerca de diferentes temas. Así surgió nuestro "Cabildo Abierto", pensado como un espacio en el que se pudieran plantear problemas o inquietudes, discutir soluciones, propuestas o acciones a tomar y llegar a alguna conclusión con una solución rápidamente aplicable.

El nombre elegido no fue al azar, ya que combina el nombre de la Avenida en la cual está nuestra oficina con el llamado a debate mediante la participación activa y sin límites de cualquier integrante de Tercer Planeta (3P) que quiera hacerlo.

¿En qué consiste?
El término Cabildo Abierto no es nuevo, surge en la época del Virreinato del Río de La Plata en la cual algunos pobladores se reunían para tratar diversos temas.

Nuestro Cabildo Abierto consiste en hacer sesiones para debatir temas propuestos por los integrantes de 3P. Cada uno, al tener un tema a tratar, anota un título representativo en una Wiki. Fue designada la figura de moderador quién es el encargado de seleccionar 2 o 3 temas propuestos para debatir en la siguiente sesión, estos temas pueden estar conectados o no; la particularidad de ellos es que el debate no debería llevar mas de 1 hora.

Una vez seleccionados los temas, se proponen días y horarios (es deseable mas de 2 opciones para elegir) y cada interesado en participar se anota según su conveniencia. Aquel día-horario que tenga mas participantes será el día elegido para sesionar. Es fundamental que aquella persona que propuso el tema asista a la sesión ya que es la encargada de presentar el tema, impulsar el debate y anotar las conclusiones.

Al comenzar la sesión, se expone cada tema, se lo discute y, al dar cierre al debate, se anotan las conclusiones propuestas en la Wiki. En caso de requerir un seguimiento, la persona que propuso el tema tendrá la responsabilidad de hacerlo.

Anotando temas
Los temas a proponer pueden ser muy variados, ellos surgen de la motivación personal de mejorar algo que vemos y sentimos puede ser mejorado o revisado. Por supuesto dado que cada persona tiene al respecto una visión distinta, un enfoque distinto, esto es lo que enriquecerá la gama de tipos de temas propuestos.

Se pueden proponer temas que traten asuntos relacionados con la metodología de trabajo o con cuestiones técnicas del desarrollo. También pueden sumarse aquellas cuestiones que tienen que ver con la convivencia o el espacio físico en el que nos encontramos. En definitiva, vale anotar cualquier tema que cada uno quiera tratar en una sesión de Cabildo Abierto.

Nosotros, en particular, hemos presentado diversos temas. Algunos de ellos fueron:

• Cómo manejamos el Collate en SQLServer?
• Timeboxing (como afecta la calidad, como tenerlo en cuenta en la planificación, como prever y manejar imprevistos, etc)
• Equipar lo necesario para poder hacer reuniones remotas
• Cómo mejorar nuestra relación con el cliente?
• Cambiar las cortinas

por citar algunos títulos.

Conclusiones
Es importante saber que existe un epacio en el que se puede proponer y accionar esas propuestas. El Cabildo Abierto intenta ser eso precisamente: un espacio en el cual se planteen y canalicen las inquietudes de todos y se busquen las respuestas y soluciones en forma conjunta.

HTML5, un paso más cerca

Html5: Html para aplicaciones web

Desde hace mucho tiempo, oímos culpar de los problemas intrínsicos de las aplicaciones web, a la naturaleza “document-oriented” de la web. La web fue pensada originalmente como una red para compartir documentos “hipervinculados”, y no como plataforma de aplicaciones distribuídas. De hecho fue éste el argumento expuesto por Google en forma de historieta para lanzar Chrome.

Para subsanar esta brecha surgieron una gran variedad de tecnologías, como javascript, Java Applets, Ajax, Flash, y más recientemente Google Gears, Java FX y Silverlight con la intención de crear en los browsers lo que se conoce como Rich Clients, clientes que permitan una experiencia de usuario similar a la de una aplicación de escritorio, con todas la ventajas de la web.

Sin embargo en todo este tiempo, el “poder legislativo” de la web, la W3C, no se quedó de brazos cruzados, y como es de esperar, respondieron con un estándar, tomándose su tiempo. La respuesta de la W3C fue: HTML5

HTML5 traerá muchas novedades, pero lo importante, la idea que está detrás de la mayoría de ellas, es la creación de aplicaciones web “ricas” en nuestros browsers. Para muestra basta un botón:

• Graficos vectoriales, animaciones y efectos visuales más avanzados
• Almacenamiento local en el browser, no sólo como diccionarios, también en forma de bases de datos SQL, y otras facilidades para aplicaciones “offline/online”
• WebWorkers, tareas asincrónicas, y un sistema de mensajería entre ellas.
• Navegación Ajax
• Streaming de audio y video
• DOM Events, los elementos de un documento html, expondrán una serie eventos (ej: div.resize)
• Drag & Drop
• Tags semánticos asociados a aplicaciones como: <progress>, <meter>, <command>, <datalist>, <output>, y nuevos tipos de campos para formularios (<input>) como “datetime”, “range”, “search”, etc.
• varios etc.

A esta altura, resulta evidente que tener soporte para todo esto, de forma nativa en HTML, se ve como una amenaza para todos los que proveen estos features actualmente mediante plugins, como Flash, Java FX, Silverlight y otros.

HTML5 todavía está en pañales, y se acerca lentamente, sin embargo la mayoría de los browsers ya soportan varios features de HTML5.

IE9, Podría Microsoft estar suicidando Silverlight?

Con la salida de IE8, Microsoft empezó a soportar algunos features de HTML5, sin embargo este era muy limitado, y con la ausencia del elemento <canvas> que permite la inclusión de gráficos vectoriales, se especuló sobre una estratégica defensa de Silverlight.

Sin embargo, con la llegada de IE9 están anunciando un soporte para HTML5 mucho más completo, tanto que publicaron una pagina para probar entre otras cosas el soporte HTML5 de IE9 (incluyendo animaciones y gráficos vectoriales con aceleración por hardware).

Y a esto se suma un nuevo engine Javascript, que pretende ponerse a tiro con el resto con benchmarkings prometedores. Esto me recuerda un comentario sobre el futuro de Javascript de Martín Salías.

Para los que trabajamos con .Net surgen ahora dudas existenciales sobre como afectará esto el futuro de Silverlight.

Sin duda la familiaridad del framework .Net, C#, y la integración con VisualStudio son la panacea para los desarrolladores que ya trabajamos con .Net, sin embargo, ¿Qué features realmente distintivos tendrá Silverlight para los usuarios?

Gráficos 3D, Out-of-browser y Smooth Streaming?

Quizás todavía sea solo futurología, pero la llegada de IE9 nos acerca bastante a la pregunta:

¿Cuál será el lugar que ocupará Silverlight (y otras RIU) con la llegada de HTML5?.

Profecía autocumplida: Google + Apple + Microsoft

Ya no hace falta decirlo, a esta altura, HTML5 será un caso evidente de profecía autocumplida, no sólo por tratarse de un estándar de la W3C, sino por contar con el apoyo de Google (además de incluir soporte en Chrome, decidió abandonar Google Gears, por considerarlo un subset de lo que HTML5 proveerá y creo una versión HTML5 de YouTube), Apple (soporte en Safari, que incluirá IPhones que actualmente no soportan Flash), y finalmente Microsoft con la llegada IE9.

Falta aún saber cuanto falta para que sea soportado completamente por los browsers más populares, y para que nuestras IDEs nos permitan aprovecharlo.

¿Y si jugamos a que hacemos software?

Desde hace un tiempo, estoy dando una mirada de vez en cuando a una revista online sobre metodologías ágiles en portugués. Visão Ágil, como tarea hogareña del curso portugués que estoy haciendo, y con la intención de leer un poco sobre este tema (como dice la poco ecológica metáfora: matar dos pájaros de un tiro).

La técnica del Tomate

En el blog de esta revista encontré recientemente un artículo sobre la “Técnica Pomodoro” de Manoel Pimentel. La Técnica Pomodoro se utiliza para la administración personal del tiempo, y está inspirada en ideas de las metodologías ágiles, como TimeBoxing y el uso de herramientas de “baja tecnología”, puntualmente: papel, lápiz y un timer de cocina.

Estos timers con forma de tomate (pomodoro en italiano) son los que dan nombre a la técnica

Si bien ese artículo tiene un mindmap que resume muy bien los puntos clave, lo que más destacaría es la simplicidad, el énfasis en mantener el foco, y la asignación rígida de tiempos (véase TimeBoxing) tanto a las tareas como a los intervalos de descanso entre éstas.

Con respecto a este último punto, el libro oficial que puede descargarse de http://www.pomodorotechnique.com destaca la importancia de estos intervalos para “asimilar lo aprendido y hacer algo bueno por tu salud”, como caminar, ejercicios de respiración o contar un chiste. Interrumpir este período de descanso con cualquier tarea que implique un esfuerzo mental, “bloqueara el constructivo proceso mental de integración necesario para estar alerta y listo para el proximo ciclo”. Una especie de build de integración que se ejecuta periódicamente en background en nuestro cerebro.

El último que se escondió arma el release!

Sin embargo lo que quería mencionar en este artículo (y por eso el título), es algo que me parece muy valioso y puede pasar desapercibido a primera vista. Es el espíritu lúdico que hay detrás de esta técnica (vi este punto escrito en el mindmap del artículo de Pimentel).

Una idea que tambien está implícita en varias técnicas utilizadas en metodologías ágiles.

Creo que en esta manera de encarar el trabajo (y cualquier otra cosa) hay mucho más jugo de lo que se cree habitualmente. Especialmente en ambientes que promueven la productividad y la creatividad.

No hay que confundirlo con una forma de hacer apología de la competencia (que casi nunca es sana), o de esquivar el bulto a las tareas tediosas. Se trata más bien de evitar que nuestro trabajo sea una letárgica marcha atrás de la recompensa monetaria de fin de mes (Dispositivo del burro y la zanahoria),

para empezar a disfrutar del día a día, transformándolo en un juego constructivo, hasta casi “sentir que no trabajamos”.

Sin duda el tema, da para mucho más que este artículo (y para autores más calificados!) pero la intención era traer a colación el tema, y tratar de poner en evidencia, o preguntar, ¿Cuántas cosas hacemos (o podemos hacer) en este sentido?

"La columna del medio"

Aportando dinámica a la pizarra

En nuestro equipo de trabajo contamos con los ambientes de desarrollo (pruebas de unidad) y de QA (pruebas de integración).

Desde hace tiempo venimos aplicando prácticas de SCRUM. Con el uso de la pizarra notamos la necesidad de diferenciar las tareas cuyo desarrollo se encontraba en progreso de aquellas terminadas y a la espera de un pasaje al ambiente de QA.

Esto era debido a que cada vez que terminábamos una tarea la pasábamos a la columna de “Test”, ocasionando muchas veces confusiones ya que no teníamos manera de saber si las tareas que se encontraban en esta columna estaban contempladas dentro del último build.

Durante un tiempo intentamos hacer el pasaje de papelitos solamente cuando hacíamos el build al ambiente QA, pero para eso contábamos con nuestra memoria para saber que tareas estaban completas, lo que no siempre resultaba con éxito por que… seamos sinceros… esta no siempre nos era fiel =)

Entonces un día, durante la retrospectiva de uno de nuestros proyectos tuvimos la siguiente maravillosa idea para arribar a una solución:

Agregar una columna intermedia entre DESA (In progress) y QA (Test) que nos permitiera saber, de forma inmediata, cuáles eran las tareas que estaban listas pero que todavía no estaban disponibles para ser probadas en QA…

¿Como funciona?

Cada vez que el desarrollador termina alguna tarea, mueve el papelito correspondiente de “In Progress” a la columna “DESA/TEST”(la columna del medio) indicando de esta manera que el desarrollo ha finalizado y estará disponible en el próximo build para su prueba.

Si bien debo reconocer que en un principio tuve mis dudas acerca de si la nueva columna iba a servir de algo, el uso de la misma nos demostró gran efectividad.

Su implementación acarreó las siguientes mejoras:

• Nos permitió tener una noción más precisa del avance del sprint, rompiendo con la sensación de un “avance estático” generado por la acumulación de tareas en la columna de desarrollo.
• Da una idea más clara al desarrollador de qué tareas le falta completar y cuáles completó.
• Brinda al tester la certeza de saber qué estará para probar.
• Es mucho más fácil decidir en qué momento hacer un pasaje de ambiente.

Resultado final

 

Conclusiones

Por nuestra experiencia, la incorporación de esta nueva columna trae grandes beneficios a la dinámica del equipo, agilizando la comunicación. Los invitamos a probar esta alternativa y que compartan con nosotros sus experiencias.