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

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.

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.

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).}

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.

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.

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.

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.

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.

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.

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.

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).