Concepteurs Web au travail

[Diakotte]

Salut. Je suis un concepteur de sites Web débutant. Qui travaille aussi dans ce sens ? Quels conseils donneriez-vous à un débutant ?

 

[SergioVE]

Déjà ça dépend de ce que tu entends par "concepteur", ce serait bon de préciser.
En attendant, quelques idées générales.

- Avant tout, bien maîtriser les outils nécessaires.
- Exiger un cahier des charges précis du client. Sinon, c'est foutu à coup sûr.
- Ecouter le client.
- Etre ferme avec le client.
- Respecter le cahier des charges du client.
- Tenir les délais annoncés au client.

Et puis un point de vue très personnel : "Peu importe si c'est faux, du moment que c'est joli." Parce qu'un bug sur un site esthétiquement réussi, ça passe mieux que pas de bug sur un site hideux.

Cela dit, si @magellan passe par ici, il pourra peut-être te mitonner un de ses résumés pédagogiques magistraux dont il a le secret.

 

[magellan]

@SergioVE t'a explicité les éléments généraux... mais honnêtement ce que tu demandes est terriblement vaste! En gros tu as trois domaines à comprendre
- L'aspect fonctionnel (ce que ça doit faire)
- L'aspect technique (comment ça le fait)
- L'aspect relationnel (pour qui tu le fais)

Les fondamentaux
- La RIGUEUR. Dans tous les cas, ce que tu dois maintenir c'est une rigueur absolue dans tous les aspects de la gestion de tes développements. J'y reviens ensuite dans chaque aspect.
- Comprendre ce que le client veut obtenir. Cela ne veut pas dire faire les âneries qu'il te demande, c'est d'avoir compris son besoin. C'est essentiel car ton rôle sera de les conseiller, d'avoir le dernier mot pour les décisions... quitte à aller contre les choix en face de toi. Si je caricature: ton client va te demander le bouton magique qui fait tout (du vécu), et tu devras être capable de lui expliquer que ça n'a pas de sens, mais en même temps de saisir ce dont il a vraiment besoin pour le faire.
- La capacité à communiquer. Dans tous les cas, ce sont les échanges (équipes, chefs, clients, utilisateurs...) qui vont déterminer si un projet fonctionne ou pas. Qu'importe s'il y a des bugs, à condition que ce soit identifié, expliqué, et que des décisions soient prises de partout. Le "ça marche pas" sans explication n'est pas acceptable. "ça ne marche pas on sait pourquoi" ça devient plus tolérable. "ça ne marche pas et on a décidé quoi faire" est l'idéal. tu peux aussi bien laisser (parce qu'on s'en fout), corriger (parce que ça sert), ou supprimer la fonctionnalité (parce qu'elle est inutile ou impossible à faire marcher).

Je fais des posts complémentaires pour expliciter tout ça

 

[magellan]

La technique
En tant que débutant, oublie de vouloir tout savoir faire. C'est strictement impossible. Tu as besoin d'expérience, et cela ne s'apprend pas. Il faut vivre les projets, se confronter à des problèmes concrets pour savoir comment réagir.
Ce qui est important
- Connaître les constitutifs de ton projet: comme c'est du web ça va donner
* Quels sont les éléments techniques du serveur (back-end)
* Quels sont les éléments du front-end
* Selon le type de service, s'il y a ou non une base de données (SGBD, base de données objet genre MongoDB?)
* Intégration de l'ensemble: Cloud? Hébergement dédié? En interne?

Les aspects sécurité sont vitaux à réfléchir
- Authentification pour visualiser de la donnée?
- Y-a-t-il de la donnée sensible qui est consultable?
- Quelles sont les informations autorisées en visualisation (CNIL/RGPD)

Et là, tout ça s'est bien mais... il faut gérer tout ça!
- DOCUMENTER! J'insiste énormément là-dessus, car ce que tu fais aujourd'hui te semblera obscur dans six mois à peine. Nul n'est omniscient, nul ne peut prétendre à une mémoire totalement absolue. Donc DOCUMENTER est vital
- COMMENTER son code! Que je maudis les imbéciles qui ne mettent pas de commentaires! Il faut décrire même en trois mots pour dire "ça fait ça comme ça" ou juste "méthode de recherche" (pour l'exemple)
- NORMER son code! Quand on crée une procédure/méthode/constructeur, on le rend EXPLICITE. Rien ne me gonfle plus qu'une méthode qui s'appelle "BiduleTruc" sans explication, alors que son nom serait plus logiquement "ChercherElementComptable". Il en va de même pour les variables. Pas de "var toto" ou encore "const titi". NON! On leur donne un NOM pour que cela LISIBLE.

Tu codes? Très bien... maintenant il ne faut pas perdre tout ce boulot si chèrement réalisé.
- ARCHIVER: On archive son code de diverses manières. Je parle d'une sauvegarde brute de tous les éléments pour avoir un cliché complet de ton environnement au cas où (vécu: le "au cas où peut TOUJOURS arriver... surtout un HDD qui décide de rendre l'âme au pire moment)
- GERER: On fait du suivi de version. Peu importe ce que tu choisis (Git, Bitbucket... on s'en fout) mais il en faut un. Mieux: en gérant correctement les montées de version, tu peux revenir en arrière si tu as mis un bout de code par erreur qui mérite de revenir à une version antérieure.
- DOCUMENTER: Oui ici aussi, on COMMENTE les commit faits sur Git. On ne fait pas un git push "on s'en tape" mais un git push "Mise à jour pour correction de l'anomalie #400" (idéal si tu es lié à un gitlab pour savoir quelles modifications corrigent quoi)

 

[magellan]

Le fonctionnel

ça n'a l'air de rien mais pour moi un bon développeur (web ou non) c'est un développeur qui comprend ce que son client veut obtenir. Schématiquement, je me fous d'avoir dans mon équipe un génie du code mais qui ne pige pas ce que son client veut faire! ça te semble idiot? Pourtant... la sous-traitance amène souvent à confier les tâches "chiantes" comme rédiger des méthodes sans pour autant exprimer le besoin... et donc obtenir du n'importe quoi qui correspond, hélas, à la demande faite car l'interprétation est toujours possible.

Ce qui est FONDAMENTAL
- avoir des ECRITS. "Les paroles s'envolent, les écrits restent". Un cahier des charges est vital, même s'il est succinct. Il faut savoir ce que tu dois faire pour tenter de le faire correctement. Mieux: s'il y a des manquements dans ce CdC, cela peut devenir contractuel pour dire au client "vous n'avez pas décrit, je ne peux rien faire"
- COMPLETER: Toujours compléter la documentation à chaque nouveau projet. Il faut écrire ce que ça doit faire, même si c'est à grosses mailles. Comme ça, celui qui t'aide ou prend ton relai saura quoi faire, ou tout du moins comprendra mieux que sans rien pour l'aider.
- NORMER: En cas d'échanges (SOAP, intégrations de flux...) rédiger des normes claires et explicites permettra de bien faire le boulot, voire d'y trouver les éventuels manques/corrections à apporter sur les interfaces
- ECHANGER: si ton client ne donne pas assez d'informations, toujours POSER DES QUESTIONS. Je dis sans arrêt "ne crois pas avoir compris, parce que la croyance n'existe pas en technique ou en fonctionnel. Soit tu as compris et tu sais quoi faire, soit tu ne sais pas et tu dois demander à qui le sait".

Les outils
- Le mail! TOUT archiver. Oui: archiver, suivre, mettre en copie, ces échanges sont indispensables pour de la traçabilité
- Un tableur (peu importe lequel): un fichier Excel (ou autre mais résumons par excel) résume autrement mieux que des dizaines de lignes de texte imbuvable. Avec un Excel, tu sais quelles sont les tâches en un coup d'oeil, et tu peux le transmettre, l'améliorer, le corriger à la volée.
- Un outil de suivi d'anomalies/améliorations. Il y en a des dizaines qui ont chacun une philosophie. Trello est pratique pour des boards de suivi, mantis est un vrai suivi de tickets, et personnellement j'utilise Gitlab pour le lien natif avec les problématiques Git. C'est un choix à faire en interne mais c'est vital pour suivre les incidents. Avec ça tu as une vision du
* J'ai un incident
* J'ai sa description
* Quand c'est arrivé
* Qui le prend en charge et le règle
* Est-ce que cela a mené à des corrections du code

 

[magellan]

Les échanges avec les clients/utilisateurs
Tu n'y couperas pas. Tôt ou tard tu devras échanger... et là, c'est un vrai sport en soi, et cela peut même être bien plus dur et pénible que tout le reste réuni. Rien n'est plus insupportable qu'un client de mauvaise foi...

Les fondamentaux
- Toujours instaurer une relation de confiance basée sur "je comprends ce que vous voulez, je vous montrerai qu'on peut ou pas le faire"
- Echanger de manière claire et explicite. Documenter et fournir des prototypes/maquettes en posant des questions implique le client, et rendra plus claire le chantier à mener
- Ne pas accepter n'importe quoi. Oui c'est bien de facturer, c'est mieux de le faire en sachant que cela débouchera sur un fonctionnement cohérent. Enfumer le client en lui vendant du rêve est suicidaire, car le réveil est d'autant plus douloureux qu'il est facturé trop cher.
- Valider clairement chaque changement afin qu'en cas d'insatisfaction tu puisses démontrer que cela vient non pas d'une décision de ta part, mais d'une demande chez ton client.
- Ne jamais oublier l'amabilité... tout en incluant tous les étages hiérarchiques en cas de souci. Rien n'est plus efficace que de mettre en copie les hiérarchies pour faire réduire la pression, ou au contraire pour la faire monter si des intervenants traînent les pieds.
- Avoir une certitude, celle que tu ne sais rien. Si ton client te demande un truc qui semble idiot/absurde/hors sujet, l'interroger pour voir si ce n'est pas toi qui n'a pas saisi son besoin. Rien n'est pire que de se croire plus compétent que son client (même si c'est hélas bien souvent le cas... parce que le client ne jure que par son besoin alors que toi tu vas sûrement jurer que par ta technicité).

 

[magellan]

La vie d'un projet

Là... entre l'école qui te vend du rêve, et le réel où le rêve tourne souvent au cauchemar, il y a des choses à appréhender et à accepter

- Tu n'es pas développeur pour t'amuser. Si tu as un arbitrage technique à faire (choisir une technologie) tu dois le faire en connaissance de cause. Ton client n'est pas un cobaye avec qui tu vas tester ce qui marche... ou pas. Pas question de choisir un framework exotique sous prétexte de le tester. Tu veux faire de la veille techno? Ok! Pas de problème... mais pas sur le dos du client! Lui te paye pour que CA MARCHE, pas pour que tu T'AMUSES. Tu peux t'éclater avec des choses déjà validées et fiables, alors ne t'ajoute pas une couche de complexité par curiosité mal placée.
- Les cycles de développement sont complexes à décrire. Ce que tu dois définir et admettre, c'est qu'il y a une organisation claire à établir
* Qui décide
* Comment on découpe les tâches
* Qui teste
* Qui gère les retours client
* Qui assume les relations clients/utilisateurs
Ces aspects sont essentiels. les cycles en "V" et les cycles "Agile" sont radicalement différents, et les deux font sens dans des environnements différents. Savoir comment le projet est géré, c'est savoir comment réagir en cas d'incident.
- Il faut avoir du bon sens. Ne fais pas quelque chose qui n'a pas d'utilité, et encore moins du développement pour le fun. Si le projet se termine et que tu as du temps à perdre, là oui coller un bonus au client (surtout si la relation est saine) ne fait pas de mal commercialement parlant. Mais pas question de perdre du temps: tu es là pour faire de l'argent, tu n'es pas une association caritative!
- Ne PAS accepter le crunch! Je le martèle: pas question de faire du crunch suite à des bourdes du commerce ou lors de l'estimation de la charge. Tu peux envisager un peu d'heures complémentaires... mais pas systématiquement. Quand tu donnes le doigt on te prend le bras. J'ai pratiqué du crunch de dingue et ça n'arrivera plus jamais! Plutôt démissionner ou me coller en arrêt maladie.

Petite anecdote: Suite à des dérives du projet, on est passés d'un 8h/jour à 12h/jour pour envisager de livrer à temps.. mais concrètement, le dernier jour (un mercredi) on a bossés jusqu'à 6h30 du matin (donc de 9h le mercredi à 6h30 le lendemain). J'ai pris la bagnole, déposé les fichiers sur un CD gravé (ça date), puis rentré me doucher, dormir 4h, reprendre la bagnole pour aller chez le client pour contrôler la mise en production. Enfin train le soir même pour descendre à Marseille, quelques heures de sommeil et démarrage à 6h le vendredi chez un autre client pour bosser.. jusqu'au samedi matin à 5h.
PLUS JAMAIS CA.

 

[magellan]

Pour finir, j'insiste très lourdement sur la rigueur. C'est pour moi LA qualité première d'un bon développeur. Nul besoin d'être un génie ou le seul expert de la planète. Si tu es rigoureux, tu pourras faire évoluer ton projet, le comprendre et te l'approprier.

Il y a aussi une énorme part d'humilité à avoir
- Tu ne sais pas tout sur la technique. Je n'ai aucun scrupule à revoir X fois des choses pourtant élémentaires sur des sites techniques pour me rafraîchir la mémoire. "Ce que je crois savoir n'est pas ce que je suis supposé faire". Avec cet adage tu sauras avancer
- Tu ne connais pas ton client de manière parfaite. Il faut apprendre son métier, le cerner, et accepter que tu n'as pas tout compris. Plus tu sauras de quoi il parle, mieux tu pourras répondre à ses attentes et le faire dans un délai toujours plus rapide.
- N'entube pas ton client. Tu peux prendre une marge d'erreur confortable... pas multiplier les délais par 10 pour faire plaisir au commerce. On n'est plus dans les années 80/90 où le client ne comprenait pas notre métier. Bien souvent, dès que le client a une certaine taille, il aura sous le coude au moins un profil technique capable de comprendre ton chiffrage.
- Communiquer c'est vital. Si tu bosses en équipe, échanger même de manière très rapide (un mail/visio/autour d'un café) fait gagner un temps fou! Fais le et tu en apprendras plus, surtout des "dos gris" comme je le suis désormais. J'ai plus de 20 ans de métier, et 35 ans d'utilisation de l'informatique... donc j'ai une forme "d'instinct" pour renifler les conneries avant qu'elles se présentent. Si tu écoutes l'expérience (tout en prenant soin de vérifier et non de croire sur parole), tu ne feras que progresser.
- Ne te laisse surtout pas embarquer sur des sujets que tu ne maîtrises pas sans avoir pris soin de prévenir que tu ne connais pas le propos. Pas de "oui j'apprendrai" sans avoir déjà pris le temps de te documenter. Maîtriser un environnement, une architecture, ou plus basiquement un langage, ça ne se fait pas en trois jours. On dit bien "Rome ne s'est pas faite en un jour", la compétence en va de même.

 

[Diakotte]

Je n'espérais même pas une réponse aussi complète et utile. Merci de partager autant d'informations utiles.

 

[magellan]

Je n'espérais même pas une réponse aussi complète et utile. Merci de partager autant d'informations utiles.

De rien. Cela fait partie de mes attributions de chef de projet et développeur. C'est donc mon quotidien et je préfère ne pas dorer la pilule aux débutants. Le développement, c'est en général 10% de plaisir pur technique pour 70% de codage chiant et 20% de paperasse pénible.

 

[SergioVE]

De rien. Cela fait partie de mes attributions de chef de projet et développeur. C'est donc mon quotidien et je préfère ne pas dorer la pilule aux débutants. Le développement, c'est en général 10% de plaisir pur technique pour 70% de codage chiant et 20% de paperasse pénible.

Les débutants ne mesurent pas la chance qu'ils ont. On n'a plus à se préoccuper comme autrefois de devoir contrôler totalement la saisie de données : l'alpha dans le numérique, la position du point décimal (ou de la virgule), la cohérence d'une date, la présence des champs obligatoires...

 

[magellan]

Les débutants ne mesurent pas la chance qu'ils ont. On n'a plus à se préoccuper comme autrefois de devoir contrôler totalement la saisie de données : l'alpha dans le numérique, la position du point décimal (ou de la virgule), la cohérence d'une date, la présence des champs obligatoires...

Au final paradoxalement tu te cognes encore plus de contrôles aujourd'hui parce que justement le côté "souple" du code (Javascript je te hais pour ça) permet de mettre n'importe quoi dans une variable.

avec un typage fort, tu bétonnes concrètement les zones et la saisie, chose que le typage faible ne fait pas immédiatement.... mais là où tu as parfaitement raison, c'est que ce nombre de débutants ne prêtent pas attention à ça puis ensuite souffrent pour piger pourquoi leurs données sont égarées. Que "j'aime" taquiner un débutant quand il essaye de stocker la valeur 15 en base de données, qui est au final "15" (en texte), ce qui fait que la conversion non implicite colle 0 dans la base! C'est "fun" à expliquer... enfin une fois, pas tous les jours.

 

[Diakotte]

Je ne suis activement engagé dans la conception de sites Web que depuis six mois, avant cela, je le considérais comme un passe-temps. Toutes les connaissances sont nouvelles pour moi, chaque jour je maîtrise de nouvelles compétences et informations. J'utilise des béquilles comme la création graphique en ligne gratuit et d'autres outils. Mais le plus important, c'est que j'aime le faire.

 

[SergioVE]

Que "j'aime" taquiner un débutant quand il essaye de stocker la valeur 15 en base de données, qui est au final "15" (en texte), ce qui fait que la conversion non implicite colle 0 dans la base! C'est "fun" à expliquer... enfin une fois, pas tous les jours.

Ma variante c'était de saisir une date du style 37/14/2021, avec un débutant, c'était accepté à 99%...
J'ai eu une engueulade effroyable avec un responsable des données mainframe qui me descendait des échéances fin de mois systématiquement datées du 31. "Ben oui, c'est plus pratique..." !
Cela dit, je n'ai pas fait d'essais, mais un drame nous attend peut-être fin février 2100.

 

[magellan]

Je ne suis activement engagé dans la conception de sites Web que depuis six mois, avant cela, je le considérais comme un passe-temps. Toutes les connaissances sont nouvelles pour moi, chaque jour je maîtrise de nouvelles compétences et informations. J'utilise des béquilles comme la conception graphique en ligne gratuite et d'autres outils. Mais le plus important, c'est que j'aime le faire.

Je te souhaite que cela perdure. Pour ma part, la technologie est une chose passionnante... mais avant toute chose alimentaire! J'ai ce cynisme de vieux con qui sait que se faire plaisir c'est bien, bosser c'est mieux. Après j'ai un caractère particulier vu que j'ai fait de nombreux métiers différents. Cela fait de moi quelqu'un qui fera un autre métier si le destin le nécessite vraiment. J'ai la chance de pouvoir être assis sur une chaise confortable, avoir un ordinateur sous le nez et la clim (au bureau) pour ne pas souffrir de la chaleur ou du froid. Je reconnais donc d'avoir un métier assez peinard face à ce que j'ai pu faire avant.

J'insiste très lourdement sur quelques aspects à prendre en compte au fil de sa carrière
- Respecter l'expérience d'autrui même si ce n'est pas la même ou même celle utile au projet. Avoir une fondation solide, même dans une technologie obsolète, c'est aussi avoir vécu la communication, le travail en équipe, les périodes de crise... bref la vie des projets!
- Il n'y a rien d'éternel dans notre métier (sauf le COBOL!) ... comprenne qui pourra!
- Le langage et l'organisation technique ne sont qu'un vocabulaire et une grammaire. Ce qui comptera toujours, c'est le propos. Donc, tu seras amené à évoluer avec les technologies, réapprendre une syntaxe, mais ce qui sera fondamental c'est de comprendre ce que tu dois coder.
- On commence tous en bas... et on monte en compétence. On ne se prend pas pour un expert, car l'expertise vient avec le temps, et on trouvera toujours autour de soi un collègue qui sera possiblement meilleur que soi.
- Etre humble ne veut pas dire se faire humilier ou fermer sa gueule. Il faut savoir dire les choses même si elles sont désagréables. Ce qui est nécessaire par contre, c'est aussi d'écouter les autres. S'il y a eu des décisions, c'est qu'il y a eu une raison...

 

[magellan]

Ma variante c'était de saisir une date du style 37/14/2021, avec un débutant, c'était accepté à 99%...
J'ai eu une engueulade effroyable avec un responsable des données mainframe qui me descendait des échéances fin de mois systématiquement datées du 31. "Ben oui, c'est plus pratique..." !
Cela dit, je n'ai pas fait d'essais, mais un drame nous attend peut-être fin février 2100.

Ou ces blagues de [CENSURE] où le format côté serveur est à l'anglaise, et que la donnée réceptionnée n'est pas analysée. Et là... le type qui teste te met comme date de validation le 06/06/2021 ... et là oui ça marche. Et moi pourri comme je suis 28/02/2021 et entendre le dev pleurer/gueuler face à mes tests agrémenté d'un "mais comment tu as fait pour planter mon service?!"

 

[SergioVE]

Ou ces blagues de [CENSURE] où le format côté serveur est à l'anglaise, et que la donnée réceptionnée n'est pas analysée. Et là... le type qui teste te met comme date de validation le 06/06/2021 ... et là oui ça marche. Et moi pourri comme je suis 28/02/2021 et entendre le dev pleurer/gueuler face à mes tests agrémenté d'un "mais comment tu as fait pour planter mon service?!"

C'est un point à signaler à @Diakotte. Ne pas se contenter de ses propres tests ; on a naturellement et instinctivement tendance à tester ce dont on sait que ça va fonctionner, alors que l'utilisateur, même si on met de côté les âneries citées plus haut, va tester ce qu'il fait habituellement et qu'il maîtrise.

 

[magellan]

C'est un point à signaler à @Diakotte. Ne pas se contenter de ses propres tests ; on a naturellement et instinctivement tendance à tester ce dont on sait que ça va fonctionner, alors que l'utilisateur, même si on met de côté les âneries citées plus haut, va tester ce qu'il fait habituellement et qu'il maîtrise.

C'est un sujet en soi tant c'est vaste...

 

[chonos]

Ou ces blagues de [CENSURE] où le format côté serveur est à l'anglaise, et que la donnée réceptionnée n'est pas analysée. Et là... le type qui teste te met comme date de validation le 06/06/2021 ... et là oui ça marche. Et moi pourri comme je suis 28/02/2021 et entendre le dev pleurer/gueuler face à mes tests agrémenté d'un "mais comment tu as fait pour planter mon service?!"

Salut,
on peux te cloner ?
car ici ou je suis c'est un peux "beaucoup" comme cela ;-)
l'autre fois ils nous ont supprimer les "-" dans les nom composé de AD !
je te laisse deviner les pb que cela a générer !

j'ai ici 2 salles pour les recettes (presque personnes les utilises jusqu'à présent )

 

[magellan]

Salut,
on peux te cloner ?
car ici ou je suis c'est un peux "beaucoup" comme cela ;-)
l'autre fois ils nous ont supprimer les "-" dans les nom composé de AD !
je te laisse deviner les pb que cela a générer !

j'ai ici 2 salles pour les recettes (presque personnes les utilises jusqu'à présent )

Il y a un règle élémentaire : toute donnée en entrée doit être contrôlée! Je ne compte plus le nombre de saisies que j'ai fait sciemment planter chez mes devs parce que "monsieur ne daignait pas valider qu'on est sur une zone de montant ... et non une zone de texte".