Guarda la calma y transiciona a un nuevo equipo de desarrollo

Post escrito originalmente por Carlos Ramirez en Toptal

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.

Al pasar la antorcha a los nuevos desarrolladores, asegúrese de que el nuevo equipo no se queme.

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.

 

Una buena documentación es la piedra angular de cualquier transición exitosa. Asegúrate de que tu nuevo equipo tiene todo lo que necesita.

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.

 
¿Sin antecedentes técnicos? No hay excusa para no comprender adecuadamente los componentes básicos de tu proyecto. Te puede costar muy caro.

• ¿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.


 
Asegúrate de administrar adecuadamente los aspectos técnicos y personales de tu traspaso de proyecto. Permite que tu nuevo equipo se sienta como en casa.

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.