Bonne année à tous!
Inspiré de l'article Business, je vous aime, collègues Verovir , ainsi que de son propre article. Une discussion nocturne sur les licenciements (bien que ce dernier mérite une réponse détaillée séparée).
Chers collègues, dans cet article, vous avez bien identifié les principaux problèmes que vous pouvez rencontrer dans le secteur informatique (et pas seulement).
Mais une évaluation objective et des recommandations pour chacun de ces points («ce qui s'est réellement passé et que faire») est une question discutable.
// Au fait, il en va de même pour votre article précédent
Par exemple.
Vous avez parlé d'un diplômé VMK qui a facilement dispersé vos chefs d'équipe et est parti pour la Californie, puis les traces sont perdues.
Il s'agit d'une histoire bien connue de l'ère soviétique, lorsque les usines n'aimaient pas les diplômés chauds qui établissaient plusieurs normes par unité de temps.
Ils n’ont pas aimé parce que «qu’aujourd’hui est un exploit, demain est un plan».
Demain, ce diplômé partira pour la Californie, ou deviendra une famille et une hypothèque, et deviendra le même chef d'équipe qui n'attrape pas la souris que vous avez licencié à cause de lui.
Vous avez marché sur un râteau, mais vous n'avez pas remarqué de coup au front.
Cela est indépendant de la qualité réelle de ces chefs d'équipe (selon que leur licenciement était soit votre erreur, soit qu'ils devaient être licenciés sans rapport avec le diplômé VMK).
Vous écrivez sur l'entreprise, mais l'entreprise ne concerne pas uniquement les exploits de choc dans une seule tâche, avec un facteur de bus élevé.
Les affaires consistent à résoudre des tâches à grande échelle avec une équipe qui avance lentement (oui, avec des chefs d'équipe tels que le vôtre, avec des employés qui pensent comme des enfants à emporter de la maternelle, etc.), mais sûrement, comme un brise-glace, et balaie irréversiblement tout sur son passage et avec un degré élevé de probabilité atteint les résultats prévus.
Selon mes collègues qui ont étudié cette question, une équipe de cinq rockstar de génie motivée le fera en N temps, une équipe de cinq personnes le fera en 3xN temps.
Et cette évaluation me semble adéquate.
Notez que la hausse totale des prix sera d'environ 15xN - car vous devez non seulement payer 5 salaires, mais les payer 3 fois plus longtemps. Et cela ne compte pas les autres dépenses - un bureau plus grand, plus d'ordinateurs et d'autres dépenses.
Mais c'est une équipe. Avec une bonne gestion, il est garanti d'arriver au résultat prévu.
Et, si nous parlons d' affaires , l'équipe peut gérer les tâches en termes de volume et d'échelle, auxquelles les solitaires ne peuvent plus faire face.
Un autre exemple. Le collègue d' OlegGelezcov a bien noté que votre article est de la série «les rameurs ne valent rien» (au fait, votre précédent article se trouve dans la même steppe).
Autrement dit, pour la plupart, vous écrivez «peu importe comment vous êtes traité, effacez-vous, tirez des conclusions et passez à autre chose».
Parlons des rameurs
Apparemment, nous parlons de développeurs (programmeurs) et en partie d'ingénieurs QA
Récemment, il a été à la mode de comparer les développeurs non seulement avec les rameurs, mais aussi avec les travailleurs de la machine.
Voyons voir si c'est vrai.
Pour commencer, un développeur est un ingénieur, et un travailleur, même le plus qualifié, est un travailleur.
Et c'est une différence fondamentale, d'où tout le reste suit, jusqu'à des différences de 180 degrés.
Un développeur peut-il remplacer un testeur, un analyste, un PM?
Un testeur est facile.
Créez des cas de test pour votre code, cliquez sur tout et écrivez des autotests.
De plus, le développeur écrit toujours des tests unitaires et d'intégration.
Oui, ce sera un peu pire, car l'auteur testera son code d'un œil aveugle (mais vous pouvez le donner à un autre développeur).
Analytics - si ce n'est pas facile, mais pas difficile.
Une partie de la formation du développeur consiste précisément à étudier le domaine, l'énoncé du problème et la modélisation. Et maintenant, OOP démodé aujourd'hui est exactement à propos de "ceci".
PM'a? Eh bien, si un développeur est plus ou moins capable de regarder les tâches "d'en haut", plus ou moins sociable et généralement ami avec sa tête, alors s'il n'y a pas d'expérience, alors avec difficulté, avec moins de qualité, mais il le peut.
Un remplacement inversé est-il possible? Surtout si nous sommes honnêtes avec nous-mêmes et admettons que les testeurs, les analystes et les PM sont principalement des diplômés des universités techniques qui n'ont franchement pas «retiré» la programmation (et récemment, les gens sont venus pour «entrer dans l'informatique» du tout parties, et précisément ces positions; des exceptions se développent))?
Un testeur - avec difficulté, commençant, très probablement, à partir d'un poste junior, de l'étude approfondie des langages et des plates-formes de développement, des modèles de développement (plutôt que des tests), de l'informatique en général, d'un changement dans le paradigme de la pensée, mais cela peut.
En d'autres termes, il peut, mais pas tout le monde, et avec de très grandes difficultés et dépenses.
Analyste? S'il existe une formation en ingénierie et en travail, il sera probablement en mesure, mais moins probable qu'un testeur.
Parce que, à l'exception rare des analystes forts (et en effet des analystes , pas des "analystes"), ceux qui n'ont pas maîtrisé le développement vont aux soi-disant analystes.
Et le fait que le développement nécessite une certaine composition psychologique (introversion, persévérance, concentration élevée; oui, il y a maintenant des tentatives de refaire l'industrie pour qu'au contraire l'hyperactivité soit demandée, mais nous discutons aussi de ce problème), et moderne les analystes "en ce sens sont nettement plus éloignés des développeurs que des testeurs.
En général, le concept d' analyse ne concerne pas le rôle qui a été appelé "analyse" dans les processus de développement modernes.
En d'autres termes, non plutôt que oui.
PM? Comme le dit le proverbe, "il n'y a pas de temps pour expliquer." Avec un degré de probabilité élevé, non, à très peu d'exceptions près.
Et si nous ne parlons pas d'un système lorsque l'entreprise développe délibérément des gestionnaires de PM / ligne à partir de développeurs, et non à partir de testeurs et d'analystes.
Mais dans le cas de l'usine et des travailleurs, la situation est plutôt miroir.
En gros, si vous envoyez le directeur, le comptable, le commerçant à des cours de 3 mois, au moins, ils pourront remplacer le tourneur, le soudeur, le serrurier dans les catégories initiales.
Mais un travailleur peut-il remplacer ces rôles après une formation de 3 mois?
Peut-être qu'un travailleur hautement qualifié pourra remplacer un comptable (pas le principal) après les cours et réduire le débit avec le prêt et transférer des fonds et des fonds entre comptes (si cela sera intéressant pour lui est une autre question).
Directeur, agent de commercialisation, etc.? C'est manifestement plus difficile, sinon de parler d'exceptions explicites.
Si quoi que ce soit, la discussion ci-dessus sur les divers métiers et rôles n'est pas pour élever quelqu'un par rapport aux autres, et vice versa.
Il s'agit du fait qu'il existe certains rôles dans le processus de production et de la valeur objective de chaque rôle, qui est déterminée notamment (non) remplaçable par des représentants d'autres rôles.
Il s'agit du fait que tous ces discours à la mode ces dernières années sur les "rameurs", "les développeurs à la machine" - ce n'est qu'une tentative systématique de minimiser le rôle des développeurs.
Ceux qui font avancer ce sujet ne réussiront pas à la fin, car il y a la nature des choses dont tout le reste découle. Un développeur est un ingénieur , pas un rameur ou un travailleur (avec tout le respect que je lui dois).
Et tôt ou tard, tout reviendra à la case départ, car cela ne fonctionne pas d'une autre manière, ou tout se brisera lorsque tout le monde partira pour le contrôle qualité, les analystes, les PM et que personne ne voudra aller chez les développeurs (et il n'y a personne d'autre )