Wie können Sie feststellen, ob Ihre Programmierer unterdurchschnittliche Leistungen erbringen? [geschlossen]

60

Ich bin ein Teamleiter mit mehr als 5 Entwicklern. Ich habe einen Entwickler (nennen wir ihn A ), der ein guter Programmierer ist, der sauberen, leicht verständlichen Code schreibt. Es ist jedoch etwas schwierig, mit ihm umzugehen, und manchmal frage ich mich, ob er wirklich unterdurchschnittlich ist oder nicht.

  1. Unser Unternehmen verlangt von den Entwicklern, dass sie den Arbeitsfortschritt in dem von uns verwendeten Bug-Tracker angeben, nicht nur, um die Programmierer zu überwachen, sondern um die Stakeholder über den Fortschritt auf dem Laufenden zu halten. Die Sache ist, dass A einen Aufgabenfortschritt erst aktualisiert, wenn er erledigt ist (vielleicht 3 Wochen, nachdem er zum ersten Mal bearbeitet wurde), und dies lässt alle sich fragen, was in der Mitte der Entwicklungswoche vor sich geht. Er würde seine Gewohnheit trotz wiederholter Prüfung nicht ändern. (Es ist in Ordnung, Entwickler hassen Papierkram, ich auch)
  2. In den letzten 2-3 Monaten hat er häufig Urlaub wegen verschiedener Ereignisse - entweder ist er krank oder muss viele persönliche Ereignisse besuchen usw. (Es ist in Ordnung, schlechte Dinge passieren in einer Kette. Es ist nur ein Zufall.)
  3. Wir definieren Sprints oder Roadmaps für jeden Monat. Und zu Beginn des Sprints besprechen wir den Arbeitsaufwand, den die Entwickler in einem Sprint leisten müssen, und die Zeit, die sie für die einzelnen Aufgaben benötigen . Normalerweise wird er nicht alle schaffen. (Es ist in Ordnung, die Entwickler haben regelmäßig Termine verpasst, die nicht auf ihre Schuld zurückzuführen sind).
  4. Ich wohne in Singapur. Ich bin mir nicht sicher, ob das wichtig ist. Ja, Asiaten sind bekanntermaßen zurückhaltend, aber spielt das eine Rolle?

Wenn nur ein oder zwei der oben genannten Ereignisse eintreten, habe ich nicht das Gefühl, dass A nicht ausreichend ist, aber sie treten alle zusammen auf. Also habe ich das Gefühl, dass A unterdurchschnittlich ist und vielleicht - Gott bewahre - nachlässt.

Dies ist nur ein Gefühl, das auf meiner jahrelangen Erfahrung als Programmierer beruht. Aber ich könnte mich irren.

Es ist bekanntermaßen schwierig, die Arbeit eines Programmierers zu messen, da nicht alle beiden Aufgaben gleich sind, und es fehlt ein Standardziel, um das Engagement eines Programmierers für Ihr Unternehmen zu messen. Es ist absolut unmöglich zu sagen, ob der Programmierer seinen Job macht oder nachlässt. Alles, was Sie tun können, ist, ihnen zu vertrauen - ja, ihnen zu vertrauen und ihnen Autonomie zu geben, ist die beste Möglichkeit für Programmierer zu arbeiten. Ich weiß das. Beginnen Sie also keinen Vortrag darüber, warum Sie Ihren Programmierern vertrauen müssen viel - aber wenn sie dein Vertrauen missbrauchen, kannst du es wissen?

Ergebnis:

Ich habe ein klares Gespräch mit ihm über meine Wahrnehmung seiner Leistung. Er war empört, als ich vorschlug, dass ich das Gefühl hatte, dass er nicht auf seinem besten Niveau auftrat. Er fühlte, dass dies ein völlig unfaires Gefühl war. Ich antwortete dann, dass dies mein Gefühl war und ich wusste nicht, ob mein Gefühl richtig war oder nicht. Er hätte nichts davon und beendete die Diskussion sofort.

Bevor er ging, sagte er, dass er "versuchen würde, der Firma mehr zu geben", in einem sehr kalten Ton. Ich war überrascht von seiner Reaktion. Ich bin mir sicher, dass ich ihn in gewisser Weise beleidigt habe. Ich bin mir nicht sicher, ob das das Richtige war, um so offen mit ihm umzugehen.


Meine Frage ist: Wie können Sie feststellen, ob Ihre Programmierer unterdurchschnittlich abschneiden? Sicher gibt es erfahrene Teamleiter, die das besser wissen als ich? 


Zusätzliche Hinweise:

  1. Ich hasse Mikromanagement. Alles, was wir für unseren Softwareprozess haben, ist Sprint (wo Aufgaben priorisiert und zugewiesen werden und am Ende des Monats eine Überprüfung des Arbeitsaufwands). Entwickler müssten die Aufgaben aktualisieren, wenn sie täglich ausgeführt werden.
  2. Es gibt kein Stand-up-Meeting oder ähnliches. Hauptsächlich, weil wir die Freiheit haben, von zu Hause aus zu arbeiten, und jeder diese Freiheit schätzt.
  3. Obwohl ich derjenige bin, der den Termin festlegt, werden die Entwickler den Kostenvoranschlag für jede Aufgabe vorlegen und ich werde - basierend auf dem Kostenvoranschlag - die Aufgaben bestimmen, die in einen bestimmten Sprint gehen. Wenn sie die Aufgaben am Ende des Sprints nicht erledigen können, schiebe ich sie zum nächsten. Theoretisch kann man also während des gesamten Sprints nur 1 oder 2 Aufgaben erledigen und dann die verbleibenden 99 Aufgaben auf den nächsten Sprint verschieben, und trotzdem ist er in Ordnung, solange dies gerechtfertigt ist - in Form von täglichen Aktualisierungen des Arbeitsfortschritts
Ein Teamleiter
quelle
10
Wie wäre es, wenn Sie ein paar Programmiervorschläge für bestimmte Aufgaben machen und erklären, dass dies eine Methode ist, um Wissen zu teilen und etwas anderes zu tun. Es könnte einen Einblick in seine Arbeitsweise geben und Ihnen Wissen aus erster Hand vermitteln?
Dreza
44
Haben Sie darüber nachgedacht, dass mit dieser Person möglicherweise noch etwas ganz anderes passiert? Wenn jemand viel krank anruft und viele persönliche Veranstaltungen besuchen muss, würde ich vermuten, dass etwas in seinem Privatleben passiert, das ihn bei der Arbeit ablenkt. Ihn wegen seiner Leistung zu belästigen, wird keinem von Ihnen helfen. Sprechen Sie mit dem Mann, finden Sie heraus, was in seinem Privatleben vor sich geht, helfen Sie ihm, wenn Sie können, geben Sie ihm etwas Spielraum, wenn er für Sie wertvoll genug ist - er wird Ihnen dafür danken und wahrscheinlich mit Interesse zurückkehren, wenn sein Privatleben es ist aussortiert.
Marjan Venema
4
@MarjanVenema, ich habe mit ihm gesprochen, er hatte das Gefühl, dass er bereits sein Bestes gab, nämlich mein Gefühl war falsch. Auch möchte nicht jeder sein Privatleben mit Ihnen teilen. Sie riskieren, als geschäftig eingestuft zu werden, indem Sie nach dem Privatleben anderer Personen fragen
A Team Lead
3
Was halten die anderen Entwickler im Team von dieser Person?
MarkJ
5
Ich öffne diese Frage erneut. Für mich macht es am Arbeitsplatz keinen Sinn, was allgemeine und fachübergreifende Belange betrifft. Die spezifische Messung der Leistung von Software-Entwicklern unterscheidet sich von der Messung der Leistung einiger anderer Berufe, daher sehe ich keine Angemessenheit für die Migration. @ATeamLead, Sie sollten diese Frage jedoch mit einigen weiteren Informationen aktualisieren, die in den Kommentaren gefragt wurden, z. B. Ihrem geografischen Standort.
Thomas Owens

Antworten:

49

Dies sollte ein überraschend leicht zu lösendes Problem sein.

Treffen Sie sich ein zweites Mal mit ihm. Sagen Sie ihm, dass Sie akzeptieren, dass wahrscheinlich Ihre Wahrnehmung der Realität daran schuld ist. Dann qualifizieren Sie das mit "Wenn dies jedoch der Fall ist, müssen wir zusammenarbeiten, um meine Wahrnehmung zu verbessern." Schließlich ihn herauszufordern , dieses Problem zu lösen, damit er nicht Mikro-verwaltet fühlen.

Genau das ist mir vor langer Zeit passiert. Für mich war das Problem, dass ich die Möglichkeit nicht mag, dass irgendjemand glaubt, ich suche zusätzliche Anerkennung dafür, dass ich einfach meinen Job mache. Und das war fair genug, aber es muss eine regelmäßige Rückkopplungsschleife zwischen jedem Mitarbeiter und seinem Vorgesetzten geben.

Wenn dies nicht der Fall ist, treten diese Probleme auf.

Regelmäßige, geplante 1: 1-Spiele sind eine großartige Idee. Und wie bereits erwähnt, müssen Stand-ups nicht orthogonal zur Arbeit von zu Hause aus sein. Aber sie müssen die drei Fragen beinhalten: Was hast du gestern gemacht? Was haben Sie heute vor? Und die, die die meisten Leute vergessen ... Was (wenn überhaupt) hält dich auf?

Sie sollten jedoch versuchen, Situationen zu vermeiden, in denen Teammitglieder niemals zusammenarbeiten. Ich habe schon früher in dieser Situation gearbeitet und es hat Misstrauen innerhalb und außerhalb des Teams ausgelöst. Habt einen normalen Tag, an dem ihr alle ins Büro kommt. Treffen Sie sich regelmäßig, um Ideen zur Verbesserung von Prozessen oder was auch immer zu äußern.

Machen Sie es nicht zu einem Ereignis mit Zeilenberichten. Machen Sie es sich zu einer Gelegenheit, einfach zu reden. Sie werden überrascht sein, was Sie lernen. Wenn möglich, verwandeln Sie das in ein gesellschaftliches Ereignis, gehen Sie auf ein paar Drinks zur Arbeitszeit als Bindungsübung.

pdr
quelle
3
we need to work together to improve my perception- Genau das, was ich dachte, als ich die Frage las, insbesondere den Abschnitt "Ergebnis".
Robert Harvey
2
Mein Mitgefühl gilt dem Entwickler. Wenn er pünktlich liefert, was angefordert wurde, sind die "Gefühle" des Projektmanagers nicht nur unbegründet und irrelevant, sondern auch beleidigend.
Steven A. Lowe
4
@ StevenA.Lowe: Vermisse ich etwas? Die Frage besagt, dass die Entwickler ihre eigenen Erwartungen festlegen können und er sie immer noch regelmäßig vermisst. Um nicht zu sagen, dass ich mich nicht schuldig gemacht habe, meine eigenen Fähigkeiten überschätzt zu haben (und das OP macht das gleiche Zugeständnis), aber ich kämpfe darum, zu sehen, wo Sie lesen, dass er "pünktlich liefert, was erwartet wurde".
pdr
@pdr: lol vielleicht habe ich falsch gelesen, obwohl diese frage scheinbar jeden tag bearbeitet wird. Dem fraglichen Entwickler fehlen seine Schätzungen, aber anscheinend nicht mehr als den anderen Entwicklern im Team. vermuten einen Mangel an Ausbildung und / oder Führung;)
Steven A. Lowe
2
+1 - das Problem ist nicht, dass er unterdurchschnittlich abschneidet. Wie der OP sagte, weiß er nicht , ob er es ist oder nicht, und das ist das Problem, das sowohl er als auch der Entwickler lösen müssen.
Zibbobz
12

Hier gibt es viele gute Ratschläge, und ich möchte nichts davon wegnehmen. Deshalb poste ich dies als separate Antwort.

Zunächst ist mir (und anscheinend anderen) klar, dass Sie die Wurzel des Problems nicht entdeckt haben . Sie starren auf ein Symptom und versuchen, es zu heilen. Sie müssen herausfinden, was so viel Reibung zwischen Ihnen und diesem Entwickler verursacht. Vielleicht sind Sie zu autoritär (meine Product Ownerin hat sich kürzlich als "Unendliche Macht" über ein Projekt beschrieben und das war beleidigend für mich, obwohl sie lachte, als sie es sagte). Vielleicht hat er schwerwiegende familiäre Probleme (würde erklären, dass er immer arbeitslos ist). Es ist ein Grundproblem hier, und bis Sie sie finden, wird dies nicht festgelegt werden.

Guter Fang!

Wenn seine Leistung besser sein könnte, ist es toll, dass Sie das festgestellt haben. Denken Sie jedoch daran, dass Sie vorsichtig vorgehen müssen, um zu vermeiden, dass Sie einen guten Entwickler verlieren, wenn seine schlechte Leistung im Vergleich immer noch eine gute Leistung ist. Gute Entwickler sind schwer zu finden, und gute Entwickler benötigen eine Reihe ganz bestimmter Dinge. Schauen Sie sich vielleicht den Joel-Test an, um zu sehen, ob seine Bedürfnisse erfüllt werden.

Finden Sie die Ursache des Problems

Wenn er mit etwas im Zusammenhang mit seiner Arbeit nicht zufrieden ist, können Sie das Problem nur beheben, indem Sie die Ursache des Problems ermitteln. Lassen Sie mich klar sein, Sie sagten, Ihr Programmierer habe guten Code geschrieben. Das bedeutet, dass er gerne programmiert. Es ist mehr als offensichtlich, dass er bei der Arbeit frustriert ist (wie aus Ihrer Beschreibung des Meetings hervorgeht), und Sie haben wahrscheinlich Recht, dass seine Leistung unter der erwarteten Leistung liegt, gehen Sie aber nicht davon aus . Denken Sie daran, dass viele Programmierer einfach keine sozialen Fähigkeiten haben.

Du bist auch nicht perfekt

Denken Sie daran, dass es manchmal zu Persönlichkeitskonflikten kommt, insbesondere bei Introvertierten . Wenn es sich um einen Persönlichkeitskonflikt handelt, überlegen Sie, inwieweit Sie bereit sind, eine Leistungssteigerung zu erzielen (siehe 1).

All das sagte

Ich habe einen Blogbeitrag über Managing Programmers geschrieben. Ich denke, du solltest es lesen.

http://deltreey.blogspot.com/2012/07/managing-programmers.html

Ich kann den letzten Teil dieses Beitrags nicht genug betonen.

Wenn Ihre Entwickler überhaupt gut sind, möchten sie Code erstellen.

Ihr Programmierer möchte nicht nachlassen, auch wenn er nachlässt. Sie müssen die Wurzel dieses Problems finden, und es kann sich als etwas herausstellen, das einfach nicht behoben werden kann, und er muss losgelassen werden, aber was auch immer es ist, Sie können keine fundierte Entscheidung treffen, ohne es zu bestimmen.

Deltree
quelle
10

Wenn Sie das Gefühl haben, dass es "etwas schwierig ist, mit jemandem umzugehen", wie Sie es beschreiben, und um besser zu verstehen, wie jemand arbeitet und ob es Probleme (objektiv oder subjektiv) gibt, die die Produktivität von Entwicklerteammitgliedern beeinträchtigen, sollten Sie überlegen, mit Ihrem Team regelmäßig 1: 1 zu üben Teammitglieder, wie in einem ausgezeichneten Artikel The Update, The Vent und The Disaster vorgestellt :

... Ich schlage nicht vor, dass jedes 1: 1 eine gewundene Angelegenheit ist, um tief verborgene, aufkommende Katastrophen zu entdecken, aber Sie möchten einen wöchentlichen Ort schaffen, an dem Unzufriedenheit ruhig auftreten kann. 1: 1 ist Ihre Chance, wöchentlich vorbeugende Wartungsarbeiten durchzuführen und gleichzeitig die Gesundheit Ihres Teams zu verstehen.

... Der Sound, der ein erfolgreiches 1: 1-Regime umgibt, ist Stille. Das gesamte Zuhören, Hinterfragen und Diskutieren, das während eines 1: 1-Vorgangs stattfindet, ist vorbeugende Wartung durch das Management. Sie werden sehen, wann das Interesse an einem Projekt nachlässt und Maßnahmen ergreifen, bevor es zu Unzufriedenheit am Arbeitsplatz führt. Sie werden von Spannungen zwischen zwei Mitarbeitern erfahren und eine Diskussion moderieren, bevor sie zu einem schreienden Match in einer Besprechung wird. Ihre Belohnung für eine Kultur des gesunden 1: 1s ist ein deutlicher Mangel an Drama .


Ein sehr starker Punkt des erwähnten Artikels ist, dass er in sich geschlossen ist , in dem Sinne, dass er nicht nur die Vorteile erklärt, sondern auch eine Reihe praktischer Empfehlungen enthält, die es einem grundsätzlich ermöglichen, regelmäßige 1: 1-Übungen zu beginnen, ohne in anderen Quellen zu graben (obwohl er danach sucht) zusätzliche Informationen werden nicht schaden, wissen Sie).

Mücke
quelle
Ich verstehe nicht, wie das mit meiner Frage zusammenhängt.
Ein Teamleiter
@ATeamLead Ich habe die Antwort aktualisiert, um die Verbindung zu verdeutlichen. Grundsätzlich gibt es bei einem regulären 1: 1 weniger Rätsel und Schwierigkeiten, als Sie beschreiben. Wenigstens war , dass meine eigene Erfahrung
gnat
1
+1 Dies ist mit der Frage verbunden, da Probleme wie diese in erster Linie seltener auftreten und in zweiter Linie leichter zu lösen sind, wenn Sie diese Vorgehensweise befolgen.
MarkJ
7

Offensichtlich gibt es hier ein großes Kommunikationsproblem. Er leistet vielleicht fantastische Arbeit, aber wenn Sie das Gefühl haben, nicht zu wissen, was er vorhat, ist das für sich genommen ein Problem. Und wenn Sie nicht wissen, was er tut, dann tun es wahrscheinlich auch seine Kollegen nicht. Dies kann zu Problemen führen, wenn er seinen zwei Wochen alten Code eincheckt. Besonders wenn jemand in einem ähnlichen Bereich arbeitet.

Sie können jederzeit vorschlagen, dass er regelmäßig Updates eincheckt / bereitstellt, um diese Art von Konflikten zu minimieren. Auf diese Weise können Sie Ihre Anfrage in Bezug auf die Unterstützung des Teams formulieren, anstatt "Ich weiß nicht, was Sie tun".

Ich weiß, dass Stand-ups viel Hass bekommen, aber es muss eigentlich nicht im selben Raum stattfinden. Ein kurzer Anruf oder ein Gruppen-Skype-Update einmal am Tag ist sehr schnell und bringt jeden auf die gleiche Seite.

Ich arbeite zurzeit mit einem Team aus Indien in Irland und kann mir nicht vorstellen, nicht jeden Tag mit ihnen in Verbindung zu stehen. Entweder weiß ich ungefähr, woran sie arbeiten, oder ich kann es sehr schnell herausfinden.

Eoin
quelle
Wann hast du den täglichen Standup gemacht?
Ein Teamleiter
1
Wir machen es um 9:30 GMT, was derzeit um 15:00 Uhr indischer Zeit funktioniert. Wir haben mich und ein Team zu einer Telefonkonferenz eingeladen, die nie länger als 15 Minuten dauert und in der Regel in 10 zu Ende ist. Es gibt einige Entwickler aus Irland, die von zu Hause aus arbeiten und die auch anrufen können.
Eoin
7

Zwecklos

Tägliche Statusaktualisierungen sind sinnlos. Es ist lächerlich, wenn Leute berichten, dass ich heute 2,5% vollständig bin, und dass ich heute 3,74% vollständig bin.

Es bietet den Stakeholdern keinen Wert und ärgert die Leute, die die Arbeit machen.

Überlassen Sie sie ungestört ihrer Arbeit.

Unbegründet

Aus welchen Gründen ist Entwickler A Ihrer Meinung nach "unterdurchschnittlich"? Wenn seine Arbeit pünktlich erledigt wird, sollte das gut genug sein.

Sie sagen, Sie hassen Mikromanagement, aber was Sie beschrieben haben, ist genau das.

Unser Unternehmen verlangt von den Entwicklern, dass sie den Arbeitsfortschritt in dem von uns verwendeten Bug-Tracker angeben, nicht nur, um die Programmierer zu überwachen, sondern um die Stakeholder über den Fortschritt auf dem Laufenden zu halten. ... Entwickler müssten die Aufgaben aktualisieren, wenn sie täglich ausgeführt werden.

Das ist sinnloser (so) Quatsch. Ihr Team kippt keine Burger um, sondern erarbeitet technische Lösungen. Fortschritt ist weder linear, noch kann er leicht gemessen oder sogar geschätzt werden. Auch wenn dies der Fall war, haben solche täglichen Messungen oder Schätzungen keinen Wert.

Gefährlich

Untersuchen Sie die Basis für Ihr "Gefühl", dass Entwickler A "unterdurchschnittlich" ist. Sie denken, er / sie könnte es besser machen, aber auf der Grundlage welcher Beweise?

Unglücklich! = Unterdurchschnittlich

Fahren Sie wie beschrieben fort, und irgendwann wird Entwickler A wahrscheinlich entscheiden, dass er / sie unterschätzt wird, dem Unternehmen genug gegeben hat und ein anderes Unternehmen findet. Es ist weitaus weniger wichtig, den Mitarbeitern die letzten 0,01% ihres Aufwands abzunehmen, als sie langfristig zu binden.

Steven A. Lowe
quelle
Wie würden Sie Ihre Entwickler verwalten? Geben Sie ihnen Aufgaben für einen bestimmten Zeitraum, lassen Sie sie tun, was sie wollen, kümmern Sie sich nicht um ihre Fortschritte, und akzeptieren Sie am Ende des Monats resignierend, dass nur ein Teil der festgelegten Aufgaben erledigt wird?
Ein Teamleiter
Es ist dumm,% complete stuff zu verlangen, aber tägliche Stand-ups, IMO, sind ein großer Segen, wenn sie kurz und informell gehalten werden und mehr über die Kommunikation von Bedürfnissen / Herausforderungen und Prioritäten in einem Moment, in dem Sie die Aufmerksamkeit des gesamten Teams haben.
Erik Reppen
1
Ich verwalte meine Entwickler nicht, ich verwalte meine Projekte. Wenn sich ein Entwickler dazu verpflichtet, Aufgabe A in X Tagen zu erledigen, checke ich nach X / 2 Tagen ein, um zu sehen, wie er sich als reine Formalität verhält Frist. Nach X Tagen liefern sie. Wenn Sie Menschen haben, die chronisch zu viel versprechen und zu wenig liefern, wird die Aufforderung, jeden Tag einen imaginären Prozentsatz der erreichten Fortschritte zu ermitteln, nichts an dem grundlegenden Problem ändern (das Schätzungen, Tools, Schulungen usw. sein kann). Prozesse und Zahlen! = Management.
Steven A. Lowe
1
@ErikReppen: Ich stimme der Art der ausgetauschten Informationen zu, bin jedoch der festen Überzeugung, dass solche Informationen in dem Moment, in dem sie entdeckt werden, nur an interessierte Parteien übermittelt werden sollten, anstatt das gesamte Team jeden Tag ohne triftigen Grund abzulenken. Rechtzeitige Kommunikation ist der Schlüssel, nicht Rituale;)
Steven A. Lowe
1
Ich habe in zu vielen Umgebungen gearbeitet, in denen man sich einfach nicht darauf verlassen kann, auch wenn alle Beteiligten so verantwortlich sind, wie sie können. Interessiert oder nicht, jedes Mitglied eines Teams sollte sich der Hindernisse bewusst sein, auf die seine Teamkollegen stoßen. Es geht nicht um Manager gegenüber Mitarbeitern, sondern um ein Team, das zusammenarbeitet. In Szenarien, in denen dies nicht der Fall ist, würde ich zustimmen, dass dies nur eine weitere nutzlose Ablenkung ist.
Erik Reppen
5

Entwickler mögen den Aufwand hassen, das zu dokumentieren, was sie tun, und den Status zu aktualisieren - aber das gehört dazu, ein professioneller Entwickler zu sein. Ich würde vorschlagen, dass Sie versuchen, ihn darauf hinzuweisen, dass seine späten Aktualisierungen Ihres Problemprotokolls eine unnötige negative Wahrnehmung seiner Arbeit hervorrufen. Wenn er nicht sieht, dass seine Kommunikationsstörung ein Leistungsproblem ist, sind Sie sein Teamleiter. Sag ihm, dass es ist.

Schätzung - das ist ein klassisches Problem. Ich empfehle "Software Estimation - Demystifying the black art" von Steve McConnell zu lesen. In diesem Fall erwecken Sie den Eindruck, dass die meisten Entwickler dies unterschätzen. Dies ist seltsamerweise normal und wird nur selten angesprochen. Ich würde vorschlagen, dass Sie ein Problem mit dem Schätzungsprozess selbst haben, und nicht mit dieser einen Person.

Versuchen Sie, den Kreislauf der Überprüfung von Schätzwerten zu schließen und zu verbessern. Wenn Ihre Entwickler dann regelmäßig pünktlich eintreffen und diese Person nicht, können Sie überlegen, was Sie mit ihr tun sollen.

Schließlich haben Sie das Stand-up-Meeting. Auch wenn es per Instant Message ist. Alles, was Sie wollen, ist, dass jeder weiß, "was ich getan habe, was ich heute tue, irgendwelche Probleme". Und wenn es Probleme gibt, nehmen Sie sie für eine spätere Diskussion offline. Das habe ich schon mal gemacht und es war erfolgreich für dieses Team.

Andy Burns
quelle
4

Warum sind deine Sprints so lang? Sprints sollten niemals länger als zwei Wochen dauern. Ich denke, der größte Teil Ihres Problems liegt dort. Ich würde Ihnen empfehlen, die Sprintzeit probeweise zu verkürzen und Ihre Frage dann erneut zu analysieren.

Was ist mit den Code-Check-Ins? Überprüft er ständig seinen Code? Ich persönlich denke, dass Programmierer nicht wirklich Management-Leute sind und je mehr Sie versuchen, damit umzugehen, desto mehr werden sie frustriert. In der Tat hasse ich es, diese Update-Aufgaben zu erledigen und wahrscheinlich sind PMs und Leads deswegen da. Gleichzeitig gebe ich bei Scrum-Meetings oder bei jedem Treffen einen Status. Wenn Sie nun eine Aufgabe zuweisen, weisen Sie sie einer Zeitleiste zu, oder weisen Sie ihnen die Zeitleiste zu?

Daher kann ich nur feststellen, ob jemand unter Leistung leidet, indem ich die festgeschriebene Zeitachse auf% der geleisteten Arbeit abbilde. Wenn nun jemand sagt, dass es zwei Tage dauern wird, eine Methode zu schreiben, die zwei Zahlen addiert, wissen Sie, dass es ein Problem gibt, daher sollte der Zeitplan etwas Realistisches sein und von beiden Parteien vereinbart werden.

Gehen Sie so vor: Wenn Sie in einer Stunde einen Code schreiben können, geben Sie ihm eine Stunde + etwas Puffer. Wenn er dir das in dieser Zeit liefert, denke ich, dann geht es euch gut. Wenn dies nicht der Fall ist, fragen Sie ihn und später können Sie entscheiden, ob er eine vernünftige Erklärung abgibt oder nicht.

Sie können beispielsweise XPlanner in das Versionierungstool integrieren.

Bytekoder
quelle
Was ist mit den Code-Check-Ins? Überprüft er ständig seinen Code? Nein, tut er nicht - er checkt erst ein, wenn er mit einem Feature fertig ist, und das könnte eine Woche dauern, was den Check-in angeht. Wenn Sie eine Aufgabe zuweisen, weisen sie diese einer Zeitleiste zu, oder weisen Sie ihnen die Zeitleiste zu? Sie fühlen sich dem verpflichtet.
Ein Teamleiter
1
Das ist wieder ein Problem! Was ist, wenn etwas mit seiner Maschine passiert? Ich denke, er sollte jeden Tag seinen Code einchecken. Ich verstehe, dass ein nächtlicher Build abgebrochen werden kann, wenn sein Code einen Fehler aufweist, aber gleichzeitig ist es nicht schwer, Fehler bei der Kompilierung zu beheben, es sei denn, er codiert auf dem Notizblock lol.
Bytekoder
Außerdem gibt es viele nicht triviale Programmieraufgaben, die sich nicht so leicht abschätzen lassen. Und natürlich erledigt jeder einzelne Programmierer - per Definition - diese Art von Aufgaben anstelle der Programmieraufgaben, die er zuvor erledigt hat (Warum sollten Sie etwas wiederholen, das Sie leicht wiederverwenden können?). Das macht die Schätzung sehr, sehr schwierig und ich werde sie nicht bemängeln, selbst wenn ihre Schätzung sprunghaft fehlt
A Team Lead
2
@Bytekoder, es gibt Tausende von Laufzeit- / Logikfehlern, die eine Anwendung beschädigen. Ihre Code-Kompilierung bedeutet nicht, dass sie stabil ist.
Ein Teamleiter
2
-1. Die Länge des Sprints ist kaum das Problem. Und das häufige Einchecken von Code in den einzigen verfügbaren Zweig wird nur dazu dienen, den Build zu unterbrechen.
Amadeus Hein
4

Ich glaube nicht, dass sich der Programmiererberuf von Natur aus von anderen Berufen unterscheidet, wenn es darum geht, jemanden zu identifizieren, der nachlässt. Möglicherweise müssen Sie mit Ihrem Bauch gehen.

Ich persönlich finde es seltsam, dass sich A wochenlang weigert, Updates zur Verfügung zu stellen. Ich bin ein Programmierer, der von zu Hause aus arbeitet, und zwischen mir und meinem Arbeitgeber besteht ein impliziter Vertrag, der mich täglich über meine Fortschritte informiert. Dies sind keine "offiziellen" Updates, es ist nur eine kurze E-Mail oder eine Sofortnachricht, die ihn darüber informiert, was mit der Software passiert, für deren Erstellung ich bezahlt werde. Das Update dauert weniger als eine oder zwei Minuten und bietet uns beiden die Möglichkeit, es zu schließen. Für Fehlerbehebungen markiere ich das Ticket bis zum Ende des Tages in unserem Bug-Tracker als behoben. Dies sind keine schwierigen Vorgänge für mich, obwohl ich eine entspannte Arbeitsumgebung mit sehr wenig Papierkram mag.

Selbst gelegentliche Updates von ihm wären sehr willkommen, da bin ich mir sicher. Sie klingen in Ihrem Beitrag sehr, sehr nachsichtig. Wenn Sie den Verdacht haben, dass er über einen längeren Zeitraum nachlässt, brauchen Sie keine weitere Entschuldigung, um mit ihm darüber zu sprechen.

UndergroundHero
quelle
0

Tägliche Stand-ups, auch wenn Sie über Skype oder in einem Chatroom sind, sind der Weg dorthin, aber nicht, wenn Sie dies als Update für die Stakeholder betrachten. Wenn das gesamte Team einmal am Tag eincheckt, um mitzuteilen, woran es gearbeitet hat, welchen Herausforderungen es sich gegenübersieht und was es als Nächstes vorhat, gibt es mehrere Siege:

  • Unabhängig davon, ob Sie aus guten oder schlechten Gründen Zeit verschwenden, wird die Tatsache, dass etwas zu lange dauert, transparenter, und Ihre Entwickler werden ermutigt, bei Bedarf um Hilfe zu bitten, ohne übermäßige Recherchen anzustellen, die wahrscheinlich nicht durchgeführt werden mussten oder ein Problem zu lösen, um es zu lösen, wenn der Rest des Teams etwas dazu beiträgt, es viel schneller auszuschalten.

  • Als Manager können Sie erkennen, wo am häufigsten Straßensperren auftreten. Auf diese Weise können Sie fundamentale Probleme, die Zeit und Geld kosten, besser einschätzen und möglicherweise lösen.

  • IMO, es hilft dem Team wirklich zu lernen, Schätzungen besser zu unterschätzen, wenn es sieht, wie lange es normalerweise für alle dauert, bis manchmal sogar relativ einfache Dinge erledigt werden.

  • Sie werden oft an Dinge erinnert, die im Hinblick auf eine erneute Priorisierung kommuniziert werden müssen, wenn Ihre Teammitglieder Ihnen mitteilen, was sie als Nächstes vorhaben.

Also vergiss '% of complete'. Machen Sie den Prozess einfach so, dass jeder mit sich selbst wie mit allen anderen ehrlich wird, und machen Sie bessere / zuverlässigere Schätzungen, wenn sie mehr Erfahrung damit sammeln -Numerierende Übung, eine Zahl auf etwas zu setzen, das man wirklich nicht kann.

Es hört sich so an, als würde das obere Management verstehen, dass Fristen nicht immer eingehalten werden. Wenn Sie täglich aufstehen, erhalten Sie mehr Munition, da Sie genauere Vorstellungen darüber haben, warum sie nicht getroffen werden.

Und mach sie nicht als erstes. IMO immer ein Fehler. Die Menschen brauchen Zeit, um sich wieder auf das Problem einzulassen, bevor sie zuverlässiger über alle Probleme berichten können, IMO.

Schnelle Stand-ups, bei denen es mehr um Kommunikation als um Rechenschaftspflicht geht und bei denen es vor allem darum geht, Ziele zu setzen, machen meiner Meinung nach agiles Arbeiten aus. Den Rest konnte ich mir nehmen oder gehen lassen, insbesondere Scrum, das ich als Executive / Stakeholder-Schlangenöl angesehen habe.

Erik Reppen
quelle
0

Underperforming?

Die Intensität schwindet während der Karriere einer Person. Wenn er mehr wert ist als er kostet, dann rede mit ihm und versuche, seine Arbeit zu erleichtern. Oder fangen Sie an, nach einem Ersatz zu suchen.

Kommunikation

Verlassen Sie sich nicht auf wöchentliche Treffen. Die meisten Leute werden keinen vollständigen Braindump machen. Weitere 1: 1s einplanen. Fragen Sie sie, wie die Dinge laufen, was Sie besser können und was Sie für besser halten. Manchmal gibt es nichts zu besprechen, aber das ist in Ordnung. Wenn Sie mehr 1: 1 haben, erhöhen Sie die Wahrscheinlichkeit, dass sie sich daran erinnern, etwas zu erwähnen.

Beharrlicher kommunizieren

Sie können mehr Informationen von Menschen erhalten, wenn Sie nicht das Gefühl haben, dass dies eine zusätzliche Aufgabe ist. Wenn sie alle remote sind, lassen Sie sie ein Chat-Programm mit Protokollierungsfunktionen wie Hipchat oder IRC verwenden. Wenn Sie ein beständigeres Kommunikationsmittel haben, werden Sie ermutigt, mehr zu reden. Gehen Sie mit gutem Beispiel voran und sprechen Sie häufig, um andere zu ermutigen, dasselbe zu tun. Lassen Sie die Leute mindestens einmal am Tag sagen, wo sie mit ihren Projekten sind. Manchmal kann man durch einen Blick auf den Chat ein Gefühl dafür bekommen, wie sich die Dinge entwickeln.

Quellcodeverwaltung

Lassen Sie jeden seinen Code täglich einchecken. Wenn Sie git verwenden, lassen Sie sie in ihre eigene Filiale auf dem Firmen-Repo pushen. Anhand der Commits können Sie erkennen, wie sie sich entwickeln.

Trennen Sie die Mittel von den Zwecken

Die Stakeholder wollen auf den neuesten Stand gebracht werden? Gehen Sie selbst mit den Interessengruppen um. Ein Teil Ihrer Arbeit als Manager ist es, der Scheißregenschirm zu sein, damit sich Ihre Programmierer auf ihre Arbeit konzentrieren können. Sehen Sie sich die Chat-Protokolle und Commits an und schreiben Sie eine Zusammenfassung über den Stand der Dinge.

Rog182
quelle
-7

Das sind meine Vorschläge:

  1. Innovation: Fantasie und Kreativität werden eingesetzt, um Kosten zu senken und die aktuelle Situation zu verbessern.

  2. Corporation: Bereitschaft, anderen beim Erreichen ihrer Ziele zu helfen

  3. Initiative: Nicht routinemäßige Jobs und Aufgaben ausführen.

  4. Anwesenheit: Abwesenheiten oder Verspätungen, unter den Standards.

  5. Wachsamkeit: Fähigkeit, neue Informationen und Situationen schnell zu verstehen

  6. Genauigkeit und Qualität: Codeüberprüfungen, pünktliche Lieferung, Ausgaberate).

Ahmed Essawy
quelle