Débuter dans les relations avec les développeurs

illustrations illustrations illustrations illustrations illustrations illustrations illustrations
#communauté #devex #devrel #apple
post-thumb
                   

Publié le 21 octobre 2022 par Andrew Owen (3 minutes)

Vous serez peut-être surpris d’apprendre que le domaine des relations avec les développeurs existe depuis près de 40 ans au moment où j’écris ces lignes. Il a débuté chez Apple avec Mike Boich et Guy Kawasaki sur le projet Macintosh. Mais ce n’est que près de 30 ans plus tard qu’il s’est généralisé.

Apple a contribué à définir le marché des ordinateurs personnels avec l’Apple II. Son produit phare était VisiCalc, le premier tableur pour micro-ordinateur. IBM a observé l’adoption rapide de l’Apple II par les entreprises et a réagi en 1981 en lançant l’IBM PC. Au moment du lancement du Mac en 1984, l’IBM PC représentait environ 80 % du marché des PC.

Le Macintosh n’était pas compatible avec les logiciels écrits pour l’Apple II ou l’IBM PC, et pour réussir, il avait besoin de logiciels. Le rôle d’évangéliste logiciel a donc été créé chez Apple pour promouvoir le Mac en tant que plate-forme de développement. Et cela a fonctionné, car contrairement à d’autres alternatives à l’IBM PC lancées dans les années 1980, le Mac existe toujours.

À l’ère des bouleversements, il est largement reconnu que si vous voulez que les développeurs utilisent vos produits, ce que vous devez leur offrir est la voie la plus rapide vers le succès. L’Atari ST et le Commodore Amiga, autrefois très populaires, sont aujourd’hui principalement considérés comme des machines de jeu, si tant est qu’on se souvienne d’eux. Vous ne voulez pas que votre produit suive le même chemin.

Lorsque j’ai commencé à défendre les intérêts des développeurs, j’ai demandé conseil à une personne que j’avais rencontrée lors d’une conférence sur les API. Elle m’a donné trois choses qu’elle aurait aimé entendre lorsqu’elle débutait:

  1. Reconnaissez que vous portez, au minimum, deux casquettes. Votre casquette de développeur, qui devrait vous sembler familière, car vous n’êtes plus seulement un développeur. Vous êtes aussi dans le produit/le marketing/l’ingénierie/les ventes, quelle que soit l’organisation dans laquelle DevRel se trouve dans votre entreprise. Lorsque vous acceptez de jouer plusieurs rôles, il vous sera plus facile d’établir des priorités entre les différents objectifs.
  2. Protégez votre temps de développeur. Les gens voudront passer beaucoup plus de temps en tête-à-tête avec vous. Vous pouvez leur accorder ce temps, jusqu’à une certaine limite. Si vous consacrez tout votre temps aux réunions des parties prenantes avec d’autres Product Managers, vous n’écrirez pas de code. Vous devez continuer à écrire du code pour maintenir votre crédibilité.
  3. Votre manager doit être activement de votre côté. Si ce n’est pas le cas, dites-lui que c’est ce dont vous avez besoin pour réussir votre travail. Un manager qui vous soutient est très utile dans l’ensemble, je peux en témoigner personnellement.

Il a également recommandé le livre de Mary Thengvall “The Business Value of Developer Relations”. Elle recommande également l’ouvrage de Jono Bacon “The Art of Community”. Le premier est également une excellente lecture si vous envisagez de mettre en place un service de relations avec les développeurs. Le second devrait être une lecture obligatoire pour tous les community managers.

Voici maintenant une liste de sites que j’ai personnellement trouvés utiles dans mon rôle de défenseur des développeurs:

Blogs

Communautés

Bulletins d’information

Podcasts

Sites web

YouTube

Image: Original par Kjokkenutstyr.