Sollte ich einen langsameren Entwickler zwingen, das Tool zu wechseln, um zu versuchen, seine Geschwindigkeit zu erhöhen?

Ich habe einen Entwickler in meinem Team, der zwar qualitativ hochwertigen Code liefert, aber deutlich langsamer ist als die anderen Entwickler in meinem Team. Dies verursacht einen ziemlich ernsthaften Engpass, den ich zu lösen versuche. Mittel- bis langfristig wird es anderen Teammitgliedern ermöglichen, das Team funktionsübergreifend zu machen, um die Geschwindigkeit zu erhöhen, aber ich schaue nach jeder Möglichkeit, um die Leistung dieses bestimmten Entwicklers zu steigern (insbesondere, da das Projekt am Ende ist Risiko einer Budgetüberschreitung).

Dieser spezielle Entwickler programmiert immer noch gerne "old skool". Das heißt, er verwendet einen Texteditor zum Codieren, eine Befehlszeile für jede mögliche Situation, und wenn er die Möglichkeit hätte, seine Maus und alle visuellen Hilfsmittel zu entfernen, würde er es tun. Er ist ausdrücklich klar: Sie wollen nichts anderes tun als programmieren, am liebsten dort, wo sie keinen Kontakt zu anderen Menschen haben, und am liebsten zu Hause. Absolut keine Meetings, keine Diskussionen, er will die anfallenden Aufgaben selbst erledigen und erledigen. Der Versuch, Agile einzuführen, wird eine Herausforderung sein. Er hat nicht viele andere Aufgaben, 95 % seiner Arbeit ist Code.

Nun, ich bin nicht dagegen , dass Entwickler sich weigern, Schnittstellen, Mäuse und IDEs zu verwenden, wenn sie sich das Leben schwer machen wollen (persönlich denke ich, dass es nur ein Show-Off-Move ist und meiner Meinung nach die Entwicklungszeit erheblich verlangsamt), aber wenn Velocity ist unterdurchschnittlich betrachte ich dies als eine der Optionen, um die Leistung zu steigern.

Die Frage ist also, ist es fair und liegt in meiner Zuständigkeit, den Entwickler zu bitten, auf eine IDE umzusteigen, um die Geschwindigkeit zu verbessern? Meiner Erfahrung nach hat dies eine drastische Verbesserung der Zeit zur Erledigung einer Aufgabe zur Folge, aber ich habe das Gefühl, dass es ihn in eine Ecke zwingen und ihm etwas wegnehmen würde, das ihm wirklich Spaß macht, was der Motivation nicht helfen wird.

Für diejenigen, die sagen "es gibt mehr Flexibilität/Leistung!", Ich verstehe diesen Punkt, und die Befehlszeile ist immer für die 2% der Zeit da, die Sie brauchen. Für den Rest der Zeit wurden IDEs und visuelle Schnittstellen aus einem bestimmten Grund entwickelt: Geschwindigkeit und Benutzerfreundlichkeit. Ich glaube nicht daran.

Bearbeiten: Zur Verdeutlichung, ich bin ein neues Mitglied des Teams, das als Projektmanager eingestellt wurde, aber ich bin auch ein ehemaliger leitender Entwickler, der erheblich mehr Erfahrung hat als die anderen Entwickler im Team. Mir wurde freie Hand gegeben , Architektur- und Entwicklungsentscheidungen zu treffen, um dieses spezielle Projekt, das in ernsthaften Schwierigkeiten steckt und für den Erfolg des Unternehmens von entscheidender Bedeutung ist, wieder in Gang zu bringen.

Edit2: Ein häufiger Vorschlag hier ist, den Entwickler zu fragen, was seiner Meinung nach dazu beitragen wird, seine Geschwindigkeit zu verbessern. Ich habe das schon ein paar Mal gemacht, aber es kommt keine brauchbare Antwort: "Ich werde darüber nachdenken", was nicht passiert. Das ist einer der Gründe, warum ich auf relativ ungewöhnliche Routen schaue, um zu sehen, ob ich die Produktivität auf andere Weise steigern kann.

Edit3: Es ist klar, dass die gesamte IDE/CLI-Diskussion unlösbar ist; Beide Seiten haben ihre Standpunkte, und wie bei OSX/Windows oder Python/PHP oder ... gibt es keinen richtigen oder falschen Weg. Wenn Sie dazu etwas sagen möchten, gehen Sie zu dieser Diskussion , um weiter mit Ziegelwänden zu sprechen. Die Frage war nicht, ob IDEs besser sind als CLIs, sondern ob ich diesen Entwickler bitten kann, etwas Neues auszuprobieren, um zu sehen, ob es die Geschwindigkeit beeinflusst. Letztendlich können Entwickler mit Lochkarten oder in Minecraft programmieren, wenn sie möchten, solange die Geschwindigkeit vorhanden ist . Bitte beachten Sie, dass es eine viel längere und schwierigere Lernkurve hat, mit CLI effizient zu werden, als dies bei IDEs der Fall ist, und es ist möglich , dass dies hier der Fall ist.

Kommentare sind nicht für längere Diskussionen gedacht; Diese Konversation wurde in den Chat verschoben .
Wie oft müssen Sie seinen Code aufgrund von Qualitätsproblemen im Vergleich zu anderen Teammitgliedern überprüfen? Ist es weniger?
Dutzende Kommentare wurden bereits in den Chat verschoben . Wenn Sie das OP nicht um Klärung bitten, kommentieren Sie es bitte dort oder treten Sie dem Site-weiten The Workplace Chat bei . OP: Bitte bearbeiten Sie Antworten auf nützliche Kommentare in Ihrer Frage, anstatt die Diskussion am Laufen zu halten.
Auch der Werkzeugwechsel ist mit Kosten verbunden. Wenn Sie den Entwickler dazu bringen, zu wechseln, denken Sie daran, dass dies seine Produktivität kurzfristig beeinträchtigen wird, unabhängig vom langfristigen Ergebnis.
Beachten Sie, dass Sie von einer Beziehung zwischen der Entwicklungsumgebung und der Geschwindigkeit ausgehen . Dies kann der Fall sein, aber es kann auch nicht der Fall sein.
„Die Frage war nicht, ob IDEs besser sind als CLIs, sondern ob ich diesen Entwickler bitten kann, etwas Neues auszuprobieren, um zu sehen, ob es die Geschwindigkeit beeinflusst.“ - Nein, sehen Sie sich noch einmal den Titel der Frage an. „Force“ und „ask“ haben zwei ganz unterschiedliche Konnotationen.
Was haben Sie bisher mit Ihrem Team gemacht? Haben Sie sich mit jedem von ihnen zusammengesetzt und besprochen, wofür sie ursprünglich verantwortlich waren? Probleme/Hindernisse, die sie hatten? Wie wollen sie vorankommen? Setzen Sie Ihre eigenen Erwartungen? Bestätigte Fristen und Leistungen?
@dKen Der Rahmen der Diskussion ist strittig. "Force" ist einfach zu stark und zu anmaßend, auch wenn Sie mit Ihren produktivitätssteigernden Ideen recht haben. Versuchen Sie, etwas Demut zu zeigen, wenn Sie sich diesem Entwickler nähern.
Nicht alle Story Points sind gleich, schauen Sie sich nicht nur seine Geschwindigkeit an, schauen Sie sich die Arbeit an, die er produziert hat, ob er die Themen und Probleme angeht, vor denen die anderen Entwickler zurückschrecken. Verbringt er neben seiner eigenen Arbeit viel Zeit damit, Kollegen zu unterstützen? das sind Dinge, die man beachten muss.
Geben Sie Ihrem Mitarbeiter einen Kompromiss. Bieten Sie ihnen eine Woche Homeoffice an, wenn sie einer Woche Arbeit mit einem IDE zustimmen. Dann kannst du beide Wochen messen und vergleichen. Vielleicht arbeiten sie zu Hause schneller und länger? Beachten Sie jedoch, dass es eine Lernphase für neue Tools gibt.
@Jasper Keine rationale oder vernünftige Person kann argumentieren, dass die Entwicklungsumgebung die Geschwindigkeit nicht beeinflusst. Etwas anderes vorzuschlagen ist schlichter Wahnsinn. Ist das hier die Ursache? Ich bin mir nicht sicher, aber es ist zu 100 % eine Möglichkeit, und ich frage mich, ob ich es weiter untersuchen sollte (Tipp: nein, sollte ich nicht. Es gibt viele andere Dinge, die ich zuerst versuchen muss, wie zum Beispiel die Änderung meines Führungsstils ).
@dKen Ich arbeite hauptsächlich mit CLI-Tools und bin der Schnellste in meinem Team. Die Entwicklungsumgebung wirkt sich sicherlich auf die Geschwindigkeit aus, in meinem Fall verlangsamen mich IDEs.
Abgesehen von all den Argumenten über die Vorzüge von IDEs macht mich diese Frage wirklich traurig. Es veranschaulicht einen negativen Trend, den ich in den letzten Jahren gesehen habe, und Agile scheint ihn zu fördern. Es gibt eine Menge Dinge, die in die Bewertung der Nützlichkeit eines Softwareentwicklers über die Entwicklungsgeschwindigkeit hinaus einfließen sollten: Kenntnisse der Tools, des Betriebssystems, des Produkts, die Fähigkeit, vorhandenen Code zu entwerfen und zu analysieren, Debugging-Fähigkeiten usw. Jemand könnte a etwas langsamer beim Programmieren, haben aber enzyklopädische Kenntnisse der verwendeten Sprache. Du willst diese Person nicht verlieren.
Ich würde vorschlagen, die Formulierung „ erfordern “ statt „ erzwingen “ oder „ fragen “ zu verwenden.
Pauschalaussagen der Form „Kein vernünftiger oder vernünftiger Mensch …“ sind ideologisch, nicht rational oder vernünftig.
"Bitte seien Sie sich bewusst, dass es eine viel längere und schwierigere Lernkurve hat, mit CLI effizient zu werden, als dies bei IDEs der Fall ist." Wie können Sie für die gesamte Menschheit sprechen?
Ihre beiden Fragen zu diesem Stapel beziehen sich auf Ihre Interaktion mit Menschen. Sie haben angegeben, dass Ihre Rolle "Carte Blanche" ist, aber Sie sind noch kein Manager oder Teil eines HR-Mitarbeiters. Haben Sie darüber nachgedacht, sich auf die Verbesserung Ihrer sozialen Fähigkeiten am Arbeitsplatz zu konzentrieren? Denken Sie daran, dass Alter, sozialer Hintergrund und kulturelle Normen die Leistung aller Menschen beeinflussen , einschließlich Ihrer eigenen.

Antworten (14)

Das Management muss messbare Ziele setzen.

Sie müssen dann bestätigen, dass der Entwickler diese Ziele erreicht. Wenn nicht, müssen sie handeln.

Wenn Sie mit diesbezüglichen Problemen konfrontiert sind und nicht der Vorgesetzte dieses Mitarbeiters sind, konzentrieren Sie sich auf die Geschwindigkeitsprobleme, wenn Sie mit Ihrem Chef sprechen. Wenn Sie der Manager sind, müssen Sie Ihre Erwartungen klarer formulieren.

Für den Rest der Zeit wurden IDEs und visuelle Schnittstellen aus einem bestimmten Grund entwickelt: Geschwindigkeit und Benutzerfreundlichkeit. Ich glaube nicht daran.

Argumentieren Sie nicht über den „Werkzeuge“-Ansatz, wie Sie es hier getan haben. Es wirkt kleinlich und ist letztendlich sinnlos - einige der besten Programmierer, die ich kenne, lieben/schwören auf vim und sind mit vim produktiver als ich es jemals sein werde. Es geht nicht um die Werkzeuge, es geht um die Gesamtproduktivität.

Jedes Mal, wenn Sie dies einem Manager gegenüber erwähnen, werden Sie mit ziemlicher Sicherheit die Wahrscheinlichkeit verringern, dass er Maßnahmen ergreift.

Wenn Sie sich auf die Tools konzentrieren, können Sie garantiert weder diesen Mitarbeiter noch das Management davon überzeugen, Maßnahmen zu ergreifen, da es sich um eine unbedeutende Anschuldigung handelt, die letztendlich irrelevant ist. Sie müssen sich auf die Ergebnisse (oder das Fehlen von Ergebnissen) konzentrieren.

Nur zur Klarstellung, ich bin der Manager, also sieht es so aus, als wäre es meine Herausforderung, das herauszufinden. Letztendlich haben Sie meine Frage beantwortet, die lautete: „Sollte ich auf einen Werkzeugwechsel drängen?“, also werde ich dies berücksichtigen und verschiedene Ansätze untersuchen. Vielen Dank!
@dKen, das ist wahrscheinlich noch wichtiger, klare Ziele zu präsentieren als Argumente, die auf Tools basieren. Ihre Kollegen werden Sie unglaublich kleinlich finden, wenn Sie versuchen, entweder für einen PIP zu argumentieren oder sogar einen Mitarbeiter zu entlassen, hauptsächlich basierend auf den von ihnen verwendeten Tools.
Ich denke, du hast recht. Der Rest des Teams gedeiht mit dem „selbstverwalteten“ Ansatz, der von Agile kommt, aber dieser eine Entwickler könnte damit zu kämpfen haben (tatsächlich hat er bereits gesagt, dass er den Druck von Aufgaben und Fristen vorzieht, anstatt sich auszusuchen, was er tut selbst). Ich denke, der nächste Schritt besteht darin, vielleicht klare Ziele zu setzen und zuzuweisen, die er leichter einhalten kann. Nochmals vielen Dank für Ihren Beitrag (und ja, ich denke, den Werkzeugen die Schuld zu geben, kommt vorerst nicht in Frage).
@dKen Ihrer Beschreibung nach hat er möglicherweise Probleme mit dem Selbstmanagement und dem Zeitmanagement, und einige Leute bevorzugen mehr Struktur, während andere mit weniger Erfolg haben. Es ist möglich, dass es sich um ein Problem handelt, bei dem die Arbeit erweitert wird, um ihren Platz auszufüllen - insbesondere, wenn sie konsistent sind. Möglicherweise müssen Sie mit ihnen an engeren Fristen mit regelmäßigerer Berichterstattung als Ihre anderen Mitarbeiter arbeiten – individuelle Strategien wie 15-minütige Berichterstattung am Ende des Tages, morgendliche Zielsetzung usw. Sie müssen experimentieren, um den richtigen Weg zu finden funktioniert für sie, aber nichts davon wird funktionieren, wenn Sie das Problem nicht klar kommunizieren.
Meine Perspektive auf die Tools ist zweigeteilt: 1) Sie scheinen davon überzeugt zu sein, dass ihre Weigerung, eine IDE zu verwenden, Sturheit ist, aber Sie könnten ebenso stur und falsch sein. Ich habe früher auf einem System gearbeitet, auf dem mich IDEs normalerweise verlangsamt haben, außer beim schrittweisen Durchlaufen des Codes. In meinem aktuellen Projekt ist eine IDE ein Glücksfall. Es kommt auf die Person und das Projekt an. 2) Der Entwickler könnte in seiner Komfortzone stecken bleiben, in diesem Fall scheint es fair, dass er gezwungen ist, verschiedene Tools auszuprobieren, aber wenn er es ehrlich versucht und es ihm nicht hilft, sollten Sie sich zurückziehen und es zulassen Sie benutzen ihre Werkzeuge.
Als neuartige Idee, nachdem Sie Ihre Bedenken und Erwartungen artikuliert haben, warum fragen Sie den Entwickler nicht, was seiner Meinung nach seine Geschwindigkeit verbessern würde?
@dKen, wenn die Person behauptet, dass sie mit einer persönlichen Aufgabenliste besser abschneiden würde, anstatt frei aus allen Teamarbeiten im Scrum (oder usw.) auswählen zu können. Wäre es möglich, diese Behauptung auf die Probe zu stellen und ein paar Wochen lang einen einigermaßen eigenständigen Teil der Arbeit zu schneiden, der seinen „fairen Anteil“ an der Gesamtsumme darstellt, um zu sehen, was passiert?
Hey @dan, ja, das scheint mir das vielversprechendste, was ich mit dem Entwickler ausprobieren könnte. Ich gehe früh zur Arbeit und stelle etwas für ihn zusammen. Mal sehen, wie es geht.
@BrianDHall Nochmals vielen Dank für Ihren Input, Kumpel. Wie vermeide ich, ihm nicht das Gefühl zu geben, dass ich ihn herausgreife, wenn er mehr als die anderen melden muss?
@dKen Ist es Ihr Ziel, ihn nicht herauszuheben oder einfach zu vermeiden, dass er sich herausgegriffen fühlt, während Sie ihn tatsächlich herausgreifen? Es ist nichts Falsches daran, jemanden aus guten Gründen herauszuheben – und ehrlich und offen damit umzugehen. zB "Da wir uns darauf geeinigt haben, einen neuen Arbeitsansatz auszuprobieren, muss ich Sie öfter als die anderen Entwickler melden, um sicherzustellen, dass diese Änderung für uns beide gut funktioniert."
@wjl Mein Ziel ist es, eine nachhaltige Geschwindigkeit zu erreichen. Wenn ich das schaffe, ohne ihn herauszugreifen, verringert sich die Wahrscheinlichkeit, dass er sich angegriffen und isoliert fühlt, was der Moral nicht gut tun wird. Es ist jedoch möglicherweise nicht vermeidbar. Ich habe ihm einige klare Ziele gesetzt, für die er verantwortlich ist, also mal sehen, ob er das Gefühl hat, dass ich ihn deutlich anders behandle als die anderen.
@wjl ein schlechter Manager passt seinen Stil nicht an seine Mitarbeiter an. Sie werden versuchen, für alle ihre Mitarbeiter genau die gleichen Dinge zu tun, unabhängig davon, wie die Mitarbeiter geführt werden möchten. Eine gute Führungskraft erkennt, dass alle Mitarbeiter unterschiedlich geführt werden möchten und passt ihren Stil entsprechend an.
Oft können Sie mit einer CLI mehr automatisieren als mit einer Benutzeroberfläche. Aus diesem Grund findet die serverseitige Entwicklung in Unix-Befehlszeilen und Shell-Skripten statt. Die Existenz eines UI-Tools bewirkt nicht unbedingt mehr, als dass Sie NICHT LERNEN, wie man etwas tatsächlich tut; und die Benutzeroberfläche ist nutzlos, wenn Sie gelernt haben, wie man sie benutzt - und das automatisierte Tool macht einen halbherzigen Job. Wenn dieser Typ "nicht so schnell ist, wie ich möchte", aber "viel Gutes tut", dann weiß er wahrscheinlich, was er tut.

Als Old-School-Entwickler, der Texteditoren und die CLI verwendet, kann ich sagen, dass es nicht unbedingt zu einer Geschwindigkeitssteigerung führt, wenn jemand gezwungen wird, andere Tools zu verwenden.

Das heißt, wenn Sie der Teamleiter sind, ist es im Allgemeinen unklug, das Mikromanagement so weit herunterzuschrauben, dass Sie verlangen, dass er bestimmte Tools gegenüber anderen verwendet.

Entweder er macht seinen Job oder er tut es nicht.

Wenn ja, lass ihn in Ruhe

Wenn dies nicht der Fall ist, beginnen Sie mit dem Prozess, um ihn zu beenden.

Das alte Sprichwort, dass die Verwaltung von Programmierern wie das Hüten von Katzen ist, ist keine Untertreibung der damit verbundenen Schwierigkeiten.

Dieser Teil sticht für mich besonders hervor:

Meiner Erfahrung nach hat dies eine drastische Verbesserung der Zeit zur Folge

Ja, deiner Erfahrung nach. Bei ihm kann es eine schrecklich schädliche Wirkung haben.

Argumentieren Sie niemals auf der Grundlage eines Tools.

Denken Sie daran, der Punkt ist, entweder er macht seinen Job oder er tut es nicht.

BEARBEITET ZUM HINZUFÜGEN::

Vermeiden Sie Mikromanagement um jeden Preis. Alles, was Sie tun, ist, Sie auf ein Scheitern vorzubereiten, da der Mitarbeiter auf drei Arten reagieren kann.

  1. Ärgern Sie sich darüber und lassen Sie ihre Moral sinken
  2. "Delegieren umkehren" und Sie in die Position versetzen, in der Sie die meiste Zeit mit Dingen auf sehr niedrigem Niveau verbringen werden
  3. Scheinen Sie zu gehorchen, verlangsamen Sie und geben Sie dann die Schuld für den Leistungseinbruch. „Ich kam mit meinem Texteditor gut zurecht, dann zwang er mich, dieses Tool zu verwenden, mit dem ich nicht vertraut bin.

Ihre Aufgabe ist es einfach, zu beschleunigen. Stellen Sie sicher, dass Ihr Team über die Tools verfügt, die es benötigt, und beseitigen Sie alle Erfolgshindernisse. Wenn Ihr Ziel bei diesem Mitarbeiter Geschwindigkeit ist, dann setzen Sie sich mit ihm zusammen und besprechen Sie Geschwindigkeit, nicht die Tools. Fragen Sie ihn, wie er in kürzerer Zeit mehr produzieren könnte.

Erwähnen Sie, dass Sie denken, dass die neuen Tools nützlich sein könnten, aber bitten Sie ihn um seine Meinung. Wenn es seine Entscheidung ist, kann er die Werkzeuge freiwillig verwenden, ohne dass die Moral darunter leidet. Er kennt vielleicht andere Tools, die es ihm ermöglichen würden, ohne die IDE oder Tools, die Sie jetzt verwenden, auf den neuesten Stand zu kommen. Denken Sie daran: Das Ziel ist eine Leistungssteigerung, nicht "Verwenden Sie diese Tools oder etwas anderes".

Danke für die Antwort Richard. Er macht seinen Job, aber mit einer deutlich langsameren Geschwindigkeit, als es im Moment tragbar ist. Ich treibe einige Änderungen in unserer Arbeitsweise voran, die sich für den Rest des Teams sehr positiv ausgewirkt haben, aber er widersetzt sich, weil es eine Änderung seines üblichen Prozesses ist. Generally unwise to micromanage: Ich werde manchmal zum Mikromanagement gerufen, aber in Situationen, in denen das Projekt hinter dem Zeitplan zurückbleibt und Aufgaben eine strenge Priorisierung erfordern, um maximalen Nutzen zu erzielen, ist das nicht manchmal notwendig?
@dKen Ich bearbeite meine Frage, um dies zu beantworten ^^^
Danke, tolle Tipps und schöne Bearbeitung. Ich glaube, ich muss meine Vorgehensweise etwas ändern.
Ich denke, jeder ist zu vorsichtig. Ich sage, dass das Ändern der Umgebung ein garantierter Leistungseinbruch ist. Das beste Szenario ist, dass die Leistung nach einiger Zeit ausreichend ansteigt, um die anfänglichen Verluste auszugleichen. Aber diese werden schwer sein – wenn die Projektfrist nahe ist, ist das der beste Weg, sie zu verpassen. Es ist eine einfache Frage der Investition und der daraus resultierenden Rendite.
@dKen Aber hilft dein Mikromanagement objektiv? Oder gibt es dir nur die Gewissheit, dass du etwas tust ? Die meisten Menschen befolgen die Regel „Wenn du nicht reparieren kannst, was kaputt ist, fang an, etwas zu reparieren, was du kannst“, ohne es jemals zu merken. Ich sage nicht, dass dies hier der Fall ist, aber genau das gibt dem Mikromanagement seinen schlechten Ruf.
@Agent_L, du hast Recht mit dem Performance-Hit. Werkzeugwechsel ist jetzt ausgeschlossen. Über MicroManaging leide ich gelegentlich, aber in diesem Fall hat MM das Projekt umgedreht. Die meisten Leute mögen es nicht, MMed zu sein, aber wenn es den Unterschied zwischen einem gescheiterten oder einem erfolgreichen Projekt bedeutet, das ihren Job sichert, dann gibt es keine Wahl. Mein MM war nach allen messbaren Statistiken effektiv, obwohl es sich erwartungsgemäß etwas negativ auf die Moral ausgewirkt hat. Jetzt ist jedoch nicht die Zeit für Sentimentalitäten.
Oder Nummer 4. aufhören, weil er sich nicht mehr wohl fühlt und @dken gerade einen hochwertigen (wenn auch nicht den schnellsten) Coder verloren hat.
@dKen Wenn es objektiv geholfen hat, dann ist es nicht der Fall, worüber ich mir Sorgen gemacht habe :)
@dKen gut, über Erfolg lässt sich nicht streiten, aber sobald das Projekt wieder auf Kurs ist, vergiss nicht, einen Rückzieher zu machen, sonst brennst du aus.
Sicherlich gibt es mehr Alternativen, als ihn in Ruhe zu lassen oder ihn zu kündigen ?!
@gerrit Darauf läuft es oft hinaus, aber ich habe in meinem letzten Absatz Alternativen aufgenommen.
@dKen "Jetzt ist aber nicht die Zeit für Stimmung." Es sei denn, die Stimmung erreicht den Punkt, dass Sie gehen wollen ... Ich würde annehmen, dass das Verlassen Ihrer Entwickler einen negativen Einfluss auf die Einhaltung Ihrer Projektfrist haben würde. Natürlich kann ein Moralschlag auch die Motivation verringern, was die Dinge verlangsamen kann, selbst wenn sie nicht gehen. Das soll nicht heißen, dass Gefühle das A und O sind, nur dass es auch unklug ist, sie komplett zu ignorieren.
Nummer 2 würde ich persönlich machen. „Ok Boss, kann ich jetzt auf Speichern klicken? Ok, soll ich Commit machen? Wie oft sollte ich Commit machen? Wie viele Leerzeichen sind ein Tabulator? Soll ich die Tab-Konvertierung der IDE verwenden oder die Leerzeichen manuell zählen? die IDE, wie soll ich meine Fenster anordnen?Welches Farbschema in der IDE ist Ihrer Meinung nach am produktivsten?Ich kann möglicherweise keinen Code schreiben, bis Sie mir sagen, welches Wörterbuch ich für die Rechtschreibprüfung verwenden soll.Also habe ich diesen einen Teil wo Ich möchte mir die Tabellen beim Erstellen des Modells ansehen, kann ich die Fenster in der IDE nebeneinander platzieren?
Dann hatte ich nach 2-3 Wochen plötzlich woanders einen neuen Job, bei dem ich den Editor meiner Wahl verwenden konnte.
@coteyr Das habe ich selbst gemacht. Ein ehemaliger Manager hat mich immer wieder wie einen Idioten behandelt, also habe ich mich wie einer verhalten, bis er meine Arbeit für mich erledigt hat. Viel Zeit für die Jobsuche gewonnen.

Wie andere angemerkt haben, ist das Erzwingen eines Werkzeugwechsels an und für sich möglicherweise nicht immer der beste Ansatz oder die beste Arbeit. Sie jedoch davon zu überzeugen, dass es in ihrem besten Interesse ist, ein Werkzeug zu wechseln, wird es tun.

Dabei wird ein zweigleisiger Ansatz verfolgt:

  1. demonstrieren Sie ihnen greifbar, dass ein Wechsel des Werkzeugs ihnen hilft, ihre Produktivität zu steigern

  2. Verwenden Sie Ihre Managementhebel, um sie davon zu überzeugen, dass sie ihre Produktivität verbessern müssen , damit sie motiviert sind, eine Antwort darauf zu finden, wie.

    Nr. 2 ist eine Standard-Management-Frage, die etwas außerhalb des Rahmens Ihrer Frage liegt (dies ist Standard-Management 101).

    Der Rest meiner Antwort wird sich darum drehen, wie man Stift Nr. 1 erreicht und sie davon überzeugt, dass ein Werkzeugwechsel ihnen helfen wird, wenn sie daran interessiert sind, ihre Produktivität zu verbessern.

Ein folgender Ansatz könnte zumindest bei einigen Entwicklern besser funktionieren als "Erzwingen": Beweise produzieren . Welchen speziellen Flavor Sie verwenden können, hängt von der Persönlichkeit des einzelnen Entwicklers und Ihrer/seiner Dynamik ab. Einige dieser Ansätze können (und sollten wahrscheinlich) gemischt und aufeinander abgestimmt werden.

  • Ansatz 1: Demo

    Bitten Sie ihn, sich eine Demo (von Ihnen selbst oder einem anderen respektierten Entwickler) anzusehen, wie eine bestimmte Reihe von Aufgaben mit IDE/neuem Tool schneller erledigt wird.

    Wenn sie ein guter Entwickler sind, würden sie zumindest etwas von Beweisen und Logik beeinflusst werden. Sie sind immer noch Fleischbeutel mit Fehlern in der Software (auch bekannt als Mensch), so dass dies aufgrund von Besonderheiten der Verhaltenspsychologie möglicherweise nicht immer so gut funktioniert wie gewünscht, also setzen Sie Ihre Erwartungen entsprechend.

    Sie können dies entweder auf offensichtliche Weise tun (indem Sie es so formulieren: "Ich weiß, dass Sie IDEs nicht mögen, ich möchte Ihnen zeigen, wie sie Ihnen helfen können"); oder weniger offensichtlich ("Hier ist eine Demo für das gesamte Team, sehen Sie mir zu, wie ich in 15 Minuten XYZ mache, damit Sie alle so cool sein können wie ich" - nachdem er selbst einen Tag gebraucht hat, um dasselbe zu tun).

  • Ansatz 2: Herausforderung

    Das funktioniert nicht mit allen Persönlichkeiten; und kann nach hinten losgehen; aber einige Leute sind intensiv wettbewerbsfähig.

    Fordern Sie sie heraus, um zu sehen, wessen Annäherung schneller ist; entweder als Mutprobe; oder als Wettbewerb.

    Als Anreiz; Sie können ihnen versprechen: "Wenn Sie die Herausforderung gewinnen, werde ich das Thema NIE wieder ansprechen und Ihnen eine Woche lang kostenlose Pizza kaufen; wenn Sie verlieren, verpflichten Sie sich, die IDE einen Monat lang zu lernen und auszuprobieren."

  • Ansatz 3: Überwältigen Sie sie mit den Vorteilen des neuen Tools

    Mir persönlich geht es ähnlich wie dem von Ihnen beschriebenen Entwickler. Ich werde die Maus nur benutzen, wenn ich muss; Ich mache Dinge in der Befehlszeile (mit hoher Effizienz), von denen die meisten Leute nicht wissen, dass sie getan werden können; Ich habe meinen Teamkollegen CLI-Fähigkeiten in einem formellen Rahmen beigebracht. Früher habe ich Eclipse und andere IDEs gehasst.

    Was die Dinge für mich verändert hat, war, dass mein Manager mich buchstäblich (oder ist das im übertragenen Sinne? :) zu Tode geritten hat mit "Oh, schau dir DAS coole Ding an, das ich in Eclipse machen kann!" (Einfaches Refactoring. Einfaches Debuggen. „Zur Definition springen“. „Wo wird dieser Bezeichner verwendet?“ suchen. etc...)

    Ich verwende CLI immer noch, wenn dies gerechtfertigt ist; aber ich habe mich bemüht, die Lernkurve für Eclipse zu erklimmen und mit seinen Mängeln Frieden zu schließen, einfach weil der Manager objektiv bewiesen hat, dass es mein Leben als Entwickler besser/einfacher machen wird.

  • Ansatz 4: WICHTIG: Bieten Sie ihnen Hilfe bei der Lernkurve an

    Ein Teil des Widerstands ist wahrscheinlich die Kombination aus Menschen, die Komfortzonen und objektive Schwierigkeiten beim Erlernen der Verwendung moderner IDEs mit einem beliebigen Grad an Kompetenz mögen .

    Ihre Aufgabe als Manager ist es, Barrieren zu beseitigen, die Ihr Team beeinträchtigen; Als solches sind Sie in der Lage, mit letzterem umzugehen.

    Bieten Sie ihnen alle Ressourcen an, die sie benötigen – Schulungsmaterialien; Klassen usw. Nach meiner langjährigen Erfahrung ist jedoch die Hilfe von Ihnen selbst oder von angesehenen Teammitgliedern am hilfreichsten und verlockendsten.

    Wenn sie wissen, dass sie Fragen über die IDE an jemanden stellen können, der sie nicht auf die Art "eh, das ist eine n00b-Sache, du schwachsinniger Idiot" beurteilen wird; sie werden weniger widerstandsfähig sein.

    Wenn sie die Freude erleben , dass ihnen jemand bei einem seltsamen IDE-Problem hilft, würden sie sich weit weniger besorgt fühlen.

Das ist brilliant. Ich glaube nicht, dass eine der anderen Antworten unterschiedliche Möglichkeiten aufzeigte, den Entwickler zu ermutigen, alternative IDEs auszuprobieren, und ich mag die Ansätze (eigentlich haben sie mich mit ihrer Cleverness zum Lachen gebracht). Gute Arbeit.
Es hilft auch, wenn alle im Team dieselbe IDE verwenden, weil sie sich dann alle gegenseitig helfen können, und es ist auch einfacher, vorübergehend auf Paarprogrammierung umzuschalten, wenn Sie auf eine Schwierigkeit stoßen, da Ihr Partner bereits weiß, wie er in Ihrer IDE navigiert.
@Sumyrda Das funktioniert in beide Richtungen. Funktionsübergreifend zu sein, könnte auch das Konzept von IDEs beinhalten; Es gibt keinen Grund, warum sich ein Entwickler nicht in mehr als einer wohlfühlen sollte (ich verwende zum Beispiel verschiedene IDEs für verschiedene Programmiersprachen). Natürlich wirkt sich das zunehmende Lernen auf die Geschwindigkeit aus, aber wenn das mittelfristige Ziel flexiblere, wertvollere und zufriedenere Mitarbeiter sind, dann ist dies Teil der erforderlichen Investition.
Noch eine kleine Ergänzung zum „Challenge“-Ansatz: Es bietet sich an, das Pair Programming im Team einzuführen. Dh mal Leute an einer Maschine zusammenarbeiten lassen. Dadurch wird das Wissen über Tools und Techniken ohne aktive Beteiligung des Managements auf Peer-to-Peer-Ebene verbreitet.
15 Minuten mit einer IDE, ein Tag mit anderen Tools; Was denkst du, verwendet dieser Entwickler, edlin?
@MichaelKjörling - das zusammengesetzte Filmmaterial wurde für dramatische Effekte leicht verbessert :)

Einfach gesagt, Sie sind auf dem falschen Weg. Die Wahl der Tools wird einen Entwickler nicht produktiver machen. Wenn Sie jemanden zwingen, die Werkzeuge zu verwenden, mit denen er nicht gerne arbeitet, wirkt sich dies negativ auf seine Moral aus und macht ihn weniger produktiv. Ich verwende eine ausgezeichnete IDE, wenn ich unter Windows codiere, und Befehlszeilentools, wenn ich unter Linux codiere, und es gibt absolut keinen Unterschied in meiner Produktivität zwischen den Umgebungen - aber das liegt daran, dass ich beides mag.

Um den Entwickler produktiver zu machen, sprechen Sie mit ihm und fragen Sie, was ihn motivierter machen würde. Es ist wirklich ein HR-Problem, kein technisches.

Schön formuliert, danke. Ich bin der PM hier, also liegt es auf meinen Schultern. Sieht so aus, als ob das Problem woanders als bei den verwendeten Tools liegt.
Ich verwende auch die Befehlszeile und den Texteditor unter Linux und IDE unter Windows. Zum Teil, weil ich keine IDE gefunden habe, die mir für Linux gefällt. Aber es gibt noch einen weiteren wichtigen Effekt, den ich bemerke, wenn ich keine IDE verwende (obwohl dies möglicherweise nicht zu Ihrer Situation passt) - ich muss viele Dinge auf einer viel niedrigeren und spezifischeren Ebene verstehen. Ich muss die Build-Dateien von Hand schreiben und die Projekte so entwerfen, dass sie sinnvoll sind und ohne IDE einfach zu bearbeiten sind. In der Zwischenzeit sind meine Windows-Projekte, die IDE verwenden, so organisiert, wie es die IDE will, haben große undurchsichtige/automatisierte/abhängige Bereiche und fühlen sich anfällig für seltsame IDE-Probleme.
Ein weiterer Faktor hierbei ist, dass unterschiedliche Menschen unterschiedlich denken. Ich denke einfach nicht visuell (oder intuitiv), also funktioniert es einfach nicht, mich dazu zu bringen, effektiv mit irgendetwas zu arbeiten, das Symbole anstelle von Wörtern beinhaltet. Ich weiß nur nicht, was sie bedeuten sollen, außer in den wenigen Fällen, in denen ich gebräuchliche auswendig gelernt habe.
Die Verwendung besserer Werkzeuge verbessert die Produktivität absolut. Zu sagen, dass dies nicht der Fall ist, ist komisch.
"Die Wahl der Tools wird einen Entwickler nicht produktiver machen." - vermutlich würden Sie bereitwillig zustimmen, dass die Wahl der Tools einen Entwickler weniger produktiv machen kann? In diesem Fall sieht Ihre Behauptung etwas wackelig aus, nicht wahr?
@Davor. „Besser“ ist eine Meinung, keine Tatsache. Einige Tools sind für manche Menschen in manchen Umgebungen besser. Ich bin mir absolut sicher, dass es seine Produktivität nicht verbessern wird, einen Entwickler, der mit Befehlszeilentools vertraut ist, zur Verwendung einer IDE zu zwingen.
Es ist wirklich ein HR-Problem, kein technisches. Ich würde sagen, es ist ein Sprung, dies anzunehmen. Es könnte wirklich beides sein. Vielleicht schöpft diese Person mit ihrem gewählten Werkzeugsatz ihr Potenzial aus.
@Davor: Ich glaube nicht, dass irgendjemand anderer Meinung ist, dass die Verwendung besserer Tools die Produktivität verbessert. Worüber wir uns nicht einig sind, ist die Definition von "besser". Um einen Randfall zu nehmen, die meisten von uns würden zustimmen, dass ein hochauflösendes 24-Zoll-Display besser ist als ein 14-Zoll-CRT, oder? Aber wenn Sie zufällig einen blinden Programmierer haben, der für Sie arbeitet, wird die Aufrüstung seines Displays die Produktivität steigern?
@Davor: OK, also bin ich ein lächerlicher Elitär :-) (Und ein guter, anpassbarer Programmiereditor ist kein "Notizblock".) Aber ich denke, fast jeder vermisst hier einen wichtigen Punkt, nämlich das, es sei denn, Sie sind es Wenn Sie absolut triviale Codierung durchführen (für die Sie wahrscheinlich eine schnelle Dateneingabeperson einstellen könnten), wird die meiste Zeit dem Denken gewidmet sein, nicht dem Tippen/Mausen oder anderweitigen Interagieren mit CLI-Tools oder IDE. Tatsächlich habe ich einige meiner produktivsten Momente beim Wandern erlebt.
@jamesqf Eine gute IDE ist jedoch nicht nur beim Tippen hilfreich. Es ist auch unglaublich hilfreich für das Debugging (z. B. in der Lage zu sein, Code schrittweise zu durchlaufen und schnell die Werte relevanter Variablen anzuzeigen), verwandten Code zu finden (z. B. schnell alle Verwendungen eines bestimmten Symbols zu finden oder zur Definition eines bestimmten Symbols zu navigieren), Änderungen im Laufe der Zeit zu sehen ( zB mit visualisierten Diffs und Source-Control-Integration,) schneller Zugriff auf relevante Dokumentation, etc. Dies alles trägt dazu bei, den Denkteil zusätzlich zu den Beschleunigungen im Tippteil zu beschleunigen. Allerdings bin ich auch im IDE-unter-Windows-, vim-unter-Linux-Camp.
@reirab: Ich stimme zu, dass ein guter Debugger sehr nützlich ist. Die Frage, die ich stellen würde, ist, ob die in IDEs eingebetteten wesentlich besser sind als gdb &c? Ebenso sind die Möglichkeit, Symbole zu finden, die Dokumentation einzusehen, &c nützlich, und das sind hauptsächlich Dinge, die ich mit meinem Befehlszeilen-Editor tun kann. Ich wage zu behaupten, dass ich sie alle machen könnte, wenn ich sie häufig genug machen müsste, um den Aufwand für das Schreiben von Makros zu rechtfertigen.
@jamesqf Zum größten Teil sind IDEs (unter Linux) ohnehin nur ein Wrapper für gdb. Abhängig von der Situation kann ich mein Debugging von c++ über Eclipse durchführen, weil dessen GUI besser ist als ddd, oder ich kann gdb von der Befehlszeile aus ausführen, während ich in emacs bearbeite. In vielen Fällen ist der Befehl like schneller und einfacher, um die Antwort zu erhalten, die ich brauche. Es ist schön, viele Optionen zu haben.
@NemanjaTrifunovic Nehmen wir an, ich war Manager bei einem Bauprojekt und einer meiner Mitarbeiter hat Nägel mit einem Schraubenschlüssel eingeschlagen. Wenn er alle anderen überholt hat, dann ja, er kann jedes Werkzeug verwenden, das er will. Wenn er jedoch anfängt, der langsamste Hammer zu werden, dann ist es vielleicht an der Zeit, ihm zu sagen, dass er auf einen Hammer umsteigen soll. Ich bin nicht hier, um zu entscheiden, ob die Metapher auf CLIs oder IDEs zutrifft, aber es ist sicherlich möglich, dass ein Tool objektiv besser ist.
@LordFarquaad. Eine schöne Analogie, aber ich habe speziell über Softwareentwicklung gesprochen, von der ich ein oder zwei Dinge verstehe, im Gegensatz zu Konstruktion.
@NemanjaTrifunovic Ich verstehe. Wenn mich jemand von Eclipse auf IntelliJ umstellen würde, weil „es besser war“, wäre ich für lange, lange Zeit verloren. Aber ich war irgendwie gezwungen, Eclipse anstelle von vim zu verwenden, und das verbesserte meine Produktivität sprunghaft. Offensichtlich gibt es viel zu viele Faktoren, um durch eine Frage wie diese zu entscheiden, ob der Entwickler auch mit einem Wechsel besser bedient wäre (und ich stimme zu, dass es bessere Optionen gibt, die man zuerst ausprobieren kann), aber ich hatte gehofft, ein nicht domänenspezifisches Beispiel dafür zu machen zeigt, dass auf beiden Seiten des Arguments eine gewisse Gültigkeit bestehen könnte.

Sie sind hier viel zu selbstbewusst in Ihrem Urteil.

Ich habe oft beobachtet, dass Leute, die mit Tastaturschnittstellen nicht fließend sind, dazu neigen, stark zu unterschätzen, wie effektiv eine gute Tastaturschnittstelle von jemandem verwendet werden kann, der es ist. Doppelt so, wenn die Schnittstelle erweiterbar ist und von jemandem verwendet wird, der sich mit der Konfiguration auskennt.

Sie klingen sehr nach einer solchen Person.

Erschwerend kommt hinzu, dass Ihr Posting ziemlich nachteilig wirkt.

Folglich halte ich es für äußerst unklug, zu versuchen, dieses Problem zu erzwingen.

Das heißt, Sie glauben eindeutig daran und sind daran interessiert, eine Konvertierung durchzuführen. Sie müssen sich daran erinnern, dass das Wechseln der von Ihnen verwendeten Werkzeuge eine ziemlich holprige Fahrt sein kann, insbesondere wenn das neue Werkzeug sich stark von dem unterscheidet, an das Sie gewöhnt sind.

Meiner Meinung nach ist der beste Weg, dies anzugehen, die Hindernisse zu beseitigen, um den Übergang zu glätten. Die Antwort von DVK geht darüber gut hinweg.

Aber Sie müssen bedenken, dass dieser Entwickler andere Erfahrungen hat als Sie.

Beispielsweise halten Sie es vielleicht für keine große Sache, ein neues Projekt in Ihrer bevorzugten IDE zu starten. Der neue Benutzer wird jedoch mit einer verwirrenden Reihe von Optionen konfrontiert, deren Auswirkungen er nicht versteht. Und wahrscheinlich vergleichen sie den Prozess ständig damit, einfach eine Tastenkombination zu drücken, um eine neue Datei in ihrem alten Tool zu öffnen, und fragen sich, warum das neue Tool die Dinge so kompliziert machen muss.

Beachten Sie, dass Sie andere potenzielle Optionen haben, um eine höhere Produktivität zu erreichen. Sie haben seine Arbeit als qualitativ hochwertiger eingeschätzt, also weisen Sie ihm Aufgaben zu, bei denen Qualität von größerer Bedeutung ist. Sie erzielen Ihre Produktivitätsgewinne, indem Sie Ihren schnellen Entwicklern erlauben, andere Aufgaben zu erledigen und schneller voranzukommen, anstatt sie in eine Aufgabe zu verstricken, die mehrere Iterationen durchlaufen muss, um ihren Code aufzupolieren.

Das Tastatur-Maus-Problem ist etwas, das diese Antwort berührt (und andere nicht), das wichtig ist. Einige Leute denken Wetten auf die Home-Tasten und brechen ihren Gedankengang ab, wenn sie zwischen Tastatur und Maus wechseln, während es für andere keine Rolle spielt. Ich schreibe heutzutage nicht viel Code (und benutze einen Texteditor), aber ich fand die IDEs, die die Verwendung der Maus erfordern, eine echte Qual. Eine gut gestaltete IDE mit guten Tastenkombinationen kostet Sie nur die Strafe, eine Menge neuer Tastenkombinationen im Vergleich zum Editor zu lernen, zwingt dieser Person eine ungeeignete IDE auf und Sie werden die Produktivität nie zurückerhalten.
Die Person, die die Tastaturschnittstelle verwendet, ist möglicherweise auch nicht fließend. Es gibt gute Entwickler, die sich hauptsächlich auf die Tastatur verlassen, aber nur weil jemand eine IDE meidet, heißt das nicht, dass er eine Art Old-School-Ninja ist.
@Chris H: Ein guter Editor oder eine IDE sollte Sie nicht dazu zwingen, Verknüpfungen zu lernen, sondern es Ihnen ermöglichen, Ihre Verknüpfungen zu DEFINIEREN. Und erlauben Sie, dass diese Abkürzungen so komplex wie gewünscht sind, wie z. B. meine Tastenkombination, die make ausführt, wenn ich gerade C/C++ codiere, oder LaTeX, wenn ich an einer tex-Datei arbeite ...
You've judged his work as being of greater quality- Die ursprüngliche Antwort nannte es "gut", was sich als angemessen liest. Es wird nicht als überlegen erwähnt.
"Ich habe oft beobachtet, dass Leute, die mit Tastaturschnittstellen nicht fließend sind, dazu neigen, stark zu unterschätzen, wie effektiv eine gute Tastaturschnittstelle von jemandem verwendet werden kann, der" Ich kann sagen, dass ich das Gegenteil gesehen habe. Ich habe die Erfahrung gemacht, dass Leute mir sagten, wie schnell ihr mausfreier Stil ist, und dann beobachteten, wie quälend lange es dauert, bis sie die grundlegendsten Dinge tun.

Stellen Sie sicher, dass diese Person langfristig kein besserer Programmierer ist. Er bringt Features vielleicht langsamer heraus, aber wenn sie von höherer Qualität sind, ist es schwierig, dagegen zu argumentieren.

Dinge nicht schnell genug zu erledigen, um das Budget einzuhalten, ist Teil seines Jobs. Jemand, der dafür verantwortlich ist, muss eingreifen und auf eine Korrektur hinarbeiten. Vielleicht muss er Hilfe zur Rechenschaft ziehen. Hoffentlich wäre jemand bereit, mit ihm zusammenzuarbeiten, um dieses Problem zu lösen, bevor drastische Maßnahmen ergriffen werden. Vielleicht ist es die Verwendung anderer Tools. Seien Sie nicht überrascht, wenn Sie ihn zu einem Wechsel zwingen, der seine Produktivität verringert. Diese Dinge brauchen Zeit und sind schlimmer, wenn die Person nicht glaubt, dass es hilft, und nicht motiviert ist.

Anscheinend ist sich dieses Problem jetzt einem Verantwortlichen bewusst oder er unternimmt nichts dagegen. Vielleicht haben sie das Gefühl, dass der Rest des Teams die Lücke schließen wird? Ich würde diese Person wissen lassen, dass Sie dies nicht beabsichtigen, insbesondere wenn sie keine Kompromisse eingehen und andere Tools verwenden wird.

Danke @JeffO. Ich bin hier der Manager, also liegt es direkt auf meinen Schultern, herauszufinden, wie es funktioniert. Ich weiß es zu schätzen, dass Sie gesagt haben, dass das Tool " das Problem sein könnte ", anstatt andere, die es als überhaupt nicht möglich ausgeschlossen haben, was meiner Erfahrung nach einfach nicht stapelbar ist. Ich habe viel zu bedenken.
Wenn Sie so stark davon überzeugt sind, sollten Sie in einer Art Paired-Programming-Situation neben ihm sitzen und ihm bei der Arbeit zusehen. Wenn er das Gefühl hat, dass er der bessere Weg ist, ist das der einzige Weg, wie ich sehe, dass er entweder Ihre Meinung ändert und Sie dies ausschließen können.
Ihr erster Satz ist ein sehr wichtiger Punkt, denke ich: "Stellen Sie sicher, dass diese Person auf lange Sicht kein besserer Programmierer ist.". Die meisten sehr guten Programmierer, die ich kenne, sind nicht unbedingt schnelle (und schlampige) Programmierer. Sie sind Codierer, bei denen Sie nicht umgestalten müssen, sobald sie fertig sind. Vergleichen Sie das mit jemandem, der rechts und links neue Bugs produziert oder Dinge nicht zu Ende denkt.

Es gibt verschiedene Managementschulen:

  • Menschen sollten die Dinge tun, die das Management ihnen sagt, und sie so tun, wie das Management ihnen sagt, sie zu tun.

  • Menschen sollten Dinge tun, die dem Unternehmen helfen, und selbst herausfinden, wie sie das tun, denn sie sind Profis.

Die meisten Entwickler werden normalerweise nach dem zweiten Weg verwaltet und reagieren etwas schlecht auf den ersten. Ok, ich habe es stark vereinfacht und es gibt viel mehr als 2 Managementschulen, aber Sie sollten verstehen, worauf es ankommt. Wenn Sie möchten, dass ein Entwickler oder ein anderer hochqualifizierter Mitarbeiter etwas tut, gehen Sie normalerweise wie folgt vor:

  • Sagen Sie ihnen, wo das Ziel ist, und helfen Sie ihnen herauszufinden, wo sie stehen.
  • Lassen Sie sie eine Lösung erarbeiten.
  • Bieten Sie Hilfe an, wo immer sie sie brauchen.

Als Manager sind Ihnen die Tools, die Ihr Team verwendet, egal. Entscheidend sollte sein, ob das Team Zugang zu den benötigten Tools hat, angemessen in den verwendeten Tools geschult ist und ob es Tools gibt, die unnötige Reibung in den Teamprozessen verursachen. Denken Sie daran: Sie sind die Experten, sie wissen, wie man arbeitet, deshalb bezahlen Sie sie.

Was Sie tun können, ist, das Bewusstsein für Tools zu schärfen. Einige Möglichkeiten, das Bewusstsein und die Vertrautheit mit einer breiteren Palette von Tools zu schärfen, bestehen darin, Teammitglieder den Code des anderen beim Check-in überprüfen zu lassen, Programmiersitzungen zu zweit abzuhalten, zu besonderen Anlässen unterschiedliche Teamzusammensetzungen zu haben (z project Friday") und viele mehr.

Spezifischer Ratschlag für den IDE vs. Texteditor-Teil der Frage:

Wenn ein Entwickler, der jahrelang mit einem Texteditor gearbeitet hat, deutlich langsamer ist als andere Entwickler, die mit einer IDE arbeiten, wird dieser Entwickler durch den Wechsel zu einer IDE nicht plötzlich auf die gleiche Geschwindigkeit wie die anderen Entwickler kommen. Der Geschwindigkeitsunterschied liegt bei weitem nicht im Bereich "deutlich langsamer".

Letztendlich kommt es darauf an, ob die Entwickler ihre Ziele rechtzeitig und mit einem hohen (aber angemessenen) Qualitätsstandard erreichen. Die Umgebung sollte keine Rolle spielen, selbst wenn sie Schmetterlinge verwenden, solange sie dieses Ziel erreichen :). Abgesehen von Einschränkungen in Bezug auf Kosten und Sicherheit sollten sie Autonomie über ihre Umgebung haben und nicht in der Lage sein, die Verantwortung auf die Werkzeuge zu übertragen, wenn etwas schief geht, weil sie sich dafür entschieden haben. Wenn es ein Leistungsproblem gibt, liegt es am dev. Das Mikromanagement der Werkzeuge des Entwicklers wird es nicht lösen, und der Entwickler wird es Ihnen übel nehmen.
Meiner Erfahrung nach behaupten die meisten Manager, den zweiten Weg zu gehen, aber in dem Moment, in dem jemand etwas tut, wozu er nicht ausdrücklich aufgefordert wurde, zeigen sie ihr wahres Gesicht und werden wütend auf Sie, weil Sie etwas tun, was Sie getan haben. nicht gesagt zu tun. Und ja, das sind IT-Manager.
Was meine eigenen Vorlieben angeht, mag ich sie irgendwo dazwischen. Klare Ziele gesetzt bekommen, aber auch Spielraum für andere Dinge haben, die einen Nutzen bringen, wenn ich sie sehe (die ich dann in der Regel zuerst meinen Managern vorstelle, je nachdem, welche Auswirkungen sie haben würden).

Ich stimme vielen dieser Antworten wirklich nicht zu, die darauf hindeuten, dass es immer schlecht ist, einen Entwickler zu zwingen, bei der Entwicklung ein bestimmtes Tool zu verwenden. Was ist zum Beispiel, wenn Sie in Java programmieren und Debugging durchführen müssen, aber einen Entwickler haben, der nur einen Texteditor und die Befehlszeile verwendet. Ich habe Leute getroffen, die jahrelang in der Branche waren, die nicht wussten, dass Sie den Code in Eclipse während des Debuggens ändern können und Ihre Änderungen sofort wirksam werden ... Ich meine, schauen Sie sich diese Frage zum Debuggen von Java in VIM an. https://stackoverflow.com/questions/545056/how-to-debug-java-application-using-vim-gvim. Die akzeptierte Antwort enthält einen Link zu etwas namens JavaKit, das zuletzt 2008 aktualisiert wurde. Wenn ich der Chef bin und einen Entwickler habe, der Stunden damit verbringt, Java in Vim zu debuggen, um einen Fehler zu finden, würde ich ihm zeigen, wie Ich kann diese Aufgabe in 5 Minuten in einer IDE erledigen. Danach werde ich ihnen mitteilen, dass sie dieses Spiel in ihrer Freizeit spielen können, und ich erwarte, dass sie in der Zwischenzeit die IDE verwenden. Aber auch hier müsste ich den Nutzen oder die geschäftliche Notwendigkeit für dieses Tool demonstrieren, um sicherzustellen, dass ich kein Mikromanagement bin, aber ich würde mich nicht einer Debatte darüber hingeben, ob ein Entwickler mit oder ohne IDE effizienter debuggt oder nicht. Wenn der Entwickler wirklich ein Zauberer mit Texteditoren und der Befehlszeile wäre, würden Sie nicht sehen, dass sie langsamer arbeiten ...

Wenn die einzige Sorge seine eigene persönliche Geschwindigkeit ist, dann stimme ich dem breiten Konsens zu: Schaff das. Lassen Sie ihn wissen, dass er möglicherweise Optionen zur Steigerung der Produktivität durch den Einsatz moderner Tools hat, aber ansonsten ist das seine Sache.

Wenn die Arbeitsweise Ihres Teams jedoch einige dieser Tools erfordert – ob Sie mit Projekten arbeiten, die zumindest das Öffnen von Visual Studio erfordern, um Prozessabläufe einzurichten, oder ob Sie das Team auf einem Code-Analysator ohne CLI standardisiert haben – dann ist die Verwendung dieses Tools eine Jobanforderung, und Sie sollten das klarstellen. Er arbeitet im Team und sollte die Produktivität des Teams generell nicht durch seinen persönlichen Arbeitsstil beeinträchtigen.

Alles, was sich in der Blackbox des Programmierers befindet, liegt in seiner Hand, solange er die Erwartungen an Produktivität und Qualität erfüllt oder übertrifft. Alles, was nach außen zum Team durchdringt und Auswirkungen auf andere oder das Team als Ganzes hat, folgt er Ihren Anforderungen oder er wird losgelassen. Das ist eine vernünftige Erwartung und eine vernünftige Aufteilung der Verantwortlichkeiten für einen Fachmann.

Wenn Sie entscheiden, wie einiges davon eine Voraussetzung für das ordnungsgemäße Funktionieren des Teams ist: Machen Sie einfach in einem Teammeeting deutlich, dass die Verwendung des Tools eine Voraussetzung (für alle) ist. Wenn er es weiterhin nicht verwendet und sich nicht ändert, nachdem er direkt darum gebeten wurde, eskalieren Sie bei Bedarf mit dem Management. Persönlich würde ich mich bemühen, ihm das zu "verkaufen", aber nicht zu viel, wenn es eine Voraussetzung ist - besonders wenn der Rest des Teams bereits davon überzeugt ist.

Ich habe kürzlich versucht, die Xcode-IDE mit einem sehr großen Projekt zu verwenden, an dem wir gerade arbeiten, auf einem 4 Jahre alten Mac: totale Katastrophe! Um die aktuellen hochmodernen IDEs auszuführen, benötigen Sie auch eine hochmoderne Maschine, ansonsten sehen Sie nur zu, wie die IDE ihre schicken Fenster oder noch schlimmere Ladeindikatoren zeichnet, anstatt zu codieren. Und hier kommt normalerweise das CLI zum Einsatz, da es immer mit sehr hoher Geschwindigkeit arbeitet, unabhängig von der Leistung Ihrer Maschine.

Vielleicht kannst du ihn also bestechen? Besorgen Sie ihm die schnellste Maschine, die Sie finden können, und er kann damit lernen, mit der IDE zu arbeiten. Wenn er sofort wieder auf die CLI umschaltet, geben Sie ihm die alte Maschine und die neue jemandem, der damit umgehen kann. Nicht als Strafe, sondern um die Ressource effektiv zu nutzen. Wenn er es wirklich lange versucht, lass ihn es vielleicht behalten. Kommt ganz auf dein Budget an.

Wie andere bereits erwähnt haben, muss er sehen, wie die IDE funktioniert, lassen Sie sich einfach von einigen Entwicklern anrufen und helfen, ein Problem zu debuggen. Sie werden die IDE automatisch wie beabsichtigt verwenden und all die coolen Sachen machen, und er wird in der ersten Reihe sein und es einfach beobachten und aufnehmen, weil er wahrscheinlich zu beschäftigt ist, nach dem Fehler zu suchen. Sie erleben viele Oh-ich-wusste-nicht-dass-Sie-das-können-Momente, wenn Sie jemand anderem beim Programmieren in einem anderen Editor zusehen. Oft sogar in derselben, also lassen Sie die Entwickler ihre bevorzugten IDE-Features in schnellen Präsentationen teilen.

Ich habe eine 6-7 Jahre alte HP Z400 Workstation, und keine IDE kommt jemals auch nur in die Nähe, um mehr als 5 % der CPU zu verbrauchen? Es fällt mir schwer zu glauben, dass ein 4 Jahre alter Mac von einer IDE zum Stillstand kommen würde, wenn ich glaube, dass der neueste XCode auf einem Mac von 2010 ausgeführt wird.
Apple hat in der Vergangenheit aufgeblähte Software für leistungsschwache Hardware zu einem hohen Preis verkauft.
Wir verwenden die neuesten MacBooks mit 16 GB RAM. Mein Computer ist identisch und ich betreibe zwei IDEs für zwei Sprachen, plus Photoshop und andere Schweine überraschend schnell. Spezifikationen sind nicht das Problem. Wie ich bereits erwähnt habe, widmet sich der Entwickler der „alten Schule“; Es gibt wenig Gründe, außer dass er nervös sein und die Dinge auf die schwierige Art und Weise tun möchte, um mehr zu lernen (was großartig ist, solange es die Geschwindigkeit nicht beeinflusst). Er weiß, wozu andere IDEs in der Lage sind.
@dKen Beim Management geht es zumindest teilweise um Empathie. Sie werden damit zu kämpfen haben, wenn Sie das Argument der anderen Seite mit "Ich möchte nervös sein" umschreiben.
@MatthewWhited: Hast du persönliche Erfahrungen? Aus meiner persönlichen Vollzeit-iOS / MacOS-Erfahrung ist das, was Sie sagen, nur eine ungebildete Tirade.
Wenn Geschwindigkeit in diesem Unternehmen wichtig genug ist, dass die langsame Geschwindigkeit eines Entwicklers eine große Sache ist, haben Sie ehrlich gesagt keine Zeit dafür. Das Austauschen von Maschinen, das Einrichten neuer IDEs, das Warten darauf, dass der Entwickler in der neuen Umgebung wieder zur vollen Produktivität zurückkehrt, falls dies jemals der Fall ist, usw., all dies braucht Zeit. Jede Menge Zeit. Zeit, die es so anhört, als hättest du sie nicht.

Die Tools, die sie verwenden, sind nicht der limitierende Faktor.

Er ist ausdrücklich klar: Sie wollen nichts anderes tun als programmieren, am liebsten dort, wo sie keinen Kontakt zu anderen Menschen haben, und am liebsten zu Hause. Absolut keine Meetings, keine Diskussionen, er will die anfallenden Aufgaben selbst erledigen und erledigen. Der Versuch, Agile einzuführen, wird eine Herausforderung sein. Er hat nicht viele andere Aufgaben, 95 % seiner Arbeit ist Code.

Sie engagieren sich nicht mit anderen Mitgliedern des Teams. Keine Rückmeldung bekommen. Keine Codeüberprüfungen durchführen (was eine der besten Möglichkeiten ist, die Produktivität, Codequalität und Fähigkeiten von Entwicklern zu verbessern).

Erlauben Sie ihnen weiterhin, aus der Ferne zu arbeiten, aber nicht 100 % der Zeit (unser Büro übernimmt 10 %).

Führen Sie obligatorische persönliche Code-Reviews mit dem gesamten Team durch. Lassen Sie sie die Werkzeuge und Techniken der anderen Mitglieder sehen. Code, der nicht von einem anderen Teammitglied überprüft und abgezeichnet wurde, wird nicht an Master übergeben. Vielleicht wechselt ihr alle zu Vim, ich weiß es nicht, aber es wird euch allen besser gehen.

Dies ist eine Managementfrage. Der Punkt ist, dass der Entwickler nicht schnell genug für die Projektanforderungen arbeitet. Seine/ihre langsame Leistung muss vom Manager gemeldet werden und dann muss er/sie sie korrigieren. Wenn er/sie Fragen an den Rest des Teams hat, ist das eine andere Geschichte, aber das grundlegende Problem hier ist, dass der Entwickler für die Arbeit, die er/sie erledigt, nicht schnell genug arbeitet. Das Management muss die Situation mit dem Entwickler und vielleicht einem PIP bearbeiten, um die Dinge wieder in Gang zu bringen.

Bearbeiten Sie basierend auf Kommentaren: Ich hatte eine ähnliche Situation. Ich empfehle Team-"Trainings"-Aktivitäten zu Werkzeugen und anderen Dingen, die den Rest der Entwickler "erfolgreich" machen. Wenn Sie die Person nicht erschrecken möchten, müssen Sie das Team als Ganzes darin schulen, bestimmte Praktiken und Werkzeuge zu befolgen, um den Ansatz des Teams besser zu vereinheitlichen. Dies wird wahrscheinlich für das gesamte Team um einer Person willen umständlich sein, aber wenn Sie sie nicht speziell nennen möchten, müssen Sie es für alle allgemein machen. Sie können die erforderlichen Werkzeuge diktieren, sobald Sie den besten Weg gefunden haben, aber auch dies spricht das gesamte Team mit erzwungenem Verhalten an und nicht nur den Einzelnen. Sie können sich mit ihnen unterhalten, ohne einen PIP zu haben, aber ich sehe keinen Weg, ihnen zu sagen, dass sie nicht so schnell sind wie die anderen Entwickler. was dann in den gleichen Sound gerät, den Sie von vornherein vermeiden wollten. Ja, Tools können helfen, die Dinge zu beschleunigen, aber der Punkt ist, dass der Entwickler die Art und Weise mag, wie er/sie Dinge tut, was bedeutet, dass er die Tools nicht verwendet, was dann zu einem persönlichen Problem zurückkehrt. Vielleicht hilft ihnen die Schulung, neuere Tools zu verwenden?

Ein PIP wird ihn nur dazu bringen, zu gehen. In der Regel ist ein PIP nichts anderes als eine Vorbereitung auf die Beendigung, es ist ein schrecklicher Demotivator
Ich bin der Manager hier, also geht es auf mich. Ich will nicht zu schnell zu drastisch werden. Ich bin neu im Team, aber ich schaue mir ein paar Dinge an, die ich ausprobieren kann, bevor ich es auf die nächste Stufe bringe. Ich bin zuversichtlich, dass ich etwas tun kann, um die Geschwindigkeit zu erhöhen.
@RichardU Stimmen Sie zu, dass PIP ein Demotivator ist, Ihre Antwort schlägt jedoch vor, "den Prozess der Beendigung zu beginnen". Ich bin mir nicht sicher, inwiefern das ein Problem für mich ist, wenn Sie denselben Ansatz vorschlagen, ohne einen Verbesserungsplan zu erwähnen ...
Danke @mutt, schöne Bearbeitung. Das Training ist ein großer Punkt, ebenso wie das Training des gesamten Teams, um keinen herauszugreifen. Guter Rat. Ich werde das Training in Betracht ziehen, aber dieser eine Typ ist ziemlich stur, also könnte es eine Herausforderung sein! Willkommen bei PM denke ich :)
@dKen Leider ja. Bitte beachten Sie, dass Sie bei der Durchführung des vollständigen Teamansatzes sorgfältig darauf achten, dass Sie im Training nicht als "einschränkend", sondern als "befähigend" empfunden werden. Es ist sehr gut für alle, sich über neue Dinge auf dem Laufenden zu halten, und Schulungen sind ein guter Weg, dies zu tun. Sie haben auch mehr Gewicht, um mit der Person zu sprechen, wenn sie sich weigert, auch beim Training zu kooperieren. Wie enderland auch erwähnt, ändert es die Perspektive des Einzelnen, bessere Programmierer zu sein, und nicht nur das Werkzeug selbst. Ich würde hoffen, dass das Training ihm/ihr helfen würde, „in neue Dinge hineinzuwachsen“, um besser mit dem Team zusammenzuarbeiten.
@mutt War nicht dazu gemacht, Ihre Antwort zu beeinträchtigen, nur wenn Sie eine verbesserte Leistung / Umschulung wünschen, nennen Sie es nicht PIP, viel zu viel negative Konnotation. Sorry, das hätte ich deutlicher formulieren sollen.
@dKen Wenn Sie ihn PIP machen würden, würden andere Sie in Ihrer Einschätzung unterstützen? Das heißt, fällt die langsame Geschwindigkeit des Entwicklers auch seinen Mitarbeitern auf? Es ist immer eine gute Idee sicherzustellen, dass das Problem für andere, die mit der Person arbeiten, objektiv sichtbar ist. Es kann auch mildernde Faktoren geben, die Sie auf diese Weise entdecken: Arbeitet diese Person beispielsweise an einem schwierigeren Problem als die anderen Entwickler im Team?
@dKen Ich würde mir nicht die Zeit nehmen, das gesamte Team für einen Mitarbeiter zu schulen, es sei denn, Sie wollten sie sowieso schulen. Das erlaubt nur einer Person, eine Belastung für andere zu sein. Wenn es sich um eine schlechte Übereinstimmung handelt und es auch für andere sichtbar ist, führen Sie die ehrliche Diskussion, die Sie mit dem Entwickler führen müssen. Es ist nicht unbedingt ein objektives Spiegelbild des Entwicklers, sondern des Entwicklers im Kontext dieses Projekts / Unternehmens - aber es klingt immer noch nach einer schlechten Übereinstimmung und einer Situation, die korrigiert werden muss.

Wenn es ein nützliches Werkzeug gibt, das er nicht verwendet, weisen Sie ihn darauf hin.

Ich bin sicherlich gegenüber Texteditoren voreingenommen und habe versucht, Scala in vim zu schreiben, aber ich wurde schnell auf IntelliJ hingewiesen, und obwohl es eine andere Denkweise und eine gewisse Lernkurve hat; Ich bin viel produktiver damit.

Weisen Sie ihn daher auf die besten Tools hin, die er Ihrer Meinung nach vermisst. Zwingen Sie ihn nicht, es zu benutzen, schlagen Sie ihm einfach vor, es zu versuchen. Wenn er sich weigert, es auch nur zu versuchen, ist das für mich ein Warnsignal, es sieht nach einer schwierigen Person aus, mit der man arbeiten kann. Wenn er es versucht, aber nicht produktiver damit ist, dann versteht man zumindest, warum er so "old skool" ist, manche Leute werden durch einfach zu bedienende Schnittstellen verwirrt, ich bin ein bisschen so. Vielleicht können Sie ihn für Aufgaben einsetzen, bei denen es eine Benutzeroberfläche gibt, mit der er arbeiten kann?

Eine Person, die schnell ein Skript für jede Aufgabe schreiben und schneller tippen kann, als Sie sprechen, kann mit der Befehlszeile viel produktiver sein als mit einer schrulligen IDE, unabhängig davon, wie professionell Ihre Vertriebsabteilung in Ihr Team gedrängt wird. Gehen Sie nicht davon aus, dass dies in irgendeiner Weise mit der Leistung zusammenhängt.

Außerdem bin ich nicht einverstanden mit dem allgemeinen Ansatz, dass jemand anderes über die Tools entscheidet, es sei denn, sie empfehlen ein neues Tool, von dem ich nichts weiß. Die Person, die das Tool täglich nutzt, ist kompetenter als irgendein „Entscheider“ weiter oben in der Hierarchie, der es nur schnell evaluiert oder vielleicht sogar einfach die gut aufbereitete Demo ohne Ecken und Kanten angeschaut hat.

Die fruchtlose und letztendlich bedeutungslose Diskussion über CLI vs. IDE finden Sie hier . Die Frage war: Habe ich Recht, eine IDE auszuprobieren, um zu sehen, ob sie die Geschwindigkeit ändert? Ich frage nicht nach den Vorlieben der Leute für Entwicklungstools.
Die einzige Umgebung, in der es sich lohnt, einen Entwickler zu bewerten, ist das Tooling, mit dem er oder sie sich am wohlsten fühlt (innerhalb der Beschränkungen des Unternehmens in Bezug auf Kosten, Sicherheit usw.). Das Erzwingen einer externen Umgebung wird den Entwickler nicht schneller machen, und es liegt sowieso in der Verantwortung des Entwicklers, sich am Ende des Tages eine optimale Umgebung anzueignen.
Sollte ich einen langsameren Entwickler zwingen, das Tool zu wechseln, um zu versuchen, seine Geschwindigkeit zu erhöhen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v