Guarda la Calma y Transiciona a un Nuevo Equipo de
Desarrollo
This article was originally written in English
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.
¿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.
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:
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.
Artículo via Toptal
No hay comentarios.:
Publicar un comentario
Bienvenido a nuestro blog, para nosotros es un gusto que comente nuestro material