Creo que lo primero que hay que responder es: ” ¿por qué el desarrollador es lento?” Hay muchas razones que pueden rectificarse fácilmente. Aquí hay algunas razones por las que me he encontrado en mi carrera (ciertamente limitada):
- Búsqueda de la perfección:
Si un desarrollo nunca termina hasta que el código sea perfecto, el desarrollador nunca terminará. Ningún software es perfecto, y ningún software no trivial está exento de errores.
Como se cita a Confucio en este artículo: “Mejor un diamante con un defecto que una piedra sin él”. Tenga en cuenta que esto no significa que el software se pueda desarrollar de una manera slap-dash; implementar el mínimo y luego dejar que QA encuentre todos los errores. Pero la determinación de qué es “suficientemente bueno” debe determinarse en función del riesgo. El software que reproduce un video no necesita el mismo nivel de robustez que el software que controla un marcapasos.
- Frenesí refactorizante:
Un desarrollador con el que trabajé no podía dejar el código que no se ajustaba a la guía de estilo. Si se encontraba con un código heredado, tendría que actualizarlo. Si bien la refactorización tiene su lugar, debe mantenerse en su lugar. La refactorización debe depender de qué más es una prioridad y cuánto tiempo está disponible para las pruebas de regresión. En este caso, estábamos hablando de refactorización no funcional, por lo que no hubo un beneficio inmediato para el cliente, que preferiría corregir el error que saber que el código se ve mucho más limpio que antes.
- La terquedad se establece en:
Si tengo una tarea que no sé cómo hacer, haré un buen esfuerzo para resolverla por mi cuenta, ya sea mirando otro código, usando Google, herramientas de depuración, etc. Si paso demasiado tiempo y todavía no tengo idea (descargo de responsabilidad: la definición de “demasiado tiempo” depende de la tarea en cuestión y otras prioridades), luego hablaré con uno de mis colegas desarrolladores. El problema puede ser técnico, o que me faltan algunos antecedentes. De cualquier manera, las personas que son tercas y se niegan a pedir ayuda simplemente se están pegando un tiro (y a la compañía) en el pie.
- Callejón de distracción:
¿El desarrollador se coloca a lo largo de un sendero ocupado? ¿Hay interrupciones constantes? Tengo un compañero de trabajo que una vez tuvo que copiar algo de una pizarra para una reunión en 15 minutos. Cada vez que alguien pasaba, hacía algún tipo de comentario ingenioso. Ella no terminó a tiempo.
En otro caso, una vez estuve trabajando en un proyecto y salí de la ciudad en un par de días. Un grupo de nuevos desarrolladores recibió instrucciones de dejar de enviarme preguntas para poder concentrarme en mi trabajo.
Encontrar la fuente de distracciones es el primer paso para eliminarlas.
- Análisis parálisis:
Como dicen, “” hay mil formas de desollar a un gato “. Si eso es cierto, entonces hay un millón de formas de implementar software. Si bien un buen diseño es importante para un buen software, también es importante no perder demasiado tiempo diseño y rediseño. A veces solo necesita construir algo y ver si funciona. Otras veces, una breve reunión de revisión de diseño o una sesión de lluvia de ideas puede ser todo lo que se necesita para solidificar lo que hay que hacer.
- Deber de limpieza:
Mantener el código antiguo puede ser una pesadilla. He tratado con código heredado del que nadie en la compañía realmente tenía una comprensión completa. Vadear y tratar de descubrir lo que estaba sucediendo condujo a un retraso tras otro, ya que cada nivel de prueba surgió otro escenario especial que había roto. No hay mucho que pueda hacer aquí, excepto tener paciencia y darle al desarrollador algo más manejable la próxima vez.
- Requisitos revisados:
Me dieron una tarea que parecía simple; Un pequeño cambio que podría completarse y probarse en una semana. Di mi estimación, escribí el código y me sometí a pruebas de aceptación. Resulta que tenía los requisitos completamente incorrectos, y la tarea se convirtió en un proyecto que tomó meses y resultó en una característica de la que nadie estaba contento (especialmente teniendo en cuenta el esfuerzo que se realizó). Si hubiera hecho más preguntas sobre los requisitos, nos habríamos dado cuenta de que el trabajo era mucho más grande de lo previsto. Si hubiera planteado mis inquietudes antes una vez que tuviera la mejor imagen, entonces podríamos haber eliminado el cambio en ese momento.
Ninguna de las razones que mencioné son insuperables, y la mayoría solo requiere hablar con el desarrollador y dar un poco de orientación. Cada causa requiere un tacto y una estrategia diferentes; No hay bala de plata. Mientras lo hace, asegúrese de que no haya razones culturales para estos comportamientos.
Dicho esto, ¿qué pasa si el desarrollador simplemente no está haciendo el trabajo que necesita? Si realmente es la incapacidad del desarrollador para cumplir con la descripción del trabajo, podría ser el momento de tener una discusión y tal vez mover al empleado a un puesto junior. Si bien no desea despedir a alguien sin ningún motivo, tampoco debe hacer que el resto del equipo apoye a alguien que no puede cargar con su propio peso.
Aviso que dije incapaz . Puede aumentar la lealtad y la moral entrenando y trabajando con desarrolladores, en lugar de simplemente reducir sus pérdidas. Si bien sé que la lealtad laboral parece ser casi inexistente en estos días, he rechazado varias ofertas porque estoy feliz donde estoy. Si este desarrollador puede ser entrenado o asesorado (dependiendo del problema), intente eso primero.
Supongo que, a fin de cuentas, el resumen muy breve de una respuesta muy larga es: depende . Nadie dijo que la administración fuera fácil. 😉
