El empleado no escucha mis demandas.

Hay 2 posibles cosas que podrían estar sucediendo aquí:

1. Este desarrollador es muy incompetente. Tiene una configuración de Docker para el desarrollo, por lo que debería ser bastante simple agregar lo que sea necesario para la producción. En teoría, ya tiene configurada la infraestructura de producción y la documentación (o un experto en el dominio) sobre cómo producir la aplicación, por lo que no debería ser demasiado difícil. Dicho esto, "duro" y "largo" no son la misma palabra; el hecho de que no sea "difícil" no significa que no pueda llevar mucho tiempo. Si el desarrollador es incompetente, debe despedirlo y encontrar a uno que no lo sea. Eres el administrador, así es como administras.

2. Este desarrollador es muy bueno en su trabajo. Los buenos desarrolladores dicen cosas como "No voy a impulsar el código roto". Así es como sabes que tienes una persona realmente buena en tu equipo, cuando te rechazan de esa manera, porque significa que se enorgullecen de su trabajo y se aseguran de que se haga bien. Así es como sabe, cuando esta persona entrega algo, puede demorar un poco más, pero su guardia no tendrá que saltar de la cama a las 2 a.m. por una falla completa del servidor de gravedad 1. Si esta persona es un muy buen desarrollador, y no estás acostumbrado a tratar con buenos desarrolladores (como parece que no lo estás), eso implica que el resto de tu equipo no son buenos desarrolladores, o al menos no tan buenos como esta persona. Esto significa que, si esta persona no creó esta aplicación y solo la implementa, entonces probablemente la aplicación que se está implementando se escribió de manera deficiente y puede haber factores extraños que impidan que se implemente correctamente, como configuraciones incompatibles, lo que aumentaría el tiempo esperado que tomaría para la implementación. Si este es el caso, debe darle a esta persona todo el tiempo que necesita para hacer su trabajo correctamente. Debe alentarlos a verificar su trabajo en Git "para asegurarse de que no pierdan su progreso" (utilice esto como excusa, no vincule estos compromisos de Git específicamente con el rendimiento y, de hecho, entonces debe darle a esta persona todo el tiempo que necesita para hacer su trabajo correctamente. Debe alentarlos a verificar su trabajo en Git "para asegurarse de que no pierdan su progreso" (utilice esto como excusa, no vincule estos compromisos de Git específicamente con el rendimiento y, de hecho, entonces debe darle a esta persona todo el tiempo que necesita para hacer su trabajo correctamente. Debe alentarlos a verificar su trabajo en Git "para asegurarse de que no pierdan su progreso" (utilice esto como excusa, no vincule estos compromisos de Git específicamente con el rendimiento y, de hecho,NO los utilice como indicador de rendimiento; si no está solicitando un código de trabajo pulido en estas confirmaciones, entonces no le grite a este desarrollador cuando sus confirmaciones de Git no estén pulidas o no funcionen), y puede usar esos puntos de control para medir la productividad, pero no presione más. que eso.

En base a lo que dijiste, me inclino un poco por lo segundo. Cuando dijiste "Está haciendo muchas cosas [sic] que no son necesarias", a veces esas "cosas" son cosas que se requieren para que una aplicación pase de la calidad de desarrollo a la calidad de producción. Ciertamente he tenido mi parte de gerentes que me dicen que no haga ese tipo de "cosas", y yo respondí diciendo que la aplicación explotaría si la pusiéramos en producción de esa manera, y me dijeron que no lo hiciera de todos modos, y efectivamente, tan pronto como llegó a la producción, todo se fue a la mierda. No seas ese gerente.

Mi sugerencia es permitir que su desarrollador le explique lo que está pasando. Tal vez llévelo a una reunión de estado solo para que le explique lo que ha hecho, lo que está haciendo y lo que aún debe hacerse, y vea si puede reducir el alcance para que lo haga más rápido, o poner más gente para ayudarlo, o algo así. O simplemente, de manera informal, haz algunas preguntas y prepárate para escuchar sus respuestas, no solo descartar su trabajo como "cosas que no son necesarias". Luego, una vez que lo haya escuchado, puede tomar una decisión; si cree que está trabajando bien y haciendo lo que debe hacer, entonces déjelo continuar, si no, puede despedirlo.

Este es un ciclo simple de rendición de cuentas:

1. Establecer expectativas
2. Supervise el rendimiento, apoye, capacite
3. Evaluar el rendimiento
4. Consecuencias: Acción correctiva o refuerzo
5. volver a 1

Dicho esto, mi experiencia es que algunos empleados simplemente nunca "lo entienden". Entonces, las consecuencias eventualmente terminan siendo la terminación.

Parece que estás tratando con un desarrollador sin experiencia, que no está acostumbrado a que lo administren. Tal vez haya trabajado antes en solitario/independiente y tenga habilidades técnicas, pero por lo que escribiste, probablemente seas su primer supervisor (al menos el primero que realmente supervisa).

Tu empresa, tu realidad. Depende de usted saber si puede pagar directamente al tipo o si es mejor despedirlo. Si quieres quedártelo, tendrás que explicar algunas cosas que quizás des por sentadas:

1. Sea honesto acerca de sus habilidades técnicas:

Si realmente sabe cómo hacer algo, se espera que planifique bien y entregue a tiempo. Si necesita aprender algo, déjelo en claro al aceptar la tarea, de lo contrario, será infravalorado como empleado.

2. Todos deben brindar visibilidad a sus gerentes:

Si su gerente tiene un enfoque improvisado con sus entregas, entonces él es la excepción, no la regla, o usted se las ha arreglado para ganar este privilegio, que puede ser revocado en cualquier momento. Los gerentes normales quieren ver entregas o progreso parcial. Si no demuestras nada, le estás dando motivos para creer que no estás haciendo nada y querrá saber por qué. Y si te niegas a contestar, creerá que te niegas a hacer tu trabajo. Por lo tanto, no debería tener lugar en la empresa. Ahora, un empleado no necesita satisfacer la curiosidad de todos los compañeros de trabajo, pero es básicamente el trabajo de un gerente o supervisor saber qué están haciendo las personas a las que supervisa y qué progresos están logrando, así mismo, es parte de el trabajo de cualquiera para dar tal visibilidad a su gerente.

3. Hay un lugar para redactar código

Y este lugar debe estar bien diferenciado del código que está listo para usar. Las personas deben estar bien instruidas para no criticar el código borrador, es decir, nadie puede quejarse de los estándares del código en una rama/repositorio de código borrador, ni pedir que se completen los encabezados o que se produzca documentación. Esto alivia la ansiedad de ser criticado por un trabajo incompleto (imagínese que un maestro robó su examen en la mitad del tiempo permitido y lo calificó como estaba).

Pero los gerentes y los colegas que brindan ayuda deben tener acceso a estos repositorios para que puedan brindar información y sugerencias a nivel conceptual, como "oye, estás usando la herramienta X, ¿has considerado usar la herramienta Y?", "No, porque es de pago". ", "Bueno, ¡pero ya tenemos una licencia para eso!".

Si usted es un desarrollador con más experiencia, también puede decir que desea asesorarlo sobre cómo desglosar los proyectos, de modo que pueda entregar el código y planificar mejor. Aún más importante, dividir un proyecto en partes más pequeñas es una parte fundamental de ser gerente de proyecto o arquitecto de software, si es que alguna vez quiere convertirse en uno.

4. Ten mucho cuidado al culpar a otros

Cada vez que un empleado culpa a otra persona, usted como gerente debe saber si está inventando una excusa o si se trata de un informe justo. Tal vez esté dejando sus responsabilidades en otras personas, por ejemplo, "Jake necesita cambiar su interfaz con mi sistema porque son incompatibles a partir de ahora. No importa si Jake siguió las especificaciones que acordamos hace un año, decidí que quería que cambio y no he hablado con él todavía!". Por lo tanto, depende del gerente en el lugar decir "No, debe cumplir con las especificaciones, a menos que estén en el límite imposible de cumplir, no está trabajando demasiado, Jake, para su conveniencia".

Una pregunta justa para hacer cuando un empleado culpa a otro podría ser "¿Ya hablaste con Jake sobre esto?". Un "no" es más o menos una indicación de que el empleado no se está comunicando bien pero habla mal de los demás. Debe reprender este comportamiento.

Pero si sucede que todos los demás no están entregando, o si todos los demás cambian sus interfaces para que el empleado problemático necesite volver a trabajar en sus entregas, entonces toda la oficina tiene un problema de organización, por lo que es posible que deba inspeccionar mejor las entregas de todos.

Pero una versión más interpersonal de esto podría ser: culpar a los demás genera mucha mala voluntad hacia usted. Así que esté muy seguro de sus afirmaciones al hacerlo, y conozca los medios correctos para ello. Nunca lo uses como una excusa para tus propios defectos.

Esto es simple, tú eres el jefe. Suena como si solo estuviera poniendo obstáculos en tu camino, honestamente. Un desarrollador experimentado confirmará y enviará código con mucha frecuencia a su propia rama; el único lugar donde habría preocupación por enviar código roto sería una versión, integración o maestro. ¿Lo pusiste en una posición para rediseñar todo el sistema? Si no, entonces está haciendo un trabajo diferente que tal vez le guste hacer, en lugar de lo que le pediste que hiciera.

Por lo general, no soy el tipo de persona que "soy el jefe", pero usted es responsable del desempeño de sus empleados, y ellos son responsables de su desempeño, como lo define usted, su jefe.

Déjame agregar esto: ¿Qué te hubiera pasado, quieres que TU jefe venga y lo despida? Probablemente lo despedirán por ser un líder ineficaz.

Asegúrate de que haya alguna forma de seguirlo o poner a alguien más con él. Producirá o no producirá. Si no lo hace, el beneficio de tener a alguien trabajando con él valdrá la pena al averiguar dónde lo dejó y qué ha hecho.