Me enfrento a un problema que es bastante nuevo para mí y quiero discutirlo. Tengo en mi equipo un desarrollador que no tiene en cuenta las directivas que se le dan. No sigue las prioridades que se le dan y, a veces, incluso las especificaciones.
La persona es competente en la codificación, está motivada y tiene buenas intenciones, por lo que estoy bastante seguro de que podemos encontrar una manera de hacer ese trabajo.
Permítanme dar algunos ejemplos para tener una mejor comprensión de la situación.
Teníamos un proyecto que estaba casi listo para ser publicado. Sin embargo, se debe corregir un error en una funcionalidad y otro en la función que registra la cuenta del cliente. Teníamos a otro desarrollador sobre el error en la funcionalidad, así que le dije que arreglar el problema de la creación de la cuenta era absolutamente crítico y que debería dedicar su tiempo a eso. Traté de ser lo más claro posible: "Si no podemos registrar un nuevo cliente, no podemos vender nuestro producto, por lo que las funcionalidades, con o sin errores, son inútiles. Esta es la prioridad número 1". Obviamente, me entero que va ayudando al otro desarrollador. Hizo un buen trabajo, pero ese trabajo no era la prioridad y no era lo que le habían asignado.
En otro proyecto le dimos especificaciones técnicas sobre un desarrollo que tiene que hacer. Se le ocurre algo que funciona, pero no cumple con las especificaciones. Le dijimos que refactorizara su trabajo para que coincidiera con la especificación. Esto era mejor pero aún no coincidía con ellos. La especificación era más complicada de lo que se necesitaba para hacer su trabajo, por lo que decidió simplificarla. Lo cual es bueno, excepto por el hecho de que soy responsable de eso, por lo que debería hablar conmigo cuando toma decisiones como esa, y sabemos que una futura mejora del software necesitará esa especificación (que él habría sabido si él había hablado conmigo).
Estoy bastante seguro de que el problema no surge del tipo, sino de la interacción entre él y la forma en que se realiza la gestión en la empresa.
Entonces, básicamente, ¿cómo hacer que la situación mejore y hacer que todos caminen en la misma dirección? ¿Qué crees que hicimos mal al administrar aquí?
Veo dos enfoques para el problema y desde donde me siento, no estoy seguro de cuál es el mejor enfoque:
Cooptarlo: según la descripción, se enorgullece de su trabajo y publica un código de calidad, pero lo hace a su manera. Tienes que hacerle creer que tu camino se ha convertido en su camino. Antes de entregarle las tareas, debe dedicar tiempo a "involucrarlo" en el problema actual y él se hará cargo de todo. La mejor técnica para eso variará mucho y es probable que todo el proceso tome mucho tiempo, pero podría terminar con un miembro valioso del equipo.
Vuélvase formal: cuando asigne tareas, proporcione objetivos, plazos, puntos de control y entregables ultra claros. Realice un seguimiento y verifique regularmente el estado y déjele claro que sus plazos incumplidos están poniendo en riesgo el proyecto. Si no cambia de comportamiento, tendrá que ascender en la cadena de gestión hasta que alguien cambie su comportamiento o hasta que lo retiren de sus proyectos.
No estoy seguro de estar siguiendo tu lógica.
Dijiste que le dijiste en qué trabajar (específicamente) y él fue y trabajó en otra cosa, y le diste 'especificaciones' (que son, ya sabes, específicas) y lo construyó de la manera que quería, y tú' ¿Está pensando que se debe a una falta de comprensión o interacción con la gerencia?
El problema es él, pura y simplemente. Si ha sido tan específico como dice y aún recibe esta reacción, entonces es hora de reevaluar su puesto en la empresa. Sí, es un buen programador, pero hay muchos buenos programadores que también pueden seguir instrucciones y trabajar en lo que se supone que deben hacer.
Desde una perspectiva puramente comercial, le está costando tiempo y dinero. Le pagaste para que trabajara en una gran solución en la que no se suponía que debía trabajar (lo que retrasó el lanzamiento de tu producto) y luego le pagaste para que trabajara en lo que debería haber estado trabajando en primer lugar. Luego le pagaste para construir algo tres veces cuando tenía las especificaciones desde el principio, pero eligió hacerlo a su manera.
Y para no ser demasiado directo, parece que usted (o quienquiera que esté a su cargo) también podría ser parte del problema. Si ve estos problemas y sigue diciendo que no es él o que debe haber alguna manera de trabajar con su comportamiento, bueno, eso también es un problema. Entonces, ¿qué hiciste mal? Estás excusando sus acciones, lo que solo le dice que están bien.
A veces, la parte más difícil de gestionar proyectos es gestionar a las personas.
Un equipo de alto rendimiento significa que las personas que lo componen trabajan de manera colaborativa y solidaria hacia un objetivo colectivo. Los individuos de este equipo son todos exitosos o todos fracasan; no hay diferencias individuales. Si bien está citando algunos comportamientos positivos de este trabajador, probablemente porque desde una perspectiva individual son comportamientos positivos que podrían producir algunos resultados positivos, sus comportamientos son inconsistentes con el trabajo en equipo y las metas del equipo. Centrarse en cómo sus comportamientos son positivos parece más tratar de justificar y excusar lo que ha hecho y, si haces esto, te conviertes en su facilitador.
Identifíquelo y dígale lo que hizo "mal" (lo pongo entre comillas porque es un juicio de valor basado en su situación particular, no necesariamente en su ética de trabajo), dígale lo que se espera de aquí en adelante, encuadre su plan de mejora, evalúe su desempeño al final del cuadro de tiempo y luego reaccione en consecuencia hasta incluir la eliminación y el reemplazo.
En su lado de esta ecuación, necesita evaluar sus canales de comunicación. Mientras trato de no justificar su comportamiento, estoy recogiendo un enlace de comunicación roto como la posible causa raíz. Tomó un par de decisiones "ejecutivas" que no concordaban con sus instrucciones. La primera pregunta es: ¿hay algo en este tipo, como su rasgo de personalidad, que hace que evite comunicarse? Por ejemplo, es un tipo introvertido, cabizbajo, perdido en su trabajo y simplemente ataca. La pregunta dos es: ¿ha desactivado el canal de comunicación bidireccional? ¿Está abierta la puerta de su oficina? ¿Escuchas, quiero decir, realmente escuchas, a tu equipo y sus mensajes para ti? Si arreglaste este enlace, ¿desaparecería este problema por arte de magia?
No solo amas a la gente :)
Este es un problema de rendimiento, no solo de su proyecto. Si ya ha hablado con él y no ha hecho ninguna diferencia, debe hablar con su gerente funcional. He estado del lado del cliente en este comportamiento, y tengo que decirles que rompió mi confianza con el equipo. Trabajo muy duro para asegurarme de no tratar a mis clientes con la indiferencia que hace esta persona.
Tiene buenos consejos de otros arriba sobre cómo enfrentar el problema directamente, pero no olvide incluir al gerente funcional.
Buena suerte.
A menudo, cuando un equipo, no solo un individuo, hace un trabajo incorrecto, es porque las limitaciones no se han aclarado al equipo.
En primera instancia, ¿el segundo desarrollador también sabía que el trabajo de su desarrollador de problemas era una prioridad? ¿Habría distraído al primer desarrollador si hubiera sabido eso?
En el segundo, ¿por qué el desarrollador necesitaba preguntarle sobre los motivos del diseño y la especificación? ¿Por qué no se le dio toda la información que necesitaba para que su trabajo tuviera sentido?
Parece que sería absolutamente perfecto en un equipo de desarrollo Agile. Está ayudando a otros en colaboración, simplificando las cosas, tomando decisiones pragmáticas y produciendo software excelente que funciona con las capacidades que conoce.
Desafortunadamente, estas mismas tendencias que funcionarían tan bien en Agile significan que probablemente se sienta frustrado por los procesos más tradicionales, en los que no puede usar su creatividad, colaborar, tomar decisiones sobre cómo resolver problemas (en lugar de simplemente implementar soluciones) , etc.
A veces, no se trata tanto de administrar a las personas correctamente como de detectar que sus talentos y fortalezas no están bien alineados con la tarea en cuestión. Si tiene algún proyecto piloto de Agile en curso, sugeriría que es un excelente candidato. De lo contrario, puede ser hora de que se vaya, y eso no tiene por qué ser algo malo para ninguno de los dos.
Estoy en algún lugar entre la opinión de SBWorks y la opinión de Trevor sobre esto. Y creo que todo se reduce al nivel de disconformidad que tienes.
Como primer paso, inclúyalo en el proceso de diseño tanto como sea posible en su sistema de proyectos. Mientras lo hace, escuche atentamente su opinión. Busque pistas de objeción oculta en él. Si no hay desacuerdos, documente sus decisiones comunes (resaltando su consentimiento). Sin embargo, es muy probable que no esté de acuerdo en todo. Naturalmente, usted decide después de evaluar las posibilidades, eso no es nuevo de ninguna manera. Solo tenga cuidado de documentar el informe de la minoría y la razón por la que elige un enfoque sobre el otro.
Si tiene éxito, habrá terminado y tendrá un recurso valioso para el trabajo de planificación futuro. No hay problema en esta sucursal.
La otra opción es que vuelva a pasar lo mismo. Le preguntas por qué dejó el camino que acordaste, él dice que siempre supo que el camino estaba equivocado. En este punto, debe consultar los acuerdos y los documentos producidos en el paso 1. Vi que esto sucedió un par de veces y todavía no estoy seguro de que lo hayamos manejado bien...
Creo que después de dos rondas de que esto siga fallando, lo dejaría ir. En ese caso, realmente necesita un proceso o entorno de trabajo diferente. (Tengo que decir que nunca despedí a nadie por este motivo...)
jmort253
M0N4K0
Deadalnix
MCW