Dédié aux chefs de projet (et à ceux qui rêvent de devenir patrons).
Écrire des tonnes de code est difficile, mais gérer des personnes est encore plus difficile ! Vous avez donc juste besoin de ce livre pour apprendre à faire les deux.
Est-il possible de combiner histoires drôles et leçons sérieuses ? Michael Lopp (également connu dans les cercles restreints sous le nom de Rands) a réussi. Vous trouverez des histoires fictives sur des personnes fictives avec des expériences incroyablement enrichissantes (bien que fictives). C'est ainsi que Rands partage ses expériences variées, parfois étranges, acquises au fil des années de travail dans de grandes entreprises informatiques : Apple, Pinterest, Palantir, Netscape, Symantec, etc.
Êtes-vous chef de projet ? Ou vous voulez comprendre ce que fait votre foutu patron toute la journée ? Rands vous apprendra comment survivre dans le monde toxique des dindes gonflées et prospérer dans la folie générale des gens flamboyants et dysfonctionnels. Dans cette étrange communauté de cerveaux maniaques, il existe des créatures encore plus étranges : des managers 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 simplement les choses telles qu'elles sont (peut-être que toutes les histoires ne devraient pas être rendues publiques : P). Mais c'est seulement ainsi que vous comprendrez comment survivre avec un tel patron, comment gérer les geeks et les nerds, et comment mener à bien « ce foutu projet » !
Extrait. Mentalité d'ingénierie
Réflexions sur : devriez-vous continuer à écrire du code ?
Le livre de Rands sur les règles destinées aux managers contient une très courte liste de « choses incontournables » en matière de gestion moderne. Le laconisme de cette liste vient du fait que le concept de « devoir » est une sorte d'absolu, et lorsqu'il s'agit de personnes, il existe très peu de concepts absolus. Une méthode de management réussie pour un employé sera un véritable désastre pour un autre. Cette pensée est le premier élément de la liste des « choses à faire » du manager :
Restez flexible !
Penser que l’on sait déjà tout est une très mauvaise idée. Dans une situation où la seule constante est que le monde est en constante évolution, la flexibilité devient la seule position correcte.
Paradoxalement, le deuxième élément de la liste est étonnamment rigide. Cependant, ce point est mon préféré car je pense qu’il contribue à créer les bases de la croissance managériale. Ce paragraphe se lit comme suit :
Arrêtez d'écrire du code !
En théorie, si vous voulez devenir manager, vous devez apprendre à faire confiance à ceux qui travaillent pour vous et leur confier entièrement le codage. Ce conseil est généralement difficile à digérer, surtout pour les nouveaux managers. L'une des raisons pour lesquelles ils sont devenus managers est probablement leur productivité en matière de développement, et lorsque les choses tournent mal, leur première réaction est de s'appuyer sur les compétences en lesquelles ils ont pleinement confiance, à savoir leur capacité à écrire du code.
Quand je vois qu'un nouveau manager « s'enfonce » dans l'écriture de code, je lui dis : « Nous savons que vous pouvez écrire du code. La question est : pouvez-vous diriger ? Vous n'êtes plus responsable de vous seul, vous êtes responsable de toute l'équipe ; et je veux m'assurer que vous pouvez amener votre équipe à résoudre les problèmes par elle-même, sans que vous ayez à écrire le code vous-même. Votre travail consiste à trouver comment vous développer. Je ne veux pas que vous soyez un seul, je veux qu’il y en ait beaucoup comme vous.
Un bon conseil, non ? Échelle. Gestion. Responsabilité. Des mots à la mode si courants. C'est dommage que le conseil soit faux.
Incorrect?
Ouais. Le conseil est faux ! Pas complètement faux, mais suffisamment faux pour que j'ai dû appeler d'anciens collègues et m'excuser : « Vous vous souvenez de ma déclaration préférée sur la façon dont vous devriez arrêter d'écrire du code ? C'est faux! Oui... Recommencez la programmation. Commencez par Python et Ruby. Oui. Je suis sérieux! Votre carrière en dépend !
Lorsque j'ai commencé ma carrière en tant que développeur de logiciels chez Borland, j'ai travaillé dans l'équipe Paradox Windows, qui était une immense équipe. Il y avait à lui seul 13 développeurs d'applications. Si vous ajoutez des personnes d'autres équipes qui travaillaient également constamment sur les technologies clés de ce projet, telles que le moteur de base de données principal et les services d'application principaux, vous obtenez 50 ingénieurs directement impliqués dans le développement de ce produit.
Aucune autre équipe pour laquelle j'ai travaillé ne se rapproche de cette taille. En fait, chaque année qui passe, le nombre de personnes dans l’équipe avec laquelle je travaille diminue progressivement. Que se passe-t-il? Sommes-nous, les développeurs, devenant collectivement de plus en plus intelligents ? Non, nous partageons simplement la charge.
Que font les développeurs depuis 20 ans ? Pendant ce temps, nous avons écrit une tonne de code. Mer de code ! Nous avons écrit tellement de code que nous avons décidé que ce serait une bonne idée de tout simplifier et de passer à l'open source.
Heureusement, grâce à Internet, ce processus est désormais devenu aussi simple que possible. Si vous êtes un développeur de logiciels, vous pouvez le consulter dès maintenant ! Recherchez votre nom sur Google ou Github et vous verrez un code que vous avez oublié depuis longtemps, mais que tout le monde peut trouver. Effrayant, non ? Ne saviez-vous pas que le code vit éternellement ? Oui, il vit éternellement.
Le code vit pour toujours. Et un bon code non seulement vit éternellement, mais il grandit parce que ceux qui l'apprécient veillent constamment à ce qu'il reste à jour. Cette pile de code de haute qualité et bien entretenu contribue à réduire la taille moyenne de l'équipe d'ingénierie, car elle nous permet de nous concentrer sur le code existant plutôt que d'en écrire du nouveau, et d'effectuer le travail avec moins de personnes et dans un délai plus court.
Ce raisonnement semble déprimant, mais l'idée est que nous ne sommes tous qu'un groupe d'automates d'intégration utilisant du ruban adhésif pour relier différents éléments d'éléments existants afin de créer une version légèrement différente de la même chose. Il s’agit d’une pensée classique parmi les cadres supérieurs qui aiment l’externalisation. « Quiconque sait utiliser Google et possède du ruban adhésif peut le faire ! Alors pourquoi payons-nous beaucoup d’argent pour nos machines ?
Nous payons très cher ces dirigeants, mais ils pensent de telles absurdités. Encore une fois, mon point clé est qu'il existe de nombreux développeurs brillants et très travailleurs sur notre planète ; ils sont vraiment brillants et diligents, même s'ils n'ont pas passé une seule minute dans des universités accréditées. Ah oui, maintenant ils sont de plus en plus nombreux !
Je ne vous suggère pas de commencer à vous soucier de votre place simplement parce que de brillants camarades la recherchent prétendument. Je vous suggère de commencer à vous en inquiéter car l’évolution du développement logiciel évolue probablement plus rapidement que vous. Vous travaillez depuis dix ans, dont cinq en tant que manager, et vous pensez : « Je sais déjà comment on développe un logiciel. » Oui tu sais. Au revoir…
Arrêtez d'écrire du code, mais...
Si vous suivez mon conseil initial et arrêtez d'écrire du code, vous cesserez également volontairement de participer au processus de création. C'est pour cette raison que je n'utilise pas activement l'externalisation. Les automates ne créent pas, ils produisent. Des processus bien conçus permettent d'économiser beaucoup d'argent, mais ils n'apportent rien de nouveau à notre monde.
Si vous avez une petite équipe qui fait beaucoup pour peu d'argent, alors l'idée d'arrêter d'écrire du code me semble être une mauvaise décision de carrière. Même dans des 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 des logiciels. Et le développement de logiciels évolue constamment. Cela change en ce moment. Sous vos pieds ! A cette seconde même !
Vous avez des objections. Comprendre. Écoutons.
« Rands, je me dirige vers le fauteuil du réalisateur ! Si je continue à écrire du code, personne ne croira que je peux grandir.
Je veux vous demander ceci : depuis que vous occupez votre fauteuil « Je suis sur le point de devenir PDG ! », avez-vous remarqué que le paysage 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 évolue-t-il exactement et qu’allez-vous faire face à ces changements ? Si vous avez répondu « non » à ma première question, alors vous devez changer de chaise, car (je parie !) le domaine du développement logiciel est en train de changer en ce moment même. Comment allez-vous grandir si vous oubliez lentement mais sûrement comment développer des logiciels ?
Mon conseil est de ne pas vous engager à implémenter des tonnes de fonctionnalités pour votre prochain produit. Vous devez constamment prendre des mesures pour rester au courant de 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. Autre chose?
« Pouah, Rands ! Mais il faut que quelqu'un soit l'arbitre ! Il faut que quelqu’un ait une vision d’ensemble. Si j'écris du code, je perdrai la perspective."
Il faut encore être l'arbitre, il faut encore diffuser les décisions, et il faut encore se promener quatre fois dans le bâtiment tous les lundis matin avec un de vos ingénieurs pour écouter son discours hebdomadaire "Nous sommes tous condamnés" pendant 30 heures. minutes. ! Mais au-delà de tout cela, vous devez conserver un état d’esprit d’ingénierie, et vous n’avez pas besoin d’être programmeur à plein temps pour le faire.
Mes conseils pour conserver une mentalité d’ingénieur :
- Utilisez l'environnement de développement. Cela signifie que vous devez être familier avec les outils de votre équipe, notamment le système de création de code, le contrôle de version et le langage de programmation. En conséquence, vous maîtriserez le langage utilisé par votre équipe lorsqu’elle parle de développement de produits. Cela vous permettra également de continuer à utiliser votre éditeur de texte préféré, qui fonctionne parfaitement.
- Vous devez être capable de dessiner un schéma architectural détaillé décrivant votre produit sur n'importe quelle surface et à tout moment. Maintenant, je ne parle pas de la 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 diagramme mignon, mais un diagramme difficile à expliquer. Il doit s'agir d'une carte adaptée à une compréhension complète du produit. Cela change constamment et vous devez toujours savoir pourquoi certains changements se sont produits.
- Reprendre la mise en œuvre d'une des fonctions. Je grimace littéralement en écrivant ceci car ce point comporte de nombreux dangers cachés, mais je ne suis vraiment pas sûr que vous puissiez accomplir le point n°1 et le point n°2 sans vous engager à implémenter au moins une fonctionnalité. En implémentant vous-même l'une des fonctionnalités, non seulement vous participerez activement au processus de développement, mais cela vous permettra également de passer périodiquement du rôle de « Manager en charge de tout » au rôle d'« Homme en charge de l'implémentation d'une fonctionnalité ». des fonctions. Cette attitude humble et sans prétention vous rappellera l'importance des petites décisions.
- Je tremble encore de partout. Il semble que quelqu'un me crie déjà: "Le manager qui a pris sur lui la mise en œuvre de la fonction ?!" (Et je suis d'accord avec lui !) Oui, vous êtes toujours le manager, ce qui veut dire que cela devrait être une petite fonction, d'accord ? Oui, vous avez encore beaucoup à faire. Si vous ne pouvez tout simplement pas vous charger de l'implémentation de la fonction, j'ai quelques conseils supplémentaires à vous donner : corrigez quelques bugs. Dans ce cas, vous ne ressentirez pas la joie de créer, mais vous comprendrez comment le produit est créé, ce qui signifie que vous ne serez jamais sans travail.
- Écrivez des tests unitaires. Je fais encore cela tard dans le cycle de production, lorsque 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 ?
« Rands, si j'écris du code, je vais dérouter mon équipe. Ils ne sauront pas qui je suis : un manager ou un développeur.
Très bien.
Oui, j'ai dit : "D'accord !" Je suis heureux que vous pensiez que vous pouvez confondre votre équipe simplement en nageant dans l'étang des développeurs. C'est simple : les frontières entre les différents rôles dans le développement logiciel sont actuellement très floues. Les gars de l'interface utilisateur font ce que l'on peut appeler globalement la programmation JavaScript et CSS. Les développeurs en apprennent de plus en plus sur la conception de l’expérience utilisateur. Les gens communiquent entre eux et se renseignent sur les bugs, sur le vol du code d'autrui, mais aussi sur le fait qu'il n'y a aucune bonne raison pour qu'un manager ne participe pas à cette bacchanale d'information massive, mondiale et croisée.
D’ailleurs, vous souhaitez faire partie d’une équipe composée de composants facilement remplaçables ? Cela ne rendra pas seulement votre équipe plus agile, mais donnera à chaque membre de l'équipe la possibilité de voir le produit et l'entreprise sous différents angles. Comment pouvez-vous en arriver à respecter Frank, le gars calme en charge des builds, pas plus qu'après avoir vu l'élégance simple de ses scripts de build ?
Je ne veux pas que votre équipe devienne confuse et chaotique. Au contraire, je souhaite que votre équipe communique plus efficacement. Je pense que si vous êtes impliqué dans la création du produit et dans le travail sur les fonctionnalités, vous serez plus proche de votre équipe. Et plus important encore, vous serez au plus près des changements constants dans le processus de développement logiciel au sein de votre organisation.
N'arrêtez pas de développer
Une de mes collègues chez Borland m'a un jour attaqué verbalement pour l'avoir traitée de « codeuse ».
« Rands, le codeur est une machine stupide ! Singe! Le codeur ne fait rien d’important à part écrire des lignes ennuyeuses de code inutile. Je ne suis pas un codeur, je suis un développeur de logiciels ! »
Elle avait raison, elle aurait détesté mon premier conseil aux nouveaux PDG : « Arrêtez d’écrire du code ! Non pas parce que je suggère qu'ils sont des codeurs, mais plutôt 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 mis à jour mes conseils. Si vous voulez être un bon leader, vous pouvez arrêter d'écrire du code, mais...
Être 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 développeur de logiciels chevronné qui n'a toujours pas quitté la Silicon Valley. Au cours des 20 dernières années, Michael a travaillé pour diverses entreprises innovantes, notamment Apple, Netscape, Symantec, Borland, Palantir, Pinterest, et a également participé à une startup qui est lentement tombée dans l'oubli.
En dehors de son travail, Michael tient un blog populaire sur la technologie et la gestion sous le pseudonyme de Rands, où il discute avec les lecteurs d'idées dans le domaine de la gestion, exprime son inquiétude quant à la nécessité constante de rester à l'écoute et explique que, malgré le des récompenses généreuses pour la création d'un produit, votre réussite n'est possible que grâce à votre équipe. Le blog peut être trouvé ici .
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 que d'être occupé.
» Plus de détails sur le livre peuvent être trouvés sur
»
»
Pour Khabrozhiteley, 20 % de réduction en utilisant le coupon - Gérer des gens
Lors du paiement de la version papier du livre, une version électronique du livre sera envoyée par e-mail.
PS : 7% du prix du livre sera consacré à la traduction de nouveaux livres informatiques, une liste de livres remis à l'imprimerie .
Source: habr.com