Management eines Programmierteams: Wie und wie kann man sie richtig motivieren? Teil eins

Epigraph:
Der Ehemann, der die schmutzigen Kinder ansieht, sagt zu seiner Frau: Nun, was, wir waschen diese oder neue?

Im Rahmen der Diskussion unseres Teamleiters sowie von Igor Marnat, Direktor der RAS-Produktentwicklung, über die Merkmale der Motivation von Programmierern.


Das Erfolgsgeheimnis bei der Entwicklung cooler Softwareprodukte ist bekannt: Nehmen Sie ein Team cooler Programmierer, geben Sie dem Team eine coole Idee und stören Sie die Teamarbeit nicht. Coole Entwickler sind selten und gefragt. Einige Personalvermittler sagen sogar, dass sie den Eindruck haben, dass es einfacher ist, einen coolen Programmierer zur Welt zu bringen, als ihn vom Markt einzustellen. Zusätzlich zu den Schwierigkeiten bei der Einstellung als solche sind die Erfahrung jedes einzelnen Entwicklers, sein Wissen über ein vorhandenes Produkt und die Geschichte seiner Entwicklung oft unersetzlich oder werden hart und lang wieder aufgefüllt. Wenn Sie Glück haben und bereits ein cooles Team von Programmierern haben, ist es daher wichtig, an deren Motivation zu arbeiten. Es ist fast so schwierig und langwierig, neue Entwickler einzustellen, daraus ein Team zu machen und Kinder zu gebären und zu erziehen.

Berücksichtigen Sie die Hauptfaktoren, die Programmierer (Programmierteams) motivieren, indem Sie die Maslow-Pyramide verwenden, um die Präsentation klarer und strukturierter zu gestalten. Wenn Sie plötzlich nichts mehr von der Maslow-Pyramide gehört haben, ist dies keine unbestreitbare, aber sehr beliebte und visuelle Theorie des amerikanischen Psychologen Abraham Harold Maslow, der eine Theorie der Persönlichkeitsmotivation vorschlug, die auf einer Hierarchie menschlicher Bedürfnisse basiert (siehe Bild unten).

Maslow ordnete die Bedürfnisse des Individuums in einer hierarchischen Reihenfolge an, von physiologischen Bedürfnissen bis hin zur Notwendigkeit, Potenziale freizusetzen und sich selbst zu verwirklichen. Eine wichtige Annahme in Maslows Theorie lautet: "Eine Person kann die Bedürfnisse einer höheren Ebene erst erfahren, wenn ihre Bedürfnisse einer niedrigeren Ebene erfüllt sind." Zum Beispiel kann eine Person nicht von dem Bedürfnis nach Wissen oder ästhetischen Bedürfnissen getrieben werden, wenn diese Person drei Tage lang nicht geschlafen oder gegessen hat.



Bevor wir uns mit den Details befassen, wollen wir uns mit der offensichtlichen Tatsache befassen - das Team besteht aus Menschen, alle Menschen sind unterschiedlich, jeder hat seine eigene Motivationsstruktur. Neben der Tatsache, dass jede Person von unterschiedlichen Interessen getrieben wird, befindet sich jede Person auch in unterschiedlichen Lebensbedingungen. Jemand steht am Anfang einer Karriere und denkt darüber nach, wie man sie baut, jemand wird heiraten und jemand möchte ein neues Fachgebiet lernen. Was für den einen wichtig ist, ist für den anderen völlig unwichtig, und morgen wird sich alles wieder ändern. Um diesen Kontext richtig zu verstehen, gibt es ein einfaches Mittel: Sie müssen darüber nachdenken und damit arbeiten. Das Wichtigste ist die Kommunikation.
Sprechen Sie mit Ihrem Team über etwas anderes als Arbeit und bauen Sie eine informelle Beziehung auf.

Lassen Sie uns nun die Maslow-Pyramide durchgehen und ihre Ebenen für die Verwaltung eines Teams von Programmierern betrachten.

I: Physiologische, biologische Bedürfnisse:

Apropos Motivation: Viele denken vor allem oft an das Gehalt. In diesem Fall meine ich mit Gehalt den konstanten Teil des Vergütungspakets, der nicht von den Ergebnissen abhängt. Dies gilt nicht für Boni, Boni und Werbeaktionen des Unternehmens. Ich würde das Gehalt in unserem Fall dem Niveau der „physiologischen Bedürfnisse“ zuschreiben. Boni, Boni nach Arbeitsergebnissen, Optionen und Aktien des Unternehmens - all dies würde ich auf andere Ebenen verweisen.

Meiner Meinung nach mag das seltsamerweise klingen, dass das Gehalt eher ein demotivierender als ein motivierender Faktor ist. Die Besonderheit der Arbeit mit Programmierern besteht darin, dass sie alle Menschen sind, zum einen sehr klug (ein Merkmal des Berufs) und zum anderen tief und / oder umfassend ausgebildet. In der Regel sind Programmierer neben ihrem Beruf mit einem oder mehreren Themenbereichen, für die sie Produkte entwickeln, bestens vertraut. Darüber hinaus sind gute Programmierer interessiert und kennen die Geschichte der Programmierung, Algorithmen, Standards usw. Gleiches gilt für ihren Themenbereich. Für Menschen dieser Stufe ist das Gehalt normalerweise nicht der Hauptmotivationsfaktor.

Gleichzeitig demotiviert das Fehlen eines fairen Gehalts für Programmierer in ihrem Verständnis und demotiviert stark. Ein faires Gehalt ist die Norm. Das Gehalt ist viel höher als die Norm (Markt) - seltsamerweise ist der Faktor auch eher demotivierend. Ein Kollege erzählte mir einmal von einem Team von Programmierern in einem der großen animierten amerikanischen Unternehmen, das aus mehreren Gründen Gehälter in Höhe des Zwei- bis Dreifachen des Marktes erhielt. Wie er sagte, hatte er noch nie in seinem Leben sattere, faulere und demotiviertere Programmierer gesehen. Die Tatsache, dass eine Gehaltserhöhung kurzfristig motivieren kann, aber nach einigen Monaten ein neues Gehalt zur Norm wird und nicht mehr motiviert. Im Allgemeinen würde ich sagen, dass für Programmierer zu Beginn einer Karriere der Gehaltsfaktor wichtiger ist, da sie beruflich wachsen und sich entwickeln - seine Bedeutung nimmt ab und andere Faktoren beginnen sich durchzusetzen.

Der zweite wichtige Punkt ist das Vorhandensein eines fairen Gleichgewichts bei den Gehältern im Team. Wenn das Team der Meinung ist, dass der Beitrag eines der Teilnehmer spürbar geringer ist, die Vergütung jedoch nicht unterschiedlich ist, wird das gesamte Team demotiviert. Manchmal sind Manager versucht, das Feuer mit Geld zu überfluten - um eine ausgebrannte oder demotivierte Person zu halten und ihr Gehalt über die Norm zu erhöhen. Dies schafft normalerweise nur auf lange Sicht Probleme - die Motivation der Person selbst wird nicht besonders wachsen oder um ein paar Monate wachsen, aber die Motivation des Restes des Teams wird sinken. In solchen Situationen lohnt es sich, nach anderen Ansätzen zu suchen, es sei denn, es handelt sich natürlich um einen einzigartigen Spezialisten, der auch für kurze Zeit um jeden Preis gehalten werden muss.

II. Das Bedürfnis nach Sicherheit, Komfort und Beständigkeit der Lebensbedingungen:

Vor 70 Jahren konnte das Vorhandensein eines Ofens in einem Auto ein motivierender Faktor bei der Auswahl eines Autos sein, dann war es über der Norm, es war ein Zeichen von Luxus. Jetzt ist sogar das Fehlen einer Klimaanlage Unsinn, und ihre Anwesenheit wird kein motivierender Faktor bei der Auswahl eines Autos sein. Also vor 10-15 Jahren ein bequemes Büro, gutes Bügeleisen, leckerer Kaffee, Fitness, ein flexibler Zeitplan usw. könnte ein guter Motivationsfaktor sein, aber jetzt ist es eher die Norm für einen guten Programmierer, zu arbeiten. Gleichzeitig wird ihre Abwesenheit wieder demotivieren.

Ein wichtiger demotivierender Faktor ist die mangelnde Konzentrationsfähigkeit, ein lautes Arbeitsumfeld. Die Arbeit eines Programmierers erfordert Ruhe und Konzentration. Wenn die Büroräume keine Möglichkeit bieten, Entwicklern einen abgeschiedenen Arbeitsplatz zu bieten, muss zumindest eine komfortable Zusammenarbeit zwischen Kollegen sichergestellt werden, die sich nicht gegenseitig stören. Es ist besser, energische und laute Kameraden miteinander zu vereinen, damit sich diejenigen, die es brauchen, konzentrieren können.

Die Kosten für die Zeit des Programmierers sind jetzt deutlich höher als die Kosten für das Eisen, an dem er arbeitet. Zwei oder drei Monitore, leistungsstarke Computer, ein bequemer Arbeitsplatz für jeden Entwickler - sollten in jedem Unternehmen die Norm sein. Dieses Thema wird in einem von Joel Spolskys Artikeln " Der Joel-Test: 12 Schritte zu besserem Code" ausführlich beschrieben .

Die physische Komponente des Komforts ist die grundlegendste und einfachste. Lassen Sie uns nun über den Rest sprechen.

In vielen Unternehmen ist die Norm für Programmierer ein flexibler Arbeitszeitplan und ein Mangel an Kleiderordnung. Dies ist gut und richtig, wenn die Funktionen des Teams dies zulassen (z. B. gibt es keine Besprechungen mit Kunden, Politikern oder Bankern).

Ein wichtiger Punkt ist das Vorhandensein eines bestimmten Zeitfensters, in dem das gesamte Team vor Ort zusammenarbeitet, damit die Mitarbeiter persönlich kommunizieren und Probleme lösen können. Tatsächlich verlässt der Programmierer die Arbeit auch nach der Arbeit nicht. Normalerweise rollen Arbeitsmomente in seinem Kopf, unabhängig von seiner Anwesenheit im Büro, und gute Entscheidungen fallen oft außerhalb von ihm. Angesichts der Notwendigkeit, gut zu sein (worauf wir weiter unten eingehen), ist geringfügige Kontrolle schädlich. Es demotiviert nicht nur, sondern reduziert auch die Leistung. Wie die Praxis zeigt, wird ein motiviertes Team ohne Kontrolle wahrscheinlich länger als nötig arbeiten. Mit Kontrolle können Entwickler von neun bis sechs an der Tastatur sitzen, aber das Ergebnis wird meiner Meinung nach schlechter sein. Wie sie sagen, kann eine Person ein Pferd zu einer Wasserstelle bringen, aber selbst hundert werden es nicht zum Trinken bringen, wenn er nicht will.

In der Beschreibung dieses Bedarfsniveaus werden auch die Freiheit von Angst und Furcht, das Fehlen von Chaos, das Bedürfnis nach Struktur und Ordnung erwähnt. Dies sind auch ä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 für was verantwortlich ist, wie die Rollen zugewiesen werden, was zu tun ist, wer, wann, welche Anforderungen im Mittelpunkt des Produkts stehen, welche Erwartungen die Chefs und der Kunde haben ... Das meiste davon sollte formell beschrieben werden, sollte alles regelmäßig besprochen werden. Ohne Diskussion und regelmäßige Verwendung funktionieren Beschreibungen nicht. Es wird empfohlen, diese nach der postmortalen Analyse nach der Veröffentlichung regelmäßig zu überprüfen und zu aktualisieren.

Zweitens eine ruhige und freundliche Atmosphäre. Wir alle verbringen den größten Teil unserer Zeit bei der Arbeit und möchten dies ohne Stress, Konflikte oder Angst tun. Das Entwicklungsteam arbeitet in der Regel bereits unter dem Druck des Zeitplans und der Kunden. Niemand braucht zusätzlichen Stress von Kollegen und Vorgesetzten. Die Atmosphäre im Team im Allgemeinen, die Tatsache, dass eine Entwicklungsgruppe als „Team“ bezeichnet werden kann, ist die direkte und wichtige Verantwortung des Managers, eine der wichtigsten mittel- und langfristigen Aufgaben. Daher ist es wichtig, dass der Manager insbesondere mit Konflikten im Team arbeitet, damit sich seine Entwicklung nicht verschlechtert. Konfliktmanagement ist ein separates Thema, das eine separate Studie verdient.

Es gibt zwei Möglichkeiten, den emotionalen Zustand eines Teams zu beeinflussen, das Verhalten von Kollegen (wenn jemand in den Kommentaren etwas hinzufügt, ist das in Ordnung). Das erste ist ihr eigenes Verhalten. Ein persönliches Beispiel ist für den Manager und das Team sehr wichtig. Wie sie sagen, was Pop ist, so ist die Gemeinde. Verhalten Sie sich so, wie Sie es von Ihren Kollegen erwarten. Die zweite ist die Förderung des richtigen Verhaltens und sozusagen die Herabstufung des Falschen. Kommunizieren Sie mit Menschen, geben Sie ihnen Feedback, es gibt viele Möglichkeiten, dies zu tun. Im Allgemeinen ist Feedback ein Thema für eine weitere Diskussion, es ist ein großer und wichtiger Teil der Arbeit mit Motivation.

Eine weitere Bemerkung über die Atmosphäre, die ungewöhnlich erscheinen mag, aber in der Praxis wichtig ist. Meistens sind weniger Mädchen im Entwicklungsteam als Männer. Oft sind Teams komplett männlich. Unter solchen Bedingungen, auch unter Last, wird manchmal obszönes Vokabular im Team verwendet. Die Praxis zeigt, dass sich dies negativ auf die Atmosphäre auswirkt und die Kommunikation allmählich unhöflich wird. Sie sollten es vermeiden, es selbst zu verwenden, und es nicht in einem Team fördern.

Entwicklungsteams werden oft als F & E (Forschung und Entwicklung) bezeichnet, und Forschung ist ein wesentlicher Teil der Arbeit. 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, einen Fehler zu machen, die Initiative zu ergreifen, verschiedene Optionen auszuprobieren, die zum Erfolg führen oder nicht enden können. Fehler sind ein normaler Teil der Arbeit, sie können nicht vermieden werden, aber Sie können sie studieren, analysieren, für die Zukunft daraus lernen und weitermachen. Prinzip 5 Warum, das aus Toyota stammt, hilft, die Grundursache des Problems zu finden. Fehler zu bestrafen ist eine großartige Möglichkeit, eine Atmosphäre der Angst und Unsicherheit zu schaffen. Die einzige Ausnahme ist, wenn sich nach den Ergebnissen der Analyse herausstellt, dass der Fehler durch eine unprofessionelle Einstellung zur Arbeit verursacht wird. In diesem Fall kann es erforderlich sein, Personalentscheidungen zu treffen.

Die Atmosphäre im Team wird sehr stark von Ihren Erwartungen und dem emotionalen Zustand vor Beginn des Gesprächs beeinflusst. Bevor Sie eine schwierige Diskussion, eine Art Nachbesprechung oder nur ein emotionales Gespräch beginnen, ist Ihre Einstellung, Einstellung zu der Person, mit der Sie sprechen werden, wichtig. Ich denke immer standardmäßig und handle auf der Grundlage dessen, was eine Person aufrichtig versucht hat, das Beste zu tun. Wenn Sie sehen, dass dies nicht der Fall ist, müssen Sie ruhig und gründlich den Kontext herausfinden und verstehen, was er richtig gemacht hat, warum er es für richtig hielt und wo unsere Erwartungen abweichen. Normalerweise stellt sich heraus, dass sie nicht wirklich voneinander abweichen, nur seine Vision des Kontexts ist vollständiger oder frischer, und Sie wussten nichts. Oder im Gegenteil, er wusste nichts. Dies ist besonders wichtig in einem verteilten Team, wenn die Wahrscheinlichkeit geringer ist, dass Personen persönlich kommunizieren, E-Mails und Instant Messenger verwenden. Dies ist in einem Team, das aus Programmierern aus verschiedenen Ländern besteht und auf verschiedene Zeitzonen verteilt ist, noch kritischer. Hier spielen kulturelle Unterschiede eine große Rolle.

In einer schwierigen Situation ist es einfach, sehr einfach, sich im laufenden Betrieb zu bewegen, aber dann ist es schwierig, sich zurückzuziehen, und das Sediment bleibt lange Zeit erhalten. Ich werde ein einfaches Beispiel aus jüngster Erfahrung geben. Einer der Teammanager benötigte dringend Kommentare zu einem Kundenproblem von einem Manager eines benachbarten Teams aus einem anderen Land. Er pingte einen Kollegen im Messenger an, wartete 15 Minuten, pingte erneut, ging dann 15 Minuten später in einen großen Chat, in dem sich andere Manager befanden, und traf leicht einen Kollegen mit der Formulierung: „Da Sie sich vielleicht nicht dazu herablassen, mir zu antworten und die Frage ist nicht so dringend? ”. Infolgedessen stellte sich heraus, dass unser Corporate Messenger etwas langweilig war und der Kollege die Frage überhaupt nicht sah. Ich musste mich entschuldigen. Im Allgemeinen ist es besser, vom Guten auszugehen. Es ist immer möglich, einen Fehler zu machen und später zu überfahren. Es gibt keine Probleme damit (obwohl Sie dies nicht tun sollten). Im Allgemeinen habe ich während mehr als 20 Jahren Arbeit in unserer Branche nur einmal (!) Einen wirklich bösartigen Kollegen getroffen. Zum Glück haben wir uns ziemlich schnell getrennt. Die Annahme, dass Kollegen das Beste wollen, um das Beste aus ihrer Sicht des Kontexts herauszuholen, ist in den allermeisten Fällen richtig.

Ihre Aufgabe als Manager ist es, die Synchronisation der Kontexte und ein gemeinsames Verständnis der Erwartungen, Anforderungen und Fristen sicherzustellen, die vom Standardteam festgelegt wurden. Es mag wie Kleinigkeiten erscheinen, aber die Atmosphäre im Team ist genau aus solchen Kleinigkeiten aufgebaut. Aus Sicht eines verteilten Teams besteht eine der wichtigsten Aufgaben darin, eine regelmäßige persönliche Kommunikation der Teammitglieder sicherzustellen. Ich habe oft von Programmierern gehört, dass zum Beispiel, nachdem die Ingenieure des Supportteams zu ihnen gekommen waren und persönlich zusammengearbeitet hatten, sie glücklich bei der Arbeit blieben, um Pascha, der sie kürzlich besuchte, in einem schwierigen Fall persönlich zu helfen, obwohl früher Pascha war nur eine Ikone im Boten, und niemand würde um der Ikone willen verweilen.

Ich habe übrigens über das Support-Team gesprochen und mich an ein kanonisches Beispiel für mich erinnert. Irgendwie hatte einer der Kunden in Amerika ein Problem mit dem Produkt, einer der Support-Team-Ingenieure, die an seiner Implementierung arbeiteten (aus Russland geschickt), blieb nach der Arbeit, um zu helfen, aber das Problem wurde nicht gelöst und wurde nicht gelöst. Im Allgemeinen verweilte er und saß fast bis zum Morgen dort. Zu diesem Zeitpunkt eskalierten Kundenmanager das Problem, identifizierten seine Kritikalität für sie und verließen die Arbeit am Abend. Der Eskalationsprozess gewann bereits in einer anderen Zeitzone an Dynamik. Support-Manager in Russland versuchten zu helfen, da sie Schwierigkeiten bei der Kommunikation mit dem Kundenbüro hatten (VPN, Kommunikationsprobleme, Schwierigkeiten bei Anrufen zwischen Ländern, ...). Sie wussten nicht, dass der Mann bereits saß im Büro und löst das Problem und versuchte ihn zu finden. Gefunden erst am Morgen (Amerikaner), als das Problem von ihm bereits praktisch gelöst und das Produkt verdient wurde. Sie rannten in den Steinbruch, was zum Teufel, der Kunde hat eine solche Eskalation, nichts funktioniert, wo er dich trägt, wir können dich nicht finden usw. Unnötig zu erwähnen, dass der Typ aufgrund dieses Verhaltens sehr demotiviert war. Die Organisation eines verteilten Teams ist ein separates großes Thema, aber es gibt zwei Dinge zu beachten. Kommunikation, Atmosphäre sind sehr wichtig, der Erfolg der Arbeit hängt davon ab. Zweitens funktioniert dies nicht von alleine, es muss separat und eingehend behandelt werden.

Ein weiterer wichtiger Punkt im Zusammenhang mit diesem Bedarfsniveau ist wieder das Gehalt. Nicht die Höhe des Gehalts als solches, sondern die Existenz einer bestimmten Reihenfolge seiner Änderung. Das Unternehmen sollte einen Ansatz zur Bestimmung der Anforderungen für Positionen auf verschiedenen Ebenen haben. Jeder Entwickler sollte in der Lage sein, die Erwartungen für seine Arbeit mit dem Unternehmen zu besprechen, um zu verstehen, wie und wann sich seine Bemühungen auf sein Gehalt auswirken können. Zu diesem Zweck dienen regelmäßige Treffen mit dem Manager, halbjährliche oder jährliche Zertifizierungen. Dies ist wiederum einer jener Momente, deren Anwesenheit nicht explizit motiviert, deren Abwesenheit jedoch stark motiviert.

Aus der Notwendigkeit der Ordnung und der Verfügbarkeit von Regeln folgt die Notwendigkeit, diese Regeln einzuhalten und die vom Team verabschiedeten formellen und informellen Regeln einzuhalten. Im Allgemeinen würde ich sie das Bedürfnis nennen, "gut zu sein". Das Vorhandensein dieses Bedarfs bestätigt, dass Mikromanagement nicht erforderlich, sondern schädlich ist. Es reicht aus, eine Person mit allem zu versorgen, was für die Arbeit notwendig ist, sie über den Kontext und die Prioritäten zu informieren und auf ihrer Ebene Handlungs- und Entscheidungsfreiheit zu bieten. , , .

, — , . . . , , . , , . — , , , . “ Google — Site Reliability Engineering ”, , , , , .

Fortsetzung folgt...