Preguntas frecuentes

El Radar recoge las experiencias y aprendizajes de los Thoughtworkers a partir del trabajo que realizan para nuestros clientes. Como resultado, abarca diferentes tecnologías, industrias y geografías. Como gran empresa de servicios al cliente, con una larga trayectoria en el desarrollo de software a medida, creemos que representa una muestra razonable, pero no pretendemos ser exhaustivos ni estudiar el mercado en general.

No publicamos el Radar para asegurarnos ingresos, ni aceptamos peticiones de proveedores para influir en lo que incluimos. Compartimos nuestras opiniones en la creencia de que ganar en tecnología no significa tener la respuesta correcta; significa ser abierto y reflexivo sobre las opciones en un ecosistema en rápida evolución.

El Radar está escrito por el Consejo Asesor Tecnológico (TAB) de Thoughtworks.

El TAB es un grupo de unos 20 tecnólogos de alto nivel de Thoughtworks que se reúnen dos veces al año en persona y dos veces por semana virtualmente. Su función principal es asesorar a Rachel Laycock, Directora de Tecnología de Thoughtworks. El TAB representa a una amplia gama de líderes tecnológicos de diferentes países, áreas de especialización y antigüedad.

Rachel Laycock (CTO) • Martin Fowler (Chief Scientist) • Bharani Subramaniam • Birgitta Böckeler • Bryan Oliver • Camilla Falconi Crispim • Chris Chakrit Riddhagni • Effy Elden • Erik Doernenburg • James Lewis • Ken Mugrage • Maya Ormaza • Mike Mason • Neal Ford • Ni Wang • Nimisha Asthagiri • Pawan Shah • Selvakumar Natesan • Shangqi Liu • Vanya Seth • Will Amaral

El Radar se dedica a rastrear tecnologías y técnicas, a las que nos referimos como blips. Organizamos los blips utilizando dos elementos de categorización: los cuadrantes y los anillos. Los cuadrantes representan los diferentes tipos de blips. Los anillos indican nuestra recomendación para utilizar esa tecnología o técnica.

Un blip es una tecnología o técnica que desempeña un papel en el desarrollo de software. Los blips son cosas que están "en movimiento", es decir, que su posición en el Radar está cambiando, lo que suele indicar que cada vez tenemos más confianza en ellos a medida que se mueven por los anillos.

Los cuadrantes son una categorización del tipo de blip:

• Técnicas. Incluyen elementos de un proceso de desarrollo de software, como el diseño de experiencias; y formas de estructurar el software, como los microservicios.

   

• Plataformas. Cosas sobre las que construimos software, como tecnologías móviles como Android, plataformas virtuales como la JVM, o tipos de plataformas genéricas como las nubes híbridas.

   

• Herramientas. Pueden ser componentes, como las bases de datos, herramientas de desarrollo de software, como los sistemas de control de versiones; o categorías más genéricas de herramientas, como la noción de persistencia políglota.

   

• Lenguajes y frameworks. Estos incluyen lenguajes de programación como Java y Python, pero hoy en día se centran principalmente en frameworks como Gradle, Jetpack y React.js.

   

No le damos mucha importancia a los cuadrantes: en realidad son una forma de dividir el Radar en áreas temáticas. No creemos que sea importante el cuadrante en el que se sitúe una mancha, a diferencia de los anillos, que generan mucho debate.

Nuestro radar tiene cuatro anillos, que describiremos empezando por el centro:

• El anillo "Adoptar" representa los elementos que creemos que deberías considerar seriamente utilizar. No decimos que debas utilizarlas en todos los proyectos; cualquier herramienta debe usarse sólo en un contexto apropiado. Sin embargo, pensamos que un blip en el anillo de Adopción representa algo que no hay duda de que está probado y maduro para su uso.

   

• El anillo de “Prueba” es para los blips que creemos que están listos para su uso, pero no tan probados como los del anillo de adopción. Por ello, pensamos que la mayoría de las organizaciones deberían utilizarlos a modo de prueba, para decidir si deben formar parte de su conjunto de herramientas. Hemos utilizado blips de prueba en producción, pero somos conscientes de que los lectores pueden ser más precavidos que nosotros.

   

• El anillo “Evaluar” son cosas que hay que mirar de cerca, pero no necesariamente probarlas todavía - a menos que pienses que serían un ajuste particularmente bueno para ti. Por lo general, los datos que aparecen en el anillo de evaluación son cosas que nos parecen interesantes y a las que vale la pena prestar atención.

   

• El anillo “Resistir” es para cosas con las que, aunque estén aceptadas en el sector, no hemos tenido una buena experiencia. Por lo tanto, las señalamos para advertirte de que también puedes tener problemas con ellas. A veces significa que pensamos que son irremediablemente defectuosas; o simplemente que están siendo mal utilizadas. Colocamos en el anillo de retención cosas que desearíamos que la industria no utilizara.

   

Tenemos algunas discusiones bastante apasionadas sobre en qué anillo debe ir un blip. En el transcurso de la creación del Radar, hemos aprendido algunas reglas prácticas que nos ayudan a clasificar las cosas en anillos.

Sólo podemos poner blips en el anillo de prueba cuando tenemos experiencia en el uso de ese blip para el software de producción. Esto significa que a veces vamos por detrás de la curva tecnológica, porque puede que nos guste el aspecto de una tecnología pero aún no hayamos convencido a un cliente para que la pruebe, y hasta que no lo hagamos, un blip no puede pasar a la fase de prueba.

En el anillo Adoptar, sólo incluimos elementos cuando pensamos que no utilizarlos en el contexto adecuado del proyecto sería una decisión poco acertada y potencialmente irresponsable.

Dado que muchos blips pueden estar en un par de cuadrantes diferentes, no nos preocupamos demasiado por el cuadrante en el que acaba un blip, y no prestamos atención a su posición angular dentro del cuadrante.

En cambio, sí que prestamos atención a la posición radial. Si colocamos un blip en el anillo de Prueba pero cerca del anillo de Adopción, significa que tenemos cada vez más confianza en su potencial.

• Ninguno de los miembros del TAB se ha topado con él.

• Algunos miembros del TAB lo han mirado pero no lo encuentran suficientemente interesante.

• Lo pusimos en nuestra lista inicial, pero tuvimos que reducir el número de anuncios para que cupieran en el Radar. Este tema fue una de las víctimas, es decir, nos pareció menos importante que los demás.

• Ya hemos hablado de ello en un Radar anterior, y no tenemos nada nuevo que decir al respecto ahora. Si un blip no se mueve, desaparece del Radar.

• Hicimos un blip más genérico, para hablar del concepto más amplio. Por ejemplo, en nuestra primera edición del Radar no hablamos de bases de datos NoSQL específicas, sino que mencionamos "bases de datos no relacionales". Más tarde, llamamos a los blips para bases de datos NoSQL específicas.

El Radar representa las tecnologías que están actualmente en nuestra mente. Dada la rapidez con la que avanza la tecnología, la regla por defecto es que los blips sólo aparecen en el Radar durante una edición, a menos que se muevan los anillos. Sin embargo, los miembros del Consejo Asesor de Tecnología de Thoughtworks (TAB) siempre pueden argumentar a favor de mantener un blip, por ejemplo, cuando haya ocurrido algo digno de mención que justifique una actualización de la reseña. 

Creemos que es importante mantener los blips más antiguos en el archivo para que estén completos y sean visibles, pero tenga en cuenta que no los estamos actualizando. En algunos casos, los equipos de Thoughtworks pueden seguir trabajando con estas tecnologías y recomendarlas; en otros, los consejos podrían estar obsoletos. Si está consultando un elemento de nuestro archivo, téngalo en cuenta.

Hemos ideado varias formas de mostrar los blips que cambian de un Radar a otro. En primer lugar, mostramos los blips nuevos de forma diferente a los blips que han aparecido antes. 

El cambio más común son los blips que se mueven entre anillos. Un blip que abarca una categoría amplia puede dividirse en elementos más estrechos a medida que esa categoría madura.

A veces movemos blips de un cuadrante a otro, lo que significa que nuestra clasificación del blip ha cambiado. No consideramos que este cambio sea importante y, por tanto, no lo mencionamos en ningún sitio.

 Todos los blips que ves en el Radar proceden de nuestros Thoughtworkers de todo el mundo. Antes de nuestras reuniones del Radar, nuestros equipos proponen cosas que han descubierto durante su trabajo en proyectos de clientes. Para aparecer en el Radar, nuestros colegas deben estar convencidos de que han visto algo que vale la pena compartir.

Intentamos limitar el número de blips que tenemos en el Radar, así que si pensamos que se está llenando demasiado discutiremos qué blips deben quedarse y cuáles no, a menudo con una votación para ayudar a centrar el consejo. 

No, pero el Radar es utilizado por los Thoughtworkers como una herramienta de intercambio de conocimientos entre proyectos y experiencias.

El Radar capta las cosas que se mueven, por lo que sólo las mencionamos si vemos un cambio significativo en la forma en que consideramos una tecnología a través de los anillos. Hay muchas tecnologías que nos gustan y que utilizamos continuamente y que no están en el Radar porque creemos que están asentadas y que hace tiempo que se han ganado su lugar.

Encontrarás muchas de estas tecnologías en los Radares anteriores, especialmente las del anillo de Adopción que ya han desaparecido. Pero tampoco es una lista exhaustiva, ya que siempre estamos luchando por el espacio en el Radar.

Nos reunimos dos veces al año, idealmente en persona para hablar del Radar.

En la reunión, los miembros del TAB dedican varias horas al Radar. Nuestro principal objetivo durante la reunión es decidir qué blips incluir, en qué anillos se encuentran y qué debemos decir sobre ellos.

Comenzamos colocando los blips candidatos en la pared, cada uno de ellos situado en el cuadrante y el anillo sugeridos. A menudo, diferentes personas sugieren los mismos blips, a veces en diferentes anillos. Una vez colocados los candidatos en la pizarra, pasamos al largo proceso de evaluación de cada ficha. Tomamos cada blip de uno en uno y discutimos si creemos que debería estar en el Radar, y si es así, dónde. Esta discusión es siempre agradable, hay muchas opiniones y experiencias en la sala, pero también hay una cordialidad y un respeto mutuo que hace que las discusiones sean mucho menos molestas de lo que a veces son este tipo de discusiones.

Nota: No deje de consultar los podcasts sobre cómo construimos el Radar a distancia y en persona.

Una vez elegidos y colocados los blips, hay que redactar las descripciones. Cada blip tiene un encargado que se encarga de redactarlo, lo que suele ocurrir después de la reunión. El TAB tiene un propietario de producto que tiene la nada envidiable tarea de perseguirnos para que redactemos nuestros blips. Una vez redactados, inician un proceso interno de comentarios en Thoughtworks y trabajan con los representantes de las distintas regiones para comenzar las traducciones. Mientras tanto, un diseñador trabaja en el gráfico y el PDF.

El Radar puede leerse en dos versiones: la web interactiva y el PDF. El sitio web permite explorar, buscar y enlazar blips. Por su parte, el PDF es ideal para leer todos los blips en un solo lugar.

Sí, animamos a la gente a que construya sus propios radares. Es una forma estupenda de obtener una evaluación objetiva de toda su cartera tecnológica y valorar qué está funcionando bien y dónde tiene oportunidades de mejora. Hemos creado una herramienta en línea que puede ayudarte a empezar.

Para entrar en el Radar es necesario llamar la atención de los Thoughtworkers, en particular en el contexto de nuestro trabajo de proyecto. Si consigues entusiasmar a un equipo de Thoughtworks, puedes llegar al anillo de evaluación, pero necesitamos experiencia real para seguir avanzando.

No tenemos un proceso formal para que personas externas propongan tecnología, o para organizar demostraciones. Pero los Thoughtworkers siempre buscan formas de mejorar el proceso de creación de software y somos miembros activos de numerosas comunidades tecnológicas.

Regularmente organizamos un seminario web de adelanto con dos miembros del TAB unas semanas antes de lanzar un nuevo volumen.

Además, solemos dar charlas sobre el Radar en las distintas regiones de Thoughtworks. El contenido depende de cada ponente; a la mayoría le gusta centrarse en los aspectos que le interesan especialmente, aunque estará encantado de responder a preguntas sobre todos los temas. Por lo general, las charlas sobre el Radar son impartidas por uno o dos miembros del TAB, tal vez con otro trabajador del pensamiento que esté familiarizado con él.

Si está interesado en que alguien hable sobre el Radar, o para obtener más información sobre estos temas, póngase en contacto con la oficina de Thoughtworks más cercana.

Ajey Gore (2010-12) • Anne J Simmons (2015-16) • Badri Janakiraman (2011-17) • Bharani Subramaniam (2016-present) • Birgitta Boeckeler (2020-present) • Brain Leke (2014-16) • Brandon Byars (2020-24) • Bryan Oliver (2025-present) • Camilla Falconi Crispim (2016-2018,2020-present) • Cassie Shum (2020-22) • Chris Chakrit Riddhagni (2025-present) 

Chris Stevenson (2010) • Claudia Melo (2013-15) • Cyndi Mitchell (2010-11) • Darren Smith (2010-14) • Dave Elliman (2015-16) • David Rice (2010-11) • Effy Elden (2025-present) • Erik Doernenburg (2010-present) • Evan Bottcher (2011-21) • Fausto de la Torre (2016-24) • Graham Brooks (2010-12)

 Hao Xu (2010-24) • Ian Cartwright (2010-23) • Ian Robinson (2010-11) • James Fischer (2010-13) • James Lewis (2012-present) • Jiaxing Chen (2016) • Jeff Norris (2010-15) • Jim Webber (2010-11) • Jonny LeRoy (2014-20) • Ken Mugrage (2024-present) • Ketan Padegaonkar (2017-19)

Lakshminarasimhan Sudarshan (2017-22) • Marco Valtas (2016-19) • Marisa Hoenig (2022-24) • Martin Fowler (2010-present) • Maya Ormaza (2023-present) • Mike Mason (2010-present) • Neal Ford (2010-present) • Ni Wang (2018-20, 2025-present) • Nick Hines (2010-12) • Nimisha Asthagiri (2025-present) • Pawan Shah (2023-present)

 Perla Villarreal (2020-22) • Pramod Sadalage (2010-12) • Rachel Laycock (2013-21, 2023-present) • Rebecca Parsons (2010-2024) • Ronaldo Ferraz (2012-13) • Sam Newman (2012-16) • Samir Seth (2010-11) • Scott Conley (2010) • Scott Shaw (2011-2024) • Selvakumar Natesan (2023-present) • Shangqi Liu (2018-present)

 Sofia Tania (2023-2024) • Srihari Srinivasan (2012-17) • Thiyagu Palanisamy (2012-16) • Thomas Squeo (2024) • Vanya Seth (2023-present) • Wendy Istvanick (2010-12)  • Will Amaral (2024-present) • Zhamak Dehghani (2016-22)

En realidad, el propósito del Radar en parte es ayudarnos a estar al día. Es inevitable que en nuestra profesión aparezcan constantemente cosas nuevas, y no podemos estar al día con todo. Puedes ver el Radar como nuestra opinión sobre cómo deberías priorizar tus investigaciones.

• Empieza por mirar el anillo de Adopción. ¿Conoces (y utilizas) todos los indicadores? Si no estás familiarizado con un blip, mira si es relevante para tu trabajo; si es así, deberías estudiarlo ahora — y ponerlo en práctica tan pronto como puedas. Si un blip de Adopt es relevante para tu trabajo y no lo estás utilizando, piensa bien por qué.

   

• Presta mucha atención a los blips del anillo de retención. Estamos señalando cosas que podrían ser más perjudiciales que útiles, dependiendo del contexto. Si lo estás utilizando, deberías reflexionar sobre por qué es así y si tiene sentido empezar a planificar el alejamiento de él. Educar a los que te rodean también podría ser una buena idea. La herramienta BYOR (Build Your Own Radar) puede resultar útil para iniciar estas discusiones.

   

• Una vez que te hayas familiarizado y hayas empezado a utilizar todo lo que hay en el anillo de adopción, pasa al anillo de prueba. Aquí, querrás mirar cada punto y considerar cuáles son relevantes para ti. Asegúrate de familiarizarte con estos temas — investiga en la web, consigue un par de libros, construye un prototipo con los elementos más prometedores. También puedes empezar a pensar en lo que supondría probarlos en tu organización.

   

• El anillo de evaluación es la última prioridad, que puedes empezar a investigar una vez que sepas lo que hay en el anillo de prueba. Debido a sus circunstancias, puede ser más importante conocer algo en este anillo que algo más profundo. Que no lo hayamos usado todavía no significa que sea menos importante. Pero en términos de priorizar tu aprendizaje, los anillos son una buena manera de hacerlo.

   

Por supuesto, esto es sólo nuestra opinión sobre sus prioridades. No esperamos que todo el mundo esté de acuerdo con nosotros, pero al menos es un comienzo.

Suscríbete al Radar Tecnológico para recibir correos electrónicos cada dos meses con información sobre tecnología de Thoughtworks y futuras publicaciones del Radar Tecnológico.