Cómo demostrarle a la gerencia que los desarrolladores mediocres están perjudicando al equipo [cerrado]

Estoy en la precaria posición de "dirigir" un equipo de desarrolladores en una pequeña empresa. Digo "gestión" porque, aunque asigno trabajo y proporciono retroalimentación sobre su desempeño, no tengo ningún recurso para disciplinar a un individuo.

Algunos miembros de mi equipo no sé qué hacer con ellos, no pueden trabajar solos, requieren grandes cantidades de agarre de la mano y, cuando se los deja, generalmente causan estragos en el proyecto, por lo general hasta el punto de fallar. Cuando ocurre una falla, me queda rescatar el proyecto y empujarlo (algunas veces cojeando) a través de la línea de meta.

Estos desarrolladores no solo carecen de habilidades con los conceptos de programación, sino también de la capacidad para formular una solución a un problema en el código. Cosas simples como escribir bucles son difíciles para ellos, y mucho menos diseñar e implementar una solución a un problema.

Hemos probado la programación en pareja, ofreciendo pagar las clases, comprar libros, dedicar tiempo durante la jornada laboral a la formación e incluso dedicarnos días enteros a formar al equipo.

El otro desarrollador senior y yo no sabemos qué hacer, pero nuestra productividad se ve limitada por tener que lidiar con estas personas día a día. La gerencia nos obliga a darles trabajo y su principal queja es que las cosas no se hacen con la suficiente rapidez.

Ninguno de nuestro equipo de gestión trabaja directamente con ninguno de los desarrolladores, excepto yo y el otro desarrollador senior. La administración no es técnica y cree que todos los desarrolladores se crean por igual, y que obviamente necesitamos más personas en estos proyectos para hacerlos más rápido.

Ya estoy preparando un documento con secciones de "El mes del hombre mítico" y "Código completo" para enviar a la gerencia y, con suerte, ilustrar con estadísticas que lo que realmente nos está obstaculizando es tener que arrastrar a la gente mediocre a través del ciclo de desarrollo.

¿Qué otros recursos existen? Libros, artículos, consejos generales, cualquier cosa sería útil.

¿El problema surge de la falta de habilidades o capacidad, problemas de actitud por parte de los programadores o de una cultura corporativa que no promueve una buena ética de trabajo?

Si se trata de habilidades, ya sabe que hay algunas cosas que no puede enseñar. Si la empresa está dispuesta (y parece que lo está), y puede mostrar una mejora, aumentaría la capacitación y vería qué desarrolladores están a la altura de las circunstancias. Aquellos que no lo hagan, tendrán que dejarlos ir. No contrataría desarrolladores adicionales hasta que sepa que dejará ir a algunos de los que ya tiene.

Si es por pereza u otros problemas de actitud por parte de los programadores, tendrá que convencer a su gerencia para que lo respalde en las acciones disciplinarias. Documente todos los problemas, como describe Scott Vercuski . Elimine gradualmente a aquellos programadores que no puedan estar a la altura de las circunstancias. Informe a los programadores restantes que se espera que aprendan buenas técnicas de programación y mejores prácticas, y que las utilicen.

Tenga revisiones de código, si aún no lo está haciendo. Hay muchos recursos que explican cómo hacer esto correctamente. No deberían estar gritando partidos, sino más bien como sesiones de estrategia para producir los resultados deseados. Discute el código. ¿Cómo puede ser mejorado? Escriba un código nuevo en la revisión, si es necesario.

Si la administración es el problema, dígales que ellos son el problema y muéstreles cómo pueden solucionarlo. Pero debes ser elocuente y persuasivo. Debes ser su defensor. Escribe un artículo sobre el problema. Haz una presentación y muéstrala. Apelar a fines de lucro.

Finalmente, sea el mejor líder para su gente que pueda ser. Ayudarles a. Manténgalos desbloqueados para que puedan hacer su trabajo. Parte de su trabajo es proteger a su gente de la política de la alta dirección y mantener un entorno de trabajo decente, para que puedan concentrarse en hacer el mejor trabajo posible. En otras palabras, asegúrese de que su gente pueda confiar en usted.

Es curioso que nadie te haya dicho que tal vez careces de habilidades de gestión.

Una vez, terminé trabajando con personas que no podían codificar un ciclo después de un año y medio de entrenamiento. Los entrené, hasta que pudieron usar un marco web con todas las funciones, y solo tomó un mes.

Tal vez usted debe obtener un entrenamiento.

Tal vez usted debería leer un informe acerca de usted .

No digo eso para atacarte. De ningún modo. Entiendo muy bien el problema, ya que tampoco pude gestionar equipos en el pasado.

Pero no esquive la pelota, usted es el principal responsable de lo que sucede en su equipo, sin importar cuánta literatura de buenas prácticas haya leído en su vida.

En ese caso, deja de quejarte y ponte manos a la obra. No como programador, sino como administrador.

Finalmente, puedo equivocarme. Quizás hayas hecho todo bien. En ese caso, puede, y probablemente debería, renunciar. Intentar evitar que un avión se estrelle moviendo las manos es inútil, por muy fuerte que seas. Hay muchos equipos casuales que harán milagros con tus habilidades para sacar lo mejor de las suyas.

La documentación es su mayor recurso ... un antiguo gerente me dijo "Si no lo escribe, no sucedió". Si sus desarrolladores le dan una estimación escrita del tiempo necesario para completar una tarea y constantemente (y severamente) no cumplen con esos plazos, debe documentarse.

¿Tiene algún tipo de sistema de cronometraje? ¿O los desarrolladores registran su tiempo? Si afirman que un problema les llevará X días y después de X días no se hace, puede preguntarse por qué no se hizo.

Para reiterar ... la documentación es la clave, si de repente despide a alguien y no tiene la documentación adecuada sobre una razón, puede entrar en territorio de demanda. Cuanta más documentación tenga, debería ser evidente para la gerencia que los desarrolladores junior no están haciendo todo lo posible y deben ser reemplazados.

Mucha suerte para ti, aunque me temo que estás en un camino muy difícil ... He estado allí y es un proceso largo.

He estado en esta situación antes y ciertamente puedo sentir empatía. Lo que hice fue recortar una pequeña tarea autónoma que debería llevarme a mí oa otro desarrollador senior no más de 2 días aproximadamente. Para esta tarea, crearía una gran cantidad de documentación que identifique cómo se debe implementar la solución, cualquier cambio en la base de datos, etc. Luego me sentaría con el desarrollador, le daría un recorrido de alto nivel de la tarea y se la asignaría con un plazo de 1 semana. Al final de la semana, tienes algo tangible con lo que puedes comparar su trabajo: ¿Cumplieron con las especificaciones? ¿Cómo están? ¿Cuántos errores encontró QA? ¿Rompieron el proceso de construcción o ruptura de alguna manera?

Una vez hecho esto, asumiendo que han fallado, tienes una reunión directa y puntual con ellos para explicarles cómo no están cumpliendo con sus deberes. Haga las mismas cosas una o dos veces más y, siempre que documente y se comunique en la cadena, debería poder empujarlas. Puede ser duro, pero parece que necesitas que las personas den un paso al frente y simplemente no tienes las personas adecuadas para hacerlo.

Además, asegúrese de participar en la entrevista de nuevos candidatos.

Mi consejo es este:

Si es gerente, debe tener los derechos que acompañan a su responsabilidad. Estos derechos incluyen la disciplina de sus subordinados. Si la alta dirección se niega a concederle esos derechos, no asuma esa responsabilidad.

No tiene que ser tan severo con sus supervisores, necesariamente, pero eso es lo esencial de lo que debe suceder.

Mi consejo sería implementar un rastreador de errores y asignar tareas. Esto mostrará la productividad de cualquiera del equipo. La primera vez que lo usamos logramos organizar el equipo y medir el tiempo que dedicamos a las tareas. Una de las cosas que me gustó fue el hecho de que cuando alguien asignaba una tarea enviaba un correo electrónico al trabajador y una copia a otra persona para que revisara la tarea.

Por cierto, usamos BugTracker.Net .

Me pregunto cómo llegaron estas personas a la empresa en primer lugar:

Estos desarrolladores no solo carecen de habilidades con los conceptos de programación, sino también de la capacidad para formular una solución a un problema en el código.

Cosas simples como escribir bucles son difíciles para ellos ...

Su empresa necesita, sin duda, invertir más tiempo y esfuerzo en la contratación de mano de obra, como dice el viejo refrán: la prisa genera desperdicio.

Ahora, una vez que se encuentre en la situación que describe, termine su informe (como otros han insinuado) hágalo conciso y subraye cuánto dinero le cuesta a la empresa, envíelo y espere lo mejor (como dijo que "no tiene recurso para disciplinar realmente a un individuo ").

Leí esto hace un tiempo acerca de alentar a los programadores a querer ser los mejores.

Arreo de nerds

Mencionaste que para tu equipo "brindas retroalimentación sobre su desempeño".

Entonces:

1. Siéntese con su equipo.
2. Entrégueles copias impresas de esta página y dígales que la publicó sobre ellos.
3. Déjelos leerlo.
4. Pídales que le ayuden a resolver el problema.
5. Escuche y anótelo.
6. Lleva eso a tu equipo de gestión.

Peopleware es otro libro que debería unirse a su lista.

Sin embargo, cuando lo leí no me resultó práctico porque nadie en la empresa quería probar sus recomendaciones.

Parece que estás en el camino correcto.

Si les muestra números difíciles, verán las cosas más claras: cree una asignación de codificación y entréguela a varios programadores diferentes para que trabajen por sí mismos. Hágalo comprobable por usted mismo.

Mantenga los detalles de cuánto tiempo tarda cada uno, cuántos defectos produce el código.

Muestre los números a la alta dirección, ahora deberían estar convencidos.

El libro

Código completo: un manual práctico de construcción de software por Steve McConnell

es una buena fuente que puede ayudar a aprender las mejores prácticas.

Requerir que cada desarrollador lea y aprenda esto con discusiones podría ayudar un poco, pero lo más importante es cuantificar los resultados. Tómese su sueldo y el del resto del equipo y luego calcule cuánto tiempo extra tiene que dedicar a corregir los errores de otros con el costo adicional de que los desarrolladores arruinen las cosas para empezar.

Luego, muestre cómo un equipo de mejores desarrolladores puede mejorar el ROI.

Mantenga el informe conciso. No lo hagas prolijo. Póngalo en términos de cuánto dinero están perdiendo en este.

Ahora tenemos una herramienta que mide la complejidad de nuestros módulos de código. Se ejecuta en nuestros módulos PL / SQL, pero creo que hay herramientas disponibles en otros entornos.

Hay varias secciones a lo largo, pero fue una revelación para la administración cuando varios de nuestros módulos clave se marcaron como 'no comprobables'.

Lo combinamos con una herramienta de análisis de imact que ayuda a resaltar la funcionalidad duplicada, y abordamos todo esto empaquetado como una evaluación de la 'deuda técnica'.

Como pudimos presentar esto módulo por módulo, hubiera sido fácil identificar a los perpetradores (lo hicimos, pero no lo informamos). Tal como estaba, la organización estaba más orientada a mejorar en el futuro que a señalar con el dedo.

(Aparte, todo el código ahora se envía para su revisión y se debe proporcionar un análisis de código adjunto. Las cosas definitivamente están mejorando aquí).

Esto simplemente no es posible a menos que tenga una buena tracción con la gerencia. En mi experiencia, si intentas forzarlo, podrías meterte en problemas.

Solo una idea.

Supongo que usa los sistemas de control de versiones de origen como SVN. Por lo tanto, establezca la política de revisar las confirmaciones y rechazar las malas. Luego, muestre a los otros gerentes las estadísticas de los compromisos rechazados para demostrar que los desarrolladores mediocres son mucho más costosos para la empresa.

Aquí tienes otra idea: no arregles lo que se rompen. Envíelo de vuelta para su revisión en un correo electrónico indicándoles qué está mal y cómo solucionarlo (solo en términos generales) y gestión de cc. Asegúrese de tener en cuenta para que la administración comprenda exactamente cómo esto afectará su fecha límite final. Esto crea la documentación de los problemas de rendimiento para usted y algunos de ellos pueden dejar de ser tan malos cuando tienen que solucionar sus propios problemas.