Question:
Comment devrais-je aborder un patron qui continue à embaucher des travailleurs temporaires, pour me faire terminer quelque chose?
KAT
2018-10-09 18:22:07 UTC
view on stackexchange narkive permalink

Pour faire court, nous avons récemment eu beaucoup de travail à faire dans mon travail et pour combler ce vide, mon patron a embauché des travailleurs temporaires. Au début, il en a embauché trois qui sont restés environ deux mois, mais après que le client ait dépassé la date limite, il en a réembauché un récemment.

J'ai été très prudent de leur déléguer le travail comme ils l'ont fait un énorme gâchis de la base de code et puis quand une poussée vers la production approche, je suis approché pour le rendre réalisable. Mon patron devient un peu pointilleux à ce sujet et m'a dit qu'il était là pour m'aider, et je dois leur donner quelque chose à faire. Le problème est qu'il n'est pas un développeur, donc il n'a pas la perspective de ce qu'il faut pour réparer ou corriger un mauvais code; il a seulement la perspective de payer pour eux.

Je n'aurais aucun problème à leur donner des choses à faire si je ne savais pas (comme c'est arrivé de nombreuses fois maintenant) que dans quelques semaines ils Je partirai et quand quelque chose se cassera, je serai celui qui sera chargé de le réparer en un temps record. La dernière fois que cela s'est produit, un temporaire a passé près de deux semaines à écrire du code que je devais ensuite corriger dans un jour.

Comment transmettre cela sans avoir l'air d'un perfectionniste qui veut juste tout faire lui-même?

Les commentaires ne sont pas destinés à une discussion approfondie;cette conversation a été [déplacée vers le chat] (https://chat.stackexchange.com/rooms/84260/discussion-on-question-by-kyle-how-to-approach-boss-that-keeps-hiring-temp-worke).
Êtes-vous impliqué dans le processus d'embauche / de vérification?Les nouveaux employés subissent-ils des tests techniques?Sont-ils en fait des travailleurs temporaires ou des pigistes?
Avez-vous réussi à corriger 2 semaines de code temporaire en un jour?
Si le manager n'est pas dans le logiciel, dans quel domaine est-il?Est-il possible que vous puissiez faire une analogie qui lui convient mieux?
Ce n'est pas à vous de décider comment votre patron ou votre entreprise dépense son argent.Tout ce que vous pouvez faire est d'essayer de faire "votre truc" ... aussi bien que vous le pouvez.
@mathreadler Complet et absurde.Tout patron digne de ce nom est capable d'écouter ses subordonnés lorsqu'ils soulignent qu'une stratégie crée plus de problèmes qu'elle n'en résout et augmente finalement les coûts.Bien sûr, il y a de terribles patrons, mais cela ne veut pas dire que vous n'essayez même pas de leur faire prendre conscience du problème.
@jpmc26 Dans leur esprit, c'est probablement plus un atout et non un problème, et tout à coup, ils obtiennent ces longues vacances inexplicables.Hmmm :) Pouvez-vous mieux comprendre maintenant?
Dix réponses:
Philipp
2018-10-09 18:59:57 UTC
view on stackexchange narkive permalink

Vous voudrez peut-être prendre quelques arguments du livre The Mythical Man-Month de Frederick Brooks. Bien qu'il ait été initialement écrit en 1975 (remanié en 1995), il reste l'un des travaux les plus importants concernant la gestion des équipes de développement logiciel.

Il est surtout connu pour codifier la loi de Brooks:

l'ajout de ressources humaines à un projet logiciel tardif le rend plus tard

Les raisons sont:

  • Nouveau les développeurs doivent être informés de l'architecture existante du projet avant de pouvoir faire quelque chose d'utile. Cela prend du temps à l'équipe de développement existante.
  • Il y a une limite supérieure au nombre de personnes qui pourront apporter des contributions utiles à un projet de développement logiciel en même temps. Il est souvent impossible de trouver des sous-tâches raisonnables à attribuer à de nouvelles personnes.

Un bon développement logiciel nécessite une équipe centrale stable qui travaille ensemble du début à la fin.

Votre responsable n'est peut-être pas au courant de cette règle. Il essaie donc de vous aider de la seule façon à laquelle il pense: ajouter plus de personnes à votre projet.

Les commentaires ne sont pas destinés à une discussion approfondie;cette conversation a été [déplacée vers le chat] (https://chat.stackexchange.com/rooms/84440/discussion-on-answer-by-philipp-how-should-i-approach-a-boss-that-keeps-embauche-t).
JohnHC
2018-10-09 18:34:04 UTC
view on stackexchange narkive permalink

Le problème avec les intérimaires et les sous-traitants (divulgation, j'en suis un) est qu'il n'y a souvent pas de retour si la livraison est mauvaise.

Cela peut valoir la peine d'avoir une discussion avec votre patron sur la qualité de les temps. Embaucher à bas prix signifie déplacer les coûts plus loin, mais il finira par payer pour corriger le code.

Vous pouvez également demander à être impliqué dans le processus de recrutement en fournissant un petit test de codage pour vous assurer que les intérimaires valent vraiment la peine d'être embauchés. Rien de trop dramatique, moins d'une heure de travail pour se faire une idée de ses capacités.

Ister
2018-10-10 12:31:51 UTC
view on stackexchange narkive permalink

Ce que vous avez écrit soulève en fait un certain nombre de signaux d'alarme suggérant que la seule solution viable est de changer votre travail. Vous avez écrit que votre responsable ne tient pas compte de l'importance et de la valeur des tests unitaires, je suppose que c'est la même chose avec l'analyse et la conception, car ces idées fausses sont généralement regroupées. Vous dites également qu'il pense que l'ajout d'un développeur temporaire pendant un mois entraînera autre chose qu'un retard supplémentaire. Apparemment, votre manager n'a pas la moindre idée de la manière dont le projet de développement logiciel doit être exécuté et il y a peu ou pas de chances qu'il change d'avis

Pourtant, vous pouvez essayer.

Pendant un 9 femmes à accoucher en un mois est un moyen populaire de «prouver» que l'ajout de personnes n'accélère pas nécessairement le travail, cela ne fonctionne généralement pas pour quelqu'un qui ne comprend pas vraiment le problème mais qui connaît mieux le problème. Plutôt que cela, utilisez l'exemple de creuser un puits.

Disons que vous devez creuser un puits de 1 m de diamètre et 15 m de profondeur. Un homme a besoin de 15 heures pour le creuser. Combien d'hommes faudra-t-il pour accomplir la tâche en 1h?

La réponse que la plupart des managers (et la plupart des gens en général) vous donneront sera que ce sera 15 hommes mais ce n'est pas vrai et c'est simple à montrer à quiconque n'a aucune idée du codage qui creuse du tout. Tout comme dans le codage, vous pouvez remplacer une personne en train de creuser par une autre. Vous pouvez (à un certain niveau) partager votre travail. Mais un seul homme rentre dans un trou de 1 m de large pour travailler. Si vous ajoutez une deuxième personne à l'intérieur, la première sera gênée par elle et ne pourra pas faire son travail.

Vous pouvez accélérer un peu le travail en échangeant une personne épuisée par une nouvelle pour qu'une deuxième personne vous aide un peu. Ce ne sera pas la moitié du temps, une sauvegarde ne dépassera probablement pas 1/3. Mais ajouter un troisième homme n'aidera probablement pas du tout. Les deux échangeront toutes les heures environ, ayant le temps de retrouver leur endurance. Donc, si vous insistez pour utiliser le troisième ouvrier à l'intérieur du trou, le seul effet sera que vous perdrez plus de temps lorsqu'ils échangent ou simplement plus d'hommes attendent leur tour, étant payés mais n'apportant aucune valeur supplémentaire. Pas de gain au mieux, une perte au pire.

Ainsi, vous pouvez utiliser la troisième personne pour certaines tâches auxiliaires, comme enlever l'excès de saleté du voisinage du puits. Très bien, cela ajoute peut-être 5% de gain de temps pour le coût d'un ouvrier complet.

Mais comment pouvez-vous utiliser un quatrième homme, sans parler de 11 autres? Si vous insistez vraiment pour les utiliser tous, vous commencerez à avoir des coûts supplémentaires tels que la communication, le temps de permutation, etc. .

Et cela suppose que tous les collaborateurs sont qualifiés . Et si creuser un puits nécessitait une précision supplémentaire et que vous engagiez un intérimaire non formé pour cela? Vous devez leur apprendre pour que vous passiez la première heure à montrer comment bien faire des murs pour qu'ils ne se désagrègent pas et comment obtenir cette forme parfaitement ronde. Ensuite, ils travailleront à 50% de la vitesse de l'homme formé et leur travail ne sera toujours pas parfait, donc le type permanent devra faire les correctifs, perdant du temps de son travail. En réalité, avant que la nouvelle personne ne puisse apporter quoi que ce soit mais retarde, le puits sera prêt. Et cela prendra plus de temps que si l'ouvrier qualifié creuse seul. Vous pouvez toujours utiliser un temp pour ces tâches auxiliaires ou les plus simples (pendant que je fais une pause au milieu, laissez les murs intacts), mais cela fait encore 5, peut-être 10% de gain au mieux. Et si la température atteint le mur, le travailleur qualifié doit réparer tout cela et ce n'est plus du tout un gain.

Et c'est quelque chose d'aussi simple que de balancer une pelle. Le codage est beaucoup plus complexe.

Résumez-le avec quelque chose comme ça:

Il est évident que vous devez former un développeur et 1 mois est un minimum pour les faire fonctionner au niveau de productivité de base s'ils sont qualifiés . Pendant la formation, vous devez investir le temps d'un développeur régulier dans la formation et le travail des intérimaires doit de toute façon être revu, donc ajouter quelqu'un à l'équipe pendant moins de 4 à 6 mois n'est rien d'autre que du gaspillage.

L'autre idée suggérait que vous pourriez être impliqué dans le processus d'embauche. C'est un bon conseil pour réduire le temps d'introduction d'une nouvelle personne dans l'équipe et limiter le nombre d'erreurs dans son code, mais cela nécessitera toujours une formation (une introduction). Donc, un intérimaire, même qualifié, pendant un mois est un gaspillage. Au mieux, vous pouvez les utiliser pour écrire des choses auxiliaires. Comme les tests unitaires ;-)

Si votre manager ne peut pas comprendre une telle comparaison, votre dernière option est de revenir sur le marché du travail.

"Disons que vous devez creuser un puits de 1 mètre de diamètre et 15 mètres de profondeur. Un homme a besoin de 15 heures pour le creuser. Combien d'hommes faudra-t-il pour accomplir la tâche en 1h?"ceci en particulier est fantastique, car contrairement à l'exemple de grossesse manifestement évident, il fournit le "gotcha!"angle qui est synonyme de ce qui se passe en essayant d'embaucher plus de développeurs, donc c'est plus cognitivement relatable en tant que métaphore, en termes de fournir ce superficiel "eh bien ça DEVRAIT fonctionner de cette façon!"première impression. Nous utilisons une "montée en puissance d'un mois" pour chaque poste, même les non-développeurs, et même cela ignore le coût pour le reste de l'équipe.
Ce qui est amusant, c'est que dans de nombreuses cultures, c'est une question mathématique typique au niveau primaire avec la * réponse acceptée * "1h".Je pense que cela pourrait être la source principale d'une idée fausse ultérieure selon laquelle l'ajout de ressources supplémentaires ** toujours ** réduit le temps de manière linéaire.Après tout, c'est ce qu'ils vous ont appris à l'école!
"il est impossible d'aiguiser un crayon avec une hache émoussée. Il est également vain d'essayer de le faire avec dix haches émoussées à la place."- Edsger W. Dijkstra
L'exemple du puits est probablement meilleur que vous ne le faites - un homme doit creuser, soulever les déblais du trou et empiler les déblais en un tas, deux ou trois hommes le projet se décompose naturellement en tâches complémentaires (creuser, soulever, empiler) mais ajouter plus de personnel que le nombre de tâches complémentaires n'aide pas - soit vous ajoutez une pelleteuse et ils se gênent, soit vous avez des gens qui attendent car la quantité de déblais à soulever ou à empiler n'est pas suffisante pourles garder occupés.
"Vous avez écrit que votre responsable ignore l'importance et la valeur des tests unitaires ..." Ouais, non.J'ai vu les ordures qui passent parfois pour les tests.Les tests unitaires ne sont pas magiques.Si la personne qui les écrit n'est pas à la fois suffisamment compétente et expérimentée pour reconnaître un mauvais code sans eux, cela représentera un coût net à la fois au début et à long terme.Arrêtez d'agir comme une solution miracle et d'utiliser des approches de tarte dans le ciel pour parler de développement de logiciels.
@jpmc26 aucune technique n'est une solution miracle dans le développement de logiciels (et dans d'autres domaines aussi, je crois).Encore des tests unitaires aident et bien écrits vous apportent une valeur ajoutée.Si le patron refuse de l'admettre, il est généralement incompétent.Et c'est un drapeau rouge pour moi.Notez que j'ai vu un excellent code sans tests unitaires ainsi qu'un code médiocre avec eux.
xyious
2018-10-09 21:45:32 UTC
view on stackexchange narkive permalink

Ceci s'aventure dans des conseils généraux de développement logiciel ....

  1. Si le code que quelqu'un écrit casse quelque chose, ajoutez un test automatisé pour que vous puissiez le voir plus tôt la prochaine fois.

  2. Examinez les demandes d'extraction, ne fusionnez rien tant que vous n'êtes pas sûr que rien d'autre ne casse.

  3. Les tests font une bonne spécification. Le TDD est un bon moyen de vous assurer que ce que vous obtenez est ce que vous voulez. Donnez à quelqu'un une tâche pour écrire le code dont vous avez besoin (comme illustré par les tests que vous avez déjà écrits).

  4. La programmation par les pairs peut être une option. Vous pouvez corriger les choses immédiatement et répondre aux questions au fur et à mesure.

J'ajouterai également à cette excellente réponse, que s'ils écrivent du code pendant 2 semaines sans aucun examen de ce qu'ils font, cela doit changer.Donnez-leur des tâches de 1 à 3 jours et vous pourrez revoir et détecter les erreurs beaucoup plus tôt.
Non pas que cette réponse ne soit pas correcte, mais étant donné la description du PO de leur lieu de travail, je doute que le «test» entre même dans le vocabulaire du patron.Et les revues de code?Le patron d'OP ne verra que de l'argent s'écouler ...: - /
Tu as probablement raison.Mais à ce stade, vous devez parler au patron et lui dire clairement que l'embauche et le licenciement de travailleurs temporaires coûteront beaucoup plus cher que de faire les choses correctement.
C'est la bonne réponse, le problème ne vient pas des développeurs temporaires, le problème est le manque de discipline et d'organisation.@Aaron-f Vous n'avez pas plus besoin de parler à votre patron de vos cas de tests que de vos noms de variables.Vous écrivez du code avec des tests, point final.S'il n'y a pas de tests, ce n'est pas fini.Meilleur moyen d'être sûr que cela est vrai: TDD
Le fait est que moins cher ce trimestre l'emporte presque toujours sur moins cher au cours des deux prochaines années.À chaque étape du développement, le coût de réparation d'une erreur augmente d'un facteur de 10. Coût de 10 dollars pour résoudre un problème lors de la conception?Il en coûtera 100 à réparer une fois le code en développement, 1000 à corriger dans les tests d'intégration et 10000 à corriger en production.Les processus agiles ne font qu'atténuer ce problème en examinant plus fréquemment, mais c'est toujours vrai.Le patron d'OP repousse les coûts à une phase ultérieure pour que le résultat soit bon maintenant au prix de multiplier les risques, les coûts et les impacts du calendrier plus tard.
"Les tests font une bonne spécification. Le TDD est un bon moyen de s'assurer que ce que vous obtenez est ce que vous voulez."C'est catégoriquement faux parce que les personnes qui déterminent les exigences ne peuvent probablement pas les lire.Même dans ce cas, le code de test unitaire ne sera pas de meilleure qualité que le reste du code que quelqu'un écrit, ce qui signifie que si vous avez une personne qui n'est pas compétente, vous obtiendrez de mauvais tests avec le mauvais code, ce qui rendgérer le code * encore plus * cher.
Kilisi
2018-10-10 03:58:05 UTC
view on stackexchange narkive permalink

Comment aborder le patron qui ne cesse de recruter des intérimaires pour que je termine quelque chose?

Vous avez déjà. Tout ce que vous pouvez faire est de persévérer pour en parler au patron.

En attendant, il y a une solution, la raison pour laquelle vous devez refaire le travail est que vous avez découvert que c'était trop tard. Vous avez la possibilité de mettre en pratique certaines compétences et d'assumer plus de responsabilités, mais vous ne le faites pas. Ce n'est pas un problème ésotérique, c'est juste une façon de regarder un problème et une méthodologie de résolution. Cela vaut la peine d'être appris.

C'est l'un de ces moments où la microgestion est essentielle. Évaluez la situation dans son ensemble (y compris les gens, ils sont une ressource) et faites un plan de résolution, utilisez efficacement la main-d'œuvre dans ces conditions. C'est la SEULE façon de le faire, vous ne laissez même pas les personnes expérimentées s'écarter de votre plan, elles n'ont pas la vue d'ensemble, vous leur donnez de petites tâches et vérifiez tout ce qu'elles font, elles vous rendent compte à chaque étape.

Le plus important est de comprendre complètement le problème et d'avoir un plan solide. Ensuite, divisez-le en tâches plus simples dans la mesure du possible et ne comptez sur personne pour faire son travail sans supervision.

Bonne réponse - OP gérer les ressources en détail est la seule vraie réponse qui permet d'atteindre les objectifs commerciaux souhaités.
JimmyJames
2018-10-10 19:08:40 UTC
view on stackexchange narkive permalink

Si vous pouvez vous en tirer avec des arguments logiques comme les 9 mois pour faire une analogie de bébé, c'est génial mais, d'après mon expérience, cet argument ne fonctionne qu'avec des personnes qui comprennent déjà. Et même lorsqu'elles le font, elles seront souvent suivies de questions sur le nombre optimal de membres de l'équipe.

Ce qui pourrait aider si la logique échoue est de rassembler des données montrant comment le travail est réellement effectué et se concentrer sur le travail des gens qui doit être corrigé. Si vous regroupez ces éléments, vous pouvez afficher un graphique assez spectaculaire de ceux qui ajoutent réellement à la sortie et de ceux qui y contribuent.

Une partie du problème est que les gestionnaires sont sous pression pour livrer et ils ont besoin pour montrer qu'ils font quelque chose pour y arriver. Ne rien faire pourrait les rendre inefficaces et non pertinents. Vous pouvez y contribuer en proposant des modifications que votre responsable peut apporter et qui aideront (meilleures machines, ordinateurs portables, tableaux blancs, un serveur de build, différentes heures, espace de travail isolé, etc.)

Twyxz
2018-10-09 18:40:06 UTC
view on stackexchange narkive permalink

Le niveau de compétence des intérimaires dépend probablement du montant que votre manager y investit. Comme ce ne sont que des intérimaires, il ne veut évidemment pas gaspiller trop de fonds. Comme vous le dites, votre patron n'est pas un développeur et suppose probablement qu'un codeur peut coder.

Cependant, si cela augmente votre charge de travail à long terme et que cela affecte votre travail actuel. Vous devez le tirer pour un 1x1 et simplement transmettre vos problèmes et la raison pour laquelle vous ne leur déléguez pas autant de travail et vos soucis pour l'avenir si vous leur déléguez du travail

Vous voulez Assurez-vous de ne pas avoir l'impression que vous avez un essai avec votre patron, mais en même temps, vous devez faire passer le message car il ne comprend pas ce qui se passe dans le développement. Si vous mentionnez simplement que vous seriez heureux de déléguer le travail, mais seulement lorsque vous vous sentez en sécurité.

Ross Millikan
2018-10-12 02:27:27 UTC
view on stackexchange narkive permalink

Je trouve utile de discuter d'un exemple spécifique. Prenons un cas de quelque chose qu'un intérimaire a fait et que vous avez dû réparer. Décrivez le problème sur lequel vous travaillez. Faites une chronologie minutieuse des événements, indiquant quand le temp a été invité à y travailler, combien de temps le temp a travaillé dessus, quand les problèmes ont été découverts, comment les problèmes ont été résolus, et quand le code était prêt ou du moins revenu à utilisable. Comparez avec une estimation de la façon dont cela aurait fonctionné avec une équipe de développement stable. Vous pouvez admettre que vous avez choisi l'exemple, mais que vous avez également une liste de nombreux problèmes où cela s'est produit.

Maintenant, discutez de votre solution, qui semble embaucher un membre permanent du personnel. Combien de temps faudra-t-il pour former cette personne (mais vous ne le faites qu'une fois, pas une fois par intérim), comment les coûts se comparent-ils (comme vous le savez), etc.

Cela ressemble à votre patron / l'entreprise ne comprend pas que vous avez trop de travail à faire. L'embauche d'intérimaires a du sens lorsque la surcharge est temporaire, mais c'est une solution très coûteuse lorsque la surcharge est permanente. Vous devez faire ce cas.

BryKKan
2018-10-12 21:13:25 UTC
view on stackexchange narkive permalink

Les autres réponses sont toutes très bonnes. Cependant, je suggérerais une autre approche. S'il s'agit d'un problème récurrent, c'est peut-être, comme votre responsable semble le penser, une indication que votre charge de travail est trop élevée pour que ses attentes soient satisfaites par vous seul.

Vous faites remarquer que sa solution à ce problème ne fonctionne pas, et vous devrez peut-être lui expliquer pourquoi. Les autres réponses couvrent la plupart des arguments que vous pourriez faire valoir à cet égard. Mais si vous voulez voir un changement, la meilleure façon d'accomplir cela est généralement de suggérer votre propre solution alternative.

Peut-être qu'au lieu de continuer à embaucher des intérimaires, il pourrait envisager un ajout permanent à l'équipe. Si vous êtes réellement prêt à déléguer des tâches, mais que vous ne pouvez pas parce que la qualité du code n'est pas à la hauteur, c'est la partie que vous devez corriger. Cependant, si vous voulez que quelqu'un investisse dans l'apprentissage de votre architecture et de votre style de codage, il doit s'attendre à ce que l'investissement soit rentable. Un ajout permanent à l'équipe entraîne des coûts supplémentaires, mais l'amélioration de la qualité de leur contribution et la réduction du besoin de supervision / retouche peuvent facilement se rentabiliser à long terme.

Brythan
2018-10-15 07:23:39 UTC
view on stackexchange narkive permalink

Tests unitaires

Cette réponse suggère que vous devriez écrire des tests unitaires et les faire coder pour les tests. C'est une approche, mais cela vous laisse la tâche d'écrire des tests unitaires. Ce n'est peut-être pas ce que vous voulez. Et pour obtenir les meilleurs résultats, vous devez écrire de bons tests complets et avoir de bons développeurs. Parce que les tests contrôlent le résultat plutôt que le processus. Il est tout à fait possible d'écrire du code moche (difficile à maintenir et à modifier) ​​qui passe les tests.

Une autre approche consiste à changer les choses. Au lieu d'écrire des tests, demandez aux autres développeurs d'écrire les tests. Vous continuez à écrire le code que vous alliez écrire de toute façon. S'il réussit les tests, tant mieux. Si ce n'est pas le cas, vous pouvez alors vous demander pourquoi. Si la raison est que le test est nul (ce qui signifie qu'il ne correspond pas aux exigences réelles), supprimez le test. Chaque fois que vous faites cela, enregistrez cette décision.

Vous pouvez également consulter les tests de réussite pour leur utilité. Encore une fois, s'ils ne sont pas utiles pour codifier les exigences, supprimez-les. Enregistrez la décision.

Cela repose sur le fait qu'il est plus facile de revoir les tests que le code. Il est donc beaucoup plus facile de voir si un développeur peut passer de l'écriture de tests au code que de déterminer si le code du développeur est suffisamment bon à lui seul.

À la fin du mandat du développeur temporaire, rédigez des statistiques sur le nombre de tests utiles ou supprimés. Ce sont alors les informations que vous présentez à votre patron lorsque vous vous opposez à l'embauche de plus d'intérimaires. Incluez le temps qu'il a fallu pour examiner les tests par rapport au temps qu'il aurait fallu pour écrire la suite de tests finale. Si ce nombre est net négatif, alors la société a payé de l'argent pour un «développeur» pour aggraver votre logiciel. Même s'il est net positif, comparez le coût de l'intérim à ce que votre coût aurait été.

D'après mon expérience, les patrons répondent le mieux aux arguments financiers avec des preuves. Sans la preuve, ils peuvent rejeter l'argument. Avec des preuves techniques mais pas financières, ils ne comprendront pas nécessairement les preuves (certains peuvent mais beaucoup ne le feront pas). Alors exprimez toute preuve technique en termes financiers.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 4.0 sous laquelle il est distribué.
Loading...