training-data - neural - training dev test set
Cómo demostrarle a la gerencia que los desarrolladores mediocres están perjudicando al equipo (17)
Estoy en la posición precaria de "administrar" un equipo de desarrolladores en una empresa pequeña. Digo "administrar" porque aunque asigno trabajo y proporciono retroalimentación sobre su desempeño, no tengo ningún recurso para disciplinar a un individuo.
Algunos de mi equipo no sé qué hacer con ellos, no pueden trabajar solos, requieren grandes cantidades de mano y, cuando se los deja solos, generalmente causan estragos en el proyecto, por lo general hasta el punto de falla. Cuando ocurre una falla, me queda salvar el proyecto y empujarlo (algunas veces cojeando) a través de la línea de meta.
Estos desarrolladores no solo carecen de habilidades con conceptos de programación, sino que generalmente tienen la capacidad de formular una solución a un problema en el código. Cosas simples como escribir bucles son difíciles para ellos, mucho menos diseñar e implementar una solución a un problema.
Hemos probado la programación de pares, ofreciendo pagar clases, comprando libros, asignando tiempo durante el día de trabajo para la capacitación e incluso tomando días completos para capacitar al equipo.
El otro desarrollador senior y yo no sabemos qué hacer, pero nuestra productividad está siendo acelerada por tener que lidiar con estas personas día a día. La gerencia nos está forzando a darles trabajo y su mayor queja es cómo las cosas no se están haciendo lo suficientemente rápido.
Ninguno de nuestro equipo de gestión trabaja directamente con ninguno de los desarrolladores, aparte de mí y el otro desarrollador sénior. La administración no es técnica y cree que cada desarrollador se crea 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 "The Mythical Man Month" y "Code Complete" para enviar a la gerencia con la esperanza de ilustrar con estadísticas que lo que realmente nos está impidiendo es arrastrar a la gente mediocre a través del ciclo de desarrollo.
¿Qué otros recursos hay por ahí? Libros, artículos, consejos generales, cualquier cosa sería útil.
¿El problema se deriva de la falta de habilidades o habilidades, 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 sabes que hay algunas cosas que no puedes enseñar. Si la empresa está dispuesta (y parece que sí lo está) y puede mostrar mejoras, 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 dejarlo ir. No contrataría desarrolladores adicionales hasta que sepa que va a dejar ir algunos de los existentes.
Si es por pereza u otros problemas de actitud por parte de los programadores, tendrá que convencer a su administración para que lo respalde en las acciones disciplinarias. Documente todos los problemas, como describe Scott Vercuski . Gradualmente elimine a los programadores que no pueden estar a la altura de las circunstancias. Deje que los programadores restantes sepan que se espera que aprendan buenas técnicas de programación y mejores prácticas, y las usen.
Tenga revisiones del código, si no lo está haciendo ya. Hay muchos recursos que explican cómo hacer esto correctamente. No deberían gritar coincidencias, sino más bien considerarse como sesiones estratégicas 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 el problema es la administración, dígales que son el problema y muéstreles cómo pueden solucionarlo. Pero debes ser elocuente y persuasivo. Usted debe ser su abogado. Escribe un trabajo sobre el problema. Haz una presentación y muéstrala. Apelar a los motivos de lucro.
Finalmente, se el mejor líder para tu gente que puedas ser. Ayudarles a. Manténlos desbloqueados para que puedan hacer su trabajo. Parte de su trabajo es proteger a su gente de la política de la alta gerencia y mantener un ambiente de trabajo decente, para que puedan enfocarse en hacer el mejor trabajo que puedan. En otras palabras, asegúrese de que su gente pueda confiar en usted.
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 en todas partes, pero fue bastante revelador para la administración cuando varios de nuestros módulos clave se marcaron como "no comprobables".
Combinamos con una herramienta de análisis de imágenes que ayuda a resaltar la funcionalidad duplicada, y abordamos todo esto como una evaluación de ''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 estaban las cosas, la organización estaba más orientada a mejorar en el futuro que a señalar con el dedo.
(Como un aparte, todo el código ahora se envía para su revisión, y se debe proporcionar un análisis de código acompañante. Las cosas definitivamente están mejorando aquí).
Aquí hay otra idea para ti: no arregles lo que rompen. Envíalo de vuelta para volver a trabajar en un correo electrónico diciéndoles lo que está mal y cómo solucionarlo (solo en términos generales) y administración de cc. Asegúrese de tener en cuenta para la comprensión de la gestión cómo afectará exactamente a su fecha límite final. Esto crea la documentación de problemas de rendimiento para usted y algunos de ellos pueden dejar de ser tan malos cuando tienen que arreglar sus propios problemas.
Divertido 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 de características completas, y me llevó solo un mes.
Tal vez deberías obtener un entrenamiento.
Tal vez deberías leer un informe sobre ti .
No estoy diciendo eso para atacarte. De ningún modo. Entiendo muy bien el problema, ya que en el pasado tampoco pude administrar equipos.
Pero no esquive la pelota, usted es el principal responsable de lo que sucede en su equipo, sin importar la cantidad de literatura de buenas prácticas que haya leído en su vida.
En ese caso, deja de quejarte y ponte a trabajar. No como codificador, sino como gerente.
Finalmente, puedo estar equivocado. Tal vez has hecho todo bien. En ese caso, puede, y probablemente debería, renunciar. Tratar de evitar que un avión se estrelle con mover las manos es inútil, sin importar qué tan fuerte sea. Hay muchos equipos casuales que harán milagros con tus habilidades para sacar lo mejor de ellos.
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 las discusiones podría ayudar un poco, pero lo más importante es cuantificar los resultados. Tome los sueldos de usted y del resto del equipo y luego calcule cuánto tiempo adicional tiene que dedicar a corregir los errores de los demás, con el costo adicional de que los desarrolladores estropeen las cosas para empezar.
Luego, muestre cómo un equipo de mejores desarrolladores puede mejorar el ROI.
Esto simplemente no es posible a menos que tenga una buena tracción con la administración. En mi experiencia, si intentas forzarlo, podrías tener problemas.
He estado en esta situación antes y ciertamente puedo empatizar. Lo que hice fue eliminar una tarea pequeña y autónoma que debería llevarme a mí oa otro desarrollador senior no más de 2 días más o menos. Para esta tarea, crearía montones de documentación que identifique cómo se debe implementar la solución, cualquier cambio en la base de datos, etc. Luego me sentaré con el desarrollador, les daré un recorrido de alto nivel de la tarea y se los asignaré con un plazo de 1 semana. Al final de la semana, tiene algo tangible con el que puede comparar su trabajo: ¿cumplieron con las especificaciones? ¿Cuán hechos están? ¿Cuántos errores encontró QA? ¿Rompieron la construcción o el proceso de ruptura de alguna manera?
Una vez hecho esto, suponiendo que hayan fallado, tiene una reunión directa y puntual con ellos explicando cómo no están cumpliendo con sus deberes. Haz las mismas cosas una o dos veces más y, mientras documentes y comuniques la cadena, deberías poder expulsarlas. Puede ser duro, pero parece que necesita personas para intensificar y simplemente no tiene las personas adecuadas para hacerlo.
Además, asegúrese de participar en la entrevista de nuevos candidatos.
La documentación es su mayor recurso ... un antiguo gerente mío me dijo "Si no lo escribes, no sucedió". Si sus desarrolladores le dan un presupuesto por escrito del tiempo necesario para completar una tarea y constantemente (y severamente) se pierden esos plazos, debe documentarse.
¿Tienes algún tipo de sistema de cronometraje? o los desarrolladores registran su tiempo? Si afirman que un problema les tomará X días y después de X días no está listo, puede preguntar por qué no lo hizo.
Para reiterar ... la documentación es la clave, si de repente interrumpes a alguien y no tienes la documentación adecuada en cuanto a una razón por la que puedes 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 presionando y deben ser reemplazados.
La mejor de las suertes para ti, me temo que estás en un camino muy difícil ... he estado allí y es un proceso prolongado.
Leí esto hace un tiempo sobre alentar a los programadores a querer ser los mejores.
Mantenga el informe conciso. No lo hagas prolijo Ponlo en términos de cuánto dinero están perdiendo en este caso.
Me pregunto cómo fue que estas personas ingresaron a la compañía en primer lugar:
Estos desarrolladores no solo carecen de habilidades con conceptos de programación, sino que generalmente tienen la capacidad de formular una solución a un problema en el código.
Cosas simples como escribir loops 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 dicho: la prisa es un desperdicio.
Ahora, una vez que se encuentre en esa situación como usted describe, termine su informe, (como otros lo insinuaron) haga que sea conciso y subraye cuánto dinero le cuesta a la compañía, envíe y espere lo mejor (como dijo que "no tiene recurso para disciplinar a un individuo ").
Mi consejo es este:
Si usted es un gerente, debe tener los derechos que corresponden a su responsabilidad. Estos derechos incluyen la disciplina de aquellos bajo usted. Si la alta gerencia se niega a otorgarle esos derechos, rechace asumir esa responsabilidad.
No tiene que ser tan estricto con sus supervisores, necesariamente, pero esa es la esencia 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 pasamos trabajando en 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 verificar la tarea.
Por cierto, utilizamos BugTracker.Net .
Parece que estás en el camino correcto.
Si les muestra los números difíciles, verán las cosas más claras: crearán una tarea de codificación y se la darán a varios programadores diferentes para que trabajen solos. Haz que sea comprobable por ti mismo.
Mantenga los detalles de cuánto tiempo lleva cada uno, cuántos defectos produce el código.
Muestre los números a la alta gerencia, ahora deberían estar convencidos.
Peopleware es otro libro que debe unirse a su lista.
Sin embargo, cuando lo leí, no me pareció práctico porque nadie en la empresa quería probar sus recomendaciones.
Solo una idea.
Supongo que usas los sistemas de control de versiones de origen como SVN. Por lo tanto, realice la política de revisar los commits y rechazar los malos. Luego, solo demuestre a los otros gerentes las estadísticas de compromisos rechazados para demostrar que los desarrolladores mediocres son muy costosos para la empresa.
Usted mencionó que para su equipo "brinda retroalimentación sobre su desempeño".
Asi que:
- Siéntate con tu equipo.
- Entrégales las impresiones de esta página y cuéntales que la has publicado sobre ellos.
- Déjelos leerlo.
- Pídales que lo ayuden a resolver el problema.
- Escúchalo y escríbelo.
- Lleva eso a tu equipo de gestión.