menú

Cada seis meses aproximádamente, ThoughtWorks publica su Technology Radar. Lo que comenzó como un experimento interesante, se convirtió en una publicación bastante notable. Lo que recibió mucha atención de nuestros clientes y otros cibernautas.

Preguntas Frecuentes:

A medida que el Radar se ha ido haciendo más popular, nos encontramos con varias preguntas sobre él: Por qué tiene el formato que tiene y cómo lo presentamos. Hemos creado este FAQ para responder a algunas de las preguntas más frecuentes que recibimos.

¿Qué es el Technology Radar de ThoughtWorks?

El Radar es un documento que establece los cambios que creemos que son relevantes actualmente en el desarrollo de software — cosas en movimiento a las que creemos que deberían prestar atención y considerar aplicar en sus proyectos. Refleja la opinión idiosincrásica de un grupo de tecnólogos de alto nivel y está basado en nuestras experiencias y trabajo cotidiano. Si bien pensamos que esto resulta interesante, no debería tomarse como un análisis profundo del mercado.

¿Qué es el TAB?

El Radar está escrito por el Comité Consultor de Tecnología de ThoughtWorks (ThoughtWorks Technology Advisory Board), conocido como el TAB por sus siglas en inglés.

El TAB es un grupo de alrededor de 20 tecnólogos senior de ThoughtWorks. El TAB se reúne frente a frente aproximadamente dos veces al año y quincenalmente por teléfono. Su rol principal es ser un grupo consultor para Rebecca Parsons, CTO de ThoughtWorks. El TAB actúa como un extenso cuerpo que observa los temas que impactan a la tecnología y a los tecnólogos en ThoughtWorks.

Construimos el Radar en nuestras reuniones frente a frente. Estas reuniones duran cuatro días, de los cuales aproximadamente uno es dedicado al diseño del Radar. Otros temas que se debaten incluyen las trayectorias profesionales para los desarrolladores, revisar el proceso de reclutamiento de desarrolladores, cómo mejorar nuestras habilidades para nuevas tecnologías y nuestras experiencias con arquitecturas de microservicio.

Rebecca escoge a los miembros del TAB intentando formar un grupo que pueda representar el mayor rango posible de líderes tecnológicos dentro de ThoughtWorks. El grupo tiene una membresía global (lo que hace dificulta la programación de reuniones telefónicas). Rebecca busca referencias sobre quiénes deben formar parte del TAB, pero la decisión final es suya. El TAB no debería ser visto como el mejor grupo de desarrolladores en ThoughtWorks —Hay muchos desarrolladores importantes que no están en él— sino como una selección representativa de líderes tecnológicos.

Los miembros del TAB cambian con el tiempo, por lo que cada Radar es elegido por un grupo de personas ligeramente distinto al anterior. Por lo general, vemos que dos o tres personas cambian entre reuniones, sin embargo no existe un plazo formal de servicio.

¿Cuál es la estructura del Radar?

El Radar se trata de rastrear cosas interesantes en tecnología, a la que nos referimos como blips. Organizamos los blips en el Radar usando dos elementos de categorización: los cuadrantes y los anillos. Los cuadrantes representan diferentes tipos de blips. Los anillos indican en qué etapa del ciclo de vida de adopción creemos que deberían estar.

People deciding radar structure

¿Qué cuenta como un blip?

Un blip es una tecnología o técnica que juega un rol en el desarrollo de software. Los blips son cosas que están “en movimiento” —Lo que implica que consideramos que su posición en el Radar está cambiando— generalmente indica que tenemos mayor confianza en ellas a medida que avanzan por los anillos.

¿Qué son los cuadrantes?

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

  • Lenguajes de programación y Frameworks. Solían ser solo lenguajes, pero incluimos frameworks aquí en el Radar de octubre del 2012.
  • Herramientas Éstas pueden ser componentes, como bases de datos; herramientas para el desarrollo de software, como sistemas de control de versiones; o categorías de herramientas más generales, como la noción de persistencia políglota.
  • Plataformas Cosas sobre las que construimos software, tales como tecnologías móviles como Android, plataformas virtuales como JMV, o tipos genéricos de plataformas como las nubes híbridas.
  • Técnicas Éstas incluyen elementos de un proceso de desarrollo de software como diseño de la experiencia (XD); y formas de estructurar software como microservicios.

Nosotros no nos hacemos mayor problema con los cuadrantes -—solo son una manera de dividir el Radar en áreas temáticas. No nos enfocamos en qué blip entra a cuál cuadrante, a diferencia de los anillos-— que generan mucha discusión.

¿Qué significan los anillos?

La metáfora del radar dice que cuánto más cerca de tí esté una señal (blip), más pronto estará sobre ti. Como la mayoría de las metáforas, no puede tomarse demasiado en serio, pero tiene un sentido esencial.

Nuestro radar tiene cuatro anillos, que describiremos comenzando desde el centro:

  • El anillo de Adoptar representa blips que creemos que deberías considerar seriamente usar. No decimos que se deben usar para cada proyecto. Cualquier herramienta solo debe ser usada en un contexto apropiado. Sin embargo, sí creemos que un blip en el anillo de Adopción representa algo que no hay duda que está probado y maduro para su uso.
  • El anillo de Probar es para blips que creemos que están listos para usar, pero no están tan probados como los del anillo de adopción. Por lo tanto, para la mayoría de las organizaciones, creemos que deben usarlos a modo de prueba y decidir si deben formar parte de su conjunto de herramientas. Normalmente, hemos utilizado blips de prueba en producción, pero observamos que los lectores son más cautelosos que nosotros.
  • El anillo de Evaluar significa que un blip debe tenerse en cuenta pero no necesariamente se ha probado aún, a menos que piense que sería una buena opción para usted. Por lo general, los blips en el anillo de evaluación son cosas que creemos son interesantes y vale la pena vigilar.
  • El anillo de Resistir es para blips que, aunque son aceptados en la industria, no hemos tenido una buena experiencia con ellos. Por lo tanto, les advertimos que usted también puede tener problemas. A veces esto se debe a que todavía no creemos que están lo suficientemente maduros y a veces significa que pensamos que son irremisiblemente defectuosos, o simplemente están siendo mal utilizados. Colocamos cosas en el anillo de retención que no nos gustaría que la industria use.

A diferencia de los cuadrantes, tenemos algunos argumentos bastante apasionados sobre a qué anillo debe dirigirse un blip. No tendemos a tener argumentos airados, pero los anillos son los que generan las discusiones más enérgicas. Desde que comenzamos la construcción del Radar, hemos ideado algunas reglas prácticas para ayudarnos a colocar cosas en los anillos.

Solo colocamos blips en el anillo de Probar cuando tenemos experiencia de ese blip en un proyecto real. Esto puede significar que a veces miramos detrás de la curva tecnológica, porque puede que nos guste algún aspecto de una tecnología, pero aún no hemos persuadido a un cliente para que la pruebe, y hasta que lo hagamos, ese blip no puede pasar a Probar.

Para el anillo de Adoptar, solo incluimos elementos cuando pensamos que sería una opción pobre y potencialmente irresponsable no usarlos dado el contexto de proyecto apropiado.

¿Qué importancia tiene la posición de un blip dentro de su cuadrante y anillo?

No invertimos mucha energía en decidir en qué cuadrante debería ir un blip, y nada en absoluto para ubicar su posición angular en el cuadrante. Así que las coordenadas angulares de un blip son decididas por quienes hacen el diseño visual y no tiene ningún significado semántico.

En contraste, sí ponemos atención en la posición radial. Si posicionamos un blip en el anillo Probar, pero cercano al anillo Adoptar, esto significa que estamos cerca de una amplia recomendación.

¿Por qué <alguna tecnología cool> no está incluida en el Radar?

Hay varias razones por las que no están presentes:

  • Ninguno de los miembros del TAB está familiarizado con ella.
  • Algunos TABers la han analizado pero no la encuentran suficientemente interesante.
  • La incluimos en nuestra lista inicial, pero tuvimos que reducir el número de blips para que quepan en el Radar. Este ítem fue una de las víctimas, lo que significa que sentimos que fue menos importante que otros.
  • Hablamos de esa tecnología en el Radar pasado, y no tenemos nada nuevo que decir sobre ella. Si un blip no se ha movido, se desvanece del Radar.
  • Suprimimos algo más genérico para hablar de un concepto más amplio. Por ejemplo, no hablamos específicamente de bases de datos NoSQL en nuestra primera edición del Radar, en su lugar mencionamos "bases de datos no relacionales". Después, lo llamamos bases de datos NoSQL.

¿Porqué hay blips que desaparecen de un Radar al siguiente?

El Radar representa tecnologías sobre las cuales estamos pensando activamente. Dada la velocidad a la cual la tecnología avanza, nuestra regla es que, por defecto, un blip sólo aparece en el Radar durante una edición. Tras eso es archivado. Los blips antiguos son accesibles bajo el índice A-Z completo.

Creemos que es importante mantenerlos en el índice por la integridad de la información y la visibilidad de la misma, pero ten en cuenta que no los actualizamos. En algunos casos el consejo proporcionado podría ya no ser válido. Es probable que equipos de ThoughtWorks sigan trabajando todavía con ellas todavía (y recomendándolas), pero sólo actualizaremos los blips si creemos que algo nuevo y digno de mención ha pasado (bien con la tecnología o con nuestra experiencia usándola).

¿Cómo cambian los blips?

Hemos ideado varias formas de mostrar cómo cambia un blip de un Radar a otro. Primeramente, mostramos nuevos blips de forma distinta a los que han aparecido antes. Permitimos a los blips moverse entre anillos. Los blips pueden explotar cuando una categoría general se divide en elementos particulares, o se fusionan cuando pensamos que podemos unir varias cosas como una.

Por lo general dividimos y combinamos cuando vemos diferentes partes de un blip más amplio deben estar en diferentes puntos en los anillos.

A veces movemos blips de un cuadrante a otro. Esto indica que nuestra visión sobre la clasificación del blip ha cambiado, como los cuadrantes no son de gran relevancia, no vemos el cambio como relevante y por tanto no merece ningún comentario en el texto.

¿Cuál es el criterio para incluir un blip?

Fundamentalmente, se reduce a uno o más miembros del TAB pensando que es importante. Hacemos hincapié en que es una elección personal del TAB —no tratamos de construir un Radar para toda la industria, éste es nuestro Radar. Publicamos el Radar porque hemos descubierto que otras personas pueden encontrar nuestras opiniones interesantes, pero no creemos tener alguna clase de autoridad especial. Tenemos preferencia para tecnologías que hemos usado en producción, de hecho es un requisito para entrar en los anillos Probar y Adoptar.

El cambio de los miembros del TAB afecta al blipeo. Si un champion de un blip sale del TAB, hay ciertas posibilidades de que los temas en los que él o ella esté más interesado/a tengan menor atención en el futuro.

 TAB voting

Intentamos limitar cuántos blips tenemos en el Radar, así que si creemos que se está copando mucho discutimos qué blips deberían quedarse y cuáles no encajan, en ocasiones con votación para ayudarnos a enfocar el consejo, La decisión final para ubicar los blips la toma Rebecca Parsons.

¿El Radar es una lista de tecnologías aprobadas por ThoughtWorks?

No.

El Radar capta cosas que se están moviendo —así que solo incluímos los blips que vemos que cambian significativamente en la forma en que consideramos las tecnologías a través de los anillos. Hay algunas tecnologías que nos gustan y utilizamos todo el tiempo que no están en el Radar porque creemos que están establecidas y se han ganado su lugar desde hace mucho tiempo.

Encontrarás muchas de estas tecnologías en los Radares pasados, particularmente en las del anillo Adoptar hasta que se desvanecen. Pero incluso esta no es una lista exhaustiva, ya que siempre estamos luchando con el espacio.

¿Cómo construimos el Radar?

El enfoque de construir el Radar es nuestra reunión bianual frente a frente. Antes de la reunión, las y los TABers normalmente están hablando con mucha gente y pensando qué debe ser blipeado. Las y los ThoughtWorkers que no pertenecen al TAB abogan por cosas que les interesan, aunque es el Radar del TAB, buscamos opiniones de diversas fuentes, dentro y fuera de ThoughtWorks.

En el frente a frente, invertimos muchas horas en el Radar. Nuestro objetivo principal durante la reunión es decidir cuáles son los blips y a qué anillo pertenecen. Dado que este es el punto más polémico del proceso, es importante hacer esto mientras estamos todos juntos.

Empezamos colocando los blips candidatos en el muro, cada uno ubicado en un cuadrante y anillo sugeridos. A menudo, distintas personas sugieren los mismos blips, comúnmente en distintos anillos. Una vez que tengamos los candidatos en la pizarra, seguimos con el largo proceso de de evaluar cada blip. Tomamos cada blip, uno por uno, y discutimos si debería estar en el Radar, y si es así, dónde. Esta discusión siempre es entretenida, hay muchas opiniones y experiencias sobre el espacio, pero también existe un ambiente amistoso y respeto mutuo, lo que hace que los argumentos sean mucho menos ásperos de lo que suelen ser en este tipo de discusiones.

Una vez que tenemos los blips seleccionados y ubicados, necesitamos escribir el texto para cada uno. Lo hacemos usando Mingle, así podemos colaborar fácilmente en las descripciones. Cada blip tiene un champion que es responsable de escribir sobre él, lo que generalmente sucede después de la reunión. El TAB cuenta con un coordinador que tiene el nada envidiable trabajo de perseguirnos para que escribamos nuestros blips.

Más o menos al mismo tiempo en que trabajamos en la escritura, una persona de diseño trabaja en lo gráfico. Le decimos qué blips mostrar y su distancia del centro, pero el o ella decide el ángulo dentro del cuadrante.

Nuestro coordinador extrae el texto de Mingle y lo junta los distintos formatos para el Radar.

¿En qué formatos se publica el Radar?

Tradicionalmente, el formato principal para el Radar ha sido el PDF, ya que es un documento rico en diseño que nos gusta enviar a la gente. En las ediciones más recientes del Radar, hemos construido una versión interactiva en HTML para ofrecer una mayor capacidad para explorar, buscar e ingresar a los blips.

¿Puedo construir mi propio Radar?

Sí, impulsamos a la gente a crear sus propios Radares. Es una excelente forma de visualizar una estrategia tecnológica y te podemos ayudar a empezar. Como ejercicio, alienta a las personas a pensar sobre qué tecnologías deberían estar investigando y las ayuda a evitar los peligros de vivir en una burbuja tecnológica.

¿Cómo puedo introducir mi producto en el Radar?

Para entrar en el Radar, necesitas atraer la atención de los miembros del TAB, particularmente en el contexto en que nuestro proyecto trabaja. Si lograste emocionar a un miembro del TAB, puede llegar al anillo Evaluar, pero necesitamos experimentarlo realmente para que avance más.

 Reviewing last edition 's blips

No tenemos un proceso formal en que terceros puedan nominar tecnología, o realizar demostraciones. Pero los ThoughtWorkers siempre están buscando formas de mejorar el proceso de creación de software y somos miembros activos de numerosas comunidades tecnológicas.

¿Por qué hay tantos proyectos de ThoughtWorks de código abierto?

Principalmente porque los usamos. A menudo, estos proyectos son el resultado de una necesidad que tenemos en una situación con el cliente, frecuentemente cuando sentimos que estamos reconstruyendo lo mismo nuevamente.

¿Puedo conseguir a alguien para que dé una charla sobre el Radar?

A menudo ofrecemos charlas sobre el Radar. Éstas dependen del expositor, a la mayoría de gente le gusta centrarse en los blips en que están particularmente interesados, aunque estarán felices de contestar preguntas sobre todos los ítems. Normalmente las charlas del Radar son impartidas por un miembro del TAB o dos, a veces con otro ThoughtWorker que esté familiarizado con el tema.

Neal también da una charla sobre building your own radar (construye tu propio radar).

Si estás interesado/a en conseguir a alguien para que de una charla sobre el Radar, o quieres mayor información en estos temas, contacta con la oficina de ThoughtWorks más cercana.

¿Por qué la lista de referencia no incluye todas las cosas que mencionan?

No intentamos proveer una lista de referencia completa, debido a las limitaciones de tiempo y espacio. Así que solo incluimos referencias a cosas que pensamos que serán un poco difíciles de rastrear, cosas que encontramos particularmente atractivas o que presentan un punto de vista diferente.

¿Quién ha trabajado en el Radar anteriormente?

Ajey Gore

Ajey Gore

(2010-12)
Anne J Simmons

Anne J Simmons

(2015-16)
Badri Janakiraman

Badri Janakiraman

(2011-17)
Brain Leke

Brain Leke

(2014-16)
Camilla Falconi Crispim

Camilla Falconi Crispim

(2016-18)
Chris Stevenson

Chris Stevenson

(2010)
Claudia Melo

Claudia Melo

(2013-15)
Cyndi Mitchell

Cyndi Mitchell

(2010-11)
Dave Elliman

Dave Elliman

(2015-16)
David Rice

David Rice

(2010-11)
Graham Brooks

Graham Brooks

(2010-12)
Ian Robinson

Ian Robinson

(2010-11)
James Fischer

James Fischer

(2010-13)
Jiaxing Chen

Jiaxing Chen

(2016)
Jeff Norris

Jeff Norris

(2010-15)
Jim Webber

Jim Webber

(2010-11)
Nick Hines

Nick Hines

(2010-12)
Pramod Sadalage

Pramod Sadalage

(2010-12)
Ronaldo Ferraz

Ronaldo Ferraz

(2012-13)
Sam Newman

Sam Newman

(2012-16)
Samir Seth

Samir Seth

(2010-11)
Scott Conley

Scott Conley

(2010)
Srihari Srinivasan

Srihari Srinivasan

(2012-17)
Thiyagu Palanisamy

Thiyagu Palanisamy

(2012-16)
Wendy Istvanick

Wendy Istvanick

(2010-12)

Esto es demasiado, ¿Cómo puedo mantenerme al tanto?

De hecho, el propósito del Radar es ayudarlos a mantenerse al tanto. Es inevitable para nuestra profesión que hay nuevas cosas apareciendo constantemente, y no podemos estar al tanto de todo. Puedes tomar al Radar como nuestra opinión de cómo deberías priorizar tus investigaciones.

  • Comienza viendo el anillo Adoptar. ¿Estás familiarizado (y usas) todos los blips de aquí? Si no estás familiarizado con un blip, revisa si es relevante para lo que haces; si es así, deberías estar estudiándolo ahora —y aplicándolo tan pronto puedas—. Si un blip de Adoptar es relevante para tu trabajo y no lo estás usando, piensa seriamente por qué.
  • Una vez que te hayas familiarizado y uses todo lo del anillo Adoptar, muévete al anillo Probar. Aquí, querrás ver cada blip y considerar cuáles son relevantes para ti. Asegúrate de familiarizarte con estos temas —haz una búsqueda en la web, toma un par de libros, construye un prototipo con los ítems más prometedores. También puedes comenzar a pensar sobre qué se necesita para probarlo en tu organización.
  • El anillo Evaluar es la última prioridad, que puedes empezar a investigar una vez que hayas visto qué hay en el anillo Probar. Debido a tus circunstancias, puede ser más importante conocer algo en este anillo que algo más profundo. Solo porque no las hemos usado antes, no significa que son menos importantes. Pero en términos de priorizar tu aprendizaje, los anillos con una buena forma de avanzar.
  • Puedes ignorar las cosas en el anillo Resistir, al menos por ahora.

Por supuesto, ésta es solo nuestra opinión de tus prioridades. No esperamos que todos estén de acuerdo con nosotros, pero al menos es un comienzo.

Subscríbete al Technology Radar