Je suis un manager. Comment puis-je améliorer les relations de travail et la communication avec les programmeurs? [fermé]

Un peu de fond d'abord. Je suis chef de projet dans une entreprise de taille moyenne. J'ai commencé en tant que majeure en informatique et je me suis un peu familiarisé avec la programmation, mais après quelques mois, je savais que ce n'était pas mon chemin et je suis donc passé à la gestion. Cela s’est avéré être une bonne décision et, après avoir obtenu mon diplôme, j’ai travaillé dans la gestion de logiciels dans diverses entreprises (pendant 5 ans maintenant).

Récemment, nous avons eu un projet très douloureux. Ce fut la pire des pires, avec beaucoup d'erreurs de notre côté et du côté des clients et à peine terminée sans pertes. Cela a conduit à de nombreuses situations frustrantes, dont l'une s'est aggravée au point où l'un de nos développeurs principaux a quitté la société après une dispute avec nous (la direction). Ce fut un drapeau rouge pour moi: j'ai fait quelque chose de terriblement faux. (pour mémoire, l'argument portait sur plusieurs estimations de temps erronées)

J'ai cherché plusieurs réponses et un ami m'a indiqué ce site. Il y a beaucoup de questions ici sur les frustrations avec la gestion. Je peux comprendre que les mauvaises expériences générales conduisent à une réticence générale contre "ces gars-là dans les poursuites".

Je suis ce gars en costume. Cela ne ressemble peut-être pas à ça, mais tout ce que je veux, c'est un projet réussi. Avec des ressources limitées, cela prend des décisions pénibles. C'est mon travail. Le développeur senior susmentionné s'est plaint de l'équipement de travail. Franchement, je ne savais pas que les ordinateurs dont nous disposions n'étaient pas adaptés pour travailler. Après cela, j'ai demandé à de nombreux programmeurs et le consensus général était qu'il nous fallait de meilleures machines. J'ai corrigé cela depuis, mais il y avait évidemment un énorme fossé de communication entre moi et les programmeurs. Certains des développeurs les plus brillants sont les plus timides et les plus silencieux. Je le sais et cela n'a jamais posé de problème lors d'une interview. Les gens sont différents et ont des forces dans différents domaines.

Le cas des ordinateurs sous-alimentés n’est que l’un des nombreux cas qui m’ont amené à penser qu’il existe un problème de communication. Comment puis-je améliorer la communication avec les programmeurs sans être intimidant et répétitif?

Ce que j'espère, c'est que les gens ne se plaignent pas de bonnes choses. Si vous aimez votre lieu de travail et aimez (ou du moins aimez :)) votre responsable, merci de me le dire. Qu'est-ce qu'ils font bien? De même, si vous le détestez, veuillez décrire en détail pourquoi. Je cherche des réponses sur l'amélioration de la communication parce que je pense que c'est mon problème, mais je peux me tromper.

Hou la la! Merci d'avoir posé la question. Techniquement, comme vous, je suppose que je suis un responsable, car je passe beaucoup plus de temps à communiquer et à diriger des équipes qu'à la rédaction de code ... mais voici ce que je pense des deux côtés de l’horizon de gestion. Si je suis un développeur ou un responsable travaillant pour un autre responsable, voici quelques éléments qui facilitent ma communication avec ma direction:

• Pourquoi? est une question très importante - presque toutes les réponses factuelles ont un "pourquoi" derrière cela et ce "pourquoi" pourrait bien être plus important que la question même. Il y a quelques tangentes à ceci:
  • Pourquoi le développeur - Les développeurs auront beaucoup de réponses qui n’ont absolument aucun sens pour la direction. Je l’ai certainement fait, et l’un des moyens que j’ai pris dans la gestion a été de vraiment bien expliquer aux équipes le "pourquoi" en termes de compréhension de la direction. Si vous ne disposez pas d'un "orateur pour les geeks", vous pouvez apprendre à parler geek en répétant leurs réponses à la question pourquoi dans des métaphores plus communément comprises. Continuez jusqu'à ce que vous compreniez et conveniez de ce qui se passe.
  • Le management pourquoi- votre "pourquoi" est tout aussi important. Pourquoi avez-vous besoin des estimations de temps? Pour quoi les utilisez-vous? Comment allons-nous être foutus en tant qu'entreprise si elles sont trop hautes ou trop basses? En tant que gestionnaire, vous avez probablement un aperçu approfondi de ces éléments, mais tout cela va de soi pour le développeur. Le truc, c'est que le développeur ne peut pas demander. La direction lui a demandé quelque chose et il fera de son mieux pour être précis, rapide et réfléchi - mais s'il ne sait pas pourquoi il peut optimiser ce que vous préféreriez qu'il ne connaisse pas. Proposez votre pourquoi et demandez-lui de faire la même chose - reformulez la réponse dans ses propres termes.

En ce qui concerne les estimations de temps en particulier - j’ai dû en faire beaucoup, et j’ai absolument profité de dire à mon équipe de développement: «J’en ai besoin, car je vais demander plus d’argent pour payer nos salaires, je me fierai à ce que vous me dites et Je vais utiliser vos chiffres ... cela veut dire que si vous avez une balle basse sur moi, nous sommes tous foutus parce que je ne pourrai plus demander d’argent une seconde fois - nous devons vivre avec ce que nous proposons ". Dans ce contexte, les développeurs ont abandonné les estimations les plus basses qui tentaient de me montrer leur confiance et leur brio, et les estimations les plus élevées se sont beaucoup rapprochées des attentes réelles.

• Personne ne se trompe - la question du "pourquoi" a un corollaire: poser la question "pourquoi" au lieu de dire "c'est scandaleux! Pas du tout!" maintient la conversation fluide. Il existe parfois un décalage important entre les questions posées à quelqu'un et celles posées par le demandeur. Ma meilleure direction a été horriblement surprise par mes réponses. Lorsqu'elles sont surprises, elles clignent des yeux, puis demandent: "Pourquoi dites-vous cela?". Ils ne disent pas (immédiatement) - "vous devez le changer". J'ai réduit le nombre de propositions visant à atteindre un objectif concurrentiel, mais seulement après avoir longuement discuté de la manière dont nous pourrions changer de scène et créer un contexte différent pour la question.

• Écoutez le bruit ambiant, le choix des mots et l'espace entre les mots - Voici un tas de choses que j'ai aimé et que j'ai volées pour m'utiliser moi-même:

  • traînez dans la zone de travail, faites quelque chose de productif (n'essayez pas d'obtenir du travail de développeur, ils savent que vous n'êtes pas un développeur) et écoutez-le simplement. Comment l'équipe résout-elle les problèmes? Quels sont leurs gros problèmes? Vous n'entendrez jamais vraiment parler de leur évaluation directe de vous ou de la direction en général, mais vous aurez peut-être une très bonne idée de l'endroit où se posent les problèmes. Assurez-vous que vous faites quelque chose de votre propre qui est productif. Personne n’aime l’espionnage, mais à moins que le moral ne soit si bas que vous ne puissiez pas être près d’eux sans que tout le monde évacue, la productivité à proximité devrait être supportable.
  • cherchez des mots - ils sont souvent aussi importants que les mots eux-mêmes. Lorsque j'ai utilisé des mots particulièrement positifs ou négatifs, ma direction me demande souvent pourquoi j'ai choisi ces mots lorsqu'il s'agit d'une situation avec laquelle ils ne sont pas familiers.
  • recherchez les pauses, les lacunes et le langage corporel. S'il existe une distance de puissance entre vous et les développeurs (et cela semble être le cas), ils ne voudront peut-être pas vous contredire ou vous confronter. Mais l'instinct de base de dire "hé, vous vous trompez" se manifeste généralement quelque part.

• ouvrez autant de moyens de communication que possible - soyez prêt à discuter en personne, par téléphone, par courrier électronique ou par messagerie instantanée - de tout et n'importe quoi pour établir le flux de communication. Les gens sont tellement diversifiés qu'un seul tour ne fonctionnera pas. Et je considère que le rôle du responsable est de devenir un communicateur multiformat, et non du développeur.

• Faites en sorte que cela vaille la peine de parler avec vous Si quelqu'un vous parle d'un problème et peut-être d'une solution possible, il devrait et probablement accepter le fait que vous soyez le responsable et par conséquent peut décider en faveur d'une solution différente ou de l'absence de solution du tout parce que vous ne le faites pas. pense que ça vaut la peine. Mais après la troisième fois, cela se produit, surtout si cela se produit sans une explication, environ 99% des gens cesseront de vous dire quoi que ce soit.

Et en voici un qui est incroyablement difficile pour moi, mais qui a très bien fonctionné quand je peux le faire - soyez conscient de la différence entre introvertis et extrovertis . Les chances sont que vous êtes un extraverti - c'est pourquoi votre travail semblait bon et un poste de développement pas. Les développeurs sont, pour la plupart, des introvertis. "Introverti" ne signifie pas "ne peut pas communiquer", mais signifie que leur structure, leur processus et leur vitesse sont très différents et que le besoin de communiquer sans cesse est pratiquement inexistant. Planifiez dans le temps et l'espace (mais co-localisés) de manière à laisser émerger des pensées introverties. Beaucoup de mes amis introvertis me disent qu'ils attendent juste que je "me taise pendant environ 5 minutes" pour pouvoir réfléchir ensemble et répondre. Ici'Les extravertis doivent savoir 5 choses sur les introvertis et les Rands dans Repose on the Nerd Cave - un exemple particulièrement révélateur pour les développeurs de ce qui est formidable pour les introvertis . Au fait, Rands est plutôt fantastique. Il est lui-même un geek, alors il aborde la question en partant du point de vue du développeur, ce qui peut être déconcertant si ce n'est pas votre style, mais il est drôle et a de très bonnes idées sur le développement d'équipe.

Je pense que le n ° 1 des choses que j'ai adorées chez mes managers préférés était:

• ils étaient aussi engagés et enthousiastes à propos du projet que moi (sinon plus)

• Je n’ai jamais douté qu’ils avaient le dos tourné - je savais avec certitude que lorsqu’ils seraient devant le prochain palier d’autorité, je (ou mes pairs) ne serais jamais le bouc émissaire. Ce serait toujours un échec de groupe, s'il y avait un échec.

• À l'époque, on m'avait confié quelque chose d'important et qui convenait à mes compétences, mais avec suffisamment de ressources pour développer mes compétences et faire le travail.

• ils me considéraient à la fois en tant qu'individu et en tant que membre de l'équipe - ils étaient activement engagés à connaître mes forces et mes faiblesses et à travailler pour m'aider à exploiter mes forces et à renforcer mes faiblesses.

• ils étaient au courant de mes objectifs personnels et souhaitaient les intégrer le plus possible

• ils étaient francs quand ils me rendaient heureux ne pouvaient et ne seraient pas une priorité. Il est très utile d’entendre "Je sais que tu détestes ce type de travail, mais j’ai besoin de toi pour le faire - voici comment il ne sera pas pour toujours ...".

• il y avait toujours du temps dans une semaine (peut-être pas à l'instant) pour expliquer la grande image

• il y avait des retours et un statut presque constants, sans pointer du doigt mais avec beaucoup de reconnaissance pour le travail individuel.

• il y avait toujours la vérité. Si quelque chose était sensible et ne pouvait pas être discuté, ils l'ont dit sans rien dire. Si quelque chose était incertain, ils ont donné un niveau de confiance.

La partie facile en premier: il y a un drapeau rouge technique dans votre message: je frémis à votre mention "d'estimations erronées" - c'est une estimation, ça NE PEUT PAS ÊTRE ERREUR , c'est pourquoi on l'appelle une estimation. Ça peut être un peu, ça peut être beaucoup, c'est pourquoi on appelle ça une estimation. Si vous prenez des estimations comme évangile, ce sera l'un des principaux problèmes de "vos" développeurs avec votre style.

Cependant, je suis entièrement d'accord avec vous sur la difficulté de communiquer avec les développeurs. J'ai eu une révélation il y a plusieurs années, en tant que développeur dans une formation en gestion de projet. J'ai vu plusieurs de mes collègues développeurs se dresser contre la direction après la création d'une atmosphère de discussion ouverte (la direction était présente ici). Tout ce qui n'allait pas était de la faute des gestionnaires aux yeux des développeurs. Le coup d'envoi était que la direction n'avait aucune idée de presque tous les problèmes énormes qui avaient été soulevés ce jour-là. Les développeurs supposaient qu'il était si évident que la direction ne l'aurait pas manqué, et supposaient que les développeurs leur diraient ce dont ils ont besoin.

Par conséquent, à mon humble avis, la première partie de la réponse doit être de faire savoir à vos développeurs que vous n’êtes pas psychique, et en fait probablement plutôt stupide quand il s’agit du côté technique. Vous comptez sur eux, vous comptez dessus et vous leur faites confiance pour qu'ils viennent à vous rapidement. Vous êtes là pour leur rendre la vie plus facile, pas plus difficile.

Et quoi que vous fassiez, NE leur posez PAS de questions dont vous ne voulez vraiment pas connaître la réponse - en vous référant aux "estimations erronées" ci-dessus ;-). C'est la kryptonite d'un développeur.

Il y a beaucoup de bonnes choses ici mais je ressens le besoin suivant d'être dit .. ..Désolé d'être dur .. Mais ce besoin d'être dit:

• 5 ans en tant que PM, et ne pas savoir de quel type de PC un développeur a besoin, est scandaleux.
• Demander à un développeur de quitter son poste en raison de mauvaises conditions de travail, ce qui en fait votre premier véritable drapeau rouge, est fou.

Je pense que vous avez un problème de confiance , plus qu’un problème de communication. Personne ne dit ce qui ne va pas car ils ne font pas confiance à ce que vous ferez avec ces informations et craindront même que ces informations ne soient utilisées à leur encontre. Le développeur qui vous a parlé de tous ces problèmes l'a fait parce qu'il n'y avait aucune conséquence, il a arrêté.

Personnellement, je n’engagerais jamais un PM qui n’avait aucune expérience en développement dans son domaine. Je pense que sur votre prochain projet, vous devriez consacrer une petite partie de votre temps à la dev. équipe . Disons 8 heures par semaine, en tant que développeur junior sous la direction de l’équipe.

Cela vous ouvrira vraiment les yeux sur la dynamique d’une équipe de développement, car pour l’instant, vous ne faites même pas partie de cette équipe, vous êtes un outsider. Le fait que votre dev ait arrêté a été un choc pour vous, le prouve. Tout le monde dans l'équipe savait qu'il était malheureux. Et aucun d'entre eux ne vous a dit:

"Nous allons perdre notre meilleur gars si vous ne faites pas quelque chose"

Cela devrait être le drapeau rouge n ° 2.

En tant que directeur, je suis sûr que vous avez entendu parler de kaizen , l'un des principes du système de production Toyota, synonyme d'amélioration continue .

Vous avez admis que vous avez un problème, alors c'est un bon début.

Kaizen a cinq éléments principaux:

• Cercles de qualité : groupes qui se rencontrent pour discuter des niveaux de qualité concernant tous les aspects du fonctionnement d'une entreprise.

• Amélioration du moral : un moral fort parmi la main-d'œuvre est une étape cruciale pour atteindre une efficacité et une productivité à long terme, et kaizen la définit comme une tâche fondamentale pour rester en contact permanent avec le moral des employés.

• Le travail d'équipe : une entreprise forte est une entreprise qui réunit toutes les étapes du processus. Kaizen vise à aider les employés et la direction à se considérer comme membres d’une équipe plutôt que comme concurrents.

• Discipline personnelle : Une équipe ne peut pas réussir sans que chaque membre de l'équipe soit fort en soi. Un engagement de discipline personnelle de chaque employé assure la solidité de l'équipe.

• Suggestions d’amélioration : En demandant à chacun des membres de l’équipe de faire part de ses commentaires, la direction veille à ce que tous les problèmes soient examinés et traités avant qu’ils ne deviennent significatifs.

( Source )

Si vous prenez un long regard, une constante sur ces éléments est l’accent mis sur le travail d’équipe et les retours.

Un exemple, vous dites que vous avez eu un argument au sujet des estimations de temps. Êtes-vous le responsable de ces estimations de temps? Parlez-vous avec l'équipe à ce sujet? Je suis désolé mais j'ai vu des gestionnaires extraire un numéro de leur Une chose cruciale: ne discutez jamais avec le temps que votre équipe vous donne. Beaucoup de managers s'imaginent que s'ils parviennent à respecter des délais plus courts si leur équipe travaille plus fort. Ceci est un mensonge. Neuf femmes ne peuvent pas avoir de bébé en un mois, souvenez-vous-en.

Alors, mon premier conseil:

Écoutez : commencez par envoyer un simple courrier électronique à l'équipe: "Quel est le meilleur moyen pour l'équipe de développement de donner son avis à la direction sur les performances de la direction?". Itérer avec l'équipe et mettre en œuvre le consensus. Votre tâche est de permettre à l’équipe de développer de super logiciels, pas de les rassembler. Garde ça en tête.

Honnêteté et loyauté : Si personne ne répond quand vous demandez quelque chose, c'est parce qu'ils ne croient pas que vous allez écouter ou, pire encore, ils croient que vous allez les punir pour cela. Alors soyez honnête. Si quelqu'un dit que tu crains, prends ça comme un retour et ne te venge pas. Comprenez leurs raisons, améliorez-le.

Enfin, même si j’ai déjà entendu quelques critiques à ce sujet, je vous recommande de lire un livre intitulé The Mythical Man-Month: Essays on Software Engineering . Le livre traite de l'expérience de Fred Brooks chez IBM dans la gestion du développement d'OS / 360. Bien que certaines choses ici et là puissent être obsolètes, il s’agit de la première étape pour comprendre le fonctionnement du processus de développement de logiciels complexes. S.Lott cite le Manifeste Agile , qui ne me passionne pas particulièrement, mais il vaut également la peine d'être lu.

Lis ça:

http://agilemanifesto.org/

• Individus et interactions sur les processus et les outils

• Logiciel de travail sur une documentation complète

• Collaboration client sur négociation de contrat

• Répondre au changement au sujet d'un plan

Dans de nombreux cas, l’ organisation (c’est-à-dire votre patron) vous demande

• suivre un processus clairement brisé jusqu'à sa conclusion logique menant à une "marche de la mort". Cela conduit à des arguments et à des démissions.

• créer une documentation excessive, de faible valeur et non utilisée.

• engager dans le contrôle de changement complexe a / k / a négociation de contrat. Chaque changement d'utilisateur nécessite un rituel élaboré pour "qualifier" et "prioriser" le changement. Vraiment, il s’agit du "gel" - empêcher le changement.

• suivre le plan quelles que soient les conséquences. Certaines organisations accordent de la valeur à la livraison ponctuelle de logiciels défectueux (voire inutiles). C'est le plan qui a de la valeur, pas la solution d'un problème commercial.

Il se peut que le problème ne soit pas vos compétences de communication personnelles.

Il se peut que l’ensemble de «l’environnement» ou de la «méthodologie» du développement soit brisé, et les sentiments négatifs ne sont qu’un symptôme des mauvaises pratiques en général.

Pour moi, cela semble que vous n’ayez jamais parlé aux développeurs dans une atmosphère facile. Vos entretiens avec eux étaient simplement de nature officielle? C'est dommage.

Pourquoi ne les apprenez-vous pas personnellement et apprenez-vous ainsi ce qui est bien et ce qui ne va pas dans l'entreprise, son lieu de travail et ses projets? Respectez-les et méritez leur respect, en manifestant un intérêt sincère et une reconnaissance pour leur travail.

S'ils vous font confiance et qu'ils n'ont pas à craindre les offres de prêt sur gages, ils vous diront probablement même des vérités peu attrayantes.

Je suis un chef d'équipe et mon équipe me fait confiance. Je les protège Je prends tout le blâme et je partage la gloire avec eux. Notre direction me protège. Cela renforce le moral. Nous avions un projet vraiment difficile et un client presque diabolique, presque impossible à terminer, mais nous l'avons finalement fait, car nous parlons de tout d'une manière très franche et ouverte.

Taper! Taper! Taper! Vous devriez certainement être une bonne personne, car vous vous êtes rendu ouvert pour voir ce qui peut être fait pour améliorer votre travail.

Veuillez trouver ci-dessous ce que j'ai vu chez un excellent manager et que j'ai personnellement adopté lorsque je dirigeais l'équipe en tant que membre senior.

• M entor plus que gérer.
• Un des membres de l' équipe llow d'exprimer leurs pensées et leurs préoccupations. Soyez tout ouïe. Prenez les constructifs.
• N ne trahissez jamais les membres de votre équipe en jouant des politiques de division. Cela se déclenche plus tôt et silencieusement.
• Un petit pas. N'ayez jamais de grimaces sur votre visage lorsque vous êtes avec votre équipe, quoi qu'il arrive. Celui-ci est vraiment difficile.
• G enuinely et ouvertement apprécier le gagnant pour sa / son bon travail. De la même manière, très doucement et tactiquement, cisalisez le travail, pas une personne pour aucun tort, à la personne qui en est responsable, isolément et non ouvert.
• E propriété ncourager et de leadership dans chaque individu. Cela renforce le moral et l'engagement de la personne, car elle se sentirait respectée.
• R OAM autour avec votre équipe de temps en temps. Celui-ci induit / augmente la liaison au sein des membres de l'équipe.

Je vous souhaite bonne chance dans votre entreprise sincère :)

En général, les hommes dans les tranchées commencent à se sentir mutinés lorsqu'ils sentent que leurs reproches ne sont pas entendus par des gens qui peuvent et vont arranger les choses. S'ils ne sentent même pas qu'ils peuvent supporter sans risquer de perdre leur place dans l'entreprise, c'est encore pire.

Je suis un gars de théorie-Y, et la plupart des "travailleurs du savoir" ont tendance à l'être; Si nous en avons l'occasion, nous aimons notre travail et voulons bien le faire. Cependant, l’inconvénient d’un lieu de travail de Theory-Y est qu’il n’est peut-être pas immédiatement évident qu’il ya un problème, car les personnes qui veulent bien faire et ne veulent pas faire de vagues vont trouver des moyens de contourner ce problème ou simplement l’ignorer. Cela conduit à une frustration refoulée, qui finit par exploser dans le visage de toute l'équipe. Un magasin géré par un responsable de Theory-X aurait probablement des gars qui se plaignent beaucoup plus tôt; les employés ne sont là que pour l'argent, alors si le travail est pire que d'habitude, ils vont s'en plaindre.

En ce qui concerne ce que vous pouvez faire, dans un environnement avec des personnes âgées et des leaders dans la pièce, ils constituent votre meilleur atout. Parlez-leur. Vous pouvez prévoir 30 minutes par semaine pour un "aller-retour", où les pistes vous fournissent des mises à jour et des inquiétudes non résolues concernant le projet au jour le jour, et vous leur donnez des mises à jour du côté des entreprises et planifiez avec elles la résolution des problèmes. avant qu'ils ne deviennent des problèmes qui affectent sérieusement l'équipe.

Dans Agile, à la fin de chaque "sprint" ou "itération" (unité de travail de développement d’une durée généralement comprise entre une et trois semaines), l’ensemble de l’équipe, des plus jeunes membres jusqu’au PM, dispose d’une "rétrospective". ". Ils regardent ce qu'ils ont fait, ce qui s'est bien passé, ce qui ne s'est pas passé, et identifient les choses à continuer et les choses à changer. Il existe plusieurs formats et vous pouvez en inventer le vôtre, mais le résultat du rétro devrait être que les gens sentent que leur voix a été entendue et que les choses vont changer en conséquence.

Parler d'agile; Mon premier travail a été pour une petite entreprise, et par "petite", je veux dire que toute la société ne pouvait pas mettre en place une équipe de softball. Il y avait quatre programmeurs quand j'ai commencé et ce nombre a été réduit à deux avant mon départ. Le fondateur, président, PDG et actionnaire à 95% de la société l'a dirigée avec une poigne de fer, et il était l'unique source de planification dans l'organisation, ce qui signifiait qu'il n'y en avait pas beaucoup. Le patron était un bourreau de travail et s'attendait à ce que tous les autres le soient aussi; Tout ce que vous deviez donner n’était ni plus ni moins que ses attentes, et pour cela, il payait un salaire de base aux personnes qui travaillaient pour lui depuis une décennie.

J'ai quitté cette entreprise et commencé à travailler pour une autre entreprise qui faisait les choses très différemment. ils ont pratiqué la méthodologie de base SCRUM Agile, avec des relevés quotidiens, une programmation en binôme, des équipes de sprint et des rétrospectives. Une journée toutes les deux semaines au début de chaque sprint, nous n’avons fait que planifier les deux semaines de travail suivantes. Pendant une bonne partie de la journée, nous n'avons rien fait d'autre que regarder en arrière ce que nous avions fait et trouver des moyens de nous améliorer en tant qu'équipe. Il y avait des développeurs assis à côté de moi qui étaient des MVP de Microsoft, faisant le travail, encourageant et complétant ce que je faisais.

Nuit. Et. Journée. La principale différence? Premièrement, je ne pensais pas que je devais me suicider pour le projet; Un principe fondamental de Agile est le rythme de développement durable. Deuxièmement, j'avais une voix dans la décision quant à la manière dont je serais censé faire mon travail. Je devais faire le travail, mais si j'avais «des brûlures d'estomac» à propos de ce que j'allais m'attendre lors du prochain sprint, je pourrais exprimer cet avis qui serait entendu et pris en compte. Si je sentais qu'il y avait un meilleur moyen, je pourrais le dire et ce serait diverti.

En ce qui concerne la recherche de solutions et la résolution de problèmes, vous devez faire attention à ne pas ressembler à un travail de haut en bas. Pour les ordinateurs; Dites que votre RMR (revenu mensuel récurrent) ne permet à la société de mettre à niveau quatre ordinateurs en deux semaines. Les quatre premiers ordinateurs ne doivent pas tous aller aux responsables et aux personnes âgées; ils devraient aller vers les personnes avec les ordinateurs les plus lents. Si vous donnez des bonus à l’équipe, ne les donnez pas simplement à "nos précieux seniors et leads, sans qui cela n’aurait pas été possible"; TOUT LE MONDE dans votre équipe de développeurs y est parvenu. Si un junior a une plainte, écoutez-le; ce n'est pas parce qu'il est junior qu'il ne sait rien.

Améliorer les relations: vous
venez d'avoir un projet difficile? Donnez-leur une pause après. Le temps des vacances pour se détendre, reprendre leur souffle.
Charte des droits des codeurs Ces choses vont de soi . Des choses fondamentales qui devraient aller de soi. Si vous les violez, vous abusez de vos codemonkeys.
Le test de Joel, je suis d'accord avec la plupart d'entre eux. Mais certains dépendent vraiment. Si vous en manquez, vous rendez probablement la vie de vos programmeurs plus difficile alors il le faut.
Dette technique . Vous pouvez donc insister pour que les travaux soient achevés, mais vous devez réaliser qu'en prenant des mesures délicates, vous contractez une dette technique qu'il faudra plus de temps à une date ultérieure pour la réparer. Si cette date arrive AVANT la fin du projet, vous avez vraiment foiré.
RSA animer: MotivationC'est un élément fantastique qui montre vraiment comment motiver les travailleurs du savoir.
Journée libre pour coder ce qu'ils veulent. De la vidéo RSA. Vous ne vous souvenez pas du nom, mais la société mentionnée a une brève explication sur son site. Cela semble être une bonne idée pour moi. Dans la plupart des magasins, tout le monde sait qu’il ya des problèmes, mais personne n’a le temps de les réparer et ce n’est pas une priorité. Cela leur permet de s'attaquer à la dette technique. Cela leur permet également de montrer leurs idées brillantes.

Et pour l'amour de Dieu, essayez de garder une semaine de travail de 40 heures. Aussi, flextime. Flextime peut compenser tout un monde de conneries. Pour moi au moins.

Améliorer la communication entre les programmeurs et les patrons
C'est plus difficile pour moi. Toute cette question de shmoozing est davantage une compétence de chef que l’attention d’un programmeur. Je pourrais dire que certaines choses de base, telles que les estimations de temps, ne sont que des estimations. Marcher sur l'eau et satisfaire aux exigences sont faciles s'ils sont gelés. Peut-être demander aux programmeurs timides de faire une présentation de leur projet lors d'une révision du code ou quelque chose du genre. La pratique rend parfait, toi? Mais je m'inclinerais devant l'avis des autres sur celui-ci.

"De même, si vous le détestez, veuillez décrire en détail pourquoi."
Eh bien, cela va ouvrir les vannes ici. Et si je n'utilisais pas d'openID pouvant évidemment être lié à moi, je m'exprimerais probablement aussi. Si vous voulez vraiment une liste géante de ce qu'il ne faut pas faire, demandez-le sur un forum plus convivial pour la publication anonyme.

J'ai toujours constaté que les gens en général ne vous traiteraient pas mieux que vous ne les traitez (bien qu'ils puissent vous traiter moins bien). Personnellement, je (développeur) répond à l'honnêteté honnêtement, au respect avec respect, à la confiance avec confiance, etc. Vous devriez avoir une discussion informelle avec votre équipe dans une atmosphère neutre et leur dire ce que vous venez de nous dire. Le point que l’on oublie dans les environnements toxiques "nous contre eux" est que tout devrait être "nous". La direction et les travailleurs doivent le savoir et l'entreprise doit le prendre en charge.

Bonne chance.

Vous avez maintenant une expérience confirmée d'accepter non seulement les commentaires, mais également d'agir en conséquence. Vous avez démontré que vous avez de l'influence auprès des décideurs supérieurs et que vous pouvez faire avancer les choses pour votre équipe. Cela fait une grosse différence. Les programmeurs peuvent être plus introvertis, mais nous aimons parler de programmation. Un environnement informel est agréable, mais tout le monde doit rester professionnel. Permettez aux gens de s’exprimer, mais assurez-vous que les discussions sont productives et pas seulement une session de salope.

D'après mon expérience, le facteur le plus important pour que j'aime ou que je n'aime pas mon supérieur est qu'il / elle comprend le développement en général et le travail que je fais. Certains résultats positifs sont énumérés ici:

• Je n'ai pas à perdre trop de temps pour justifier pourquoi un changement prend si longtemps ou ne peut pas être mis en œuvre. Eh bien, techniquement, tout changement peut être mis en œuvre et la direction exige généralement la mise en œuvre de toute façon. Mais au moins dans une telle situation, votre supérieur hiérarchique direct est de votre côté et demande plus de temps (au lieu de vous pousser ou de vous épuiser).
• Je sais que j'ai une meilleure chance d'être pris en charge en cas de mauvaise situation (piratage WTF, problème de production, etc.). Habituellement, les personnes non techniques ont tendance à blâmer le développeur pour une telle situation, tandis qu'un bon gestionnaire COMPREND ce qui se passe réellement et soutient son développeur (pas seulement savoir ou vouloir le prendre pour être gentil).
• Je sais que mon travail et mes performances doivent être évalués par une personne appropriée.

À mon avis, si vous ne programmez plus et généralement dans un calendrier de projet ou un budget serré, vos développeurs auront une chance de ne pas aimer. Si tel est le cas, vous feriez mieux de monter rapidement et d'avoir quelqu'un d'autre pour être le responsable direct. Désolé, j'ai mal paru dans ce paragraphe, mais c'est ce que je vois. Votre semble être une bonne personne et mérite une vérité.

Je suis aussi l'un des types en costume, et ce depuis plus de 15 ans. J'étais développeur de logiciels à mes débuts et j'écris toujours du code lorsque j'en ai l'occasion. Je pense donc pouvoir parler des deux côtés et j'ai un peu d'expérience dans ces situations. J'ai également des références, telles que "Employé de l'année", élues par le personnel, qui me rendent confiant dans la gestion de ces situations.

Je constate très souvent qu'il existe des différences substantielles dans les systèmes de valeurs et les méthodes / approches opérationnelles adoptées par la direction et les développeurs.

Pour beaucoup de développeurs, la sincérité, l’honnêteté et un environnement de travail flexible figurent en bonne place sur la liste. Malheureusement, les mêmes valeurs ne figurent pas très haut dans la liste des cadres supérieurs. Et cela conduit inévitablement à d’énormes conflits, en particulier si les cadres intermédiaires (vous et moi) décidons de prendre complètement le parti de la direction. La seule solution (de mon point de vue) consiste à prendre une position ferme devant votre équipe, à l’appuyer pleinement, à établir une relation de confiance par une communication ouverte et, surtout, à faire ce que vous dites. (ce qui est souvent le contraire de ce que vous obtenez de la part de la direction, où la politique l'emporte sur la sincérité).

Dans le même temps, vous devez vous-même rester opérationnel, vous devez donc trouver un moyen de communiquer avec la direction dans une langue qu'ils comprennent et jouent leur jeu. C'est le véritable défi de l'encadrement intermédiaire.

Je crois qu'avec le bonheur des développeurs, la productivité dépend entièrement des petites choses. Le calcul fonctionne assez bien pour la gestion. Donnez-moi un beignet (-25 cents) le matin et je travaillerai deux fois plus fort toute la journée (+ plusieurs dollars). Ce n’est pas que nous sabations activement les choses en travaillant lentement lorsque nous sommes insatisfaits, c’est que nous travaillons sur des systèmes extrêmement compliqués et il est extrêmement difficile de se concentrer lorsque nous sommes frustrés. Il vaut probablement mieux éviter de coder autant lorsque nous sommes en colère.

Les estimations, cependant, doivent être traitées par elles-mêmes. Chaque problème que je rencontre peut être résolu en me remettant un beignet, à l’exception des estimations peu réalistes . Vrai ou faux, c'est ce que voit un développeur: la direction a tout à gagner (comme un nouveau bateau) à une estimation plus courte, tandis que les développeurs ont tout à perdre (comme dormir un mois). La direction est en charge, alors ils gagnent la guerre des estimations à chaque fois. Je pense que le système d’estimation fonctionne mieux lorsque les développeurs décident de la date limite (c’est assez difficile pour nous de donner une estimation précise, alors comment ferait-on un manager?), Mais la direction les motive à être ambitieux, sachant qu'aucun développeur ne se laisse guider par les chemins de fer être un peu en retrait.

Considérez quel type de réaction donnez-vous à un programmeur qui peut avoir une question, un commentaire ou une préoccupation. Y a-t-il un "Que voulez-vous maintenant ?" ou "Pourquoi me déranges-tu avec ça ?" sorte de réponse? Dans quelle mesure incitez-vous les développeurs à exprimer leurs préoccupations et leurs commentaires? Ce n'est cependant qu'un point de départ.

Deuxièmement, faites attention à l'endroit où vous essayez d'avoir ces discussions. Je doute que je discuterais de ma machine de travail avec quelqu'un du prochain cube si je savais que mon supérieur hiérarchique était à portée de voix. Si vous souhaitez que les personnes donnent des réactions ouvertes et honnêtes, vous devez protéger votre vie privée en sachant que leurs réponses ne seront ni diffusées publiquement ni utilisées à leur encontre.

Troisièmement, réfléchissez au type de compétences en intelligence émotionnelle que vous possédez. Intelligence émotionnelle pour les gestionnaires de projet: les compétences interpersonnelles dont vous avez besoin pour obtenir des résultats exceptionnels par Anthony Mersino seraient une recommandation de livre que j'ai obtenue hier d'un déjeuner-causerie sur le QE. Si vous voulez vraiment vous plonger dans la psychologie, vous pouvez utiliser différents outils de profil de personnalité, tels que Ennéagramme, styles sociaux et MBTI.

Enfin, considérez quelle est la culture de votre entreprise. Y a-t-il des erreurs sous le tapis? Les plaintes sont-elles un gros non-non qui pourrait facilement causer des problèmes à quelqu'un? Quels comportements sont récompensés ou encouragés et lesquels sont tolérés et acceptés? Bien que ce soit en partie une observation, certaines peuvent également nécessiter des conversations qui doivent être tenues soit loin du bureau, soit dans une pièce où il n’ya pas de risque d’espionnage. Vous allez probablement être répétitif en essayant de l'utiliser au début. Ce n’est pas une mauvaise chose si vous essayez d’établir une nouvelle pratique et de convaincre les gens de s’exprimer si la culture est avant tout une culture dans laquelle tout le monde sait qu’il faut "aspirer". C’est peut-être plus délicat que d’autres réponses, mais c’est ce que je

Les développeurs ont-ils le sentiment que vous êtes leur avocat? J'entends par là qu'ils savent qu'ils sont libres de partager avec vous leurs préoccupations / frustrations sans se faire tabasser? Est-ce qu'ils sentent que vous vous battez pour eux? Ont-ils l'impression que vous appréciez leur travail? Est-ce qu'ils sentent que vous voulez vraiment qu'ils réussissent dans leur carrière?

S'ils se sentent appréciés, vous aurez probablement une meilleure communication.

En tant que développeur, je suis un grand nerd et je manque de compétences sociales et je ne m'en excuse pas. Après tout, je suis le talent et vous m'avez engagé pour mon talent. Si vous aviez besoin de social papillon pour faire le travail, vous auriez une salle remplie de gestionnaires de projets plutôt que de développeurs.

Je sais que certains développeurs sont très astucieux sur le plan social, mais je pense que la médiane penche vers le nerd introverti.

Quand quelqu'un me demande de faire quelque chose, je ne fais absolument aucune déduction et EXACTEMENT ce qui est demandé. Il semble que certains chefs de projet me posent toujours des problèmes, car ils attendent de moi que je fasse des déductions sur leur projet, ce que je ne ferai absolument pas. Par conséquent, parfois, les choses ne se passent pas comme prévu, même si elles s'avèrent être exactement ce qu'elles sont. ils ont demandé. Je pense que la raison pour laquelle certains chefs de projet se retrouvent ici est qu’ils ne fournissent pas de fichiers de haute qualité ni de DRB de grande qualité et qu’ils accordent trop de valeur à l’aspect social de la gestion de projet plutôt qu’en noir et blanc.

Je pense que c'est là que les mondes se rencontrent. Je pense que dans le monde de la gestion de projet, les compétences sociales et la qualité de la franchise personnelle sont des facteurs importants, mais pour les développeurs comme moi, cela ne signifie absolument rien. Cela ne m'impressionne pas de constater à quel point telle ou telle tâche est importante. Je ne veux même pas sortir pour le déjeuner ou des bières comme l'ont suggéré certaines personnes ici.

Ce que je veux vraiment, ce sont de bons HLD et BRD de haute qualité. Je veux des calendriers et des échéances réalisables, et si de nouvelles conceptions ou de nouveaux plans sont introduits, je souhaite que le calendrier et les échéances soient réajustés. J'ai travaillé sur des projets où les exigences semblent changer rapidement. Pour moi, c'est un signe alarmant que je suis confronté à un leadership de projet de qualité médiocre. En tant que développeur, la pire chose à faire est de me présenter quotidiennement les nouvelles exigences du projet, surtout après que nous ayons déjà établi un calendrier ou que nous ayons pris des engagements. C'est intolérable lorsque de nouvelles exigences sont introduites, sans compensation des délais. Travailler plus d'heures, travailler tard, cela ne me pose pas de problème, mais ce n'est pas toujours quelque chose de quantitatif avec le développement. Certains changements peuvent prendre quelques heures de plus, Certains changements peuvent prendre des semaines pour que la recherche et le développement, les tests, l'assurance qualité, etc., soient corrects. Ce n'est pas toujours comme de faire un gâteau, parfois, un simple changement des exigences peut ressembler à changer toute la recette. J'ai vu des chefs de projet se mélanger et faire des crises de panique lors des téléconférences, car leurs délais ne permettraient pas un développement supplémentaire, mais ils demandent un développement qui ne figurait pas dans les exigences initiales de leur projet.

Je ne peux que donner mon exemple personnel et mon expérience personnelle à titre d'exemple, veuillez donc ne pas en déduire que je parle au nom de tous les développeurs. Je ne vois ces choses que dans le microcosme de ma propre carrière, mais cet article décrit les conditions exactes qui m'ont amené à jeter l'éponge.

À quelle fréquence parlez-vous à vos développeurs? Je ne parle pas des réunions sur l'état des projets, des questions sur les produits livrables ou d'autres sujets que vous leur apportez: à quelle fréquence rencontrez-vous l'un de vos programmeurs, demandez-vous comment les choses se passent et écoutez-le ?

Beaucoup d'autres réponses sont vraiment bonnes - vous devriez vous pencher sur le développement agile. Vous avez besoin que vos développeurs apprennent et grandissent dans leurs rôles. Mais si vous n'écoutez pas réellement ce que vos développeurs disent (ou ne disent pas!), Vous devez alors vous en occuper en premier.

Bonne référence sur les rencontres individuelles - http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html

Court et doux. Excel à ce que vous faites - cela va engendrer une communication.

Que signifie exceller pour vos développeurs? .. Lire, relire, oui même étudier PeopleWare

Toutes les bonnes idées et commentaires dans les posts ci-dessus!

Voici une idée: envoyez votre personnel informatique à des ateliers de communication dans votre collège communautaire local - à la charge de l'entreprise, bien sûr.

Assurez-vous a) que les ateliers ont une bonne réputation et b) de ne pas envoyer vos employés ensemble. Ils auront tendance à rester unis et à ne pas se mêler aux autres membres du groupe, non seulement en réduisant la valeur des ateliers, mais en perturbant les autres.

La communication productive en équipe est une compétence que n'importe qui peut apprendre, mais c'est un sujet qui manque selon moi dans la plupart des parcours scolaires.

Cette idée n’est en aucun cas une solution miracle, mais c’est une bonne pièce de base du puzzle. Non seulement vos collaborateurs apprendront-ils à mieux communiquer entre eux, mais le bonus sera qu'ils commenceront à mieux comprendre et respecter VOTRE travail (la communication étant au cœur de la gestion de la performance).

Juste mes 2 bits :)

Juste pour donner une réponse à une recommandation qui a été soulevée dans quelques réponses déjà. Michael Lopp (aka rands ) a été écrit au sujet de la gestion des développeurs et « obtenir dans leur tête » sur son blog, Rands au repos , et dans un livre, Gestion Humains ( sources de livres ). Le livre contient principalement du contenu édité de ses articles antérieurs à 2007 et constitue un bon moyen de se familiariser avec les parties relatives à la gestion de son blog (il parle également du jeu, par exemple, et de la question de savoir si vous voulez lire cela, cela est une autre affaire). Son écriture est généralement excellente et souvent humoristique. Il est donc peu risqué de le lire.

Emmenez l'équipe chercher de la bière (et vous achetez).

Je suis en retard à la fête, mais je viens de voir cette question.

Une chose que je ne vois pas très bien adressée est la suivante:

Les grognements ne disent jamais toute la vérité aux costumes. Rands dit cela dans l' ADN mais ne l'aborde pas de front, il aborde un sujet différent.

Vous portez un costume et vous signez les chèques. Vous représentez les intérêts de l'entreprise. Vous ne représentez pas les ingénieurs. Si vous le faisiez, vous ne signeriez pas leurs chèques, ils signeraient les vôtres.

Ce n'est bien sûr pas une nouvelle pour vous ni pour les ingénieurs. Mais quand un ingénieur sait que soulever certaines questions - des problèmes - avec son lieu de travail causerait un conflit important - le compromis risque / récompense ne favorise pas l'ingénieur. Les ingénieurs sont payés pour produire des produits et non pour déclencher des combats de cultures. S'engager dans ceux-ci est une voie rapide pour faire le travail mal.

Une partie de la tâche de gestion consiste donc à donner aux ingénieurs un moyen d’être ouverts aux problèmes, sans encourir de politique d’entreprise ni de revirements de carrière. Après tout, c'est bien d'avoir des augmentations. Il y a d' autres entreprises, si celle-ci ne vous semble pas sympathique.

Je suis surpris que personne n'ait mentionné ce grand livre qui traite précisément de votre question et de votre sujet - "Peopleware: Projets et équipes productifs" de DeMarco et Lister . De l'éditorial: les principaux problèmes de développement logiciel sont humains, pas techniques . Les trois premières critiques sur amazon me suffiraient facilement pour me convaincre d'acheter ce livre si j'étais dans votre situation.

Beaucoup de réponses ici ont de très bons points, mais je voudrais juste ajouter quelques ressources qui pourraient aider. Je me suis trouvé dans quelques situations qui se sont soit écroulées dans un gâchis gigantesque, soit ont été résolues très efficacement grâce à la communication entre les personnes impliquées. Trois livres m'ont permis d'améliorer personnellement mes compétences en communication, en particulier dans les situations de stress élevé où il y a beaucoup de choses en ligne:

• Conversations difficiles: comment discuter de ce qui compte le plus
• Conversations cruciales: des outils pour parler lorsque les enjeux sont élevés
• Confrontations cruciales: des outils pour résoudre les promesses non tenues, les attentes non respectées et les mauvais comportements

En lisant votre question, je pense que vous voyez la valeur de la communication. Personnellement, j'estime que la communication est plus importante pour un gestionnaire ou un dirigeant que les compétences commerciales ou techniques. Les personnes que vous dirigez doivent avoir les compétences techniques dont vous avez besoin pour mener à bien la majorité du projet. Un bon responsable technique ou un bon chef de projet devrait être capable de se concentrer sur la communication, que ce soit au sein de l’équipe, entre l’équipe et le client, ou entre l’équipe et l’entité commerciale (ou même une combinaison des trois).

Lisez quelques superbes romans qui donnent un aperçu des perspectives du personnel technique:

• Les pirates, Steven Levy - http://en.wikipedia.org/wiki/Steven_Levy
• Microserfs, Douglas Coupland - http://en.wikipedia.org/wiki/Douglas_Coupland
• La cathédrale et le bazar, Eric Raymond - http://fr.wikipedia.org/wiki/Cathedral_and_the_Bazaar

Celles-ci sont aussi importantes que n'importe quel mémoire typique sur la gestion (Drucker et al).

J'ai occupé divers rôles au cours de nombreuses années: développeur, développeur principal, responsable technique, etc.

D'après votre question, il est bien évident que vos développeurs ne vous disent pas des choses parce qu'ils ne pensent pas que vous pouvez aider.

Cela peut être dû à 2 raisons.

1. Ils ne pensent pas que vous ayez le pouvoir de réparer les choses. Cependant, je pense que cela est peu probable car vous le sauriez probablement et les développeurs vous en auraient gémi.
2. Vous êtes le genre de personne qui, lorsqu'un développeur vient à vous avec un problème, fait l'une ou plusieurs des choses suivantes
   • Quand ils viennent à vous avec des problèmes, vous leur dites - J'aime les solutions, pas les problèmes.
   • Vous les écoutez bien et leur demandez ensuite de résoudre le problème. Vous leur donnez un discours encourageant sur l'honneur de leur donner la responsabilité de résoudre le problème. Au fil du temps, vos gars comprennent que lorsqu'ils vous abordent avec un problème, ils se retrouvent avec un travail supplémentaire, de sorte qu'ils ne vous posent pas de problèmes.
   • Vous niez que c'est un problème. Vous en donnez des raisons convaincantes. Mais comme cela continue, avec le temps, vos gars apprennent qu'il est inutile de vous aborder avec un problème.
   • Vous dites "Oui, je comprends". Vous dites que ce genre de choses arrive de temps en temps et qu'il n'y a rien que l'on puisse faire. Si ceci est un motif, alors encore une fois, vos gars le comprennent.

S'il s'agit de l'un ou de l'ensemble des éléments ci-dessus, vous devez y remédier.

Ce que je déteste le plus, ce sont les gens qui s’interposent entre moi, le développeur et l’utilisateur final. Les meilleurs gestionnaires me le permettent et modifient notre solution en fonction de ce que l'utilisateur pense ou souhaite faire avec.

La pire pratique à mes yeux est souvent de se déguiser en "bonne" - le responsable a généralement lui-même, ou un BA ou une autre personne, rédige des spécifications que les développeurs doivent interpréter et mettre en œuvre, avec des délais convenus à l'avance.

Si c'est une solution personnalisée, même souvent les développeurs ne savent pas combien de temps cela va prendre et généralement, le client n'a aucune idée de ce qui est le mieux pour eux. C'est pourquoi le développement itératif est excellent. N’est-ce pas la façon dont la plupart des transactions sont conclues alors qu’un bon manager se battra pour fonctionner comme ci-dessus.

Enfin, certains développeurs ne sont pas bons en communication et ne peuvent pas se rapporter aux clients. Ils conviennent peut-être mieux aux problèmes d’exigences claires, en particulier d’exigences techniques claires. Peut-être avez-vous besoin de développeurs qui communiquent mieux et veulent travailler pour résoudre des problèmes commerciaux et non purement techniques.

Il est très facile de garder l'équipe heureuse

Essayez de les écouter maintes fois, leur question contient également des réponses. J'encourage les membres de l'équipe à venir avec des problèmes et la solution probable.

La sortie en équipe est une bonne idée (peut-être un plan de match)

si votre projet nécessite des travaux tard le soir et le week-end et que vous pensez que vous n’ajoutez pas beaucoup de valeur à l’équipe, ce serait une bonne idée de venir un moment avec quelque chose à manger et d’apprécier l’équipe pour ses efforts et si possible. arranger un peu de PTO

faire un bimestriel 1: 1 avec chaque membre de l'équipe pour s'assurer qu'ils sont à l'aise.

Dernier point, mais non des moindres, il serait peut-être bon que vous compreniez le projet d'un point de vue fonctionnel et technique.

S'il vous plaît laissez-moi savoir si vous avez plus de question

Je suis aussi (français, pardonnez mon anglais) de responsable logiciel ayant une formation en ingénierie scientifique mais pas spécifiquement en informatique. Je n'ai donc aucune affinité particulière avec le codage au début, mais j'ai été un ingénieur en statistiques de l'école de Deming, qui enseigne de manière très différente dans toutes les écoles "modernes" qui ont suivi, bien qu'elles prétendent hériter de Deming. Le pire est 6 sigma, maigre était mieux, mais malheureusement, ce qui s'est passé est la suivante : http://leanandkanban.wordpress.com/2011/05/13/what-did-deming-really-say :

«À l'origine, Six Sigma était dérivé de Toyota Quality Management (TQM) de Toyota pour atteindre six niveaux de qualité sigma. Puis, avec Allied Signal et GE, il s'est transformé en projet de Black Belts basé sur des statistiques pour devenir un programme de réduction des coûts - chaque projet a besoin d'un retour sur investissement clair. En d'autres termes, nous avons dénigré le programme d'une philosophie de leadership à un ensemble de projets ponctuels visant à réduire les coûts. C'était une complète bastardisation de l'original, et cela conduisait rarement à un changement durable, car le leadership et la culture manquaient.

«Une chose similaire s’est imposée lorsqu’elle a été réduite à une boîte à outils (par exemple, la cartographie des flux de valeur, les panneaux KPI, les cellules, le kanban).

«Lean et Six Sigma ne reflètent en aucun cas la pensée originale d'excellentes entreprises japonaises ou de leurs professeurs comme Deming.»

Aujourd'hui, le mouvement Agile est maigre (voir le cours Jeff Sutherland et son hommage à Deming http://blogs.forbes.com/stevedenning/2011/05/27/jeff-sutherland-the-21st-century-will-be-the -century-of-scrum / ), c’est mieux que Waterfall mais c’est encore très loin de l’enseignement original de Deming car au lieu de lire Deming dans son texte original, les gourous le reconditionnent à peu près sans jamais citer ses 14 principes de gestion, et vend des outils et des séminaires qui ont peu de valeur par eux-mêmes.

Maintenant, s’agissant du logiciel, le problème est qu’il ya des gens qui connaissent les principes généraux mais ne savent pas vraiment comment les appliquer, et ceux qui écrivent des logiciels ignorent les principes parce qu’ils écoutent de faux gourous qui leur ont vendu des outils sans leur dire les vrais principes et ils devraient en fait créer leurs propres outils de gestion.

Donc, pour moi, le chef de projet logiciel devrait s’efforcer d’approfondir l’opérationnalité quotidienne du codage logiciel, ne se limitant pas à la planification dans Microsoft Project (ou à un graphique avec Agile) ou à une présentation attrayante dans Powerpoint à la haute direction, mais ayant également des valeurs pour l'équipe de développement. Lorsque l'équipe de développement a des problèmes, même s'il s'agit de problèmes techniques, le chef de projet peut vous aider à orienter le diagnostic de manière externe. Il peut consulter le code, même s’il ne comprend pas le moindre détail, il peut poser des questions naïves qui peuvent amener les développeurs à se rendre compte qu’ils n’ont pas pensé à cet indice (j’ai de nombreux exemples personnels mais c’est trop long donc écrivez plutôt un article sur mon blog).

Une autre chose est que j'essaie d'avoir une conscience générale de l'évolution du domaine, comme de nouveaux cadres, de nouveaux paradigmes d'architecture en lisant des articles techniques. Je participerai à quelques tests d'intégration, rédigerai moi-même des documentations (des choses que les programmeurs détestent, donc je les ferais pour eux, ils me nourriraient bien sûr avec le noyau), tout ce que je suis capable de faire pratiquement pour aider l'équipe.

En général, les développeurs ont l’impression de travailler dur, et c’est vrai, je leur dis souvent que je fais la partie facile en restant dans l’abstraction. Néanmoins, j’essaie d’aider concrètement lorsque cela est nécessaire - parce que la micro-gestion Ce n’est pas bon non plus, car cela peut générer des sentiments d’interférence.

En conclusion: éliminez les slogans avec les développeurs (c'est en fait l'un des 14 principes de Deming), montrez-leur que vous vous souciez du logiciel concret du projet, pas des documents ou de votre réunion avec la haute direction uniquement.