Cómo Perfeccionar y Aprovechar los Talleres Remotos UX

Los mejores diseñadores de hoy en día son más que creadores, son facilitadores. En un proceso cada vez más multidisciplinario, colaborativo y creativo que incluye a muchos participantes, actúan como conductores que alinean e inspiran al equipo a dar lo mejor de sí.

Los talleres UX son probablemente una de las mejores maneras de poner esto en práctica. El surgimiento de ideologías como Pensamiento de Diseño, Lean UX, y Design Sprints han convertido los talleres UX en una necesidad, y para los diseñadores, les ha otorgado la capacidad de facilitar un taller de diseño es una habilidad altamente deseable .

Un taller de UX consiste en invitar a tu equipo (otros diseñadores, desarrolladores, gerentes de productos, etc.) a una sala de conferencias, reunir una agenda alrededor de un objetivo (por ejemplo, prototipos de una nueva funcionalidad de producto) y llegar a algunas técnicas de colaboración, como el brainstorming y el bosquejo. Lograrás mejores resultados al hacer esto que tratando de administrar todo tú mismo—y como una ventaja añadida, cultivar un equipo más comprometido y motivado.

Imagínate hacerlo con miembros de equipo remotos viviendo en el otro lado del mundo sin comunicación cara a cara en una situación donde es muy probable que se produzcan problemas técnicos. Si realizar un taller de diseño con un equipo co-ubicado (todos en el mismo lugar físico) ya es un desafío, su versión remota puede ser una frustración real y una pérdida de tiempo si ignoras las técnicas de facilitación crítica y probada.

Echemos un vistazo a algunas prácticas probadas con el tiempo que ayudarán a que un taller UX remoto funcione sin problemas. También veremos lo que sucede antes, durante y después, y algunas de las trampas que debe buscar.

Antes del Taller

Definir los Roles de los Participantes y Obtener Ayuda

Planificar y facilitar un taller de diseño remoto requiere preparación y colaboración. Es una buena idea delegar algunas tareas a otros. Esto ayudará a evitar los cuellos de botella y las sorpresas desagradables durante el taller — como tener que recoger notas y explicar los próximos pasos simultáneamente.

Hay dos funciones que trabajan juntas en el funcionamiento de un taller UX remoto: el líder de taller y el asistente local:

El líder y facilitador del taller

Esta es la persona (probablemente tú) que, entre otras cosas, “dirigirá el programa”, manejará la colaboración y el calendario del taller, fijará el ritmo de las actividades y mantendrá a los participantes involucrados. Su misión principal es ayudar al equipo a ser productivo y mantener el flujo de taller. Sea un líder de servicio. Dependiendo de la técnica del taller remoto, también puedes participar (por ejemplo, podrías llevar una sesión de creación de prototipos y boceto al mismo tiempo).

El asistente local

Dado que el facilitador sólo puede estar en un lugar a la vez, cada uno de los lugares remotos debe tener un asistente local que puede contribuir junto con el resto del equipo. Es importante tener a alguien al otro lado para:

• Ocuparse de la logística (reservar un salón de conferencias, agendar el taller con los participantes, etc.)
• Organizar la sala y configurar la tecnología remota (véase a continuación)
• Obtener materiales y suministros (Sharpies, Post-its, blocs de notas, etc.)
• Ayuda para ejecutar el taller

Configurar la Sala y Probar la Tecnología con Anticipación

Nada es más frustrante que tener una gran discusión o una generación de ideas interrumpida por una conexión perdida, una interferencia de pantalla compartida, un eco excesivo en la sala o que no se puedan ver los detalles del boceto que hizo tu colega en papel y se posicione infructuosamente frente a la cámara para que puedas ver y dar tu opinión sobre ello. Esta lista puede ser larga.

A pesar de que el rendimiento final de un taller UX remoto depende en gran medida de la tecnología y la sala, muchos de nosotros todavía damos por sentado que todo saldrá bien. Esta suposición puede ser peligrosa. Aunque probablemente no sea posible ejecutar un taller UX perfecto, con un poco de planificación y pruebas suficientes, puede evitar la mayoría de las sorpresas negativas. Asegúrate de que tienes:

1. Una conexión a Internet estable y una copia de seguridad. Además de tu conexión a Internet principal, asegura una red móvil como copia de seguridad. La mayoría de las redes 3G / 4G de hoy en día admiten videoconferencias en niveles aceptables. ¡Prepárate para cambiar rápidamente a su conexión móvil si es necesario, y asegúrese de probarla de antemano!
2. Una sala tranquila, cómoda y bien iluminada. En la medida de lo posible, evita cosas como el eco, la interrupción de otros, la luz dura (por ejemplo, de las ventanas abiertas que son desastrosas para las cámaras), reflejos en pizarras, o demasiada oscuridad. Si alguien está participando de un espacio compartido (como una sala de oficina regular o una situación de coworking), asegúrese de que hay reglas para el ruido y las interrupciones cuando una reunión está en curso. Por ejemplo, en mi trabajo anterior, apagamos algunas de las luces para que alguien de repente entrando en la sala supiera que se estaba llevando a cabo una reunión remota.
3. Equipos de videoconferencia apropiados. Hoy en día hay toneladas de soluciones específicas que satisfacen diferentes necesidades y presupuestos. Para una configuración de una sola persona, unosauriculares con micrófono y la cámara HD en el formato de laptops modernas puede ser suficiente. Para salas de conferencias (y ordenadores de sobremesa), comprueba esta herramienta en línea para encontrar la mejor solución de videoconferencia para tu equipo .
4. El software de colaboración adecuado Para los talleres de UX remotos, es fundamental contar con excelentes programas de videoconferencia, uso compartido de archivos y uso compartido de pantallas. Varias soluciones ofrecen todo en un solo lugar, como Google Hangouts, Slack y Zoom. Mi preferencia por la videoconferencia y el uso compartido de la pantalla es Zoom (de lejos), sobre todo debido a la impresionante calidad de video, pero recomiendo echar un vistazo a algunos revisiones de software para decidir por ti mismo.

Por último, una vez que hayas comprobado los elementos anteriores en su lista, asegúrate de probar todo bien antes del taller. Luego, prueba nuevamente si puedes.

Be realistic when facilitating a UX workshop

Planea con tu asistente local y decida qué técnicas y herramientas de taller usarás para los resultados que desea lograr.

1. Explica y practica las técnicas con el asistente local de antemano, para que estén en sincronía durante el taller.
2. Es importante calcular el tiempo de cada tarea con exactitud, no seas demasiado optimista al estimar las duraciones de la actividad, o en permitir demasiado tiempo.
3. Programe las pausas para que los participantes puedan reorientar sus energías.
4. Por último, planea algún tiempo para solucionar problemas técnicos potenciales y otros problemas que puedan surgir durante el taller (5 minutos por tarea está bien). Ellos lo harán.

Durante el Taller

Balancea Herramientas Digitales y Físicas

Uno de los desafíos más difíciles al ejecutar un taller UX remoto es encontrar una combinación ideal de herramientas digitales y físicas. Es un delicado equilibrio, ya que ambos tienen sus ventajas y desventajas; uno tiene que elegir sabiamente.

El objetivo es mantener el flujo de taller mientras procesa eficientemente el flujo de datos (contenido) que genera. Deseas que el equipo genere ideas rápidamente, pero también quieres sacar el máximo provecho de esas ideas procesándolas de manera que obtenga la máxima productividad (agrupación, fusión, división, priorización, etc.). Aquí hay dos estrategias diferentes para esta combinación:

Enfoque del taller 1: Principalmente artefactos no digitales

Este enfoque se aplica cuando se crea la mayoría de los artefactos “analógicamente” usando lápiz + papel y digitalizándolo más tarde al escanear o tomar fotos. Este enfoque es el más apropiado cuando:

1. La mayor parte del equipo está en un lugar (sólo unos pocos participantes son remotos)
2. Deseas aprovechar la velocidad y la libertad de contenido que se genera a mano (bocetos, Post-its, etc.)
3. El costo de digitalizar y clasificar la información capturada es bajo, es decir, no es necesario modificar o procesar el contenido generado en exceso (resumir, reescribir, etc.).

Por ejemplo, en un concepto de taller llamado “estudio de diseño”, los participantes de la sesión pueden dibujar rápidamente a mano, capturar imágenes con su móvil y compartir a través de Dropbox o Slack. Otro ejemplo es una sesión de ideación corta en la que sólo tiene que asignar algunos Post-its (menos de 20), y alguien puede escribir rápidamente las notas Post-it en una hoja de cálculo para facilitar la clasificación y la priorización.

Naturalmente, hay algunos inconvenientes a este enfoque:

1. El riesgo de perder el acceso a cosas que no digitalizas. Imagina que semanas o meses después necesitas revisar el tema, recordar qué fue discutido, pero no puedes encontrar ninguna exploración o fotos. A menos que te hayas tomado el tiempo para almacenar los post-its, mantenerlos organizados y accesibles, este no es un escenario deseable.
2. Con los artefactos digitalizados, uno no tiene la capacidad de "copiar, pegar, deshacer, duplicar, clasificar”, etc. fácilmente, lo que dificulta la productividad.

Enfoque del taller 2: La mayoría de artefactos digitales

Utiliza este enfoque cuando uses herramientas digitales para crear y administrar contenido generado por talleres (como tableros virtuales y hojas de cálculo en línea). Este enfoque es el más apropiado cuando:

1. Quieres mantener todo lo que fue creado (hallazgos, ideas, bocetos, etc.) fácilmente accesible
2. Deseas editar y reorganizar contenido rápidamente (copiar + pegar, duplicar, filtrar, clasificar, número, priorizar, por ejemplo, como en un formato de hoja de cálculo)
3. El equipo es en su mayoría remoto

Un buen ejemplo para usar este enfoque de taller es cuando el equipo está creando diagramas de afinidad, mapas de empatía o viajes de usuarios usando tableros virtuales.

Otro escenario que funciona con este enfoque es cuando necesitas recopilar ideas en sesiones de ideación. En lugar de Post-its en el tablero o pizarrón (físico o virtual), puedes utilizar una hoja de cálculo en línea compartida donde cada participante escribe sus ideas en las celdas de la hoja de cálculo (consulta a continuación).

También puedes acelerar el proceso de selección y priorización de ideas durante las sesiones brainstorming con el uso de funciones de cálculo y clasificación automáticas. En el ejemplo de abajo, el equipo necesitaba elegir las mejores ideas de más de 40 que habían pensado anteriormente. La hoja de cálculo permitió votar por las mejores ideas y ordenó automáticamente la lista por el número de votos. Todo el proceso tomó menos de 8 minutos.

Los participantes en el taller votaron por ideas (columna B) ingresando puntos en una escala de 5 a 1 en las columnas asignadas (columnas C a L). A continuación, la hoja de cálculo calculó el total de puntos (votos) para cada idea, permitiendo al facilitador ordenar los resultados rápidamente (columna M).

Las desventajas típicas de esta estrategia son:

1. Las técnicas de taller que requieren dibujo (como el dibujo) y otras tareas de mano libre (post-its) pueden verse en desventaja a menos que haya una gran herramienta de captura digital disponible
2. Algunas personas del equipo no tendrán acceso a las herramientas digitales seleccionadas (software, hardware adecuado, etc.). Algunas juntas virtuales en línea en modo gratuito limitan el número de usuarios y no es factible sumar el número requerido de participantes debido a restricciones presupuestarias

Un ejemplo práctico

Se discutieron dos enfoques de taller UX (1: principalmente físicos, y 2: en su mayoría digitales); En el mundo “real”, puedes usar un enfoque híbrido y mezclar aspectos de ambos. Imaginemos un taller de diseño de un día para el cual podríamos aplicar el siguiente método (considerando que todo se hace vía videoconferencia):

Qué		Cómo (y usando cuál herramienta)
1	Empatizar	Resultados actuales de la investigación del usuario (Keynote / Google Slides) Mapa de empatía (pizarrón virtual)
2	Encuadre del Problema	Brainstorming (pizarra virtual o hoja de cálculo) Diagrama de afinidad (pizarra virtual o hoja de cálculo)
3	Ideation	Brainstorming (hoja de cálculo compartida) Priorizando (hoja de cálculo compartida)
4	Prototipando	Bocetar (Lápiz + papel, tomar fotografías y compartirlas en una pizarra virtual o en un grupo de aplicaciones de mensajería) Elegir las mejores ideas (votación por puntos en la pizarra virtual)

• 
  
• 
• 
• 

Acelera el trabajo con plantillas

Asegúrate de tener todo listo para usar cuando comience el taller: plantillas, documentos pre-llenados, tableros virtuales, etc. Prepárate diligentemente y no desperdicies el tiempo de todos al instalarte frente a ellos.

Después del taller

Obtener comentarios, evaluar y mejorar

Es una buena idea obtener comentarios de tu equipo después del taller e identificar áreas que podrían mejorarse. El mejor momento para hacer esto es justo después de que haya terminado porque todo seguirá estando fresco. Por ejemplo, como resultado del uso extensivo de la tecnología en el caso de un enfoque casi digital, muchas trampas y fallas potenciales invariablemente surgen, discutiendo por qué ocurrieron y cómo evitarlo sucediendo de nuevo es de gran beneficio para cualquier equipo.

Antes del taller, prepara una breve encuesta en línea anónima y envía el enlace a los participantes justo después del taller. Asegúrate de rastrear cada aspecto como una sección separada (equipo y técnicas utilizadas, comunicaciones, tecnología remota, software, duración del taller, etc.) y deja que el equipo deje comentarios, no sólo la tasa o las casillas de verificación.

Hay muchas otras maneras de obtener retroalimentación posterior al taller — como pedirle al equipo que coloque post-its en una pared con comentarios (físicos o virtuales), o hacer entrevistas individuales. Elige el que más te convenga, pero no pierdas la oportunidad.

Cuida tus artefactos digitales

Los activos generados durante el taller son útiles no sólo mientras están en curso, sino que pueden utilizarse para discusiones en el futuro cercano o como punto de partida para otros talleres.

En un enfoque tradicional (o casi no digital), es muy probable que termines con pilas de post-its, notas manuscritas y bocetos. Si este es el caso, una buena práctica es mantener al menos los artefactos más importantes hasta que estés seguro de que puede dejarlos ir. También tienes la opción de digitalizarlos (tomar fotos, tabulación a hojas de cálculo, etc).

En un enfoque casi digital, no tendrás tanto papel para tratar, pero los artefactos digitales generados todavía tendrán que organizarse, clasificarse y archivarse en algún tipo de sistema. Es mejor no dejar una lista desordenada de archivos incompletos, abandonados que causarán dolores de cabeza en el futuro — invierta algo de tiempo justo después del taller para organizarlos. Puedes hacer esto de dos maneras:

1. Crear un repositorio centralizado y organizado para el taller. Por ejemplo, una carpeta maestra compartida con subcarpetas para cada técnica que se utilizó durante el taller. Asegúrate de incluir enlaces a tablas virtuales y cualquier otra fuente/herramienta externa.
2. Asegúrate de que los artefactos básicos están completos (bocetos, hojas de cálculo, tableros virtuales, etc.). Cuando no sea posible terminarlos durante el taller, si crees que pueden ser útiles en el futuro, hazlo lo antes posible una vez que haya terminado. No confíes en tu memoria porque meses más tarde, un bosquejo incompleto o hoja de cálculo puede no tener ningún sentido para ti.

Para concluir

Utilizando diferentes técnicas y herramientas, los talleres UX remotos pueden ofrecer los mismos resultados que los talleres ubicados en una misma ubicación. Si se hace correctamente, los beneficios de productividad potenciados por las herramientas de colaboración digital compensa la falta de discusión cara a cara.

Planificar y ejecutar un taller de diseño remoto UX no es ciencia de cohetes, pero los muchos detalles complejos y las trampas potenciales requieren atención. A pesar de la preparación meticulosa, es improbable que obtendrás todo bien en el primer intento. Lo mejor es relajarte, divertirte con tu equipo, y recuerda que — ¡cada taller representa una oportunidad para aprender, y la próxima vez es siempre una mejora!

Este articulo fue escrito por Carlos Rosemberg. Originalmente publicado en Toptal.

Guarda la Calma y Transiciona a un Nuevo Equipo de Desarrollo

Es común que un producto de software haga una transición de un equipo de desarrollo a otro en el curso de su vida. Las diferentes etapas del producto pueden requerir un equipo de desarrollo diferente: una consultoría para construir la versión inicial, un desarrollador independiente para mantenerla, un equipo interno para llevarlo a escala, o un diseñador profesional para hacerlo visualmente llamativo.

A pesar de que esto ocurre con frecuencia, muchos fundadores no técnicos y los propietarios de los productos no se encuentran preparados y luchan cuando llega el momento de traer al próximo equipo. Esto a menudo da como resultado una incapacidad para que el nuevo equipo pueda avanzar rápidamente, una pérdida de tiempo, y una frustración que incluye a todos los miembros.

Si esto suena como que podrías ser tú, ya sea ahora o en el futuro, entonces deberías estar algo preocupado. Por suerte, voy a guiarte a través de los pasos a seguir para prepararte para esta eventualidad y hacer la transición lo más sencilla posible.

Pasar la Antorcha: Abordando un Nuevo Equipo de Desarrollo

En este artículo, voy a ofrecerte una lista de verificación que te ayudarán a prepararte para un cambio de este tipo. Comenzarás a conocer tu producto en un nivel más íntimo y obtendrás un mayor control sobre los diversos servicios y tecnologías que conlleva el hacerlo, lo cual te ayudará a abordar un nuevo equipo con tranquilidad relativa y confianza.

¿Pero si no estás reemplazando todo el equipo? ¿Deberías tomarte el tiempo de leer esto?

Incluso si algunos miembros del equipo anterior permanecen a bordo, puede ser que no tengan todas las respuestas e información necesaria para una transición sin problemas. A pesar de que pueden proporcionar continuidad y ayuda en el proceso de transferencia de conocimiento del antiguo equipo al nuevo, depender de los miembros del equipo titular no reemplaza el hecho que el dueño del producto se haga cargo y facilite la transferencia. Además, no poder hacerse cargo podría causar fricción entre los nuevos y antiguos miembros del equipo, o responsabilizar a antiguos miembros del equipo con tareas innecesarias, obligándolos a perder demasiado tiempo comunicándose con los nuevos miembros del equipo y resolviendo distintos problemas.

Sin embargo, si algunos miembros del equipo se quedan a bordo, pueden ser de gran valor en tus esfuerzos de transición. Consulta con ellos, mantenlos informados y trata de aprovechar su experiencia sin inundarlos con demasiadas tareas relacionadas con la transición. ¡No esperes que ellos hagan todo el trabajo pesado! Ese es tu trabajo.

Así que sin más preámbulos, ¡metámonos de lleno en esto!

Reunir Documentación

A los desarrolladores independientes a menudo se les pide saltar en una base de código existente que nunca han visto antes. Esto es especialmente cierto con respecto a los ingenieros de software de Toptal. Nuestro objetivo es siempre ponernos en marcha tan pronto como sea posible para que podamos empezar a tener un impacto positivo para nuestros clientes.

Tener acceso a una documentación clara e íntegra sobre el proyecto puede acelerar dramáticamente el proceso de incorporación, y ayudar a los desarrolladores a evitar errores que pueden impedir el progreso.

Una buena documentación debe cubrir al menos los siguientes temas:

• Creación de un entorno de desarrollo - La primera tarea para cualquier nuevo empleado es instalar la aplicación y ponerla en funcionamiento en sus propias computadoras. El proceso para hacer esto varía entre las tecnologías. En general, requiere tareas tales como obtener el código fuente, la creación de la base de datos, la instalación de dependencias, configurar el entorno con claves de la API y las credenciales, la importación de datos de muestra, y así sucesivamente. Los desarrolladores tienen una buena idea de todo lo relacionado con este proceso dentro de sus respectivos campos, y deben tener la capacidad de ajustar los detalles conformemente.
• Ejecutar el conjunto de pruebas automatizadas - Al ver pasar las pruebas de una aplicación nos aseguramos que todo se ha configurado correctamente y que los próximos cambios no rompen ninguna de las características actuales.
• Implementar en los servidores de ensayo y producción - Actualizar la aplicación en vivo con los nuevos cambios es un proceso altamente estructurado, y el orden de esas operaciones se debe esbozar paso a paso lo más detallado posible.
• Cualquier otra información que sea relevante para un nuevo desarrollador a bordo - Cada aplicación tiene su propio conjunto de peculiaridades. Al escribir estas peculiaridades, se le ahorra a futuros equipos, esfuerzos innecesarios en depurar problemas que el equipo anterior ya ha descubierto cómo solucionar.

La documentación debe ser escrita por un desarrollador que tenga experiencia de primera mano en la configuración de la aplicación y contribuyendo a la base de códigos.

¡Antes de que ocurra cualquier transición, solicita que el equipo de desarrollo anterior facilite la transferencia de conocimientos mediante la creación de un recurso que toque los temas anteriores!

Si la escritura no es el punto fuerte del equipo, pídeles que registren una o más capturas de pantalla que demuestren la configuración del entorno de desarrollo, despliegue, etc. Hoy en día incluso hay herramientas como Vagrant y Docker que permiten a entornos de desarrollo completos ser empaquetados y distribuidos a los demás. En esencia, en lugar de dar instrucciones a alguien sobre cómo construir un martillo, entregales el martillo.

La prueba de fuego para saber qué tan comprensible y efectiva es la documentación de un proyecto, es la rapidez en que un nuevo desarrollador puede entender la configuración de su entorno de desarrollo y ejecución de su aplicación.

Entiende tu Producto

Tener gran documentación no te exime de la necesidad de conocer los fundamentos de la tecnología de tu propio producto. Como propietario de un producto de software, es tu responsabilidad entender tu aplicación lo mejor posible, incluso si no posees muchos conocimientos técnicos.

• ¿Qué elementos tecnológicos utiliza tu aplicación? - Hay muchos marcos de aplicación común para el back-end y el front-end, y cualquier equipo nuevo de desarrollo debe estar familiarizado con los que utiliza tu aplicación. Algunos ejemplos de tecnologías web de back-end son Ruby on Rails, Node.js, y [Django](https://en.wikipedia.org/wiki/Django_(web_framework). Algunos ejemplos de tecnologías web front-end son React.js, Angular.js, y Ember.js.
• ¿Dónde se encuentra alojado? - Diferentes servidores web tienen diferentes procesos de implementación, que requieren diversos niveles de experiencia. En los últimos años, las tecnologías de nube han creado una serie de nuevas opciones de alojamiento web, y tendrás que identificar cuál de estos, en concreto, estás utilizando y describir por qué lo elegiste sobre los demás.
• ¿Cuál es el proceso de desarrollo? - ¿Tu equipo utiliza una herramienta de gestión de control de fuente específica como [Git](https://en.wikipedia.org/wiki/Git_(software)? Si es así, ¿cuál es el proceso por el cual una nueva característica se ha desarrollado, probado, aprobado, e implementado? El proceso debe ser normalizado, debidamente documentado y fácil de reproducir por los nuevos integrantes.
• ¿Qué servicios de terceros utiliza tu aplicación? - Algunas aplicaciones se basan en servicios de terceros como Shopify. Por favor, ten en cuenta que la dependencia de los servicios de terceros está aumentando gradualmente, e incluso si actualmente no utilizas ningún servicio adicional, tu proyecto puede decidir emplear un servicio de terceros más adelante.
• ¿En qué plataformas se puede ejecutar tu aplicación? - ¿Tu aplicación es una aplicación de escritorio, aplicación web, sitios web responsive para teléfonos móviles, una aplicación nativa de iOS, aplicación nativa de Android, o alguna otra? ¿Se ejecuta en varias plataformas diferentes? ¿Cuál plataforma es tu prioridad en un momento dado? ¿En cuál plataforma es tu producto más fuerte o más débil? Asegúrate de conocer todos los detalles de las plataformas actuales de tu aplicación, e incluso a cuáles se puede ampliar.

Toma Posesión

El proceso de desarrollo de software de hoy en día utiliza una gran cantidad de servicios de terceros y herramientas. Ya sea que lo sepa o no, tu aplicación no es una excepción.

Durante el trascurso de desarrollo, tu equipo anterior puede haberse registrado o suscrito a tu nombre, o incluso utilizado sus propias cuentas para obtener acceso a los servicios que se necesitaban. La transición a un nuevo equipo significa que debes tomar posesión y estar en control de cada uno de los servicios y herramientas en las cuales tu aplicación está basada, para que así puedas permitir el acceso a tu nuevo equipo, sin necesidad de pasar por un intermediario o perseguir a los desarrolladores originales.

La siguiente lista muestra las diferentes herramientas o servicios externos de los que tu aplicación podría sacar provecho:

• Gestión de Fuente de Control - GitHub, Bitbucket, Gitlab
• Alojamiento Web - Heroku, EngineYard, Digital Ocean, Bluehost, Amazon Web Services
• Alojamiento de archivos - Amazon Web Services (S3)
• Proveedor de DNS - GoDaddy, DNSimple, Hover
• Servicios de Desarrollo - NewRelic, FileStack, Segment, Bugsnag (y muchos otros)
• Servicios de Pago - Stripe, Braintree, PayPal
• Servicios de blog - WordPress, Tumblr, Ghost
• Soluciones de comercio electrónico - Shopify, Squarespace
• Analítica / Seguimiento - Google Analytics, Mixpanel, Kissmetrics
• Email Marketing: MailChimp, Constant Contact

Pregúntale a tu equipo de desarrollo saliente cuáles son aplicables. Para cualquiera de los servicios que son de propiedad del equipo de desarrollo, pídeles que te transfieran la propiedad. Si eso no es posible, entonces pídeles ayuda para crear una nueva cuenta y asegúrate de que la aplicación utiliza tu cuenta en lugar de la de ellos. Esto no debería requerir nada más que cambiar algunos ajustes de configuración para tu aplicación. No hace falta decir que debes asegurarte de que cada contrato de desarrollo protege tus intereses desde el primer día y garantiza una transición sin problemas, sin importar la situación.

Autoriza el Acceso

Con una sólida comprensión del ecosistema de tu aplicación y la propiedad de las diversas herramientas y servicios que utiliza, ahora puedes dar acceso completo al equipo entrante o miembro.

La mayoría de los servicios te permitirá añadir un colaborador a tu cuenta y otorgarle un determinado nivel de acceso. Está bien ser conservador en este caso, muchos fundadores, especialmente los empresarios individuales, prefieren dar a sus desarrolladores acceso de administrador a sus servicios y hacer que manejen todo. Esto tiene el efecto secundario de mantenerte fuera del circuito, que como hemos aprendido, puede hacer más difícil la transición en el futuro.

¿Deberías darle a tus desarrolladores privilegios completos de administrador? Es tu decisión, a la mayoría de las personas no parece importarles el uso de este enfoque. Sin embargo, siempre se debe planificar a futuro y asegurarse de que tu decisión no afecte negativamente a un nuevo equipo de desarrollo. De no hacerlo en las primeras etapas del proyecto puede tener consecuencias molestas en el futuro.

• 
• 
• 

Gestionando el traspaso

Ahora que has cubierto todas las bases, necesitas gestionar el traspaso de un equipo a otro. Estos son algunos consejos básicos para enfrentar tanto al equipo entrante como al de salida.

Equipo Entrante

• Establece expectativas - El nuevo equipo debe saber cuáles son tus objetivos más importantes para que puedan centrarse en la dirección correcta. La gestión de tus propias expectativas sobre lo que el nuevo equipo puede lograr de inmediato es igualmente importante.
• Realiza visitas de control a menudo - No dejes al nuevo equipo a su suerte. Debes hacer visitas de control con frecuencia para asegurarte de que tienen todo lo que necesitan, y que no se sientan como que tienen que valerse por sí mismos. Trata de hacer esto sin llegar a hacer micro gestión. Asegúrate de que sepan que estás para apoyar y ayudar si lo necesitan, pero no pongas presión innecesaria sobre ellos.
• Sé paciente - Se necesita tiempo para que los desarrolladores puedan adaptarse a una nueva base de códigos. Entiende que habrá un poco de tiempo de aprendizaje antes de que el nuevo equipo pueda igualar el ritmo del anterior.

Equipo Saliente

• Recolecta todo el código en circulación - Asegúrate de que todo el código fuente se haya registrado en el repositorio principal, y que sabes el estado de lo que se ha desplegado y lo que no. El nuevo equipo tendrá que saber exactamente dónde retomar y empezar a trabajar. Yo mismo he experimentado una situación en la que seguí el trabajo de un equipo que había desplegado código sin ponerlo en el repositorio principal. Esto llevó a que se crearan bugs, la duplicación de trabajo y dolores de cabeza que podrían haberse evitado fácilmente si el equipo saliente hubiera dejado el código fuente en un estado coherente.
• Actualiza el nivel de acceso - Si se separaron en buenos términos, es posible que desees mantenerlos con acceso a tu código y/o despliegue. Muchos equipos están dispuestos a ayudar durante la fase de transición, hasta que el nuevo equipo pueda asumir plenamente. Si no, considera cambiar o revocar el acceso para evitar cualquier problema accidental o conflictos con el nuevo equipo.
• Dales las gracias por su trabajo - Las transiciones pueden ser agitadas. Mientras estás ocupado con el nuevo equipo, no te olvides de agradecer a tu equipo saliente por su contribución al proyecto.

Conclusión

Cualquier transición en la vida puede dar miedo, lo cual trae la incertidumbre de si funcionará o no, el miedo a lo desconocido, y así sucesivamente. La transición a un nuevo equipo de desarrollo no es diferente, pero puedes y debes tomar medidas para que sea más fácil. En la mayoría de los casos, sólo se requiere un poco de planificación a largo plazo.

Tener un mayor conocimiento técnico y no técnico de tu producto de software, el proceso de desarrollo, y todas las cosas que entraron en el proceso ayudará a que cualquier transición de un equipo a otro, sea tan tranquila y sin dolor como sea posible.

Lo mejor de todo: ¡Tu nuevo equipo te respetará y dará las gracias por estar preparado! Es probable que les ahorre tiempo y esfuerzo, lo que también significa que vas a ahorrar dinero. Además, cuanto más pronto el nuevo equipo se dé cuenta de la insistencia en un alto nivel profesional, mejor. Lo más probable es que continúen la implementación de estas prácticas una vez tomen el control del proyecto, por lo que la próxima transición será también sin problemas.

Así que vamos a revisar los puntos clave que deben preceder a cualquier transferencia de propiedad de tu producto de software:

• Recoger o crear la mayor documentación posible acerca de tu aplicación, el entorno de desarrollo y el proceso de despliegue.
• Conocer tu producto dentro y por fuera.
• Mantener el control de todos los servicios y dependencias de terceros de tu aplicación, y tener los nombres de usuario y contraseñas para todo.
• Esté preparado para darle a tu nuevo equipo acceso a todo lo que necesitan para empezar a funcionar.
• Sé proactivo y no dejes nada al azar, o para el equipo de desarrollo de salida.

Este articulo fue escrito por Carlos Ramirez III. Originalmente publicado en Toptal.