¿Cómo hacer mejores desarrolladores de software a partir de los que están por debajo del promedio?

Por lo que dice, ¿el problema es la atención a los detalles, la revisión y el aumento del alcance? Si bien los puntos que menciona anteriormente son útiles y brindan información, no le darán a su equipo el tipo de habilidades que necesitan para dominar los puntos de desarrollo que está planteando. Eso llega con el tiempo en la dirección correcta ( supongo que los recursos con los que está trabajando son relativamente jóvenes, aquí ).

También diría que, si bien es genial tener conocimiento de las diversas metodologías que menciona, podría ser confuso para el desarrollador en cuanto a en qué modo deberían operar. Por ejemplo, los comportamientos que esperaría de un programador. en un entorno scrum serían muy diferentes de los esperados en una metodología más rígida basada en ITIL. Tenga cuidado de no confundir o dar mensajes contradictorios.

¿Puedo sugerir algunas cosas que me han funcionado en el pasado? La clave de todos ellos es hacerlos regulares y fiables. La repetición enfatiza la importancia y también asegurará que el conocimiento se mantenga.

1. Trabajo en curso/revisión del alcance: una sesión semanal para revisar el trabajo de la semana, dónde está asignado y, lo que es más importante, relacionarlo con el alcance acordado. Esto brinda a los desarrolladores la vista general que necesitan, además de la dirección que limita su alcance. También muestra cómo lo que hacen interactúa con el trabajo de quienes los rodean. Grabe esa sesión para que las personas puedan volver a consultarla. La desventaja de esto es que la gente tiende a no gritar si el trabajo definido en esa sesión se completa antes de tiempo ;)
2. Revisión por pares: las personas aprenderán a prestar más atención a los detalles si se les anima a realizar revisiones periódicas del trabajo por parte de sus pares. Por lo general, creamos listas de verificación para entregables particulares para poner en marcha esto para los recursos que ya no alcanzan el estándar requerido (por ejemplo, errores comunes que se deben buscar en cada especificación técnica). Esto también debería comenzar a ayudarlo a reducir su participación con el tiempo a medida que mejoran.
3. Retroalimentación 360: la retroalimentación para cualquier persona debe ser instantánea para tener el mayor efecto y debe entregarse de manera constructiva. Es más fácil decirlo que hacerlo, y requiere cierto esfuerzo de su parte para estar dispuesto a ser directo. Sin embargo, sus desarrolladores, dependiendo de la cultura en la que se encuentren, pueden sentirse menos cómodos brindándole comentarios. Parte de hacer que esto funcione es permitirles hacerle saber cuáles son sus problemas. Se sorprendería de la frecuencia con la que hay otra razón para la falta de atención a los detalles y debería tratar de sacar esto de ellos para asegurarse de que su equipo sea más eficaz.

La primera pregunta que tengo para ti es qué punto de referencia estás usando para establecer el "promedio". Usted dice, 'la mayoría están por debajo del promedio'. Apuesto a que el rendimiento de su mayoría es su promedio. Además, apostaría a que su población de trabajadores encaja muy bien en la curva de rendimiento estándar, lo que significa que su MODA = Mediana = Media. No voy a entrar en esto para enseñarle estadísticas, sino para que vuelva a examinar sus expectativas y la vara con la que está midiendo el rendimiento. ¡Esto es absolutamente crítico! Porque si estás midiendo contra un palo falso, nunca conseguirás que tu equipo mejore; de hecho, puede tener consecuencias adversas.

Aquí está el trato, la curva de rendimiento y la distribución probabilística dicen que lo más probable es que tengas un equipo promedio con artistas individuales promedio. De vez en cuando, tendrás suerte, pero también tendrás mala suerte y fracasarás. Pero debe planificar suponiendo un desempeño promedio de sus habilitadores de capacidades humanas. Planificar asumiendo lo contrario dará como resultado un plan demasiado optimista e inalcanzable y no es mucho más que una ilusión.

Y dado que no puede elegirlos, debe aceptar el nivel de rendimiento que está obteniendo y crear controles de calidad internos para controlar los defectos y mejorar gradualmente el rendimiento con el tiempo. Tirar una tonelada de dinero para tratar de hacer un cambio bajo esta dinámica es un desperdicio. Cualquier señal que pueda ver puede ser nada más que estocástica, con una señal de regreso a la media (regresión a la media).

Dicho esto, los tres principales impulsores del rendimiento son el propósito, la autonomía y el dominio. Asegúrese de comprender cuáles son y comience a construir una cultura que los habilite. Si experimenta una causa especial en el bajo rendimiento, esto puede ayudar. (Hacer que su equipo lea un libro, por cierto, no facilita ninguno de estos tres).

Creo que lo más importante es responder a la pregunta de por qué es necesario mejorar a los desarrolladores. ¿Es porque quiere que el desarrollo se realice mejor y más eficientemente o quiere tener mejores desarrolladores que, por cierto, harán mejor el desarrollo? Si solo es el primero, entonces hay dos formas de lograrlo: a. Mejorar el rendimiento del equipo, que creo que es una tarea más fácil, muchas metodologías, tomemos SCRUM como ejemplo, podría ayudar en ese caso b. Mejorar el rendimiento de las personas, lo que aparentemente quieres hacer y lo que creo que es mucho más difícil.

Supongamos que desea lograr b.

En mi opinión, deberías empezar por asegurarte de que los propios desarrolladores sientan la necesidad de mejorar su forma de trabajar si ven que tu trabajo es mucho más fácil, si no es así, tienes que cambiarlo. Es muy difícil sugerir una forma de motivarlos, probablemente cada miembro del equipo esté motivado por un factor diferente. Seguro que no estoy convencido de que estén motivados porque se les paga más que justo, en muchas situaciones el dinero no lo es todo, muchas veces es responsabilidad, autorrealización, tener las cosas bajo control, una visión concreta y clara del futuro, etc. ..

Tener gente motivada para superarse tiene más de la mitad del trabajo hecho. Entonces, muchas de las técnicas mencionadas en otras respuestas deberían funcionar bastante bien. Desde mi perspectiva, los dos más importantes son: a) Comentarios frecuentes: provienen de la revisión por pares, la demostración de la aplicación, la reunión retrospectiva o cualquier otra reunión/discusión sobre lo que sucederá en el futuro y cómo podemos mejorarlo. b) Delegación de responsabilidad: inicialmente, usted puede ser el principal proveedor de comentarios, pero debería cambiar con bastante rapidez y el equipo mismo debería organizarse en torno a la superación personal. c) Slack: el aprendizaje es un proceso doloroso y se deben cometer muchos errores durante ese tiempo. Debe ser paciente y no debe exigir un alto rendimiento y aprendizaje al mismo tiempo, el tiempo de inactividad es necesario.

Me doy cuenta de que no tienes autoridad para contratar/despedir, pero a veces es necesario dejar ir a los realmente malos.

Eche un vistazo a la pregunta similar: Manejo de miembros del equipo no calificados / desmotivados

No existe un marco "bala de plata" para el desarrollo de software.

¿Se ha centrado en el equipo para construir un equipo de alto rendimiento?

Algunos de los ejercicios de formación de equipos que he utilizado con éxito son:

1. Lyssa Adkins (Coaching Agile Teams) tiene un excelente ejercicio de creación de equipos: árbol de alto rendimiento.

   o Utiliza los valores de Scrum: Compromiso, Coraje, Enfoque, Apertura (transparencia) y Respeto para la formación de equipos.

   o Equipo identifica las características de un equipo de alto rendimiento.

2. Facilitar reuniones retrospectivas para la mejora continua.

   o ¿Qué va bien?

   o ¿Qué necesita mejorar?

   o Deje que el equipo se comprometa a implementar 2-3 mejoras.

3. Use una reunión de "Refrigerador de agua" para formar el equipo en una sesión informal.

   o Reunión informal para jugar.

4. Use Persona para los miembros del equipo.

   o Ayuda a las personas a conocer a los miembros del equipo.

Para equipos distribuidos, uso las herramientas en línea Conteneo y Trello para reuniones.

Ejemplo de un árbol de alto rendimiento:

Lo primero es lo primero, decida una metodología: muchos de los que menciona son opuestos y no funcionarían bien juntos. TDD, Agile, SCRUM: elija uno (TDD puede ayudar aquí, pero puede ser un cambio de mentalidad) :D

A continuación, parece que el control de calidad es su verdadero problema. Esto significa que debe introducir algunos cambios básicos en el proceso. Mire los tutoriales de código anticuados: implemente un "policía" basado en reglas para estandarizar el código (muchos "policías" en estos días, y VS lo tiene incorporado). Si usa VS, implemente también un proceso de prueba en la compilación (los casos de prueba se pueden compilar en la etapa de codificación y probar sobre la marcha; ¡algunas extensiones incluso verifican a medida que se codifica el código!). Asegúrese de que los casos de prueba estén escritos por una persona diferente al codificador, preferiblemente un sys an/prog y con algo de experiencia (un buen líder de desarrollo ayudará con esto; si no tiene un líder de desarrollo, piense en crear uno incluso si es una posición sin aumento de sueldo desde dentro de los rangos), obtenga una mayor participación de los usuarios si es posible para mantener las cosas en equilibrio. Dele al líder de desarrollo la responsabilidad de garantizar que se cumpla la seguridad y que se configuren los scripts de prueba; permítales trabajar directamente con el analista de sistemas/buses, así como asesorar a los codificadores. Haga que los usuarios firmen diseños/guiones de prueba y "paguen" por cualquier aumento del alcance. Haga que el control de calidad se realice dentro del equipo y que usted lo apruebe, de esa manera, el analista de control de calidad, el evaluador y el codificador sabrán que están siendo monitoreados (de manera justa); también hace que las correcciones de errores sean más baratas, ya que se detectarán antes en el ciclo de desarrollo.

Los codificadores mejoran con la experiencia y el aprendizaje de buenas prácticas (a través de la tutoría y la ósmosis): si el equipo no tiene a nadie de ese calibre, tal vez deba presionar para contratar un puesto de líder de desarrollo (o tomar prestado uno de otro proyecto tal vez ) para hacer exactamente eso: el PM puede empujar, pero se necesita otro codificador para mostrar cómo se debe hacer.