Je vais le décrire en utilisant l'exemple du développeur abstrait Tom. Tom a obtenu un emploi chez Internetmagazinzaden en tant que développeur PHP intermédiaire. La société crée des magasins en ligne allant du modèle à des magasins complexes avec un tas d'intégrations. La société a tout le meilleur Agile, SCRUM, stand-up et rétro. Tom travaille depuis 3 mois et tout va bien pour lui, il a lancé quelques IM, ils travaillent même et les clients sont contents.
Voici une nouvelle tâche pour le développement de la messagerie instantanée, mais avec intégration avec CRM. Tom commence par la tâche d'intégration et à un moment donné, il ne réussit pas et le terme s'étire sur une semaine. Au même moment, lors du rassemblement général, Tom dit qu'il «comprend le problème», espérant être déjà proche d'une solution. Tom se tourne vers le développeur senior Mike (qui n'est pas son mentor et se trouve juste non loin de Tom), il le dirige vers des manuels et explique brièvement ce qui doit être fait.
Tom part lire les tutoriels et régler le problème. Après quelques jours, il revient à Mike avec des questions sur l'intégration et ils les règlent ensemble.
Tom part pour régler le problème pendant quelques jours, après quoi il revient à Mike et lui donne la solution finale. Mike vérifie l'affectation et signale quelques bugs mineurs que Tom corrigera bientôt.
Cela semble tout à fait une image de travail, mais il y a plusieurs points qui nous montrent que Tom n'est plus un développeur intermédiaire comme nous le pensions auparavant, mais June.
- Tom a passé très longtemps (dans ce cas, une semaine) à traiter le problème et n'a pas signalé le problème à temps.
- Je ne pouvais pas le comprendre moi-même avec le tutoriel et au lieu de googler des moments incompréhensibles, je suis allé voir Mike.
- Tom a passé le temps d'un autre développeur au lieu d'utiliser des stand-ups et de discuter de ses problèmes là-bas.
Parfois, lors d'entretiens pour le poste de chef d'équipe, ils posent la question "Comment divisez-vous les développeurs en juin, moyen, senior?" Et ma réponse est quelque chose comme ceci:
- , ;
- , ;
- - .
Dans le cas de Tom, il vient de recevoir le tutoriel et la description de l'implémentation de Mike, mais il n'a pas pu le comprendre et est retourné à Mike. Ce fut pour moi la première "cloche" importante que nous ne sommes pas au milieu. Le deuxième appel important était que la compétence de «signaler un problème» est très importante pour le milieu, et s'il ne la possède pas, alors en termes de soft skills, cela le ramène aux juniors. La troisième «cloche» est l'attitude imprudente face au temps d'un autre développeur inhérent à Juniors, qui parfois ne comprend pas l'importance de suivre le processus et se tourne vers le développeur le plus «gentil» au lieu d'aller en tête et d'obtenir un mentor à travers lui. Ceci est important, car le développeur Mike est peut-être occupé sur un projet super responsable ou sa tâche nécessite une grande concentration, mais le programmeur John est littéralement assis à la table suivante,qui vient de terminer un projet et n'a pas encore eu le temps de se lancer dans un nouveau projet.
Prenons un autre cas. Le développeur principal Vasya travaille pour l'entreprise depuis longtemps. Vasya a un chef d'équipe, Petya. Et il se trouve que Petya est un leader très réfléchi et non seulement il définit une tâche, mais travaille avec un analyste système sur chaque aspect de celle-ci et ne la donne qu'ensuite au travail. Vasya et Petya travaillent dans l'entreprise depuis 4 ans et ce schéma est déjà dans l'ordre des choses. En même temps, Vasya met parfaitement en œuvre les tâches selon les spécifications techniques écrites, documente le code et se réjouit que tout soit si "beau et bien" avec lui.
Mais pas de chance, après un certain temps, l'entreprise ferme et Vasya doit chercher un emploi et pour une raison quelconque, ils commencent à qualifier Vasya lors d'entretiens non pas en tant que senior, mais en tant que milieu. "Comment est-ce arrivé? Où suis-je tombé? " Il se demande.
Tout est à nouveau simple, Vasya a perdu la capacité de trouver la solution optimale au problème, en 4 ans, l'analyste système et le chef d'équipe attentionné ont tellement détendu Vasily que cette compétence n'était plus nécessaire.
Que faire dans ce cas? Le plus souvent, après avoir trouvé cela dans une entreprise, vous ne devriez pas retirer des roubles aux développeurs et baisser leurs salaires (même indirectement), mais être perplexe face à la question "est-ce que cela peut être réglé?" Et si la réponse est «non», il vaut mieux dire au revoir à l'employé «gentiment», car à un moment donné, il sera insatisfait du fait que son salaire n'augmente pas, et le reste de l'équipe peut avoir des problèmes avec cela. Si la réponse est oui, vous aurez besoin d'un travail très réfléchi de la part du service de formation du personnel et du chef d'équipe. En effet, dans ce cas, vous devrez pomper la compétence de l'employé et le faire le plus doucement possible pour ne pas blesser sa fierté et lui donner la motivation de se développer.