Fui contratado como gerente de proyecto / programador senior para administrar un grupo interno de programadores en una empresa. Soy responsable de coordinar 12 programadores.
Mi jefe no tiene experiencia en programación, ¿cómo puedo convencerlo de que deje ir a un programador ineficaz? El argumento de mi jefe es que el programador sabe que no es muy bueno, pero por eso es barato.
La mayor parte de su código debe ser limpiado. Hoy encontré el código que cometió que estaba lleno de contenido difícil de entender y completamente mal escrito (lo que aumentaría el costo de mantenimiento del código más adelante):
public static bool isDivisibleBy(this int num, int numnum)
{
var tmp = (float)num / (float)numnum;
var res = tmp.ToString();
if (res.Contains("."))
return false;
else
return true;
}
public static int reminder(this int num, int numnum)
{
var absNum = Math.Abs(num);
var absNumnum = Math.Abs(numnum);
//speedup
if (absNum.isDivisibleBy(absNumnum))
{
return 0;
}
else
{
var tmp = absNum / absNumnum;
var tmp2 = absNum - (absNumnum * tmp);
var tmp3 = tmp - tmp2;
//sign
if ((num > 0 && numnum > 0) || (num < 0 && numnum < 0))
{
return Math.Abs(tmp3);
}
else
{
return Math.Abs(tmp3) * -1;
}
}
return 0;
}
}
Mi jefe no tiene experiencia en programación, ¿cómo puedo convencerlo de que deje ir a un programador ineficaz? El argumento de mi jefe es que el programador sabe que no es muy bueno, pero por eso es barato.
Parte del problema aquí es que está resolviendo el problema equivocado. En lugar de intentar que despidan al tipo, lo que puede o no estar justificado y que su jefe claramente no está interesado en hacer, desde el punto de vista de la gestión de proyectos, su objetivo es entregar un producto que funcione dentro de las limitaciones de su proyecto.
En un comentario que hiciste arriba, dijiste:
Probé para eliminarlo del proyecto y aumentó la productividad.
En jerga de PM, eliminarlo como un recurso asignado a un entregable mejoró la productividad. ¡Gran! En lugar de usar esto como base para una discusión con su jefe, un enfoque más pragmático puede ser simplemente asignar un trabajo no crítico a esta persona. Si hacerlo le permite entregar un mejor producto más rápido, entonces está desempeñando la función esencial de su función.
Si bien parece que reemplazar el programador puede ser mejor para el proyecto, puede que no sea mejor para la empresa por alguna razón. El despilfarro presupuestario es realmente problema de tu jefe , no tuyo, una vez que hayas aumentado la visibilidad del problema. Sin embargo, hacer un uso eficiente del presupuesto y el talento disponibles es su problema, por lo que, a menos que se trate de un posible problema de recursos humanos, simplemente sacaría a esta persona de la ruta crítica del proyecto.
Siempre que sea transparente, su jefe puede:
Si no tener a esta persona involucrada activamente en el proyecto es verdaderamente más productivo que tenerla participando, entonces probablemente no importe qué opción elija su jefe. Después de todo, le pagan por tomar ese tipo de decisiones, así que déjalo en sus manos.
Antes de lanzarse directamente a 'despedir al tipo', considere otras alternativas, como brindar capacitación. Si el programador sabe que tiene margen de mejora, entonces es probable que esté dispuesto a esforzarse para hacerlo . Si sabe que no es muy bueno programando y no le importa mejorar, entonces posiblemente debería considerar opciones de carrera alternativas.
Si su jefe no está de acuerdo con el costo de capacitar al programador (o contratar a otra persona, si el programador se niega a capacitarse o es realmente incompetente), entonces debe asegurarse de que los costos del código de baja calidad y la incompetencia del desarrollador (como ya que una mayor capacidad de mantenimiento, más defectos, una moral más baja, un rendimiento reducido del equipo en general, etc.) son totalmente visibles para él. Si expone exactamente cuáles son las trampas de la deuda técnica, idealmente de una manera formal con investigación para respaldar su posición (lo cual, en lugar de tal "prueba", puede tomarse como bastante subjetivo), entonces con suerte hará la decisión de dejar ir al programador por su cuenta. ¿Y si no lo hace? Esa es su llamada.
Normalmente, también sugeriría primero asegurarse de que su opinión realmente tenga algún mérito, pero después de mirar el bloque de código, puedo estar de acuerdo en que, en este caso específico, hay, al menos, margen de mejora. Suponiendo, por supuesto, que el ejemplo anterior sea indicativo de la capacidad real del programador, y no el resultado de la presión del tiempo, la carga de trabajo excesiva, el proceso inconcluso (usted dijo que comprometió el código, ¿fue enviado a producción? Si no, es posible que planeaba volver a retocarlo y aún no lo había hecho) o cualquier número de otras posibles razones legítimas.
Creo que deberías explicarle a tu jefe la existencia de Programadores Net Negative Producers .
El desarrollo de software es una de las profesiones donde es posible que los empleados tengan una producción negativa. Esto significa que cuestan más tiempo a largo plazo que sus resultados agregan valor a corto plazo. Incluso si son baratos, harán perder el tiempo a los costosos desarrolladores. ¡Y todos sabemos que siempre te faltan un par de desarrolladores en un proyecto!
Identificar y manejar NNPPers no es tan fácil, pero algunas señales como no entregar un código limpio podrían ser un comienzo. Las señales aún aisladas pueden resolverse con el entrenamiento adecuado. Los verdaderos NNPPer también tienen un problema de actitud en el que piensan que sus formas son las correctas y son difíciles de entrenar.
Los CowboyCoders se identifican más por su actitud que por sus circunstancias. Los CowboyCoders prefieren, ¡no, insisten! -- para evitar estándares, procesos y políticas, y odiar trabajar con otros.
Asegúrese de leer este blog bastante largo sobre " Tratar con programadores que producen negativos netos " y compártalo con su jefe si le gusta. Tal vez incluso compártalo con el desarrollador con el que tiene problemas, esto podría darle una idea de por qué tiene problemas con su comportamiento.
Mi selección de ese artículo como consejo para ti es:
Quitar a un mal desempeño del equipo a menudo puede ser más productivo que agregar uno bueno.
Vea si puede reasignarlo a otro proyecto o producto.
Todd A. Jacobs
Vicki Laidler
ptms
MCW