Das Buch „Wie man mit Intellektuellen umgeht. Ich, Nerds und Geeks "

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

Das Schreiben von Tonnen von Code ist schwierig, und das Verwalten von Personen ist noch schwieriger! Sie brauchen also nur dieses Buch, um zu lernen, wie man beides macht.

Ist es möglich, coole Geschichten und ernsthafte Lektionen zu kombinieren? Michael Lopp (in engen Kreisen auch als Randes bekannt) war erfolgreich. Es erwarten Sie fiktive Geschichten über fiktive Menschen mit unglaublich nützlichen (wenn auch fiktiven) Erfahrungen. Auf diese Weise teilt Randy seine vielfältigen, manchmal seltsamen Erfahrungen, die er im Laufe der jahrelangen Arbeit in großen IT-Unternehmen gesammelt hat: Apple, Pinterest, Palantir, Netscape, Symantec usw.

Sind Sie ein Projektmanager? Oder wollen Sie verstehen, was Ihr verdammter Chef den ganzen Tag macht? Rand wird Ihnen beibringen, wie Sie in der giftigen Welt der aufgeblasenen Truthähne überleben und im allgemeinen Wahnsinn von Menschen mit Funktionsstörungen gedeihen können. In dieser seltsamen Gemeinschaft manischer Weisheiten 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 nicht wie ein Manuskript über Management oder Führung. Michael Lopp versteckt nichts, er erzählt einfach alles so wie es ist (vielleicht sollten nicht alle Geschichten veröffentlicht werden: R). Aber nur so werden Sie verstehen, wie Sie mit einem solchen Chef überleben können, wie man mit Geeks und Nerds umgeht und wie man „dieses verdammte Projekt“ zum Happy End bringt!

Auszug. Ingenieurmentalität

Gedanken zum Thema: Müssen Sie weiterhin Code schreiben?

In Rands Buch über Führungsregeln gibt es eine sehr kurze Liste moderner Must-Do-Manager. Der Lakonismus dieser Liste beruht auf der Tatsache, dass das Konzept des „Muss“ eine Art Absolut ist, und wenn es um Menschen geht, gibt es nur sehr wenige absolute Konzepte. Eine erfolgreiche Methode zur Verwaltung eines Mitarbeiters ist für einen anderen eine echte Katastrophe. Diese Idee ist der erste Punkt auf der "Must-Do" -Liste des Managements:

Bleiben Sie flexibel!

Zu bedenken, dass Sie bereits alles wissen, ist eine sehr schlechte Idee. In einer Situation, in der die einzige unveränderliche Tatsache die Tatsache ist, dass in der Welt ständige Veränderungen stattfinden, wird Flexibilität zur einzig wahren Position.

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

Hör auf, Code zu schreiben!

Wenn Sie eine Führungskraft sein möchten, sollten Sie theoretisch lernen, denen zu vertrauen, die für Sie arbeiten, und ihnen das Schreiben von Code vollständig zu übergeben. Dieser Rat ist normalerweise schwer zu „verdauen“, insbesondere für neue Führungskräfte. Wahrscheinlich ist einer der Gründe, warum sie zu Führungskräften wurden, ihre Produktivität in der Entwicklung, und wenn die Dinge schief gehen, besteht ihre erste Reaktion darin, auf Fähigkeiten zurückzugreifen, bei denen sie absolut sicher sind, dh auf ihre Fähigkeit, Code zu schreiben.

Wenn ich sehe, dass ein neu geprägter Anführer vor dem Schreiben von Code "fällt", sage ich ihm: "Wir wissen, dass Sie Code schreiben können. Die Frage ist anders: Weißt du, wie man führt? Sie sind nicht mehr allein für sich selbst verantwortlich, sondern für das gesamte Team. und ich möchte sichergehen, dass Sie Ihr Team dazu bringen können, Probleme selbst zu lösen, ohne selbst Code schreiben zu müssen. Ihre Aufgabe ist es, herauszufinden, wie Sie sich skalieren können. Ich möchte, dass du nicht der Einzige bist, ich möchte so viele Menschen wie dich. “

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

Falsch?

Ja. Der Rat ist falsch! Nicht, dass es völlig falsch wäre, aber falsch genug, dass ich einige ehemalige Kollegen anrufen und mich entschuldigen musste: "Erinnern Sie sich an meine Lieblingsaussage, dass Sie aufhören sollten, Code zu schreiben? Es ist falsch! Ja ... wieder programmieren. Beginnen Sie mit Python und Ruby. Ja, ich meine es ernst! Deine Karriere hängt davon ab! “

Als ich meine Karriere als Softwareentwickler bei Borland begann, arbeitete ich im Paradox-Team für Windows und es war ein riesiges Team. Nur ein Anwendungsentwickler war 13 Personen. Wenn wir Mitarbeiter aus anderen Teams hinzufügen, die ebenfalls ständig an Schlüsseltechnologien für dieses Projekt gearbeitet haben, wie z. B. die Hauptdatenbank-Engine und die Hauptanwendungsdienste, werden 50 Ingenieure direkt in die Entwicklung dieses Produkts einbezogen.

Kein anderes Team, für das ich jemals gearbeitet habe, hat annähernd ähnliche Größen erreicht. 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 verteilen nur die Last.

Was haben Entwickler in den letzten 20 Jahren getan? Während dieser Zeit haben wir eine Menge Mistcode geschrieben. Meer von Code! Wir haben so viel Code geschrieben, dass wir uns entschieden haben: Es wäre schön, alles zu vereinfachen und auf Open Source Code umzusteigen.

Glücklicherweise ist dieser Prozess dank des Internets jetzt so einfach wie möglich geworden. Wenn Sie ein Softwareentwickler sind, können Sie es jetzt ausprobieren! Suchen Sie Ihren Namen bei Google oder Github und Sie werden einen Code sehen, den Sie längst vergessen haben, den aber jeder finden kann, der dies wünscht. Beängstigend, oder? Sie wussten nicht, dass der Code für immer lebt? Ja, er lebt für immer.

Der Code lebt für immer. Ein guter Code lebt nicht nur für immer, er wächst auch, denn diejenigen, die ihn schätzen, achten ständig darauf, dass er seine Frische nicht verliert. Diese Menge an qualitativ hochwertigem und gut gepflegtem Code trägt dazu bei, die durchschnittliche Größe eines Engineering-Teams zu reduzieren, da wir uns nicht auf das Schreiben von neuem Code, sondern auf vorhandenen Code konzentrieren und mit weniger beteiligten Personen und in kürzerer Zeit arbeiten können.

Diese Argumentation klingt deprimierend, aber die Idee ist, dass wir alle nur eine Gruppe von Integrationsmaschinen sind, die Klebeband verwenden, um verschiedene Teile bestehender Dinge miteinander zu verbinden und eine etwas andere Version derselben Sache zu erstellen. Dies ist ein klassischer Gedankengang für Top-Management, das Outsourcing liebt. „Dies kann jeder tun, der weiß, wie man Google benutzt und der Klebeband hat! Warum zahlen wir dann eine Menge Geld an unsere Automaten? “

Wir zahlen diesen Führungskräften wirklich viel Geld, und sie denken solchen Unsinn. Noch einmal: Meine Schlüsselidee ist, dass es auf unserem Planeten viele brillante und sehr fleißige Entwickler gibt. Sie sind wirklich brillant und eifrig, obwohl sie keine Minute an akkreditierten Universitäten gesessen haben. Oh ja, jetzt gibt es immer mehr davon!

Ich schlage nicht vor, dass Sie anfangen, sich Sorgen um Ihren Platz zu machen, nur weil einige brillante Kameraden ihn angeblich verfolgen. Ich schlage vor, Sie machen sich Sorgen um ihn, weil die Entwicklung der Softwareentwicklung möglicherweise schneller voranschreitet als Sie. Sie arbeiten seit zehn Jahren, davon fünf Jahre als Führungskraft, und Sie denken: „Ich weiß bereits, wie Software entwickelt wird.“ Ja du weißt schon Tschüss…

Hör auf, Code zu schreiben, aber ...

Wenn Sie meinen ersten Ratschlägen folgen und aufhören, Code zu schreiben, werden Sie gleichzeitig freiwillig aufhören, am Erstellungsprozess teilzunehmen. Aus diesem Grund bin ich im Outsourcing nicht besonders aktiv. Maschinen schaffen nicht, sie produzieren. Gut konzipierte Prozesse können viel Geld sparen, bringen aber nichts Neues in unsere Welt.

Wenn Sie ein kleines Team haben und es viel für wenig Geld tut, dann scheint die Idee, das Schreiben von Code zu beenden, eine schlechte Karriereentscheidung zu sein. Selbst in Monsterfirmen mit ihren endlosen Vorschriften, Prozessen und Richtlinien haben Sie kein Recht zu vergessen, wie Sie Software selbst entwickeln. Und die Softwareentwicklung ändert sich ständig. Sie verändert sich gerade. Unter deinen Füßen! Diese Sekunde!

Sie haben einen Einwand. Ich verstehe Lass uns zuhören.

"Randy, 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: Seit Sie Ihren Platz eingenommen haben: „Ich werde bald Direktor!“, Haben Sie bemerkt, dass sich der Bereich der Softwareentwicklung auch in Ihrem Unternehmen verändert? Wenn Sie mit Ja antworten, werde ich Ihnen eine weitere Frage stellen: Wie genau ändert sich dies und was werden Sie im Zusammenhang mit diesen Änderungen tun? Wenn Sie meine erste Frage mit „Nein“ beantwortet haben, müssen Sie zu einem anderen Stuhl wechseln, denn (ich gebe einen Zahn!) Der Umfang der Softwareentwicklung ändert sich in dieser Sekunde. Wie werden Sie überhaupt wachsen, wenn Sie langsam aber sicher vergessen, wie man Software entwickelt?

Mein Rat ist, sich nicht mit unzähligen Funktionen für Ihr nächstes Produkt anzuvertrauen. Sie müssen ständig Maßnahmen ergreifen, um auf dem neuesten Stand zu bleiben, wie Ihr Team Software erstellt. Sie können dies sowohl als Direktor als auch als Vizepräsident tun. Noch etwas?

„Äh, Randy! Aber jemand muss ein Schiedsrichter sein! Jemand sollte das große Ganze sehen. Wenn ich Code schreibe, verliere ich die Aussicht aus den Augen. "

Sie müssen immer noch der Schiedsrichter bleiben, Sie müssen immer noch die Entscheidungen ausstrahlen und Sie müssen immer noch viermal jeden Montagmorgen mit einem Ihrer Ingenieure durch das Gebäude gehen, um 30 Minuten lang seine wöchentliche Tirade zu hören: „Wir sind alle zum Scheitern verurteilt ! " Abgesehen davon müssen Sie die technische Denkweise in sich behalten, und dafür müssen Sie kein Vollzeitprogrammierer sein.

Mein Rat zur Aufrechterhaltung einer technischen Mentalität:

1. Verwenden Sie die Entwicklungsumgebung. Dies bedeutet, dass Sie mit den Tools Ihres Teams vertraut sein sollten, einschließlich eines Codeerstellungssystems, einer Versionskontrolle und einer Programmiersprache. Infolgedessen sprechen Sie fließend die Sprache, die Ihr Team verwendet, wenn es um Produktentwicklung geht. Außerdem können Sie weiterhin Ihren bevorzugten Texteditor verwenden, der hervorragend funktioniert.
2. Sie müssen in der Lage sein, ein detailliertes Architekturdiagramm zu zeichnen, das Ihr Produkt auf jeder Oberfläche und zu jeder Zeit beschreibt. Jetzt meine ich keine vereinfachte Version mit drei Zellen und zwei Pfeilen. Sie müssen das detaillierte Produktdiagramm kennen. Das schwierigste. Nicht irgendein hübsches Schema, sondern ein Schema, das schwer zu erklären ist. Dies sollte eine Karte sein, die für ein umfassendes Verständnis des Produkts geeignet ist. Es ändert sich ständig, und Sie sollten immer wissen, warum diese oder andere Änderungen aufgetreten sind.
3. Übernehmen Sie die Implementierung einer der Funktionen. Ich zittere buchstäblich, wenn ich das schreibe, weil dieser Punkt mit vielen versteckten Gefahren behaftet ist, aber ich bin mir wirklich nicht sicher, ob Sie Absatz 1 und Absatz 2 erfüllen können, ohne mindestens eine Funktion zu übernehmen . Dank der unabhängigen Implementierung einer der Funktionen können Sie nicht nur aktiv am Entwicklungsprozess teilnehmen, sondern auch regelmäßig von der Rolle des für alles verantwortlichen Managers zur Rolle der für die Implementierung einer der Funktionen verantwortlichen Person wechseln. Diese bescheidene und unprätentiöse Position wird Sie an die Wichtigkeit kleiner Entscheidungen erinnern.
4. Ich zittere immer noch. Es scheint, dass mich schon jemand anschreit: „Der Leiter, der die Implementierung der Funktion übernommen hat ?! (Und ich stimme ihm zu!) Ja, Sie bleiben immer noch ein Anführer, was bedeutet, dass es eine kleine Funktion sein sollte, okay? Ja, Sie haben noch viel zu tun. Wenn Sie die Implementierung der Funktion in keiner Weise übernehmen können, habe ich einen Ersatztipp für Sie: Beheben Sie einige Fehler. In diesem Fall werden Sie die Freuden der Schöpfung nicht spüren, aber Sie werden verstehen, wie das Produkt hergestellt wird, was bedeutet, dass Sie niemals von der Arbeit ausgeschlossen werden.
5. Schreiben Sie Unit-Tests. Ich mache das immer noch in den späteren Phasen des Produktionszyklus, wenn die Leute verrückt werden. Stellen Sie sich das als Gesundheitscheckliste für Ihr Produkt vor. Mach es oft.

Wieder ein Einwand?

„Rand, wenn ich den Code schreibe, werde ich mein Team verwirren. Sie werden nicht wissen, wer ich bin, der Anführer oder der Entwickler. “

Gut.

Ja, ich sagte: "Gut!" Ich bin froh, dass Sie glauben, dass Sie Ihr Team nur verwirren können, wenn Sie in einem Teich von Entwicklern schwimmen. Hier ist alles einfach: Die Grenzen zwischen verschiedenen Rollen im Bereich der Softwareentwicklung sind derzeit sehr verschwommen. Die UI-Leute machen das, was man allgemein als JavaScript- und CSS-Programmierung bezeichnen kann. Entwickler lernen immer mehr über das Entwerfen von Benutzerinteraktionen. Die Menschen kommunizieren miteinander und erfahren etwas über Fehler, Diebstahl des Codes eines anderen und dass es keinen guten Grund für den Führer gibt, nicht an diesen massiven, globalen, fremdbefruchtenden Informationsbacchanalien teilnehmen zu können.

Möchten Sie auch Teil eines Teams sein, das aus leicht austauschbaren Komponenten besteht? Dies macht Ihr Team nicht nur agiler, sondern gibt jedem seiner Mitglieder die Möglichkeit, das Produkt und das Unternehmen aus verschiedenen Blickwinkeln zu betrachten. Wie können Sie Frank, diesen coolen Typen, der für das Layout verantwortlich ist, immer noch respektieren, wenn Sie nicht die schlichte Eleganz seiner Assemblerskripte sehen?

Ich möchte nicht, dass in Ihrem Team Verwirrung und Chaos herrschen. Im Gegenteil, ich möchte, dass die Kommunikation in Ihrem Team effektiver wird. Ich bin sicher, wenn Sie selbst an der Erstellung eines Produkts und der Arbeit an Funktionen beteiligt sind, sind Sie Ihrem Team näher. Und was noch wichtiger ist, Sie sind näher an den ständigen Änderungen im Softwareentwicklungsprozess in Ihrem Unternehmen.

Hören Sie nicht auf, sich zu entwickeln

Eine meiner Borland-Kolleginnen hat mich einmal verbal angegriffen, weil ich sie als „Kodiererin“ bezeichnet habe.

„Rand, der Encoder ist eine hirnlose Maschine! Affe Ein Encoder schreibt nur langweilige Zeilen mit nutzlosem Code. Ich bin kein Programmierer, ich bin ein Softwareentwickler! "

Sie hatte recht, sie würde meinen ersten Rat an die neuen Führer hassen: "Hör auf, Code zu schreiben!" Nicht weil ich davon ausgehe, dass sie Programmierer sind, sondern weil ich proaktiv vorschlage, dass sie einen der wichtigsten Teile ihrer Arbeit - die Softwareentwicklung - ignorieren.

Also habe ich meinen Rat abgeschlossen. 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 Veteran der Softwareentwicklung, der das Silicon Valley noch nicht verlassen hat. In den letzten 20 Jahren gelang es Michael, in einer Vielzahl innovativer Unternehmen wie Apple, Netscape, Symantec, Borland, Palantir und Pinterest zu arbeiten und an einem Startup teilzunehmen, das langsam in Vergessenheit geriet.

Zusätzlich zu seiner Arbeit unterhält Michael ein beliebtes Technologie- und Management-Blog unter dem Pseudonym Rand, in dem er Management-Ideen mit Lesern bespricht, seine Besorgnis über die ständige Notwendigkeit zum Ausdruck bringt und erklärt, dass Ihr Erfolg trotz der großzügigen Belohnungen für das zu erstellende Produkt nur möglich ist Danke an dein Team. Der Blog kann unter www.randsinrepose.com gefunden werden .

Michael lebt mit seiner Familie in Redwood, Kalifornien. Er findet immer Zeit, um Mountainbike zu fahren, Hockey zu spielen und Rotwein zu trinken, da es wichtiger ist, gesund zu sein als beschäftigt zu sein.

»Weitere Informationen zum Buch finden Sie auf der Website des Herausgebers
» Inhalt
» Auszug

20% Rabatt-Gutschein für Straßenhändler - Managing Humans

Nach Zahlung der Papierversion des Buches wird eine elektronische Version des Buches per E-Mail verschickt.

PS: 7% der Kosten des Buches fließen in die Übersetzung neuer Computerbücher. Die Liste der Bücher, die der Druckerei übergeben wurden, finden Sie hier .