Comment faire en sorte que des personnes non techniques comprennent un problème non lié à une interface utilisateur? [fermé]

Question

Supposons que vous travailliez sur un projet d'entreprise dans lequel vous devez obtenir l'approbation de la direction pour pouvoir développer un nouvel ensemble de fonctionnalités. Habituellement, votre direction n'a pas de problème à signer une nouvelle fonctionnalité d'interface utilisateur. Malheureusement, ils ont du mal à comprendre certains problèmes cachés qui sont essentiels au bien-être de l'application, tels que les transactions, l'intégrité des données, le routage des flux de travail, la configurabilité, la sécurité, etc. pas immédiatement visible, il n'est pas évident pour eux que cela est crucial.

Comment les avez-vous convaincus qu'il fallait régler ces problèmes d'infrastructure et qu'ils étaient importants pour leur processus métier?

Answer 1

Chaque métier a ses côtés non-sexy. Des choses qui DOIVENT être faites, mais personne ne les remarque directement. Dans une épicerie, quelqu'un doit organiser quand et comment remplir les étagères de l'épicerie afin qu'elles aient toujours l'air fraîches. Dans une blanchisserie, vous avez besoin de quelqu'un qui pense à la façon dont les processus devraient être optimisés afin que le client récupère ses vêtements à temps.

La partie la plus délicate est la suivante: le client ne remarquera pas que ces subtilités ont été correctement exécutées JUSQU’À CE QUE CELLES-CI SONT MANQUÉES! Par exemple, lorsque le linge n'est pas prêt à temps, mais avec deux jours de retard, ou que les légumes du supermarché ont des taches brunes et sont terribles.

Même chose pour l'informatique. Vous ne remarquerez pas de bonnes transactions avant que votre client principal frappe à votre porte et vous dise qu'un projet important et coûteux a échoué parce que les entrées de la base de données de votre produit ont été mystérieusement mélangées. Vous ne remarquez pas de sécurité suffisante tant que les informations de carte de crédit du client ne s'affichent pas dans Elbonia (et peu de temps après). dans les journaux nationaux avertissant les clients de votre entreprise).

Ce que vous devez vraiment insister encore et encore, c'est que les logiciels ne sont PAS statiques. Il doit être soigné même après la fin de sa phase de développement initiale. Ce n'est pas simplement un produit que vous achetez une fois et que vous oubliez. Chaque constructeur automobile sait que les services sont d’une importance primordiale pour les produits qu’il fabrique, tout simplement parce que des choses se produiront qui doivent être réparées et améliorées. C'est la même chose avec les logiciels.

Alors, faites une présentation, visualisez, verbalisez, traduisez vos informations techniques en avantages. Les gens d’affaires ne se soucient pas de votre souhait d’esthétique du code dans un projet de refactoring, mais ils COMPRENDRONT que vos modifications aideront le produit à devenir plus fiable, à acquérir une meilleure réputation et à réduire le nombre de demandes de service. Faites-les comprendre en leur montrant les avantages!

Answer 2

Même chose que font les gens depuis des milliers d’années: dessiner des images. Diagrammez les problèmes, utilisez des métaphores visuelles familières pour votre public, faites glisser le problème sur leur territoire.

En supposant qu'ils ne soient pas intentionnellement obtus ...

Answer 3

Un grand +1 pour les analogies et les métaphores. Si possible, trouvez-en un qui réponde aux intérêts personnels de votre public (s'il s'agit d'une ou deux personnes). Pour les métaphores générales, je me trouve souvent en train d’utiliser des navettes ou des métros, pour une raison quelconque.

par exemple. Nous sommes en train de migrer une application d'un OODB vers Postgres / Hibernate: l'essentiel de ce travail est effectué dans la version '4'. De nombreux experts de domaine ont demandé pourquoi il y avait si peu de fonctionnalités orientées utilisateur dans R4. Je leur dis régulièrement que nous sommes en train de démolir la ville pour la mettre dans un métro. C'est très coûteux et indéniablement risqué, mais une fois que cela sera fait, les avantages de la R5 + seront véritablement stupéfiants. ' La vraie conversation est plus complexe, mais je peux revenir à ce thème encore et encore, bien après R4. Dans quelques mois, j'espère pouvoir dire: "Vous avez demandé X et c'est maintenant très facile, précisément parce que vous nous avez mis dans ce métro, en R4".

Answer 4

Le moyen le plus sûr de faire en sorte que les cadres supérieurs achètent des travaux de développement est de les présenter de manière quantifiable. Idéalement, cette mesure quantifiable est en $$. Vous devez leur expliquer les conséquences d'un sabotage sur l'intégrité des données, la sécurité, les transactions, etc., et leur incidence sur la communauté des utilisateurs et des utilisateurs et, éventuellement, sur les résultats. Vous devez être prudent dans ces situations car la direction s'attend parfois à ce que ces exigences non fonctionnelles "fonctionnent". Si tel est le cas, vous devez soit estimer haut et travailler sur ces éléments parallèlement au travail visible de l'interface utilisateur (l'ignorance est une bénédiction) ou vous devez documenter ces domaines de besoin lorsque vous communiquez avec la direction, donc si les choses tournent mal comme vous le souhaitez, ce n'est pas votre travail qui est en jeu.

Answer 5

Malheureusement, il faut généralement un désastre ou deux avant que ce matériel ne reçoive l'attention qu'il mérite.

Cela dépend vraiment de votre gestion, mais j’ai eu de la chance avec de bonnes vieilles méthodes de peur honnêtes à bonnes. Si vous passez par deux scénarios de catastrophe et que vous signalez à quelqu'un qu'il va être blâmé s'il se produit, cela peut être suffisant pour que son arsenal instinct de récupération se déclenche et fasse enfin attention:)

Answer 6

Analogies de voitures.

Tout le monde connaît ce 'système' et il est suffisamment complexe pour décrire la situation désastreuse.

Answer 7

Je me bats avec essentiellement le même genre de situation. Qu'il s'agisse d'une signature de la direction ou d'une acceptation par un utilisateur / sponsor, le problème reste l'un des vocabulaires, des priorités et des perspectives différents. J'ai posé une question similaire ici .

J’ai également obtenu diverses réponses, extrêmement proches d’utiles, mais pas assez définitives. Parcourir et rechercher SO afin d’utiliser des mots-clés pertinents m’a amené à trouver des idées utilisables dans diverses réponses réparties sur de nombreuses questions sans lien entre elles. Trouver et extraire ces gemmes m'a amené à poser cette question sur l'exploration de sites .

Il aurait été utile de pouvoir marquer les différentes réponses et de les voir toutes dans une seule liste, mais hélas, cette fonctionnalité n’est pas encore disponible dans SO. Je l 'ai suggéré sur notre serveur .

J'espère que vous trouverez quelque chose que vous pouvez utiliser parmi les références que j'ai données.

Answer 8

Le bon type de question à contrer est le secret.

• Puis-je planter toutes les 5 pages Web?
• Devons-nous protéger les numéros de carte de crédit?
• Est-il acceptable de payer des sous-traitants pour déployer un correctif chaque week-end?
• Le voulez-vous maintenant ou voulez-vous qu'il fonctionne?

Answer 9

Robustesse. En bout de ligne, vous devez parler leur langue, ce qui affecte leur résultat net. S'il s'agit d'un problème de sécurité ou de correction, vous devez leur dire que les clients ne voudront pas de produits agissant de manière incorrecte, quelle que soit leur apparence.

Answer 10

J'aime bien l'idée de Dette technique , car elle permet de traduire les problèmes techniques ( bien que vaguement) en argent - et la plupart des gestionnaires le comprennent bien.

Bien que l’idée de dette technique ait été à l’origine appliquée aux problèmes d’architecture, elle peut être utilisée plus largement pour tout type de situation où il existe une pression pour prendre un raccourci - c’est-à-dire faire une dette technique - plutôt que de le faire. droit la première fois. (Faire les choses correctement équivaut à économiser pour acheter quelque chose - cela prend du temps - plutôt que de l’acquérir à crédit et de s’endetter.)

De même que les dettes peuvent être bonnes (par exemple, les prêts au logement) et mauvaises (par exemple, les cartes de crédit), les dettes techniques peuvent être bonnes ou mauvaises. Je ne tenterai pas de caractériser complètement les différences, mais une bonne dette technique peut être suivie avec précision, de sorte que vous sachiez combien vous êtes endetté.

Alors, essayez d’expliquer votre problème important de non-assurance-chômage en termes de dette technique et le coût de ne pas le résoudre en termes de paiement d’intérêts sur cette dette.

Answer 11

Une image descriptive aide vraiment les personnes non techniques à comprendre de quoi vous parlez. Par exemple, voici un exemple de Sun décrivant le traitement des informations dans l’une de leurs applications quelque peu complexes.

_{(source: sun.com )}

Essayer d'expliquer cette application avec des mots serait impossible pour un non-technicien. En pointant sur le diagramme et en regardant, cette partie est notre point faible, nous devons l’améliorer. Cela leur semblera logique. S'ils ont le sentiment de bien comprendre ce que vous faites, ils seront beaucoup plus disposés à appuyer votre demande.