JH Regenwasser „Wie man Katzen weidet“: Rassen von Programmierern und Merkmale ihrer Zucht

Es wurde bereits viel über das Management von Menschen als Ganzes gesagt (vielen zufolge mehr als genug). Das Verwalten von Programmierern unter Berücksichtigung der Besonderheiten ihrer Aufgaben, der Organisation der Arbeit und der internen Beziehungen in einem Team ist viel weniger. Jeder Versuch, Ihre Erfahrungen mit einer Person zusammenzufassen und zu analysieren, die in der IT-Umgebung, als Entwickler und als Manager gekocht hat, ist von besonderem Wert für diejenigen, die sich darauf vorbereiten, den gleichen Weg zu gehen und zu überlegen, wie allgemeine Management-Theorien auf die Realitäten des Programmierers angewendet werden können.

J. Hank Rainwater, ein Programmierer der alten Schule, ist einer der Menschen, die den Tritt in die Rolle des technischen Leiters vergeblich kennen, weil sie selbst in ihnen schwebten. Sein Buch „ How to Graze Cats “ besticht durch seine Objektivität: Es beschreibt spezifische Situationen, die jedem bekannt sind, verschiedene Komponenten und Arbeitsbedingungen des Teams und sogar die technologischen Lösungen des Autors (leider bereits veraltet). In einer kurzen Artikelserie möchten wir alles behandeln, was uns im Buch am nützlichsten und relevantesten erschien - von der Typologie der Mitarbeiter bis hin zu Empfehlungen für die Kommunikation mit anderen Teams.

Beginnen Sie mit einer vernünftigen Frage: Warum eigentlich Katzen? Der Autor selbst verweist als Erklärung auf ein Zitat von Helen Alman, die diese Analogie in ihrem Buch Close to the Machine zeichnet:

„Einer meiner Bekannten mit Projektmanagern hat einmal den Prozess der Verwaltung von Programmierern mit dem Weiden von Katzen verglichen. Er wollte sagen, dass die Hunde, die treu in die Augen schauen, wir absolut nicht brauchen. Ein guter Programmierer muss zusammen mit all seinen Kuriositäten geschätzt werden. Auf der anderen Seite müssen all diese guten Programmierer irgendwie dazu gebracht werden, sich in eine Richtung zu bewegen. “

Erstens sind Programmierer mit Katzen verwandt, weil weder der eine noch der andere eine angeborene Tendenz hat, in die Irre zu gehen. Sie ziehen es vor, alleine zu gehen, und die Kultur, die sich im IT-Bereich entwickelt hat, hat diese Art von Verhalten seit langem gefördert (oder zumindest nicht behindert). Dementsprechend steht der technische Manager vor einer doppelt schwierigen Aufgabe: Um einzelne Personen in einer mehr oder weniger zusammenhängenden Gruppe zu organisieren, ohne ihre Individualität zu verletzen, müssen Sie höchstwahrscheinlich Ihre eigenen Fähigkeiten im Umgang mit Personen verbessern.

The Rainwater definiert seine Zielgruppe wie folgt: Neulinge im Management (Entwickler von gestern, die eine Führungsposition erhalten haben), Leiter kleiner Teams (bis zu zehn Personen), die an mehreren Projekten von kleinen oder mittleren Unternehmen arbeiten. In größerem Maßstab funktionieren einige Techniken nicht mehr, und erfahrene technische Leiter haben wahrscheinlich bereits viel für sich selbst gelernt. Das Buch soll dem Leiter in der akutesten Übergangsphase helfen und sich auf zukünftige Veränderungen vorbereiten.

Wenn Sie allgemein sehen, steht ein unerfahrener Manager vor zwei Hauptproblemen: Eine neue Position verändert die Mechanismen seiner Interaktion grundlegend, zum einen mit Menschen und zum anderen mit Prozessen. Wir werden später ausführlich auf die zweite eingehen, aber ein häufiger Fehler sollte sofort erwähnt werden.

Sehr viele können nicht akzeptieren, dass sie einen Teil ihrer Aufgaben im Zusammenhang mit dem Schreiben von Code aufgeben müssen. Je stärker der Programmierer, desto stärker das Gefühl des Protests. Die Situation wird durch ein neues Verantwortungsbewusstsein für den gesamten Code, den das Team produziert, verschärft. Anstatt die Zeit neu zu verteilen und Stunden für die Verwaltungsarbeit aufzuwenden, macht sich der Manager große Sorgen um die technische Seite von Projekten - er führt alle Überprüfungen selbst durch, überprüft das Design akribisch oder schreibt sogar die erfolglosen Fragmente neu. Die hartnäckigsten vernachlässigen alle anderen Verantwortlichkeiten, die nicht direkt mit dem Code zusammenhängen, und dies endet in einer Katastrophe. Die nüchterneren verwandeln sich in Werwölfe: tagsüber der Anführer, nachts der Programmierer, und dies endet mit Burnout.

Aus diesem Grund muss ein technischer Leiter zunächst die Unvermeidlichkeit von Änderungen in der Arbeitsstruktur erkennen und akzeptieren und sich auf eine ziemlich lange Zeit des „Auseinanderbrechens“ einstellen. Der Autor schätzt die Anpassungszeit auf etwa sechs Monate - erst zu diesem Zeitpunkt gewöhnt sich die Mehrheit an die neue Rolle und fühlt sich darin wohl. Man kann sich darüber trösten, dass die Definition von „technisch“ keine leere Phrase ist: Derjenige, der die Entwickler führt, kann es sich einfach nicht leisten, vollständig von der Arbeit mit Technologien abzuweichen, sodass nicht zu befürchten ist, dass Managementaktivitäten sie ersetzen werden.

Kommen wir nun zur zweiten Quelle der Veränderung - der Arbeit mit Menschen. In einer Führungsposition muss ein Programmierer nicht nur mit Teammitgliedern auskommen, sondern sie grob gesagt als Ressource nutzen - identifizieren, wer zu was fähig ist, und diese Fähigkeiten dorthin lenken, wo sie am dringendsten benötigt werden. Die Aufgabe besteht also aus zwei Teilen: Sie müssen in der Lage sein, Menschen zu verstehen und mit ihnen zu kommunizieren.

Um dem Leser beim ersten Absatz zu helfen, bietet Rainwater eine Klassifizierung der „Rassen“ von IT-Katzen an, die er auf der Grundlage seiner eigenen Erfahrungen und Beobachtungen erstellt hat. Seine Rassenliste fasst regelmäßig vorkommende Entwicklertypen mit lebendigen Unterscheidungsmerkmalen, Stärken und Schwächen zusammen. Wie jede andere sollte diese Klassifizierung nicht als absoluter Standard angesehen werden - in freier Wildbahn mischen und kreuzen sich Typen häufig und sind immer weniger ausgeprägt. Dies ist jedoch ein nützlicher Ausgangspunkt für die Analyse der intellektuellen und persönlichen Eigenschaften ihrer Programmierer.

Der Autor unterteilt die Rassen in drei Gruppen: häufig (am häufigsten gefangen), selten (gelegentlich gefangen) und Mischlinge (in ihrer ursprünglichen Form haben sie einen geringeren Wert als die Gesamtmasse).

Gemeinsame Rassen

Architekt

Favorit der meisten Manager. Es konzentriert sich auf die allgemeine Struktur des Codes, geht von der Analyse und abstrakten Konstruktionen bis zur Implementierung spezifischer Lösungen für sie im Code. Stärke - es bringt gute Ideen hervor, manchmal kann es ein Projekt alleine führen, vom Entwurf bis zur endgültigen Form (obwohl einige Personen das Interesse verlieren, nachdem die allgemeine Struktur skizziert wurde, und die „handwerkliche“ Arbeit an Entwickler auf niedrigerer Ebene weitergeben). Schwäche - oft entsteht ein verwirrender, undurchsichtiger Code mit seltsamen Designs, der nur dem Eigentümer gehorcht und es sehr schwierig ist, externen Support zu leisten.

Konstruktivist

Er freut sich aufrichtig über den Programmierprozess selbst und strebt ein gutes Ergebnis an. Strategische Planung ist normalerweise gleichgültig, der Code ist ahnungslos geschrieben und denkt nicht zu viel über die allgemeine Logik nach. Auf kurze Distanz schadet dies nicht viel, und Sie können sich auf die Qualität der Arbeit des Konstruktivisten verlassen. Wenn das Projekt wächst, wirkt sich der Mangel an interner Logik normalerweise aus und es werden „Patch“ -Entscheidungen getroffen - wir erinnern uns, dass der Konstruktivist sich sehr auf das Ergebnis konzentriert. Funktioniert hervorragend in Verbindung mit einem Architekten. Dokumente widerstrebend ("alles ist klar"), aber mit gebührender Beharrlichkeit des Kopfes - ganz solide.

Der Künstler

Ich kannte auch die Freude am Schreiben von Code, aber sein Element ist die Suche nach unerwarteten, eleganten Lösungen für die Implementierung der gegebenen Anforderungen. Mit Logik und Organisation gibt es in der Regel keine Probleme. Der Hauptnachteil ist eine übermäßige Liebe zur Kunst und zum Experimentieren, die dazu anregt, einfache Aufgaben zu verlängern und Termine zu stören. Es hat einige Ähnlichkeiten sowohl mit dem Architekten als auch mit dem Konstruktivisten, zeichnet sich jedoch normalerweise durch seinen hellen individuellen Programmierstil aus.

Ingenieur

Betrachtet die Softwareentwicklung als virtuelles Analogon der Hardware-Baugruppe mit allen sich daraus ergebenden Konsequenzen. Er passt sich sehr gerne aneinander an, setzt unterschiedliche Module zu einer komplexen Struktur zusammen, damit alles funktioniert, und findet im konstruierten System einen Platz für Lösungen von Dritten. Fähigkeiten sind sicherlich nützlich, aber es gibt eine Möglichkeit, den Ingenieur mitreißen zu lassen. Komplexität kann für ihn zum Selbstzweck werden. Übermäßige Komplexität und mangelnde Produktflexibilität sind zwei Schwachstellen dieser Rasse.

Wissenschaftler

Im Gegensatz zu Künstlern betrachtet er das Programmieren als exakte Wissenschaft - er versucht, in allem Grundprinzipien zu folgen und den „Knebel“ zu vermeiden. Sehr pedantisch, bemüht sich, den Code zur Perfektion zu bringen und unter allen Bedingungen einen korrekten Betrieb zu erreichen, oft zum Nachteil praktischer Überlegungen. Wie ein Ingenieur neigt er dazu, alles unnötig zu komplizieren. Aber wenn es um wirklich komplexe Aufgaben geht, die Sorgfalt und Wissen erfordern, hat er keinen Preis.

Lihach

Es geht vor allem um Geschwindigkeit, einschließlich der Codequalität. Vernachlässigt Kleinigkeiten wie Kommentieren, korrektes Design, Befolgen anerkannter Vorschriften. Auf den ersten Blick liefert es ein gutes, recht funktionierendes Ergebnis, aber eingehende Tests zeigen viele Probleme auf. Leider wird diese Rasse von den Führern selbst gepflegt: Scorchers werden am häufigsten von jungen Programmierern erhalten, denen falsche Prioritäten eingeflößt wurden und die Angst haben, die Erwartungen nicht zu erfüllen.

Seltene Rassen

Der Assistent

In der modernen Terminologie wird ein Zauberer normalerweise als Rockstar bezeichnet. Übernimmt die schwierigsten Aufgaben und verwaltet, findet revolutionäre Wege zur Lösung von Problemen, erledigt alles pünktlich und effizient. Selbst bei der Pflege seines Codes treten in der Regel keine besonderen Schwierigkeiten auf. Im Allgemeinen scheint alles wunderbar zu sein, aber der technische Leiter muss seine Augen in zweierlei Hinsicht offen halten. Erstens sollte man keine übermäßige Abhängigkeit vom Zauberer zulassen - das gesamte Team, einschließlich des Leiters, riskiert, sich in einen Tanz für einen Mitarbeiter zu verwandeln. Zweitens müssen Sie darauf vorbereitet sein, dass der Zauberer Sie eines Tages trotzdem enttäuschen wird - niemand kann konsequent Wunder wirken. Eine solche Gelegenheit sollte ruhig genutzt werden und einen Backup-Plan haben.

Minimalistisch

Er schreibt überraschend funktionalen Code in sehr bescheidenen Mengen. Alles sieht harmonisch aus, klar gebaut und gibt seine Ernennung eindeutig bekannt. Diese Rasse ist sehr launisch bei der Auswahl von Aufgaben und Projekten; Der Minimalist wird mehr als andere um das Recht kämpfen, den Anwendungsbereich seiner Fähigkeiten festzulegen. Schwachpunkt - Eskorte. Er kämpft mit aller Kraft darum, Änderungen an seinem Code vorzunehmen (ganz zu schweigen von denen anderer) - er ist einfach nicht daran interessiert, mit den Details herumzuspielen, wenn die Hauptsache erledigt ist.

Analog

Es unterscheidet sich im spezifischen Denken, gleicht seine Schwierigkeiten mit Abstraktionen mit Liebe zu Analogien aus. Bei Besprechungen ist es schwierig, seinen Gedankengang zu verstehen, aber er versteht den Punkt schnell. In der Regel schreiben sie guten, einfach zu unterstützenden Code, aber in einigen Fällen kann ein Missverständnis einer Abstraktion diese verlangsamen. Es kommt auch vor, dass Analogien scheitern, besonders wenn die Analogistin eine ihrer Geliebten aus all dem heraushebt, was sie versucht, an allem zu ziehen. Sie können die Fehler des Analogisten ausgleichen, indem Sie ihn mit dem Architekten zusammenbringen - sie töten sich entweder gegenseitig oder schaffen etwas Außergewöhnliches.

Stuntman

Er liebt spektakuläre Tricks und ist ständig auf der Suche nach technologischen Innovationen, die sie liefern. Tatsächlich gibt es keine wirkliche Rückkehr zu diesem Hobby: Der Stuntman kann nicht pragmatisch denken, der tatsächliche Wert dieser oder jener Technologie für das Endprodukt und den Benutzer bleibt für ihn verborgen. Dieser Mitarbeiter muss seine Begeisterung ständig überwachen und auf die vorrangigen Aufgaben umleiten.

Köter

Regenwasser unterscheidet Mischlinge in eine separate Kategorie als Katzen mit einigen offensichtlichen Fehlern, ein Vorteil gegenüber Schwächen im Verhältnis zu Stärken. Aber er ruft nicht an, um sie loszuwerden, ohne hinzusehen. Viele der Mischlinge sind für das Training sehr zugänglich und können nach und nach in anderen Rassen umgeschult werden. Nachfolgend finden Sie Prognosen und Empfehlungen für verschiedene Typen.

Slobber

Der Hauptanbieter von schlampigem, schlampigem Code. Springt oft von Stil zu Stil. Wie ein Scorcher opfert er das Design und die Einhaltung der vom Team getroffenen Vereinbarungen, aber im Gegensatz zum Scorcher kann er nicht einmal durch die hohe Arbeitsgeschwindigkeit gerechtfertigt werden. Es ist sein Code, der manchmal von Grund auf neu geschrieben werden muss - so anstrengend und ressourcenintensiv, um ihn zu verstehen.

Schlamperei ist akut und chronisch. Wenn ein Mitarbeiter plötzlich angegriffen wird, kann dies an persönlichen Problemen liegen. Wenn dies für ihn eine übliche Bedingung ist, lohnt es sich zu überlegen, ob es sinnvoll ist, Zeit für die Umschulung aufzuwenden. Das Hauptkriterium hierbei ist der Wunsch und die Bereitschaft des Slowenen, Anstrengungen zu unternehmen. Der Slowene, der im Allgemeinen Spaß an seiner Arbeit hat, kann mit der gebührenden Aufmerksamkeit des Leiters oder Mentors rehabilitiert werden und effektivere Arbeitsmethoden erlernen.

Bremse

Lange Zeit kann er die Aufgabe nicht übernehmen, weiß nicht, wo er anfangen soll, jagt die Spezifikationen in der verzweifelten Hoffnung, dass sie Klarheit schaffen. Da es nicht schwer zu erraten ist, beruht die Unentschlossenheit der Bremse auf Selbstzweifeln. Hier muss gehandelt werden, basierend darauf, woher diese Unsicherheit stammt. Wenn ein Entwickler in der Vergangenheit kläglich gescheitert ist und jetzt panische Angst vor Fehlern hat, lassen Sie ihn die Möglichkeit, sich auch bei kleinen und unkomplizierten Aufgaben zu beweisen, damit diese Angst allmählich verschwindet. Wenn es sich um Unerfahrenheit handelt, wird sich mit der Zeit und der bekannten Unterstützung des Teams wahrscheinlich alles von selbst normalisieren. Wenn eine solche Unentschlossenheit nur ein Charakterzug ist, ist es am einfachsten, dem armen Kerl ein Modell zu geben, das ihm hilft, einen Stil zu wählen und an die Arbeit zu gehen.

Liebhaber

Dem Liebhaber fehlt das Wissen, aber normalerweise gibt es mehr als genug Motivation. Diese Art von Mischlingen bricht höchstwahrscheinlich in gute Entwickler ein. Ihre Fortschritte müssen jedoch genau überwacht werden - um Fähigkeiten zu bewerten und Erfolge aufzuzeichnen, die Anlass geben, sie an verantwortungsvollere Aufgaben zu senden. Man sollte die Erwartungen nicht zu übertreiben: Viele sind erschöpft, wenn sie mit Schwierigkeiten oder einer unvermeidlichen Routine in der Arbeit eines Programmierers konfrontiert sind. Im Allgemeinen haben Amateure ihre Vorteile - vor allem das berüchtigte, frische, unverfrorene Aussehen, obwohl es anstrengend sein kann, zu warten, bis sie auf alle Rechen treten und gemeinsame Wahrheiten verstehen.

Profan

Es scheint einfach langweilig. Normalerweise erbt der neue Anführer diese vom alten, die Geschichte ihrer Platzierung im Team bleibt ein Rätsel. Etwas für solche Menschen zu tun ist schwierig - Entwicklung erfordert ständige Selbstverbesserung, die sie einfach nicht ziehen werden. Wenn sich ein Laie seines Niveaus bewusst ist und sich nicht durch unzureichende Ambitionen auszeichnet, können Sie versuchen, ihn an die Testabteilung zu binden - manchmal hindern niedrige Fähigkeiten die Menschen nicht daran, Fehler richtig zu finden. Diejenigen, die sich ihrer Nähe nicht einmal bewusst sind, sollten sich besser nicht damit auseinandersetzen.

Vielseitig

Eine nukleare Mischung aus einem Ingenieur, einem schlampigen und nicht allzu talentierten Künstler. Der Code, den er schreibt, ist eine unverdauliche Vinaigrette aus verschiedenen Stilen und Modulen. Im Gegensatz zu schlampigen Produkten ist dies ein Code mit einem Anspruch auf Talent - anscheinend scheint er sogar etwas zu enthalten, bis Sie versuchen, ihn auszuführen. Die Hauptfrage der Person, die den eklektischen Code liest: "Was meinte er?" Um die Situation zu korrigieren, müssen Sie zunächst verstehen, ob diese Verwirrung wirklich das Ergebnis einer Suche ist oder ob vor Ihnen ein Versuch unternommen wird, über die Gleise zu sabbern. Der gutartige Eklektizismus wird stark von systematischen Codeüberprüfungen profitiert.

Schließlich gibt es noch eine andere Rasse, die sich in jeder Hinsicht von den anderen unterscheidet - dies ist ein Cowboy oder ein einsamer Wolf. Katzengewohnheiten erreichen ihn in höchstem Maße. In seinem Handwerk ist ein Cowboy in der Regel sehr gut (sonst kann er einfach nicht an Ort und Stelle bleiben), in der Teamarbeit - ist absolut hoffnungslos. Er zeichnet sich durch seine Entschlossenheit aus, nur nach seinen eigenen Regeln zu spielen: Projekte anzunehmen, die ihn interessieren, und keine anderen, die Mittel einzusetzen, die er will, ausschließlich mit seinen Plänen zu rechnen und so weiter. Bei Cowboys gibt es nur einen Weg: ein für alle Mal zu verstehen, dass sie nicht Teil des Teams werden, und zu entscheiden, ob Sie sie genug schätzen, um ihre besonderen Gewohnheiten zu ertragen. Im Allgemeinen sind Cowboys in zwei Fällen unverzichtbar: in kritischen, scheinbar hoffnungslosen Situationen und in isolierten Projekten, die von externen Experten begleitet werden.

Wir haben also die Rassen aufgelistet, denen der Autor am häufigsten begegnet ist. Zu dieser Klassifizierung sollten jedoch einige Anmerkungen gemacht werden:

• Der Anführer sollte sich nicht als Ausnahme von der Regel betrachten: Er hat Programmiererfahrung, was bedeutet, dass er selbst zu einer der Rassen gehört. Dies ist ein wichtiger Umstand - sein individueller Ansatz beim Schreiben von Code wirkt sich auf die Kultur des gesamten Teams aus. Zum Beispiel kann in einer Gruppe minimalistischer Führer die Dokumentation verrutschen, weil er ihm selbst in seiner eigenen Arbeit nie die richtige Aufmerksamkeit geschenkt hat.
• Wir wiederholen noch einmal: Typen sind nicht immer rein und unveränderlich, Menschen erweisen sich oft als facettenreicher als theoretische Konstruktionen. Es ist am einfachsten zu beurteilen, wer zu welcher Rasse gehört, wenn einzelne Merkmale am deutlichsten sichtbar sind - mit neuen Anfängen und wenn sich die Frist nähert.
• Wenn Sie ein Team von Grund auf neu bilden müssen, denken Sie daran, dass das erfolgreichste Ensemble Architekten (strategisches Denken), Konstruktivisten (Ausarbeitung von Details) und Künstler (kreative Serie) sind. Aber höchstwahrscheinlich haben Sie bereits ein besetztes Team, und das ist völlig normal - Sie können in jedem Team zusammenarbeiten.
• Die drei Hauptqualitäten, die für die Arbeit mit den meisten Rassen erforderlich sind, sind Unterscheidungsvermögen, Geduld und die Fähigkeit, Mentor zu werden.

Bei all dem Spaß an dieser Liste ist es möglicherweise nicht sofort klar, wie Sie im Arbeitsalltag davon profitieren können. Der Autor bietet einige Beispiele mit einer Analyse spezifischer Situationen, die häufig bei bestimmten Rassen auftreten.

Beispiel Nr. 1

Situation: Sie haben einen umfangreichen Code, der auf die aktuellen Anforderungen des Unternehmens aktualisiert werden muss, und einen minimalistischen Entwickler, der ihn zum ersten Mal in seinem Leben sieht. Der Entwickler behauptet, dass der Code von Grund auf neu geschrieben werden muss - alles ist zu kompliziert, aber Sie können es nicht tun: Es wurden bereits viele Ressourcen für das Produkt aufgewendet. Was zu tun ist?

Lösung: Ändern Sie die Aufgabe leicht. Ein Minimalist liebt Klarheit, hat eine Schwäche für die Arbeit mit Architektur - bestechen Sie ihn mit mehreren nicht zu teuren und offensichtlich fehlerhaften Objekten oder Funktionen und geben Sie ihm die Freiheit, sie in Zukunft nach eigenem Ermessen zu rekonstruieren. Bitten Sie darum, den Code zu studieren und zu dokumentieren, auch zu diesem Zweck. Infolgedessen wird der Minimalist gezwungen sein, das zu tun, was er bestritten hat - den wundersamen Code herauszufinden, um zu einer interessanteren Lektion überzugehen.

Beispiel Nr. 2

Situation: Sie sind mit dem Architekten nicht einverstanden über die von ihm implementierte Lösung. Es scheint Ihnen, dass einige Dinge nicht optimal erledigt werden, er sieht keine Probleme.

: – , . , , . , , – -. , , . , , – , , .

. , , , , .