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


82

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.


20
En los cierres: ¡Vamos! ¡Controla!
Peter

6
Agregar esta pregunta a mis favoritos no es suficiente. Tengo que configurarlo como fondo de pantalla.
Manos Dilaverakis

5
Maldita sea, debería votar para cerrar, pero me gusta la pregunta :(
IAdapter

3
Una cosa muy importante que debe hacer es convencer a la gerencia de que usted y / o su contraparte desarrollador senior tienen voz y voto sobre quién es contratado (y despedido o disciplinado). Si se supone que eres responsable de guiarlos, deberías tener al menos algo de voz sobre si son o no parte de tu equipo en primer lugar.
Michael Todd

5
Votado para cerrar, subjetivo y argumentativo. Debería ser un wiki de la comunidad si la gente solo quiere desahogarse.
Joe

Respuestas:


26

¿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.


Interesado aquí Robert. ¿Tiene enlaces o recursos sobre "Cómo no hacer una revisión del código"? Pregunto porque creo que estaba en uno que salió terriblemente mal el otro día ... Me gustaría documentación externa para cuando vaya a la gerencia (una vez más) sobre este Ingeniero Senior. (Incluso fui tan lejos como para rebotar el escenario de otro estudiante de último año con el que trabajé una vez y él estuvo de acuerdo en que la respuesta que obtuve "parecía un poco fuera de lugar".)
Jason D

@Jason: No estoy seguro de lo que sucedió en la revisión de su código, pero este artículo podría brindarle alguna información: it.toolbox.com/blogs/puramu/…
Robert Harvey

no es exactamente lo que esperaba, pero señaló otras fallas fundamentales en cómo llevamos a cabo el proceso de revisión. (p. ej., no tener a la parte "adulta" / sin derechos adquiridos como la que dirige la revisión ...) Usaré ese vínculo, entre otros, para discutir las mejoras en nuestro proceso de revisión de código con la administración y usaré mi experiencia personal reciente como un ejemplo de por qué el mediador imparcial debería estar allí ...
Jason D

32

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.


6
No entiendo por qué la gente te rechazó. Usted plantea el punto válido de que los líderes / gerentes que evolucionan a partir de ingenieros normales casi nunca reciben capacitación sobre cómo administrar personas. La vieja falacia de "usted es un gran ingeniero, por lo tanto será un gran gerente".
Erich Mirabal

1
Bueno, porque no es políticamente correcto decirle a alguien que pide ayuda que tal vez él sea la causa de su situación. Debo decir que no me gusta que me digan eso a mí mismo, pero suele ser un electrochoque útil.
e-satis

4
Gracias por señalar esto, y tampoco obtengo los votos negativos. Nunca he tenido ningún tipo de formación en gestión. Me pusieron en esta posición (precaria) sin ninguna experiencia previa. Admito plenamente que podría ser parcialmente culpable. He solicitado (más de una vez) que se contrate a un director de desarrollo real, alguien con experiencia en la dirección de un equipo de desarrolladores. La solicitud parece haber caído en oídos sordos.

1
He encontrado algunos consejos de gestión realmente buenos en manager-tools.com. Tienen podcasts divididos en temas útiles. Tal vez puedas encontrar algo que te ayude.
Paul Hildebrandt

@Paul: gracias por eso, ¡definitivamente lo comprobaré!

15

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.


Usamos un sistema de seguimiento del tiempo y una herramienta de seguimiento de errores, pero no tengo acceso para ver el tiempo de otras personas. Definitivamente comenzaré a documentar mis experiencias con más diligencia.

Si reúne suficiente documentación sobre sus estimaciones, puede proporcionar esas estimaciones a su gerente y pedirle que realice una comparación de la hoja de tiempo y, con suerte, mostrará que el desarrollador estimó X días y pasó X + Y días de manera constante, lo que le dará más munición. por tu decisión.

2
Si el problema son las estimaciones, tenga en cuenta que las buenas estimaciones requieren tiempo. Para estimar cuánto tiempo tomará un problema de codificación, debe llegar al nivel de averiguar qué líneas de código necesita cambiar, qué clases y métodos necesita escribir, y así sucesivamente, y por supuesto necesita factorizar a tiempo para la prueba. La buena noticia es que averiguar estas cosas es algo que tendría que hacer de todos modos, por lo que realmente no se está tomando más tiempo para la estimación.
Ryan Lundy

6

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.


5

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.


2

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 .


Tenemos un rastreador de errores y un sistema de seguimiento del tiempo, pero no están integrados. También dejamos que el desarrollador individual ingrese su tiempo dedicado a una tarea. Es posible que tenga que ver si podemos realizar un seguimiento del tiempo total transcurrido entre la asignación y la finalización en el rastreador de errores frente al tiempo estimado.

Entonces pensaría que es una cuestión de ética de los empleados en la que tendrías que concentrarte.
Nelson Miranda

Suena como un lugar encantador para pasar 8 horas al día ... ¡NO! ¡Desde cuándo los programadores nos convertimos en trabajadores de fábrica! ¿Cómo es la rotación de personal en su organización y cuánto dinero desperdicia porque no puede adaptarse a la naturaleza humana? ¿Alguien que trabaja allí tiene presión arterial alta? Lo único que puede administrar es una maquiladora. Nadie que se precie querría trabajar en ese entorno. Vaya, es hora de mi descanso para tomar café. ;-)
Sam

2

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 ").


3
El personal de desarrollo no se incluyó en el proceso de contratación, así es como entraron.


1

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.

1

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.


La última vez que estuve en esa situación, renuncié y me fui a otro lugar, es mucho mejor ahora trabajar con un equipo de desarrollo diferente que realmente tiene las habilidades para hacer un desarrollo real.
James

0

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.


0

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.


OP ya afirma que usa Code Complete. ¿Algún otro buen libro?
aaaa bbbb

0

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


0

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í).


0

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.


0

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.


0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.