Comment puis-je plaider en faveur de programmeurs coûteux?

Dans notre entreprise, nous devons faire beaucoup de choses apparemment pas compliquées, comme développer l'interface utilisateur mobile.

Disons que les programmeurs expérimentés nous coûtent 4x autant que les débutants.

Les deux sont fondamentalement capables de terminer les choses apparemment simples dans le même laps de temps.

La différence est que les programmeurs expérimentés produisent moins de bugs et que leur code est plus stable, etc. Les programmeurs débutants perdent beaucoup de temps à tout le monde (PM, clients, etc.). Mais ils sont nettement moins chers.

Le contre-argument est qu'il faut aux débutants et aux débutants le même temps pour créer un tableau en HTML. Il est donc luxueux d’engager des programmeurs expérimentés pour faire ce que les programmeurs débutants peuvent également accomplir.

Devrions-nous investir dans des programmeurs de plus en plus nombreux et de meilleure qualité ou dans un nombre plus élevé de PM, étant donné que la différence entre programmeurs expérimentés et nouveaux programmeurs dans notre domaine peut être 4x.

J'ai une expérience directe des deux théories testées dans le monde réel - dans le même projet en fait.

Avant mon arrivée, la décision avait été prise d'embaucher des BA plus chers et des programmeurs très bon marché. L'idée était de faire en sorte que les spécifications de bonne qualité soient suivies servilement par les très jeunes programmeurs.

Après plus de 6 mois du projet principal, je suis devenu responsable du développement. Après avoir réglé quelques facteurs d'hygiène, le problème de la qualité du code est resté. J'avais un budget de réserve et j'ai embauché un programmeur très expérimenté (plus d'un architecte de solution) doté de compétences de communication hors du commun et une ancienne carrière de formateur en C # (le langage dans lequel le projet a été écrit). L'idée était d'améliorer la qualité des autres codeurs en fournissant un mentorat et une formation efficace et gratuite.

Après un mois ou deux, il devint douloureusement évident que même cela ne marcherait pas. L'équipe d'origine fut alors retirée du projet et deux autres programmeurs de premier plan furent ajoutés. Ils ont livré le projet que l'équipe d'origine avait complètement échoué après plus de 8 mois d'essais en 3 sprints d'un mois, en partant de zéro, car le code d'origine était irrémédiable.

Si vos exigences sont très basiques, vous pourrez peut-être utiliser un programmeur très junior, mais il est probable qu’elles coûteront beaucoup plus cher à long terme. Parfois, les exigences "simples" évoluent vers une grande complexité.

Si je n'avais pas fait le choix difficile de changer de direction, ils y travailleraient probablement encore :) - Plus sérieusement, dans cet exemple, le manque de communication et de compétences de la part de l'équipe d'origine signifiait qu'ils ne poseraient pas de problèmes avec le cahier des charges, mais essaierait simplement de faire tout ce qui leur était demandé, que cela ait du sens sur le plan architectural ou non. Un développeur plus expérimenté et plus confiant a posé des questions et s'est penché sur les exigences sous-jacentes et a donc fini par produire la bonne solution du premier coup.

Oh, une autre chose. Ne présumez pas que vous pouvez immédiatement engager un bon programmeur. Il y a beaucoup de gens avec une expérience de plusieurs années de la médiocrité qui donneront un résultat presque aussi mauvais qu'un jeune mais coûteront la même chose qu'une superstar (parfois même plus). J'ai un très bon "taux de réussite", mais cela vient avec l'expérience et j'en ai beaucoup. C'est le sujet d'une conversation complètement différente qui est hors sujet ici ...

TL; DR Les bons programmeurs sont une bonne affaire. Le plus difficile est de les trouver et de créer un environnement de travail suffisamment attrayant pour les conserver.

Si vous avez des statistiques de performances approfondies, vous pouvez analyser les affaires avec les mathématiques. Celles-ci pourraient montrer que la vitesse de développement compenserait l'augmentation du prix, voire mieux, qu'une conception robuste permettrait d'économiser davantage en maintenance et en développement des versions ultérieures. Malheureusement, de tels chiffres ne sont pas disponibles très souvent - en particulier pour les nouvelles technologies.

Un autre argument peut être le délai de commercialisation. Ceci est plus facilement compris par la haute direction. Cependant, si le temps n'est pas vraiment critique, cela ne vous aidera pas.

En dernier recours, trouvez une photo de Red Adair , le célèbre pompier, qui a été appelé dans une catastrophe majeure après plusieurs tentatives infructueuses d'hommes moins expérimentés. Sa célèbre citation:

Si vous pensez que l'embauche d'un professionnel coûte cher, attendez d'avoir embauché un amateur.

... mérite d'être imprimé en couleur et affiché bien en vue sur la porte de votre bureau, afin que tout le monde comprenne de quoi il s'agit ;-)

La réponse de mcottle me plaît et je suis favorisée, mais je souhaite aborder d'autres dynamiques et arguments que les autres réponses n'ont pas encore évoqués.

Tout d'abord, la réponse de mcottle implique implicitement le fait qu'en-dessous d'un certain niveau de compétence, certains problèmes sont tout simplement impossibles. Malheureusement, la façon dont vous le découvrez est que votre équipe essaie et échoue, ce qui est trèscoûteux. Après avoir échoué, il y a deux leçons possibles à tirer de cela. Une des options consiste à apprendre que vous avez besoin de développeurs plus compétents. Vous devez donc les embaucher et terminer le projet de manière à dépasser considérablement le budget et le calendrier, mais au moins, vous êtes prêt à l'avenir. L’autre option est qu’un tel projet est «trop difficile» pour votre équipe et que de telles choses ne devraient pas être tentées à l’avenir, c’est-à-dire que vous abandonnez le projet et effectivement tout projet similaire. Bien sûr, il sera rarement exprimé comme "nous sommes trop stupides pour le faire", mais sera rationalisé car "nos systèmes sont très complexes" ou "nous avons beaucoup de code hérité" ou d'autres. Ce dernier point de vue peut considérablement fausser le point de vue d’une entreprise sur ce qui est possible et sur la durée et le coût du développement. "

Une question est, quel est exactement le plan de votre entreprise? D'accord, ils vont embaucher des programmeurs juniors bon marché. Trois ans passent, et maintenant? Que font-ils avec le développeur qui les accompagne depuis trois ans? Est-ce qu'ils ne lui ont jamais accordé une augmentation de salaire? Les options ici sont les suivantes:

• Ils accordent des augmentations de manière concurrentielle pour fidéliser leurs employés. Dans ce cas, pourquoi auraient-ils de la difficulté à payer les taux de développeur senior maintenant? J'y reviendrai cependant.
• Ils ont des taux stagnants, ce qui signifie qu'ils finiront par se "résumer" en des employés qui manquent de motivation et / ou de compétences.
• Ils éliminent plus activement les employés plus âgés.

Les deux autres cas impliquent un important roulement de personnel, ce qui entraîne une perte de connaissances de la part de l'entreprise et une rémunération constante des employés. Dans le second cas, vous sélectionnez essentiellement les mauvais développeurs et les coûts vont donc augmenter sous la forme de calendriers croissants. Tout se passera bien pour le projet X jusqu'à ce que, soudain, Jim s'en va, qui était l'un des meilleurs développeurs, car il n'a pas obtenu d'augmentation depuis deux ans, le projet prendra "naturellement" beaucoup plus longtemps, vous devez embaucher et former de nouveaux développeurs juniors qui (vraisemblablement) ne seront pas aussi bons que Jim. C'est ainsi que vous recalibrez les attentes.

Même dans le cas où des augmentations compétitives sont fournies, si vous avez tous des développeurs débutants, où et comment sont-ils censés apprendre? En gros, vous espérez que l'un d'entre eux apprendra les bonnes pratiques par lui-même en dépit de son environnement de travail et finira par en encadrer d'autres (par opposition à un départ plus vert). Il serait beaucoup plus logique de "préparer la pompe" avec de bons développeurs. Plus probablement, vous développerez une culture de débutants experts . Le résultat est que vous finirez par payer des tarifs pour développeurs seniors à des personnes légèrement meilleures que les développeurs débutants et culturellement toxiques.

L'un des avantages, en particulier de très bons développeurs, que je suis étonné que personne d'autre n'ait mentionné, est qu'ils peuvent facilement être un facteur multiplicatif . Il se peut fort bien qu'un développeur débutant et un développeur senior prennent le même temps pour créer une table. Cependant, un bon développeur ne fera pas cela. Ils vont faire un générateur de table qui réduit le temps pour tout le monde pour faire une table. Alternativement / en plus, ils vont augmenter le plafond de ce qui est possible pour tout le monde . Par exemple, les développeurs qui ont implémenté le framework Google MapReduce étaient probablement extrêmement qualifiés, mais même si les utilisateursde MapReduce sont totalement incapables de créer eux-mêmes une version massivement distribuée de leur algorithme, ils le peuvent désormais facilement avec MapReduce. Souvent, cette dynamique est moins flagrante. Par exemple, de meilleures pratiques de contrôle, de test et de déploiement de la source améliorent les compétences de chacun , mais il peut être plus difficile de rechercher une personne spécifique.

Pour discuter un peu de l’autre côté, peut-être que les hauts dirigeants ont raison. Peut-être que des développeurs plus expérimentés ne sont pas nécessaires. Si tel est le cas, cependant, il semblerait que le développement ne soit pas une partie importante de la société. Dans ce cas, je voudrais simplement éliminer complètement les développeurs et utiliser un logiciel standard ou embaucher des entrepreneurs à la demande. Il serait peut-être intéressant d’expliquer pourquoi ils n’utilisent pas uniquement des sous-traitants plutôt qu’une équipe interne. De toute façon, si vous allez avoir beaucoup d’employés, la montée en charge des entrepreneurs ne devrait pas être un problème.

Ce n'est pas une situation ou.

Surtout dans le cas d'un projet plus vaste, vous avez assez régulièrement quelques personnes relativement expérimentées occupant des rôles supérieurs et un certain nombre de personnes moins expérimentées occupant des rôles secondaires. De cette façon, les seniors peuvent non seulement aider directement au projet en écrivant du code et en aidant à prendre des décisions difficiles, mais ils peuvent aussi aider indirectement en guidant les juniors.

Avec un peu de soin, ceci peut également aider à empêcher les ingénieurs expérimentés de s’épuiser rapidement en leur demandant de faire en permanence des travaux qui manquent de défi ou d’intérêt pour eux. Au moins d'après mon expérience, même un petit peu de temps pour encadrer des personnes enthousiastes de niveau junior (ou même de niveau interne) peut rendre le sprint beaucoup plus intéressant.

Pour être juste, je devrais ajouter que ce type de poste ne conviendra probablement pas à tous les ingénieurs expérimentés. Cela nécessite de mettre davantage l'accent sur l'architecture et la conception, la communication, la documentation, etc. Très tôt, cela demande souvent beaucoup de discipline. Pour les personnes qui ont écrit du code, il serait tentant de le rédiger au lieu d’enseigner à un ingénieur débutant comment le faire. Il est également souvent tentant de procéder à une réécriture complète dès le départ lorsque le code ne vous convient pas personnellement, même s'il est parfaitement adapté à votre travail.

Si, toutefois, vous ne pouvez vraiment pas convaincre la direction d’adopter une combinaison de niveaux d’expérience, il ne fait aucun doute que vous devez acquérir plus d’expérience. Si vous laissez un projet entièrement au personnel junior, il y a de fortes chances que vous n'obteniez jamais un produit utilisable. Pire encore, ils ne se rendront pas compte que ce qu’ils font n’apporte aucun progrès réel vers un produit utilisable. Ils continueront donc à travailler dans une direction choisie bien après qu’une personne plus expérimentée aurait réalisé qu’elle avait fait un pas en avant. Une erreur fondamentale dès le début, et il est nécessaire de faire marche arrière, de se regrouper, de prendre ses repères et de partir dans une nouvelle direction afin d’avoir le moindre espoir d’arriver à une destination intéressante.

Tout projet concret est dicté par la demande du client et implique donc des tâches peu complexes (par exemple, créer des formulaires CRUD) et complexes (par exemple, créer un système de notification piloté par des événements). La seule façon d'avoir des tâches peu complexes consiste à dire à plusieurs reprises au client le mot "non", ce qu'aucun service commercial dont j'ai jamais entendu parler n'est disposé à le faire.

Si vous n'avez que des développeurs de niveau junior, cela signifie que vous ne pourrez effectuer que des tâches peu complexes, et donc uniquement en mesure de créer un produit de faible valeur et de lutter plus durement sur le marché pour différencier vos produits. Si vous souhaitez vous différencier, vous devez créer des fonctionnalités de grande valeur, qui se traduisent inévitablement par des tâches très complexes. Après tout, si c'était facile, cela n'aurait pas de valeur. Cela signifie que vous avez besoin de personnes pour exécuter ces tâches très complexes et de développeurs de haut niveau.

Si vous n’avez que des développeurs de niveau supérieur, vous perdrez leurs compétences en travaux de faible valeur, vous aurez du mal à les conserver lorsque vous les forcerez à faire ledit travail, et vous risquerez de vous lancer dans l’astronomie architecturale en essayant de simplifier davantage des tâches simples. intéressant de travailler. Cela signifie que vous devez également avoir des développeurs inexpérimentés pour prendre en charge ces tâches.

Une équipe en bonne santé travaillant sur des produits axés sur le client est généralement un mélange. Le rapport entre les développeurs débutants et les développeurs seniors dépend du rapport entre les tâches peu complexes et les tâches complexes, et cela dépend de votre stratégie commerciale. Si vous recherchez activement de gros volumes de travaux de découpe de biscuits à faible marge, faciles à comprendre, vous n’aurez pas à effectuer beaucoup de tâches complexes et embaucherez probablement des développeurs de niveau débutant. Si vous cherchez activement à différencier et à cibler des créneaux mal desservis avec des marges de profit plus élevées, vous devrez effectuer de nombreuses tâches complexes et rechercher principalement des développeurs de haut niveau.

Dans ma réponse, je dirai que les programmeurs expérimentés ne codent pas nécessairement plus vite que les développeurs débutants. En fait, les programmeurs les plus rapides sont en moyenne des gars qui viennent de quitter l'université.

La connaissance du domaine est une clé pour le développeur senior. Un bon développeur senior doit avoir une connaissance approfondie du domaine, ce que n’a peut-être pas un développeur junior. Les développeurs expérimentés comprennent le problème, ce qu’il faut résoudre et comment le résoudre. Ils peuvent résoudre des problèmes plus complexes pour l'entreprise que la plupart des développeurs débutants.

La programmation est un ensemble de compétences relativement bon marché, ce sont les connaissances spécialisées qui comptent.

N'essayez pas de faire valoir votre point de vue. Le marché fixe le prix des employés. Si le marché est prêt à payer 4 fois plus d'expérience, c'est parce que les entreprises dans leur ensemble ont compris qu'il y avait une augmentation de productivité de 4 fois.

Évidemment, le marché pourrait être faux, peut-être 3,5 ou 5 fois, mais à moins que vous ne soyez une agence numérique, la concurrence avec le marché ou quelque chose de ce genre n'a aucune importance.

Votre vrai problème est que vous êtes assez bon en interview pour être en mesure de faire la distinction entre un bon développeur expérimenté et juste un vieux développeur qui le blague.

Votre deuxième question du budget PM vs développeur. Je dirais qu'un développeur peut se passer d'un PM mais qu'un PM ne peut pas se passer d'un développeur. Obtenez votre moteur de développement trié en premier, puis demandez à un PM de retirer l’administrateur de ses mains.

Vous ne trouverez personne dans votre pays au quart du coût d'un très bon développeur. Vous pouvez trouver quelqu'un pour la moitié du salaire, et ce sera un débutant absolu. Pour quelqu'un qui gagne un quart du salaire, vous devez sortir du pays, vous aurez alors des problèmes de communication, des gens qui suivent aveuglément les spécifications et des problèmes de toutes sortes.

Vous avez besoin d' un bon développeur. Si vous ajoutez plus de programmeurs débutants, vous avez besoin d'un bon développeur doté de solides compétences en communication, qui est disposé et capable de garder un œil sur les juniors. Sans un bon développeur, vous êtes perdu. Vous aurez peut-être de la chance de trouver des débutants extraordinaires et talentueux, mais une fois qu'il aura compris qu'ils sont bons, ils voudront un salaire plus élevé.

Si vous n'avez pas un bon développeur, vous n'avez personne qui voit la situation dans son ensemble, et personne qui peut résoudre les problèmes qui ne peuvent pas être résolus en utilisant stackoverflow. Et vous aurez un code qui pue et qui est incontrôlable, car les développeurs débutants ne savent pas comment créer du code maintenable. Ils peuvent l'apprendre, mais ils ne le feront pas sans un bon développeur dans l'équipe.

Votre entreprise devra surmonter quelques obstacles avant de pouvoir décider si engager de meilleurs programmeurs serait rentable. Désolé si je fais des suppositions négatives sur votre travail, mais je ne suis pas convaincu qu'ils sachent ce qu'ils font.

1. Ont-ils évalué avec précision la complexité du logiciel que vous construisez? On dirait qu'ils ne pensent pas que ce que vous faites est très difficile, alors pourquoi embaucher des personnes meilleures? Avez-vous présenté le cas où des erreurs sont commises et comment de meilleures solutions et une meilleure productivité pourraient rapporter de l'argent? Gagner du temps, c'est bien, mais beaucoup d'entreprises préfèrent perdre toute une semaine de programmeur que de leur donner l'argent nécessaire pour acheter un tapis de souris.
2. Votre entreprise est-elle attrayante pour les bons programmeurs? Sont-ils capables de les identifier? Rien de pire que d’embaucher un développeur senior, payez-leur plus d’argent et entraînez toute l’équipe en raison de leur manque de compétences et / ou de leadership.
3. Votre entreprise peut-elle utiliser un bon programmeur? Si tout ce qu'ils veulent faire, c'est leur lancer des spécifications de mauvaise qualité et leur dire simplement d'aller le construire, à quoi ça sert? Vont-ils leur donner la liberté de faire les choses à leur manière? Après tout, une bonne programmeuse, par définition, sait mieux utiliser son temps. Ils ont un impact sur ceux qui les entourent et font progresser les autres programmeurs. Ils introduisent de meilleures conceptions et architectures que les autres utilisent pour rendre le produit encore meilleur.

Désolé, mais je sens que votre entreprise ne sait pas quoi faire avec un bon programmeur. Vous voudrez peut-être donc les convaincre d'embaucher de meilleurs gestionnaires et de résoudre ces problèmes internes.