Que peut-on faire quand “donner l'exemple” ne fonctionne pas? [fermé]

40

Je travaille pour une grande entreprise (plus de 8 000 employés) depuis près de 2 ans et j'ai été embauché juste après avoir terminé mes études.

Tout le monde ici est confronté quotidiennement à un code hérité qui est souvent très mal conçu et bourré de bidouilles. Au début, je suis resté discret, en essayant de ne pas trop critiquer les choses. Mais la situation actuelle est devenue très difficile à vivre et personne ne semble vouloir améliorer / remplacer les outils que nous utilisons.

Pour être plus explicite, nous avons:

  • Un outil de contrôle de source obsolète (Visual SourceSafe)
  • Vieux makefiles qui ne supportent que la reconstruction complète
  • .def fichiers qui doivent être gérés manuellement et séparément pour toutes les architectures existantes
  • Fichiers d'en-têtes monolithiques et projets avec très peu de fichiers différents (mais chacun a environ 3000 lignes de code, ce qui prend parfois en charge des tâches très différentes)
  • aucune utilisation des « nouvelles » installations de langues (et std::stringn'est pas nouvelle mais personne sauf moi l' utilise)

J'ai décidé, il y a quelques mois, d'agir, en concevant un nouvel environnement de compilation. Je pouvais obtenir des versions incrémentielles fiables, des temps de compilation plus rapides, des projets mieux structurés, la .defgénération automatique de fichiers. J'ai même créé un pont de / vers Git vers / à partir de Visual SourceSafe.

J'ai montré mes réalisations à plusieurs collègues et à notre patron, mais c'était comme si personne ne s'en souciait. Ils étaient tous du genre "Eh bien ... les gens ont l'habitude de le faire ainsi maintenant. Pourquoi changerions-nous les choses?"

Les changements que j'ai suggérés ont été conçus de manière à permettre une transition en douceur de l'ancien système au nouveau. Chaque amélioration peut être appliquée séparément et en toute sécurité.

J'ai même essayé d'impliquer certains de mes collègues dans les changements. Mais jusqu'à présent, pas de succès.

Avez-vous déjà fait face à une situation similaire? Que peut-on faire quand "donner l'exemple" ne fonctionne pas?

ereOn
la source
10
"J'ai décidé, il y a quelques mois, de faire quelque chose à ce sujet" ... "J'ai montré le résultat à mon patron". On dirait que vous vous êtes trompé dans cet ordre.
3
@ ThorbjørnRavnAndersen: Je ne suis pas sûr de l'obtenir: comment suis-je censé montrer quelque chose que je n'ai pas encore fait? Ou peut-être que vous vouliez dire que j'aurais dû demander avant de le faire?
ereOn
21
Je suis allé là-bas, et à l’OMI, vous devez sortir de là, car, comme dit le proverbe, "un idiot vous battra toujours - d’abord, il vous abaissera à son niveau, puis vous battra avec son expérience ". Si les gens ne reconnaissent pas le besoin de mise à niveau, c'est la stagnation professionnelle, et la stagnation dans notre domaine est la mort. Vous pouvez mettre les choses que vous avez faites sur votre CV et si vous êtes bon, vous aurez probablement un bon travail dans un mois de toute façon.
TC1
8
Sainte vache, 8000 développeurs? Pour qui travaillez-vous, Facebook? Google? Microsoft?
Kyralessa
5
@Kyralessa: je ne pense pas que ni facebook ni google utilisent VSS.
Jake Berger

Réponses:

46

But pour la tête : "Diriger par l'exemple" devrait avoir une amélioration en tête, mais il devrait être ciblé sur les personnes non sur la technologie. Peut-être avez-vous investi trop de temps dans l'amélioration de la technologie, mais pas assez dans ce qui se passe dans leur tête. Pensez aux facteurs déterminants pour lesquels il existe une opposition à de nouvelles choses. Dans de nombreux cas, ils craignent simplement certains risques. Identifiez ces risques et trouvez des contre-arguments.

Prenez la viande fraîche : il est plus facile de gagner les employés qui veulent changer les choses. Vous les remarquez immédiatement quand vous les voyez.

Évitez la viande pourrie : certains ne comprendront jamais vos idées. Laissez-les de côté.

Devenez une masse critique : Trouvez des personnes qui comprennent vos idées. Gagner le par un. À un moment donné, si une masse critique est atteinte, de plus en plus de personnes suivront volontairement votre exemple.

Vocabulaire de gestion : les gestionnaires ne sont pas intéressés par de meilleures conceptions. Leur langue est l'argent et le temps. Précisez combien d'heures de travail sont perdues pour les bugs. Indiquez clairement que les clients insatisfaits qui rencontrent des bugs ne sont pas rentables. Montrez à quel point vous pouvez implémenter une nouvelle fonctionnalité plus rapidement. Vous devez choisir un autre vocabulaire pour les gestionnaires.

Tout est une question de processus : les meilleures technologies ne font pas de meilleurs programmeurs et programmes. Si vous avez de bons processus en cours d'exécution, même des technologies obsolètes donnent de bons résultats. Pensez aux efforts et au temps perdu. Peut-être que ce n'est pas la technologie, mais quelque chose dans les processus va terriblement mal. Dans la plupart des cas, c'est un manque de communication.

Trouver une nouvelle entreprise : Vous avez déjà beaucoup travaillé. Vous pouvez toujours essayer d'améliorer les choses, mais c'est également à vous de décider combien de temps vous voulez l'essayer et combien d'énergie vous voulez investir. N'oubliez pas que même si vous ne pouvez pas obtenir beaucoup d'amélioration, vous en apprendrez beaucoup sur vos efforts. À un moment donné, vous devez passer à autre chose.

Theo Lenndorff
la source
3
Associé à "augmenter la masse critique": youtube.com/watch?v=V74AxCqOTvg
back2dos
2
@ Farmor si vous ne pouvez pas les convaincre sans dire "allez lire une page Web", c'est peut-être vous qui devez mettre à jour vos compétences en communication.
1
Je veux dire s'ils sont têtus et n'écoutent pas les jeunes. Vous pouvez faire valoir votre point en vous référant à la documentation. Par exemple, s'ils disent que vos points ne sont pas corrects et que presque tous les experts en gestion de versions écrivent vos points, ils seront obligés de les soumettre. Et j'aime taquiner les arrogants. Par exemple, s'ils aiment Torvalds, vous pouvez dire que Torvals dit: "Si vous aimez SVN, vous êtes stupide et moche", comme il l'a fait dans son discours sur Google. Je ne comprends pas pourquoi la référence à la documentation quand une personne têtue ne croit pas que vous êtes la mauvaise chose. Vous pouvez même le faire sur votre téléphone et leur montrer tout de suite.
Farmor
6
-1 pour l'âgisme. Parfois, vous devez écouter attentivement le "spécialiste des fossiles" et vous permettre d'avoir un peu d'humilité. Puis, avec les connaissances acquises, améliore encore votre idée. La marginalisation des autres juste parce qu’ils sont vieux est un moyen sûr de perdre un précieux savoir-faire et le soutien de développeurs expérimentés influents.
Doug T.
1
@Lundin: Les gestionnaires devraient avoir une expertise technique, mais plus on grimpe haut, plus l'argent et le temps deviennent importants. Il n’ya rien de mal à cela, car il est nécessaire de garder une trace des aspects commerciaux d’une entreprise. Il est essentiel de donner aux gestionnaires les bons arguments entre les mains afin qu'ils puissent justifier leurs décisions à leurs gestionnaires. En tant que développeur, vous pouvez gagner un manager si vous lui fournissez les bons arguments.
Theo Lenndorff
30

Avez-vous déjà arrêté de considérer que vous pourriez avoir tort?

Donc, vous lisez des dessins de modèles et de modèles à l’école et vous êtes privé de ce qui semble être des pratiques relativement désuètes où vous travaillez. Il ne fait aucun doute que ce sont de meilleures idées et que les nouveaux projets devraient commencer avec cela à l’esprit, mais il semble que vous vous trouviez à un tout autre niveau.

Rassembler les développeurs, c'est comme essayer de rassembler les chats, ils ont un esprit qui leur est propre et une façon préférée de faire les choses, qu'ils soient corrects ou non. J'ai assez de mal à appliquer les meilleures pratiques et à gérer une équipe de 2 développeurs, mais vous travaillez pour une entreprise qui en compte 8 000.

C'est un nombre incroyablement énorme. Même un simple changement de processus selon lequel tous les développeurs doivent planifier des réunions et que le calendrier public ne soit pas au bureau devient une politique extrêmement complexe et difficile à mettre en œuvre de manière globale. La direction aurait également besoin de beaucoup d'efforts pour s'assurer que la politique est acceptée et adoptée à tous les niveaux.

Vous ne le penserez peut-être pas, mais quelque chose d'aussi simple que de passer de fichiers d'en-tête monolithiques à plusieurs, ou de déplacer le contrôle de version de SourceSafe vers Git nécessite un effort et un investissement énormes de la part de toutes les personnes concernées. Il faudrait:

  • Soutien important de la direction

  • Acceptation à l'échelle de l'entreprise

  • Investissement des heures de réunion pour tous les développeurs afin de les informer des nouvelles initiatives (Les réunions coûtent des heures de travail, les heures de travail coûtent de l'argent)

  • La formation doit être planifiée et mise en place pour que même les développeurs les plus stupides sachent ce qu’ils font.

  • Même en supposant une heure de formation, à travers 8 000 développeurs x 50 € / heure = 400 000 € de coût de formation. C’est plus que ce que mon équipe de développement logiciel reçoit au cours d’une année entière au titre du budget, des logiciels et du matériel. C'est un investissement exceptionnel que vous proposez.

Mais vous dites: "Pensez à tout le temps que vous pourriez gagner en augmentant votre productivité." À juste titre, mais un investissement important représente un risque important, alors je ferais mieux de vous assurer que vous avez raison à ce sujet avant de le signer. Si aucun des cadres supérieurs ne vous soutient, je ne peux pas justifier la dépense. En fin de compte, nous pourrions être inefficaces, mais nous sommes cohérents et avec 8 000 développeurs dans l’entreprise, la cohérence est le plus important.

Pour ce faire, vous devez vous connecter avec plusieurs responsables et trouver le moyen de mesurer avec précision et objectivité le temps perdu par les développeurs. Ce temps équivaut à des dollars et seuls les dollars et la politique vous aideront à gagner cette bataille.

arbre_érable
la source
4
Merci. Pour être honnête, au début, quand je suis arrivé, pendant quelques semaines, j'étais tout le monde: "Mais bon sang, ces gars-là n'ont aucune idée!" puis réalisé à quel point j'avais tort sur beaucoup de points. Mais après deux ans là-bas, je suis presque sûr que certains processus peuvent être améliorés et pourraient résoudre bon nombre des plaintes que j'ai entendues. Je comprends que ce soit aussi une question d’opinion, mais si quelqu'un me montrait la preuve que je faisais quelque chose d’inefficace, j’au moins l’écouterais, car il me rend service. Mon département n'est composé que de 40 personnes et nous seuls réalisons ce type de développement.
ereOn
1
Je suis sûr qu’ils peuvent s’améliorer, mais comme je l’ai dit, c’est différent pour moi de changer mes comportements et mes pratiques pour s’améliorer, que d’entraîner et de forcer 40 développeurs à le faire. Un responsable non technique ne vous écoutera pas sans des responsables politiques importants qui soutiennent l’idée.
maple_shaft
Ce n'est pas juste "les choses pourraient-elles être mieux faites?". Remplacer un référentiel source est un énorme changement. Ce changement a des coûts importants, notamment le recyclage de tout le personnel. Ensuite, il y a le risque. Êtes-vous sûr à 100% qu'il n'y aura pas de capacité dont l'ancien référentiel de code source a besoin, dont vous n'êtes pas au courant et que le nouveau référentiel n'aurait pas?
DJClayworth
@DJClayworth: le référentiel VSS n'est utilisé que comme système de stockage de base. Personne ne regarde jamais l'historique et efface généralement tout avant de copier à nouveau l'intégralité du répertoire.
ereOn
1
@ereOn S'il vous plaît rappelez-vous que vous travaillez pour une entreprise, et une entreprise est de gagner de l'argent, pas de code. Sauf si c'est un but non lucratif. Dans tous les cas, votre valeur primordiale pour vos clients n’est probablement pas «nous vous fournirons le code avec les fichiers de compilation les plus rapides du secteur». Vous devez déterminer ce qui compte pour votre patron (par exemple, réduire les coûts), puis les coûts. Facteur de personnel et coût des outils.
jasonk
7

Ce que vous avez décrit ne me semble pas "donner l'exemple", cela ressemble à une proposition que vous avez faite et qui a été rejetée. Pour montrer l' exemple, vous devez montrer aux gens que votre chemin est meilleur. Parmi les problèmes que vous avez énumérés, je vois trois que vous pouvez commencer à utiliser vos propres modifications.

Vieux makefiles qui ne supportent que la reconstruction complète.

Créez vos propres fichiers makefile localement et montrez à quel point vous êtes en mesure de travailler avec eux plus efficacement.

Fichiers d'en-têtes monolithiques et projets avec très peu de fichiers différents (mais chacun a environ 3000 lignes de code, ce qui prend parfois en charge des tâches très différentes)

Soit séparez les existants lorsque vous les touchez (sans rompre la construction), soit introduisez des fichiers d’en-tête plus petits lorsque vous écrivez un nouveau code. Lorsque les gens commenceront à travailler avec eux, ils se rendront compte qu'ils n'ont pas besoin de duplication.

pas d'utilisation des "nouvelles" installations de langage (enfin std :: string n'est pas nouveau mais personne d'autre que moi ne l'utilise)

Continuez à introduire de nouvelles fonctionnalités linguistiques chaque fois que vous touchez un ancien code ou introduisez un nouveau code. Assurez-vous de simplifier les choses. Ne vous découragez pas de celui-ci. La plupart d'entre nous sont paresseux. Si nous voyons qu'une nouvelle fonctionnalité de langage facilite les choses, nous l'adopterons.

Après quelques mois, si d'autres développeurs commencent à adopter vos améliorations, vous pourrez à nouveau contacter votre patron à propos de changements plus radicaux, tels que la mise à niveau de votre système de contrôle de source. Vous devez toutefois vous assurer que les autres développeurs voient les avantages, sinon ils ne passeront jamais. Une façon de le faire serait de suggérer d’essayer Git sur un petit projet auquel peu de développeurs sont actifs. De cette façon, vous pouvez en faire une évaluation, et non une transition à grande échelle vers un système inconnu.

Enfin, si après plusieurs mois d’essais, personne ne semble vouloir améliorer la façon dont les choses se passent dans votre entreprise, vous devez vraiment vous demander si c’est un bon choix pour vous.

Bill le lézard
la source
5

En plus de Lionel Barret (avec lequel je suis plutôt d'accord), considérons également la possible motivation à la résistance.

  • Évaluer le coût du processus réel
  • Évaluez le coût du processus car il sera comme le vôtre

Mais aussi:

  • Evaluer le coût du changement en terme de
    • Argent à dépenser pour configurer le nouvel environnement pour quiconque
    • Temps à consacrer à apprendre à tout le monde à s'habituer au nouveau mode (cela peut être facile pour vous, mais pas si facile pour des personnes qui ne sont pas au courant de ce que vous faites)
    • Temps nécessaire pour gérer le changement de manière non perturbatrice.

J'ai un suspect: combien y a-t-il dans votre entreprise de personnes comme vous en termes d'âge et de culture (hommes "école" et "type d'école")? Combien de personnes comme vous devraient être embauchées au cours des deux ou trois prochaines années et combien vont prendre leur retraite ou changer de rôle au sein de l'organisation?

Mon suspect est que vous n’êtes pas assez fort pour changer la société. Dans cette situation, la société va vous changer ou vous "expulser" (dans le sens où cela deviendra votre propre désir de partir), si vous ne pouvez pas attendre plus de temps.

Mais peut-être que la société évalue que les coûts supplémentaires que je vous ai décrits peuvent être économisés, permettant ainsi au processus de changement de se produire spontanément en attendant le remplacement naturel des personnes. Vous êtes juste au début d'un processus que vous ne pouvez pas voir car il n'y a rien (encore) derrière vous.

Emilio Garavaglia
la source
1
Vos suppositions sont claires: je suis en effet l’un des plus jeunes de mon département. Certains semblent se rendre compte que malgré mon jeune âge, j'ai des connaissances précieuses. Je sais et je comprends que j’ai encore beaucoup à apprendre (et j’espère le rester jusqu’au jour de ma mort), mais beaucoup d’entre eux semblent offensés par des choses qu’ils ne connaissent pas. Je ne veux pas les repousser ou voler leur travail ou quoi que ce soit: je veux juste améliorer les choses pour que tout le monde puisse travailler / vivre mieux. Devrai-je attendre d'être plus vieux pour prendre du poids?
ereOn
1
@ereOn: votre conduite est si noble que chaque personne saine d'esprit devrait vouloir travailler avec vous.
o0 '.
@ereOn: "Devrais-je attendre d'être plus vieux pour prendre du poids?" Pas nécessairement. L'âge est une valeur en terme d'expérience dans la gestion de la complexité. N’est pas une valeur pour comprendre de nouvelles choses (elles sont nouvelles pour tout le monde, et ne pas avoir d’arriéré peut être un avantage). Ce n'est pas un problème "personnel". C'est un problème de "masse critique". Jusqu'à ce que les personnes désirant le changement soient moins de 20%, elles seront étouffées. S'ils sont plus nombreux, le leadership devient visible (et n'est pas une question d'âge). Si un dirigeant peut atteindre 40% de la population, la "nouvelle chose" aura la citoyenneté appropriée. À partir de 60%, le changement est spontané.
Emilio Garavaglia le
3

À ce stade, je ne peux ajouter qu'une référence à l'article de Joel Obtention du résultat final lorsque vous n'êtes qu'un grunt . Les sections comprennent:

Stratégie 1 Il suffit de le faire

Stratégie 2 Exploiter la puissance du marketing viral

Stratégie 3 Créer une poche d'excellence

Stratégie 4 Neutraliser les Bozos

Stratégie 5 Évitez les interruptions

Stratégie 6 Devenir inestimable

Je résumerais l'article comme suit: "Le changement doit commencer par vous."

Joshua Drake
la source
2
J'ai trouvé que GTDWYOG n'était pas très utile. À mon avis, au moins le titre est trompeur: quelqu'un qui "est impliqué dans l'embauche" ou a la liberté d'ignorer le reste du monde tout en travaillant à la cafétéria n'est pas un grognement. Un grognement est une personne qui doit faire ce qui est dit, avec peu ou pas de contrôle sur les circonstances dans lesquelles il se trouve. Selon mon expérience, malgré le tableau idéaliste présenté ici à stackexchange, c'est le cas de la plupart des développeurs. Et pour ceux-là, GTDWYOG est plus une recette pour se faire virer pour désobéissance.
keppla
1

Malheureusement, les gens se retrouvent coincés dans une ornière et développent la mentalité selon laquelle «cela fonctionne, tout le monde l'utilise bien, pourquoi le changer» et cela devient exaspérant.

Vous vous y êtes pris correctement, non seulement en vous plaignant, mais en développant une solution viable comme solution de remplacement, il ne vous reste plus qu'à souscrire à la proposition.

Montrez votre responsable hiérarchique direct (ou votre responsable technique). S'ils ne sont pas intéressés, avez-vous quelqu'un en charge du contrôle du changement ou de l'innovation?

Mais potentiellement, vos idées et votre travail pourraient être ignorés et la situation restera telle quelle.

Amy
la source
2
ah, mais le nombre de fois que j’ai entendu "laisse-le réécrire, ce sera tellement mieux et plus cool dans les nouvelles technologies x" seulement pour constater que le nouveau n’était pas meilleur que l’ancien (et dans bien des cas pire). Assez souvent, jusqu'à ce qu'il y ait un besoin , il vaut mieux ne pas casser quelque chose qui fonctionne.
gbjbaanb
1

Vous devez exposer votre cas de manière à obtenir votre patron de votre côté. BTW, ce type de changement est proposé par un directeur technique ou un chef de projet, vous devrez donc vous engager pour le projet. (En guise d'alternative, vous pouvez proposer un audit technique, un étranger dira probablement la même chose que vous mais aura plus de poids.)

Jusqu'à présent, il ne voit pas la nécessité de changer, il semble que les produits cosmétiques changent: coûteuse sans avantages évidents sauf pour satisfaire la fantaisie d'un développeur. Deux choses lui importent: le flux d’argent et une équipe stable. La technologie est une boîte noire, si cela fonctionne, c'est suffisant.

Tout d’abord, vous devez prouver que la configuration actuelle lui coûte de l’argent. Quel est le coût / heure d'un développeur et combien d'heures de compilation plus rapide le sauveraient? Faire le calcul. En outre, rédigez des articles ou des témoignages sur les risques du pipeline de codes actuel et montrez-lui des chiffres inquiétants: "à cause des pratiques de codage SourceSafe / Bad, notre société a perdu XXXK $".

Deuxièmement, votre patron peut être coincé avec de vieux codeurs grincheux qui ne veulent pas changer leurs habitudes. Si le premier point est établi, vous devez également proposer une solution à ce problème. Combien êtes-vous ? Il pourrait être intéressant de souligner qu'il sera difficile de remplacer quelqu'un car le pipeline de codage actuel est bizantine. Vous devez proposer un plan pour mettre à jour l'équipe. Apprenez-leur la meilleure pratique de l'industrie et vérifiez qu'ils respectent les nouvelles règles.

Enfin, vous devez proposer un plan pour modifier la base de code, divisée en petits projets, avec jalons et affectation des ressources. En fait, vous vous vendez en tant que chef de projet et les modifications sont obligatoires pour disposer d'un pipeline de code solide.

Lionel Barret
la source
Merci pour tes conseils. Le fait est que le responsable semble beaucoup aimer tous les anciens développeurs (parce qu’en fin de compte, ils font le travail et ne comptent pas les heures). Je sens que j'ai très peu de poids parce que je suis jeune. Plusieurs personnes de mon département viennent me poser des questions sur les bonnes pratiques, mais même lorsque j'explique les choses avec beaucoup d'humilité, à un moment donné, elles ne veulent pas montrer qu'elles en savent très peu et essaient de défendre leurs anciennes méthodes.
ereOn
1

Travaillez-vous dans une organisation qui croit que bien faire les choses, que l’efficacité et l’innovation mènent au succès et à la rentabilité; ou que la recherche du revenu et le maintien des ventes sont les prémices du succès?

Les entreprises qui se comportent comme vous le décrivez sont bien implantées sur le plan technologique. Sur un marché concurrentiel, ils ne pourraient pas concurrencer une entreprise centrée sur les individus et l'innovation.

Si vous êtes la personne que vous dites être, travaillez dans un endroit qui honore et récompense votre esprit. Après des années d’installation, vous finirez par accepter la même philosophie que celle adoptée par vos supérieurs. Allez travailler ailleurs (probablement une organisation plus petite) qui valorise le travail acharné, l'inspiration, la créativité et le progrès.

Si vous ne prenez pas de risque et que vous le faites rapidement, vous finirez par vous installer et vous ne pourrez plus continuer à nourrir votre curiosité et votre créativité car elles sont philosophiquement opposées dans votre groupe de pairs actuel.

L'excellence est une attitude et une vision du monde.

Sachez simplement que cette expérience vous a permis de savoir ce qu’il faut éviter, gardez un œil sur la complaisance et le protectionnisme afin de pouvoir le détecter rapidement.

Lors de votre prochain entretien, posez des questions telles que "Quels genres d’innovations proviennent de vos employés", "Quels sont les changements apportés par la créativité individuelle?", "Quels talents individuels puis-je apporter à cette équipe?", "Quels sont les facteurs de succès de votre organisation ? "," Comment votre organisation adopte-t-elle continuellement l'innovation technologique? "... Les réponses à de telles questions sont extrêmement révélatrices. De nombreuses organisations n'ont pas de vision, ou celles qui ont créé cette vision ont disparu, et l'organisation est dirigée par des comptables. Si vous interviewez le directeur de la technologie, demandez-lui s'il considère l'organisation comme une entreprise de technologie.

Ben DeMott
la source
-1

Si vous n'aimez pas l'environnement dans lequel vous travaillez, vous vous rendez un mauvais service. Vous devez être entouré de personnes ayant des intérêts et des objectifs similaires à ceux de votre profession. Je sais que parfois c'est plus facile à dire qu'à faire, mais le sentiment de regarder plusieurs années en arrière et de se sentir perdu vous fait perdre du temps, c'est pire que la peur de prendre un risque.

Au lieu de cela, si vous souhaitez développer un système ou un environnement utilisant une technologie et / ou des méthodologies spécifiques, je vous suggère de rechercher un projet en dehors du travail auquel vous pouvez contribuer. À tout le moins, la variété de travail sur les deux systèmes répondra au besoin de quelque chose de différent pendant que vous trouvez votre position.

Il me semble que vous êtes un poisson hors de l'eau. Allez trouver votre corps d'océan et nagez!

goutte d'eau
la source