Enable javascript in your browser for better experience. Need to know to enable it? Go here.

Técnicas

Adoptar ?

  • Para medir el rendimiento de la entrega de software, cada vez más organizaciones recurren por defecto a las cuatro métricas clave definidas por el programa DORA research: tiempo de espera de los cambios, frecuencia de despliegue, tiempo medio de restauración (MTTR) y porcentaje de fallos en los cambios. Esta investigación y su análisis estadístico han demostrado una clara relación entre el alto rendimiento de la entrega y estas métricas; proporcionan un gran indicador de cómo lo está haciendo una organización de entrega en su conjunto.

    Seguimos siendo grandes defensores de estas métricas, pero también hemos aprendido algunas lecciones. Seguimos observando enfoques erróneos con herramientas que ayudan a los equipos a medir estas métricas basándose únicamente en sus conductos de entrega continua (CD). En particular, cuando se trata de las métricas de estabilidad (MTTR y porcentaje de cambios fallidos), los datos del pipeline de CD por sí solos no proporcionan suficiente información para determinar qué es un fallo de despliegue con impacto real en el usuario. Las métricas de estabilidad sólo tienen sentido si incluyen datos sobre incidentes reales que degraden el servicio para los usuarios.

    Recomendamos tener siempre presente la intención última de una medición y utilizarla para reflexionar y aprender. Por ejemplo, antes de dedicar semanas a la creación de sofisticadas herramientas de cuadros de mando, considera la posibilidad de limitarse a realizar regularmente la comprobación rápida del DORA en las retrospectivas del equipo. Esto da al equipo la oportunidad de reflexionar sobre qué capacidades podrían trabajar para mejorar sus métricas, lo que puede ser mucho más eficaz que la creación de herramientas demasiado detalladas. Hay que tener en cuenta que estas cuatro métricas clave se originaron a partir de la investigación a nivel de organización de los equipos de alto rendimiento, y el uso de estas métricas a nivel de equipo debe ser una forma de reflexionar sobre sus propios comportamientos, no sólo otro conjunto de métricas para añadir al cuadro de mando.

  • Un single team remote wall es una técnica sencilla para reintroducir virtualmente el muro del equipo. Recomendamos que los equipos distribuidos adopten este enfoque; una de las cosas que escuchamos de los equipos que empezaron a trabajar en remoto es que echan de menos tener el muro físico del equipo. Este era un espacio único donde se podían mostrar todas las tarjetas de historias de usuario, tareas, su estado y progreso, actuando como punto de información y centro de referencia para el equipo. El muro actuó como un punto de integración con los datos reales almacenados en diferentes sistemas. A medida que los equipos se volvieron remotos, tuvieron que acudir de nuevo a los distintos sistemas para buscar la información, por lo que obtener una “visión general” de un proyecto se ha vuelto muy complicado. Si bien puede haber algo de esfuerzo extra para mantenerlo actualizado, creemos que los beneficios para el equipo valen la pena. Para algunos equipos, actualizar el muro físico formaba parte de las "ceremonias" diarias que el equipo hacía en conjunto, y lo mismo se puede hacer con un muro remoto.

Probar ?

  • La malla de datos Data mesh es un enfoque organizativo y técnico descentralizado a la hora de compartir, acceder y gestionar los datos para la analítica y el ML. Su objetivo es crear un enfoque sociotécnico que amplíe la obtención de valor de los datos a medida que crezca la complejidad de la organización y proliferen los casos de uso de los datos y se diversifiquen las fuentes de los mismos. Esencialmente, crea un modelo de intercambio de datos responsable que está en consonancia con el crecimiento de la organización y el cambio continuo. Según nuestra experiencia, el interés por la aplicación de la malla de datos ha crecido enormemente. Este enfoque ha inspirado a muchas organizaciones a adoptarlo y a los proveedores de tecnología a readaptar sus tecnologías existentes para una implantación de malla. A pesar del gran interés y la creciente experiencia en la malla de datos, sus implantaciones se enfrentan a un elevado coste de integración. Además, su adopción sigue limitada a secciones de grandes organizaciones y los proveedores de tecnología están distrayendo a las organizaciones de los aspectos socio más duros de la malla de datos: la propiedad descentralizada de los datos y un modelo operativo de gobierno federado.

    Estas ideas se exploran en Data Mesh, Delivering Data-Driven Value at Scale, que guía a los profesionales, arquitectos, líderes técnicos y responsables de la toma de decisiones en su transición desde una arquitectura tradicional de big data a la malla de datos. Proporciona una introducción completa a los principios de la malla de datos y sus componentes; cubre cómo diseñar una arquitectura de malla de datos, guiar y ejecutar una estrategia de malla de datos y navegar por el diseño organizativo hacia un modelo de propiedad de datos descentralizado. El objetivo del libro es crear un nuevo marco para profundizar en las conversaciones y conducir a la siguiente fase de madurez de la malla de datos.

  • En una organización que practica el principio “lo construyes, lo ejecutas”, una definición de listo para producción (DPR, por sus siglas en inglés), es una técnica útil para ayudar a los equipos a evaluar y preparar la disponibilidad operacional de nuevos servicios. Implementada como una lista de puntos o una plantilla, un DPR da a los equipos una guía sobre qué tener en cuenta y en qué pensar antes de llevar un nuevo servicio a producción. Aunque los DRP no definen objetivos de servicio específicos (SLOs, por sus siglas en inglés) a cumplir (esto pueden ser difíciles de definir de forma general), recuerdan a los equipos en qué categoría de SLOs pensar, qué estándares organizacionales cumplir, y qué documentación es necesaria. Los DRP, nos dan una fuente de información que los equipos convierten en los requerimientos de producto específicos, por ejemplo: observabilidad y fiabilidad, para incluir en sus backlog de producto.

    Los DPR están íntimamente relacionados con el concepto propuesto por Google en production readiness review (PRR). En organizaciones demasiado pequeñas como para tener un equipo de ingeniería de fiabilidad (SRE, por sus siglas en inglés), o preocupadas porque un proceso de panel de revisión pueda impactar el flujo de salida a producción de un equipo, tener un DPR puede al menos ofrecer una guía documentada de criterios acordados a nivel de organización. Para nuevos servicios de alta criticidad, se puede añadir un mayor nivel de escrutinio en cunplimiento de DPR mediante un PRR.

  • Escribir buena documentación es un aspecto que se pasa por alto en el desarrollo de software y que suele dejarse para el último momento y se realiza de manera desordenada. Algunos de nuestros equipos han encontrado en los cuadrantes de documentación una manera práctica de garantizar que se produzcan los artefactos correctos. Esta técnica clasifica los artefactos sobre dos ejes: El primer eje está relacionado con la naturaleza de la información, práctica o teórica; el segundo eje describe el contexto en el que el artefacto es usado, estudiado o trabajado. Esta técnica define cuatro cuadrantes en los cuales artefactos como tutoriales, guías prácticas o páginas de referencia pueden ser clasificadas y entendidas. Este sistema de clasificación no solo asegura que artefactos críticos no sean pasados por alto sino que también guía la presentación del contenido. Hemos encontrado esto particularmente útil a la hora de crear documentación de onboarding que facilita la rápida puesta al día de nuevos desarrolladores cuando se unen a un nuevo equipo.

  • El término standup tiene su origen en la idea de ponerse de pie durante esta reunión de sincronización diaria, con el objetivo de hacerla breve. Se trata de un principio común que muchos equipos intentan cumplir en sus reuniones diarias: que sean breves y directas. Pero ahora estamos viendo que los equipos desafían ese principio y están “repensando las reuniones diarias remotas”. Cuando se está en un mismo lugar, hay muchas oportunidades durante el resto del día para sincronizarnos entre nosotros de forma espontánea, como complemento a la breve reunión diaria. De forma remota, algunos de nuestros equipos están experimentando un formato de reuniones más largas, similar a lo que la gente de Honeycomb llama "sincronización de equipo serpenteante.”

    No se trata de deshacerse por completo de una sincronización diaria; todavía lo encontramos muy importante y valioso, especialmente en un formato remoto. En cambio, se trata de extender el tiempo bloqueado en los calendarios de todos para la sincronización diaria hasta en una hora, y usarlo de una manera que haga obsoletas algunas de las otras reuniones y acerque al equipo. En las actividades aún se puede incluir el bien probado recorrido por el tablero del equipo, para luego ampliarlo con discusiones de aclaración más detalladas, decisiones rápidas y tomarse el tiempo para socializar. La técnica se considera exitosa si se reduce la carga general de la reunión y mejora la unión del equipo.

  • Al armar un nuevo volumen del Radar, a menudo nos invade una sensación de déjà vu, y la técnica de server-driven UI genera un caso particularmente sólido con la llegada de los frameworks que permiten a los desarrolladores de aplicaciones móviles tomar ventaja de los ciclos de cambio más rápidos mientras que no se falle en las políticas de las tiendas de apps en torno a la revalidación de la propia aplicación móvil. Lo hemos comentado antes desde la perspectiva de permitir el desarrollo móvil para escalar a través de los equipos. La interfaz de usuario basada en servidor separa la representación en un contenedor genérico en la aplicación móvil mientras que la estructura y la data para cada vista es provista por el servidor. Esto significa que los cambios que alguna vez requirieron un viaje de ida y vuelta a una tienda de apps pueden ahora ser logrados a través de cambios simples en las respuestas que envía el servidor. Nota, no estamos recomendando este acercamiento para todos los desarrollos de interfaz de usuario, de hecho hemos experimentado algunos problemas terribles y demasiado configurados, pero con el respaldo de gigantes como AirBnB y Lyft, sospechamos que no solo nosotros en Thoughtworks nos cansamos de hacer todo del lado del cliente. Mire este espacio.

  • Con la continua presión de mantener los sistemas seguros y sin reducción en el panorama general de amenazas, un machine-readable Software Bill of Materials (SBOM) puede ayudar a los equipos a estar al tanto de los problemas de seguridad de las librerías en las que confían. El más reciente, el día cero del exploit remoto Log4Shell fue critico y ampliamente conocido. Si los equipos hubieran tenido un SBOM listo, este hubiera escaneado y corregido rápidamente el mismo. Ahora hemos tenido experiencia en ambientes de producción usando SBOMs en proyectos que se encuentran tanto en compañías pequeñas como en grandes multinacionales, hasta en departamentos de gobierno, y estamos convencidos que proveen beneficios. Herramientas como Syft hacen fácil el uso de SBOM para detectar vulnerabilidades.

  • Bifucarción táctica es una técnica que puede ayudar con la reestructuración o migración de monolitos a microservicios. Específicamente, esta técnica ofrece una posible alternativa al enfoque más común de primero modularizar completamente el código, que en muchas circunstancias puede tomar mucho tiempo o ser muy difícil de alcanzar. Con la bifurcación táctica un equipo puede crear una nueva bifurcación del código y usarla para tratar y extraer un área o problema en particular mientras se elimina el código innecesario. El uso de ésta técnica probablemente sólo sería parte de un plan a largo plazo para el monolito en general.

  • La arquitectura de los sistemas imita la estructura de la organización y su comunicación. No es novedad que las interacciones de equipo deben ser deliberadas. Ver, por ejemplo, la maniobra inversa de Conway (Inverse Conway Maneuver). La interacción del equipo es una de las variables de la rapidez y facilidad con la que los equipos pueden entregar valor a sus clientes. Estuvimos felices de encontrar una manera de medir estas interacciones, usamos la evaluación del autor de Topologías de Equipo, que te ayuda a comprender qué tan fácil o difícil les resulta a los equipos desarrollar, testear y mantener sus servicios. Midiendo la carga cognitiva del equipo, pudimos aconsejar mejor a nuestros clientes sobre cómo cambiar la estructura de sus equipos y fomentar sus interacciones.

  • Una arquitectura de transición es una práctica útil utilizada para el reemplazo de los sistemas heredados. Al igual que los andamios pueden construirse, reconfigurarse y finalmente retirarse durante la construcción o renovación de un edificio, pasos arquitectónicos provisionales durante el desplazamiento de lo heredado. Las arquitecturas de transición se eliminarán o sustituirán más adelante, pero no son un trabajo desechable, dado el importante rol que desempeñan en la reducción del riesgo y en permitir que un problema difícil se divida en pasos más pequeños. Por tanto, ayudan a evitar la trampa de caer en un enfoque de reemplazo heredado “big bang”, porque no se puede hacer que los pasos intermedios más pequeños se alineen con una visión arquitectónica final. Hay que tener cuidado para asegurarse de que el "andamiaje" arquitectónico se elimine finalmente, para que no se convierta en una deuda técnica más adelante.

Evaluar ?

  • ¿Cómo te planteas la escritura de un buen código? ¿Cómo puedes juzgar si has escrito código de calidad? Como desarrolladores de aplicaciones, siempre estamos buscando reglas, principios y patrones que podamos utilizar para compartir un lenguaje y unos valores a la hora de escribir código simple y fácil de modificar.

    Daniel Terhorst-North ha hecho recientemente un nuevo intento para crear una lista de control para un buen código. Sostiene que, en lugar de ceñirse a un conjunto de reglas como SOLID, es más aplicable el uso de un conjunto de propiedades a las que aspirar. Ha ideado lo que llama las propiedades CUPID para describir lo que debemos hacer para conseguir un código "alegre": el código debe ser componible, seguir la filosofía Unix y ser predecible, idiomático y basado en el dominio.

  • Recomendamos a las organizaciones a evaluar diseño inclusivo como manera de asegurar que la accesibilidad es considerada un requisito de primer nivel. Muy habitualmente los requisitos de accesibilidad e inclusividad son ignorados hasta justo antes, o incluso después, del lanzamiento de software. La forma más barata y simple de incluir estos requisitos, a la vez que damos feedback pronto a los equipos, es integrándolos completamente en el proceso de desarrollo. En el pasado, hemos mencionado técnicas que priorizan los requisitos de seguridad y multifuncionales; una perspectiva de esta técnica es que consigue lo mismo para accesibilidad.

  • Continuamos viendo un incremento en el uso del patrón de Operador de Kubernetes con propósitos más allá de administrar aplicaciones desplegadas en el clúster. Usando el patrón de operador para recursos no agrupados se aprovechan las definiciones de recurso personalizado y el mecanismo de programación guiado por eventos implementados en el panel de control de Kubernetes para gestionar las actividades que están relacionadas fuera del cluster. Esta técnica se basa en la idea de Kube-managed cloud services y la extiende a otras actividades, como despliegue continuo o reacción a cambios en repositorios externos. Una de las ventajas de ésta técnica por encima de una herramienta especialmente diseñada, es que abre una amplia gama de herramientas que ya vienen incluidas en Kubernetes o son parte de un ecosistema más amplio. Puedes usar comandos como diff, dry-run o apply para interactuar con los recursos personalizados del operador. El mecanismo de programación de Kube hace que el desarrollo sea más fácil al eliminar la necesidad de orquestar actividades en el orden correcto. Herramientas de código abierto como Crossplane, Flux y Argo CD aprovechan ésta técnica, y esperamos ver más de estas surgir con el tiempo. Aunque éstas herramientas tienen sus casos de uso, también estamos comenzando a ver un mal uso y abuso de ésta técnica y necesitamos repetir un viejo consejo: Sólo porque puedas hacer algo con una herramienta no significa que debas. Asegúrate de descartar enfoques más sencillos y convencionales antes de crear una definición de recurso personalizada y asumir la complejidad que este enfoque implica.

  • Malla de servicios suele implementarse como un proxy inverso, también conocido como sidecar, desplegado a la par de cada instancia de servicio. Aunque estos procesos de sidecar suelen ser ligeros, el coste general y la complejidad a la hora de adoptar una malla de servicios se incrementa con cada nueva instancia de servicio que requiere un sidecar adicional. Sin embargo, con los avances en eBPF, estamos observando un nuevo enfoque de malla de servicios sin sidecar donde las funcionalidades de la malla son transferidas de forma segura al núcleo del SO, habilitando a los servicios que se ejecutan en el mismo nodo a comunicarse de forma transparente a través de sockets, sin necesidad de proxies adicionales. Puedes probar esto con Cilium service mesh y simplificar el despliegue pasando de un proxy por servicio a un proxy por nodo. Estamos intrigados por las capacidades de eBPF y por eso nos parece importante evaluar está evolución de la malla de servicios.

  • A medida que el software continúa aumentando en complejidad, el vector de ataque a través de dependencias de software se convierte en algo cada vez más difícil contra lo que protegerse. La reciente vulnerabilidad de Log4J nos mostró cómo de difícil puede ser incluso conocer esas dependencias — muchas compañías que no usaban Log4J directamente fueron vulnerables sin saberlo solo por el hecho de que otro software en su ecosistema dependía de esta librería. Supply chain Levels for Software Artifacts, o SLSA (pronunciado "salsa"), es un conjunto de guías curadas por un consorcio para que las organizaciones se protejan de ataques contra la cadena de suministro, ha sido evolucionado a partir de las guías internas que Google ha estado usando por años. Apreciamos que SLSA no promete una “bala de plata” con un enfoque centrado en herramientas para proteger la cadena de suministro, sino que proporciona una lista de amenazas concretas y prácticas junto con un modelo de madurez. El modelo de amenazas es fácil de entender ya que cuenta con ejemplos reales de ataques, y los requisitos proveen una guía para ayudar a las organizaciones a priorizar acciones basadas en niveles incrementales de robustez para mejorar su postura de seguridad en la cadena de suministro. Creemos que SLSA provee consejos aplicables y esperamos que más organizaciones aprendan de ello.

  • La necesidad de responder rápidamente a los conocimientos de los clientes ha impulsado la creciente adopción de arquitecturas basadas en eventos y el procesamiento de flujos. Marcos como Spark, Flink o Kafka Streams ofrecen un paradigma en el que consumidores y productores de eventos simples pueden cooperar en redes complejas para ofrecer información en tiempo real. Pero este estilo de programación requiere tiempo y esfuerzo para dominarlo y, cuando se implementa como aplicaciones de un solo punto, carece de interoperabilidad. Hacer que el procesamiento de flujos funcione universalmente a gran escala puede requerir una importante inversión en ingeniería. Ahora, está surgiendo una nueva cosecha de herramientas que ofrece las ventajas del procesamiento de flujos a un grupo más amplio y establecido de desarrolladores que se sienten cómodos utilizando SQL para implementar los análisis. La estandarización de SQL como lenguaje de flujo universal reduce la barrera para la implementación de aplicaciones de flujo de datos. Herramientas como ksqlDB y Materialize ayudan a transformar estas aplicaciones separadas en plataformas unificadas. En conjunto, una colección de aplicaciones de streaming basadas en SQL en toda una empresa podría constituir un almacén de datos de streaming.

  • Hasta hace poco, la ejecución de un modelo de machine-learning (ML) se consideraba costosa desde el punto de vista computacional y, en algunos casos, requería un hardware de propósito especial. Si bien la creación de los modelos todavía entra dentro de esta clasificación, es posible crearlos de forma que puedan ejecutarse en dispositivos pequeños, de bajo coste y bajo consumo de energía. Esta técnica, denominada TinyML, ha abierto la posibilidad de ejecutar modelos de ML en situaciones que muchos podrían considerar inviables. Por ejemplo, en dispositivos que funcionan con baterías o en entornos desconectados con una conectividad limitada o irregular, el modelo puede ejecutarse localmente sin un coste prohibitivo. Si te has planteado utilizar el ML pero has creído que no era realista debido a las limitaciones informáticas o de red, merece la pena evaluar esta técnica.

Resistir ?

  • Para las organizaciones que utilizan Azure como su principal proveedor de servicios cloud, Azure Data Factory es actualmente la herramienta predeterminada en cuanto a la orquestación de pipelines de procesamiento de datos. Es compatible con la ingesta de datos, copiando datos desde y hacia diferentes tipos de almacenamientos locales o en Azure y ejecutando lógica de transformación. Aunque sí que hemos tenido una experiencia adecuada con Azure Data Factory en migraciones sencillas de almacenamientos de datos desde local a la nube, no recomendamos el uso de Azure Data Factory para orquestación de pipelines complejas de procesamiento de datos y flujos de trabajo. Hemos tenido algún éxito con Azure Data Factory cuando lo hemos usado principalmente para mover datos entre sistemas. Para los pipelines de datos más complejos, todavía tiene sus retos, incluyendo una depuración mediocre y el informe de errores. Adicionalmente, la observabilidad es limitada, ya que la capacidad de registro de Azure Data Factory no se integra con otros productos como Azure Data Lake Storage o Databricks, lo que hace que sea complicado conseguir observabilidad extremo a extremo. Adicionalmente, la disponibilidad de los mecanismos de data source-triggering (desencadenamiento de fuente de datos) está limitada a ciertas regiones. En estos momentos, animamos a usar otras herramientas de código libre para la orquestación (e.g., Airflow para las pipelines de datos complejas y limitar el uso de Azure Data Factory para la copia de datos o la toma de instantáneas. Nuestros equipos siguen utilizando Data Factory para mover y extraer datos, pero para operaciones más amplias recomendamos otras herramientas con un flujo de trabajo más completo.

  • Anteriormente, habíamos presentado los equipos de productos de ingeniería de plataformas en Adoptar, como una buena manera de operar para los equipos de plataformas internos, que permite a los equipos de entrega implementar y operar sistemas en menos tiempo y con herramientas más sencillas. Desafortunadamente, estamos viendo la etiqueta de “equipo de plataformas” aplicada a equipos dedicados a proyectos que no tienen resultados claros o un conjunto de clientes bien definido. Como consecuencia, estos equipos de plataformas misceláneas , como los llamamos, tienen dificultades para entregar debido a las altas cargas cognitivas y a la falta de una alineación clara de prioridades, ya que están lidiando con una colección miscelánea de sistemas que no tienen relación entre sí. De hecho, se convierten en otro equipo de apoyo general para las cosas que no encajan, o que no quieren en otros lados. Seguimos creyendo que los equipos de productos de ingeniería de plataformas centrados en un producto (interno) claro y bien definido ofrecen una mejor serie de resultados.

  • Seguimos viendo a los datos de producción en entornos de prueba como un área de preocupación. En primer lugar, muchos casos de esto han resultado en un daño considerable, por ejemplo, cuando se ha enviado una alerta incorrecta desde un sistema de prueba a toda una población de clientes. En segundo lugar, el nivel de seguridad, específicamente en torno a la protección de datos privados, tiende a ser menor para los sistemas de prueba. No tiene mucho sentido tener controles elaborados sobre el acceso a los datos de producción si esos datos son copiados a una base de datos de prueba a la que pueden acceder las personas desarrolladoras y QAs. Aunque es posible ofuscar la información, esto tiende a aplicarse sólo a campos específicos, tal como números de tarjetas de crédito. Por último, copiar datos de producción a sistemas de prueba puede infringir las leyes de privacidad, por ejemplo, cuando los sistemas de prueba se alojan o son accedidos desde un país o región diferente. Este último escenario es especialmente problemático con despliegues complejos en la nube. Los datos falsos son un enfoque más seguro, y existen herramientas para ayudar en su creación. Reconocemos que hay razones para copiar elementos específicos de los datos de producción, por ejemplo, en la reproducción de una incidencia o para el entrenamiento de modelos ML específicos. Aquí nuestro consejo es proceder con precaución.

  • Generalmente evitamos poner blips en Espera cuando consideramos que la recomendación es demasiado obvia, lo que incluye seguir a ciegas un estilo más architectural sin poner atención a los trade-offs. Sin embargo, debido a la dominancia pura por parte de los equipos al elegir aplicaciones de una página (Single-Page Applications o SPA) cuando realmente lo que necesitan es una página web, nos preocupa hasta tal punto que nos sugiere que no están ni tan siquiera reconociendo SPAs como un estilo de arquitectura y, en vez de ello, se lanzan directamente a la elección de la infraestructura. SPAs generan una complejidad extra que no existe con las tradicionales páginas web (server-web based): herramientas de optimización, gestión y administración del historial de búsqueda, análisis web, tiempo de carga de la página principal, etc. Esta complejidad está generalmente justificada por temas relacionados con la experiencia de usuario, y tanto es así, que se continúan desarrollando herramientas para poder abordar con mayor facilidad estas preocupaciones (aunque la agitación en la comunidad de React en torno a la gestión de estado nos da una pista de lo difícil que puede ser el obtener una solución de aplicabilidad general).

    Sin embargo, muy a menudo nos encontramos con equipos que no realizan análisis de trade-off, sino que aceptan a ciegas esa complejidad extra de “SPA por defecto” incluso cuando las necesidades de negocio no la justifican. De hecho, hemos empezado a notar que muchos desarrolladores “novatos” ni siquiera son conscientes de un método alternativo a SPA, pues han pasado la mayoría de su carrera trabajando con infraestructuras similares a React. Creemos que muchas páginas web se beneficirarán de la simplicidad de la lógica de servidor server-side, y nos apoyamos en técnicas como Hotwire que ayudan a acortar ese brecha en la experiencia de usuario.

 
  • techniques quadrant with radar rings Adoptar Probar Evaluar Resistir Adoptar Probar Evaluar Resistir
  • Nuevo
  • Modificado
  • Ningún cambio

¿No encontraste algo que esperabas ver?

Cada edición del Radar presenta noticias que reflejan lo que hemos encontrado durante los seis meses anteriores. Es posible que ya hayamos cubierto lo que buscas en un Radar anterior. A veces seleccionamos cosas simplemente porque hay demasiadas de las que hablar. También es posible que falte algún dato porque el Radar refleja nuestra experiencia, no se basa en un análisis exhaustivo del mercado.

 

¿No encontraste algo que esperabas ver?

Cada edición del Radar presenta noticias que reflejan lo que hemos encontrado durante los seis meses anteriores. Es posible que ya hayamos cubierto lo que buscas en un Radar anterior. A veces seleccionamos cosas simplemente porque hay demasiadas de las que hablar. También es posible que falte algún dato porque el Radar refleja nuestra experiencia, no se basa en un análisis exhaustivo del mercado.

 

Radar

Descarga el Radar Tecnológico Volumen 26

English | Español | Português | 中文

Radar

Mantente informado sobre Tecnología

 

Suscríbete ahora

Visita nuestro archivo y nuestros volúmenes previos