Ich wurde als Projektmanager / leitender Programmierer eingestellt, um eine interne Gruppe von Programmierern in einem Unternehmen zu leiten. Ich bin verantwortlich für die Koordination von 12 Programmierern.
Mein Chef hat keinen Programmierhintergrund, wie kann ich ihn davon überzeugen, einen ineffektiven Programmierer loszulassen? Das Argument meines Chefs ist, dass der Programmierer weiß, dass er nicht sehr gut ist, aber deswegen ist er billig.
Der größte Teil seines Codes muss bereinigt werden. Heute habe ich von ihm begangenen Code gefunden, der mit schwer verständlichen und völlig falsch geschriebenen Inhalten gefüllt war (was später die Wartungskosten des Codes erhöhen würde):
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;
}
}
Mein Chef hat keinen Programmierhintergrund, wie kann ich ihn davon überzeugen, einen ineffektiven Programmierer loszulassen? Das Argument meines Chefs ist, dass der Programmierer weiß, dass er nicht sehr gut ist, aber deswegen ist er billig.
Ein Teil des Problems hier ist, dass Sie das falsche Problem lösen. Anstatt zu versuchen, den Mitarbeiter zu feuern, was gerechtfertigt sein kann oder nicht und woran Ihr Chef eindeutig nicht interessiert ist, besteht Ihr Ziel aus Sicht des Projektmanagements darin, ein funktionierendes Produkt innerhalb Ihrer Projektbeschränkungen zu liefern.
In einem Kommentar , den Sie oben gemacht haben, sagten Sie:
Ich habe versucht, ihn aus dem Projekt zu entfernen, und es hat die Produktivität gesteigert.
In PM-Sprache, ihn als eine Ressource zu entfernen, die einer zu liefernden Leistung zugeordnet ist, verbesserte die Produktivität. Großartig! Anstatt dies als Grundlage für einen Streit mit Ihrem Chef zu verwenden, könnte ein pragmatischerer Ansatz darin bestehen, dieser Person einfach unkritische Aufgaben zuzuweisen. Wenn Sie dadurch schneller ein besseres Produkt liefern können, erfüllen Sie die wesentliche Funktion Ihrer Rolle.
Während es den Anschein hat, dass der Austausch des Programmierers für das Projekt besser ist, ist es aus irgendeinem Grund möglicherweise nicht besser für das Unternehmen. Die Haushaltsverschwendung ist wirklich das Problem Ihres Chefs , nicht Ihres, sobald Sie die Sichtbarkeit des Problems erhöht haben. Die effiziente Nutzung des verfügbaren Budgets und Talents ist jedoch Ihr Problem. Wenn es sich also nicht um ein potenzielles Personalproblem handelt, würde ich diese Person einfach aus dem kritischen Pfad des Projekts entfernen.
Solange Sie transparent sind, kann Ihr Chef:
Wenn es wirklich produktiver ist, diese Person nicht aktiv am Projekt zu beteiligen, als sie zu beteiligen, dann spielt es wahrscheinlich keine Rolle, welche Option Ihr Chef wählt. Schließlich wird er dafür bezahlt, solche Entscheidungen zu treffen, also überlassen Sie das ihm.
Bevor Sie direkt „den Mann feuern“, sollten Sie andere Alternativen in Betracht ziehen, z. B. Schulungen anbieten. Wenn der Programmierer weiß , dass er Raum für Verbesserungen hat, dann ist er wahrscheinlich bereit, sich die Mühe zu machen, dies auch tatsächlich zu tun . Wenn er weiß, dass er nicht sehr gut im Programmieren ist und es ihm egal ist, sich zu verbessern, dann sollte er möglicherweise alternative Karriereoptionen in Betracht ziehen.
Wenn Ihr Chef mit den Kosten für die Schulung des Programmierers nicht einverstanden ist (oder jemand anderen anstellt, wenn der Programmierer die Schulung ablehnt oder irgendwie wirklich inkompetent ist), dann müssen Sie sicherstellen, dass die Kosten für minderwertigen Code und Entwicklerinkompetenz (wie z B. erhöhte Wartbarkeit, mehr Defekte, niedrigere Moral, verminderte Leistung des Teams insgesamt usw.) sind für ihn vollständig sichtbar. Wenn Sie genau darlegen, was die Fallstricke technischer Schulden sind, idealerweise auf formalisierte Weise mit Recherchen zur Untermauerung Ihrer Position (die anstelle eines solchen „Beweises“ als eher subjektiv angesehen werden können), dann wird er es hoffentlich schaffen die Entscheidung, den Programmierer alleine gehen zu lassen. Und wenn nicht? Das ist sein Ruf.
Normalerweise würde ich auch vorschlagen, sich zunächst zu vergewissern , dass Ihre Meinung tatsächlich einen gewissen Wert hat, aber nachdem ich mir den Codeblock angesehen habe, kann ich zustimmen, dass es in diesem speziellen Fall zumindest Raum für Verbesserungen gibt. Vorausgesetzt natürlich, dass das obige Beispiel auf die tatsächlichen Fähigkeiten des Programmierers hinweist und nicht auf Zeitdruck, übermäßige Arbeitsbelastung oder einen unvollendeten Prozess zurückzuführen ist (Sie sagten, er habe den Code festgeschrieben - wurde er in die Produktion verschoben? Wenn nicht, ist es möglich, dass er hatte vor, zurückzugehen, um es auszubessern, und war einfach noch nicht dazu gekommen) oder aus einer Reihe anderer möglicher, legitimer Gründe.
Ich denke, Sie sollten Ihrem Chef die Existenz von Net Negative Producing Programmers erklären .
Softwareentwicklung ist einer der Berufe, in denen es für Mitarbeiter möglich ist, eine negative Produktion zu haben. Das bedeutet, dass sie langfristig mehr Zeit kosten, als ihre Ergebnisse kurzfristig einen Mehrwert bringen. Auch wenn sie billig sind, verschwenden sie die Zeit der teuren Entwickler. Und wir alle wissen, dass Ihnen bei einem Projekt immer ein paar Entwickler fehlen!
Das Identifizieren und Handhaben von NNPPern ist nicht so einfach, aber einige Signale wie das Nichtliefern von sauberem Code könnten ein Anfang sein. Noch isolierte Signale können mit entsprechendem Training aufgelöst werden. Die echten NNPPer haben auch ein Einstellungsproblem, bei dem sie denken, dass ihre Wege die richtigen sind und schwer zu trainieren sind.
CowboyCoder werden mehr durch ihre Einstellung als durch ihre Umstände identifiziert. CowboyCoder bevorzugen – nein, bestehen darauf! -- Standards, Prozesse und Richtlinien zu vermeiden und die Zusammenarbeit mit anderen zu hassen.
Lesen Sie unbedingt diesen ziemlich langen Blog über den „ Umgang mit Programmierern, die Netto-Negative produzieren “ und teilen Sie ihn mit Ihrem Chef, wenn er Ihnen gefällt. Teilen Sie es vielleicht sogar mit dem Entwickler, mit dem Sie Probleme haben, dies könnte ihm/ihr einen Einblick geben, warum Sie Probleme mit seinem Verhalten haben.
Meine Wahl aus diesem Artikel als Ratschlag für Sie ist:
Einen schwachen Mitarbeiter aus dem Team zu nehmen, kann oft produktiver sein, als einen guten hinzuzufügen.
Sehen Sie, ob Sie ihn/sie einem anderen Projekt oder Produkt zuordnen können.
Todd A. Jacobs
Vicky Laidler
ptms
MCW