Arrêter les discussions techniques sans fin et prendre une décision

Je rencontre toujours des gens qui aiment cogner depuis des lustres sur les plus petites "choses techniques".

Ne vous méprenez pas, je suis un programmeur geek qui aime ce que je fais, mais vous savez le type de conversation.

• Mac est tellement mieux que Windows
• N'utilisez pas de boucle For Each, utilisez une boucle While
• N'achetez pas un PC basé sur Intel, achetez-en un basé sur AMD.
• Nous devons utiliser un conteneur IoC plutôt qu'un autre.

Toutes ces "choses" ont des avantages et des inconvénients valides pour les deux parties, et vous n'obtiendrez jamais une réponse "correcte", et la personne ne concédera jamais le point. (bien sûr, il y en aura où il y aura une réponse, peut-être :).

Ma question (j'y arrive !!) est: dans une équipe logicielle, comment couper à travers ces longues discussions sans entraver l'innovation, afin qu'une décision puisse être prise et que vous puissiez résoudre les vrais problèmes commerciaux.

Problème 1. Certaines personnes n'aiment pas perdre. S'ils n'appellent pas les coups de feu, ils vont débattre jusqu'à ce qu'ils appellent les coups de feu par attrition.

Problème 2. Rien n'est vraiment en jeu, donc le débat est toléré.

Rien n'est en jeu? Oui. La plupart des décisions ont un impact quasi nul en dollars. Le fait qu'il se résume à "frapper pendant des âges" signifie que les deux choix sont effectivement identiques.

Que faire?

1. Sachez que rien n'est en jeu.

2. Sachez que dans 2 ou 3 ans, tout le sujet sera rouvert car quelque chose en dehors de l'organisation a changé.

3. Un tirage au sort. Sérieusement. Choisissez quelque chose et continuez. Certaines personnes verront la bêtise dans le débat. Certaines personnes débattront ensuite de la nature de la pièce lancée. Si les gens ne peuvent pas être satisfaits d'un tirage au sort, ils ont des problèmes d'ego et doivent apprendre que (a) rien n'est en jeu et (b) la décision sera modifiée dans quelques années.

S'ils ne peuvent pas comprendre que rien n'est en jeu, ils doivent écrire la valeur monétaire des deux côtés de l'argument. À un moment donné, quelqu'un peut voir que plus d'heures de travail sont consacrées à l'analyse que la décision réelle n'en vaut la peine. Un tirage au sort produit une valeur égale pour un coût inférieur.

Quelques éléments à considérer:

1. N'acceptez que des arguments quantifiables. Si quelqu'un dit que cela gagnera du temps, demandez-lui de le quantifier et de le tenir à la réponse. De cette façon, s'ils parlent de détritus, ils ne font qu'un essai avant que tout le monde sache qu'ils sont une chasse d'eau éclatée.

2. Amenez les gens à assumer la responsabilité de leurs recommandations. Indiquez clairement qu'à la fin de l'année, s'ils ont effectué de mauvais appels, cela fera partie de leur évaluation. Cela ne me dérange pas les débats, mais je veux que les gens aient le courage de leurs convictions - si vous jurez que quelque chose est génial et attendez-vous à ce que nous l'adoptions, vous feriez mieux de pouvoir vivre avec les conséquences.

Ce sont des choses réelles pour échapper aux deux problèmes de S.Lott - que certaines personnes n'aiment pas perdre et que rien n'est en jeu. Ma réponse met quelque chose en jeu, donc il n'y a pas de débat pour le plaisir de débattre.

1. Timebox la discussion. - S'il faut plus de 5 minutes à chaque partie pour présenter son cas, c'est trop complexe. Nous utilisons en fait des minuteries de cuisine pour cela . Ils fonctionnent à merveille et coûtent environ 5 dollars.
2. Exigez que les participants discutent des données et de l'expérience.
3. Nous gardons les options sur la table. Après que chaque partie ait son temps, nous passons encore 5 minutes à discuter des implications de chaque approche. Après 20 minutes, nous sortons et le faisons (le mettons en œuvre). Si cela ne fonctionne pas, nous optons pour l'autre approche.

La règle est simple. Une fois que vous ne savez pas quoi choisir, pensez à ce qui est le mieux pour l'entreprise.

Oui, le choix Intel v AMD n'est pas si simple. Mais quel est le meilleur pour votre entreprise? Par exemple, s'il y a une personne qui est chargée de commander des trucs et qu'il lui faudra du temps pour commander un PC basé sur un processeur AMD, mais basé sur Intel peut être commandé en une minute et vous ne vous souciez vraiment pas de ce que ce sera - Commandez simplement un processeur Intel car il est meilleur pour l'entreprise.

Habituellement, ces discussions ne sont que de la bikeshedding . Les gens se disputent quel format de transfert ou quel magasin de données utiliser et des tonnes d'autres détails qui devraient être vraiment transparents pour tous les composants, mais celui qui met en œuvre le détail. Personne ne s'en soucie tant que le composant remplit le contrat de conception et que les responsables de celui-ci seront en mesure de répondre aux modifications du contrat dans un délai raisonnable.

La grande majorité de tous les problèmes techniques que vous rencontrez dans le développement de logiciels sont des problèmes de bikeshedding. Tout simplement parce qu'ils ont déjà des solutions et la seule question est, quelle solution vous voulez choisir.
Vous ne devez pas vous enfermer dans de telles décisions. Vous devez verrouiller ces décisions dans une couche d'abstraction qui dissocie votre application de ces détails .
Les problèmes vraiment importants dans le développement de logiciels sont des problèmes de conception au niveau des fonctionnalités et du système. Tout le reste est secondaire.

Alors, ne lancez pas vraiment de tels débats. Concentrez votre énergie en divisant votre projet en parties indépendantes. Cela donne un logiciel plus robuste et plus flexible. Et si vous êtes en mesure d'identifier des décisions techniques qui présentent des inconvénients évidents (ce que vous ne pouvez faire qu'une fois que vous avez un logiciel en cours d'exécution), vous pouvez prendre une décision différente sans affecter le reste du système.

La normalisation est une approche

Votre équipe doit parvenir à un consensus sur ce qu'elle adoptera comme norme de développement, puis s'y tenir pendant une période de temps raisonnable (décidée par l'équipe). Si la norme échoue, une nouvelle est probablement adoptée à partir d'un nouveau lot de cadres de solution possibles.

"Hé, ces PC étaient inutiles à la fin, essayons les Mac!"

ou

"Je te l'avais dit! Le printemps est bien meilleur que l'EJB."

Etc.

Avoir une norme signifie que le code devient plus facile à travailler avec une équipe, ce qui à son tour conduit à un environnement plus productif.

Je teste actuellement l'approche, le code nommé "Papal conclave" et son assez prometteur. Il est basé sur une histoire selon laquelle, lors de l'une des élections papales, il y a eu une "impasse" et les cardinaux n'ont tout simplement pas pu faire de choix. L'entité organisant une élection (très probablement un major de la ville) a d'abord enfermé les cardinaux dans un bâtiment, puis considérablement réduit l'approvisionnement alimentaire, puis retiré le toit du bâtiment pour rendre le débat encore moins confortable. Comme prévu, les cardinaux ont fait le choix après le retrait du toit, mettant ainsi fin à une impasse de trois ans.

Donc, mon approche est que lorsque les gens sont en désaccord sur certaines choses, ils sont obligés d'en discuter jusqu'à ce qu'ils trouvent un choix. Je n'apporte aucun autre inconfort, pas même une contrainte de temps et bien sûr je ne fais rien avec le toit :). Tout ce que je fais, c'est soulever constamment le problème chaque jour. Si quelqu'un dit "Nous ne pouvons pas prendre de décision", je réponds par "Eh bien ... vous devez". Jusqu'à présent, je n'ai jamais rencontré une personne aussi désespérément accro à certains détails technologiques mineurs. Après un tas de réunions, ils ont tendance à rechercher un compromis tout comme les cardinaux.

Je suis d'accord pour dire qu'il s'agit davantage d'une discussion de soutien que de la couper. Cependant les discussions ne sont pas interminables et comme un plus, certaines personnes après un tel «conclave» ont tendance à éviter les débats technologiques mineurs, ce qui rend les choses plus confortables pour toute l'équipe.

J'ai lu quelque part que vous ne devriez pas voyager plus de 6 ensemble si vous devez vous mettre d'accord sur où vous allez et quoi faire, car vous n'atteindrez pas de consensus.

C'est un excellent exemple de la raison pour laquelle il faut une personne dotée de pouvoirs décisifs. Dans cet exemple particulier, ladite personne doit prendre une décision et dire «cela doit être comme ça», et les autres doivent respecter cette décision pour qu'un travail réel puisse être fait.

Si la décision se révèle ensuite être mauvaise par la suite, vous en êtes au moins certain et pouvez en tirer des leçons.

Une approche consiste à voter et fonctionne bien dans des équipes de plus petite taille.

Alors que deux personnes peuvent avoir la conversation; le déplacer vers un forum ouvert ... débattre pendant N temps, puis tenir un vote en levant la main.

Simple mais démocratique et vous permet d'avancer.

Une question similaire pourrait être:

Comment arrêter les guerres de religion / flammes sur les forums?

Je pense que @ S.Lott a raison dans son commentaire, si le seul point est "discussion", "s'éloigner" ou sinon l'ignorer pourrait être la seule réponse. J'ai utilisé cette technique dans le passé.

Si le point est d'arriver à une solution, pesez le pour / le contre pour le domaine en question, fixez une limite de temps et (hoche la tête à Nike) faites-le.

Idéalement - OMI - la figure de chef de file de la technologie ou l' autorité dit: « D' accord, je vous remercie de vos points, nous sommes ... » son de dés rouleau « ... aller avec l'idée de soi-et-couça. » et tout le monde va s'asseoir.

La geekery sur des points minuscules a gaspillé une énorme quantité de mon temps de réunion, et je ne veux plus l'entendre. : - /

Je trouve que lorsque vous concentrez la conversation non pas sur l'alternative qui convient, mais sur les conséquences du choix de la mauvaise, vous avez tendance à ne pas trop vous enliser. Si nous pouvons arriver à un consensus que même si A a raison, B ne nous tuera pas, personne ne sera trop blessé si nous finissons avec B. Si nous ne pouvons pas arriver à ce consensus, c'est généralement parce qu'il y a un vrai problème que nous devons aborder.

L'essentiel est que nous devions être matures et comprendre que nous ne pouvons pas toujours être d'accord les uns avec les autres, la chose importante et mature est d'apprendre les uns des autres, pourquoi nous avons les positions que nous avons, et peut-être liées aux miennes question, apprenez quelles expériences et pourquoi. Ensuite, nous pouvons faire notre propre opinion éclairée et être damnés ou non.

Personnellement, je n'ai pas besoin ni ne m'attends à ce que d'autres personnes soient d'accord avec moi, ce serait bien, mais pas important. Et jusqu'à ce point, je cite Voltaire.

"Je suis peut-être en désaccord avec ce que vous dites, mais je défendrai jusqu'à la mort, votre droit de le dire." -Voltaire, philosophe du 5e siècle

Chaque réunion devrait avoir un président responsable de l'ordre du jour et du maintien de l'ordre (et de prendre des minutes, bien qu'ils puissent déléguer cette tâche à quelqu'un d'autre si la réunion est trop grande pour qu'ils puissent tout gérer). La tâche du président est de dire à quelqu'un d'arrêter de se disputer ("les gars, veuillez le mettre hors ligne" dans le discours de l'entreprise).

Si la réunion ne vaut pas la peine de nommer un président, ce n'est pas une réunion qui en vaut la peine. Vous pourriez tout aussi bien discuter avec le refroidisseur d'eau.

On peut dire "plus facile à dire qu'à faire, quant_dev". Eh bien ... un président naturel est un chef d'équipe, un chef de projet, un chef d'équipe. Ils devraient avoir l'autorité nécessaire. Les réunions où personne ne sait qui dirige réellement les réunions sont des signes de chaos dans l'organisation, un problème plus profond qui doit être résolu.

Résolvez d'abord les problèmes généraux: nous avons besoin d'un serveur Web, d'un serveur d'applications, d'une base de données, etc.

Pour les débats sur la base de données ou le serveur à utiliser, garez ces éléments pour une autre réunion.

Au cours des réunions suivantes, permettez à la discussion de "présélectionner" les offres potentielles, par exemple MySQl, MS SQL Server, Postgres, etc.

Permettez aux membres de l'équipe d'exprimer leurs opinions, mais demandez-leur de les appuyer sur des faits. Le produit X craint! Ne le coupe pas, le produit Y ne se met pas à l'échelle! Est trop vague. Etc.

Une fois que tous les détails sont connus et sur la table, vous devez le mettre aux voix ou, en tant que chef d'équipe, prendre une décision exécutive.

Si vous avez besoin de débusquer un gagnant clair ou de confirmer le support / le manque d'une fonctionnalité / concept, n'hésitez pas à prendre un peu de temps pour faire un POC (Proof Of Concept) mais réalisez que cela prendra du temps et que les développeurs ont tendance à voulez courir avec tout ce qu'ils ont commencé ... Assurez-vous de vérifier tous les obstacles / problèmes techniques avant d'aller avec le POC.

En tant que chef d'équipe, je pense que cela dépend si la décision doit être prise ici et maintenant.

Si c'est le cas, je cherche celui qui a le coût d'inversion le plus bas. Il est toujours important, en tant qu'équipe de développement, de savoir que votre décision peut être erronée, vous devrez peut-être faire le choix maladroit et changer d'avis. Le coût de cette opération doit toujours être minimisé.

S'il peut attendre, considérez le fait qu'aucune des parties en désaccord n'est en possession de tous les faits. Demandez-leur de s'éloigner et de poursuivre leurs recherches et de faire vos propres recherches.

Le faisons-nous toujours dans le feu de l'action? Non, surtout quand je fais partie de ceux qui ont une opinion passionnée (je ne prétends pas être parfait). Mais je pense que c'est la façon d'aborder de telles situations. La boxe temporelle ne semble jamais conduire à ce que tout le monde soit d'accord, elle mène juste à un argument non conclu.

Sauf si vous avez un membre d'équipe difficile, vous n'avez généralement pas de débat sans fin à moins qu'il n'y ait aucun avantage clair à l'une ou l'autre approche. Voici quelques bonnes approches pour briser une égalité:

• Laissez la personne qui doit réellement le mettre en œuvre décider.
• Pour les problèmes d'interface utilisateur, laissez la personne la plus consciente des exigences du client décider.
• Laissez la personne ayant le plus d'expérience sur le sujet ou une partie de la base de code décider.
• Laissez la personne ayant les contraintes d'horaire les plus strictes ou les limites de main-d'œuvre et de ressources décider.
• Laissez la personne décider qui a des objections plus concrètes que théoriques.
• Trouvez un compromis entre les approches.
• Rassemblez plus d'informations et décidez à la prochaine réunion, donnant plus de poids aux personnes qui ont évidemment passé un certain temps à faire des recherches depuis la dernière réunion.

En ce qui concerne la façon d'annoncer une décision, vous dites simplement: "D'accord, nous allons avec cela à cause de cela ." Si les gens ont l'impression que vous leur avez donné une audition équitable et que vous n'êtes pas un peu délicat en tant que leader, ils suivront votre décision. Pour les personnes particulièrement têtues, vous pouvez promettre de réévaluer une fois la mise en œuvre terminée, mais la plupart des gens la laisseront tomber à ce stade.

Un bon animateur de réunion peut faciliter ce genre de discussions sans les laisser échapper.