Manuel de Developer Advocacy
(developer-advocacy.com)Dernière version du « Developer Evangelist Handbook » publié par Christian Heilmann il y a 15 ans
- Qu’est-ce que la Developer Advocacy / Evangelism ?
→ La définir
→ Le bon état d’esprit : être une personne qui provoque le changement chez les développeurs
→ Le rôle et la mise en valeur de ses points forts
- Collaborer avec sa propre entreprise
→ Se préparer aux préjugés : un rôle unique, à cheval sur plusieurs fonctions. Ne pas se décourager
→ Faire face aux changements dans l’entreprise : respecter les procédures légales. Il n’existe pas de « off-the-record ». Ne pas agir sous le coup de l’émotion ni faire d’hypothèses
→ Être aux côtés des développeurs en interne : écouter
→ Collaborer avec les RP et le marketing : ils ne sont pas des concurrents, il faut communiquer en continu
→ Être perçu comme un canal externe : faire savoir aux équipes à quels canaux on est relié
→ Former d’autres advocates et les développeurs : assurer des formations et des talks en interne, et partager les retours externes
→ Partager les techniques utiles : communiquer en interne sur les techniques découvertes
→ Trouver l’équilibre entre canaux personnels et canaux officiels
→ Effacer la marque : se dissocier de la marque de l’entreprise. Se concentrer uniquement sur le fait de permettre aux développeurs de jouer avec le produit
- Collaborer avec les concurrents
→ Quand on travaille avec des concurrents :
✓ être une personne indépendante, intéressée par ce qui est passionnant, quel que soit le produit ou l’entreprise
✓ toujours se familiariser avec les nouveautés
→ Respecter les concurrents : on ne peut pas être un excellent DA tout en étant un bagarreur.
→ Reconnaître quand le produit d’un concurrent est meilleur : valoriser les bonnes technologies, accueillir la concurrence sans la craindre, et pouvoir aussi faire remonter ces retours aux équipes internes
→ Connaître les concurrents : pour faire des comparaisons, il faut d’abord les connaître
→ Créer des exemples avec des produits concurrents et les utiliser : cela permet de comparer et d’identifier les différences
- Préparer l’outreach
→ Vérifier les faits exacts : demander en détail à l’équipe produit les spécifications exactes, les fonctionnalités, et ce qui n’en fait pas partie
→ Connaître son audience et ses besoins
→ Préparer des experts en renfort :
✓ noter les questions auxquelles on ne peut pas répondre et faire un suivi ensuite
✓ ne pas promettre ce que l’équipe produit n’est pas certaine de pouvoir fournir
→ Choisir le bon média : slides, vidéo, audio, live coding, exemples pas à pas en ligne...
→ Se préparer à l’échec :
✓ copies locales et en ligne des slides.
✓ sauvegarde séparée sur clé USB.
✓ pouvoir continuer en Q&A si les slides ne fonctionnent pas
✓ l’accès en ligne peut toujours échouer, donc prévoir du local ou un hotspot
- Trouver des occasions de prendre la parole
→ Participer à des podcasts
→ Participer à des panels : devenir expert sur un sujet précis ou être membre d’un groupe
→ Participer à des barcamps / meetups : courtes présentations
→ Écrire des articles dans des magazines en ligne, etc.
→ Organiser des sessions brown bag : séminaires sur la pause déjeuner
→ Poser des questions en conférence
→ Devenir un intervenant qu’on a envie d’inviter : rendre publics et publier ses sujets de présentation (Term)
✓ informations personnelles, bio à jour, slides/vidéos récentes
✓ sujets que je veux traiter, technologies que j’utilise
✓ ce que j’attends des organisateurs de conférence, etc.
- Voyages d’affaires et participation à des conférences
→ Conseils de déplacement : garder un jour tampon, voyager à moindre coût
→ Qui paie les frais ?
→ Participer à différents événements sur le lieu de la conférence et aller à la rencontre des autres intervenants
→ Utiliser les réseaux sociaux pendant les événements :
✓ laisser ses coordonnées sur les réseaux sociaux dans les slides
✓ signaler sa participation à la conférence via des hashtags, etc.
✓ partager les contenus amusants ou les bonnes présentations
✓ repartager les actualités des organisateurs de la conférence
✓ publier ses slides en ligne et le faire savoir
→ Construire son réseau grâce aux événements
→ Créer un calendrier pour suivre les événements auxquels on participe et en garder une trace
→ Tirer parti du buzz des conférences
→ Faire partie de la conférence où l’on intervient
→ Publier immédiatement la présentation et les ressources associées
→ Écrire à propos de la conférence
- Donner des présentations et animer des workshops
→ Restez vous-même : votre meilleur atout est la confiance en vous.
→ Inviter à l’échange
→ Préparer des supports à emporter pour les participants (takeaways)
→ Préparer la session de QA et la maîtriser complètement
→ Être honnête et dire uniquement la vérité : ne pas improviser une réponse quand on ne sait pas
→ Assurer le suivi et communiquer après la présentation
- Conseils de présentation : tenir le temps et autres points
→ Comment faire tenir tout cela en X minutes ?
→ Less is More : commencer par une seule chose importante (insight, résultat de recherche, état actuel de X, nouvelle fonctionnalité du produit X). Que voulez-vous que les gens retiennent de cette présentation ?
→ Votre présentation est très importante uniquement pour vous
✓ votre présentation n’est qu’une parmi des dizaines d’autres
✓ votre présentation sera enregistrée et diffusée partout
✓ les gens ne se souviendront pas de tout le contenu
✓ les gens n’ont pas besoin de vous pour obtenir l’information. Cette information est facile à trouver en ligne
→ Organiser les informations complémentaires
→ Live coding ? À quoi faut-il faire attention
→ Éviter les questions
→ Ce qu’il faut raccourcir : slide de sommaire, informations sur l’entreprise, présentation personnelle, blagues et mèmes
→ Ce qu’on peut insérer comme remplissage pendant la présentation : où trouver les ressources, comment vous contacter, collègues et experts à contacter à votre place...
→ Préparer un résumé de la présentation
- Ce qu’il ne faut pas dire sur scène, et les alternatives
→ « C’est facile » : « Pour y arriver, il suffit de passer par ces quelques étapes », « Ces outils sont bien documentés, donc vous aussi... »
→ « Pour ceux qui ne sauraient pas, je vais répéter brièvement » : « Pour résumer, X est... », « Comme vous le savez, X est... »
→ « Tout le monde peut le faire » : « En procédant ainsi, le reste du travail deviendra plus agréable » « C’est très efficace, alors essayez-le et parlez-en autour de vous »
→ « Ne vous inquiétez pas, X va résoudre ce problème » : « Comme X résout les problèmes liés à Y, vous pouvez créer Z »
« X a été conçu pour faciliter Y, et il est utilisé en conditions réelles. Les résultats sont encourageants »
→ « Comme tout le monde le sait » : « On en a beaucoup parlé ces derniers temps, et X (lien) l’explique bien »...
→ « Comme on l’a appris à l’école » : « Cela faisait partie du cursus d’informatique, et il y a une bonne raison à cela »
→ « Y (notre produit) est bien meilleur que X (le concurrent). » : « Voici comment faire cela avec X. Nous avons choisi une autre approche, et voici pourquoi. »
« Il existe plusieurs solutions à ce problème. Nous savons que X ne dispose pas de certaines fonctionnalités qui pourraient le rendre plus efficace... »
→ « C’est possible avec seulement quelques lignes de code » : « Comme vous le voyez, on peut démarrer avec quelques lignes de code. Je l’ai simplifié pour cette démo, et le code source est disponible à l’emplacement X »
→ « Pour devenir un expert (professional), faites X » : « L’intérêt de X, c’est Y ; c’est donc un outil professionnel à l’usage.
→ En plus de cela, regardez vos propres talks/vidéos puis demandez-vous : « Si je ne savais pas cela, qu’est-ce que je ressentirais en entendant cette phrase ? » Retirez-la ou reformulez-la ensuite
- Écrire d’excellents billets et articles
→ Simple is not stupid : écrire de manière simple et facile à comprendre est très difficile. Utiliser des mots simples, des termes faciles à comprendre pour une large audience, et des phrases concises
→ Allez à l’essentiel. Ne l’enrobez pas
→ La longueur du texte compte. Un article technique pour le web doit être court et aller à l’essentiel. S’il est trop long, divisez-le en plusieurs billets
→ Ajoutez différents médias pertinents : vidéo, audio, slides, images, etc.
→ Structurez le contenu avec des titres hiérarchisés, etc.
→ Le contenu aussi a besoin d’une date d’expiration.
→ Citez d’autres sources pour étayer vos propos
→ Écriture préemptive (Pre-emptive) — faites en sorte que votre produit suscite l’intérêt des développeurs. La « vente », c’est l’équipe commerciale qui s’en charge
- Écrire d’excellents exemples de code
→ Résoudre un problème au moyen d’un exemple
→ Montrer un exemple qui fonctionne
→ Expliquer l’environnement nécessaire
→ Écrire du code qu’on peut Copy & Paste
→ Proposer le téléchargement de l’exemple
→ Écrire des exemples propres et malins
→ Héberger le code et la démo
✓ le versioning est votre ami
✓ hébergement automatique
✓ utiliser un code sandbox
✓ environnement de live coding
- Préparer d’excellents supports de présentation
→ Savoir clairement ce que vous maîtrisez
→ Commencer par le contenu lui-même, pas par les slides
→ Commencer à rédiger dans un format texte portable
→ Astuce pour préparer rapidement des slides : décomposer les bullets
→ Choisir et préparer un bon outil de présentation
✓ il doit pouvoir s’adapter au 16:9 comme au 4:3
✓ il doit permettre de recadrer et redimensionner facilement les images
✓ il doit permettre de déplacer librement les objets à l’écran
✓ contrôle à distance possible
✓ passage fluide vers d’autres supports de présentation
✓ prise en charge du plein écran
✓ possibilité de faire apparaître les éléments un par un
- Créer d’excellentes slides pour présenter
→ Ne pas écrire ce que vous allez dire, mais expliquer avec des phrases courtes / images / captures d’écran / graphiques
→ Trouver et utiliser de bonnes images
→ Soigner la lisibilité des exemples de code
→ Conseils pour utiliser le son et la vidéo
→ N’utiliser les animations que là où elles sont nécessaires (sans en faire trop)
→ Rester concis — si possible, couvrir un seul sujet
→ Tenir compte du public
→ S’il existe des templates d’entreprise ou de conférence
→ Personnaliser (s’approprier) tout le matériel : ne réutilisez pas tel quel ce que vous avez reçu d’autres personnes
→ Partager et en profiter
→ Conseils de présentation supplémentaires
✓ se présenter : pourquoi je suis la bonne personne pour parler de ce sujet, et pourquoi / de quoi je veux parler
✓ utiliser l’humour : faire attention à ne pas attaquer les autres
✓ créer un lien avec la réalité
✓ ajuster le rythme pour ne pas parler trop vite : une pause est bénéfique pour le public
✓ éviter « Hello World »
✓ si possible, utiliser de nouveaux supports de présentation. Les tenir à jour
- Checklist pour des présentations plus faciles à comprendre, plus accessibles et orientées vers l’action
→ Support de présentation
✓ HTML/PPTX/PDF ?
✓ le code est-il en ligne ?
✓ les vidéos / sons intégrés sont-ils lisibles quel que soit l’OS, et aussi hors ligne ?
→ Format
✓ les médias intégrés prennent-ils en charge l’accessibilité ? (sous-titres, texte alternatif, transcript, etc.)
✓ la police est-elle suffisamment grande ?
✓ la taille est-elle adaptée à la conférence ? 16x9, 4x3
✓ le contraste est-il suffisant pour rester lisible même si le projecteur a des défauts ?
✓ y a-t-il une marge de sécurité suffisante si le projecteur rogne l’image ?
✓ faut-il une police de remplacement si vous présentez sur une autre machine que la vôtre ?
→ Contenu
✓ contient-il des éléments agressifs ou potentiellement déclencheurs ?
✓ est-il compréhensible sans contexte particulier ?
✓ y a-t-il des termes que les interprètes / traducteurs doivent connaître à l’avance ?
✓ si une partie ou une seule slide est partagée séparément, y a-t-il un risque de mauvaise interprétation ?
✓ les sources sont-elles indiquées et les droits vérifiés pour tous les médias et documents ?
→ Tracking
✓ pouvez-vous savoir qui a téléchargé la présentation ?
✓ y a-t-il un Call-to-Action à la fin des slides, avec un lien téléchargeable ?
→ Assurance
✓ tous les contenus sont-ils accessibles hors ligne, indépendamment de l’ordinateur ? (support de présentation / exemples / médias, le tout sur clé USB)
✓ avez-vous prévu des éléments explicatifs si la vidéo / l’audio ne fonctionne pas correctement ?
- Garder une trace de tout son travail
→ Enregistrer toutes les présentations en audio
→ Si possible, les enregistrer aussi en vidéo
→ Rassembler et consigner en un seul endroit tous les liens utilisés dans les présentations
→ Tenir une liste de toutes les conférences auxquelles j’ai participé / vais participer : avec liens vers slides / blog / liens / vidéos
- Connaître et utiliser le web (social)
→ Trouver de bons contenus web
→ Redistribuer les contenus du web : écrire des billets de blog, les enregistrer sur des sites de social bookmarking, les utiliser dans des supports de présentation, les citer dans des mailing lists ou des forums, poster sur Twitter
✓ toujours attribuer la source à l’auteur original
→ Se faire connaître sur le web
→ Utiliser des sites et produits sociaux puissants : Flickr, YouTube, Vimeo, Archive.org, GitHub, LinkedIn, Facebook, Meetup, Twitter
→ Utiliser le web comme dépôt, canal de diffusion et outil de cross-promotion
→ Donner des indices sur le produit, faire du teasing (Tease), publier des previews
→ Suivre l’impact : ajouter de la telemetry aux documents / blogs, s’abonner aux flux de commentaires, utiliser des raccourcisseurs d’URL traçables
→ Construire son réseau
→ Créer ou rejoindre une newsletter
→ Créer ou rejoindre un podcast
- Travailler depuis son ordinateur
→ Équipements : micro externe, moniteur, caméra, éclairage
→ Réaliser des screencasts et des captures d’écran
→ Streaming
→ Participer à des chats en ligne en temps réel
→ Précautions et conseils pour participer à des événements en ligne en direct
- Conseils pour enregistrer ses présentations en ligne
4 commentaires
L’ancienne version s’intitulait Developer Evangelist Handbook, mais de nos jours on emploie davantage le terme Advocacy qu’Evangelist/Evangelism, j’ai donc reflété ce changement.
C’est aussi un livre auquel je me référais presque comme à une bible lorsque je travaillais comme developer evangelist en 2010.
L’auteur a travaillé pendant 20 ans comme développeur et est un vétéran du domaine, ayant exercé cette fonction durant une dizaine d’années chez Yahoo, Mozilla et Microsoft.
On trouve diverses appellations comme Developer Advocate/Evangelist/Relations, mais je pense que ce livre pourra être utile à toutes les personnes qui exercent ce type de métier, ainsi qu’aux développeurs qui font beaucoup de présentations en externe.
Dans la création de supports de présentation, l’idée de « ne pas réutiliser sans personnaliser - Don't reuse without personalising » est aussi quelque chose sur lequel j’insiste beaucoup.
Quand on utilise une image ou un schéma pris ailleurs, il y a souvent beaucoup d’éléments qui ne collent pas, et il arrive aussi fréquemment que la personne elle-même ne comprenne pas vraiment tout le schéma en question.
Si possible, je recommande de les redessiner selon sa propre interprétation et en accord avec le concept de sa présentation avant de les utiliser.
Merci pour cette bonne synthèse. Je trouve que « ne pas réutiliser sans personnaliser » est une traduction un peu trop littérale ; dans le contexte que vous mentionnez, une formulation comme « se l’approprier avant de le réutiliser » serait peut-être plus facile à comprendre.
En l’écrivant, je me rends compte que c’est bien ça ^^; Je l’ai légèrement pris en compte. Merci.
@_@)b