Carlos Ramirez III
Carlos is a professional software engineer specializing in the Ruby on Rails framework. He has worked with US tech companies for years.
Expertise
Experience
15 years
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.
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.
Carlos is a professional software engineer specializing in the Ruby on Rails framework. He has worked with US tech companies for years.
15 years
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.
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!
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:
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.
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.
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.
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.
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.
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.
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.
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:
Located in San Rafael, CA, United States
Member since December 6, 2014
Carlos is a professional software engineer specializing in the Ruby on Rails framework. He has worked with US tech companies for years.
15 years
World-class articles, delivered weekly.
World-class articles, delivered weekly.
Join the Toptal® community.