Das Buch „Wie man Intellektuelle verwaltet. Ich, Nerds und Geeks“

Speziell für Projektmanager (und diejenigen, die davon träumen, Chefs zu werden).

Unmengen von Code zu schreiben ist schwer, aber die Verwaltung von Menschen ist noch schwieriger! Sie brauchen also nur dieses Buch, um zu lernen, wie man beides macht.

Ist es möglich, lustige Geschichten und ernsthafte Lektionen zu kombinieren? Michael Lopp (in engen Kreisen auch als Rands bekannt) hatte Erfolg. Sie finden fiktive Geschichten über fiktive Menschen mit unglaublich lohnenden (wenn auch fiktiven) Erfahrungen. So teilt Rands seine vielfältigen, manchmal seltsamen Erfahrungen, die er im Laufe der Jahre bei der Arbeit in großen IT-Konzernen gesammelt hat: Apple, Pinterest, Palantir, Netscape, Symantec usw.

Sind Sie Projektmanager? Oder möchten Sie verstehen, was Ihr verdammter Chef den ganzen Tag macht? Rands zeigt Ihnen, wie Sie in der giftigen Welt der aufgeblasenen Truthähne überleben und im allgemeinen Wahnsinn dysfunktionaler, extravaganter Menschen gedeihen. In dieser seltsamen Gemeinschaft verrückter Hirngespinste gibt es noch seltsamere Kreaturen – Manager, die durch ein mystisches Organisationsritual die Macht über die Pläne, Gedanken und Bankkonten vieler Menschen erlangt haben.

Dieses Buch ist anders als jedes Management- oder Führungsmanuskript. Michael Lopp verheimlicht nichts, er erzählt es einfach so wie es ist (vielleicht sollten nicht alle Geschichten öffentlich gemacht werden :P). Aber nur so wirst du verstehen, wie du mit so einem Chef überlebst, wie du mit Geeks und Nerds umgehst und wie du „dieses verdammte Projekt“ zu einem glücklichen Ende bringst!

Auszug. Ingenieursmentalität

Gedanken zu: Sollten Sie weiterhin Code schreiben?

Rands‘ Buch über Regeln für Manager enthält eine sehr kurze Liste moderner Manager-„Must-Dos“. Die Lakonizität dieser Liste ergibt sich aus der Tatsache, dass der Begriff „müssen“ eine Art Absolutheit ist, und wenn es um Menschen geht, gibt es nur sehr wenige absolute Begriffe. Eine erfolgreiche Managementmethode für einen Mitarbeiter wird für einen anderen eine echte Katastrophe sein. Dieser Gedanke ist der erste Punkt auf der „Must-Do“-Liste des Managers:

Bleiben Sie flexibel!

Zu denken, dass man bereits alles weiß, ist eine sehr schlechte Idee. In einer Situation, in der die einzige konstante Tatsache darin besteht, dass sich die Welt ständig verändert, wird Flexibilität zur einzig richtigen Position.

Paradoxerweise ist der zweite Punkt auf der Liste überraschend unflexibel. Dieser Punkt ist jedoch mein persönlicher Favorit, weil ich glaube, dass er dazu beiträgt, die Grundlage für die Weiterentwicklung von Führungskräften zu schaffen. Dieser Absatz lautet:

Hören Sie auf, Code zu schreiben!

Wenn Sie Manager werden wollen, müssen Sie theoretisch lernen, denen zu vertrauen, die für Sie arbeiten, und ihnen die Programmierung vollständig zu überlassen. Dieser Rat ist in der Regel schwer zu verdauen, insbesondere für frischgebackene Manager. Wahrscheinlich ist einer der Gründe, warum sie Manager geworden sind, ihre Produktivität in der Entwicklung, und wenn etwas schief geht, ist ihre erste Reaktion, auf die Fähigkeiten zurückzugreifen, auf die sie vollstes Vertrauen haben, nämlich ihre Fähigkeit, Code zu schreiben.

Wenn ich sehe, dass ein frischgebackener Manager im Schreiben von Code „versinkt“, sage ich ihm: „Wir wissen, dass man Code schreiben kann.“ Die Frage ist: Können Sie führen? Sie sind nicht mehr nur für sich selbst verantwortlich, sondern für das gesamte Team; und ich möchte sicherstellen, dass Sie Ihr Team dazu bringen können, Probleme selbst zu lösen, ohne dass Sie den Code selbst schreiben müssen. Ihre Aufgabe ist es, herauszufinden, wie Sie sich skalieren können. Ich möchte nicht, dass du nur einer bist, ich möchte, dass es viele wie dich gibt.“

Guter Rat, oder? Skala. Management. Verantwortung. Solche gebräuchlichen Schlagworte. Schade, dass der Rat falsch ist.

Falsch?

Ja. Der Rat ist falsch! Nicht ganz falsch, aber so falsch, dass ich einige ehemalige Kollegen anrufen und mich entschuldigen musste: „Erinnern Sie sich an meine Lieblingsaussage darüber, wie Sie mit dem Schreiben von Code aufhören sollten? Es ist falsch! Ja... Beginnen Sie erneut mit der Programmierung. Beginnen Sie mit Python und Ruby. Ja, es ist mein Ernst! Ihre Karriere hängt davon ab!“

Als ich meine Karriere als Softwareentwickler bei Borland begann, arbeitete ich im Paradox Windows-Team, einem riesigen Team. Es gab allein 13 Anwendungsentwickler. Wenn man Leute aus anderen Teams hinzufügt, die ebenfalls ständig an Schlüsseltechnologien für dieses Projekt gearbeitet haben, wie etwa der zentralen Datenbank-Engine und den zentralen Anwendungsdiensten, sind 50 Ingenieure direkt an der Entwicklung dieses Produkts beteiligt.

Kein anderes Team, für das ich jemals gearbeitet habe, kommt auch nur annähernd an diese Größe heran. Tatsächlich nimmt die Anzahl der Personen in dem Team, in dem ich arbeite, mit jedem Jahr allmählich ab. Was ist los? Werden wir Entwickler gemeinsam immer schlauer? Nein, wir teilen nur die Last.

Was haben Entwickler in den letzten 20 Jahren gemacht? Während dieser Zeit haben wir eine Menge Code geschrieben. Meer aus Code! Wir haben so viel Code geschrieben, dass wir entschieden haben, dass es eine gute Idee wäre, alles zu vereinfachen und Open Source zu verwenden.

Glücklicherweise ist dieser Vorgang dank des Internets mittlerweile so einfach wie möglich geworden. Wenn Sie Softwareentwickler sind, können Sie es jetzt ausprobieren! Suchen Sie bei Google oder Github nach Ihrem Namen und Sie werden Code sehen, den Sie schon lange vergessen haben, den aber jeder finden kann. Beängstigend, oder? Wussten Sie nicht, dass Code ewig lebt? Ja, er lebt ewig.

Der Code lebt ewig. Und guter Code lebt nicht nur ewig, er wächst auch, weil diejenigen, die ihn wertschätzen, ständig dafür sorgen, dass er aktuell bleibt. Dieser Haufen an qualitativ hochwertigem, gut gepflegtem Code trägt dazu bei, die durchschnittliche Größe eines Entwicklungsteams zu reduzieren, da wir uns auf vorhandenen Code konzentrieren können, anstatt neuen Code zu schreiben, und die Arbeit mit weniger Leuten und in kürzerer Zeit erledigen können.

Diese Argumentation klingt deprimierend, aber die Idee ist, dass wir alle nur ein Haufen Integrationsautomaten sind, die Klebeband verwenden, um verschiedene Teile bestehender Dinge miteinander zu verbinden, um eine etwas andere Version derselben Sache zu schaffen. Dies ist eine klassische Denkweise unter Führungskräften, die Outsourcing lieben. „Jeder, der sich mit Google auskennt und etwas Klebeband hat, kann das machen! Warum zahlen wir dann viel Geld für unsere Maschinen?“

Wir zahlen diesen Managern wirklich viel Geld, aber sie denken so einen Unsinn. Noch einmal: Mein Kernpunkt ist, dass es auf unserem Planeten viele brillante und sehr hart arbeitende Entwickler gibt; Sie sind wirklich brillant und fleißig, obwohl sie keine einzige Minute an akkreditierten Universitäten verbracht haben. Ach ja, mittlerweile gibt es immer mehr davon!

Ich schlage nicht vor, dass Sie sich Sorgen um Ihren Platz machen, nur weil einige brillante Kameraden angeblich auf der Jagd nach ihm sind. Ich empfehle Ihnen, sich darüber Sorgen zu machen, denn die Entwicklung der Softwareentwicklung schreitet wahrscheinlich schneller voran als Sie. Sie arbeiten seit zehn Jahren, fünf davon als Führungskraft, und denken: „Ich weiß schon, wie Software entwickelt wird.“ Ja du weißt. Tschüss…

Hören Sie auf, Code zu schreiben, aber ...

Wenn Sie meinem ursprünglichen Rat folgen und aufhören, Code zu schreiben, beenden Sie auch freiwillig die Teilnahme am Erstellungsprozess. Aus diesem Grund nutze ich Outsourcing nicht aktiv. Automaten erschaffen nicht, sie produzieren. Gut konzipierte Prozesse sparen viel Geld, bringen aber nichts Neues in unsere Welt.

Wenn Sie ein kleines Team haben, das für wenig Geld viel leistet, dann scheint mir die Idee, mit dem Schreiben von Code aufzuhören, eine schlechte Karriereentscheidung zu sein. Selbst in Monsterunternehmen mit ihren endlosen Vorschriften, Prozessen und Richtlinien haben Sie kein Recht zu vergessen, wie man selbst Software entwickelt. Und die Softwareentwicklung verändert sich ständig. Es verändert sich gerade. Unter deinen Füßen! In genau dieser Sekunde!

Sie haben Einwände. Verstehen. Lasst uns zuhören.

„Rands, ich bin auf dem Weg zum Regiestuhl! Wenn ich weiterhin Code schreibe, wird niemand glauben, dass ich wachsen kann.“

Ich möchte Sie Folgendes fragen: Haben Sie bemerkt, dass sich die Softwareentwicklungslandschaft verändert, sogar innerhalb Ihres Unternehmens, seit Sie auf Ihrem Stuhl „Ich bin bald CEO!“ saßen? Wenn Sie mit „Ja“ antworten, stelle ich Ihnen eine weitere Frage: Wie genau ändert sich das, und was werden Sie gegen diese Änderungen unternehmen? Wenn Sie meine erste Frage mit „Nein“ beantwortet haben, müssen Sie auf einen anderen Lehrstuhl wechseln, denn (ich wette!) Der Bereich der Softwareentwicklung verändert sich genau in diesem Moment. Wie soll man jemals wachsen, wenn man langsam aber sicher vergisst, wie man Software entwickelt?

Mein Rat ist, sich nicht darauf festzulegen, unzählige Funktionen für Ihr nächstes Produkt zu implementieren. Sie müssen ständig Maßnahmen ergreifen, um den Überblick darüber zu behalten, wie Ihr Team Software erstellt. Dies können Sie sowohl als Direktor als auch als Vizepräsident tun. Etwas anderes?

„Uff, Rands! Aber jemand muss der Schiedsrichter sein! Jemand muss das große Ganze sehen. Wenn ich Code schreibe, verliere ich den Überblick.“

Sie müssen immer noch der Schiedsrichter sein, Sie müssen immer noch die Entscheidungen übertragen, und Sie müssen immer noch jeden Montagmorgen viermal mit einem Ihrer Ingenieure durch das Gebäude gehen, um sich seine wöchentliche Schimpftirade „Wir sind alle verloren“ für 30 anzuhören Protokoll. ! Aber darüber hinaus muss man eine technische Denkweise bewahren und dafür muss man kein Vollzeitprogrammierer sein.

Meine Tipps zur Aufrechterhaltung einer Ingenieursmentalität:

1. Nutzen Sie die Entwicklungsumgebung. Das bedeutet, dass Sie mit den Tools Ihres Teams vertraut sein sollten, einschließlich des Code-Build-Systems, der Versionskontrolle und der Programmiersprache. Dadurch beherrschen Sie die Sprache, die Ihr Team verwendet, wenn es über Produktentwicklung spricht. Dadurch können Sie auch weiterhin Ihren bevorzugten Texteditor verwenden, der einwandfrei funktioniert.
2. Sie müssen jederzeit in der Lage sein, auf jeder Oberfläche ein detailliertes Architekturdiagramm zu zeichnen, das Ihr Produkt beschreibt. Damit meine ich nicht die vereinfachte Version mit drei Zellen und zwei Pfeilen. Sie müssen das detaillierte Diagramm des Produkts kennen. Das Schwierigste. Nicht irgendein niedliches Diagramm, sondern ein Diagramm, das schwer zu erklären ist. Es sollte eine Karte sein, die zum vollständigen Verständnis des Produkts geeignet ist. Es ändert sich ständig und Sie sollten immer wissen, warum bestimmte Änderungen stattgefunden haben.
3. Übernehmen Sie die Umsetzung einer der Funktionen. Ich zucke buchstäblich zusammen, während ich das schreibe, weil dieser Punkt viele versteckte Gefahren birgt, aber ich bin mir wirklich nicht sicher, ob Sie Punkt 1 und Punkt 2 erreichen können, ohne sich auf die Implementierung mindestens einer Funktion festzulegen. Indem Sie eine der Funktionen selbst implementieren, sind Sie nicht nur aktiv am Entwicklungsprozess beteiligt, sondern können auch regelmäßig von der Rolle des „Managers, der für alles verantwortlich ist“ in die Rolle des „Manns, der für die Implementierung verantwortlich ist“ wechseln der Funktionen.“ Diese bescheidene und bescheidene Haltung wird Sie daran erinnern, wie wichtig kleine Entscheidungen sind.
4. Ich zittere immer noch am ganzen Körper. Es scheint, als würde mich schon jemand anschreien: „Der Manager, der die Umsetzung der Funktion übernommen hat?!“ (Und ich stimme ihm zu!) Ja, Sie sind immer noch der Manager, was bedeutet, dass es sich um eine kleine Funktion handeln sollte, okay? Ja, es gibt noch viel zu tun. Wenn Sie die Implementierung der Funktion einfach nicht übernehmen können, habe ich noch einen Rat für Sie: Beheben Sie einige Fehler. In diesem Fall werden Sie nicht die Freude am Schaffen verspüren, aber Sie werden verstehen, wie das Produkt entsteht, was bedeutet, dass Sie nie arbeitslos bleiben.
5. Schreiben Sie Unit-Tests. Ich mache das immer noch spät im Produktionszyklus, wenn die Leute verrückt werden. Betrachten Sie es als eine Gesundheitscheckliste für Ihr Produkt. Tun Sie dies oft.

Schon wieder Einspruch?

„Rands, wenn ich Code schreibe, verwirre ich mein Team. Sie werden nicht wissen, wer ich bin – ein Manager oder ein Entwickler.“

Gut.

Ja, ich sagte: „Okay!“ Ich freue mich, dass Sie glauben, Sie könnten Ihr Team verwirren, indem Sie einfach im Entwicklerteich schwimmen. Es ist ganz einfach: Die Grenzen zwischen verschiedenen Rollen in der Softwareentwicklung sind derzeit sehr fließend. Die UI-Leute machen etwas, was man allgemein als JavaScript- und CSS-Programmierung bezeichnen kann. Entwickler lernen immer mehr über User Experience Design. Menschen kommunizieren miteinander und erfahren etwas über Bugs, über den Diebstahl des Codes anderer Leute und auch über die Tatsache, dass es für einen Manager keinen guten Grund gibt, sich nicht an diesem massiven, globalen, sich gegenseitig befruchtenden Informationsbacchanalia zu beteiligen.

Möchten Sie außerdem Teil eines Teams sein, das aus leicht austauschbaren Komponenten besteht? Dadurch wird Ihr Team nicht nur flexibler, sondern jedes Teammitglied hat auch die Möglichkeit, das Produkt und das Unternehmen aus verschiedenen Perspektiven zu betrachten. Wie kann man Frank, den ruhigen Kerl, der für die Builds verantwortlich ist, mehr respektieren als nachdem man die schlichte Eleganz seiner Build-Skripte gesehen hat?

Ich möchte nicht, dass Ihr Team verwirrt und chaotisch wird. Im Gegenteil, ich möchte, dass Ihr Team effektiver kommuniziert. Ich bin davon überzeugt, dass Sie Ihrem Team näher sind, wenn Sie an der Entwicklung des Produkts und der Arbeit an Funktionen beteiligt sind. Und was noch wichtiger ist: Sie sind den ständigen Veränderungen im Softwareentwicklungsprozess in Ihrem Unternehmen näher.

Hören Sie nicht auf, sich weiterzuentwickeln

Eine Kollegin von mir bei Borland hat mich einmal verbal angegriffen, weil ich sie eine „Kodiererin“ genannt habe.

„Rands, der Programmierer ist eine hirnlose Maschine! Affe! Der Programmierer macht nichts Wichtiges, außer langweilige Zeilen nutzlosen Codes zu schreiben. Ich bin kein Programmierer, ich bin ein Softwareentwickler!“

Sie hatte Recht, sie hätte meinen ersten Rat an neue CEOs gehasst: „Hört auf, Code zu schreiben!“ Nicht, weil ich andeute, dass sie Programmierer sind, sondern vielmehr, weil ich proaktiv vorschlage, dass sie beginnen, einen der wichtigsten Teile ihres Jobs zu ignorieren: die Softwareentwicklung.

Deshalb habe ich meinen Rat aktualisiert. Wenn Sie ein guter Anführer sein wollen, können Sie aufhören, Code zu schreiben, aber ...

Sei flexibel. Denken Sie daran, was es bedeutet, Ingenieur zu sein, und hören Sie nicht auf, Software zu entwickeln.

Über den Autor

Michael Lopp ist ein erfahrener Softwareentwickler, der das Silicon Valley immer noch nicht verlassen hat. In den letzten 20 Jahren hat Michael für eine Vielzahl innovativer Unternehmen gearbeitet, darunter Apple, Netscape, Symantec, Borland, Palantir, Pinterest, und war auch an einem Startup beteiligt, das langsam in Vergessenheit geriet.

Außerhalb der Arbeit betreibt Michael unter dem Pseudonym Rands einen beliebten Blog über Technologie und Management, in dem er mit Lesern Ideen im Bereich Management diskutiert, seine Besorgnis über die ständige Notwendigkeit zum Ausdruck bringt, am Puls der Zeit zu bleiben, und erklärt, dass er trotz der … großzügige Belohnungen für die Entwicklung eines Produkts, Ihr Erfolg ist nur dank Ihres Teams möglich. Den Blog finden Sie hier www.randsinrepose.com.

Michael lebt mit seiner Familie in Redwood, Kalifornien. Er findet immer Zeit zum Mountainbiken, Hockeyspielen und Rotweintrinken, denn Gesundheit ist wichtiger als beschäftigt zu sein.

» Weitere Details zum Buch finden Sie unter Website des Verlags
» Inhaltsverzeichnis
» Auszug

Für Khabrozhiteley 20 % Rabatt mit Gutschein - Leute führen

Nach der Bezahlung der Papierversion des Buchs wird eine elektronische Version des Buchs per E-Mail verschickt.

PS: 7 % des Buchpreises fließen in die Übersetzung neuer Computerbücher, eine Bücherliste wird der Druckerei übergeben hier.

Source: habr.com