Motto:
Der Mann sieht die schmutzigen Kinder an und sagt zu seiner Frau: Sollen wir diese waschen oder neue gebären?
Unter dem Schnitt finden Sie den zweiten Teil eines Artikels unseres Teamleiters sowie RAS-Produktentwicklungsdirektors Igor Marnat über die Besonderheiten der Motivation von Programmierern. Den ersten Teil des Artikels finden Sie hier -
Im ersten Teil des Artikels habe ich die beiden unteren Ebenen der Maslowschen Pyramide angesprochen: physiologische Bedürfnisse, Bedürfnisse nach Sicherheit, Komfort und Beständigkeit, und bin dann zur nächsten, dritten Ebene übergegangen, nämlich:
III - Bedürfnis nach Zugehörigkeit und Liebe
Ich wusste, dass die italienische Mafia „Cosa Nostra“ heißt, aber ich war sehr beeindruckt, als ich herausfand, wie „Cosa Nostra“ übersetzt wird. „Cosa Nostra“ bedeutet aus dem Italienischen übersetzt „Unser Geschäft“. Die Wahl des Namens ist für die Motivation sehr erfolgreich (lassen wir den Beruf einmal beiseite, in diesem Fall interessiert uns nur die Motivation). Eine Person möchte normalerweise Teil eines Teams sein, um ein großes, gemeinsames, unser Geschäft zu erledigen.
Der Befriedigung des Bedürfnisses nach Zugehörigkeit und Liebe wird in der Armee, der Marine und allen großen paramilitärischen Formationen große Bedeutung beigemessen. Und wie wir sehen, in der Mafia. Das ist verständlich, denn man muss Menschen zwingen, die wenig gemeinsam haben, die zunächst kein Team von Gleichgesinnten bilden, die durch Wehrpflicht (nicht freiwillig) zusammengebracht werden, die unterschiedliche Bildungsniveaus und unterschiedliche persönliche Werte haben , ihr Leben buchstäblich unter Lebensgefahr einer gemeinsamen Sache zu widmen, ihr Leben einem Kameraden anzuvertrauen.
Das ist eine sehr starke Motivation; für die meisten Menschen ist es äußerst wichtig, das Gefühl zu haben, zu etwas Größerem zu gehören, zu wissen, dass man Teil einer Familie, eines Landes, eines Teams ist. In der Armee dienen Uniformen, verschiedene Rituale, Paraden, Märsche, Banner usw. diesen Zwecken. Für jedes Team sind ungefähr die gleichen Faktoren wichtig. Wichtig sind Symbole, Unternehmensmarke und Unternehmensfarben, Utensilien und Souvenirs.
Es ist wichtig, dass bedeutende Ereignisse eine eigene sichtbare Verkörperung haben, mit der sie in Verbindung gebracht werden können. Heutzutage ist es eher die Regel, dass ein Unternehmen über eigene Merchandise-Artikel, Jacken, T-Shirts usw. verfügt. Es ist aber auch wichtig, das Team innerhalb des Unternehmens hervorzuheben. Wir veröffentlichen oft T-Shirts auf Basis der Ergebnisse einer Veröffentlichung, die allen an der Veröffentlichung beteiligten Personen ausgehändigt werden. Einige Veranstaltungen, gemeinsame Feiern oder Aktivitäten mit dem gesamten Team sind ein weiterer wichtiger Motivationsfaktor.
Neben äußeren Merkmalen beeinflussen mehrere weitere Faktoren das Zugehörigkeitsgefühl zu einem Team.
Erstens das Vorhandensein eines gemeinsamen Ziels, das jeder versteht und dessen Bedeutung jeder einschätzt. Normalerweise wollen Programmierer verstehen, dass sie etwas Cooles machen, und zwar gemeinsam, als Team.
Zweitens muss das Team über einen Kommunikationsraum verfügen, in dem das gesamte Team anwesend ist und der nur ihm gehört (z. B. ein Chat im Messenger, regelmäßige Team-Synchronisationen). Neben Arbeitsthemen, informeller Kommunikation, manchmal Diskussion externer Ereignisse, Licht von oben – all das schafft ein Gemeinschafts- und Teamgefühl.
Drittens möchte ich die Einführung guter Ingenieurspraktiken innerhalb des Teams hervorheben, den Wunsch, die Standards im Vergleich zu den im Unternehmen akzeptierten Standards zu erhöhen. Die Umsetzung der besten in der Branche akzeptierten Ansätze, zunächst im Team und dann im Unternehmen als Ganzes, gibt dem Team die Möglichkeit, das Gefühl zu haben, den anderen in gewisser Weise voraus zu sein, den Weg zu weisen und so ein Zugehörigkeitsgefühl zu schaffen zu einem coolen Team.
Das Zugehörigkeitsgefühl wird auch durch die Beteiligung des Teams an Planung und Management beeinflusst. Wenn Teammitglieder an der Diskussion von Projektzielen, Arbeitsplänen, Teamstandards und technischen Praktiken sowie an der Befragung neuer Mitarbeiter beteiligt sind, entwickeln sie ein Gefühl der Beteiligung, der Mitverantwortung und des Einflusses auf die Arbeit. Menschen sind viel eher bereit, selbst getroffene und geäußerte Entscheidungen umzusetzen als die von anderen vorgeschlagenen, selbst wenn sie praktisch im Einklang sind.
Geburtstage, Jubiläen, bedeutende Ereignisse im Leben der Kollegen – eine gemeinsame Pizza, ein kleines Geschenk des Teams vermitteln ein warmes Gefühl der Verbundenheit und Dankbarkeit. In manchen Unternehmen ist es üblich, für 5, 10, 15 Jahre Betriebszugehörigkeit kleine Gedenktafeln zu verschenken. Einerseits glaube ich nicht, dass mich das so sehr zu neuen Erfolgen motiviert. Aber natürlich wird fast jeder froh sein, dass er ihn nicht vergessen hat. Dies ist einer der Fälle, in denen das Fehlen einer Tatsache eher demotiviert als dass ihr Vorhandensein motiviert. Stimmen Sie zu, es kann ziemlich schade sein, wenn LinkedIn Sie am Morgen daran erinnert und Ihnen zu Ihrem 10-jährigen Jubiläum an Ihrem Arbeitsplatz gratuliert, aber kein einziger Kollege aus dem Unternehmen gratuliert Ihnen oder erinnert sich an Sie.
Ein wesentlicher Punkt ist natürlich die Veränderung in der Zusammensetzung des Teams. Es ist klar, dass selbst wenn der Zu- oder Abgang einer Person aus dem Team im Voraus angekündigt wird (z. B. in einem Firmen- oder Team-Newsletter oder bei einer Teambesprechung), dies niemanden besonders zu neuen Erfolgen motiviert. Aber wenn Sie eines schönen Tages eine neue Person neben sich sehen oder eine alte nicht sehen, kann das eine Überraschung sein, und wenn Sie gehen, geradezu unangenehm. Menschen sollten nicht stillschweigend verschwinden. Vor allem in einem verteilten Team. Vor allem, wenn Ihre Arbeit von einem Kollegen aus einem anderen Büro abhängt, der plötzlich auftaucht und verschwindet. Solche Momente sind es auf jeden Fall wert, das Team vorab gesondert zu informieren.
Ein wichtiger Faktor, der auf Englisch heißt Eigentum (Die wörtliche Übersetzung von „Besitz“ spiegelt seine Bedeutung nicht vollständig wider.) Dabei handelt es sich nicht um ein Gefühl der Eigenverantwortung, sondern vielmehr um ein Gefühl der Verantwortung für Ihr Projekt, das Gefühl, wenn Sie sich emotional mit dem Produkt und das Produkt mit sich selbst verbinden. Dies entspricht in etwa dem Gebet des Marines im Film „Full Metal Jacket“: „Das ist mein Gewehr. Es gibt viele solcher Gewehre, aber dieses ist meins. Mein Gewehr ist mein bester Freund. Sie ist mein Leben. Ich muss lernen, es genauso zu besitzen, wie ich mein Leben besitze. Ohne mich ist mein Gewehr nutzlos. Ohne mein Gewehr bin ich nutzlos. Ich muss mein Gewehr gerade schießen. Ich muss genauer schießen als der Feind, der versucht, mich zu töten. Ich muss ihn erschießen, bevor er mich erschießt. Lass es so sein…“.
Wenn ein Mensch lange Zeit an einem Produkt arbeitet, die Möglichkeit hat, die volle Verantwortung für dessen Entstehung und Entwicklung zu tragen, zu sehen, wie aus „nichts“ ein funktionierendes Ding entsteht, wie Menschen es nutzen, entsteht dieses kraftvolle Gefühl. Produktteams, die lange Zeit an einem Projekt zusammenarbeiten, sind in der Regel motivierter und kohärenter als Teams, die für kurze Zeit zusammengestellt werden und im Fließbandmodus arbeiten und von einem Projekt zum anderen wechseln, ohne die volle Verantwortung für das gesamte Produkt , Vom Anfang bis zum Ende.
IV. Bedürfnis nach Anerkennung
Ein freundliches Wort freut auch die Katze. Die Anerkennung der Bedeutung der geleisteten Arbeit und deren positive Bewertung motiviert jeden. Sprechen Sie mit Programmierern, geben Sie ihnen regelmäßig Feedback und feiern Sie eine gut gemachte Arbeit. Wenn Sie ein großes und verteiltes Team haben, sind regelmäßige Treffen (sogenannte Einzelgespräche) hierfür perfekt; wenn das Team sehr klein ist und lokal zusammenarbeitet, wird diese Gelegenheit normalerweise ohne besondere Treffen im Kalender (allerdings in regelmäßigen Abständen) angeboten bis eins ist alles. Es wird noch benötigt, man kann es nur seltener tun. Dieses Thema wird in Podcasts für Manager auf manager-tools.com ausführlich behandelt.
Es lohnt sich jedoch, die kulturellen Unterschiede im Auge zu behalten. Einige Ansätze, die amerikanischen Kollegen bekannt sind, funktionieren bei russischen nicht immer. Das Maß an Höflichkeit, das in der täglichen Kommunikation in Teams in westlichen Ländern akzeptiert wird, erscheint Programmierern aus Russland zunächst übertrieben. Einige für russische Kollegen typische Geradlinigkeit können von ihren Kollegen aus anderen Ländern als Unhöflichkeit empfunden werden. Dies ist bei der Kommunikation in einem interethnischen Team sehr wichtig; zu diesem Thema wurde viel geschrieben; der Manager eines solchen Teams muss sich daran erinnern.
Feature-Demonstrationen, bei denen Programmierer Features zeigen, die während eines Sprints entwickelt wurden, sind eine gute Praxis, um diesen Bedarf zu realisieren. Dies ist nicht nur eine hervorragende Gelegenheit, Kommunikationskanäle zwischen Teams zu klären, Produktmanagern und Testern neue Funktionen vorzustellen, sondern auch eine gute Gelegenheit für Entwickler, die Ergebnisse ihrer Arbeit zu zeigen und ihre Urheberschaft anzugeben. Nun, und verbessern Sie natürlich Ihre Fähigkeiten im öffentlichen Reden, was niemals schädlich ist.
Es wäre eine gute Idee, den bedeutenden Einsatz besonders ausgezeichneter Kollegen bei gemeinsamen Teamtreffen mit Urkunden, Gedenktafeln (zumindest einem freundlichen Wort) zu würdigen. Die Menschen schätzen solche Urkunden und Gedenktafeln in der Regel sehr, nehmen sie bei einem Umzug mit und kümmern sich im Allgemeinen auf jede erdenkliche Art und Weise um sie.
Um einen bedeutenderen, langfristigen Beitrag zur Arbeit des Teams, die gesammelte Erfahrung und das Fachwissen zu kennzeichnen, wird häufig ein Notensystem verwendet (auch hier kann eine Analogie zum System der militärischen Dienstgrade in der Armee gezogen werden, das zusätzlich Diesem Zweck dient auch die Sicherung der Unterordnung. Oftmals arbeiten junge Entwickler doppelt so hart, um neue Stars zu gewinnen (z. B. vom Junior-Entwickler zum Vollzeit-Entwickler wechseln usw.).
Es ist von entscheidender Bedeutung, die Erwartungen Ihrer Mitarbeiter zu kennen. Einige sind eher durch eine hohe Note motiviert, die Möglichkeit, sich beispielsweise als Architekt bezeichnen zu lassen, während andere Noten und Titel im Gegenteil gleichgültig sind und eine Gehaltserhöhung als Zeichen der Anerkennung durch das Unternehmen betrachten . Kommunizieren Sie mit Menschen, um zu verstehen, was sie wollen und welche Erwartungen sie haben.
Ein Zeichen der Anerkennung, ein höheres Maß an Vertrauen seitens des Teams, kann durch mehr Handlungsspielräume oder die Einbindung in neue Arbeitsfelder gegeben werden. Beispielsweise kann ein Programmierer, nachdem er bestimmte Erfahrungen gesammelt und bestimmte Ergebnisse erzielt hat, nicht nur seine Funktionen gemäß der Spezifikation implementieren, sondern auch an der Architektur neuer Dinge arbeiten. Oder engagieren Sie sich in neuen Bereichen, die möglicherweise nicht direkt mit der Entwicklung zu tun haben – Testautomatisierung, Implementierung bewährter Engineering-Praktiken, Unterstützung beim Release-Management, Vorträge auf Konferenzen usw.
V. Das Bedürfnis nach Erkenntnis und Selbstverwirklichung.
Viele Programmierer konzentrieren sich in verschiedenen Phasen ihres Lebens auf verschiedene Arten von Programmieraktivitäten. Manche Leute betreiben gerne maschinelles Lernen, entwickeln neue Datenmodelle, lesen beruflich viel wissenschaftliche Literatur und erstellen etwas Neues von Grund auf. Ein anderer Ansatz nähert sich dem Debuggen und Unterstützen einer vorhandenen Anwendung an, bei der Sie sich tief in den vorhandenen Code vertiefen, Protokolle, Stack-Traces und Netzwerk-Captchas tage- und wochenlang studieren und fast keinen neuen Code schreiben müssen.
Beide Prozesse erfordern einen großen intellektuellen Aufwand, ihre praktischen Ergebnisse sind jedoch unterschiedlich. Man geht davon aus, dass Programmierer bestehende Lösungen nur ungern unterstützen, sondern vielmehr motiviert sind, neue zu entwickeln. Darin liegt ein Körnchen Weisheit. Andererseits widmete sich das motivierteste und geschlossenste Team, mit dem ich je zusammengearbeitet habe, der Unterstützung eines bestehenden Produkts und der Suche und Behebung von Fehlern, nachdem das Support-Team sie kontaktiert hatte. Die Jungs lebten buchstäblich für diese Arbeit und waren bereit, samstags und sonntags auszugehen. Einmal haben wir uns eifrig mit einem anderen dringenden und komplexen Problem beschäftigt, entweder am Abend des 31. Dezembers oder am Nachmittag des 1. Januars.
Mehrere Faktoren beeinflussten diese hohe Motivation. Erstens war es ein Unternehmen mit einem großen Namen in der Branche, das Team verband sich mit ihm (siehe „Das Bedürfnis nach Zugehörigkeit“). Zweitens waren sie die letzte Grenze, es gab niemanden dahinter, es gab zu diesem Zeitpunkt noch kein Produktteam. Zwischen ihnen und den Kunden gab es zwei Ebenen der Unterstützung, aber wenn das Problem sie erreichte, gab es keinen Rückzugsort, niemand stand hinter ihnen, das gesamte Unternehmen war auf ihnen (vier junge Programmierer). Drittens hatte dieses große Unternehmen sehr große Kunden (Landesregierungen, Automobil- und Luftfahrtkonzerne usw.) und sehr große Installationen in mehreren Ländern. Dadurch entstehen immer komplexe und interessante Probleme, einfache Probleme werden durch die Unterstützung der Vorgängerstufen gelöst. Viertens wurde die Motivation des Teams stark vom professionellen Niveau des Support-Teams beeinflusst, mit dem es interagierte (es waren sehr erfahrene und technisch kompetente Ingenieure), und wir waren stets von der Qualität der von ihnen vorbereiteten Daten und der von ihnen durchgeführten Analyse überzeugt , usw. Fünftens, und das ist meiner Meinung nach der wichtigste Punkt: Die Mannschaft war sehr jung, alle Jungs standen am Anfang ihrer Karriere. Sie waren daran interessiert, ein großes und komplexes Produkt zu studieren, ernsthafte Probleme zu lösen, die für sie in einer neuen Umgebung neu waren, und sie versuchten, sich professionell an das Niveau der umgebenden Teams, Probleme und Kunden anzupassen. Das Projekt erwies sich als ausgezeichnete Schule, alle machten später eine gute Karriere im Unternehmen und wurden technische Leiter und leitende Manager, einer der Jungs ist jetzt technischer Manager bei Amazon Web Services, der andere wechselte schließlich zu Google und so weiter von ihnen erinnern sich noch mit Wärme an dieses Projekt.
Wenn dieses Team aus Programmierern mit 15–20 Jahren Erfahrung bestünde, wäre die Motivation eine andere. Natürlich sind Alter und Erfahrung nicht zu 100 % ausschlaggebend, sondern es kommt auf die Motivationsstruktur an. In diesem speziellen Fall führte der Wunsch junger Programmierer nach Wissen und Weiterentwicklung zu hervorragenden Ergebnissen.
Im Allgemeinen müssen Sie, wie bereits mehrfach erwähnt, die Erwartungen Ihrer Programmierer kennen, verstehen, wer von ihnen sein Tätigkeitsfeld erweitern oder ändern möchte, und diese Erwartungen berücksichtigen.
Jenseits von Maslows Pyramide: Sichtbarkeit der Ergebnisse, Gamification und Wettbewerb, kein Blödsinn
Es gibt noch drei weitere wichtige Punkte zur Motivation von Programmierern, die unbedingt erwähnt werden müssen, aber sie in Maslows Bedürfnismodell einzubeziehen, wäre zu künstlich.
Der erste ist die Sichtbarkeit und Nähe des Ergebnisses.
Softwareentwicklung ist normalerweise ein Marathon. Die Ergebnisse der Forschungs- und Entwicklungsbemühungen werden erst nach Monaten, manchmal Jahren sichtbar. Es ist schwierig, ein Ziel zu erreichen, das weit hinter dem Horizont liegt, der Arbeitsaufwand ist erschreckend, das Ziel ist weit weg, nicht klar und nicht sichtbar, „die Nacht ist dunkel und voller Schrecken.“ Es ist besser, den Weg dorthin in Teile aufzuteilen, einen Weg zum nächsten Baum zu machen, der sichtbar und erreichbar ist, dessen Umrisse klar sind und der nicht weit von uns entfernt ist – und zu diesem nahen Ziel zu gehen. Wir wollen uns mehrere Tage oder Wochen anstrengen, das Ergebnis einholen und auswerten und dann weitermachen. Daher lohnt es sich, die Arbeit in kleine Teile zu unterteilen (Sprints im agilen Verfahren erfüllen diesen Zweck gut). Wir haben einen Teil der Arbeit abgeschlossen – aufgenommen, ausgeatmet, besprochen, die Schuldigen bestraft, die Unschuldigen belohnt – wir können mit dem nächsten Zyklus beginnen.
Diese Motivation ähnelt in gewissem Maße dem, was Spieler erleben, wenn sie Computerspiele abschließen: Sie erhalten regelmäßig Medaillen, Punkte und Boni, wenn sie jedes Level abschließen; dies kann als „Dopamin-Motivation“ bezeichnet werden.
Dabei ist die Sichtbarkeit des Ergebnisses im wahrsten Sinne des Wortes wichtig. Eine geschlossene Funktion in der Liste sollte grün werden. Wenn der Code geschrieben, getestet und freigegeben ist, sich der visuelle Status jedoch nicht für den Programmierer sichtbar ändert, wird er sich unvollständig fühlen und kein Gefühl der Vollständigkeit haben. In einem der Teams in unserem Versionskontrollsystem durchlief jeder Patch drei aufeinanderfolgende Phasen: Der Build wurde zusammengestellt und die Tests bestanden, der Patch bestand die Codeüberprüfung und der Patch wurde zusammengeführt. Jede Etappe war optisch mit einem grünen Häkchen oder einem roten Kreuz gekennzeichnet. Einmal beschwerte sich einer der Entwickler darüber, dass die Codeüberprüfung zu lange dauerte, die Kollegen schneller werden mussten und die Patches mehrere Tage lang hängen blieben. Ich fragte: Was ändert sich dadurch eigentlich für ihn? Wenn der Code geschrieben, der Build zusammengestellt und die Tests bestanden sind, muss er schließlich nicht auf den gesendeten Patch achten, wenn keine Kommentare vorhanden sind. Die Kollegen selbst werden es prüfen und genehmigen (sofern es wiederum keine Kommentare gibt). Er antwortete: „Igor, ich möchte so schnell wie möglich meine drei grünen Häkchen bekommen.“
Der zweite Punkt ist Gamification und Wettbewerb.
Bei der Entwicklung eines der Produkte hatte unser Ingenieurteam das Ziel, eine herausragende Position in der Community eines der Open-Source-Produkte einzunehmen und unter die Top 3 zu kommen. Zu dieser Zeit gab es keine objektive Möglichkeit, die Sichtbarkeit einer Person in der Community zu beurteilen; jedes der großen teilnehmenden Unternehmen konnte behaupten (und behauptete in regelmäßigen Abständen), dass es der größte Beitragszahler sei, aber es gab keine wirkliche Möglichkeit, die Beiträge der Teilnehmer zu vergleichen untereinander, um seine Dynamik im Laufe der Zeit zu bewerten. Dementsprechend gab es keine Möglichkeit, dem Team ein Ziel zu setzen, das an einigen Papageien gemessen, der Grad seiner Erreichung beurteilt werden könnte usw. Um dieses Problem zu lösen, hat unser Team ein Tool zur Messung und Visualisierung des Beitrags von Unternehmen und einzelnen Mitwirkenden entwickelt . Aus motivierender Sicht war es einfach eine Bombe. Es waren nicht nur Ingenieure und Teams, die ihre Fortschritte und die ihrer Kollegen und Konkurrenten ständig überwachten. Auch das Top-Management unseres Unternehmens und aller großen Wettbewerber startete mit Stackalytics in den Tag. Alles wurde sehr transparent und anschaulich, jeder konnte seine Fortschritte sorgfältig überwachen, sich mit Kollegen vergleichen usw. Für Ingenieure, Manager und Teams ist es jetzt bequem und einfach, Ziele zu setzen.
Ein wichtiger Punkt, der bei der Implementierung eines Systems quantitativer Metriken auftritt, ist, dass das System, sobald Sie diese implementiert haben, automatisch danach strebt, die Erreichung dieser quantitativen Metriken zu priorisieren, zum Nachteil der qualitativen. Als eine der Metriken wird beispielsweise die Anzahl der abgeschlossenen Codeüberprüfungen verwendet. Offensichtlich kann die Codeüberprüfung auf unterschiedliche Weise durchgeführt werden. Sie können mehrere Stunden damit verbringen, einen komplexen Patch gründlich zu überprüfen und zu überprüfen, indem Sie Tests durchführen, ihn auf Ihrer Bank ausführen, anhand der Dokumentation überprüfen und zusätzlich eine Überprüfung in Ihrem Karma erhalten, oder Klicken Sie blind in ein paar Minuten auf ein paar Dutzend Patches, geben Sie jedem +1 und erhalten Sie plus zwanzig an Karma. Es gab komische Fälle, in denen Ingenieure so schnell auf Patches klickten, dass sie automatischen Patches vom CI-System +1 gaben. Wie wir später scherzten: „Geh, geh, Jenkins.“ Bei Commits gab es auch viele Leute, die den Code mit Code-Formatierungstools durchgegangen sind, Kommentare bearbeitet, Punkte in Kommas geändert und so ihr Karma aufgepumpt haben. Der Umgang damit ist ganz einfach: Wir nutzen den gesunden Menschenverstand und nutzen neben quantitativen auch wesentliche, qualitative. Der Grad der Nutzung der Ergebnisse der Teamarbeit, die Anzahl externer Mitwirkender, der Grad der Testabdeckung, die Stabilität von Modulen und dem gesamten Produkt, die Ergebnisse von Skalierungs- und Leistungstests, die Anzahl der Ingenieure, die die Schulter eines Kernprüfers erhielten Gurte, die Tatsache, dass Projekte in die Community der Kernprojekte aufgenommen wurden, die Einhaltung der Kriterien verschiedener Phasen des Engineering-Prozesses – all diese und viele andere Faktoren müssen zusammen mit einfachen quantitativen Metriken bewertet werden.
Und schließlich der dritte Punkt: Kein Blödsinn.
Entwickler sind sehr kluge Leute und in ihrer Arbeit äußerst logisch. Sie verbringen 8 bis 10 Stunden am Tag damit, lange und komplexe logische Ketten aufzubauen, sodass sie im Handumdrehen Schwachstellen darin erkennen. Wenn sie etwas tun, möchten sie, wie alle anderen auch, verstehen, warum sie es tun und was sich zum Besseren verändern wird. Es ist äußerst wichtig, dass die Ziele, die Sie Ihrem Team setzen, ehrlich und realistisch sind. Der Versuch, einem Programmierteam eine schlechte Idee zu verkaufen, ist eine schlechte Idee. Eine Idee ist schlecht, wenn Sie selbst nicht daran glauben oder, im Extremfall, nicht den inneren Zustand haben, nicht zuzustimmen und sich zu verpflichten (ich bin nicht einverstanden, aber ich werde es tun). Wir haben einmal in einem Unternehmen ein Motivationssystem implementiert, zu dessen Bestandteilen ein elektronisches System zur Bereitstellung von Feedback gehörte. Sie haben viel Geld investiert, Leute zur Ausbildung nach Amerika gebracht, im Allgemeinen haben sie das Beste investiert. Einmal sagte einer der Manager in einem Gespräch nach der Schulung zu seinen Untergebenen: „Die Idee ist nicht schlecht, es sieht so aus, als würde sie funktionieren.“ Ich selbst werde Ihnen kein elektronisches Feedback geben, aber Sie geben es Ihren Leuten und verlangen es von ihnen.“ Das war's, es ließe sich nichts weiter umsetzen. Die Idee endete natürlich im Nichts.
Source: habr.com