Mickey Mantle et Ron Lichty ont écrit un livre sur la gestion et la contractualisation des programmeurs "Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams” . Le livre examine les caractéristiques des programmeurs et des équipes de développement, en s'appuyant sur leur propre expérience, sur des interviews et des conversations avec des programmeurs, des chefs d'équipe, des managers, des directeurs et des directeurs de technologies. Ils fournissent une variété d'outils ainsi que de nombreuses règles de base qu'ils ont recueillis au fil des ans. Ils ont récemment présenté leur livre à InfoQ :
InfoQ : Quel est le problème sous-jacent ? Pourquoi avez-vous écrit ce livre ?
En tant que professionnels du monde logiciel, nous avons vu l'industrie du logiciel évoluer depuis des décennies en mettant l'accent sur un matériel plus rapide, de nouveaux et "meilleurs" langages de programmation, des frameworks de développement, l'amélioration des processus et des certifications (par exemple ISO 9000), et l'évolution des méthodologies de gestion de projet - toutes de grandes contributions à l'industrie du logiciel. Cependant nous avons constaté que peu d'attention était accordée au cœur et à l'âme de cette industrie, à savoir les légions de programmeurs qui créent de grands produits logiciels, et à la façon de gérer ces programmeurs avec efficacité.
Notre expérience en tant que développeurs, et les dizaines d'années que nous avons passées à gérer des programmeurs, nous ont enseigné un grand nombre de leçons sur qui nous sommes, nous les programmeurs, ce qui nous motive, et comment nous pouvons être gérés efficacement.
Nous avons trouvé peu de livres qui abordaient la problématique de la gestion des développeurs et des équipes de développement, et ceux que nous avons trouvés ne mentionnaient pas la plupart des leçons que nous avions apprises au fil des années. C'est pourquoi nous avons décidé d'écrire un livre très personnel, partageant beaucoup d'anecdotes, de leçons, et d'outils que nous avons appris, acquis ou construits au cours des années que nous avons consacrées à gérer les programmeurs avec succès.
InfoQ : Qu'est-ce qui vous qualifie pour écrire sur ce sujet ? Pourquoi les gens devraient écouter vos points de vue ?
Nous ne sommes pas des universitaires, nous avons écrit du code et géré des équipes qui ont produit des logiciels utilisés ensuite par un grand nombre de personnes. Lorsque Ron dirigeait le développement des économiseurs d'écran et des jeux chez Berkeley Systems et Mickey celui des logiciels pour enfants de Broderbund Software, nous étions peut-être plus impliqués dans les produits que nos équipes codaient, que presque n'importe quel autre duo de responsables de développement dans le monde. Nous racontons l'histoire de la création de ces produits et de la gestion des équipes, en partageant les connaissances que nous avons apprises à la dure, en espérant que nous pourrons alléger cette tâche d'encadrement des programmeurs pour les autres managers.
Mais le livre ne se limite pas à notre expérience. Le "coeur crémeux", c'est ainsi qu'un lecteur a désigné les 80 pages du milieu du livre, contient 300 règles de base et pépites de sagesse venant de managers du monde entier (y compris de nombreuses sommités). Ce sont des mots de sagesse que nous avons entendus, lus, et utilisés nous-mêmes au fil des ans. Nous les partageons en sachant que ces règles et ces pépites aideront d'autres responsables, comme elles nous ont aidés.
InfoQ : Quel est le public visé par votre livre ?
Nous avons tout d'abord écrit ce livre pour les managers en première ligne, aussi bien les nouveaux que les chevronnés. Le livre fournit un grand nombre aussi bien de conseils pratiques que d'outils qu'ils peuvent utiliser pour devenir de meilleurs managers de développeurs et d'équipes de développement.
Il s'adresse également aux managers des services de développement qui sont, pour la plupart, chargés d'encadrer une équipe composée tout ou partiellement de responsables de développement. Nous espérons que, grâce à Managing the Unmanageable, ils pourront s'appuyer sur nous pour le lancement et l'essor de leurs responsables de développement ainsi que le fonctionnement de leurs services.
La troisième public visé, et nous avons été informés par de nombreux chefs d'entreprises, chefs d'exploitation et d'exploitation informatique que nous avions atteint notre objectif, est le top management qui dépendent de logiciels (et des programmeurs qui développent ces logiciels) pour la réussite de leurs entreprises et veulent acquérir des connaissances sur la façon d'encadrer les développeurs apparemment incontrôlables qu'ils emploient.
Enfin, les lecteurs continuent de nous dire que Managing the Unmanageable est extrêmement utile pour quiconque veut être un meilleur gestionaire de ressources humaines. La plus grande partie du livre contient des idées et des outils qui peuvent être appliqués à toute personne voulant être un grand manager.
InfoQ : La gestion des programmeurs n'est-elle pas semblable à la gestion de n'importe quel rôle d'expert ? Qu'est-ce qu'il y a de spécial à propos des développeurs ?
Toute personne ayant géré d'autres groupes, y compris d'autres disciplines d'ingénierie en plus de développeurs arrivera probablement à la conclusion que la gestion des développeurs se révèle vraiment différente et plus difficile. C'est en partie parce que les résultats sont moins tangibles (et par conséquent il est plus difficile de mesurer les progrès) que dans des disciplines telles que la conception de matériel ou le génie mécanique. C'est aussi en partie parce que, même d'il y a des parties de la programmation qu'on pourrait appeler "ingénierie", il y a d'autres éléments plus justement appelés "métier" ou "art" ou "échange". L'ingénierie est, la plupart du temps, prévisible et répétable d'une manière qui n'existe pas dans la programmation. Quand, pour la dernière fois, avez-vous entendu parler d'un grand immeuble ou d'une autoroute ou d'une station d'épuration qui a dû être abandonné juste avant son achèvement parce que les constructeurs ne parvenaient pas à trouver comment le finir ? Bien que que tous les travailleurs intellectuels aient des défis à relever, nous pensons que ces défis sont généralement plus grands pour les programmeurs.
InfoQ : Quel est l'aspect le plus difficile auquel on doit s'attendre pour gérer une équipe de développement ?
Beaucoup de nouveaux managers étaient, encore peu de temps auparavant, des collègues des développeurs qu'ils dirigent maintenant. La transition de contributeur individuel à manager solitaire est un défi. Faire cette transition avec une équipe dont vous faisiez partie peut être particulièrement difficile. Et, pour compliquer les choses, la plupart des nouveaux managers sont promus à ce poste sans aucune formation ou coaching sur comment ou quoi faire. Pour beaucoup, c'est l'aspect le plus difficile de ce nouveau travail.
Un deuxième défi est de savoir exactement quoi faire : ce qui est important et ce qui ne l'est pas. Dans notre livre nous avons essayé d'indiquer les domaines sur lesquels nous jugeons le plus important de se concentrer et ceux qui le sont moins pour un nouveau manager.
Un troisième défi est un changement radical du comportement. Un grand programmeur (ce qu'étaient beaucoup d'entre-eux avant d'être choisis pour être managers) excelle à s'exclure du monde et entrer dans la "zone", cet espace calme où, en tant que programmeur, vous habitez seulement avec le microprocesseur, pendant que vous écrivez du code qui le plie à votre volonté. Mais un bon manager ne doit pas seulement laisser un tapis de bienvenue virtuel devant la porte. Il doit littéralement envoyer une invitation à ses développeurs à l'interrompre à tout moment sur n'importe quelle question ! Le travail n'est plus une question d'accomplissement personnel, mais de soutien et d'aide aux développeurs dans leur travail.
InfoQ : Vous regardez les programmeurs à travers différentes "loupes" dans le livre. Quels sont les aspect qui font la différence quand on regarde les développeurs, et pourquoi sont-ils importants ?
Nos "loupes" examinent les types de programmeurs (par exemple les programmeurs de systèmes, les programmeurs de base de données, etc...), les différents types de personnalités (par exemple les gens du matin, les gens de la nuit, etc...), les différentes générations (baby-boom, millénaire, etc...), et d'autres. Le point important est que, pour gérer un développeur efficacement, vous devez le comprendre à un niveau très personnel et utiliser tous les outils dont vous disposez pour le faire. Ensuite, utiliser le levier qui fonctionnera le mieux avec cette personne. Cette motivation est très variable, nous donnons même une formule pour vous aider à comprendre ce qui importe le plus pour un programmeur !
InfoQ : Vous présentez distinctement différents types d'informations dans le livre. Certaines sections semblent être des tutoriaux avec des modèles, des lignes directrices et des listes de contrôle quand d'autres se concentrent sur des aspects tels que la culture, la motivation et les relations. Pourquoi cet équilibre, et quels sont les domaines les plus importants ?
Les différents types d'informations renvoient au sous-titre du livre "Rules, Tools, and Insights for Managing Software People and Teams". L'objectif de ce livre était de fournir ces trois types d'informations (règles, outils et idées) que nous aurions aimé avoir tous les trois lorsque nous avons commencé à encadrer nos pairs et d'autres programmeurs. Ce sera au lecteur de décider lequel est le plus important. Nous pensons qu'ils sont tous importants.
InfoQ : Dans la section sur le management vous consacrez un chapitre entier à "la gestion ascendante", probablement une compétence que tout manager se doit de posséder, indépendamment de son domaine. Encore une fois, qu'y a-t-il de spécial dans la gestion de développeurs ?
Vous avez raison, la gestion ascendante est une compétente que tout bon manager doit maîtriser pour maximiser tout le succès qu'il rencontre dans son travail. Nous ne comprenons que trop bien son importance après toutes ces années à gérer nos chefs. Pourtant, nous en avons rarement entendu parler dans un cours de gestion.
Bien que la gestion puisse être universelle, nous avons ajouté quelques détails pertinents en ce qui concerne les développeurs qui sont devenus des managers. Alors que les développeurs rapportent généralement à d'anciens programmeurs, tôt ou tard (et souvent plus tôt que tard) nous, les managers de développeurs, nous trouvons en train de gérer des chefs (et leurs chefs) qui peuvent ne pas comprendre (ou prendre la peine de comprendre) la culture ou la technologie inhérente à la réussite de la gestion de développeurs.
InfoQ : Vous consacrez un chapitre à la culture d'entreprise et à la création d'une "sous-culture du développement pour réussir même dans la plus toxique des cultures d'entreprise". Qu'est-ce qui est nécessaire pour créer cette sous-culture de la réussite ?
Il s'agit d'un chapitre important dans le livre puisqu'il montre comment tirer partie des aspects positifs de votre culture d'entreprise tout en essayant d'en murer les aspects négatifs et de les remplacer par des valeurs que votre équipe peut adopter.
InfoQ : Il y a toute une partie sur les "règles d'or et pépites de sagesse" qui se sont avérées précieuses pour vous au fil des ans. Comment les lecteurs devraient les utiliser ?
Nous pensons que ces règles d'or et ces pépites de sagesse sont parmi les meilleures choses à retenir du livre. Le seul fait de les lire peut donner à un manager la confiance en ses convictions pour faire ce qu'il pense être la meilleure chose pour développer un logiciel, soutenu par la sagesse de ceux qui ont réduit leur expérience à de petits morceaux de connaissance. Nous les avons personnellement utilisés pour désamorcer des conflits, faire passer un message à nos développeurs qui, sinon, ne l'auraient pas entendu, et pour s'orienter vers un meilleur développement. Par exemple, lorsque nous sommes face à solution compliquée à un problème apparemment simple, et souvent entouré de partenaires commerciaux exigeants qui ne comprennent pas pourquoi développer toutes les fonctionnalités à la fois n'est pas facile, comment peut-on ignorer le conseil "ne te complique pas la vie" ?
L'une des premières règles que nous avons découvertes tous les deux était la loi de Brooks : "Ajouter de la main d'œuvre à un projet logiciel en retard le retarde encore plus." Fred Brooks a codifié cette règle dans son classique sur le management de projet logiciel, The Mythical Man-Month, il y a presque 40 ans - et pourtant nous continuons à rencontrer des exécutifs qui n'en ont pas entendu parler. Il est utile d'avoir une règle comme ça dans sa poche.
InfoQ : Sur le site web qui accompagne le livre, vous fournissez une liste d'outils. A quoi les lecteurs du livre auront-il accès sur le site ?
Nous avons inclus des outils que nous avons créés ou recueillis au fil des ans, dont des exemples de descriptions d'offres d'emploi, des listes de contrôles pour que le nouveau développeur parte du bon pied, un exemple de classeur de projets pour aider à la gestion de projets, des modèles d'objectifs trimestriels, et de nombreux autres outils utiles. Les bons managers voudront personnaliser ces outils, mais avoir un point de départ leur fera gagner beaucoup de temps. Nous pensons que ces outils seuls valent plus que le prix du livre !
InfoQ : Y a-t-il autre chose que vous voudriez partager avec nos lecteurs ?
Nous avons écrit ce livre principalement pour créer quelque chose que nous aurions aimé avoir lorsque nous avons commencé à gérer d'autres programmeurs. Nous étions tous deux des développeurs avant d'être "promus" au rang de manager, comme beaucoup sans formation, peu d'indications, et presque pas de feedback. Nous avons tous les deux commis des erreurs mais nous avons appris au long du chemin (d'après ceux qui ont travaillé pour nous) et nous sommes tous deux de bons, voire d'excellents, managers. Nous espérons que ce livre peut rendre cette transition de pair à manager plus facile pour d'autres, et nous espérons qu'il servira de mentor à ces managers qui n'en trouvent pas par eux-même. Nous l'avons écrit du fond du cœur en gardant cet objectif à l'esprit.
Les auteurs ont également fourni un accès gratuit au chapitre 8 du livre.
A propos des auteurs
Ron Lichty a développé des logiciels pendant 30 ans, la plupart en tant que manager de développement, directeur de développement, et vice-président rsponsable produits et ingénierie pour des entreprises comme Apple, Fujitsu, Razorfish, et Schwab. Il a publié quatre livres et des centaines d'articles. Il est sollicité par des start-ups et de petites et grandes entreprises pour démêler les nœuds dans le développement de logiciel et le faire tourner rond.
Mickey Mantle a développé des logiciels pendant plus de 40 ans en tant que créateur de produits logiciels et matériels, Manager et exécutif pour des entreprises comme Evans & Sutherland, Pixar, Broderbund, et Gracenote, il développe actuellement des applications pour terminaux mobiles et tablettes, écrit et intervient comme consultant.