Cel: +52 (55) 3040-5403 Correo: mariana.velazquez@recluit.com
post-tittle

Técnicas de trabajo en equipo para mejorar como desarrollador

Por: Reclu IT

9 de mayo de 2022

Los desarrolladores ambiciosos de nivel junior y medio invierten tiempo en el crecimiento profesional para subir de nivel y pasar a proyectos más desafiantes y gratificantes: leen libros, artículos, hacen cursos y tutoriales.

Sin embargo, a menudo pasan por alto algunas de las oportunidades de desarrollo que están disponibles en su equipo y trabajo actual. Eso es común entre los desarrolladores en las primeras etapas de su carrera: no tienen suficiente experiencia para reconocer todas las oportunidades disponibles. Como resultado, pierden un tiempo precioso que podría haberse dedicado a mejorar sus habilidades para pasar a un nuevo rol antes.

Dichos desarrolladores suelen trabajar en equipos con colegas más experimentados cuyo conocimiento, a veces acumulado durante décadas, está fácilmente disponible para quienes saben cómo extraerlo y absorberlo. Veamos algunas técnicas familiares que hacen que dicha transferencia de conocimiento dentro de un equipo sea eficiente.

Cada técnica mencionada aquí se basa en la colaboración y la cooperación, en otras palabras, en el trabajo en equipo. Eso los hace excelentes para transferir conocimientos explícitos e implícitos (o tácitos) sobre el producto, la organización y su industria de expertos a principiantes.

Revisiones de código

Para los desarrolladores junior, cualquier solicitud de extracción no trivial enviada por sus colegas es una oportunidad para explorar cómo otros resuelven problemas y qué patrones de diseño y técnicas de desarrollo utilizan según las circunstancias actuales. Es una oportunidad para hacer preguntas como:

  • ¿Por qué se seleccionó un enfoque particular para la implementación?
  • ¿Fue una elección aleatoria o deliberada?
  • ¿Cuál fue la razón detrás de esa acción?
  • ¿Qué otras opciones se pueden considerar en situaciones similares en el futuro?

Sugeriría ir aún más lejos con esta técnica y, ocasionalmente, revisar el código de los principales contribuyentes de proyectos populares de código abierto para obtener información sobre cómo se acercan los desarrolladores fuera de su organización y qué impulsa sus decisiones técnicas.

Cuantos más comentarios recibamos, más rápido aprenderemos, más mejoraremos nuestras habilidades de codificación y diseño, y menos problemas tendrán.

Otro beneficio de las revisiones de código como técnica de trabajo en equipo es que los desarrolladores revisan el código y abordan los comentarios a su propio ritmo. Eso es conveniente para los desarrolladores menos extrovertidos que encuentran prácticas como la programación en pareja y la realización de reuniones de equipo agotadoras o estresantes.

Programación en pareja

La programación en pareja es perfecta para observar y reproducir cómo los colegas experimentados resuelven problemas, crean cierto diseño o implementación, depuran código, solucionan problemas, usan herramientas de desarrollo, etc. Es ideal para transferir conocimiento tácito que no se puede escribir ni verbalizar.

La programación en pares también es una gran técnica para los tutoriales de código y la resolución de problemas complejos que requieren la cooperación de desarrolladores con experiencia en diferentes áreas.

Debes tener en cuenta que el emparejamiento puede ser agotador. Después de una intensa sesión de emparejamiento de dos horas, ¡incluso querrás tomar una siesta! Especialmente si tenías que conducir la mayor parte del tiempo y hablar un segundo idioma. Es por eso que puede ser más fácil ejecutar algunas sesiones de emparejamiento rápido en lugar de una sola más larga. El emparejamiento también puede ser costoso en términos de tiempo invertido. Aplicarlo para tareas triviales no es el mejor uso del tiempo de los desarrolladores.

A la hora de buscar pareja para una sesión hay que tener en cuenta la personalidad del candidato. Algunas personas simplemente no disfrutan mucho del emparejamiento. Algunos pueden ser tan extrovertidos y confiados que, sin siquiera darse cuenta, «secuestrarán» la sesión de emparejamiento e impondrán sus ideas sobre usted, lo que puede hacer que su papel sea demasiado pasivo. La brecha de conocimiento entre los socios de emparejamiento no debería ser demasiado grande.

Es genial cuando los desarrolladores se convierten en buenos socios de dos o tres de sus colegas. Eso ayuda con la transferencia de conocimientos y fortalece los lazos entre compañeros de equipo a nivel personal.

Solicitar y proporcionar comentarios

Antes de comenzar a trabajar en una tarea compleja, escribe un breve plan, compártelo con tus colegas y solicita su opinión. El propósito es validar las ideas, los planes y el diseño antes de comenzar la implementación, encontrar mejores opciones cuando sea posible y descubrir problemas potenciales con anticipación.

Los miembros del equipo a menudo estarían felices de compartir sus ideas con el autor del plan: es posible que deseen ayudar, tal vez solo sientan curiosidad o deseen mostrar cuán informados y experimentados son. De todos modos, sus comentarios pueden ser valiosos y pueden ahorrar días de reelaboración en el futuro.

Cuando un desarrollador necesita proporcionar comentarios sobre las sugerencias hechas por sus colegas, esta es otra oportunidad para ver cómo otros resuelven problemas, hacen preguntas y aprenden de eso de manera similar a las solicitudes de incorporación de cambios.

Es importante tener en cuenta que los comentarios pueden ser subjetivos. Tampoco debe tomarse como algo personal. Incluso cuando los comentarios se sienten demasiado negativos y desalentadores, lo más probable es que el revisor no haya tenido la intención de herir los sentimientos del autor y simplemente estaba criticando la propuesta.

Realización de reuniones de equipo

Muchos equipos de desarrollo de software tienen una rotación para realizar reuniones periódicas como standups, retros, demostraciones y sesiones de planificación de sprints. Cada reunión es una oportunidad para que la persona que la dirige fortalezca las conexiones con otros miembros del equipo, practique habilidades blandas que se vuelven cada vez más importantes en los puestos de alto nivel y aprenda a facilitar discusiones para lograr resultados significativos.

Si tu equipo no tiene tal rotación, considera pedirle a tu gerente la oportunidad de realizar algunas reuniones como una experiencia de aprendizaje. Lo más probable es que el gerente lo permita. Si tu gerente ha estado dirigiendo reuniones de equipo durante mucho tiempo, podría estar feliz de delegar esa responsabilidad a los miembros del equipo.

Después de realizar las primeras reuniones, pídele a tu gerente y a algunos de tus colegas comentarios sobre cómo fue la reunión, qué les gustó y qué cambiarían o mejorarían. Eso le revelará sus puntos ciegos y le dará una idea de lo que puede necesitar mejorar.

imagen: @DCStudio

Deja tu comentario

Tu dirección de correo electrónico no será publicada.

Campos obligatorios(*)
post-tittle

Técnicas de trabajo en equipo para mejorar como desarrollador

Por: Reclu IT

9 de mayo de 2022

Los desarrolladores ambiciosos de nivel junior y medio invierten tiempo en el crecimiento profesional para subir de nivel y pasar a proyectos más desafiantes y gratificantes: leen libros, artículos, hacen cursos y tutoriales.

Sin embargo, a menudo pasan por alto algunas de las oportunidades de desarrollo que están disponibles en su equipo y trabajo actual. Eso es común entre los desarrolladores en las primeras etapas de su carrera: no tienen suficiente experiencia para reconocer todas las oportunidades disponibles. Como resultado, pierden un tiempo precioso que podría haberse dedicado a mejorar sus habilidades para pasar a un nuevo rol antes.

Dichos desarrolladores suelen trabajar en equipos con colegas más experimentados cuyo conocimiento, a veces acumulado durante décadas, está fácilmente disponible para quienes saben cómo extraerlo y absorberlo. Veamos algunas técnicas familiares que hacen que dicha transferencia de conocimiento dentro de un equipo sea eficiente.

Cada técnica mencionada aquí se basa en la colaboración y la cooperación, en otras palabras, en el trabajo en equipo. Eso los hace excelentes para transferir conocimientos explícitos e implícitos (o tácitos) sobre el producto, la organización y su industria de expertos a principiantes.

Revisiones de código

Para los desarrolladores junior, cualquier solicitud de extracción no trivial enviada por sus colegas es una oportunidad para explorar cómo otros resuelven problemas y qué patrones de diseño y técnicas de desarrollo utilizan según las circunstancias actuales. Es una oportunidad para hacer preguntas como:

  • ¿Por qué se seleccionó un enfoque particular para la implementación?
  • ¿Fue una elección aleatoria o deliberada?
  • ¿Cuál fue la razón detrás de esa acción?
  • ¿Qué otras opciones se pueden considerar en situaciones similares en el futuro?

Sugeriría ir aún más lejos con esta técnica y, ocasionalmente, revisar el código de los principales contribuyentes de proyectos populares de código abierto para obtener información sobre cómo se acercan los desarrolladores fuera de su organización y qué impulsa sus decisiones técnicas.

Cuantos más comentarios recibamos, más rápido aprenderemos, más mejoraremos nuestras habilidades de codificación y diseño, y menos problemas tendrán.

Otro beneficio de las revisiones de código como técnica de trabajo en equipo es que los desarrolladores revisan el código y abordan los comentarios a su propio ritmo. Eso es conveniente para los desarrolladores menos extrovertidos que encuentran prácticas como la programación en pareja y la realización de reuniones de equipo agotadoras o estresantes.

Programación en pareja

La programación en pareja es perfecta para observar y reproducir cómo los colegas experimentados resuelven problemas, crean cierto diseño o implementación, depuran código, solucionan problemas, usan herramientas de desarrollo, etc. Es ideal para transferir conocimiento tácito que no se puede escribir ni verbalizar.

La programación en pares también es una gran técnica para los tutoriales de código y la resolución de problemas complejos que requieren la cooperación de desarrolladores con experiencia en diferentes áreas.

Debes tener en cuenta que el emparejamiento puede ser agotador. Después de una intensa sesión de emparejamiento de dos horas, ¡incluso querrás tomar una siesta! Especialmente si tenías que conducir la mayor parte del tiempo y hablar un segundo idioma. Es por eso que puede ser más fácil ejecutar algunas sesiones de emparejamiento rápido en lugar de una sola más larga. El emparejamiento también puede ser costoso en términos de tiempo invertido. Aplicarlo para tareas triviales no es el mejor uso del tiempo de los desarrolladores.

A la hora de buscar pareja para una sesión hay que tener en cuenta la personalidad del candidato. Algunas personas simplemente no disfrutan mucho del emparejamiento. Algunos pueden ser tan extrovertidos y confiados que, sin siquiera darse cuenta, «secuestrarán» la sesión de emparejamiento e impondrán sus ideas sobre usted, lo que puede hacer que su papel sea demasiado pasivo. La brecha de conocimiento entre los socios de emparejamiento no debería ser demasiado grande.

Es genial cuando los desarrolladores se convierten en buenos socios de dos o tres de sus colegas. Eso ayuda con la transferencia de conocimientos y fortalece los lazos entre compañeros de equipo a nivel personal.

Solicitar y proporcionar comentarios

Antes de comenzar a trabajar en una tarea compleja, escribe un breve plan, compártelo con tus colegas y solicita su opinión. El propósito es validar las ideas, los planes y el diseño antes de comenzar la implementación, encontrar mejores opciones cuando sea posible y descubrir problemas potenciales con anticipación.

Los miembros del equipo a menudo estarían felices de compartir sus ideas con el autor del plan: es posible que deseen ayudar, tal vez solo sientan curiosidad o deseen mostrar cuán informados y experimentados son. De todos modos, sus comentarios pueden ser valiosos y pueden ahorrar días de reelaboración en el futuro.

Cuando un desarrollador necesita proporcionar comentarios sobre las sugerencias hechas por sus colegas, esta es otra oportunidad para ver cómo otros resuelven problemas, hacen preguntas y aprenden de eso de manera similar a las solicitudes de incorporación de cambios.

Es importante tener en cuenta que los comentarios pueden ser subjetivos. Tampoco debe tomarse como algo personal. Incluso cuando los comentarios se sienten demasiado negativos y desalentadores, lo más probable es que el revisor no haya tenido la intención de herir los sentimientos del autor y simplemente estaba criticando la propuesta.

Realización de reuniones de equipo

Muchos equipos de desarrollo de software tienen una rotación para realizar reuniones periódicas como standups, retros, demostraciones y sesiones de planificación de sprints. Cada reunión es una oportunidad para que la persona que la dirige fortalezca las conexiones con otros miembros del equipo, practique habilidades blandas que se vuelven cada vez más importantes en los puestos de alto nivel y aprenda a facilitar discusiones para lograr resultados significativos.

Si tu equipo no tiene tal rotación, considera pedirle a tu gerente la oportunidad de realizar algunas reuniones como una experiencia de aprendizaje. Lo más probable es que el gerente lo permita. Si tu gerente ha estado dirigiendo reuniones de equipo durante mucho tiempo, podría estar feliz de delegar esa responsabilidad a los miembros del equipo.

Después de realizar las primeras reuniones, pídele a tu gerente y a algunos de tus colegas comentarios sobre cómo fue la reunión, qué les gustó y qué cambiarían o mejorarían. Eso le revelará sus puntos ciegos y le dará una idea de lo que puede necesitar mejorar.

imagen: @DCStudio

Deja tu comentario

Tu dirección de correo electrónico no será publicada.

Campos obligatorios(*)

Política de privacidad de www.recluit.mx

Para recibir la información sobre sus Datos Personales, la finalidad y las partes con las que se comparte,
contacten con el Propietario.