¿Cómo ayudas a tus compañeros programadores a crecer?

Como líder de equipo, ¿cómo puedes ayudar a tus programadores a crecer?

La razón por la que pregunto esto es porque hay algunos programadores que trabajan conmigo, y realmente quiero "liberarlos", para alcanzar su máximo potencial y mantenerlos contentos.

Pero no sé cómo hacer esto, ¿tengo que

1. ¿Interactúa con ellos con frecuencia, o les da tiempo de tranquilidad, los deja sin ser molestados?
2. ¿Pedirles que sigan las pautas de codificación, como imponer pruebas unitarias, estilos de codificación, o dejar que hagan lo que les parezca?
3. Sé indulgente con ellos. ¿Por ejemplo, si realmente no les importa si realmente asumen el cargo durante 8 o 4 horas, o si necesitan imponer algunas "disciplinas" en el lugar de trabajo?

Adivina qué, cada posición tiene sus propios puntos, y diferentes personas argumentan por diferentes cosas. Tales confusiones hacen que la gestión de personas sea indefinidamente más difícil.

¿Qué piensas?

Es una línea muy fina que tienes que caminar.

Al final, cualquier decisión técnica que tome son decisiones con las que no tendrá que vivir. Así que haga el menor número posible de ellos, deje que las personas que tienen que vivir con ellos tomen sus propias decisiones. Pero guíelos si cree que van por un mal camino.

Por otro lado, las opciones de proceso son suyas. En esas decisiones, deja que el equipo te guíe, pero finalmente debes tomarlas. Al menos al principio.

Lea las tres etapas de madurez de Roy Osherove de un equipo de software y vea si puede averiguar en qué etapa se encuentra su equipo actualmente. Esto debería afectar tu forma de actuar. Cuanto más caótico, más tienes que poner los controles en su lugar. p.ej. En un equipo extremadamente caótico, debe comenzar por revisar todo el código comprometido. Pero mientras lo hace, tómese el tiempo para enseñarles a revisar el código de los demás.

Y si logras llevar a un equipo de Chaos a Midlife, cambia tu comportamiento en ese punto, de lo contrario no avanzarán más (esto último por experiencia personal).

Sí, administrar personas es indefinidamente más difícil que administrar computadoras o software, precisamente porque cada persona es diferente y podemos cambiar incluso día a día. Entonces no hay una respuesta universal. Creo que solo necesita comunicarse mucho con sus desarrolladores para conocerlos y comprender sus fortalezas / debilidades individuales, su actitud hacia el trabajo y el aprendizaje, etc. De este modo, puede aprender sobre cada uno de ellos, si prefiere mucha comunicación y talleres, o aprender por su cuenta en un rincón tranquilo.

Los desarrolladores de la OMI en circunstancias normales tienen un impulso natural de aprender (a menos que hayan sido quemados o agotados por una mala experiencia laboral previa). Entonces, todo lo que necesita hacer es comprender qué y cómo les gustaría aprender, y proporcionarles las herramientas y el tiempo para hacerlo (dentro de límites razonables, por supuesto).

Por ejemplo, en nuestro equipo, podemos definir libremente las tareas de aprendizaje para nosotros mismos, siempre que estén de alguna manera (directa o indirectamente) relacionadas con el proyecto. Estas tareas suelen ser de unas pocas horas a un día por sprint (aunque no en todos los sprints). (Un ejemplo reciente: obtuve una tarea para aprender y experimentar con Scala aceptado, sobre la base de que esto, y un enfoque funcional en general, podría ayudar a simplificar una parte compleja de nuestro código Java). Luego, estos se priorizan y se programan en un Sprint, al igual que las tareas regulares. También se alienta y se espera que realice demostraciones / conferencias sobre lo que aprendimos, para transferir conocimiento a otros miembros del equipo (y potencialmente incluso a desarrolladores en diferentes equipos).

¿Pedirles que sigan las pautas de codificación, como imponer pruebas unitarias, estilos de codificación, o dejar que hagan lo que les parezca?

Cuando se trabaja en equipo, es imprescindible seguir el mismo proceso de desarrollo. Por supuesto, ese proceso debería ser lo más simple que podría funcionar, no algo descrito en un manual de 600 páginas. Y el proceso debe ser definido y continuamente adaptado a la situación por el propio equipo . Entonces, si el equipo ha aceptado un estándar de codificación y TDD, deben seguirlo.

Sé indulgente con ellos. ¿Por ejemplo, si realmente no les importa si realmente asumen el cargo durante 8 o 4 horas, o si necesitan imponer algunas "disciplinas" en el lugar de trabajo?

Si no conoce a un desarrollador, es normal seguir más de cerca lo que está haciendo, sus entregas, su ritmo de trabajo, etc. También está bien revisar su código (ya sea usted mismo o un equipo experimentado y confiable miembro). Una vez que se ha ganado la confianza, gradualmente puede obtener más libertad. Pero esa confianza debe ganarse primero. En cuanto a las horas de trabajo, en mi experiencia, las horas flexibles son excelentes hasta un límite, es decir, es bueno tener un mínimo común acordado, como diariamente entre las 11 a.m. y las 2 p.m., cuando los desarrolladores se encuentran (generalmente) en su lugar de trabajo, para que puedan puede ser abordado con preguntas o invitado a reuniones. Pero aparte de eso, no tiene sentido ser estricto.

OK como guía, es su trabajo sacar los proyectos por la puerta. Por lo tanto, debe ser quien haga cumplir los estándares, las revisiones de código, solicite informes de progreso y todas esas cosas cuando los desarrolladores prefieran que los deje en paz. Estas cosas son solo requisitos de la administración y, a excepción de las revisiones de código, no aumentan las habilidades de los empleados.

Sin embargo, desea ayudarlos a crecer, lo cual es un gran atributo en un líder.

Las revisiones de código son sin duda un primer paso, te ayudarán a ver quién tiene menos habilidades estelares y necesita mejoras para tener incluso un rendimiento satisfactorio. Ayudarán a los desarrolladores a ver otras formas de hacer las cosas y comprender diferentes partes de la base del código en las que trabajaron personalmente. En mi opinión, las revisiones de código se realizan mejor en persona en una sala de conferencias con el desarrollador y el revisor (que debería ser otro desarrollador cuando sea posible, no siempre el líder, revisar el código de otro también es una habilidad que debe desarrollarse) y usted como Un moderador. Debe mantener notas sobre lo que se debe cambiar para identificar tendencias. Lo que realmente está buscando no son errores o cambios (se puede mejorar el código de todos), sino un fracaso constante para aprender de los errores. No le digas a la alta gerencia que estás guardando estas notas o te verás obligado a usarlas como medidas en el proceso de evaluación del desempeño que francamente frustra el propósito. Si varios desarrolladores están cometiendo los mismos errores, una sesión de entrenamiento o una entrada wiki sobre cómo hacer X puede estar en orden.

Ahora hacia el vicio creciente llegando al nivel mínimo. Primero, necesita saber qué conjuntos de habilidades tienen los desarrolladores y qué conjuntos de habilidades sería útil que tuvieran y qué podrían estar interesados ​​en conocer. Debe hablar con ellos y revisar sus currículums y comprender lo que les gusta y no me gusta hacer

No le dé todas las tareas interesantes solo a los más hábiles. Eso no ayuda a los demás a ponerse al día sobre nuevos problemas y tecnologías. No puedes pasar de ser el chico más joven que solo realiza las tareas más pequeñas y menos importantes al chico mayor a menos que alguien se arriesgue y te asigne un trabajo más difícil. Dicho esto, los menos experimentados pueden necesitar ser asignados primero para emparejar el programa con un senior para obtener habilidades más avanzadas. La inclusión de los juniors en las revisiones de códigos también los expondrá a técnicas más avanzadas.

Primero deles la oportunidad de resolver el problema por sí mismos. Pero a veces las personas están estancadas y no saben por dónde comenzar (una habilidad que también necesita desarrollar, especialmente en los nuevos programadores) o qué hacer para resolver un problema.

Si les das un par de días para investigar algo y todavía no tienen una dirección sobre cómo van a hacer algo, entonces es posible que debas intervenir con algunas sugerencias. Si usted es técnico, puede darles algunas ideas sobre cómo resolver el problema. De lo contrario, una reunión con varias personas en las que se intercambian ideas puede ayudar si la persona está estancada. O pedirle a una persona con más experiencia que le dé algunas sugerencias. Lo que no quiere hacer es quitarles el problema y resolverlo usted mismo. Pero debe equilibrar la realización del proyecto con el ego del programador y, a veces, debe enviarlos en una dirección específica. Si tiene una mala solución y necesita ser reparada, lo peor que puede hacer es dársela a otra persona a menos que tenga la intención de despedir al programador.

He visto a malos programadores mimados, donde alguien más tiene que arreglar casi todo lo que hacen. Los otros programadores resienten esto y solo quieren a la persona fuera de sus vidas. Mimar a un mal programador hace que los buenos programadores se vayan. Tienes que encontrar la línea entre mimar y desarrollar habilidades. Si le das a alguien varias oportunidades y él o ella nunca mejora, entonces libéralo.

Para las personas mayores que ya son competentes en sus habilidades actuales, las cosas son más fáciles. Por lo general, solo tiene que darles la oportunidad de hacer algo nuevo y ellos intervienen y lo aprenden. Solo asegúrate de que las oportunidades interesantes se difundan y no todos vayan al programador Joe the Wonder que puede arreglar cualquier cosa. Quiere terminar con diez Joes, no solo uno.

Otra forma de desarrollar habilidades es tener una sesión de entrenamiento semanal de 1 hora. Haga que cada desarrollador sea responsable de un tema en particular. Esto los ayudará a mejorar en la comunicación, les hará investigar algo en profundidad y les dará a todos el beneficio de su investigación. Algunos temas deben asignarse a personas que no están familiarizadas con el tema para obligarlos a desarrollar un poco de conocimiento en ese tema y otros deben asignarse a personas que saben que son los expertos locales en ese tema. Los temas deben ser una combinación de cosas en las que necesita que las personas sean buenas en el futuro cercano o en este momento y una cierta cobertura de las nuevas tecnologías futuras que no utiliza en este momento, pero las personas están interesadas en aprender para ver si pueden ser útiles. Pero a todos, incluso a los más jóvenes, se les debe asignar un tema.

Dependiendo de cómo se factura el tiempo de sus desarrolladores (esto es más difícil en una situación de facturación del cliente), generalmente vale la pena que los desarrolladores tengan de 4 a 8 horas a la semana para trabajar en proyectos personales. Estarán emocionados de hacer esto. Las mejores personas querrán trabajar allí y aprenderán muchas cosas que serán útiles para el futuro. Es difícil para los contadores de frijoles entender la necesidad de esto, pero esta vez se pagará muchas veces en satisfacción de los empleados, nuevas funciones o software que nadie requirió (o que ayudarán a automatizar parte del trabajo pesado) y un desarrollo más rápido debido a Nuevas técnicas aprendidas. Algunos desarrolladores usarán este tiempo estrictamente para proyectos personales que no están relacionados con lo que haces (y eso es bueno, seguirán adquiriendo habilidades y contentos por la oportunidad), pero muchos otros lo usarán para resolver problemas persistentes que, debido a la naturaleza de cómo se gestionan los proyectos, nadie tuvo tiempo de arreglarlo de antemano. Entonces puede obtener refactorizaciones que beneficien a todos; algunas personas pueden escribir pruebas para mejorar la cobertura de las pruebas y facilitar la refactorización; otros pueden explorar algunas características nuevas que pueden hacer que su software sea más útil para sus clientes. En general, si puede persuadir a los contadores de frijoles, no hay forma de perder permitiéndoles esta libertad.

Tienes que aprender a equilibrar, dejando que las personas tengan un poco de tensión para sus habilidades y mantener el proyecto en marcha. Cuanto menos experiencia tenga el desarrollador, más alguien necesita verificar el progreso, especialmente en las primeras etapas, cuando cambiar de dirección es más fácil. Los inexpertos pueden luchar y tener miedo de hablar. Estas personas tienden a irse justo antes del lanzamiento y descubres que su parte del proyecto no está cerca de completarse. Tenga especial cuidado de verificar el progreso de cualquier persona que haya cambiado de trabajo con frecuencia (a menos que fuera un contratista, ya que esa es la naturaleza de la contratación).

Por lo general, se puede confiar en que los más experimentados le informarán cuando tengan problemas para encontrar la solución y necesiten ayuda de alguien con más conocimiento en el área o buscarán a esa persona y obtendrán la transferencia de conocimiento. Por lo tanto, no necesitan ser monitoreados tan de cerca en las fases iniciales del aprendizaje de un nuevo conjunto de habilidades para un proyecto. Encontrarán una manera de entregar el proyecto. Aquellos que tienen un historial de entrega generalmente se pueden dejar solos, excepto por los informes de progreso mínimos (por lo general, también debe informar a su gerencia y, por lo tanto, necesita algo de información).

1. Dé a su equipo un trabajo desafiante y las herramientas para resolverlos. Incluso si ve su trabajo como mundano porque solo está apoyando un sistema heredado, presione a todos para que lo mejoren.
2. Su equipo debe desarrollar estándares de codificación. Su trabajo es ayudarlos a hacer cumplir y adaptar los estándares.
3. Trabaje con su equipo para desarrollar un sistema de estimación. Su trabajo es ayudar a coordinar este esfuerzo con el equipo y proporcionar cumplimiento. Las fuerzas externas esperan un código de calidad de manera oportuna y no siempre tienen una lógica razonable o proporcionan ninguna lógica para sus solicitudes. No puedes escapar de esto, pero debes manejar ambos lados. Una vez que su equipo haya construido una reputación de hacer las cosas, todos aceptarán más sus estimaciones de tiempo. Necesitan saber que los apoyará si están haciendo el esfuerzo.

Cuando digo que su trabajo es imponer, no me refiero a adoptar algún tipo de estilo de liderazgo draconiano. Cuando un grupo de personas capaces tienen opiniones sobre cómo se van a comportar, también deben aceptar las consecuencias por no seguir las reglas. Al final, alguien está a cargo y como eres el líder de ese equipo, eres tú.

¿Interactúa con ellos con frecuencia, o les da tiempo de tranquilidad, los deja sin ser molestados?

Interactúa con ellos con frecuencia. Obviamente, no es el punto de molestarlos, pero como su gerente, debería tener conversaciones regulares con ellos sobre cómo van las cosas y una conversación más general. Aproximadamente una vez cada pocas horas suena la frecuencia correcta, pero tóquela de oído.

¿Pedirles que sigan las pautas de codificación, como imponer pruebas unitarias, estilos de codificación, o dejar que hagan lo que les parezca?

Debe esperar que trabajen exactamente con los mismos estándares que usted. Si realiza pruebas unitarias y sigue las pautas, entonces deberían hacerlo. Necesitan aprender a codificar bien y es su responsabilidad enseñarles eso.

Sé indulgente con ellos. ¿Por ejemplo, si realmente no les importa si realmente asumen el cargo durante 8 o 4 horas, o si necesitan imponer algunas "disciplinas" en el lugar de trabajo?

Al principio estaría más disciplinado, pero me tranquilizaría cuando demuestren que se puede confiar en ellos. Darle a la gente la confianza para trabajar un día de 4 horas desde el principio es pedir problemas, sin embargo, dejar que un empleado valioso que trabaja regularmente tarde tenga cierta holgura entre los proyectos está bien.

Relacionado con tus tres puntos:

¿Interactúa con ellos con frecuencia, o les da tiempo de tranquilidad, los deja sin ser molestados?

Diré que realmente depende del tipo de persona con la que trabajas. Algunos prefieren discutir a la hora fija del café (alrededor de las 10 a.m., por ejemplo) y trabajar solos, sin ser molestados. Con ellos (OK, lo admito, soy exactamente así), generalmente envío correos electrónicos (incluso cuando están cerca de mí, a unos 2-3 metros de distancia) para que pueda dejarles la opción cuando lean su información . Y, por cierto, no les pregunte si "recibieron su memo" :-) Y, por supuesto, algunos "necesitan" más orientación, más interacción.

¿Pedirles que sigan las pautas de codificación, como imponer pruebas unitarias, estilos de codificación, o dejar que hagan lo que les parezca?

En cuanto a las siguientes pautas, es bastante claro para mí. Si establece directrices relacionadas con el estilo de codificación, siempre proporcionar la prueba de los casos regla, etc entonces usted tiene que hacerlas cumplir si usted es el desarrollador principal. Para el proyecto que está administrando, cada desarrollador debe seguir sus pautas, sin excepción, incluso para las " superestrellas ".

Sé indulgente con ellos. ¿Por ejemplo, si realmente no les importa si realmente asumen el cargo durante 8 o 4 horas, o si necesitan imponer algunas "disciplinas" en el lugar de trabajo?

Si ya sabe cómo trabaja la gente y está seguro de que no romperá su confianza, puede relajar la disciplina. Pero creo que para este punto, la regla (o no regla) que defina debería aplicarse a todos. Lo importante es que no debería haber ninguna excepción. Actualmente estoy muy contento de trabajar para un gerente de proyecto que simplemente dice "mientras hagas tus 40 trabajos por semana y el trabajo esté hecho, está bien". De esa manera, puede llegar tarde una mañana, trabajar solo 6 horas y los próximos dos días trabajar durante 9 horas. No importa "mientras el trabajo esté terminado". Me gusta esa regla

Diría que la cantidad de experiencia (no solo de programación, sino también en entornos empresariales) que tienen sus desarrolladores es un elemento clave en la cantidad de tiempo que pasan con ellos. Actualmente estoy trabajando con algunos desarrolladores que acaban de salir de la escuela, y descubro que necesitan más orientación sobre cómo trabajar con otros, no solo en la documentación / prueba / estándares, sino también en formas interpersonales (cuándo llamar por teléfono o reunirse en persona, en lugar de simplemente enviar correos electrónicos). El conocimiento de nuestro negocio también es algo clave para aprender, ya que muchas de las mismas palabras se usan de manera muy diferente en nuestro contexto comercial que en un contexto de desarrollo de software. Y esto es antes de llegar a las siglas ...

Pero no sé cómo hacer esto, ¿tengo que

1. ¿Interactúa con ellos con frecuencia, o les da tiempo de tranquilidad, los deja sin ser molestados?
2. ¿Pedirles que sigan las pautas de codificación, como imponer pruebas unitarias, estilos de codificación, o dejar que hagan lo que les parezca?
3. Sé indulgente con ellos. ¿Por ejemplo, si realmente no les importa si realmente asumen el cargo durante 8 o 4 horas, o si necesitan imponer algunas "disciplinas" en el lugar de trabajo?

Mi sugerencia es tener algunas conversaciones sobre qué estilo funciona mejor para ese ajuste individual y fino con el tiempo. Algunas personas pueden querer reunirse una vez al día para revisar cómo van las cosas, mientras que otras pueden considerar que una vez por trimestre es excesivo. Algunas personas pueden querer una evaluación de desempeño formal por escrito todos los meses y otras pueden simplemente querer hablar sobre el desempeño. La clave es llevar la relación al escenario donde puede ser honesto sobre lo que funciona y lo que no funciona para alguien.

La otra cara de esto sería estudiar filosofías de desarrollo personal, aunque esto puede ser un camino complicado si alguien se analiza incorrectamente. Si desea algunos ejemplos de tales filosofías, puede consultar Myers-Briggs, Eneagram y Strengths Finder 2.0 para ver algunos ejemplos.

Les preguntas cómo preferirían trabajar.
Lo que les gustaría cambiar, etc.

No todos a la vez. Solo ... como aparecen las cosas.
Mantente natural (o olerán miedo)

Y luego ... incluso puedes aprender cosas de ellos . Si no crees que ese sea el caso, (demasiada distancia en educación y experiencia) realmente no te molestas en tratar de hacerlos crecer, solo los confundiría.

(En ese caso especial, ríndete y gobierna con puño de hierro , es más honesto que fingir interés que no tienes en ellos)

Establecer un proceso democrático , votar, discutir temas.

Como todos los presidentes, mantienes la última palabra: el veto .
El resto depende del grupo.

Una forma de ayudar a su gente a crecer es dejar que hagan lo que mejor hacen.

Si tiene suerte, tendrá uno o dos programadores cuyos estándares de "pruebas" personales son más estrictos que los del departamento en general. En ese caso, puede colocarlos en el "sistema de honor" para esos problemas, o incluso adoptar sus métodos.

Con el "tiempo flexible", puede permitirse un mayor margen de maniobra para sus trabajadores más productivos. Mientras estén haciendo el trabajo, me preocuparía menos por sus horas. Algunas personas entran, pasan entre 5 y 6 horas "sin parar" y logran más que otras que hacen 10 horas de ritmo lento.

Pero uno de sus trabajos como gerente es corregir DEBILIDADES. Es decir, tendrá que TENER EN CUENTA a los programadores descuidados cuyos estándares de prueba son inadecuados o las personas que no son lo suficientemente productivas, porque no están demorando el tiempo.