Le plus triste dans la situation actuelle est que l'informatique devient progressivement une industrie où il n'y a pas du tout de mot « stop » dans le nombre de responsabilités par personne.
En lisant les offres d'emploi, parfois vous ne voyez même pas 2-3 personnes, mais toute une entreprise réunie en une seule personne, tout le monde est pressé, la dette technique augmente, l'ancien héritage ressemble à la perfection sur fond de nouveaux produits, car au moins a un dock et des commentaires dans le code, les nouveaux produits sont écrits à la vitesse de la lumière, mais par conséquent, ils ne peuvent pas être utilisés avant un an après leur écriture, et souvent cette année n'apporte pas de profit, de plus, le coût de le cloud est supérieur aux ventes du service. L'argent des investisseurs sert à maintenir un service qui ne fonctionne pas encore, mais qui a déjà été mis à disposition sur le réseau en tant que travailleur.
A titre d'exemple : une entreprise bien connue dont le remaster d'un ancien jeu a reçu les notes les plus basses de l'histoire de l'industrie. Je faisais partie de ceux qui ont acheté ce produit, mais même maintenant, ce produit fonctionne terriblement et, en théorie, n'aurait pas encore dû être commercialisé sous cette forme. Remboursements, baisse de note, grand nombre d'interdictions d'utilisateurs sur les forums pour plaintes concernant le fonctionnement des services. Le nombre de patchs ne ravit pas, mais terrifie, mais quand même, le produit n'est pas utilisable. Si cette approche conduit à de tels résultats pour une entreprise qui se développe depuis 91, alors pour les entreprises qui débutent, la situation est encore pire.
Mais nous avons regardé les résultats de cette approche de la part de l'utilisateur du service, et regardons maintenant les problèmes rencontrés par les salariés.
J'entends souvent dire qu'il ne devrait pas y avoir d'équipes DevOps, qu'il s'agit d'une méthodologie, etc., mais le problème est que, pour une raison quelconque, les entreprises ont cessé de chercher des noks, des dba, des infructors et des ingénieurs de construction - maintenant, tout est un ingénieur DevOps chez une seule personne. Bien sûr, dans certaines entreprises, il existe encore de tels postes vacants, mais ils le sont de moins en moins. Beaucoup ont appelé ce développement, j'y vois personnellement une dégradation, il est impossible de maintenir un bon niveau de connaissances dans tous les domaines, et en même temps de réussir à travailler pas plus de 8 heures. Naturellement, ce sont des fantasmes. En réalité, de nombreux informaticiens sont obligés de travailler à la fois 12 et 14 heures, dont 8 rémunérées, et souvent sans jours de congé, car « on m'a confié une tâche, il n'y a pas de quais ni de virages, et le service coûte de l'argent ». et pour 1 dans le cloud, vous pouvez, en principe, ne pas percevoir de salaire en quelques mois, surtout si vous travaillez sur une base IP. En effet, on perd la parole en entreprise, avec la séparation des tâches, je suis de plus en plus confronté au fait que les managers se lancent dans les processus de développement sans rien comprendre du tout, ils confondent données métiers et fonctionnement des applications, du coup, c'est le chaos commence.
Lorsque le chaos commence, les entreprises veulent trouver le coupable, et ici vous avez besoin d'un coupable universel, il est difficile de rejeter la faute sur plus de 10 personnes, alors les managers unissent leurs positions, car plus un spécialiste a de tâches, plus il est facile de prouver sa négligence. Et dans les conditions Agile, trouver le « coupable » et donner la fessée est la base de cette méthodologie pour faire des affaires en management. L'agilité a longtemps été exclue de l'informatique et son concept principal est devenu l'exigence de résultats quotidiens. Le problème est qu'un spécialiste hautement spécialisé n'aura pas toujours un résultat quotidien, ce qui signifie qu'il sera plus difficile à déclarer, et c'est une autre raison pour laquelle les entreprises veulent des « spécialistes en tout ». Mais la raison principale, bien sûr, est la masse salariale - c'est lui qui est la principale raison de tous les changements, pour le bien de l'allocation, les gens ont accepté de travailler pour eux-mêmes et pour ce type. Mais en fin de compte, comme dans d’autres domaines, cela est devenu simplement une obligation, moyennant un paiement moindre pour un plus grand nombre de services fournis.
Désormais, vous pouvez même souvent voir des articles que les développeurs devraient déjà être capables de déployer, devraient traiter de l'infrastructure aux côtés d'un ingénieur DevOps, mais à quoi cela conduit-il ? C'est vrai - à une baisse de la qualité des services, à une baisse de la qualité des développeurs. Il y a littéralement 2 jours, j'ai expliqué au développeur qu'on pouvait écrire et lire depuis différents hôtes, et ils m'ont prouvé avec de la mousse à la bouche qu'ils n'avaient jamais rien vu de tel, le voici dans les paramètres ou l'hôte, le port, base de données, utilisateur, mot de passe et c'est tout.... Mais le développeur sait lancer des déploiements, écrire des yamls.... Mais il oublie déjà les tests unitaires et les commentaires dans le code.
En conséquence, nous constatons ce qui suit : un traitement constant, la recherche de solutions aux problèmes en dehors des heures de travail, une formation constante le week-end, et non pas pour augmenter les revenus, mais pour nous maintenir à flot. Les développeurs sont obligés d'aider un ingénieur DevOps avec CI/CD, et si le développeur n'a pas le temps, il commence à se taire, et les managers commencent à composter les cerveaux, et si cela ne contribue pas à augmenter le désir de faire des heures supplémentaires, alors postulez pénalités et amendes, la personne cherche un nouvel emploi, laissant derrière elle une dette technique de la taille de l'Everest, en conséquence, la dette commence également à croître parmi les développeurs. ils sont obligés d'écrire du code avec moins de refactorisation pour avoir le temps d'aider soit un ancien soit un nouvel ingénieur DevOps, et les managers sont plutôt contents de tout, car il y a un coupable et on le voit tout de suite, ce qui veut dire que la règle principale du management Agile est respectée, le coupable est trouvé, les résultats de sa flagellation sont visibles.
Une fois à l'ITGM, j'ai fait une présentation « Quand on apprend à dire non » - ses résultats ont été très révélateurs. Un grand nombre de personnes croient que ce mot est tabou, et tant que nous n'arrêterons pas de le penser, les problèmes ne feront que croître.
M'a en partie inspiré pour écrire cet article., mais je l'écrirai peut-être plus tard dans des termes moins agréables.
Seuls les utilisateurs enregistrés peuvent participer à l'enquête. s'il te plait.
Avez-vous été confronté au travail lorsqu'un employeur a tenté de remplacer plusieurs personnes par vous ?
-
65,6%Oui, je le rencontre régulièrement
-
5,4%Oui, rencontré 1 fois15
-
15,4%Je n'ai pas remarqué43
-
13,6%Je suis un bourreau de travail, je fais moi-même des heures supplémentaires38
279 utilisateurs ont voté. 34 utilisateurs se sont abstenus.
Source: habr.com