Mantenga la calma y haga la transición a un nuevo equipo de desarrollo

Publicado: 2022-03-11

Es común que un producto de software pase de un equipo de desarrollo a otro durante su vida útil. Las diferentes etapas del producto pueden requerir un tipo diferente de equipo de desarrollo: una consultoría para construir la versión inicial, un desarrollador autónomo independiente para mantenerlo, un equipo interno para llevarlo a escala o un diseñador profesional para agregar algo. música pop".

A pesar de la frecuencia con la que esto ocurre, muchos fundadores y propietarios de productos no técnicos se encuentran desprevenidos y luchando cuando llega el momento de incorporar al siguiente equipo. Esto a menudo resulta en una incapacidad para que el nuevo equipo progrese rápidamente, pérdida de tiempo y frustración para todos los involucrados.

Si esto suena como si pudieras ser tú, ya sea ahora o en el futuro, entonces deberías estar algo preocupado. Afortunadamente, vamos a repasar los pasos que puede seguir para prepararse para esta eventualidad y hacer que la transición sea lo más fluida posible.

Pasar la antorcha: incorporación de un nuevo equipo de desarrollo

En este artículo, le proporcionaré una lista de verificación de elementos que lo ayudarán a prepararse para tal cambio. Conocerá su producto a un nivel más íntimo y obtendrá un mayor control sobre todos los diversos servicios y tecnologías que intervienen en su fabricación, lo que le permitirá incorporarse a un nuevo equipo con confianza y relativa facilidad.

¿Pasar la antorcha a los nuevos desarrolladores? Asegúrate de que el nuevo equipo no se queme y no pierdas el tiempo apagando incendios.

¿Pasar la antorcha a los nuevos desarrolladores? Asegúrate de que el nuevo equipo no se queme.
Pío

Pero, ¿y si no estás reemplazando a todo el equipo? ¿Deberías molestarte en leer esto?

Incluso si parte del equipo anterior permanece a bordo, es posible que no tengan todas las respuestas y la información necesarias para una transición sin problemas. Si bien pueden brindar continuidad y ayudar en el proceso de transferencia de conocimientos del antiguo equipo al nuevo, depender de los miembros del equipo en funciones no reemplaza el hecho de que el propietario del producto se haga cargo y facilite la transferencia. Además, no hacerse cargo puede causar fricciones entre los antiguos y los nuevos miembros del equipo, o sobrecargar a los antiguos miembros del equipo con tareas innecesarias, obligándolos a perder demasiado tiempo comunicándose con los nuevos miembros del equipo y resolviendo varios problemas.

Aún así, si algunos miembros del equipo permanecen a bordo, pueden ser un activo invaluable en sus esfuerzos de transición. Consulte con ellos, manténgalos informados e intente aprovechar su experiencia sin abrumarlos con demasiadas tareas relacionadas con la transición. ¡No espere que ellos hagan todo el trabajo pesado! Ese es tu trabajo.

Entonces, sin más preámbulos, ¡vamos a sumergirnos!

Reunir documentación

A los desarrolladores independientes a menudo se les pide que salten a una base de código existente que nunca antes habían visto. Esto es especialmente cierto en el caso de los ingenieros de software de Toptal. Nuestro objetivo siempre es ponernos al día lo más rápido posible para que podamos comenzar a tener un impacto positivo para nuestros clientes.

Tener acceso a una documentación clara y completa sobre el proyecto puede acelerar drásticamente el proceso de incorporación y ayudar a los desarrolladores a evitar obstáculos que puedan impedir el progreso.

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

  • Configuración de un entorno de desarrollo : la primera tarea para cualquier recién llegado es poner en marcha la aplicación en sus propias computadoras. El proceso para hacerlo varía entre tecnologías. En general, requiere tareas como obtener el código fuente, configurar la base de datos, instalar dependencias, configurar el entorno con claves y credenciales API, importar datos de muestra, etc. Los desarrolladores tienen una buena idea de todo lo relacionado con este proceso dentro de sus respectivos campos y deberían poder ajustar los detalles en consecuencia.
  • Ejecutar el conjunto de pruebas automatizado : ver pasar las pruebas de una aplicación garantiza que todo se haya configurado correctamente y que los cambios futuros no rompan ninguna de sus funciones existentes.
  • Implementación en los servidores de ensayo y producción : la actualización de la aplicación en vivo con los cambios más recientes es un proceso altamente programado, y el orden de esas operaciones debe describirse paso a paso, tan detallado como sea posible.
  • Cualquier otra información que sea relevante para un desarrollador recién incorporado : cada aplicación tiene su propio conjunto de peculiaridades. Escribirlos ahorra a los equipos futuros una gran cantidad de esfuerzos de depuración de problemas que el equipo anterior ya ha descubierto cómo tratar.

Una buena documentación es la piedra angular de cualquier transición exitosa. Asegúrese de que su nuevo equipo tenga todo lo que necesita para hacerse cargo.

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

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

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

Si la escritura no es su punto fuerte, pídales que graben uno o más screencasts que demuestren la configuración, implementación, etc. del entorno de desarrollo. Hoy en día, incluso existen herramientas como Vagrant y Docker que permiten empaquetar entornos de desarrollo completos y distribuirlos a otros. En esencia, en lugar de darle instrucciones a alguien sobre cómo construir un martillo, entréguele el martillo mismo.

La prueba de fuego de cuán completa y efectiva es la documentación de un proyecto es cuán rápido un nuevo desarrollador puede configurar su entorno de desarrollo y ejecutar su aplicación.

Comprenda su producto

Tener una excelente documentación no lo exime de la necesidad de conocer los conceptos básicos de la tecnología de su propio producto. Como propietario de un producto de software, es su responsabilidad comprender su aplicación lo mejor que pueda, incluso si no es muy técnico.

¿Sin formación técnica? No hay excusa para no comprender correctamente los componentes básicos de su proyecto. Te podría costar caro.

¿Sin formación técnica? No hay excusa para no comprender correctamente los componentes básicos de su proyecto. Te podría costar caro.
Pío

Las siguientes preguntas son comunes y se espera que sepa las respuestas sin tener que buscarlas:

  • ¿Qué pila de tecnología utiliza su aplicación? - Hay muchos marcos de aplicaciones comunes para el back-end y el front-end, y cualquier nuevo equipo de desarrollo debe estar familiarizado con los que usa su aplicación. Algunos ejemplos de tecnologías web de back-end son Ruby on Rails, Node.js y Django. Algunos ejemplos de tecnologías web front-end son React.js, Angular.js y Ember.js.
  • ¿Dónde está alojado? - Diferentes servidores web tienen diferentes procesos de implementación, que requieren diferentes niveles de experiencia. En los últimos años, las tecnologías de la nube han creado una serie de nuevas opciones de alojamiento, y deberá identificar cuál en particular está utilizando y describir por qué se eligió sobre las demás.
  • ¿Cuál es el proceso de desarrollo? - ¿Su equipo utiliza una herramienta de gestión de control de código fuente en particular, como Git? Si es así, ¿cuál es el proceso mediante el cual se desarrolla, prueba, aprueba e implementa una nueva característica? El proceso debe estar estandarizado, debidamente documentado y fácil de replicar por parte de los recién llegados.
  • ¿Qué servicios de terceros utiliza su aplicación? - Algunas aplicaciones se basan en servicios de terceros, como Shopify. Tenga en cuenta que la dependencia de los servicios de terceros está aumentando gradualmente, e incluso si actualmente no usa ningún servicio adicional, su proyecto puede decidir emplear un servicio de terceros más adelante.
  • ¿En qué plataformas se puede ejecutar su aplicación? - ¿Es su aplicación una aplicación de escritorio, una aplicación web, un sitio web móvil receptivo, una aplicación nativa de iOS, una aplicación nativa de Android o cualquier otra cosa? ¿Se ejecuta en varias plataformas diferentes? ¿Qué plataforma es su prioridad en un momento dado? ¿En qué plataforma es más fuerte y más débil su producto? Asegúrese de conocer todos los detalles de las plataformas actuales de su aplicación, e incluso en cuáles se puede expandir.

Tomar posesión

El proceso de desarrollo de software actual utiliza una gran cantidad de servicios y herramientas de terceros. Ya sea que lo sepa o no, su aplicación no es una excepción.

Durante el transcurso del desarrollo, es posible que su equipo anterior se haya registrado en su nombre o incluso haya utilizado sus propias cuentas para obtener acceso a los servicios que se necesitaban. La transición a un nuevo equipo significa que debe tomar posesión y tener el control de cada uno de los servicios y herramientas en los que se basa su aplicación para que pueda otorgar acceso a su nuevo equipo sin necesidad de pasar por un intermediario o perseguir a los desarrolladores originales.

La siguiente es una lista de las diversas herramientas o servicios externos que su aplicación podría utilizar:

  • Gestión de control de código fuente : 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 blogs : WordPress, Tumblr, Ghost
  • Soluciones de comercio electrónico - Shopify, Squarespace
  • Análisis / Seguimiento - Google Analytics, Mixpanel, Kissmetrics
  • Marketing por correo electrónico: MailChimp, contacto constante

Pregúntele a su equipo de desarrollo saliente cuáles son aplicables. Para cualquier servicio que sea propiedad del equipo de desarrollo, pídales que le transfieran la propiedad. Si eso no es posible, pídales que lo ayuden a crear una nueva cuenta propia y asegúrese de que la aplicación use su cuenta en lugar de la de ellos. Esto no debería requerir nada más que cambiar algunos ajustes de configuración para su aplicación.

No hace falta decir que asegúrese de que cada contrato de desarrollo proteja sus intereses desde el primer día y asegure una transición sin problemas, pase lo que pase.

Autorizará el acceso

Con una sólida comprensión del ecosistema de su aplicación y la propiedad de todas las diversas herramientas y servicios que utiliza su aplicación, ahora puede proporcionar acceso completo al equipo o individuo entrante.

La mayoría de los servicios le permitirán agregar un colaborador a su cuenta y otorgarle un nivel particular de acceso. Está bien ser conservador aquí . muchos fundadores, especialmente los empresarios individuales, prefieren dar a sus desarrolladores acceso completo de administrador a sus servicios y que ellos se encarguen de todo. Esto tiene el efecto secundario negativo de mantenerlo al margen, lo que, como hemos aprendido, puede dificultar la transición en el futuro.

¿Debería otorgar a sus desarrolladores privilegios de administrador completos? Es su decisión, y la mayoría de las personas no tienen problemas con este enfoque. Sin embargo, siempre debe planificar con anticipación y asegurarse de que su decisión no afecte negativamente a un nuevo equipo de desarrollo. No hacerlo en las primeras etapas del proyecto puede tener consecuencias molestas en el futuro.

Administrar el traspaso

Ahora que tiene todas las bases cubiertas, deberá administrar el traspaso de un equipo al siguiente. Aquí hay algunos consejos básicos para tratar tanto con el equipo entrante como con el saliente.

Asegúrese de administrar adecuadamente los aspectos técnicos y personales de la entrega de su proyecto. Haga que su nuevo equipo se sienta como en casa y no se enoje con su antiguo equipo.

Asegúrese de administrar adecuadamente los aspectos técnicos y personales de la entrega de su proyecto. Haz que tu nuevo equipo se sienta como en casa.
Pío

Equipo entrante

  • Establezca expectativas : el nuevo equipo debe saber cuáles son sus objetivos más importantes para poder enfocarse en la dirección correcta. Manejar sus propias expectativas sobre lo que el nuevo equipo puede lograr de inmediato es igualmente importante.
  • Regístrese con frecuencia : no deje que el nuevo equipo se hunda o nade. Desea verificar con frecuencia para asegurarse de que tengan todo lo que necesitan y no sientan que necesitan valerse por sí mismos. Trate de hacer esto sin microgestión. Asegúrese de que sepan que usted está allí para apoyarlos y ayudarlos si lo necesitan, pero no los presione innecesariamente.
  • Sea paciente : a los desarrolladores les lleva tiempo acostumbrarse a una nueva base de código. Comprenda que habrá algún tiempo de aprendizaje antes de que el nuevo equipo pueda igualar el ritmo del anterior.

Equipo saliente

  • Recopile todo el código pendiente : asegúrese de que todo el código fuente esté registrado en el repositorio principal y de que conoce el estado de lo que se ha implementado o no. El nuevo equipo necesitará saber exactamente dónde recoger y comenzar a trabajar. Yo mismo experimenté una situación en la que asumí el control de un equipo que había implementado código sin ponerlo en el repositorio principal. Esto dio lugar a errores, trabajo duplicado 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.
  • Actualice su nivel de acceso : si se separaron en buenos términos, es posible que desee dejarles acceso a su código y/o implementación. Muchos equipos están felices de ayudar durante la fase de transición hasta que el nuevo equipo pueda hacerse cargo por completo. De lo contrario, considere degradar o revocar el acceso para evitar problemas accidentales o conflictos con el nuevo equipo.
  • Agradézcales por su trabajo . Las transiciones pueden ser agitadas. Mientras está ocupado tratando con el nuevo equipo, no olvide agradecer a su equipo saliente por su contribución a su proyecto.

Conclusión

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

Tener una mayor comprensión técnica y no técnica de su producto de software, el proceso de desarrollo y todas las cosas que intervinieron en el proceso ayudará a que cualquier transición de un equipo al siguiente sea lo más fluida y sencilla posible.

¡Lo mejor de todo es que su nuevo equipo lo respetará y le agradecerá por estar en la cima de su juego! Es probable que les ahorre tiempo y esfuerzo, lo que también significa que ahorrará dinero. Además, cuanto antes se dé cuenta el nuevo equipo de insistir en altos estándares profesionales, mejor. Lo más probable es que continúen implementando estas prácticas una vez que se hagan cargo del proyecto, haciendo que la próxima transición también sea fluida.

Entonces, repasemos los puntos clave que deben preceder a cualquier transferencia de propiedad de su producto de software:

  • Recopile o cree toda la documentación que pueda sobre su aplicación, el entorno de desarrollo y el proceso de implementación.
  • Conoce tu producto por dentro y por fuera.
  • Mantenga el control de todos los servicios y dependencias de terceros de su aplicación, y tenga los nombres de usuario y contraseñas para todo.
  • Esté preparado para darle a su nuevo equipo acceso a todo lo que necesita para ponerse en marcha.
  • Sea proactivo y no deje nada al azar, o al equipo de desarrollo saliente.
Relacionado: Cómo no administrar su equipo remoto de desarrolladores