Sind SMART-Ziele für Programmierer nützlich? [geschlossen]

Einige Organisationen, die ich kenne, verwenden SMART- Ziele für ihre Programmierer. SMART ist eine Abkürzung für Specific, Measurable, Achievable, Relevant und Time-Bound. Sie sind in großen Unternehmen ziemlich verbreitet.

Meine eigenen früheren Erfahrungen mit SMART-Zielen waren nicht allzu positiv. Haben andere Programmierer eine effektive Möglichkeit gefunden, die Leistung zu messen? Was sind einige Beispiele für gute SMART-Ziele für Programmierer (falls vorhanden)?

In einem Wort

Nein

Erstens: Meine Projekte waren noch nie so stabil, dass ich die SMART-Ziele mit einer beliebigen Bedeutung festlegen konnte. Die Zeitskalen zwischen dem Wechsel meiner Rollen in einem Projekt und dem Zeitpunkt, an dem Perf-Reviews durchgeführt werden, sind einfach zu weit voneinander entfernt.

Zweitens: Die Messung der individuellen Leistung ist eine großartige Möglichkeit, um eine "Nicht mein Job" -Mentalität und einen negativen Wettbewerb zwischen Einzelpersonen und / oder den verschiedenen Subteams in einer Organisation zu erzeugen. Es ist sehr einfach, das System zu spielen und sicherzustellen, dass Sie auf sich selbst aufpassen und nicht wirklich dem gesamten Team helfen. Wir sollten die Menschen ermutigen, Teamplayer zu sein, aber dann tun unsere Organisationen genau das Gegenteil.

Die meisten dieser Arten von Systemen stehen der Teambildung entgegen. Mary Poppendieck hat dies weitaus besser formuliert als ich es jemals in LeanEssays: Team Compensation konnte .

Sue hat einen Anruf von Janice in der Personalabteilung erhalten. „Sue“, sagte sie, „großartige Arbeit, die Ihr Team geleistet hat! Und vielen Dank, dass Sie all diese Bewertungsformulare ausgefüllt haben. Aber wirklich, man kann nicht jedem eine Top-Bewertung geben. Ihre durchschnittliche Bewertung sollte "Entspricht den Erwartungen" sein. Man kann nur ein oder zwei Leute haben, die die Erwartungen weit übertroffen haben ... “

... Einer der größten Vordenker des 20. Jahrhunderts, W Edwards Deming, schrieb, dass nicht messbarer Schaden durch die Rangfolge von Menschen, Verdienstsystemen und Anreizzahlungen entsteht. Deming glaubte, dass jedes Unternehmen ein System ist und die Leistung von Einzelpersonen größtenteils das Ergebnis der Funktionsweise des Systems ist. Seiner Ansicht nach verursacht das System 80% der Probleme in einem Unternehmen, und das System liegt in der Verantwortung des Managements. Er schrieb, dass Ermahnungen und Anreize, um Einzelpersonen zur Lösung von Managementproblemen zu bewegen, einfach nicht funktionieren. Deming widersprüchliche Rangfolge, weil es Stolz in der Verarbeitung zerstört, und Verdienst steigt, weil sie die Symptome und nicht die Ursachen von Problemen ansprechen.

... werfen wir einen genaueren Blick auf die Bewertungs- und Belohnungssysteme der Mitarbeiter und untersuchen, warum sie funktionsgestört sind ...

Wir haben SMART-Ziele in dem großen Unternehmen verwendet, in dem ich arbeite. Sie sind größtenteils bedeutungslos.

Die Ziele stammen vom oberen Management und sind hoch und abstrakt. Ihre Beziehung zu konkreten Projekten und Entwicklungen ist in der Regel ein Witz. Die meisten Projekte, die in die Gruppe aufgenommen werden, stammen aus dem Geschäft und müssen einem bestimmten Geschäftsbedürfnis entsprechen. Sie programmieren das Projekt, nehmen es in Produktion und leisten wie gewohnt hervorragende Arbeit. In welcher Beziehung steht das zu einem Ziel, das sich jemand im oberen Management ausgedacht hat?

Wir machen es als Gruppe viel besser, wenn wir unsere eigenen Ziele erreichen. Manchmal beinhalten sie Schulungen zu einem bestimmten Thema oder die Implementierung einer neuen Prozessänderung, was tatsächlich mit dem zusammenhängt, was wir tun. Sie sind immer noch nicht wirklich mit der täglichen Arbeitsweise des Codierens verwandt, da sie zumindest dazu beitragen, die Gruppe im Unternehmensumfeld voranzubringen.

BEARBEITEN

Wie Mnementh so richtig ausgeführt hat, basiert meine Antwort darauf, dass SMART-Ziele nicht SMART sind. Ich würde zu meiner Antwort hinzufügen, dass Sie, wenn Sie Manager von Programmierern sind und SMART-Ziele implementieren möchten, sicher sein sollten, dass Sie SMART sind. Verwenden Sie das Beispiel meiner Manager, um SMART-Ziele NICHT zu implementieren. Wenn Sie keine Programmierer verwalten und jemand Ihnen mitteilt, dass Sie jetzt SMART-Ziele verwenden und diese wie unsere Ziele enden, dann verstehen Sie, dass Sie Leute im oberen Management haben, die Modewörter mögen und überprüfen können sie aus einer Liste von Dingen, die sie implementiert haben.

Es gibt viele Studien, die belegen, dass Programmierer auf Kosten anderer möglicher Ziele bei allen Kriterien, die ihnen präsentiert werden, hervorragende Arbeit leisten.

Dies bedeutet, dass sie bei der Erreichung spezifischer und messbarer Ziele gut abschneiden und bei allem, was nicht speziell aufgeführt ist, weniger gut abschneiden. Das bedeutet, dass Sie beim Setzen von Zielen äußerst vorsichtig sein müssen.

Sie möchten keine Codezeilen als Ziel festlegen. Vertrau mir. Das Setzen von Bugs führt dazu, dass zunächst Buggy-Code geschrieben wird. Das Nachfragen nach Fehlerkorrekturen in vorhandenem Code führt zu sehr liberalen Definitionen von "Bug" (und möglicherweise "Fix"). (Außerdem hängt der "erreichbare" Teil davon ab, wie fehlerhaft der Code war.) Nach der Vollständigkeit der Funktionen in einer bestimmten Zeit fragen, na ja ...

Sie möchten, dass Ihre Programmierer in angemessener Zeit nützliche Informationen mit guter Codequalität schreiben und diese unter Beibehaltung der Codequalität verbessern und modifizieren. Ich habe noch nie konkrete und messbare Ziele gesehen, die selbst gute Kriterien wären.

Wir machen diese Übung jedes Jahr. Das Problem ist, dass Entwickler hier in der Regel nur sehr wenig Autonomie haben (Aufgaben werden vom Produktmanager festgelegt). Wir haben das Glück, zumindest auf dem Papier Zeit zu haben, um unsere Ziele zu erreichen. Realistisch gesehen bekommen wir jedoch weit weniger.

In diesem Rahmen habe ich festgestellt, dass das Setzen von Selbstentwicklungszielen sehr gut funktioniert. Zum Beispiel waren zwei meiner Ziele aus dem letzten Jahr:

1. Zum Lesen von Entwurfsmustern und Schreiben von Spielzeugprojekten, um jedes Muster bis zum nächsten Jahr zu lernen und zu demonstrieren. Dies hat 2 Jahre gedauert, aber die Verbesserung meiner Codierung war spürbar.
2. Um die .NET 3.5-Sprachfunktionen zu studieren und meinen Mitarbeitern vierteljährlich eine Präsentation vorzustellen. Dies endete mit einer Präsentation auf LINQ, die meine Mitarbeiter in unterschiedlichem Maße zwischen apathisch und leicht interessiert schätzten. Ich habe jedoch viel gelernt, und nachdem ich meine C # -Kenntnisse unter Beweis gestellt hatte, wurde ich dazu bewegt, an einem ziemlich coolen neuen Projekt zu arbeiten.

Also, ja, ich habe davon profitiert und Spaß dabei gehabt.

Ehrlich gesagt, in unserem Unternehmen hat der Mangel an guten SMART-Zielen für Entwickler mehr mit der Abneigung gegen Unternehmenssprache zu tun.

Ja, wenn richtig eingestellt.

Bei richtiger Festlegung können die Ziele sowohl das Team als auch die einzelnen Personen verbessern. Sie sollten auch auf die Arbeit abgestimmt und auf den Einzelnen zugeschnitten sein.

Ich war an Orten, an denen ein ganzes DBA-Team die gleichen milden Ziele verfolgt, sowie an Orten, an denen wichtige Kriterien wie "Einhaltung globaler und regionaler KPIs, wie sie vom KPI-Ausschuss festgelegt wurden". Das weiß natürlich niemand ..

Andererseits war ich an Orten, an denen der Manager im Vorfeld individuelle Ziele gesetzt hat.

Bearbeiten:

Ich habe den Artikel von Mary Poppendieck gelesen und es geht nicht um SMART. "The Perception of Impossibility" schlägt beispielsweise "Achievable" fehl.

Für den Einzelnen sollten Ziele festgelegt werden, um seine Stärken auszutauschen, Schwächen zu beheben und zum Team beizutragen. Messung ist für den Einzelnen.

Es sollte keinen Vergleich zwischen x und y geben.

Die Ziele für x und y sollten jedoch ihrem Rang oder ihrer Position innerhalb eines Systems entsprechen: Man setzt nicht die gleichen Ziele für Senioren und Junioren. Das ist ungerecht.

Einige Benchmarks sind erforderlich, um Bonusse oder Einnahmen aus einem begrenzten Pot festzulegen: Sollen wir stattdessen Codezeilen zählen? Peer-Bewertungen?

Zeigen Sie mir gültige Alternativen, bei denen ich mein globales Unternehmensethos nicht ändern muss. Ich habe keine Kritik an SMART: Ich tun haben Kritik an Pisse schlechte Manager ...

Als Leistungsrahmen ist SMART nur so effektiv wie die enge Abstimmung Ihrer Ziele mit denen Ihrer Manager. Manchmal müssen Ihre SMART-Ziele zuerst DUMBEN, d. H. mach sie:

• Machbar
• Verständlich
• Überschaubar
• Vorteilhaft

So seltsam das auch klingen mag.

SMART-Typ Ziel-Einstellung kann in einem Programmier Kontext nützlich sein , aber es muss getan werden intelligent oder, wie in anderen Antworten erwähnt, ist es wahrscheinlich , zeitraubende (oder schlechter) sein.

Um nützliche Ziele zu erreichen, ist es hilfreich zu vereinbaren, was das SMART-Akronym bedeutet: Bei einer schnellen Google-Suche wurden unterschiedliche Definitionen gefunden :

• S: scheint Konsens bei Specific zu haben (obwohl es einige Meinungsverschiedenheiten darüber gibt, was das bedeutet)
• M: Sinnvoll und motivierend sind Alternativen zum allgemeineren Messbaren
• A: scheint am häufigsten Achievable zu repräsentieren, aber ich habe auch Agreed-On gesehen
• R: Je nachdem, wo Sie suchen, finden Sie realistische, relevante, ergebnisorientierte
• T scheint sich immer auf die Zeit zu beziehen, obwohl die Betonung variiert

Zunächst sollten beide Seiten der Zielvereinbarung von einem gemeinsamen Verständnis des Prozesses ausgehen.

Als nächstes müssen die übergeordneten Ziele für Organisation, Abteilung, Gruppe, Team (oder welche Hierarchie auch immer relevant ist) erklärt und verstanden werden. Zu diesem Zeitpunkt sollte es dem Einzelnen möglich sein (IMO, Ziele müssen auf Einzelebene festgelegt werden, damit sie sich lohnen), sich auf eine kleine Anzahl von Zielen zu einigen, die die zukünftigen Aktivitäten dieser Person informieren sollen.

Wenn es dort endet, ist es immer noch Zeitverschwendung für alle. Die Ziele müssen regelmäßig überprüft und angepasst werden - wo dies erreicht wurde, sollte die mögliche Notwendigkeit der Festlegung neuer Ziele erwogen werden, wo dies nicht erreicht wurde, sollten Gründe ermittelt und erforderlichenfalls Abhilfemaßnahmen vorgeschrieben werden.

Alle Beteiligten sollten sich darüber im Klaren sein, dass diese Art von Übung sich nicht lohnt, wenn sie nicht ernst genommen wird oder wenn der zu extrahierende Wert möglicherweise algorithmischer ist.

Es kann lehrreich sein zu sehen, was die Leute für nützliche / lohnende SMART-Ziele halten. Ich habe hier eine Frage gestellt ...

Das Problem bei SMART-Zielen ist, dass sie das Messbare auswählen müssen. Da das, was messbar ist und was für den Unternehmenserfolg wichtig ist, oft nicht dasselbe ist (und in der Programmierung so gut wie nie vorkommt), scheitern SMART-Ziele meiner Erfahrung nach bei der Leistungsbewertung immer. Und manchmal scheinen die Dinge messbar, aber nicht ohne viel Aufwand (wie beim SMART-Ziel hatte ich ein Mal, um alle E-Mails innerhalb von 4 Stunden zu beantworten. Wer wirklich versuchen möchte, die Tausenden von E-Mails zu durchlaufen, die ich pro Jahr erhalte, sollte feststellen, ob dies der Fall ist War informativ oder brauchte eine Antwort. Sehen Sie sich meine gesendeten E-Mails an, um festzustellen, ob ich sie beantwortet habe. Hören Sie sich dann die Aufzeichnungen aller Anrufe an, um festzustellen, ob ich sie beantwortet habe was ist mit dieser E-Mail, die mir am Samstagabend um Mitternacht geschickt wurde ...)

Allen Leuten, die mit NEIN geantwortet haben, waren Ihre Ziele wahrscheinlich NICHT SMART genug.

Ich habe sie benutzt und finde sie unglaublich nützlich. Vielleicht möchten Sie etwas ausprobieren, das für uns funktioniert:

1. Vierteljährliche Ziele setzen.
2. Messbare Ziele setzen.
3. Setze nur ein Ziel für den Einzelnen
4. Lassen Sie den Einzelnen das Ziel akzeptieren, wenn er sagt, dass das Ziel zu ehrgeizig ist, und passen Sie es so lange an, bis Sie beide zustimmen.
5. Überlegen Sie sich am Ende des Quartals einen Booleschen Wert. Ziel erreicht = wahr oder falsch.

Dies ist äußerst leistungsfähig und schafft Rechenschaftspflicht für den Entwickler. Die Leute, die Ausreden finden wollen, gehen nach ungefähr 6 Monaten ab.

PS: Ich kann verstehen, dass Leute die Antwort runterstimmen, aber bitte schreibe mir einen relevanten Kommentar. Ich werde etwas lernen, was ich nicht weiß :-)

SMART ist ein Akronym, um sich einige Kriterien für bessere Ziele zu merken. Die Einführung von SMART bedeutet also, dass Ihr Management nach diesem Prinzip besser vorgehen muss. Ohne SMART-Management würden sich zwar Ziele setzen, diese wären aber eher zu schwierig.

Damit Programmierer keine Änderungen vornehmen müssen, muss das Management seinen Stil ändern, um SMART zu implementieren. Und wenn sie richtig sind, kann Ihre Arbeit als Programmierer einfacher werden, da die Richtung des Projekts klarer ist, Zeitrahmen festgelegt werden und so weiter.

Wenn das Management es nicht richtig macht, wird sich nicht viel ändern.