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 die Diskussion unseres Teamleiters sowie des RAS-Produktentwicklungsdirektors Igor Marnat über die Besonderheiten der Motivation von Programmierern.
Das Erfolgsgeheimnis bei der Entwicklung cooler Softwareprodukte ist bekannt: Nehmen Sie ein Team aus coolen Programmierern, geben Sie dem Team eine coole Idee und stören Sie die Arbeit des Teams nicht. Coole Entwickler sind rar und gefragt. Einige Personalvermittler sagen sogar, dass sie den Eindruck haben, dass es einfacher ist, einen coolen Programmierer hervorzubringen, als ihn auf dem Markt einzustellen. Zusätzlich zu den Schwierigkeiten bei der Personalbeschaffung an sich ist die Erfahrung jedes einzelnen Entwicklers, sein Wissen über das bestehende Produkt und die Geschichte seiner Entwicklung oft unersetzlich oder es ist schwierig und zeitaufwändig, es wieder aufzufüllen. Wenn Sie also Glück haben und bereits ein cooles Programmiererteam haben, ist es wichtig, an deren Motivation zu arbeiten. Neue Entwickler einzustellen, auszubilden und daraus ein Team zu bilden, ist fast so schwierig und zeitaufwändig wie die Geburt und Erziehung von Kindern.
Betrachten wir die Hauptmotivationsfaktoren für Programmierer (Programmiererteams) und verwenden wir Maslows Pyramide für Klarheit und Strukturierung der Präsentation. Wenn Sie noch nichts von Maslows Pyramide gehört haben: Es handelt sich nicht um eine unbestrittene, aber sehr beliebte und anschauliche Theorie des amerikanischen Psychologen Abraham Harold Maslow, der eine Theorie der persönlichen Motivation vorschlug, die auf der Hierarchie menschlicher Bedürfnisse basiert (siehe Bild unten).
Maslow ordnete die Bedürfnisse des Einzelnen in eine hierarchische Reihenfolge, von physiologischen Bedürfnissen bis hin zum Bedürfnis nach potenzieller Entwicklung und Selbstverwirklichung. Eine Schlüsselannahme in Maslows Theorie ist, dass „ein Mensch höhere Bedürfnisse nicht verspüren kann, bis seine Bedürfnisse auf niedrigerer Ebene befriedigt sind.“ Beispielsweise kann ein Mensch nicht von Wissensbedürfnissen oder ästhetischen Bedürfnissen getrieben werden, wenn er gleichzeitig drei Tage lang nicht geschlafen oder gegessen hat.
Bevor wir ins Detail gehen, konzentrieren wir uns auf eine offensichtliche Tatsache: Ein Team besteht aus Menschen, alle Menschen sind unterschiedlich, jeder hat seine eigene Motivationsstruktur. Abgesehen davon, dass jeder Mensch von unterschiedlichen Interessen angetrieben wird, befindet sich jeder Mensch auch in unterschiedlichen Lebensumständen. Jemand steht am Anfang einer Karriere und denkt darüber nach, wie er sie aufbauen kann, jemand wird heiraten und jemand möchte ein neues Fachgebiet beherrschen. Was für den einen wichtig ist, ist für den anderen völlig unwichtig, und morgen wird sich alles wieder ändern. Um diesen Zusammenhang richtig zu verstehen, gibt es ein einfaches Mittel: Man muss darüber nachdenken und damit arbeiten. Das Wichtigste ist die Kommunikation.
Sprechen Sie mit Ihrem Team unbedingt über etwas anderes als die Arbeit und bauen Sie informelle Beziehungen auf.
Lassen Sie uns nun die Maslow-Pyramide durchgehen und ihre Ebenen im Hinblick auf die Verwaltung eines Programmiererteams betrachten.
I: Physiologische, biologische Bedürfnisse:
Wenn es um Motivation geht, denken viele Menschen oft zuerst an das Gehalt. Unter Gehalt verstehe ich in diesem Fall einen festen Bestandteil des Vergütungspakets, der in keiner Weise vom Ergebnis abhängt. Dies gilt nicht für Prämien, Prämien und Firmenaktionen. Es ist das Gehalt, das ich in unserem Fall dem Niveau der „physiologischen Bedürfnisse“ zuordnen würde. Boni, leistungsabhängige Prämien, Optionen und Unternehmensanteile – das alles würde ich auf anderen Ebenen einordnen.
Meiner Meinung nach könnte das Gehalt, so seltsam es auch klingen mag, eher sein demotivierend Faktor und nicht ein motivierender Faktor. Die Besonderheit bei der Arbeit mit Programmierern besteht darin, dass es sich bei allen um Menschen handelt, die erstens sehr klug sind (ein Merkmal des Berufs) und zweitens über eine fundierte und/oder umfassende Bildung verfügen. Typischerweise verfügen Programmierer zusätzlich zu ihrem Beruf über ein tiefes Verständnis für einen oder mehrere Themenbereiche, für die sie Produkte erstellen. Darüber hinaus sind gute Programmierer an der Geschichte der Programmierentwicklung, Algorithmen, Standards usw. interessiert und kennen diese gut. Gleiches gilt für ihr Fachgebiet. Für Menschen auf dieser Ebene ist das Gehalt normalerweise nicht der Hauptmotivationsfaktor.
Gleichzeitig ist das Fehlen eines fairen Gehalts für Programmierer nach ihrem Verständnis demotivierend und demotivierend. Ein faires Gehalt ist die Norm. Das Gehalt liegt deutlich über der Norm (Markt) – seltsamerweise auch ein eher demotivierender Faktor. Ein Kollege erzählte mir einmal von einem Team von Programmierern in einem der großen amerikanischen Animationsunternehmen, das aufgrund verschiedener Umstände zwei- bis dreimal höhere Gehälter als der Markt erhielt. Wie er sagte, habe er in seinem Leben noch nie mehr gelangweilte, faule und demotivierte Programmierer gesehen. Die Tatsache einer Gehaltserhöhung mag kurzfristig motivierend sein, doch nach ein paar Monaten wird das neue Gehalt zur Norm und hört auf, zu motivieren. Generell würde ich sagen, dass für Programmierer am Anfang ihrer Karriere der Gehaltsfaktor wichtiger ist, da er mit zunehmender beruflicher Weiterentwicklung abnimmt und andere Faktoren überwiegen.
Der zweite wichtige Punkt ist das Vorhandensein einer fairen Ausgewogenheit der Gehaltshöhe im Team. Wenn ein Team das Gefühl hat, dass der Beitrag eines Mitglieds spürbar geringer ist, die Höhe der Vergütung jedoch gleich bleibt, demotiviert dies das gesamte Team. Manchmal sind Manager versucht, das Feuer mit Geld anzuheizen – um eine ausgebrannte oder demotivierte Person zu behalten, indem sie ihr Gehalt über den Normalwert anheben. Dies führt in der Regel nur auf lange Sicht zu Problemen – die Motivation der Person selbst wird nicht viel steigen, oder sie wird für ein paar Monate zunehmen, aber die Motivation des restlichen Teams wird sinken. In solchen Situationen lohnt es sich, nach anderen Ansätzen zu suchen, es sei denn natürlich, es handelt sich um einen einzigartigen Spezialisten, der um jeden Preis, auch nur für kurze Zeit, gehalten werden muss.
II. Bedürfnis nach Sicherheit, Komfort, Gleichmäßigkeit der Lebensbedingungen:
Vor 70 Jahren konnte das Vorhandensein eines Ofens im Auto ein motivierender Faktor bei der Wahl eines Autos sein; damals lag er über der Norm und war ein Zeichen von Luxus. Nun ist selbst das Fehlen einer Klimaanlage Unsinn, und ihre Anwesenheit wird natürlich kein motivierender Faktor bei der Wahl eines Autos sein. Also vor 10-15 Jahren ein bequemes Büro, gute Hardware, leckeren Kaffee, Fitness, flexible Arbeitszeiten usw. Könnten gute Motivationsfaktoren sein, mittlerweile ist dies aber eher die Norm für die Arbeit eines guten Programmierers. Gleichzeitig wird ihre Abwesenheit erneut demotivierend sein.
Ein wichtiger demotivierender Faktor ist mangelnde Konzentrationsfähigkeit und eine laute Arbeitsumgebung. Die Arbeit eines Programmierers erfordert Ruhe und Konzentration. Wenn die Büroräume nicht die Möglichkeit bieten, Entwicklern einen abgeschiedenen Arbeitsplatz zu bieten, ist es notwendig, zumindest eine angenehme Zusammenarbeit zwischen Kollegen zu gewährleisten, die sich nicht gegenseitig stören. Es ist besser, energische und lautstarke Kameraden miteinander zu vereinen und denjenigen die Möglichkeit zu geben, sich zu konzentrieren, die es brauchen.
Die Zeitkosten eines Programmierers sind mittlerweile deutlich höher als die Kosten für die Hardware, auf der er arbeitet. Zwei oder drei Monitore, leistungsstarke Rechner, ein komfortabler Arbeitsplatz für jeden Entwickler – sollte in jedem Unternehmen selbstverständlich sein. Dieses Thema wird in einem Artikel von Joel Spolsky ausführlich behandelt:Der Joel-Test: 12 Schritte zu besserem Code.“
Die physische Komponente des Komforts ist die grundlegendste und einfachste; lassen Sie uns nun über den Rest sprechen.
In vielen Unternehmen gelten für Programmierer flexible Arbeitszeiten und keine Kleiderordnung. Das ist gut und richtig, wenn es die Besonderheiten der Teamarbeit zulassen (z. B. keine Treffen mit Kunden, Politikern oder Bankern).
Wichtig ist, dass es ein bestimmtes Zeitfenster gibt, in dem das gesamte Team vor Ort zusammenarbeitet, damit die Leute persönlich kommunizieren und Probleme lösen können. Im Wesentlichen verlässt ein Programmierer die Arbeit nicht, auch nicht nach der Arbeit. Arbeitsprobleme gehen ihm normalerweise immer wieder durch den Kopf, unabhängig davon, ob er im Büro ist, und gute Entscheidungen werden oft von außerhalb des Büros getroffen. Angesichts der Notwendigkeit, gut zu sein (auf die wir weiter unten eingehen werden), ist kleinliche Kontrolle schädlich. Es ist nicht nur demotivierend, sondern verringert auch die Produktivität. Wie die Praxis zeigt, arbeitet ein motiviertes Team ohne Kontrolle eher länger als nötig. Wenn es Kontrolle gibt, können Entwickler von neun bis sechs an der Tastatur sitzen, aber das Ergebnis wird meiner Meinung nach schlechter sein. Wie man sagt, kann eine Person ein Pferd zum Tränken führen, aber selbst hundert werden es nicht zum Trinken zwingen, wenn es nicht will.
In der Beschreibung dieser Bedürfnisebene werden auch die Freiheit von Angst und Furcht, die Abwesenheit von Chaos sowie das Bedürfnis nach Struktur und Ordnung erwähnt. Auch das sind äußerst wichtige Punkte, die die Atmosphäre im Team stark beeinflussen.
Erstens das Fehlen von Chaos, Struktur und Ordnung – das Team muss verstehen, wer wofür verantwortlich ist, wie die Rollen verteilt sind, was zu tun ist, an wen, wann, welche Anforderungen dem Produkt zugrunde liegen, welche Erwartungen das Management hat usw der Kunde... Das meiste davon sollte formell beschrieben werden, alles sollte regelmäßig besprochen werden. Ohne Diskussion und regelmäßige Verwendung funktionieren Beschreibungen nicht. Es empfiehlt sich, sie regelmäßig zu besprechen und auf der Grundlage der Ergebnisse der Post-Mortem-Analyse nach der Veröffentlichung zu aktualisieren.
Zweitens eine ruhige und freundliche Atmosphäre. Wir alle verbringen die meiste Zeit bei der Arbeit und möchten dies ohne Stress, Konflikte oder Angst tun. Das Entwicklungsteam arbeitet normalerweise unter dem Druck von Zeitplänen und Kunden. Niemand braucht zusätzlichen Stress durch Kollegen und Vorgesetzte. Die Atmosphäre im Team, im Allgemeinen die Tatsache, dass eine Gruppe von Entwicklern berufen und ein „Team“ sein kann, liegt in der direkten und wichtigen Verantwortung des Managers, eine der wichtigsten mittel- und langfristigen Aufgaben. Daher ist es für eine Führungskraft wichtig, insbesondere mit Konflikten im Team zu arbeiten und deren Entwicklung nicht ihren Lauf zu lassen. Konfliktmanagement ist ein separates Thema, das eine gesonderte Untersuchung verdient.
Es gibt zwei Hauptmöglichkeiten, den emotionalen Zustand des Teams und das Verhalten der Kollegen zu beeinflussen (wenn jemand in den Kommentaren etwas hinzufügt, wäre das großartig). Das erste ist Ihr eigenes Verhalten. Persönliches Beispiel ist für einen Manager und ein Team äußerst wichtig. Wie sie sagen: So wie der Priester, so ist auch die Ankunft. Verhalten Sie sich so, wie Sie es von Ihren Kollegen erwarten. Die zweite besteht darin, richtiges Verhalten zu fördern und falsches Verhalten sozusagen zu entmutigen. Mit Menschen kommunizieren, ihnen Feedback geben, es gibt viele Möglichkeiten, dies zu tun. Im Allgemeinen ist Feedback ein Thema für eine gesonderte Diskussion; es ist ein großer und wichtiger Teil der Arbeit mit Motivation.
Noch eine Anmerkung zur Atmosphäre, die vielleicht ungewöhnlich erscheint, in der Praxis aber wichtig ist. Meistens sind im Entwicklungsteam weniger Mädchen als Männer. Oft sind die Gruppen ausschließlich männlich. Unter solchen Bedingungen, auch unter Belastung, kommt es im Team teilweise zu obszönen Ausdrücken. Die Praxis zeigt, dass sich dies negativ auf die Atmosphäre auswirkt, die Kommunikation wird allmählich unhöflich. Sie sollten es vermeiden, es selbst zu verwenden, und die Verwendung in Ihrem Team verhindern.
Entwicklungsteams werden oft als R&D (Forschung und Entwicklung) bezeichnet, wobei die Forschung einen erheblichen Teil der Arbeit ausmacht. Dies ist der Teil, der normalerweise schwer zu programmieren und zu planen ist, sonst wäre es keine Forschung. Es ist wichtig, dass das Team das Recht hat, Fehler zu machen, Initiative zu ergreifen und verschiedene Optionen auszuprobieren, die zum Erfolg führen können oder auch nicht. Fehler sind ein normaler Teil der Arbeit, sie können nicht vermieden werden, aber man kann sie studieren, analysieren, daraus für die Zukunft lernen und weitermachen. Das 5-Warum-Prinzip, das bei Toyota seinen Ursprung hat, ist ein guter Weg, um der Ursache eines Problems auf den Grund zu gehen. Fehler zu bestrafen ist eine gute Möglichkeit, eine Atmosphäre der Angst und Unsicherheit zu schaffen. Die einzige Ausnahme besteht darin, dass sich aufgrund der Ergebnisse der Analyse herausstellt, dass der Fehler auf eine unprofessionelle Arbeitseinstellung zurückzuführen ist. In diesem Fall müssen möglicherweise Personalentscheidungen getroffen werden.
Die Atmosphäre im Team wird stark von Ihren Erwartungen und Ihrer emotionalen Verfassung vor Gesprächsbeginn beeinflusst. Bevor Sie eine schwierige Diskussion, eine Nachbesprechung oder einfach nur ein emotionales Gespräch beginnen, ist Ihre Stimmung und Einstellung gegenüber der Person, mit der Sie sprechen werden, wichtig. Ich glaube und handle standardmäßig immer auf der Grundlage dessen, was die Person aufrichtig versucht hat, das Beste zu tun. Wenn aus Ihrer Sicht der Eindruck entsteht, dass dies nicht der Fall ist, müssen Sie in Ruhe und im Detail den Kontext herausfinden und verstehen, was er richtig gemacht hat, warum er es für richtig hielt und wo unsere Erwartungen voneinander abweichen. Es stellt sich normalerweise heraus, dass sie nicht wirklich voneinander abweichen, es ist nur so, dass seine Sicht auf den Kontext vollständiger oder frischer ist und dass es etwas gibt, das Sie nicht wussten. Oder umgekehrt, er wusste etwas nicht. Dies ist besonders wichtig in einem verteilten Team, wenn die Leute seltener persönlich kommunizieren und E-Mail und Instant Messenger nutzen. Dies ist umso wichtiger, wenn ein Team aus Programmierern aus verschiedenen Ländern besteht und über verschiedene Zeitzonen verteilt ist. Hier beginnen kulturelle Unterschiede eine große Rolle zu spielen.
In einer schwierigen Situation ist das Fahren während der Fahrt einfach, sehr einfach, aber dann ist das Zurückfahren schwierig und der Bodensatz bleibt lange zurück. Lassen Sie mich Ihnen ein einfaches Beispiel aus jüngster Erfahrung geben. Einer der Teammanager benötigte dringend Kommentare zu einem Problem mit einem Kunden von einem Manager eines verwandten Teams in einem anderen Land. Er pingte einen Kollegen im Messenger an, wartete 15 Minuten, pingte erneut, dann ging er 15 Minuten später zu einem großen Chat, in dem auch die anderen Manager waren, und griff den Kollegen leicht an, mit einer Formulierung wie: „Da Sie es nicht tun.“ Würden Sie sich vielleicht herablassen, mir zu antworten, und die Frage ist nicht so dringend?“ Am Ende stellte sich heraus, dass unser Firmen-Messenger etwas langweilig war und der Kollege die Frage überhaupt nicht sah. Ich musste mich entschuldigen. Im Allgemeinen ist es besser, mit dem Guten zu beginnen. Es ist immer möglich, einen schweren Fehler zu machen und später in Schwierigkeiten zu geraten; das ist kein Problem (obwohl Sie das nicht tun sollten). Im Allgemeinen bin ich in mehr als 20 Jahren Arbeit in unserer Branche nur einmal (!) einem wirklich böswilligen Kollegen begegnet. Zum Glück haben wir uns ziemlich schnell getrennt. Es erweist sich in den allermeisten Fällen als richtig, davon auszugehen, dass die Kollegen nach bestem Wissen und Gewissen das Beste wollen.
Ihre Aufgabe als Führungskraft ist es, für eine Synchronisierung der Zusammenhänge, ein gemeinsames Verständnis von Erwartungen, Anforderungen, Fristen und im Team akzeptierten Standards zu sorgen. Das mögen wie Kleinigkeiten erscheinen, aber die Atmosphäre im Team baut sich genau aus solchen Kleinigkeiten auf. Aus der Perspektive eines verteilten Teams besteht eine der wichtigen Aufgaben darin, sicherzustellen, dass die Teammitglieder regelmäßig persönlich kommunizieren. Ich habe mehr als einmal von Programmierern gehört, dass sie, nachdem beispielsweise Ingenieure aus dem Support-Team zu ihnen kamen und persönlich zusammenarbeiteten, gerne bei der Arbeit blieben, um Pasha, der kürzlich zu ihnen gekommen war, in einem schwierigen Fall persönlich zu helfen. obwohl früher Pascha nur eine Ikone im Messenger war und niemand wegen der Ikone angehalten hätte.
Übrigens begann ich über das Support-Team zu sprechen und erinnerte mich an ein kanonisches Beispiel für mich. Einmal hatte einer der Kunden in Amerika ein Problem mit dem Produkt. Einer der Ingenieure des Support-Teams, der an seiner Implementierung arbeitete (abgeordnet aus Russland), blieb nach der Arbeit, um zu helfen, aber das Problem wurde nicht gelöst und wurde nicht gelöst. Im Allgemeinen blieb er dort und saß fast bis zum Morgen. Zu diesem Zeitpunkt eskalierten die Manager des Kunden das Problem, stellten fest, wie kritisch es für sie war, und verließen abends die Arbeit. Der Eskalationsprozess nahm in einer anderen Zeitzone bereits Fahrt auf. Support-Manager in Russland versuchten zu helfen, da es bestimmte Kommunikationsschwierigkeiten mit dem Büro des Kunden gab (VPN, Verbindungsprobleme, Schwierigkeiten bei Anrufen zwischen Ländern usw.). Ich wusste nicht, dass der Mann bereits im Büro saß, löste das Problem und versuchte, ihn zu finden. Sie fanden es erst am Morgen (amerikanisch), als das Problem bereits praktisch gelöst war und das Produkt funktionierte. Sie fingen sofort an zu sagen: „Was zum Teufel, der Kunde hat eine solche Eskalation, nichts funktioniert, wo bist du, wir können dich nicht finden usw.“ Unnötig zu erwähnen, dass der Typ aufgrund dieses Verhaltens stark demotiviert war. Die Organisation der Arbeit eines verteilten Teams ist ein separates großes Thema, aber es ist wichtig, sich an zwei Dinge zu erinnern. Erstens sind Kommunikation und Atmosphäre sehr wichtig, der Erfolg der Arbeit hängt davon ab. Zweitens funktioniert dies nicht von alleine, sondern muss separat und ausführlich behandelt werden.
Ein weiterer wichtiger Punkt im Zusammenhang mit diesem Bedarfsniveau ist wiederum das Gehalt. Nicht die Höhe des Gehalts als solches, sondern das Vorhandensein eines bestimmten Verfahrens zu seiner Änderung. Das Unternehmen muss über einen Ansatz verfügen, um die Anforderungen für Positionen auf verschiedenen Ebenen zu ermitteln. Jeder Entwickler sollte in der Lage sein, die Erwartungen an seine Arbeit mit dem Unternehmen zu besprechen und zu verstehen, wie und wann sich seine Bemühungen auf sein Gehalt auswirken können. Hierzu dienen regelmäßige Treffen mit der Führungskraft sowie halbjährliche oder jährliche Leistungsbeurteilungen. Dies ist wiederum einer dieser Momente, deren Anwesenheit nicht explizit motiviert, deren Abwesenheit jedoch sehr demotivierend ist.
Aus dem Bedürfnis nach Ordnung und dem Vorhandensein von Regeln ergibt sich die Notwendigkeit, diese Regeln einzuhalten und die im Team akzeptierten Normen zu befolgen, sowohl formelle als auch informelle. Generell würde ich es das Bedürfnis nennen, „gut zu sein“. Das Vorhandensein dieses Bedarfs bestätigt, dass Mikromanagement nicht notwendig, sondern eher schädlich ist. Es reicht aus, einem Menschen alles Notwendige für die Arbeit zur Verfügung zu stellen, ihm Kenntnisse über den Kontext und die Prioritäten zu vermitteln und ihm Handlungs- und Entscheidungsfreiheit auf seiner Ebene zu geben. Unter solchen Bedingungen wird er Vertrauen spüren, die Möglichkeit, eigene Entscheidungen zu treffen, Verantwortung dafür zu übernehmen und sein Potenzial zu entfalten.
Ein weiterer wichtiger Punkt, der dem Bedürfnis nach Ordnung und der Abwesenheit von Chaos zugeschrieben werden sollte, ist die Fähigkeit, sich auf eine Aufgabe zu konzentrieren, das Fehlen häufiger Kontextwechsel. Als Programmierer braucht man Zeit und Konzentration. Programmierer mögen es wirklich nicht, eine Aufgabe dringend aufzugeben und zu einer anderen zu wechseln. Ein notwendiger Teil der Arbeit eines Programmierers ist in der Regel nicht nur die eigentliche Entwicklung des Codes, sondern auch die Fehlerbehebung und die Unterstützung bei der Bearbeitung von Kundenanfragen. Es lohnt sich, solche Dinge im Voraus zu planen, damit der Programmierer die Arbeit an einer Aufgabe ruhig und vollständig abschließen kann, bevor er zu einer anderen wechselt. Die beste Option besteht darin, sich selbst die Möglichkeit zu geben, Ihre Arbeit selbst zu planen, Prioritäten und anstehende Aufgaben im Voraus zu identifizieren und lange, längere Zeiträume für die Arbeit an einer Art von Aufgabe einzuplanen. Dieses Thema wird in dem Buch „Google – Site Reliability Engineering“, das Ansätze zur Planung der Arbeit von Teams, die den Betrieb und die Entwicklung großer, hochbelasteter, fehlertoleranter Systeme sicherstellen, sowie von Ingenieuren, deren Beruf Softwareentwicklung und deren Support vereint, gut beschreibt.
To be continued ...
Source: habr.com