Calmer le jeu?

a marqué ce sujet comme résolu.

Salut !

Je souhaiterais avoir votre avis de pros en informatique, sur ce que je peux faire socialement avec mes collègues et responsables pour calmer le jeu si celui-ci venait à s’envenimer.

Je résume le truc pour ne pas prendre trop de votre temps libre. Edit : désolé pour la longueur, je n’ai pas réussi à faire court…

Contexte

  • J’avais fini à 99% mon dev back-end, mon collègue front avait fini genre à 75% je pense.

  • Jusqu’à vendredi midi, la date de livraison était pour demain 21 juin. Elle a été reportée pour des raisons où je ne suis pas impliqué manifestement à la fin de semaine du 21 juin.

  • Ce projet et sa livraison sont en priorité absolue/urgente sur tous les autres projets de la boîte.

Mon erreur : la perte de temps du matin

  • Vendredi 18 juin à 9h00 je propose à mon collègue qu’on s’attaque aux tests achats in-apps Google, l’une des dernières grosses tâches à réaliser. Mon code backend consistant à enregistrer l’achat en database Laravel était fini à 99%, je devais juste l’ajuster en fonction de si je trouvais des pbs quand on testerait à l’aide du code front de mon collège. Premier problème : on a passé toute la matinée à essayer de faire en sorte que ma Laravel API réussisse à accéder aux données envoyées par l’appli avec $request->XYZ (le truc standard Laravel). Toute la matinée, mon collège a dit (1) que c’était du JSON et (2) avait oublié d’indiquer que je pouvais accéder aux données à travers $request->product->XYZ et non pas directement $request->XYZ. (2) a été résolu vers 11h15. (1) a été résolu vers 14h05 quand j’ai décidé de remettre en question l’affirmation "je t’envoie en JSON les données" de mon collègue. J’ai alors découvert que je pouvais utiliser $request->product['XYZ'], impliquant que l’appli n’envoyait pas ses données en JSON (milieu de matinée, j’avais déjà remarqué que le Laravel Inputs Validator n’arrivait pas à valider en mode nested-JSON les données envoyées par l’appli mais j’avais préféré croire mon collègue).

  • Je n’ai pas jugé important d’informer mon responsable de ce retard, au milieu de la matinée ni jamais en fait. Je regrette amèrement cette absence de décision. Je ne peux l’expliquer que par cela : qu’est-ce que ça aurait changé ? Il fallait bien que je puisse accéder aux données de l’appli. De plus j’aurais mis en cause mon collègue front, ce que je ne voulais pas du tout faire. Enfin, j’étais "pris dans le truc", j’ai vu le temps passer, mais j’étais dans l’incapacité, avec une absence de volonté, de communiquer avec mon responsable. Je me suis senti dépassé. Et impuissant.

  • "Dépassé" car 2 ou 3 fois mon collègue a semble-t-il sous-entendu que c’était ma faute. Pour résumer la chose… Mon collègue dev n’avait certes pas explicitement dit que je pouvais accéder aux données via la clé product, mais il m’avait bien montré un corpus de données d’envoi, et dedans on voyait clairement cette clé. Je l’avais zappée. Il s’agit-là d’une erreur d’observation de ma part impardonnable qui a débouché sur cette matinée perdue. Mon collègue a insisté en disant qu’il m’avait bien indiqué cela explicitement ; or j’ai fait une recherche sur Slack par écrit du mot clé "product" et n’ai strictement rien trouvé ! Ce que je lui ai dit, mais visiblement il était toujours en désaccord, dans le déni. Autre chose : à un moment donné il y avait une erreur, cette erreur était clairement une erreur JS mais il n’arrêtait pas de dire que c’était mon code qui bueugait. J’avais beau lui dire que ce n’était pas possible vu qu’en gros j’avais tout commenté, et qu’en plus ça ressemblait à une erreur JS, il a fallu qu’il finisse par se remettre en question pour qu’enfin il corrige son bug. Mais du coup il remettait encore la faute sur moi.

Ma seconde erreur : la perte de temps de l’après-midi

  • Il y a 3 ans d’un projet perso j’avais déjà mis en place des achats in apps google. Depuis je sais donc qu’il faut impérativement vérifier côté serveur (Laravel ici) le purchase_token de la transaction Google que l’appli reçoit de Google en cas d’acaht in-app effectué avec succès. De plus c’est marqué dans des tutos ReactNative ainsi que dans la doc officielle de Google et d’Android.

  • Du coup j’ai insisté pour qu’on vérifie ce purchase_token avant que je n’enregistre en database Laravel le fait que l’utilsiateur ait acheté un truc. Il s’agit du même code que dans la partie "Mon erreur : la perte de temps du matin", fini à 99% de mon côté : je devais juste ajuster en fonction d’éventuels bugs. Problèmes : d’une part les problèmes répertoriés dans la partie "la perte de temps du matin" ont un peu continués en début d’aprèm, et d’autre part j’ai essayé de mettre en place une connexion oAuth avec client_secret, client_id, puis certificate oAuth. J’ai sollicité mon collègue pendant la moitié de l’après-midi pour essayer de faire ça sans succès, et en fait j’ai découvert que dans notre cas d’utilisation il était largement préférable d’utiliser un service_account Google. C’est là que j’ai découvert par hasard que mon collègue dev avait utilisé son propre compte pro pour configurer les clés oAuth et le projet Google Cloud d’une part, et le compte dev de notre client pour lequel on fait le projet pour configurer la Google Play. Or bien sûr il faut que ce soit le même compte Google qui soit utilisé, pour pouvoir lier le service_account de Google Account dans la Google Play.

  • Suite à la découverte de ce pb de config de mon collègue, et suite au fait que j’ai demandé conseil à un autre dev qui est également "responsable" (appelons-le "RESPONSABLE N°2"), mon collègue a direct téléphoné à notre responsable pour se plaindre du fait qu’à cause de moi on avait perdu toute la journée/l’après-midi alors qu’on est en situation d’urgence etc. Notre responsable m’a dit d’abandonner. Il préfère croire mon collègue qui lui a dit qu’il n’y avait pas besoin de faire de vérif côté serveur car selon lui, la vérif de l’achat in-app que fait Google côté client suffit. Alors que selon moi c’est faux, j’ai même donné les liens des docs etc. à notre responsable qui n’a, je pense, pas encore vu mon message… Je l’ai mis au courant de l’erreur de config de mon collègue.

  • Je précise que mon collègue a l’air énervé contre moi. En effet quand je lui ai dit que le deuxième "RESPONSABLE N°2" (qui est réputé pour être le plus fort de toute l’équipe) avait l’air globalement d’indiquer qu’il faudra de toute façon tout rebasculer sur le compte dev qu’on a créé pour notre client, il a dit : "Et alors, du coup il a forcément raison ???"… Et depuis il n’a pas répondu à ma réponse, ni dans la conversation à 3 que j’avais initié avec le RESPONSABLE N°2 pour que ce dernier lui explique les choses techniques lui aussi, à propos des pbs de config Google Cloud et Google Console. (j’avais pris soin de ne pas mettre le vrai responsable pour ne pas mettre en défaut mon collègue, ce dernier lui a quant à lui téléphoné pour se plaindre de moi, c’est super sympa au passage…)

  • D’autres trucs que notre responsable voulait que mon collègue fasse auraient dû être faits de préférence avant ma vérif côté serveur visiblement. Du coup voilà, bien que mon collègue se soit trompé au niveau des configs Google Cloud et Google Console, ce qui a eu pour conséquence le fait de ne pas pouvoir faire la vérif même avec les Service Accounts de Google (alors qu’on était à deux doigts de boucler l’affaire), le fait est qu’en milieu d’après-midi j’aurais pu et j’aurais dû informer notre responsable de la situation. Je ne l’ai pas fait car j’étais "pris dans le truc". Je n’ai aucune autre excuse.

Conclusion

D’une manière générale je note donc plusieurs erreurs et incohérences techniques faites par mon collègue, pareil de mon côté (mais en beaucoup moins nombreuses et beaucoup moins "graves"), et surtout j’ai très mal communiqué avec le responsable.

Je note que mon collègue est visiblement en froid avec moi. Mon responsable est de son côté. J’ai argumenté et sourcé mes recommandations techniques comme quoi il faut absolument faire la vérif côté serveur, sans quoi notre responsabilité pourrait être engagée en cas d’envoi frauduleux d’une transaction factice ou fausse (docs Google et tutos reactnative).

Mais il n’empêche : le timing est short, et ce n’est pas à moi de fixer les priorités. Je le reconnais et j’affirme sans pb d’ego ni de fierté, que je me suis trompé à ce niveau et que je n’ai pas su communiquer. J’aurais dû dire à mon collègue, voyant le temps passer, "ok on fera ça plus tard, continue sur tes trucs, ce n’est pas aussi urgent".

J’ai échoué, je me suis trompé. A cause de moi on a perdu 1 journée ENTIERE !!! et j’ai perdu la confiance de mon collègue front, qui semble-t-il a vu sa fierté vexée suite à la mise en lumière tout au long de la journée de ses erreurs (je précise que je l’ai fait toujours gentiment et respectueusement ; il a tendance même avec les autres, j’ai remarqué, à vite prendre la mouche quand on remet un peu en doute le respect des échéances de sa part, ou des petites erreurs / bévues de sa part).

Question finale

Avez-vous déjà connu ce genre de situations tendues avec vos collègues ? Comment pourrais-je calmer le jeu ?

Il va falloir que je dialogue, que je réexplique tout ça calmement ? Puis-je regagner la confiance de mon collègue front ? Et celle de mon responsable ?

+0 -0

Je suis désolé, j’ai lu que le titre. D’après celui ci, tu as fait une erreur qui a impacté pas mal de gens, on t’as fait brièvement la remarque.

Très bien, tu as retenu la leçon, on ne t’y reprendra plus.

C’est tout.

Tout le monde fait des erreurs, prend exemple sur tes collègues: passe à autre chose.

Je suis désolé, j’ai lu que le titre. D’après celui ci, tu as fait une erreur qui a impacté pas mal de gens, on t’as fait brièvement la remarque.

Très bien, tu as retenu la leçon, on ne t’y reprendra plus.

C’est tout.

Tout le monde fait des erreurs, prend exemple sur tes collègues: passe à autre chose.

Jacen

J’ai lu le message complet, mais je n’ai rien à dire de plus.

Ça arrive, et ça arrivera encore, ça fait partie de la vie professionnelle normale. Laisse décanter quelques jours et vous aurez tous retenu une leçon et vous en tirerez les enseignements.

Ainsi se bâtit l’expérience.

+6 -0

Merci pour vos réponses.

Si je ne reviens pas dessus, il y a fort à parier que la vérif ne se fera jamais côté serveur.

Ça expose à un risque qu’une transaction soit enregistrée en db alors que la transaction Google est fausse (par exemple un cas d’erreur même si la transaction Google a été acceptée lors de l’achat in app accepté côté appli, ce qui est prévu dans les docs Google Billing) voire inexistante (par exemple un purchase_token factice).

Ce qui m’expose à un risque juridique par exemple…

Merci pour vos réponses.

Si je ne reviens pas dessus, il y a fort à parier que la vérif ne se fera jamais côté serveur.

Ça expose à un risque qu’une transaction soit enregistrée en db alors que la transaction Google est fausse (par exemple un cas d’erreur même si la transaction Google a été acceptée lors de l’achat in app accepté côté appli, ce qui est prévu dans les docs Google Billing) voire inexistante (par exemple un purchase_token factice).

Ce qui m’expose à un risque juridique par exemple…

HerbeQuiBenchEtSquat

Si je comprends bien ce n’est pas ton développement qui serait en cause, ce n’est pas du tout ta responsabilité. Si tu estime que le truc n’est pas bien testé, fais en part au chef de projet .De plus, c’est ton employeur qui assume les risques -y compris juridiques- .

+2 -0

Ça expose à un risque qu’une transaction soit enregistrée en db alors que la transaction Google est fausse (par exemple un cas d’erreur même si la transaction Google a été acceptée lors de l’achat in app accepté côté appli, ce qui est prévu dans les docs Google Billing) voire inexistante (par exemple un purchase_token factice).

Ce qui m’expose à un risque juridique par exemple…

S’il y a risque juridique, préviens tes responsables par écrit (mail, c’est suffisant). Soit ils t’écoutent, et tout va bien, soit ils ne t’écoutent pas, et ça devient leur erreur.

Édit : grillé, mais j’enfonce quand même le clou.

+0 -0

Je voudrais juste ajouter quelques détails à ce qui a déjà été dit et avec lequel je suis d’accord :

  1. Un retard de 1 jour, dans l’immense majorité des cas, c’est pas grave. Bien sûr, c’est mieux si ça n’arrive pas, c’est mieux si tu communiques dès que tu vois que ça dérape, mais à moins que le projet ait une raison très forte de sortir à une date précise (ex : campagne de communication), ça ne va rien changer. Et quand tu as ce genre de contrainte, normalement le projet est piloté pour avoir des marges de sécurité. Mais surtout :
  2. Ce qui est important, c’est ce qu’en dit le client. Est-ce qu’il a réagit à ce problème ? Si oui, est-ce qu’il a vraiment montré qu’il y avait des problèmes, ou est-ce qu’il a râlé pour râler ? Ou est-ce qu’il a préféré être en retard de un jour et avoir un truc qui fonctionne plutôt qu’avoir un produit dysfonctionnel mais livré à temps ?
  3. D’un point de vue technique : la première chose à faire quand on débugge, c’est vérifier ce qui se passe vraiment, et pas ce qui est censés se passer ou ce qu’un collègue prétends qu’il se passe. Le seul fait d’adopter ce réflexe fait gagner un temps énorme.

D’autre part, ton environnement de travail n’a pas l’air super sain… mais là-dessus je n’ai pas de conseils plus pertinents que « essaie d’aller voir ailleurs, dans une entreprise où les gens essaieront plus de faire avancer le projet et moins de se renvoyer la balle ».

Oui je mettrais une trace écrite dans notre outil de chronométrage / gestion de tâches plutôt que par mail, car on ne s’envoie jamais de mails à propos de tâches, ça ferait tache o_O

@SpaceFox le client n’est pas au courant ; j’aurais pu vérifier ce qui se passait mais il aurait fallu que j’installe android studio sur ubuntu, or y a plein de pbs de versions de packages, et de plus même si j’avais fait ça, il aurait fallu que je lise le code de mon collègue et tout. Au final oui ça aurait sans doute économisé du temps ceci dit.

D’autre part, ton environnement de travail n’a pas l’air super sain… mais là-dessus je n’ai pas de conseils plus pertinents que « essaie d’aller voir ailleurs, dans une entreprise où les gens essaieront plus de faire avancer le projet et moins de se renvoyer la balle ».

Non du tout l’ambiance est tip top c’est juste qu’il y a eu ce petit couac avec mon collègue on va dire pour résumer

Enfin bref jpense qu’on va me faire des remarques à la visio

+0 -0

Non du tout l’ambiance est tip top c’est juste qu’il y a eu ce petit couac avec mon collègue on va dire pour résumer

HerbeQuiBenchEtSquat

Je ne sais pas si c’est une idée de moi ou si d’autres partagent mon point de vue, mais pour moi ce n’est pas du tout ce qui ressort de tes messages.

Après on est pas sur place pour constater, on ne sait ce qui se passe dans ton entreprise qu’à travers le prisme de tes messages.

J’ai lu en diagonale. Quelques remarques d’ordre générale :

  • On est rarement l’unique responsable d’un retard quand ça implique de communiquer entre collègues. Et même de manière globale, normalement, il y a des procédures (comme les tests) qui font que ton travail est toujours en partie vérifié par une autre personne (ça ne veut pas dire lire ton code en entier, mais s’assurer que tu respecte les spécifications)

  • Un projet qui passe en mode urgence totale c’est pas forcément signe d’une bonne gestion des plannings et priorités. Donc bah encore une fois, tu n’es pas l’unique responsable. Tu es peut-être à l’origine d’un problème technique qui engendre un retard, mais cela est peut-être dû à la pression que l’on t’as mis sur les épaules pour terminer dans l’urgence.

  • Si la moindre critique te met dans cet état de pondre un pavé pour analyser la situation et les relations humaines, il va falloir aussi que tu travailles sur toi. C’est toujours désagréable d’être critiqué, d’être responsable, etc. Mais c’est la vie. T’es pas obligé d’être pote avec tous tes collègues, ca n’empêche pas d’avoir des relations cordiales mais t’es pas obligé qu’il t’adore ou de l’adorer.

Quelques remarques personnelles tirées de mon XP professionnelles :

  • J’ai fait 3 ans dans un service qui était sous-staffé, la charge était autour de 120–130% par personne (on était 3 et il aurait fallu être 4 voire 5), avec un chef qui en avait rien à foutre de nous. Tout était prioritaire, ça en devenait ridicule au point que chaque fois qu’un nouveau truc à faire tombait (prioritaire bien sûr… :-° ), bah on redemandait la liste des priorités :B
  • Je me "prenais la tête" régulièrement avec un architecture qui était aussi tétu que moi. En réunion on était pas forcément d’accord, mais finalement avec le temps j’ai compris et ça se passait mieux : on était toujours en clash en réunion, mais j’évitais de faire monter la sauce, et ensuite à tête reposée, quand j’avais réfléchi à ses idées, on discutait calmement de nos idées tous les deux.
  • J’ai fait une grosse erreur sur une carte électronique qui a coûté plus qu’une journée de retard : j’ai inversé des paires d’un connecteur RJ45 (mais dans un ordre qui fait que l’Auto-MDI-X ne fonctionne pas). Plusieurs milliers d’euros et 2 mois de retard. J’ai assumé cette erreur et faisant remarqué que d’une part on était chargés comme des mules, qu’on nous mettait une pression de fou et que donc les revues de schéma ont été supprimées pour gagner du temps. Aucun responsable ne m’a fait de remarque… puisque s’ils voulaient jouer à ce jeu là, la responsabilité serait remontée jusqu’à eux (manque de recrutement, mauvaise gestion, etc.) :-°

Enfin quelques remarques sur ton post :

  • Arrête les pavés
  • Arrête les pavés
  • Arrête les pavés

Trève de plaisanteries :

  • Apprend à synthétiser : on s’en fout que tu aie envoyé un commit à 11h23, qu’à 11h42 tu te sois levé de ta chaise pour aller aux toilettes, qu’à 11h43 tu étais aux toilettes, que tu en sois ressorti à 11h54 et que tu aie mis 36 secondes pour te laver les mains.

  • Apprend à gérer tes émotions ou plutôt à te rendre compte de la gravité de la situation : dis-toi que dans ma vie professionnelle, j’ai failli frapper un responsable qui me prenait clairement pour un con. Et que un autre responsable m’a insulté dans l’open-space devant des collègues et ne s’est jamais excusé. (je ne l’ai pas frappé, mais ensuite on ne se parlait quasiment plus et ça partait en clash quasiment en permanence, j’ai quitté la boite 6 mois après cet incident)

Edit : je rajouterai que le travail sur soi n’est pas facile et n’est pas quelque chose qui prend 10 min ni 1 semaine ni même 1 mois. Mais avant de poster en détail toute une situation, essaie d’analyser par toi même, de prendre du recul. Il me semble que tu commences tout juste à travailler, tu as encore plusieurs dizaines d’années devant toi, tu vas rencontrer pas mal de situations encore plus complexes…
Pour info, quand mon chef m’a insulté, pendant plusieurs mois je me suis remis en cause, en pensant que ça ne venait que de moi, que j’étais l’unique responsable du fait qu’il ait dépassé les bornes, mais bon avec le temps j’ai compris que non, oui je suis têtu au premier abord mais en rediscutant un peu après je sais ravaler ma fierté et faire des concessions, si après presqu’un an mon manager ne l’avait pas deviné, ce n’est pas mon problème. J’ai envisagé de faire des stages pour tenter de changer mon comportement, mais non j’ai compris que changer pour rentrer dans un moule ce n’est pas l’idéal, je suis comme je suis. Mes compétences viennent aussi avec ma personnalité, sachant que je ne suis pas non plus un génie asocial qui n’accepte aucune critique ou autre, hein.
On en est pas là avec ce que tu racontes, mais clairement essaie de prendre du recul sur ce type de situation. Je sais bien qu’en parlant ça te permet de prendre du recul, mais dans ce cas apprend à synthétiser tes problèmes. :)

+9 -0

Un ou deux conseils d’après ta version des faits :

  • Si le projet est si important, on n’est pas censés être encore dans le dur du développement le dernier jour, et laisser la pression amener les gens à s’écharper, il semble y avoir des défauts de gestion et de management ici. Comment ils font si ce jour précis l’un des développeurs est malade ? Alors ce genre de situations est assez courant, et ça peut arriver de temps en temps, mais si c’est souvent la panique comme ça, change de boîte !
  • Si ta présentation des faits n’est pas biaisée, ton collègue frontend est fautif techniquement et comportementalement, sans doute en partie sous l’effet de la pression. Reparle de ce qui s’est passé avec lui et avec tes responsables, en cérémonial d’équipe ou de façon plus informelle. Il n’y a pas de mal à faire des erreurs mais il y en a à ne pas les reconnaître, ou à mettre une mauvaise ambiance. Ne laisse pas quelqu’un te dénigrer à tort auprès de la hiérarchie ou te marcher sur les pieds trop souvent. Ne t’inquiète pas trop non plus, sur la longueur on voit bien qui délivre et qui fait du drama, les actes comptent plus que les paroles.

Sinon évidemment je plussoie les remarques précédentes sur les méthodes de travail (vérifier par soi-même les entrées et sorties pour ne pas perdre de temps en renvois de balle, etc.), ainsi que la prise de recul et le travail de synthèse. Ce que tu décris est presque un non-événement, ça ne devrait pas t’inquiéter à ce point.

+0 -0

Bon au final ça va, le seul à être revenu brièvement dessus devant tout le monde à la réu c’est mon collègue mais bon.

Je m’en fouts, adviendra ce qu’il adviendra.

Je ne me laisserais pas marcher sur les pieds si besoin, non. Rien qu’aujourd’hui je trouve qu’il a laissé un sous entendu lourd concernant un nouveau truc à dev, mais je m’en fouts. Je réagirai si besoin est à l’avenir.

J’aime pas les conflits, flemme d’en alimenter des inutiles qui plus est.

Je ne parle pas d’aujourd’hui, je parle du problème de base. Et si tu n’es pas sûr de l’interprétation, c’est peut-être encore mieux d’en discuter, justement.

Moté

Mais quand on dit "si tu as x minutes pour prendre ça en compte" ça veut dire quoi pour toi ? Et "si tu as x jours"? Dans les deux cas, ça veut dire qu’on part du principe que tu vas faire le truc en x minutes ou jours ? Ou bien c’est indépendant de la durée de réalisation du truc ?

Je pense que tu devrais poser la question quand on te dit ça. Si tu penses que ce n’est pas assez, il vaut mieux le dire tout de suite et savoir si c’est une deadline contraignante ou juste une estimation ou même une formulation.

+1 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte