Catégories
Plugin et site web

Alors, vous avez gagné une refonte passionnante… Et maintenant?

La transition du pouvoir est semée de difficultés. Différentes équipes ont des valeurs différentes, des expériences différentes, des expertises différentes, des priorités différentes, ce qui conduit à différents outils et méthodologies.

Il est tentant de considérer la conception Web comme un processus de bout en bout, commençant par la recherche et se terminant par des métriques. La réalité est que la plupart des concepteurs et développeurs rejoignent des projets à mi-chemin d'un processus continu.

Cela nous laisse un choix difficile: essayons-nous de répondre aux attentes du client avec notre propre ensemble d'outils, ou nous adaptons-nous aux outils et processus déjà en place?

Pour toute personne prenant en charge un projet Web d'un autre concepteur / développeur / agence (D / D / A), voici un guide pratique pour vous aider à réussir la transition.

Étape 1: Découvrez ce qui n'a pas fonctionné

99,99% du temps, quelque chose est tombé en panne dans la relation client-D / D / A précédente.

D'après mon expérience, ce n'est presque jamais une question d'argent. La plupart des clients sont prêts à payer au-dessus du taux de base du marché s’ils estiment obtenir un bon retour sur leur investissement. Un client qui vous dit que le D / D / A précédent est tout simplement trop cher anticipe la négociation votre honoraires.

les clients satisfaits ne font pas de shopping

Parfois, vous constaterez qu'un designer indépendant a été chassé par une agence et n'est plus disponible. Parfois, l'entreprise dépasse un D / D / A, se déplaçant dans des domaines que le D / D / A ne prend pas en charge. Mais ces situations sont rares, les clients satisfaits – même les clients moyennement satisfaits – ne font pas le tour. S'ils vous parlent, quelque chose les a motivés à le faire.

Il est très courant qu'un D / N / A passe simplement à AWOL. Il est le plus courant dans le bas du marché où les sommes d'argent impliquées sont moins susceptibles de provoquer un litige. Souvent, un D / D / A peu réputé fantôme un client en faveur d'une meilleure opportunité plus récente.

Parfois, le client engage un nouveau responsable, et le nouveau responsable introduit des attentes révisées que le D / D / A précédent ne peut pas satisfaire.

Le plus souvent, le D / D / A précédent a raté le ballon trop souvent – des erreurs se produisent et des clients raisonnables les toléreront à condition d'être corrigées rapidement, mais chacun a ses limites.

La plupart des clients seront plus qu'heureux d'expliquer ce qui n'a pas fonctionné dans la relation précédente; ce sera inévitablement une explication unilatérale, mais cela vous aidera à comprendre les attentes du client.

Soyez extrêmement méfiant envers un client qui ne sait pas ce qui ne va pas. Méfiez-vous encore plus d’un client qui parle de «mettre à niveau» sa sous-traitance – il essaie de vous flatter. Dans ces cas, le client peut bien cacher quelque chose – comme son défaut de paiement des factures.

Rappelez-vous: à un moment donné, le D / D / A précédent était nouveau et excité d'avoir un nouveau client, était optimiste quant au projet, et cela ne s'est pas bien terminé. La meilleure façon de ne pas répéter les erreurs est d'en tirer des leçons et, pour ce faire, vous devez savoir ce qu'elles étaient.

Étape 2: Réaliser un audit complet

Nous sommes souvent si désireux d'obtenir de nouveaux travaux que nous nous précipitons pour que le client signe sur la ligne pointillée, en espérant pouvoir résoudre les problèmes plus tard.

Il est impératif qu'en tant que professionnel, vous tenez vos promesses. Avant de faire ces promesses, prenez votre temps pour comprendre le projet et les activités connexes. Si un client est suffisamment investi pour signer un contrat avec vous, cela ne vous dérangera pas de faire d'abord une diligence raisonnable.

Existe-t-il encore une relation avec l'ancien concepteur / développeur / agence?

Les clients ont rarement une image complète de leur projet – ils ne sont pas des professionnels du Web, s'ils l'étaient, ils créeraient leurs propres sites. Votre meilleure source d'information est le D / D / A précédent.

Avant de contacter le précédent D / D / A vérifier avec votre client; il est possible qu’ils ne sachent pas encore qu’ils sont remplacés. Si votre client est d'accord, contactez-le.

Lorsque vous parlez au D / D / A précédent, soyez sensible au fait que vous sortez de l’argent de sa poche. Certes, le D / D / A précédent peut vous dire où aller, il peut vous ignorer complètement, mais la plupart seront pragmatiques quant à la remise d'un projet ne serait-ce que pour s'assurer que leur facture finale à leur ancien client est payée rapidement.

Chaque site a ses particularités, si vous pouvez établir un rapport amical avec le D / D / A précédent, la transition sera considérablement moins cahoteuse.

Qui contrôle le (s) nom (s) de domaine?

À mon avis, le ou les noms de domaine d’une entreprise devraient toujours être détenus par l’entreprise; c’est un atout commercial tellement essentiel qu’il doit être gardé aussi jalousement que les comptes bancaires de l’entreprise.

Malheureusement, il existe des entreprises qui sous-traitent tout ce qui concerne le Web. Si la rupture avec le précédent D / D / A est acrimonieuse, la sécurisation du nom de domaine pourrait être problématique.

Ce n’est pas votre travail de sécuriser le nom de domaine – vous n’avez aucun effet de levier, contrairement au client. C'est votre travail d'imprimer au client à quel point le (s) nom (s) de domaine est essentiel à la mission.

Qui contrôle l'hébergement?

Les modalités d'hébergement varient d'un projet à l'autre. Il n’est pas rare ni déraisonnable que le D / D / A précédent héberge le site du client sur son propre espace. Si tel est le cas, préparez-vous à le migrer rapidement soit vers votre propre serveur, soit vers un espace dédié.

Si vous migrez vers un nouvel espace, portez une attention particulière à la fourniture des e-mails. Prendre en charge un projet signifie généralement reprendre un projet en direct, ce qui signifie généralement des comptes de messagerie.

Dans tous les cas, vous avez besoin d'un accès complet à l'espace d'hébergement. Vous avez certainement besoin d'un accès FTP, vous avez probablement besoin d'un accès SSH.

En plus de l'hébergement, vérifiez si le site de votre client utilise un CDN, et si c'est le cas, qui en a le contrôle.

Code source du backend

Une fois que vous avez un accès FTP au serveur d'hébergement, vous pouvez probablement récupérer tout le code backend du serveur.

L'avantage de récupérer le code du serveur – par opposition à l'acceptation de fichiers du D / D / A précédent – est que vous pouvez être absolument certain que vous obtenez le code actuel (de travail).

Si le client a rompu avec le D / D / A précédent parce qu'il n'a pas pu exécuter une tâche particulière, vous ne voulez pas travailler avec des fichiers qui ont été partiellement modifiés.

Nouvelles installations

Si vous travaillez avec quelque chose comme un CMS, il est souvent judicieux d'exécuter une nouvelle installation sur votre serveur, puis de copier sur tous les modèles, plug-ins et de migrer la base de données.

Code source du frontend

Lorsqu'il s'agit d'acquérir du code source, le code frontend est beaucoup plus problématique que le backend.

le code frontend est beaucoup plus problématique que le backend

Si le D / D / A précédent est même partiellement compétent, le CSS et le JavaScript de l'espace Web sont réduits au minimum. Le CSS minifié n'est pas trop problématique et peut être unminifié assez facilement, mais vous ne voulez pas décoller un fichier JavaScript minifié – j'ai eu une fois un projet dans lequel un développeur avait minifié son propre code dans le même fichier avec toutes ses dépendances, y compris Vue et jQuery (oui, je connaître).

La gestion du code source frontal peut prendre une dimension supplémentaire si vous découvrez que le D / D / A précédent utilisait des techniques que vous n’avez pas utilisées – en utilisant Less au lieu de Sass, ou en écrivant des scripts en TypeScript.

Unminifying CSS & JavaScript

Unminifying (ou embellir, ou embellir) est assez simple. Il existe des outils en ligne qui vous aideront, notamment Unminify, Online CSS Unminifier, FreeFormatter, JS Minify Unminify, etc. Vous trouverez également de nombreuses extensions pour les éditeurs de code, notamment HTML-CSS-JS Prettify pour Sublime Text et Atom-Beautify pour Atom. Vous constaterez que certains éditeurs ont la fonctionnalité intégrée.

Un mot d'avertissement: l'embellissement du code ne restaure pas les commentaires, et dans le cas de JavaScript, ne désobserve pas les noms de variables. Le code d'embellissement ne remplace pas une copie du code source original non réduit.

Mesures d'urgence

Si la suppression du code source n'est pas possible pour une raison quelconque, ou plus probablement, le JavaScript non minimisé ressemble toujours à du code minifié – bien que bien formaté – alors votre dernier recours est d'importer le code et de le remplacer si nécessaire.

La première chose à faire dans ce cas est d'expliquer la situation à votre client. Assurez-vous qu'ils comprennent qu'il s'agit d'un correctif temporaire que vous corrigerez lors de la reconstruction de certaines parties du projet.

Ensuite, copiez et collez l'ancien code minifié dans une nouvelle configuration de projet. Pour CSS, cela signifie probablement créer un legacy.scss fichier, y compris l'ancien CSS, et l'importer dans votre propre Sass. Pour JavaScript, créez un legacy.js fichier, ajoutez tous les anciens JS et importez-les.

Cela entraînera un ensemble de fichiers beaucoup plus grand que nécessaire, vous pouvez finir par utiliser !important dans vos déclarations de style (beurk), et vous déclencherez de nombreux avertissements Lighthouse concernant le code excédentaire.

Cependant, dans le cas probable où votre client aurait une longue liste de changements qu'il souhaitait vivre hier, ce sale hack vous donnera un site fonctionnel que vous pourrez ensuite reconstruire pièce par pièce au fil du temps.

Les atouts

Les actifs signifient normalement des images, et les images peuvent normalement être récupérées via FTP.

Parfois, même si les fichiers image contiennent rarement du texte, vous aurez besoin des fichiers source pour apporter des modifications aux images.

Que le client les ait ou non, ou si le D / D / A précédent les remettra, dépend en grande partie de l'accord entre le client et le D / D / A précédent.

La plupart des entreprises sont raisonnablement conscientes de l’importance des actifs de la marque. Vous constaterez donc qu’elles ont au moins une copie de leur logo. que ce soit un SVG ou un JPG est une tout autre affaire. Faites-leur comprendre l'importance de localiser ces fichiers pour vous.

Code tiers

Il est rare de recevoir un projet qui ne repose pas sur un code tiers. Ce code tiers est probablement imbriqué dans le code source personnalisé, et le décoller est un travail qui prend du temps.

Il est très probable que le D / D / A précédent utilisait une bibliothèque ou un framework, et étant donné le nombre croissant d'entre eux, il est encore plus probable que la bibliothèque ou le framework qu'ils utilisaient ne soit pas celui que vous préférez.

Que vous choisissiez de décoller le code et d'échanger les dépendances précédentes de D / D / A pour vos propres préférences (généralement plus rapidement à long terme), ou si vous choisissez de travailler avec ce qui vous est donné (généralement plus rapidement à court terme) ) dépend entièrement de vous.

D'après mon expérience, il n'est pas difficile de choisir une autre bibliothèque CSS; passer d'un framework JavaScript à un autre est un travail beaucoup plus important impliquant non seulement la syntaxe, mais des concepts de base.

Méfiez-vous des environnements de construction

Chacun a sa propre façon de faire. Certains D / D / As embrassent des environnements de construction, d'autres non. Certains environnements de construction sont simples à utiliser, d'autres non. Certains environnements de construction sont adaptables à votre processus, d'autres non.

Contrairement à l'adoption d'une bibliothèque, ou même d'un framework, l'adoption d'un nouveau processus de construction est rarement une bonne idée

Les environnements de construction sont nombreux – Gulp, Grunt et Webpack sont tous populaires – et D / D / As le sont presque aussi avisés à leur sujet qu’à propos de CMS.

Au lieu de fichiers bruts, il n’est pas rare que le D / D / A précédent vous dise de «simplement exécuter telle ou telle commande CLI», pour faire correspondre votre environnement local au leur. Contrairement à l’adoption d’une bibliothèque, ou même d’un cadre, l’adoption d’un nouveau processus de création est rarement une bonne idée, car vous vous reléguez d’expert à novice à un moment où vous n’avez pas encore gagné la confiance de votre nouveau client.

Défend ton territoire. Leur approche a échoué, c’est pourquoi vous avez été amené.

Qui est licencié?

Tout code tiers payé est concédé sous licence. Vérifiez toujours qui détient ces licences. En plus d'être légalement requises, des licences valides sont normalement requises pour les mises à jour, les corrections de bogues et, dans certains cas, l'assistance.

Les pièges courants incluent: les licences de polices (qui peuvent être concédées sous le compte Creative Cloud, Fontstand, Monotype, etc. de l'ancien D / D / A); les licences d'images de stock (qui peuvent être utilisées par le D / D / A précédent uniquement); et les plugins (qui sont souvent concédés en masse sous licence D / D / As dans des bundles).

Il est extrêmement courant de trouver des clients utilisant des actifs sans licence. À plusieurs reprises, j’ai dû expliquer à un client les conséquences potentielles de l’utilisation de polices piratées.

Heureusement, il est de plus en plus courant pour les fournisseurs tiers d'associer une licence à un domaine spécifié, ce qui signifie que vous pourrez peut-être réclamer la licence au nom de votre client. Les principaux fournisseurs comme les CMS et les solutions de commerce électronique ont souvent la possibilité pour le développeur précédent de libérer une licence et de vous permettre de la réclamer.

Dans le cas de la licence, si vous n'êtes pas sûr, n'hésitez pas à contacter le fournisseur tiers et vérifiez avec lui si votre client est licencié une fois qu'il a rompu les liens avec son ancien D / D / A.

La seule chose qui sape une relation client plus rapidement que de leur dire qu’ils doivent acheter une licence pour laquelle ils pensaient avoir déjà payé, c’est de leur dire qu’ils sont poursuivis pour violation des droits d’auteur.

Protégez votre client et protégez-vous en vous assurant que tout est correctement autorisé. Si vous pouvez obtenir quelque chose par écrit à cet effet à partir du D / D / A précédent, faites-le.

Qui a la recherche et les analyses?

L'un des principaux avantages de la reprise d'un site, par opposition à la création à partir de zéro, est que vous disposez d'un ensemble mesurable de données spécifiques au site pour guider votre prise de décision.

Cela ne s'applique que si vous disposez des données. Demandez donc à être ajouté au compte analytique du client.

Il y a de fortes chances que la recherche de conception effectuée par le D / D / A précédent soit considérée comme un document interne, et non comme un produit livrable, par le D / D / A précédent. Vérifiez auprès de votre client: s’il a payé la recherche (est-ce précisé sur une facture?), Il a droit à une copie.

Nous avons aussi un blog…

Les clients ont tendance à utiliser le terme «site Web» comme un terme fourre-tout pour tout ce qui est numérique.

Lorsque vous assumez la responsabilité d'un site Web, vous êtes presque toujours censé assumer la responsabilité de tout service numérique utilisé par le client. Cela signifie des services de newsletter comme Mailchimp, des comptes de service client comme Intercom et des blogs WordPress de 227000 pages qu'ils ont oublié de mentionner dans le brief initial.

Répétez l'ensemble de Étape 2 pour chaque application supplémentaire, micro-site, blog et tout ce que possède le client, à moins que le client ne vous le dise expressément.

Étape 3: Le point de non-retour

Jusqu'à présent, vous n'avez pas demandé au client de signer sur la ligne pointillée. Tout ce processus fait partie de votre diligence raisonnable.

En vérifiant ces éléments, vous pouvez identifier les problèmes imprévus et les coûts potentiels. Êtes-vous lié à un processus de construction obscur? Avez-vous besoin de renouveler la licence du CMS? Avez-vous besoin de recréer toutes les ressources du site?

Certaines de ces conversations sont difficiles à avoir, mais le moment est venu de les avoir

S'il est question que le projet soit plus complexe que prévu, ayez une conversation honnête avec votre client – il appréciera votre transparence et il appréciera d'être tenu informé. Tout client qui n’apprécie pas une image claire de ce pour quoi il vous paie n’est pas un client que vous voulez.

Certaines de ces conversations sont difficiles à avoir, mais le moment est venu de les avoir, pas trois mois plus tard.

C'est le point de non-retour. À partir de ce moment, les problèmes ne sont plus les précédents D / D / A, ils sont les vôtres.

Changer les mots de passe

Pour chaque service dont vous disposez, de la connexion à la newsletter, à la connexion au CMS, en passant par les détails FTP, changez le mot de passe. (Assurez-vous d'avertir le client.)

Configurer un site de préparation

Vous allez avoir besoin d'un site de préparation pour que votre nouveau client puisse prévisualiser le travail que vous avez fait pour lui.

Configurez le site de préparation immédiatement, avant d'apporter des modifications au code. Ce faisant, vous découvrirez rapidement s'il manque des fichiers ou des problèmes avec les fichiers que vous possédez.

Transition réussie d'un projet

Lorsqu'un client commande un site à partir de zéro, il est rempli d'attentes. Le fait qu'ils quittent leur ancien D / D / A pour vous chercher démontre que leur expérience n'a pas répondu à leurs espérances.

Vous avez maintenant un client avec des attentes réalistes, voire pessimistes. Vous disposez d'un repère par rapport auquel votre travail peut être objectivement mesuré.

Lorsque des problèmes surviennent, comme ils le feront invariablement, n'essayez jamais de blâmer le D / D / A précédent; c'était votre travail d'évaluer l'état des lieux avant de commencer à travailler. S'il y a un problème avec les anciens actifs, vous devez l'avoir signalé à votre client dès le début.

Si vous apprenez des erreurs du D / D / A précédent, vous ne remettrez pas le projet à quelqu'un d'autre de si tôt.

Image en vedette via Unsplash.

La source

p img {affichage: bloc en ligne; marge droite: 10px;}
.alignleft {float: gauche;}
p.showcase {clear: both;}
body # browserfriendly p, body # podcast p, div # emailbody p {margin: 0;}

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *