Laissez-moi vous poser une question : En tant que gestionnaire de produit ou maître de mêlée, pensez-vous qu’il existe un point de basculement où la cohérence se transforme en tyrannie ?

J’ai posé cette question à quelques pauvres types sans méfiance lors de récents Meetups de produits et Agile ici dans la région de Raleigh. Ma récompense a été de nombreuses affirmations que de tels hobgobelins insensés existent.

Plus récemment, après avoir publié ma question sur une variété de canaux de médias sociaux, je suis convaincu que nous, dans le secteur de la livraison de logiciels, nous asservissons parfois effectivement au nom de la cohérence.

Déballons donc un peu tout cela et voyons si nous ne pouvons pas nous mettre d’accord sur ce à quoi un tel point de basculement pourrait ressembler …. en examinant d’abord ce qu’il n’est pas.

Savante cohérence

Un exemple de cohérence bénéfique pour les gestionnaires de produits est dans la façon dont nous élaborons nos user stories. Par exemple, j’aime suivre le principe INVEST – NON pas comme une prescription passe-partout – mais plutôt un guide pour m’assurer que je ne demande pas à mes équipes de manger l’éléphant en entier dans une seule user story.

Un autre exemple de bonne cohérence provient du monde de l’UX, plus précisément du 6e chapitre de l’ouvrage séminal de Don Norman, « The Design of Everyday Things ». Là, Norman affirme que ceux d’entre nous qui ont une expérience de la conduite automobile peuvent gérer une marque et un modèle que nous n’avons jamais utilisés auparavant en raison du placement cohérent de fonctionnalités telles que la pédale d’accélérateur et les rétroviseurs latéraux.

Steve Krug court avec cet exemple dans le chapitre « Billboards Design 101 » de son délicieux livre « Don’t Make Me Think. » Krug faisant des arguments efficaces en faveur de la reconnaissance par rapport à la mémorisation, en particulier lorsqu’il s’agit de traitements des hiérarchies visuelles, des hyperliens et de la mise en page du contenu.

Cependant, Krug soutient également que ce que nous voulons en fin de compte, c’est rechercher la clarté, avec l’utilisation judicieuse de la cohérence comme un moyen efficace d’y parvenir. Il propose également cet avertissement dans le même chapitre :

Et enfin, un mot sur la cohérence.

On entend souvent citer la cohérence comme un bien absolu. Les gens gagnent beaucoup d’arguments de conception juste en disant « Nous ne pouvons pas faire cela. Ce ne serait pas cohérent. »

La cohérence est toujours une bonne chose à rechercher au sein de votre site ou de votre application. Si votre navigation est toujours au même endroit, par exemple, je n’ai pas besoin d’y penser ou de perdre du temps à la chercher. Mais il y aura des cas où les choses seront plus claires si vous les rendez légèrement incohérentes.

Consistance tyrannique

.

Ma citation d’ouverture est tirée de l’ouvrage d’Emerson « Self-.Reliance, », un essai qui présente un argument convaincant pour que les gens pensent par eux-mêmes, plutôt que d’accepter un destin souvent associé aux falaises et aux lemmings.

Comme je l’ai mentionné précédemment, j’ai posé ma question d’ouverture dans une variété de canaux sociaux et de Meetups. Voici des exemples que j’ai récoltés et qui, selon moi, démontrent une cohérence insensée, voire tyrannique :

• Un scrum master qui pique une crise si un développeur ne crée pas une histoire JIRA pour corriger une coquille dans un artefact README.md.
• Un rédacteur en chef d’une organisation de presse qui insiste pour que l’application mobile native prenne en charge exactement les mêmes 150 sections que leur solution de bureau basée sur le navigateur afin de ne pas confondre les utilisateurs.
• Un chef de projet qui maintient que la planification de la capacité comme la seule et véritable façon de s’assurer qu’un client obtient ce pour quoi il a payé parce que les approches plus modernes de livraison de logiciels ont trop d’incertitude impliquée.
• Quelqu’un du terrain demande  » N’y a-t-il pas un moyen d’aligner toutes les équipes de développement sur la façon dont elles dimensionnent les histoires ?  »
• Un architecte qui plaide pour la Big Design Up-Front de tout pour chaque scénario parce qu’il insiste sur le fait que c’est la seule façon de savoir quoi construire pour soutenir un ensemble de fonctionnalités.
• Un client qui exige que les résultats fournis par une nouvelle infrastructure de recherche plein texte basée sur Lucene soient 100% identiques à ceux renvoyés par la mise en œuvre de la base de données NoSQL sortante.
• Un chef de produit qui refuse d’accepter les user stories des autres à moins qu’elles ne soient formatées de manière impeccable et complétées de manière exhaustive à l’aide d’un boilerplate TPS et de la page de garde qui l’accompagne.

Le résultat de tels scénarios est la frustration grinçante que nos équipes de développement endurent comme une dévotion servile à la cohérence … une priorisation bien intentionnée mais mal orientée qui entrave considérablement leur capacité à découvrir et à livrer rapidement et continuellement des fonctionnalités de valeur appropriées.

Sagesse supplémentaire

D’autres personnes plus intelligentes que moi ont également mis en garde contre un asservissement insensé à la cohérence ; vous trouverez ci-dessous quelques URL utiles que j’ai visitées en préparation de ce billet.

.