Comment «vendre» efficacement un bon design lors de grandes réunions

Plusieurs fois, j'ai été témoin d'une triste tragédie. Voici ce qui se passe:

1. Une revue de conception d'équipe pour un nouveau projet.
2. Je vois un design simple qui a pas mal de trous.
3. Je mentionne nonchalamment les trous et les moyens de les éviter.
4. Les avertissements sont ignorés avec des commentaires comme «cela« n'arrive jamais »dans la vraie vie»
5. Finalement, les choses qui "n'arriveront" jamais "se produisent
6. Un examen de la conception de l'équipe d'urgence pour un projet cassé.

Alors qu'est-ce que je fais? Abandonner l'attitude «Je vous l'ai dit» ne va pas gagner d'amis et influencer les gens. Parfois, les années passent et les commentaires de l'étape 3 sont quand même oubliés. Je ne veux certainement pas être le ravageur ennuyeux qui rappelle au monde les pièges. Je m'assieds souvent et regarde le Titanic partir pour l'Europe.

C'est frustrant de voir de mauvaises conceptions aller de l'avant. Il est également frustrant que je n'arrive pas à convaincre les autres du péril imminent du chemin actuel. Je fais le pire lors des réunions d'équipe où tout le monde a différentes façons de comprendre différents termes. De plus, les ego ont tendance à gagner de la raison et de la pensée. Je cherche de bonnes tactiques pour convaincre les gens des groupes d'utiliser des idées nouvelles et compliquées.

Si possible, suggérez des modifications qui n'ajouteront pas de temps significatif à un projet. Essayez de souligner que si ce n'est pas fait maintenant, retravailler plus tard sera beaucoup plus douloureux. Ce sera plus difficile si vous essayez de convaincre votre équipe qu'une nouvelle direction complète est meilleure, car cela retardera probablement le projet, etc.

Ne mettez pas les gens en mode défense lors d'une réunion, ils vous combattront pour être le gagnant. Vous ne leur ferez pas accepter que la terre est ronde. C'est une politique normale (par exemple, n'importe qui sur FoxNews)

Cela aide vraiment d'avoir le respect des autres développeurs. Si vous êtes le nouveau gars de l'équipe, je pense que vous êtes SOL. Alors, construisez simplement un représentant d'équipe et essayez vraiment d'atteindre un niveau où vous ne serez pas renvoyé dès le départ. Bien sûr, si vous êtes toujours des choses pessimistes, alors vous serez simplement étiqueté comme le gars "négatif".

Pour les choses simples (c'est-à-dire sans impact sur les horaires), assurez-vous de faire votre travail de la meilleure façon. Si vous mettez l'effort dans votre sortie immédiate (par exemple, en créant des cas de test ou en obtenant quelques fonctionnalités simples (mais cool)), d'autres personnes finiront par remarquer que votre code fonctionne de manière fiable et résiste à l'épreuve du temps. Lorsque vous commencez à leur montrer quelques astuces avec le code, ils réfléchissent à deux fois en vous abattant devant tout le monde.

Enfin, je conviens que vous ne voulez pas faire la routine "Je vous l'ai dit", mais assurez-vous d'essayer de laisser des indices à votre patron / responsable technique quand il s'avère que vous aviez raison. Peut-être renvoyer un ancien e-mail avec vos anciens commentaires. Demandez-leur si cela pourrait aider à résoudre le «nouveau» problème. Si vous ne le faites pas, ils ne se souviendront même pas que c'est vous qui l'avez soulevé la première fois. Finalement, ils comprendront que vous n'essayez pas seulement de faire la démonstration lors des réunions. La prochaine fois, ils réfléchiront à deux fois avant de vous faire exploser, surtout si cela se produit que votre "ancienne" conception remplace maintenant la version cassée actuelle.

Essayez de vous forger une réputation de personne capable d'identifier ce qui fonctionnera et pas seulement ce que vous pensez avoir un problème dans certains cas d'utilisation rares. Lorsque vous voyez ces problèmes potentiels, considérez-les simplement comme une note de bas de page qui devra peut-être être traitée plus tard.

Les gens deviennent fous dans les congrégations. Faites part de vos préoccupations à une personne clé en dehors de la réunion. Ils verront cela comme moins menaçant et peuvent prendre le temps d'entendre votre argument au lieu de penser à défendre le design. Ils peuvent également prendre plus de temps pour vous expliquer les circonstances pour lesquelles vous pouvez avoir un point valide, mais il n'est pas possible de traiter dans la version 1.0.

Clé! Entrez dans la réunion avec une compréhension complète de l'ordre du jour de votre superviseur direct. Peut-être qu'ils voient cela comme un projet mineur et la dernière chose dont ils ont besoin lors de la réunion est un opposant prenant du temps sur des questions plus importantes. Demandez-leur de vous aider à les aider.

Si vous voulez les influencer, parlez-leur en dehors de la réunion de conception. Sinon, ils vont juste penser que vous essayez de "marquer des points". Beaucoup de gens ne veulent jamais avoir de vraies discussions lors d'une réunion avec un "public".

Je ne vois pas en quoi cette situation est très différente d'un développeur seul avec un patron désemparé. Malheureusement, j'ai perdu le compte du nombre de fois où j'ai été «convaincu» de construire un projet d'une certaine manière et de l'expédier, malgré mes avertissements de catastrophe imminente. Cela vous laisse non seulement construire, mais naviguer seul dans le proverbe Titanic dans un iceberg.

Tout comme vous l'avez décrit, lorsque les morceaux ont frappé le seau proverbial, mes avertissements avaient depuis longtemps été oubliés. Parfois (heureusement pour moi), les choses ont mal tourné des mois ou plus après que je n'étais plus impliqué dans le projet. Malheureusement, cela a laissé mon successeur penser que je devais être fou, car vous pouvez parier que le patron a refusé toute main :)

Quoi qu'il en soit, un groupe de programmeurs `` convaincus '' peut être tout aussi désemparé qu'un patron aux cheveux pointus, parfois même plus parce qu'il est en toute confiance, comme Jeff O le mentionne . Lorsque cela se produit, vous avez amplement le temps de réparer les choses. N'essayez pas de faire entendre une seule voix de la raison sur un pet de cerveau collectif. Si vous pouvez le faire efficacement, votre place est au congrès, pas derrière un logiciel d'écriture de bureau.

Les actions étant plus éloquentes que les mots, vous pouvez:

• Montrez (avec des scénarios de test) pourquoi la conception échouera dans des circonstances normales. Cela se traduira probablement par une plus petite réunion où vous êtes celui qui présente, et c'est probablement tout ce dont vous avez besoin pour être entendu.

• Montrez un produit concurrent qui répond adéquatement à ce que le groupe pensait être seulement des «cas de coin». Vous seriez étonné de la longueur des efforts de Google pour anticiper les erreurs dans son tableur, par exemple.

• Réitérez le dernier projet qui a nécessité une réécriture au sol une semaine avant son expédition.

En d'autres termes, la première étape, peu importe ce que vous faites, est de traiter avec des individus ou un groupe (beaucoup) plus restreint. Si vos préoccupations sont vraiment valables, je suis sûr qu'elles seront mieux reçues une semaine ou deux après le développement. Juste, comme vous l'avez noté, évitez la position «Je vous l'ai dit».

Si possible, passez en revue le design avant (ou même après) la réunion et parlez aux designers en privé. Abattre les gens lors d'une réunion devant tous leurs collègues aura tendance à les rendre instantanément défensifs et fermés à propos de vos suggestions, et peut conduire à une réputation de "fauteur de troubles" même si vous pensez que vous êtes utile.

Une bonne façon (mais souvent difficile) de présenter des "critiques" consiste à poser des questions directrices - laissez l'autre personne essayer de répondre à votre question et réaliser la faille par elle-même. Cela ressemble alors beaucoup plus à leur propre idée et ils seront plus susceptibles de la faire avancer. Encore une fois, cela fonctionne mieux dans les discussions privées, mais peut être un moyen plus diplomatique et plus efficace dans une situation de réunion (Remarque: essayez d'éviter d'entrer dans un argument ou une longue discussion pour convaincre les gens de la réunion. Il suffit de faire passer l'idée et d'essayer ne vaut pas la peine. Il vaut peut-être mieux l'abandonner, puis discuter avec les designers après la réunion pour "clarifier quelque chose que je n'ai pas bien compris" plutôt que d'être "le gars qui a fait une simple 30 minutes rencontre gaspiller toute ma matinée ")

Une autre approche consiste à envoyer vos suggestions (diplomatiquement) par e-mail au concepteur principal (ou à une liste de distribution pertinente mais petite). Cela peut aider à réfléchir à vos idées et vous donne également une "trace écrite" pour soutenir toute situation "Je vous l'ai dit" à l'avenir (si les choses se présentent en forme de poire, vous avez au moins la preuve que vous avez essayé d'aider mais que vous avez été ignoré. Mais si les choses tournent si mal, vous ne travaillez probablement pas dans la bonne entreprise)

Enfin, gardez à l'esprit que parfois vous pouvez vous tromper. Les personnes à qui vous parlez peuvent avoir une compréhension plus claire ou plus complète de leur conception que vous, et avoir de bonnes raisons pour leur approche (par exemple, un membre de l'équipe m'a récemment accusé de créer une conception "inefficace", mais c'était une conception délibérée car je savais que les performances seraient toujours acceptables, mais cela réduirait de moitié les coûts de développement - c'était une décision commerciale plutôt qu'une décision de qualité de code). Essayez simplement d'être ouvert d'esprit sur les idées des autres - parfois, ce qui semble être une mauvaise idée peut être une bonne idée pour des raisons que vous n'avez pas envisagées.

Lorsque vous rencontrez le scénario "qui ne se produira jamais", rappelez-leur toutes les fois où ils ont dû corriger ces éléments "qui ne se produiront jamais". Mais vous devez faire attention à ne pas tomber sur "Je vous l'ai dit". Je trouve qu'il est plus efficace d'évoquer les problèmes du passé (et à quel point ils étaient coûteux et douloureux à résoudre) en discutant pourquoi vous pensez que nous devrions faire quelque chose maintenant pour ce projet en tant qu'exemples de la raison pour laquelle vous pensez que c'est important avant qu'ils n'apportent le "que n'arrivera jamais "citation.

Je pense que votre problème est peut-être que vous dites que vous mentionnez avec désinvolture un moyen d'éviter un problème. Parfois, cela signifie aborder le sujet lors d'une deuxième réunion après avoir eu le temps de faire un peu de recherche. Établissez une analyse de rentabilité pour savoir à quel point il est bon de faire maintenant et à quel point il est coûteux de le faire plus tard.

On dirait que votre meilleur pari est de travailler pour obtenir une position de chef d'équipe. Profitez de ces occasions pour souligner les pouvoirs en place que vous avez vu venir et qui auraient pu être évités. Vous ne devriez pas avoir besoin de vendre à découvert votre équipe actuelle.

Le "décontracté" dans "mentionne négligemment les trous" semble être un problème. Essayez d'utiliser (ou de faire intervenir s'il n'existe pas) un processus écrit pour analyser les risques du projet. En règle générale, le résultat d'une réunion d'analyse des risques est un simple tableau à deux colonnes: le risque et la stratégie convenue pour atténuer le risque («nous pensons que cela n'arrivera jamais» est une atténuation acceptable; l'important est d'enregistrer la réflexion actuelle sur la question à l'époque). Assurez-vous que vos problèmes sont enregistrés comme des risques. Les risques doivent être réexaminés régulièrement; il y a de nombreuses chances que votre point de vue soit venu longtemps avant que la crise ne se produise et qu'un examen des risques agisse comme un «OMG qui se produit»; nous serions fous de continuer comme ça "catalyseur". À plus long terme, une trace écrite est une preuve utile pour dire "regardez, nous semblons avoir un problème institutionnel ici" et obtenir des attitudes envers la conception ou tout ce qui a changé.

Comment mettre en œuvre vos idées

Dans les réunions, les problèmes sont considérés comme des défis. Vous résolvez des problèmes, vous surmontez des défis. Les défis sont de bonnes choses, les problèmes ne le sont pas.

Commencez lentement et utilisez cette technique sur un seul défi à la fois. La prochaine fois que vous souhaitez que votre patron adopte l'une de vos idées, procédez comme suit:

• Développer trois approches similaires mais différentes
• Dites à votre patron que vous avez besoin de son aide pour quelque chose
• Expliquez que vous ne savez pas laquelle des trois méthodes est la meilleure solution pour résoudre le problème
• Demandez-lui de vous aider à choisir l'un des trois

1. C'est extrêmement puissant. Ce que vous faites, c'est proposer des choix et non un ultimatum. Les ultimatums ne sont plus souvent abattus car ce n'est pas leur idée et il n'y a qu'une seule option.

2. Votre utilisation des mots est très importante ici. " J'ai besoin de votre aide ".

3. Laissez le patron choisir "A", "B" ou "C". En fait, laissez le boss créer l'option "D" en retirant les sections de "A", "B" et "C". Ce que vous faites, c'est de laisser votre patron faire un choix.

À ce stade, vous vous souciez moins de l'option qu'il choisit, car ce sont toutes vos idées. Il pensera qu'il résout réellement le problème parce que vous laissez la décision devenir la sienne.

Ayez Proof of Conceptvotre idée mise en œuvre. Si vous montrez à votre équipe quelque chose qui fonctionne et qui résout le problème actuel, ils l'apprécieront.