Avertissement: aucun développeur n'a été blessé lors de la recherche de cet article.

Certains jours, ils essaient de vous arracher des sommes ridicules. D'autres jours, ce sont vos frères et sœurs plus âgés et protecteurs qui résolvent vos problèmes de manière désintéressée. Traitez-les équitablement et ils pourraient même être disposés à travailler gratuitement pour vous. C'est une race intéressante et pour toute entreprise de technologie, elle est indispensable. Alors, comment embauchez-vous et travaillez-vous ensuite avec des développeurs?

 

Ma propre incursion dans le développement

Au départ, j'ai appris des bribes de développement logiciel comme un intérêt pour la technologie, mais cela s'est transformé en un intérêt pour les personnes qui s'engagent également dans le développement. Tout aussi bien, car le temps que j'ai passé à apprendre à coder a payé de gros dividendes dans ma capacité à communiquer entre le côté commercial et le côté technique de l'entreprise. À CityFALCON, nous avons eu la chance d'avoir une équipe de développeurs terre-à-terre qui étaient également prêts à ouvrir la voie à une communication bidirectionnelle, et ma capacité initiale à entamer une conversation avec une idée claire de la façon dont les développeurs pensent a probablement contribué de manière significative à cette ouverture de communication.

 

Les exigences du développeur

Au cours du processus d'embauche, les entrepreneurs auront leur premier aperçu de l'espèce. Pour ceux qui n'ont jamais travaillé dans le domaine de la technologie et qui ne connaissent pas la culture du développement logiciel, cela pourrait être un peu un choc. Mais pour ceux qui ont lu cet article, le choc doit être émoussé. Il y aura des variations d'une génération à l'autre, mais elles ne seront probablement pas aussi prononcées que la fracture générationnelle dans certaines autres professions.

Conditions courantes observées lors d'expérimentation répétée au cours du processus d'embauche: Pas d'heures supplémentaires. Pas de travail sur site. Aucune heure fixe. Pas de délais stricts. Oui, un salaire élevé. Oui temps de vacances flexible. Oui un choix de projets. Oui haute autonomie.

Voici quelques exemples de demandes que vous pourriez rencontrer en tant qu'agent de recrutement. Oui, en tant qu'agent de location, lors de l'entrevue, on vous demandera peut-être si votre entreprise offrira ces avantages. Parfois, l'exigence de rémunération élevée sans heures supplémentaires peut être un point de friction. Pour les meilleurs développeurs, ils savent qu'ils peuvent exiger cela, donc si vous avez quelqu'un assis devant vous, exigeant ces conditions avec beaucoup de confiance, vous avez probablement un bon développeur à portée de main.

Cela peut être un choc, car il est probablement légèrement différent des demandes des autres employés, qui demandent généralement des salaires élevés, peut-être des vacances et des avantages sociaux, comme des abonnements à une salle de sport et du café gratuit. Bien sûr, les développeurs aimeraient probablement aussi ces avantages, mais ils ont leurs raisons d'exiger ce qu'ils demandent.

Fait intéressant, une fois que le spécimen s'intègre dans le groupe, et en particulier dans les entreprises aux cultures très unies, il devient comme une famille. C'est à ce moment-là que beaucoup de ces demandes disparaissent (temporairement) et que le développeur devient comme le frère aîné qui vous aide, peu importe le coût pour eux. Bien sûr, si vous poussez trop fort trop longtemps, ils passeront simplement le navire à la société suivante (et peut-être meilleure).

 

Les motivations du développeur

Les exigences énoncées dans la section ci-dessus proviennent des motivations particulières du développeur. Bien sûr, comme tout travailleur humain - nous mettons un point d'honneur ici à exclure les robots travailleurs qui ont tendance à ne rien exiger du tout sauf le pétrole, l'électricité et la mise à jour logicielle occasionnelle - le développeur veut une vie agréable, une acceptation sociale, un travail intéressant, etc.

Alors que de nombreuses personnes recherchent simplement de l'argent pour acheter dans la culture de consommation, les développeurs ont tendance à être plus intéressés par le progrès intellectuel et la réussite. Cela a du sens et découle naturellement de leur travail, car leur domaine choisi est une grande entreprise à forte intensité de connaissances.

De toute évidence, ils exigent aussi de l'argent, car ils ont besoin de vivre. Mais après un certain temps, l'argent est moins important que d'autres facteurs, comme une culture de travail et une gestion qui les comprennent.

Les autres motivations comprennent:

Apprentissage - ils ne veulent pas vraiment être les personnes les plus intelligentes de la salle, car ils ne pourraient alors pas apprendre et s'améliorer. Honnêtement, la plupart des développeurs se délectent de beaucoup de connaissances sur leur domaine d'expertise et le feront étalage quand cela se présentera, mais ils écouteront également attentivement lorsque des personnes ayant des connaissances dans d'autres domaines parleront afin de pouvoir en apprendre davantage sur ces domaines. Comme une éponge cérébrale absorbant des informations pour une conquête ultérieure.

Soyez pris au sérieux - s'ils font une suggestion, ils veulent être pris au sérieux par la direction. Il s'agit d'une motivation de base pour les employés, mais pour une raison quelconque, lorsque les développeurs expriment leurs suggestions, beaucoup de gestionnaires la considèrent comme «juste un truc de technicien». Peu de choses font bouillir le sang d'un développeur comme une personne non technique déclarant «c'est juste un truc de technophile». Surprenant pour personne, la grande majorité des entreprises fonctionnent sur au moins certains technologie de nos jours, ce qui rend chaque entreprise au moins un peu «technophile»

Compris - ils veulent aussi être compris. De même que d'être pris au sérieux, c'est aussi un désir de base des employés. Et encore une fois, les développeurs ont tendance à être moins compris que les équipes en contact avec les clients ou les partenaires. Ce dernier travaille avec les humains et les interactions humaines toute la journée tandis que les développeurs travaillent avec des systèmes. Parfois, il faut un petit effort supplémentaire pour comprendre les développeurs plutôt que les rôles centrés sur l'humain, mais cela en vaut la peine.

 

Interagir avec les espèces

Maintenant que vous avez attrapé un développeur (probablement par l'embauche et non par un piège à ours), vous devez savoir comment gérer les interactions. De toute évidence, ils ne vous déchireront pas le visage comme un ours pris au piège, mais plusieurs mauvaises interactions et vous pourriez voir des sites Web plus lents et une productivité réduite - qui veut travailler dans un endroit avec une culture oppressive?

 

Donner et recevoir des conseils

Un domaine dans lequel de nombreux problèmes surgissent est celui de donner et de recevoir des conseils. Les employés qui ne sont pas du côté technologique de l'entreprise peuvent penser que quelque chose est parfaitement facile à faire, mais ce n'est peut-être pas le cas. Ils ont tendance à donner des conseils comme «oh, fais juste X et ça marchera». Bien sûr, cela peut fonctionner du point de vue de l'utilisateur, mais faire X casse trois choses sur le backend et fait tomber un système intégral que les utilisateurs ne voient pas mais sur lequel ils comptent totalement.

Il y a aussi le problème de la condescendance. On pourrait dire «ça ne devrait pas être si dur…» Mais si le développeur dit que c'est dur, c'est probablement dur. La technologie n'est pas un appareil magique et les développeurs ne sont pas des magiciens. Ils ne peuvent pas faire bouger les choses s'ils ne peuvent pas faire bouger les choses, et utiliser un langage comme «ça ne devrait pas être si difficile» est un moyen infaillible de provoquer des obstacles.

Pour ces raisons, les développeurs ne consultent souvent personne, sauf les autres développeurs. D'une certaine manière, cela a du sens: les seules personnes qui possèdent une connaissance approfondie des systèmes sont d'autres développeurs. Les experts donnent des conseils à d'autres experts, précisément parce que c'est là que réside leur expertise. Les profanes n'apportent généralement pas grand chose à la table. Vous ne voudriez pas que votre plombier dise à votre chirurgien cardiothoracique comment faire une chirurgie cardiaque, simplement parce que les deux fonctionnent avec des tuyaux et des valves, n'est-ce pas?

De même, les développeurs peuvent pousser pour certaines solutions qui ne sont pas réalisables sur le plan opérationnel ou public. Vous avez une solution pour automatiser 75% des travaux, mais cela n'atteint qu'une précision de 81%? Eh bien, cela peut être une merveille technique, mais cela ne fonctionnera tout simplement pas du point de vue de l'entreprise et du service client. Sans parler du cauchemar des relations publiques de licencier les trois quarts de la main-d'œuvre. Pour cette analogie, vous ne voudriez pas que votre chirurgien cardiaque répare votre tuyau éclaté en cas d'urgence s'il n'a jamais connu d'urgences de pression d'eau de 80 PSI auparavant.

 

Gérer les attentes

Ceux qui sont en première ligne de l'entreprise auront des visions, mais ils croient trop souvent que les développeurs sont des sorciers. Ils ne sont pas. Ils peuvent être intelligents, ils peuvent être capables de faire des tours de magie, mais tout est basé sur la physique et l'informatique. Cela signifie qu'il n'y a pas de magie et que toutes les visions d'entreprise ne peuvent pas être mises en œuvre de manière réalisable. Ou peut-être est possible, mais le département informatique ne dispose que d'un certain budget, et la vision serait bien trop coûteuse en ressources informatiques.

La pire façon de gérer les attentes est de faire participer les développeurs à la conversation dans les dernières étapes du développement. Ne fais pas ça. Si vous voulez que quelque chose soit développé, vous devez faire appel au développeur tôt. Cela garantira que c'est réellement faisable techniquement.

Les développeurs ne sont pas non plus des automates sans cervelle. Ils sont interactifs, tant que vous leur parlez, et ils répondent (généralement). Ils vous diront ce qui est possible, et ils travailleront même pour trouver des solutions s'ils pensent qu'elles existent. Ils aideront probablement également à guider le processus de développement sous un angle technique. Vous ne voulez pas que l'ensemble de votre projet repose sur une seule hypothèse pour découvrir, après 3 mois de planification, que votre hypothèse n'est pas possible en fonction des ressources informatiques de l'entreprise.

 

Promotion et responsabilités

Les développeurs veulent coder et concevoir des systèmes. C'est la raison pour laquelle ils se sont lancés dans cette ligne de travail en premier lieu. Beaucoup ne veulent pas non plus suivre le cheminement de carrière traditionnel. Les développeurs (et de nombreux autres techniciens) sont souvent transformés en managers, mais beaucoup d'entre eux ne veulent pas vraiment des responsabilités supplémentaires ni de l'aspect de gestion humaine. Les humains sont complexes et souvent illogiques, contrairement aux systèmes informatiques. Cela peut être extrêmement frustrant pour les personnes habituées à travailler avec des systèmes logiques. On ne peut pas non plus complètement détruire un humain et le reconstruire dans un environnement virtuel, donc il y a aussi ça.

D'un autre côté, certains développeurs aimeraient en fait devenir des managers. Ou ils sont suffisamment ouverts aux nouvelles idées pour au moins essayer. S'ils ne l'aiment pas, assurez-vous d'avoir un moyen de les faire revenir à des rôles moins gestionnaires après un court moment. Sinon, ils pourraient quitter le navire. Les emplois de développement exclusivement technologiques sont nombreux et bien rémunérés.

 

Seul le temps et la sociabilité

Il existe un stéréotype des développeurs en tant qu'habitants de la salle des serveurs, assis dans le froid et l'obscurité, ne parlant à personne sauf via des programmes de chat, ne quittant jamais la pièce que pour rentrer chez eux, et toute interruption est totalement indésirable. Ceci n'est que partiellement vrai.

Les développeurs, comme tout le monde, veulent vraiment du temps ininterrompu pour travailler sur leurs projets. Souvent, les développeurs doivent jongler avec différentes parties d'un système dans leur tête et essayer d'y intégrer de nouvelles idées sans casser aucune des autres parties. La mémoire humaine n'est pas aussi fiable que la mémoire de l'ordinateur et les interruptions peuvent rapidement provoquer l'effondrement de cet acte. Il faut beaucoup d'énergie pour recommencer à jongler, et c'est la raison pour laquelle les développeurs n'aiment pas être interrompus.

Cependant, ils sont aussi sociaux que n'importe qui dans le groupe. Essayez de les inclure dans vos sorties ou vos singeries au bureau (vous pouvez cependant laisser de côté la politique de bureau). Assurez-vous simplement de ne pas le faire juste avant une grosse sortie. Au lieu de cela, faites-le juste après et félicitez-les pour leur travail. Ils l'apprécieront, vous vous féliciterez d'eux et vous pourriez même en apprendre une ou deux choses sur vos systèmes technologiques en cours de route.

 

La question des délais

Celui-ci est toujours délicat. Les délais manqués sont approximatifs, mais ils se produisent avec une fréquence déconcertante dans le développement de logiciels. Les développeurs veulent publier des produits de premier ordre, mais de nombreux problèmes pourraient survenir. Ils ne veulent pas non plus être responsables si le tout tombe en panne, ni ne veulent corriger cinq failles de sécurité sur le serveur de production s'ils peuvent les corriger avant la sortie du produit.

Une source courante de problème inattendu est le code tiers. De nombreux systèmes reposent sur du code tiers, et parfois ce code ne fonctionne pas bien avec d'autres codes tiers. Ce conflit peut ne pas être découvert avant la fin d'un projet, puis l'échéance doit être repoussée d'un mois pendant que le code propriétaire est écrit pour résoudre le problème ou qu'un nouveau code tiers est trouvé et intégré. Une autre source courante de dépassement des délais est un bogue majeur dans les fondations du système provoquant des problèmes pour le nouveau code, ce qui signifie que plus d'un projet doit être révisé avant la publication.

Étant donné que les systèmes peuvent rapidement devenir si complexes qu'aucune personne ne sait comment tout fonctionne, les délais sont souvent manqués. Telle est la vie du développement logiciel. Vous pouvez définir des délais, mais assurez-vous que vos techniciens savent qu'un produit solide est plus important qu'un délai arbitraire. En fait, si vous ne connectez pas la date limite à un événement important, les développeurs pourraient tout simplement l'ignorer.

Alors, fixez des délais, mais fondez-les sur les conséquences du monde réel, comme si votre concurrent sera le premier à commercialiser et que toute votre entreprise tombera en panne. Cela aidera l'équipe de développement à établir des priorités. Soyez flexible, car les délais ne seront pas respectés. Et assurez-vous de gérer vos attentes, sinon vos délais ne seront pas alignés sur les capacités des développeurs et ils seront manqués.

Enfin, si un développeur vous dit de ne pas publier le logiciel, ne le publiez pas. Il n'y a rien de pire pour la relation client qu'une mise à jour logicielle qui casse ou crée une faille de sécurité. Manquer une échéance de quelques jours est infiniment mieux que de perdre quelques jours de revenus à cause du code bogué et de l'atteinte à la réputation qui en résultera.

 

Remarques finales

Comme tout bon article (non) scientifique, nous voulons terminer par un bref résumé et une conclusion.

Tout au long de l'article, nous avons parlé des développeurs comme d'une espèce, presque étrangère aux gestionnaires de personnes. Mais les développeurs ne sont aussi que des humains et doivent être traités comme tels. Si vous avez un peu de temps, en tant qu'entrepreneur à la recherche d'une équipe de développement, je vous suggère fortement d'apprendre au moins un peu de codage, comment fonctionnent vos systèmes et ce que fait votre équipe. Cela contribuera grandement à une communication fluide et pourrait même vous marquer quelques frères et sœurs plus âgés et plus protecteurs.

Connaître les limites de vos systèmes et de votre équipe garantira que tout le monde est sur la même longueur d'onde et qu'aucune explosion ou épuisement professionnel ne se produira. Il propulse l'équipe vers l'avant comme une équipe d'aviron bien orchestrée au lieu d'une équipe qui patauge qui rend tout le monde malheureux. Et les développeurs sont toujours aussi très demandés, alors pousser continuellement les mauvais boutons fera que cette espèce se tournera vers des pâturages plus verts. La loyauté de l'entreprise n'est morte que pour les entreprises déloyales, alors ne soyez pas victime de la perte d'un grand développeur et potentiellement de toute votre infrastructure technique.

 

Nous n'avions qu'une seule âme courageuse prête à présenter son visage comme l'une des espèces d'actualité, alors voici cette âme courageuse (c'est notre DBA et notre responsable de l'infrastructure):

Et comme personne d'autre ne s'est porté volontaire (les développeurs peuvent parfois être un peu timides et introvertis), voici une photo d'une partie de notre équipe. Pour être honnête, ils sont difficiles à trouver au même endroit à la fois; la culture de travail à distance des développeurs infecte vraiment toute une startup, même ceux qui ne sont pas des développeurs.

Et tout le monde au bureau, pas seulement les développeurs de logiciels, semble en quelque sorte faire cela tout le temps (regardant les ordinateurs)