Comment faire face au fluage des fonctionnalités
Si une hypothèse est sûre, six mois après le lancement d’un site Web (ou plus tôt?), Ses propriétaires disposeront d’une liste de choses qu’ils souhaitent modifier , des erreurs typographiques mineures à des fonctionnalités entièrement nouvelles.
Est-il possible d’accepter la fonctionnalité comme un processus naturel (ou du moins inévitable)?
De nombreux sites Web commencent à échouer lorsque leurs objectifs changent ou que leur portée s’étend.
Le fluage des fonctions intervient lorsqu'un client demande un petit ajustement qui ne prend qu'une minute ... et ne cesse jamais de faire des requêtes.
Accepter le fluage des fonctionnalités en tant que processus naturel requiert une capacité à faire la distinction entre un besoin réel et une imagination débordante ou "Ne serait-ce pas génial si ..."
Les clients veulent naturellement tirer le maximum de leur budget. Parfois, les concepteurs et les développeurs doivent dire: «Non, cela dépasse ce que nous avions convenu».
Mais toutes les demandes de changement ne sont pas des pincements. et comme le web, les projets et les entreprises changent avec le temps: les magasins ont des ventes saisonnières; les entreprises développent de nouveaux produits; les services en ligne affinent leurs processus; les publications libèrent du contenu frais. Le changement se produit
Éviter le fluage de la solution
Les clients peuvent connaître leur entreprise, mais ils recrutent des experts Web pour leur expertise Web. Le fluage des fonctionnalités intervient lorsque les clients oublient cela et traitent les concepteurs comme des outils au lieu de résoudre des problèmes.
Etre capable d'expliquer aux personnes non-Web trop enthousiastes les techniques et technologies qui ne sont pas appropriées pour un site Web donné est une guerre d'usure fastidieuse.
Mais les concepteurs qui se présentent comme des résolveurs de problèmes , et non de simples singes codeurs, sont essentiels à leurs relations avec les clients.
La clé est de faire en sorte que le client apporte des problèmes, pas des solutions. Disons que le client apprend sur Twitter. On dit qu'ils sont à la mode. Alors ils le veulent. À présent.
À long terme, l’effort d’écriture de tweets sera frustrant à moins que les tweets ne créent des avantages mesurables. Au lieu de cela, demandez au client s'il a besoin d'un compte Twitter qui publie sur le blog de l'entreprise ou tout simplement besoin d'articles de blog de qualité supérieure.
Voici quelques exemples:
"Je veux un design dynamique" est une solution, pas un problème.
"Qu'est-ce qui rendrait le site Web dynamique?" Est un problème de conception.
"Je veux un outil de recherche" est une solution, pas un problème.
"Les clients ne trouvent pas nos produits" est un problème de conception.
"Je veux un flux RSS" est une solution, pas un problème.
"Quels sont les moyens de communication les plus susceptibles d’attendre et d’utiliser les visiteurs de notre site Web?" Est un problème de conception.
"J'aime la conception de ce site Web", c'est l'envie de la concurrence, pas la solution.
"Vous n'êtes pas eux," n'est pas une réponse adéquate non plus.
Au lieu de cela, "Comment voulez-vous que les clients perçoivent votre entreprise ou votre organisation?"
Si votre question «Que pensez-vous de ce logo?» Est suivie d'un silence inconfortable, renversez-le avec un double: «Comment voulez-vous que vos clients voient votre marque? Quels visuels vos clients associeraient-ils à ces qualités? "
Dans chaque cas, la fonctionnalité peut être traitée en transformant "je veux" en une question que le concepteur , et non le client, doit résoudre .
Question Everything Up Front
Apprendre à poser des questions apparemment irréalistes est important et, avec un peu de pratique, étonnamment amusant.
Par exemple, quand un site Web aurait-il besoin de plus d'une page d'accueil? Ou si un café a commencé à vendre des vidéos?
De telles questions ne semblent ridicules que si vous pensez aux problèmes immédiats.
Considérez plusieurs pages d'accueil. Les visiteurs qui reviennent n'ont peut-être pas besoin de la présentation complète des nouveaux arrivants. Dans ce cas, une page d’accueil qui présente les faits saillants récents fonctionnerait parallèlement à une page d’accueil présentant une vue d’ensemble.
Google Optimiseur de Site aide à suivre quelles pages d'accueil génèrent un trafic plus significatif.
Une stratégie consiste à tripler vos attentes les plus élevées . Imaginez trois pages "Contactez-nous", trente catégories au lieu de dix et trois niveaux de navigation au lieu d'un. Ou comment traiteriez-vous une page de contenu si elle devenait trois fois plus longue?
Une autre stratégie consiste à tout réduire d'un tiers. Et si vous vouliez concevoir des pages Web pour les appareils mobiles? Comment un design de 960 pixels de large peut-il s'intégrer dans un écran de 320 pixels de large? Et si le site Web ne générait que dix ventes par mois au lieu d'une par jour? Comment la page "About our team" changerait-elle si le personnel de 15 personnes était réduit à 10?
Avant de signer un contrat, recherchez ces mots cruciaux: "un", "un", "le" et "un".
Avant: "Le site Web aura une liste de services."
Après: "Le site Web comportera plusieurs listes de services organisées par sujet".
Avant: "Le formulaire de contact enverra un email au propriétaire."
Après: "Le formulaire de contact principal enverra des e-mails au propriétaire et, selon le sujet, au coordinateur de l'installation, au support technique ou au représentant commercial."
Avant: "L'en-tête sera orange."
Après: "L'en-tête de la page d'accueil sera orange. Les en-têtes de pages intérieures seront deux fois moins grands pour mettre en valeur le contenu. "
Avant: "Les profils d’adhésion incluront un numéro de téléphone et une adresse e-mail."
Après: "Les profils d’adhésion contiendront les coordonnées, y compris les numéros de téléphone (bureau, domicile, autres), numéros de fax, adresses e-mail et trois champs ouverts pour les adresses postales, comptes Twitter et Facebook, etc."
Avant: "Le blog sera organisé par date."
Après: "L'écran par défaut du blog affichera les messages par date. Les messages seront organisés avec des balises; la page sera conçue pour ne pas avoir l'air vide quand elle n'a que cinq messages; et les visiteurs pourront parcourir au moins 500 messages. "
Les meilleurs plans ne se limitent pas à une conception spécifique, mais tiennent compte d'une gamme de paramètres. Les problèmes ne sont que ridicules lorsque vous en recevez un à la date limite.
Besoins Authentiques
Aucun système ne peut prendre en compte chaque scénario.
La plupart peuvent s'adapter à de petits changements incrémentiels au cours de la vie du site, mais lorsque les solutions de pansement sont plus nombreuses que les problèmes initiaux, il est temps de faire savoir à aucun client: «repenser».
Lorsque partir de zéro est plus efficace que de réparer les changements qui ont résolu les problèmes antérieurs (mais qui ont brisé d’autres choses), le plus gros obstacle est de convaincre tout le monde que le changement radical est meilleur à long terme.
Ensuite, vous avez besoin d'un autre mot: "rentable".
Le patching ou la mise en page facilitent les conceptions, les développeurs et les clients car ils sont rapides. Ils grattent une démangeaison avec un effort minimal. Et plus les gens hésitent à corriger un site Web qui se brise avec le moindre contact, moins il y a de chances que quelqu'un suggère un plus grand mal de tête.
Mais c'est un signe certain que le changement est nécessaire. La fonctionnalité draconienne se produit lorsque les concepteurs et les concepteurs redoutent réellement les changements. Vous connaissez le projet: celui avec l'historique des dossiers avec son propre classeur, avec le propriétaire dont la voix fait frémir les gens, et les processus décousus qui nécessitent des manuels d'utilisation que personne n'a le temps d'écrire.
Ces projets coûtent plus cher que de l'argent. Ils épuisent moralement les porcs de la ressource qui retiennent l'attention des projets plus récents et plus agiles et causent suffisamment de grincements de dents pour transporter les dentistes pendant la récession.
La guerre contre ce type de fluage des caractéristiques commence par la définition des problèmes , y compris les problèmes découlant des solutions de résolution des symptômes.
Repenser complètement en regardant à long terme, à la fois dans le passé et dans le futur. Le site était génial à l'époque, mais les choses ont changé. La technologie s'est améliorée. Les produits ou services du client ont évolué. Les clients sont plus (ou peut-être moins) sophistiqués ou ont des besoins différents.
Concevoir un plan pour rendre cette transition pratique . Les détails dépendent de la nature du site Web mais reviennent à la même chose: convaincre le client que le remède radical n’est pas pire que le cours actuel sur le chewing-gum et le fil de fer. C'est la guerre psychologique autant que la résolution de problèmes techniques.
Cela va arriver
La plupart des fonctionnalités prennent deux formes: une démangeaison que le client veut gratter et un réel besoin de changement.
Si vous pouvez formuler la demande en tant que question , vous vous positionnez comme un décideur plutôt que comme quelqu'un qui suit chaque caprice mal informé du client.
Réalisez que le changement se produira. Un site Web qui ne change jamais est un puits noir.
Ben Gremillion est un web designer freelance qui a appris que les clients réagissent bien si vous pouvez garder votre calme quand ils perdent les leurs.
Comment gérez-vous le fluage des fonctionnalités? S'il vous plaît partager certaines de vos expériences avec nous ...