Cet article a d’abord été publié sur le blog d’ekino ; je l’ai en effet écrit dans le cadre de mon travail en tant qu’employée.
En général
Si j’avais du mal à comprendre le programme de Sud Web au moment de m’inscrire, j’y suis allée en pleine confiance malgré tout … et Ekino a bien eu raison de m’y envoyer !
Globalement, ces deux journées ont permis des échanges, des questionnements sur nos métiers, de la (re)motivation.
La journée des « élaboratoires » fut une grande réussite. « Ça a pris ». Du coup, j’ai pu, à l’instar d’autres auditeurs, picorer d’un atelier à l’autre, écouter, participer, repartir, m’arrêter discuter autour d’un café et repartir dans une salle.
D’autres sont restés de bout en bout à chacun des ateliers qu’ils avaient choisi et ont pu participer intensément.
Beaucoup d’ateliers ont été improvisés, comme l’organisation le permettait.
Ce fut une journée d’échanges (connaissances), d’échanges (rencontres) et d’échanges (conversations de tout ordre).
Ci-dessous, mes notes durant les conférences.
C’est quoi un lead developer
Brice Fabre – @briceatwork
Brice Fabre a présenté son métier en faisant un parallèle :
- avec le pompier qui gère les risques:
- intervient sur l’urgence,
- travaille en amont pour prévenir risques et accidents (tests unitaires et tests fonctionnels),
- éduque sur prévention et dangers (transmet les bonnes pratiques)
- avec l’archéologue qui fouille:
- recherche,
- analyse et chercher les usages possibles,
- inventorie et documente.
- avec le chef d’orchestre qui harmonise:
- fait partie de l’équipe,
- s’adapte aux spécifications,
- coordonne
Le lead developer n’est pas un chef, il est avec son équipe, il code avec son équipe.
En France, on ne promeut que par du niveau hiérarchique. Or, lead dev n’est pas chef mais est très bon techniquement et ça doit être reconnu (y compris au niveau salaire).
Il n’est pas le de chef de projet car le lead dev guide son équipe par la technique et guide le développement mais n’est pas en frontal avec le client.
Il incarne le produit (au moins dans le cas de Brice) et le connaît techniquement sur le bout des doigts. Cela représente par contre un investissement en temps dont l’entreprise doit être consciente.
L’Open Web en tant que pierre angulaire du développement multi-objets
Thomas Bassetto – @tbassetto
Thomas nous enjoint à penser dès maintenant que bientôt tout le monde aura des objets connectés partout (autre que type informatiques (mobile, tablette)). Il argumente alors pour des applications non web et donne l’exemple du miroir.
Nouvel objet connecté, le miroir héberge des interfaces qui prennent en compte les traces doigts : toutes les interactions se font à droite, les vidéo et images sur la gauche. Un site internet ne pourrait s’adapter car il ne pourra pas détecter qu’il s’agit d’un miroir.
Comment vendre des prestations agiles ?
Thibault Jouannic –@thibaultj
Présentation pleine d’humour nous mettant en condition : on reçoit un coup de fil d’un prospect voulant obtenir un devis et on doit le convaincre de choisir une prestation agile.
Les clients potentiels n’ont pas toujours une idée très précise de ce qu’ils veulent mais sont très précis quand on en vient au budget et au temps.
Quand on fait de l’agile, on n’est pas au forfait. Le client a la main sur les fonctionnalités donc on ne s’engage pas là-dessus.
Première étape : lui faire peur 😀
Si on vient voir un architecte alors que la maison est construite et qu’on lui dit que finalement, on voudrait un sous-sol, ça risque d’être très compliqué. Sur le web, on ne peut pas forcément savoir d’avance toutes les fonctionnalités, mais par contre, en mode agile, on peut facilement changer d’idée en cours de route.
Ensuite, lui proposer une alternative.
Avec beaucoup d’humour, Thibault propose d’en appeler aux « experts reconnus de l’industrie » qui valorisent l’agile.
Les arguments pour :
- Il n’y a pas de spécifications à rédiger (là, franchement, vous devriez déjà vous l’avoir mis dans la poche !)
- C’est lui qui définit les priorités
- On peut arrêter à tous moment
- On a le meilleur ROI à chaque instant du projet
- « La première livraison est dans deux semaines ! » (ça aussi, il va adorer !)
Par contre, il y a une grosse condition à poser :
- Lui aussi doit s’investir en temps et en responsabilités. Il partage la responsabilité de la réussite. Et s’il dit qu’il n’a pas le temps, Thibault propose de faire valoir que s’il n’est pas prêt, lui même, à s’investir pour son projet, pourquoi un prestataire le ferait-il ?
Attention, on n’a toujours pas répondu à son besoin de devis. Or, sur 10 devis reçus, même à l’euro près, il y a des différences de plusieurs milliers :
- car la lecture des spec est nécessairement une interprétation ;
- car le développement se fait à différents niveaux.
Même si le client à l’impression d’avoir une vision claire, si on donne une estimation (alors qu’on ne sait pas l’évolution à cours ou moyen terme), on le fait sans vraiment savoir. Ce n’est ni respectueux du client, ni respectueux de sa propre organisation.
MDN : Documenter le Web ouvert
Jérémie Patonnier – @jeremiepat
Pour garder un web ouvert, documentez-le.
Pour avoir de la doc pour vous, participez-y.
L’enrichissement de la documentation MDN (Mozilla Developer Network) se fait sur wiki et avec un simple e-mail.
La doc MDN est une des + complète et utile. C’est un peu moins vrai en français et vos contributions sont les bienvenues :
- Implémentation : renseigner l’implémentation d’un élément.
- Rédaction : rédiger des articles ou des portions d’articles.
- Relecture : faire une relecture technique ou éditoriale.
- Signaler : faire remonter des erreurs.
Fiabilité : il n’y a pas de validation avant mise en ligne et quelqu’un de malveillant peut mettre des informations en ligne. Par contre, la communauté, la réactivité sont telles que ça ne restera pas longtemps en ligne.
L’icône anonyme
Anne Marte
Questionnement sociologique sur nos icônes d’avatar.
Anne Marte en a assez dit pour nous donner envie de guetter l’article qu’elle devrait (hein ?! hein ?!) sortir sur le sujet 🙂
CSS3 with a safety net
Peter Gasston – @stopsatgreen
Ce que j’ai retenu de cette présentation (outre la prestation de Peter Gasston !) : comment vendre l’amélioration progressive à un client. Non, ce n’est pas une version basse qualité qu’on améliore ; c’est une bonne version et une encore meilleure ; un croissant et un croissant au beurre, à la crème et aux amandes (Peter avait choisi le croissant jambon fromage, mais chacun ses goûts !)
Le test du recruteur
Xavier Mouton-Dubosc – @dascritch
Grosse moquerie des tests de recrutements obsolètes et inutilisables où les erreurs grossières étaient pointées du doigt.
(Cliquez sur la photo pour avoir un aperçu 😉 )
Intégrateur, lève-toi et conçois !
Bertrand Keller – @bertrandkeller
Où l’on voit que les questions sur la valorisation du développeur front-end sont encore très sensibles et soulèvent beaucoup d’intérêt.
À rapprocher de :
L’altruisme pour votre bénéfice
Anthony Ricaud – @rik24d
Ne soyons pas hypocrite, le véritable titre d’Anthony était « L’altruisme pour ta gueule » 😀
Anthony fait valoir que la participation à des projets communautaires est un acte qui peut individuellement rapporter.
En résumé, cela va influer positivement sur :
- de la visibilité et favoriser une belle embauche ;
- l’améliorer ses conditions de travail ; c’est-à-dire les outils, leur efficacité, leur fiabilité ;
- sa montée en compétences techniques ;
- sa capacité à exploiter et cultiver ses compétences humaines, comportementales, sociales (ce qui sert dans le monde professionnel !)
(Pour ma part, je peux effectivement dire que de participer à Paris-Web, contribuer à Opquast, faire une conf au w3Café, avoir lancé w3qualité, etc. m’a déjà énormément apporté et m’apporte toujours.)
D’autres comptes-rendus : « Ils parlent de Sud Web«
Photo : t_chevalier