Le livre «Comment gérer les intellectuels. I, nerds and geeks "

Dédié aux chefs de projet (et à ceux qui rêvent de devenir patron).

Écrire des tonnes de code est difficile, et gérer les gens est encore plus difficile! Il vous suffit donc de ce livre pour apprendre à faire les deux.

Est-il possible de combiner des histoires cool et des leçons sérieuses? Michael Lopp (également connu sous le nom de Randes dans les cercles étroits) a réussi. Des histoires fictives sur des personnes fictives avec des expériences incroyablement utiles (quoique fictives) vous attendent. C'est ainsi que Randy partage son expérience diversifiée, parfois étrange, acquise au fil des années de travail dans de grandes sociétés informatiques: Apple, Pinterest, Palantir, Netscape, Symantec, etc.

Êtes-vous chef de projet? Ou voulez-vous comprendre ce que votre fichu patron fait toute la journée? Rand vous apprendra comment survivre dans le monde toxique des dindes gonflées et prospérer dans la folie générale de personnes dysfonctionnelles et dynamiques. Dans cette étrange communauté de sages maniaques, il y a même des créatures plus étranges - des gestionnaires qui, grâce à un rituel organisationnel mystique, ont pris le pouvoir sur les plans, les pensées et les comptes bancaires de nombreuses personnes.

Ce livre ne ressemble à aucun manuscrit sur la gestion ou le leadership. Michael Lopp ne cache rien, il raconte tout comme il est (peut-être que toutes les histoires ne devraient pas être rendues publiques: R). Mais seulement de cette façon, vous comprendrez comment vous pouvez survivre avec un tel patron, comment gérer les geeks et les nerds, et comment mener à bien ce «putain de projet»!

Extrait. Mentalité d'ingénieur

Réflexions sur le sujet: avez-vous besoin de continuer à écrire du code

Il y a une très courte liste de gestionnaires incontournables modernes dans le livre de Rands sur les règles de leadership. Le laconicisme de cette liste vient du fait que le concept de «must» est une sorte d'absolu, et quand il s'agit de personnes, il y a très peu de concepts absolus. Une méthode efficace de gestion d'un employé sera un véritable désastre pour un autre. Cette idée est le premier élément de la liste des "incontournables" de la gestion:

Restez flexible!

Considérer que vous savez déjà tout est une très mauvaise idée. Dans une situation où le seul fait immuable est le fait que des changements constants se produisent dans le monde, la flexibilité devient la seule vraie position.

Paradoxalement, le deuxième élément de la liste est étonnamment rigide. Cependant, cet article est mon préféré, car je pense qu'il contribue à jeter les bases d'une croissance managériale. Ce paragraphe se lit comme suit:

Arrêtez d'écrire du code!

Théoriquement, si vous voulez être un leader, vous devez apprendre à faire confiance à ceux qui travaillent pour vous et leur transmettre complètement le code. Ces conseils sont généralement difficiles à «digérer», en particulier par les nouveaux dirigeants. L'une des raisons pour lesquelles ils sont devenus leaders est probablement leur productivité dans le développement, et lorsque les choses tournent mal, leur première réaction est de recourir à des compétences dans lesquelles ils sont complètement confiants, c'est-à-dire à leur capacité à écrire du code.

Quand je vois qu'un leader nouvellement créé "tombe" avant d'écrire du code, je lui dis: "Nous savons que vous pouvez écrire du code. La question est différente: savez-vous diriger? Vous n'êtes plus responsable de vous seul, vous êtes responsable de toute l'équipe; et je veux être sûr que vous pouvez amener votre équipe à résoudre les problèmes par elle-même, sans avoir à écrire le code vous-même. Votre tâche consiste à comprendre comment vous mettre à l'échelle. Je veux que tu ne sois pas le seul et unique, je veux tant de gens comme toi. »

Un bon conseil, non? Échelle. La gestion Responsabilité Ces mots à la mode courants. Il est dommage que le conseil soit incorrect.

Faux?

Ouais. Le conseil est faux! Non pas que ce soit complètement faux, mais suffisamment mal pour que j'aie dû appeler d'anciens collègues et m'excuser: «Tu te souviens de ma déclaration préférée que tu devrais arrêter d'écrire du code? C'est faux! Oui ... recommencez la programmation. Commencez avec Python et Ruby. Oui, je suis sérieux! Votre carrière en dépend! »

Quand j'ai commencé ma carrière en tant que développeur de logiciels chez Borland, je travaillais dans l'équipe Paradox pour Windows, et c'était une énorme équipe. Un seul développeur d'application comptait 13 personnes. Si nous ajoutons des personnes d'autres équipes qui ont également constamment travaillé sur des technologies clés pour ce projet, telles que le moteur de base de données principal et les principaux services d'application, nous obtenons 50 ingénieurs directement impliqués dans le développement de ce produit.

Aucune autre équipe pour laquelle j'ai jamais travaillé n'a même approché des tailles similaires. En fait, avec chaque année qui passe, le nombre de personnes dans l'équipe dans laquelle je travaille diminue progressivement. Que se passe-t-il? Sommes-nous des développeurs collectivement plus intelligents et plus intelligents? Non, nous distribuons simplement la charge.

Que font les développeurs depuis 20 ans? Pendant ce temps, nous avons écrit un tas de code de merde. Mer de code! Nous avons écrit tellement de code que nous avons décidé: ce serait bien de tout simplifier et de passer au code open source.

Heureusement, grâce à Internet, ce processus est devenu aussi simple que possible. Si vous êtes un développeur de logiciels, vous pouvez le vérifier dès maintenant! Recherchez votre nom sur Google ou sur Github, et vous verrez un code que vous avez oublié depuis longtemps, mais que quiconque souhaite peut trouver. Effrayant, hein? Vous ne saviez pas que le code vit pour toujours? Oui, il vit pour toujours.

Le code vit pour toujours. Un bon code ne vit pas seulement pour toujours, il grandit, car ceux qui l'apprécient veillent constamment à ce qu'il ne perde pas sa fraîcheur. Ce tas de code de haute qualité et bien entretenu contribue à réduire la taille moyenne d'une équipe d'ingénieurs, car il nous permet de nous concentrer non pas sur l'écriture de nouveau code, mais sur le code existant et de travailler avec moins de personnes impliquées et dans un temps plus court.

Cette ligne de raisonnement semble déprimante, mais l'idée est que nous ne sommes qu'un groupe de machines d'intégration qui utilisent du ruban adhésif pour connecter différents éléments existants afin de créer une version légèrement différente de la même chose. Il s'agit d'une ligne de pensée classique pour la haute direction qui aime l'externalisation. "Cela peut être fait par toute personne qui sait utiliser Google et qui a du ruban adhésif! Alors pourquoi payons-nous une tonne d'argent à nos distributeurs automatiques? »

Nous payons ces types de cadres vraiment beaucoup d'argent, et ils pensent que c'est un non-sens. Encore une fois: mon idée clé est qu'il existe de nombreux développeurs brillants et très diligents sur notre planète; ils sont vraiment brillants et zélés, bien qu'ils n'aient pas passé une seule minute assis dans des universités accréditées. Oh oui, maintenant il y en a de plus en plus!

Je ne suggère pas que vous commenciez à vous soucier de votre place simplement parce que de brillants camarades le chassent soi-disant. Je vous suggère de commencer à vous inquiéter pour lui, car l'évolution du développement logiciel peut se déplacer plus rapidement que vous. Vous travaillez depuis dix ans, dont cinq ans en tant que leader, et vous pensez: «Je sais déjà comment les logiciels sont développés.» Oui tu sais. Au revoir ...

Arrêtez d'écrire du code, mais ...

Si vous suivez mes conseils initiaux et arrêtez d'écrire du code, vous cesserez en même temps de participer volontairement au processus de création. C'est pour cette raison que je ne suis pas particulièrement actif dans l'externalisation. Les machines ne créent pas, elles produisent. Des processus bien conçus peuvent faire économiser beaucoup d'argent, mais ils n'apporteront rien de nouveau à notre monde.

Si vous avez une petite équipe et que cela fait beaucoup pour peu d'argent, l'idée d'arrêter d'écrire du code semble être une mauvaise décision de carrière. Même dans les entreprises monstres avec leurs réglementations, processus et politiques sans fin, vous n'avez pas le droit d'oublier comment développer vous-même un logiciel. Et le développement de logiciels est en constante évolution. Elle change en ce moment. Sous vos pieds! Cette seconde!

Vous avez une objection. Je comprends. Écoutons.

"Randy, je suis en route vers la chaise du directeur!" Si je continue à écrire du code, personne ne croira que je suis capable de grandir. »

Je veux vous poser cette question: depuis que vous avez pris votre place "je vais bientôt devenir directeur!", Avez-vous remarqué que le domaine du développement logiciel évolue même au sein de votre entreprise? Si votre réponse est oui, alors je vais vous poser une autre question: comment cela change-t-il exactement et qu'allez-vous faire en relation avec ces changements? Si vous avez répondu «non» à ma première question, alors vous devez passer à une autre chaise, car (je donne une dent!) La portée du développement de logiciels change cette seconde. Comment allez-vous grandir si vous oubliez lentement mais sûrement comment développer un logiciel?

Mon conseil est de ne pas vous confier des tonnes de fonctionnalités pour votre prochain produit. Vous devez constamment prendre des mesures pour rester à jour sur la façon dont votre équipe crée des logiciels. Vous pouvez le faire à la fois en tant que directeur et en tant que vice-président. Quelque chose d'autre?

«Euh, Randy! Mais quelqu'un doit être arbitre! Quelqu'un devrait voir la situation dans son ensemble. Si j'écris du code, je perdrai de vue la perspective. "

Vous devez toujours rester l'arbitre, vous devez toujours diffuser les décisions, et vous devez toujours faire le tour du bâtiment quatre fois chaque lundi matin avec l'un de vos ingénieurs pour écouter sa tirade hebdomadaire pendant 30 minutes: «Nous sommes tous condamnés ! " Mais en plus de tout cela, vous devez garder en vous la façon de penser de l'ingénierie, et pour cela, vous n'avez pas besoin d'être un programmeur à plein temps.

Mes conseils pour maintenir une mentalité d'ingénieur:

1. Utilisez l'environnement de développement. Cela signifie que vous devez être familier avec les outils de votre équipe, notamment un système de construction de code, un contrôle de version et un langage de programmation. Par conséquent, vous parlerez couramment le langage utilisé par votre équipe lorsqu'elle parle de développement de produits. Il vous permettra également de continuer à utiliser votre éditeur de texte préféré qui fonctionne très bien.
2. Vous devez pouvoir dessiner un schéma architectural détaillé qui décrit votre produit sur n'importe quelle surface et à tout moment. Maintenant, je ne parle pas d'une version simplifiée avec trois cellules et deux flèches. Vous devez connaître le schéma détaillé du produit. Le plus difficile. Pas n'importe quel joli schéma, mais un schéma difficile à expliquer. Il doit s'agir d'une carte adaptée à une compréhension complète du produit. Il est en constante évolution et vous devez toujours savoir pourquoi ces changements ou d'autres se sont produits.
3. Assumer la mise en œuvre d'une des fonctions. Je tremble littéralement quand j'écris ceci, parce que ce paragraphe est plein de dangers cachés, mais je ne suis vraiment pas sûr que vous puissiez remplir le paragraphe 1 et le paragraphe 2 sans assumer au moins une fonction . Grâce à la mise en œuvre indépendante de l'une des fonctions, vous participerez non seulement activement au processus de développement, mais cela vous permettra également de passer périodiquement du rôle de «Manager responsable de tout» au rôle de «Personne responsable de la mise en œuvre de l'une des fonctions». Cette position modeste et sans prétention vous rappellera l'importance des petites décisions.
4. Je tremble encore. Il semble que quelqu'un me crie déjà: «Le leader qui a repris la mise en place de la fonction?! (Et je suis d'accord avec lui!) Oui, vous restez toujours un leader, ce qui signifie que cela devrait être une petite fonction, d'accord? Oui, il vous reste encore beaucoup à faire. Si vous ne pouvez pas prendre en charge l'implémentation de la fonction de quelque manière que ce soit, alors j'ai une astuce de rechange pour vous: gérer certains bugs. Dans ce cas, vous ne ressentirez pas les joies de la création, mais vous comprendrez comment le produit est créé, ce qui signifie que vous ne serez jamais laissé au chômage.
5. Écrire des tests unitaires. Je le fais toujours dans les dernières étapes du cycle de production, quand les gens commencent à devenir fous. Considérez-le comme une liste de contrôle de santé pour votre produit. Faites-le souvent.

Encore une objection?

«Rand, si j'écris le code, alors je vais confondre mon équipe. Ils ne sauront pas qui je suis, le leader ou le développeur. »

Bon.

Oui, j'ai dit: "Bien!" Je suis heureux que vous pensiez que vous ne pouvez confondre votre équipe qu'en nageant dans un bassin de développeurs. Ici, tout est simple: les frontières entre les différents rôles dans le domaine du développement logiciel sont actuellement très floues. Les gars de l'interface utilisateur font ce qu'on peut généralement appeler la programmation JavaScript et CSS. Les développeurs apprennent de plus en plus à concevoir des interactions utilisateur. Les gens communiquent entre eux et apprennent les erreurs, le vol du code de quelqu'un d'autre et aussi qu'il n'y a aucune bonne raison pour que le leader ne puisse pas participer à cette bacchanale massive, globale et à pollinisation croisée.

Vous souhaitez également faire partie d'une équipe composée de composants facilement remplaçables? Cela rendra non seulement votre équipe plus agile, mais donnera à chacun de ses membres la possibilité de voir le produit et l'entreprise sous différents angles. Comment pouvez-vous toujours respecter Frank, ce gars cool responsable de la mise en page, si ce n'est après avoir vu l'élégance simple de ses scripts de montage?

Je ne veux pas que la confusion et le chaos règnent dans votre équipe. Au contraire, je veux que la communication dans votre équipe devienne plus efficace. Je suis sûr que si vous êtes vous-même impliqué dans la création d'un produit et le travail sur les fonctionnalités, vous serez plus proche de votre équipe. Et plus important encore, vous serez plus proche des changements constants dans le processus de développement de logiciels au sein de votre organisation.

N'arrêtez pas de développer

Un de mes collègues de Borland m'a agressé verbalement pour l'avoir traitée de «codeuse».

«Rand, l'encodeur est une machine sans cervelle! Singe Un encodeur ne fait qu'écrire des lignes ennuyeuses de code inutile. Je ne suis pas codeur, je suis développeur de logiciels! "

Elle avait raison, elle détesterait mon premier conseil aux nouveaux dirigeants: «Arrêtez d'écrire du code!» Non pas parce que je suppose qu'ils sont des codeurs, mais plus parce que je suggère de manière proactive qu'ils commencent à ignorer l'une des parties les plus importantes de leur travail - le développement de logiciels.

J'ai donc finalisé mes conseils. Si vous voulez être un bon leader, vous pouvez arrêter d'écrire du code, mais ...

Soyez flexible. Rappelez-vous ce que signifie être ingénieur et n'arrêtez pas de développer des logiciels.

À propos de l'auteur

Michael Lopp est un vétéran du développement de logiciels qui n'a toujours pas quitté la Silicon Valley. Au cours des 20 dernières années, Michael a réussi à travailler dans une variété d'entreprises innovantes, notamment Apple, Netscape, Symantec, Borland, Palantir, Pinterest, et a également participé à une startup qui s'est lentement éloignée dans l'oubli.

En plus de son travail, Michael maintient un blog populaire sur les technologies et la gestion sous le pseudonyme Rands, où il discute des idées de gestion avec les lecteurs, exprime sa préoccupation quant au besoin constant de se tenir au courant et explique que, malgré les généreuses récompenses pour le produit créé, votre succès n'est possible que merci à votre équipe. Le blog est disponible sur www.randsinrepose.com .

Michael vit avec sa famille à Redwood, en Californie. Il trouve toujours le temps de faire du vélo de montagne, de jouer au hockey et de boire du vin rouge, car être en bonne santé est plus important qu'occupé.

»Plus d'informations sur le livre sont disponibles sur le site Web de l'éditeur
» Contenu
» Extrait

20% de réduction sur les colporteurs - Managing Humans

Lors du paiement de la version papier du livre, une version électronique du livre est envoyée par e-mail.

PS: 7% du coût du livre ira à la traduction de nouveaux livres informatiques, la liste des livres remise ici à l'imprimerie.