Le plus triste dans la situation actuelle est que l'IT devient progressivement un secteur où il n'y a tout simplement pas de mot "stop" en ce qui concerne la quantité de responsabilités pour une personne.
En lisant les offres d'emploi, on constate parfois qu'il ne s'agit même plus de 2 ou 3 personnes, mais d'une seule entreprise en une seule personne. Tout le monde est pressé, la dette technique augmente, l'ancien héritage, face à de nouveaux produits, semble parfait, car il a au moins de la documentation et des commentaires dans le code. Les nouveaux produits sont écrits à la vitesse de la lumière, mais au final, on ne peut pas les utiliser pendant un an après leur création, et souvent cette année ne rapporte aucun profit. De plus, les coûts liés au "cloud" sont supérieurs aux ventes du service. L'argent des investisseurs est dépensé pour le maintien d'un service qui n'est pas encore opérationnel, mais qui a déjà été lancé comme fonctionnel.
À titre d'exemple : une entreprise bien connue, dont le remaster d'un ancien jeu a reçu les critiques les plus basses de toute l'histoire de l'industrie. J'étais l'un de ceux qui ont acheté ce produit, mais même maintenant, il fonctionne horriblement, et en théorie, il n'aurait même pas dû sortir à la vente sous cette forme. Les demandes de remboursement, la chute des notes, un énorme nombre de bans d'utilisateurs sur les forums pour se plaindre du fonctionnement des services. Le nombre de correctifs n'est pas impressionnant, mais fait peur, et pourtant – le produit n'est pas utilisable. Si cette approche amène de tels résultats à une entreprise qui développe depuis 1991, la situation est encore pire pour les entreprises qui commencent tout juste leurs activités.
Mais cela, c'est ce que nous avons constaté du point de vue de l'utilisateur du service ; maintenant, regardons les problèmes qui ont surgi du côté des employés.
J'entends souvent l'affirmation selon laquelle il ne devrait pas y avoir d'équipes DevOps, que c'est une méthodologie, etc. Toutefois, les entreprises semblent avoir cessé de chercher des chefs de projets, des administrateurs de bases de données, des ingénieurs en infrastructure et des ingénieurs de build – maintenant, tout cela est fait par un ingénieur DevOps unique. Bien sûr, dans certaines entreprises, ces postes existent encore, mais ils se font de plus en plus rares. Beaucoup ont appelé cela une évolution ; personnellement, je vois cela comme une dégradation. Il est impossible de maintenir un bon niveau de connaissance dans tous les domaines tout en réussissant à travailler moins de 8 heures. Naturellement – c'est utopique. Dans la réalité, de nombreux professionnels de l'IT sont contraints de travailler 12 ou 14 heures, dont seulement 8 sont payées. Souvent, ils n'ont pas de week-ends, car « on m'a attribué une tâche, les documents sont inexistants ou défectueux, et de plus, le service coûte cher », et une seule erreur dans le cloud peut signifier ne pas recevoir de salaire pendant plusieurs mois, surtout si l'on travaille en tant qu'indépendant. Nous perdons de fait notre voix dans les affaires, avec la séparation des responsabilités. Je rencontre de plus en plus de cas où les gestionnaires s'immiscent dans le processus de développement, ne comprenant rien à ce dernier. Ils confondent les données commerciales et le fonctionnement des applications, ce qui entraîne le chaos.
Lorsque le chaos commence, les entreprises cherchent un coupable, et il faut un coupable universel. Attribuer la responsabilité à plus de 10 personnes est difficile, donc les gestionnaires combinent les postes, car plus un spécialiste a de responsabilités, plus il est facile de prouver sa négligence. Dans un environnement Agile, la recherche de « coupable » et la punition sont essentielles à cette méthodologie de gestion. L'Agile a depuis longtemps quitté l'IT, et son concept fondamental est devenu – réclamer des résultats quotidiens. Le problème, c'est qu'un spécialiste aux compétences étroites n'aura pas toujours de résultats quotidiens, ce qui rendra le compte difficile, et c'est une autre raison pour laquelle les entreprises souhaitent des « spécialistes polyvalents ». Mais la raison principale reste bien sûr la masse salariale – c'est la principale raison de tous les changements. Pour une prime, les gens acceptaient de travailler pour eux-mêmes et pour une autre personne. Mais au final, comme dans d'autres sphères, cela est simplement devenu une obligation pour un salaire moindre en échange d'un plus grand nombre de services fournis.
On voit de plus en plus d'articles affirmant que les développeurs doivent eux aussi être capables de déployer et de s'occuper de l'infrastructure aux côtés des ingénieurs DevOps. Mais qu'est-ce que cela entraîne ? Effectivement, une baisse de la qualité des services et des développeurs. Il y a à peine deux jours, j'expliquais à un développeur qu'il est possible d'écrire et de lire depuis différents hôtes. Et je me suis fait disputer, avec des preuves convaincantes, que cela n'existe pas ; il y a dans les paramètres orm host, port, db, user, password et c'est tout... Pourtant, le développeur sait lancer des déploiements et rédiger des YAML... Mais il oublie déjà les tests unitaires et les commentaires dans le code.
En fin de compte, nous constatons ceci : des heures supplémentaires constantes, des recherches de solutions à des problèmes en dehors des heures de travail, un apprentissage permanent le week-end, et non pas pour augmenter ses revenus, mais pour rester à flot. Les développeurs doivent aider les ingénieurs DevOps avec le CI/CD, et si le développeur n'a pas le temps, il commence à être débordé, les managers commencent alors à mettre la pression, et si cela ne suffit pas à augmenter l'envie de travailler en heures supplémentaires, des sanctions et des amendes peuvent être appliquées. La personne cherche alors un nouveau poste, laissant derrière elle une dette technique équivalente à l'Everest, et cette dette commence à croître aussi chez les développeurs, car ils sont contraints d'écrire du code avec moins de refactoring pour être à même d'aider soit l'ancien, soit le nouveau DevOps ingénieur. Les managers sont tout à fait satisfaits, car il y a un coupable visible, ce qui signifie que la règle principale dans Agile est respectée : le coupable est trouvé et les résultats de sa punition sont visibles.
Autrefois, lors d'une présentation à l'ITGM sur le thème « Quand apprendrons-nous à dire non ? » – les résultats étaient particulièrement révélateurs. Un grand nombre de personnes considèrent que ce mot est tabou, et tant que nous ne cesserons pas de le penser, les problèmes ne cesseront d'augmenter.
C'est en partie cet article qui m'a incité à écrire, mais je pourrais plus tard le rédiger en des termes moins euphémiques.
Seuls les utilisateurs enregistrés peuvent participer au sondage. , s'il vous plaît.
Avez-vous déjà été confronté dans votre travail à un employeur qui aurait voulu vous substituer à plusieurs personnes ?
65,6%Oui, je me heurte régulièrement à cela183
5,4%Oui, je l'ai déjà rencontré une fois15
15,4%Je n'ai pas remarqué43
13,6%Je suis un workaholic, je travaille moi-même en heures supplémentaires38
279 utilisateurs ont voté. 34 utilisateurs se sont abstenus.
Source : habr.com
