Calmer le jeu?

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 ?

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…

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- .

Ç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.

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

@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

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.

Je voulais préciser que par ailleurs on ne voit également que ta version des faits. Peut-être est-elle exacte, ou peut-être que tu la biaises sans le vouloir.

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.

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.

C’est pas une question de l’alimenter mais de le résoudre. Il faut que tu en discutes avec ton supérieur ou avec les RH.

Nan mais si ça se trouve c’est moi qui ai mal interprété son msg en fait

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.

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.