Arrêtez cette folie avant qu'elle ne commence.

Lorsque votre patron a un problème urgent qui doit être réglé "par tout le monde", convoquez une réunion.

Discutez du problème de manière rationnelle, travaillez ce qu'il faut faire, trouvez les ressources dont vous avez besoin pour y arriver et mettez ce plan en action.

Arrêtez de paniquer, commencez à planifier. Faites-le correctement, par le bon nombre de personnes.

N'hésitez pas à faire participer votre patron à la réunion et à démontrer que «tous les intervenants sur le pont» ne sont pas toujours appropriés - vous avez besoin les bonnes mains sur le pont ".

Vous vous retrouvez alors avec une équipe unie travaillant sur le problème de la manière la plus optimale / efficace. Quiconque n'a pas besoin de travailler sur une tâche déjà entièrement (et efficacement) dotée de ressources peut travailler sur autre chose (idéalement se préparer à une tâche ultérieure (ou choc / horreur, création / exécution d'un plan de test)). Quoi qu'il en soit, si le patron atterrit sur le bureau de quelqu'un et demande pourquoi il ne martèle pas fébrilement du code dans Visual Studio, il aura la réponse appropriée.

Parfois, vous pourriez avoir besoin que tout le monde travaille sur un problème , mais parce que vous avez planifié les choses, tout le monde sait ce qu'il fait, pourquoi et quand.

Lorsque la panique est terminée et que le problème est résolu, essayez de comprendre ce qui s'est passé qui a provoqué la panique situation en premier lieu et mettre en place un processus pour atténuer les paniques futures. Il est probable que vous découvriez la cause première lors de vos enquêtes initiales, mais un processus post-mortem démontre une approche proactive pour éviter les problèmes.

En règle générale, les propriétaires ne changent pas. Si les bonnes choses à propos du travail ne compensent pas cela, vous devez partir.

Si vous restez, une approche qui a fonctionné pour moi avec un tel propriétaire est de l'ignorer. Faire ce qui te semble le mieux. Cela ne fonctionne que si vous savez vraiment ce qui est le mieux et que vous pouvez lui montrer les résultats plus rapidement qu'il ne peut découvrir ce que vous faites et être agacé. Cela fonctionne particulièrement bien pour les propriétaires avec une courte durée d'attention. Cela ne fonctionne pas bien lorsque le propriétaire connaît les détails de ce sur quoi vous travaillez tout le temps car vous n'avez pas le temps d'arriver à un résultat que vous pouvez montrer.

Si vous partez , trouvez un joli mensonge blanc pour expliquer pourquoi vous partez. Il sera encore moins réceptif à ce que vous devrez lui dire lorsque vous arrêterez.

Soutenez-le. Et être vu comme le faisant.

Ne jamais en parler en public et être vu comme ne le faisant pas.

On dirait que votre patron a peur. Alors faites-lui peur.

Je suis développeur depuis plus de 20 ans. J'ai été manager de grandes et petites équipes (et entre les deux). J'ai investi mon propre argent dans des projets et je peux voir le sentiment. Ça va comme ça.

• Je suis occupé et (peut-être même) sur le point de faire faillite et je suis trop stressé
• Je ne sais pas exactement quoi mon équipe fait pour moi, s'ils partent, je suis bourré
• J'ai des clients / utilisateurs qui disent des trucs et je dois parler de taureaux ** t sur mes pieds et je déteste ça
• Mon équipe a l'impression de s'éloigner de moi

MODIFIER: inclure la citation d'un commentaire OP auxiliaire

  La plupart Récemment, c'était parce qu'il affirmait qu'un menu dans un système que nous avons réécrit manquait de toutes les options du système d'origine. Je n'ai rien à voir avec le développement du menu, mais les deux développeurs qui ont insisté sur le fait que ce n'est tout simplement pas vrai. Et le propriétaire n'a pas encore, à ma connaissance, omis de nous fournir un exemple d'élément manquant dans ce nouveau menu. Il a juste été comme "les éléments de menu manquent."  

EG: le menu qui manquait à des choses. Il est tout à fait possible que le menu soit CORRECT du point de vue des développeurs "techniquement" utilisable mais il est ÉGALEMENT tout à fait possible que de nombreux utilisateurs aient mal compris et détesté pourquoi une fonctionnalité intuitive VRAIMENT UTILE du menu original de l'interface utilisateur a été supprimée. Cela s'est produit avec Windows8. Cela peut vous arriver. Trop de concentration sur le contenu réactif ou l'interoptabilité de l'interface utilisateur / écran tactile / clavier (par exemple: sauter avec une touche [pressions, expansion automatique, montrant clairement où l'expansion automatique peut se produire) très souvent les développeurs sont tellement pressés d'obtenir un «look» ou une «fonctionnalité» qu'ils oublient que ces choses sont utilisées par les humains.

et ne pensez pas que ce genre de chose dont je parle est trivial pour les utilisateurs. ils détestent très souvent les «nouvelles fonctionnalités» qui cassent une chose sur laquelle ils comptaient.

Le moyen d'éviter que votre patron ne panique tout le temps est de lui redonner confiance. Soutenez-le quoi qu'il arrive. N'ayez pas de réunions qui supplantent son autorité. Parlez en bien de lui. Laissez-le se tromper, faites-lui savoir un à un. Soutenez-le quand même. laissez-le sentir que vous le soutenez et dites-lui quel bon travail il fait. Je pense que c'est bien que vous soyez venu en ligne pour parler de ce genre de choses, car le faire dans un bureau peut être la pire des choses à faire.

Je dis tout cela parce que, en fin de compte, vous êtes la seule chose que vous pouvez contrôler . Et si vous suivez mon conseil (et le pratiquez!), Le pire qui puisse arriver est que vous devenez un employé tellement incroyable que vous serez d'une valeur inimaginable tout au long de votre carrière . le mieux qui puisse arriver est que vous changez d'avis les patrons sur la panique.

Ma suggestion est quelque peu différente de celle de Snow: rencontrer le propriétaire 1: 1 au moment où il n'y a pas de crise. Sortir pour un déjeuner ou un café avec lui peut être une bonne idée. Ensuite, dites-lui à peu près ce que vous avez écrit ici et essayez de le rendre aussi non personnel et non accusatoire que possible: faites comprendre au propriétaire que les appels «tous mains» sont mauvais pour les affaires.

Avec un peu de chance, le propriétaire est une personne raisonnable et comprendra votre point. Sinon, il est temps de chercher un autre emploi.

La réponse courte à cela est que vous avez besoin d'une sorte de fonction de gestion de produit plus formelle dans votre boutique.

L'objectif principal de cette fonction est de définir, comprendre et maintenir un backlog de travail priorisé pour l'équipe d'exécution. Cela permet à l'équipe d'exécution de revoir en permanence le travail devant elle et de prendre de bonnes décisions sur la manière générale de gérer les choses, qui et combien de personnes mettre sur une zone de travail donnée, et d'autres aspects pour maintenir une production stable sans trop de contexte. commutateurs et autres.

Deuxièmement, il est utile d'avoir quelqu'un dans un rôle de type gestion de projet qui fasse les choses ci-dessus pour l'équipe d'exécution. Idéalement, ce n'est pas la même personne qui s'occupe de la gestion des produits, de sorte que vous puissiez séparer les conflits d'intérêts entre l'urgence perçue et l'efficacité de l'équipe à plus long terme.

Dans une petite entreprise, il n'est pas nécessaire que ce soit des personnes dévouées. chaque rôle. Ce qu'il faut, c'est une compréhension claire de qui fournit quoi au flux et quand. Par exemple, votre patron, dans ce cas, sonne comme le propriétaire clair du produit et dirigera la fonction de gestion de produit. Qu'il fasse la majeure partie du travail lui-même, ou délègue le travail de détail et assure simplement la supervision et la hiérarchisation, vous devez tous travailler en fonction de votre situation unique en tant qu'entreprise. Une autre personne, généralement l'un des développeurs les plus expérimentés et / ou les plus organisés, peut assumer le rôle de chef de projet. Cette personne passerait une partie de son temps à traiter le travail entrant et à s'assurer qu'il est correctement réparti, qu'il ne s'ensuit pas de raclée et qu'il y a une communication de retour avec la fonction Produit sur les impacts sur les coûts d'une trop grande redéfinition des priorités.

J'ai essayé d'énoncer ces choses de manière aussi générique que possible sans spécifier de méthodologie. De toute évidence, il existe des saveurs d'Agile, de la bonne cascade à l'ancienne et un grand nombre d'approches moins connues pour vous donner des directives éprouvées sur la façon de travailler dans l'une d'entre elles. D'après ce que vous avez décrit, avec de fréquents changements de direction urgents et à court terme, opter pour une version simple de Scrum serait un bon point de départ. À partir de là, vous pouvez évaluer son fonctionnement et l'adapter aux besoins de votre entreprise. Si vous n'avez personne à bord avec au moins une certaine expérience Scrum pour agir en tant que coach, alors c'est un problème distinct qui a probablement déjà beaucoup de bonnes questions et réponses ici.

S'il n'y a pas de structure de commande entre vous et le propriétaire, il doit vraiment y en avoir.

Vous avez besoin de quelqu'un pour gérer les développeurs, et c'est à qui le propriétaire doit parler. C'est alors le travail de ce manager de répartir le travail et de résoudre le problème.

Il n'est même pas nécessaire d'être une nouvelle personne. Je suis manager, mais aussi développeur actif dans l'équipe. Le travail me vient, je le partage et coordonne l'effort. Parce que je travaille aussi activement sur les projets, je comprends l'ampleur et les problèmes, permettant à tous ceux qui n'ont pas besoin de continuer avec leurs activités BAU.

Le problème mythique du mois homme consiste à ajouter des personnes à une équipe existante lorsque le temps presse. au lieu d'accélérer les choses, vous passez du temps à mettre les nouvelles personnes au courant et augmentez généralement la charge de communication.

cela ne s'applique pas ici. vous êtes déjà une équipe et la composition de l'équipe ne change pas. vous êtes juste confronté à un nouveau problème / tâche pour cette même équipe.

ce que votre patron demande ressemble beaucoup à de la programmation mob.

https: // fr.wikipedia.org/wiki/Mob_programming

d'autres équipes ont trouvé un moyen d'être productif avec cette méthode, donc au lieu d'essayer de la changer, je profiterais de la situation, et trouver un moyen d'en tirer le meilleur parti

Faire travailler les développeurs sur des tâches et du code avec lesquels ils ne sont pas familiers est extrêmement inefficace. Amener les développeurs à changer de tâche est extrêmement inefficace en raison du réajustement mental nécessaire qui n'est généralement pas pris en compte dans ces types de conditions.

Comment pouvez-vous amener votre patron à comprendre cela? Cela dépend de votre relation avec votre patron et de quel type de patron il s'agit. Votre patron a-t-il démontré une volonté d'écouter les développeurs dans le passé? Êtes-vous en règle avec votre patron? Êtes-vous respecté par votre patron? Votre patron est-il relativement sans stress? Moins vous répondez "oui" à ces réponses, plus il sera difficile d'apporter un quelconque changement positif.

Dans mon dernier travail, on nous a dit le matin d'un jour particulier que le nombre de les tickets d’aide étaient trop élevés et que nous devions tous fermer 8 à la fin de la journée. Chacun de nous a eu du mal, et nous avons en moyenne 3 billets fermés chacun, ce qui, avec le recul, a été un effort incroyable, mais qui n'a pas été apprécié. Cependant, je ne peux pas parler de la qualité des solutions qui ont été mises en place pour ces problèmes.

En gros, ce qui s'est passé dans votre situation et la mienne est que le patron a paniqué et a essayé de résoudre un problème en lançant plus ressources à elle. Oui, ce serait formidable si tous nos patrons lisaient, comprenaient et étaient d'accord avec The Mythical Man-Month. Cependant, dans mon cas, je savais que cela n'arriverait jamais. J'espère que votre situation est meilleure que la mienne.

La seule chance que je puisse imaginer est de faire un post-mortem sur l'un de ces moments. Cela s'est-il déroulé comme prévu par votre patron? Est-ce que c'était bon pour l'entreprise ou cela a-t-il simplement fait perdre beaucoup de temps et d'argent? Quelles leçons peut-on en tirer? (ici, vous pouvez guider subtilement la réflexion de votre patron afin qu'il parvienne aux mêmes conclusions que The Mythical Man-Month sans le lire.) par exemple

• Nous avons essayé de travailler sur la tâche A, mais seule Alice sait comment cela fonctionne, elle a donc dû passer la moitié de la journée à l'expliquer à toute l'équipe. Nous avons effectivement perdu 2,5 jours de travail en équipe (la même chose que d'avoir un développeur malade pendant 2,5 jours). Que pensez-vous que nous devrions faire la prochaine fois?
• Nous avons trouvé qu'il était vraiment difficile de coordonner car nous avions tellement de personnes travaillant sur la même tâche en même temps (fournissez une estimation du temps moyen perdu par personne membre de l'équipe, puis multipliez-le par la taille de l'équipe). Que pensez-vous que nous devrions faire la prochaine fois?
• Mon délai pour la tâche importante B a été repoussé d'un jour et demi car j'ai passé une journée sur la tâche A et il m'a fallu une demi-journée pour retournez dans le flux de la tâche importante B (fournissez uniquement des chiffres véridiques). Je ne suis plus sûr de pouvoir le terminer à temps. Que pensez-vous que nous devrions faire la prochaine fois?
• Deux développeurs n'ont pas du tout été en mesure de contribuer car ils n'ont pas assez d'expérience avec la technologie C. L'équipe a perdu 2 jours ouvrables en les empêchant de contribuer tâche A. Que pensez-vous que nous devrions faire la prochaine fois?

Ce qui est génial avec cette approche, c'est que vous communiquez clairement vos problèmes, sans avoir l'air de dire à votre patron ce qu'il doit faire . Cela leur en renvoie la responsabilité, car cela n’a jamais été la vôtre en premier lieu ! Espérons qu'ils commenceront à se rendre compte des dommages causés et de la façon dont ils affectent les résultats. Dans (presque) n'importe quel argument commercial, l'argent gagne! S'ils trouvent une idée de manière indépendante, ils sont plus susceptibles de la mettre en œuvre, indépendamment du fait que la même idée se trouve exactement dans un livre vieux de 30 ou 40 ans.

Si vous avez vraiment, vraiment, de la chance, après que cela s'est bien passé à plusieurs reprises, vous pouvez dire: "Hé patron! Devinez quoi? J'ai trouvé ce livre qui est en accord avec les changements que vous avez mis en place et suggère encore plus dans le même sens! " Peut-être qu'ils le liront, mais les patrons sont généralement des gens occupés, donc il est peu probable qu'un patron sans habitude de lecture existante le lise. Ils pourraient cependant vous demander ce qu'il dit d'autre.

Assurez-vous d'abord de vos faits. Étant donné une tâche apparemment indivisible, êtes-vous sûr qu'elle est indivisible? Peut-être pas cinq façons, mais peut-être deux ou trois? S'il s'agit d'une tâche de programmation, vous devriez créer des tests unitaires, qui n'ont pas besoin d'être (ou ne devraient pas du tout être) effectués par le codeur principal. Parfois, les tâches de programmation qui semblent indivisibles en surface peuvent être divisées au moins un peu plus finement. Oui, il y a une limite, et oui, il y aura des rendements décroissants car l'effort de coordonner le travail enlève le travail productif réel, mais si cela raccourcit le temps global jusqu'à l'achèvement, vous avez au moins rencontré l'esprit de votre patron.

Comme indiqué dans une autre réponse, ce serait bien si tous ceux qui ont un lien avec un effort de développement logiciel (chefs d'équipe, chefs de projet, superviseurs, etc.) ont tous lu et adhéré à "The Mois de l'homme mythique ". Peut-être qu'à un moment donné, quand il n'y a pas de pression sur les délais et que les choses tournent bien, vous pourriez trouver un moyen de présenter le livre à votre patron. "Hé, j'ai trouvé cette lecture vraiment fascinante ...".

Ma suggestion est de ne rien lui dire. Après tout, il possède une entreprise et vous n'en avez pas. Il en sait probablement plus sur la gestion d'une entreprise que vous. Si vous en savez vraiment plus sur la gestion de l'entreprise que lui, vous devriez peut-être diriger votre propre entreprise au lieu de travailler pour lui. Cela ne veut pas dire qu'il n'y a pas d'inefficacité dans la façon dont il aborde le problème, mais il y a probablement des avantages que vous ne voyez pas et le propriétaire de l'entreprise sait probablement que ces inefficacités existent et il estime toujours que cela en vaut la peine. impliquer tout le monde. Je pense que c'est une forme de supériorité illusoire de penser que votre suggestion est la meilleure approche.