C’est la faute du développeur
Quand un projet tourne au cauchemar, les développeurs ont souvent le réflexe de pointer du doigt un management irresponsable. Mais quand peut-on parler de leurs responsabilités ? Où est la ligne qui sépare les vrais professionnels du reste des développeurs ?
Essence ordinaire
Il y a bien longtemps, dans une galaxie lointaine, très lointaine je travaillais sur le backend d’une application. Une énorme API Symfony 3 avec un sonata admin maquillée comme une voiture volée. Niveau code, c’était beau. C’était propre. On aurait pu bouffer par terre.
On n’avait aucune pression. On était dans les temps pour la livraison.
Je dis on, car on travaillait en binôme. Lambert, côté frontend, est un développeur talentueux. Il développait une application mobile Android et IOS avec Apache Cordova. Il se basait sur mon backend pour la data. Et ça se passait bien aussi dans le code de Lambert.
On est vendredi soir. Une semaine avant la deadline. On a déjà tout fini.
C’est très rare comme situation donc j’insiste. Que ça soit à l’arrière avec mon backend ou à l’avant avec l’application de Lambert, on est en avance.
Nous sommes en plein milieu d’un chaud mois d’aout dans le centre de Lyon. C’est le monde d’avant. Aucun virus à l’horizon. Toute notre agence de communication s’entasse sur la terrasse d’un bar. Une légère brise vient nous rafraichir toute la soirée. Ça et les grandes pintes qu’on se met.
La vie est belle.
Darwin. I Ching.
Lundi matin. Les nuages empêchent le soleil de percer. J’arrive avec un peu de retard à l’agence. Quand Lambert me voit arriver, il se lève et vient immédiatement vers moi.
Lambert : T’as vu le mail de Greg ?
Moi : Olala qu’est ce qui se passe ?
Lambert : C’est la merde. Ils ont ajouté 3000 features.
Moi : …
Lambert : Et c’est la même date de livraison !
Moi : Mais non t’inquiètes.
Lambert : Regarde le mail Mehdi !!!!
Moi : Il fait toujours ça Greg ! Il raccourcit les délais pour faire courir les gens.
Il transpirait le stress. Je l’avais jamais vu comme ça. En quelques minutes, tout avait basculé.
La vérité c’est que j’étais autant stressé que lui. Je savais que des changements aussi brutaux étaient signe de pression énorme en amont. Pression dont on allait bientôt hériter.
Mais surtout je savais qu’on allait devoir affronter Greg.
Greg est le directeur de l’agence. Avec Lambert, normalement, on travaille avec un chef de projet sur nos projets. Pour tous les développeurs, c’est pareil. Si tout d’un coup Greg se mêle aux discussions, il n’y a qu’une seule raison possible.
Les enjeux financiers sont énormes.
Le client est un énorme laboratoire pharmaceutique. On est dans le top 10. Il faut bien comprendre que le secteur pharmaceutique, niveau thune, c’est absolument indécent.
Certains responsables dans ces laboratoires n’hésitent à payer cher pour dépenser tout leur budget de l’année. S’ils ne le font pas, leur budget est réduit l’année d’après. On est à ce niveau de thune là. Et malgré le fait que cette application soit une application interne au laboratoire : on parle de vraiment beaucoup d’argent.
Il faut faire bonne impression. Si on fait bonne impression, les contrats seront encore plus grands. Sinon, ils iront voir ailleurs.
Ça ne rentre pas
Avec Lambert, on a passé la matinée à estimer les changements. Ils étaient abominables ces changements. On devait ajouter beaucoup de features. Y’avait beaucoup d’écrans en plus. Mais surtout, on changeait presque tous les écrans existants.
Tu connais mon opinion sur les estimations. Déjà à l’époque, j’avais cette position. Déjà à l’époque, je ne donnais pas de chiffre absolu.
On est le 10 aout. Ce WE c’est le 15 aout. Ça doit être livré en prod le lundi 17 aout.
On estime que ça prend entre 2 à 3 semaines ce qu’on nous demande. Ça ne rentre pas. Même en bossant le WE, ça ne rentre pas. Ajouter un autre dev pour nous aider ? En si peu de temps, ça ne marchera pas à cause du ramp up. De toute façon, tout le monde est sous l’eau.
On a beau retourner le problème dans tous les sens, ça ne rentre pas.
Et puis on a eu une idée.
On peut raisonnablement faire une partie des nouveaux écrans -les plus importants- sans toucher au flow existant en une semaine. On va proposer ça. Ça va bien se passer.
Jazz
Le meeting avec Greg était juste après la pause du déjeuner. En temps normal, ce n’est pas simple d’avoir une discussion normale avec lui. Il est connu pour toujours arriver à te forcer la main. En te tordant le poignet s’il le faut.
Avec la pression financière de ce projet, son visage était devenu une porte de prison.
Le meeting le plus important de toute cette histoire était sur le point de commencer. Étant le plus senior des deux, il s’adressait énormément à moi. Ça m’agaçait. Du coup, je m’adressais énormément à Lambert. Ça l’agaçait.
La discussion a duré plus d’une heure.
Très honnêtement, je ne me souviens pas de toute la discussion. Et certainement pas mot pour mot. Par contre, je me souviens bien de la partie qui nous intéresse.
Moi : Tu ne peux pas rajouter du travail sans rajouter du temps de travail. C‘est juste logique.
Greg : Vous êtes en avance. C’est toi qui me l’as dit.
Lambert : Les changements sont trop grands. Une semaine d’avance c’est pas assez.
Greg : *s’adressant à moi* Il faut juste deux semaines c’est ça ?
Moi : *s’adressant à Lambert* Deux semaines minimum ! Il nous faudrait entre deux et trois semaines. Voir plus !
Lambert : *s’adressant à Greg* Voir plus !
Greg : Il vous faut 10 jours. On est lundi. Si on compte aujourd’hui, qu’on inclue ce WE, ça fait déjà 7 jours. Avec vos talents combinés, vous avez les capacités de le faire. On peut faire des choses rapidement, en dur comme vous dites, je suis sûr que vous êtes capable. Vous avez déjà fait des miracles. Pourquoi pas cette fois ?
Je me rappelle rien répondre et bloquer complètement à ce moment-là.
Il écoute pas ce qu’on lui dit ou il le fait exprès ?
Greg : Vous le savez que ce client est important. On va le garder. Ils font leur démo lundi, on sera prêt lundi. On s’est engagé sur cette date de livraison. On va la tenir. C’est indispensable pour eux donc c’est indispensable pour nous.
OK. Il le fait exprès, car le client est persuadé que tout va bien.
Greg : Je vous paye évidemment vos deux jours majorés ce WE. Vous pouvez compter sur une prime en plus. Je fais des efforts et je trouve des solutions. On a besoin de vous.
Moi : *s’adressant à Lambert* Ce meeting ne sert à rien. On n’a pas le choix.
Lambert : …
Greg : *en se levant* Je crois en vous. Vous êtes les meilleurs. Vous allez y arriver.
Moi : Ça ne rentre pas. Mais écoute, on va essayer. Qu’est-ce que tu veux que je te dise ?
Collatéral
Les premiers dégâts ont été les tsunamis de stress qui venaient fréquemment fouetter notre santé mentale. Dans une situation comme la nôtre, chaque bug, chaque imprévu est une injection pure d’anxiété en intraveineuse. Un bug, ressenti 60.
Les dégâts sur notre temps libre étaient lourds. Juste avant le WE, on était tout sauf dans les temps. Quand on a accepté les heures supplémentaires, Lambert et moi avions des plans chacun de notre côté pour ce 15 aout. Je me souviens recevoir un appel de mes potes bourrés me demandant ce que je foutais.
J’était trop occupé pour m’expliquer au téléphone.
C’est également là qu’on a commencé les dégâts sur la qualité. Exit les tests, les builds fréquents, le clean code, les reviews et la QA. Tout notre process normal fracassé au sol. Ça donne toujours l’impression que tu vas plus vite sur le coup.
La communication aussi a pris des dégâts importants. Déjà avec la direction. Ces irresponsables étaient la source de nos malheurs. On le faisait ressentir dans nos réponses.
Les dégâts étaient aussi importants entre nous. Entre Lambert et moi. La panique et la précipitation ne sont pas compatibles avec la courtoisie. En particulier au milieu d’un brulant dimanche après midi sans la clim toujours à bosser sur cette foutue application.
Surtout qu’on savait ce qui nous attendait. On le savait que ça ne rentrait pas. On avait beau accélérer et encore accélérer, on savait comment allait finir cette folle course contre la montre.
Avec bruit et fracas.
Notre application parfaitement fonctionnelle à été remplacée par une application à peine utilisable le lundi 17 aout au matin.
Pendant que Lambert et moi on dormait, ils ont plus ou moins réussi à montrer des choses lors de cette fameuse démo. Mais l’application avait des comportements très étranges. Trop étrange. Ils ont dû la relancer. À plusieurs reprises.
On était sur le contraire absolu de « la forte impression » attendue.
Trauma
Le laboratoire pharmaceutique a fait le mort après cette histoire. Ils ne nous ont pas sollicité pour d’autres contrats. Ils ne nous ont même pas demandé de mise à jour sur cette application.
Et le plus gros des dégâts était encore à venir.
Presque un mois plus tard, Lambert vient sans raison s’asseoir à côté de moi. C’était son dernier jour. Il venait de se faire licencier pour une raison bénigne. Une petite erreur de rien du tout lui a couté son poste.
Absolument toute l’agence, sous le choc, parlait de licenciement abusif.
À juste titre.
Je lui ai tout de suite dit que ça devait être lié à cette histoire d’application. Il s’en foutait complètement. Il était juste venu me dire au revoir. Il était content. Il allait enfin quitter cette agence -qu’il avait fini par détester- avec son indemnité et le chômage le temps de trouver autre chose.
Il trouva dès la semaine suivante pour la petite histoire.
Quelques mois plus tard, je suivais le conseil de Lambert. Je posais ma démission sans aucune explication. J’étais déjà loin dans ma tête. Je me préparais à quitter la France pour m’expatrier au Canada.
Pendant cette transition j’étais persuadé que les seuls et uniques fautifs de toute cette histoire étaient la direction. C’est tout sauf ma faute! Encore moins celle de Lambert. C’est entièrement la faute de cette agence d’amateurs et d’irresponsables.
J’avais tort.
Do or do not
Toutes les conséquences de cette histoire sont entièrement de ma faute. L’erreur la plus grave a été mon attitude durant la réunion avec Greg. Je savais qu’il était impossible d’arriver au résultat dans le temps imparti. Et pourtant j’ai dit quoi ?
J’ai dit qu’on allait « essayer ».
J’ai dit ça pour éviter la confrontation. J’ai dit ça, car les enjeux étaient trop importants. J’ai dit ça pour être bien vu. J’ai dit ça aussi pour avoir une chance d’être le héros. Celui qui arrive à faire le travail à temps.
C’était fondamentalement malhonnête et non-professionnel de ma part.
On attend d’un professionnel qu’ils disent non, peu importe la personne et les enjeux en face.
Un développeur professionnel impose la réalité face au pouvoir. Un développeur professionnel défend ses dates de livrables avec la même agressivité qu’une direction veut les changer. Un développeur professionnel dit non quand les enjeux sont énormes. C’est justement là où c’est le plus important de le faire.
Un développeur professionnel fait tout pour livrer un travail de qualité dans le temps imparti. Et parfois ça veut dire non à des délais stupides. On peut réduire le scope, reporter une date, livrer par itération et de manière générale imposer des contraintes qui vont permettre de s’engager sur une date.
On s’engage à le faire, car on sait qu’on le fera. On n’essaye pas.
J’aurais dû tenir tête à Greg. Lui faire comprendre que c’était impossible. Fermer toute possibilité avec ces conditions. Anéantir clairement et de façon répétée tous ces espoirs. Le forcer à accepter notre solution alternative. Le forcer à appeler le laboratoire. Le forcer à décaler la démo.
Greg aurait dû quitter la réunion furieux contre moi. Persuadé que ça ne rentrait pas. À la recherche d’une autre solution.
Qui sait, le client aurait peut être accepté de décaler. Le client aurait peut-être trouvé une autre alternative. L’agence aurait peut-être trouvé une autre alternative. Greg aurait peut-être fini par accepter notre alternative.
Peut-être que ce client serait toujours client aujourd’hui.
Mais non. Il est sorti confiant. J’avais décidé d’essayer. J’ai condamné mon entreprise à l’échec en évitant ce conflit.
Et par la même occasion, j’ai forcé Lambert avec moi dans cette mission suicide.
Amateur
Toutes mes actions qui ont suivi ensuite hurlent l’amateurisme.
J’ai accepté de faire des heures supplémentaires alors qu’il n’y avait aucun plan B. C’est la recette du chaos. Il faut exiger un plan B si ton entreprise exige des heures supplémentaires.
J’ai volontairement supprimé les process de qualité pour aller plus vite. En plus d’être irresponsable et stupide, ça ne permet pas d’aller plus vite. Même sur le court terme.
J’ai géré la pression de façon désastreuse. Ça se ressentait dans mes communications et dans mon travail. Par souci de longueur je ne dis pas tout, mais plusieurs échanges pas du tout professionnels ont eu lieu entre nous et l’agence.
J’ai livré une application en production en étant sûr qu’elle était défectueuse. En tant que développeur, je crois que c’est la définition même du non-professionnalisme.
J’étais un irresponsable amateur qui accusait les autres d’être responsables de tout. Je ne pouvais accepter ma responsabilité à ce moment-là. C’était inconcevable pour moi, j’était la victime, pas le responsable.
Ça fait mal quand on se rend finalement compte de la réalité.
Professionnel
Je ne me suis pas rendu compte de tout ça via une épiphanie soudaine en me réveillant un matin. Je me suis rendu compte de tout ça en lisant un classique.
Ma recommandation du jour : Clean Coder.
En une phrase, ce livre est le code de conduite du développeur professionnel.
Ce livre m’a ouvert les yeux sur mon attitude et tous les problèmes qui en découlaient. Savoir quand et comment dire non est en effet quelque chose de capital qui me manquait. Mais c’est loin d’être tout ce que j’ai appris via ce livre.
Ce livre m’a appris à prendre mes responsabilités comme un professionnel. Il m’a appris à gérer mon temps, il m’a donné un véritable cadre pour estimer mes taches, il m’a appris à gérer la pression comme un professionnel, mais aussi à mieux collaborer.
Dans un monde où les développeurs se contentent de coder sans poser de question, les professionnels font bien plus que ça.
Ils sont alors vite identifiés comme « les bons éléments » dans une équipe. Et ça fait toute la différence.
Il s’adresse à tous les développeurs, peu importe leur niveau. Je dirais même que le plus tôt, le mieux. Encore un bouquin que j’aurais voulu lire en début de carrière.
Épilogue
Un vrai professionnel est un atout considérable pour une entreprise. Une personne fiable sur laquelle on peut compter. On peut compter sur son travail, mais aussi sur la façon dont elle le fait. Elle le fait de façon honnête et toujours dans l’intérêt de son entreprise. Même quand ça signifie rentrer en conflit. Surtout quand ça signifie de rentrer en conflit.
« L’échec un puissant maître est » disait aussi l’auteur du fameux « Do or do not, there is no try », les grandes leçons font parfois mal (et c’est pour ça qu’on les retient 😉
Autant je suis d’accord avec ta définition du « vrai professionnel », autant je rejette toute la partie d’auto-flagellation. Il y a une relation de subordination entre un boss et un développeur, et, au final, c’est le boss qui décide. S’il décide d’ignorer TOUS les warnings pour foncer dans un mur, je considère que c’est sa faute et pas celle du développeur (ou de n’importe quel subordonné).
Ok, tu aurais voulu être LE miracle, le héros, le sauveur (syndrôme du St Bernard ;-), c’est humain aussi, mais il t’a forcé la main : lors de cette réunion, c’est toi qui a plié car ton boss a insisté. Il était sûrement décidé à ne pas mettre fin à la réunion avant que tu plies de toutes façons. Si tu avais été ce « vrai professionnel » qui dit non, tu y serais peut-être encore. Les chefs de projet / responsables / directeurs de ceci ou cela qui refusent d’entendre « non » sont parmi les pires. Ils sont capables de se tartiner une épaisse couche de caca dans les yeux et les oreilles pour ne plus voir la réalité. Or on peut plaisanter avec tout, sauf avec la réalité.
Et MÊME SI ton collègue et toi aviez pu livrer une appli qui marche +/- correctement lors de la démo, ça aurait donné quoi pour la suite ?
– les gens pour qui on a fait un miracle en redemandent
– tout le « quick-n-dirty » fait pour aller plus vite (en mode « on corrigera ça plus tard ») doit être corrigé plus tard. Ou maintenu. Ou vivre avec.
– ça ne peut donc QUE mal finir
Voici une citation qui me plait bien au sujet de la gestion du temps :
« Il faut laisser le temps au temps à court terme pour gagner du temps sur le long terme. Le temps ne respecte pas ce que l’on fait sans lui. »
Il y aura toujours des « coups de bourre » dans les projets, mais le signe d’un projet bien géré, c’est que le coup de bourre est suivi d’un temps calme pour « réparer » tout le caca fait en mode urgence pendant le coup de bourre. Si on avance à 150% de la vitesse normale la moitié du temps et qu’on retombe à 100% ensuite, on ouvre la porte au burn-out / turn-over / production de mauvaise qualité. Un manager qui demande l’impossible à ses équipes, et qui le demande de manière répétée est un mauvais manager.
« S’il décide d’ignorer TOUS les warnings pour foncer dans un mur »
Il y avait en effet des warning, mais il est sorti serein de cette réunion. Ça, c’est ma faute.
« lors de cette réunion, c’est toi qui as plié, car ton boss a insisté »
Exact, c’est exactement mon propos. Je ne devrais pas plier. Je devrais juste fermer la porte et dire non.
C’est tout à fait ce que je pense. La faute, dans le cas de Mehdi, incombe selon moi au manager qui a mal fait son travail. Et malheureusement il existe bien plus de managers comme celui là que le contraire…
Bonjour,
Même si c’est bien de prendre ses responsabilités, je crois que le premier problème c’est que ton boss de l’époque a court circuité le chef de projet donc c’est le métier de gérer ce genre de pression.
On pourrait rajouter un roman sur le sujet.
En ce qui concerne le « on vas essayer » la première image qui m’est venue à l’esprit c’est de sauter le grand canyon avec une perche. On peut essayer, ça se tente 🙂
Après prendre ces responsabilités c’est bien, mais là j’ai un peu l’impression que c’est comme si, en voiture on t’avais grillé la priorité toute ta famille à péri dans l’accident et tu en arrive à la conclusion que tu n’aurais pas du prendre ta voiture ce jour là.
Sinon, bon article, bien écris et raconté, merci 🙂
Salut Manuel.
Je suis pas d’accord avec ton image.
C’est comme si j’avais pris la voiture, que la police m’avait dit de foncer aux feux rouges, et au lieu de tenir tête à la police j’avais foncé aux feux rouges.
Du coup tu n’aurais pas du prendre la voiture 😂😂😂
Je suis pas ultra d’accord. Si Greg a pas eu de scrupules à téj Lambert en représailles, il en aurait pas eu plus à vous téj tous les deux en représailles de votre non ferme (et justifié) en réunion. Ca renvoie à un des tes précédents articles où tu nous parlais d’entreprises et de managers toxiques, là on est en plein dedans à mon sens.
Greg était dans la merde avant qu’on fasse quelque chose. Nous virer aurait empiré la situation sur le coup. Impossible de faire ça pour lui.
Je pense que si je l’avais bousculé, furieux, il aurait appelé le labo pour décaler la démo. Soit ça, soit il perdait tout. Ensuite on fait un bon travail, et tout le monde est heureux.
Je sais que c’est très désagréable d’admettre que ça peut être de notre faute. Ça prend du recul et beaucoup d’abnégation. Mais c’est bien ma faute ici. J’avais le pouvoir de dire non, j’ai dit on essaye.
Je pense que ce n’est pas en fermant les yeux et en pointant du doigt en permanence les autres qu’on évolue. Parfois un peu d’humilité et un peu de remise en question c’est important.
Bonjour,
Merci pour ton article. J’ai personnellement beaucoup de mal à dire non de manière générale ou en tant que développeuse.
Tu sites le livre « The Clean Coder » de R.C. Martin, quelle est la différence avec son autre livre « Clean Code » ?
Bonne journée
Salut Mélanie,
Clean Code parle de code pure.
Clean Coder parle de comment se comporter en tant que développeur.
C’est bien beau de reconnaître ce qu’on a mal fait. Mais en aucun cas ça ne dédouane le patron. Le « professionnel » quel qu’il soit, n’est pas à égalité avec son supérieur hiérarchique, il subit une pression supplémentaire et peut voir sa capacité à subvenir aux besoins de son foyer menacée.
Donc oui, on peut se dire qu’on aurait dû dire non. Mais c’est un peu comme si on dit à une fille qui a subi un viol : « Tu aurais dû dire non ». Face à une personne qui à l’ascendant et qui te fais ressentir une peur, ce n’est pas aussi simple et dire que c’est toi qui est le responsable, je ne pense pas que ce soit sain.
Salut Kosro,
Je ne te rejoins pas sur ton image, les deux situations sont totalement différentes (la tienne infiniment plus grave, on ne peut vraiment pas comparer ça).
Je ne dédouane pas Greg, je dis juste que j’avais le pouvoir de le faire bouger et que je n’ai rien fait. Supérieur hiérarchique ou pas j’aurais dû insister. Je le répète, il aurait dû quitter la salle furieux. Il a quitté la salle serein. Ce fait est ma faute. Ce fait-là va entrainer tout le reste.
Mais je comprends que c’est compliqué d’admettre nos torts. Personne ne veut faire ça. J’ai longtemps répété que c’était la faute des autres.
Pas d’accord, jouer les « héros » aurait été de dire « on y arrivera » en validant la demande.
Là, l’étude de la part des développeurs a été fait, ils ont donner une réponse cohérente, si on leur force la main et que les développeurs ont dit les choses clairement, ça n’est pas de leur responsabilité, le manager a les clés, il connait ses risques, c’est à lui d’évaluer si le client préfèrera une version vide avec des paillettes , une version entre deux ou une version repoussée.
Quand on a un manager, ça n’est pas au développeur de connaître le client !
( ou alors, ils n’ont pas juste le statut de développeur )
Tu avais peut-être d’autres infos que ce qui est transmit, mais blâmer les autres développeurs qui réagiraient ainsi est indécent …
Salut Sizvix,
Tu dit « il connait ses risques ».
Justement non, dans ce que je raconte Greg quitte la réunion serein, persuadé que ca rentre car on est super dev. J’ai laisser ça arriver. J’aurais dut dire « NON » ca ne marchera pas.
Tu as expliquer à Greg que ce n’étais pas possible, il n a pas écouté. Greg est un abruti, il a perdu un client, bien fais pour sa gueule. Peut etre effectivement que tu aurai pu tout refuser en bloc lors de la réunion et refuser les heures sup, mais si on découpe les responsabilités de chacun, tu est loin d’avoir la majorité des points 🙂
Salut Thomas,
Enfin quelqu’un qui peut admettre une part de responsabilités, bravo !
Dans la plupart des cas je suis d’accord avec le « tu est loin d’avoir la majorité des points ».
Mais dans ce cas-là aujourd’hui, j’ai l’impression que j’ai en pas mal quand même.
En fait, le truc clef c’est que Greg a quitté la réunion serein. Il aurait dû quitter la réunion furieux, à la recherche de solution, au téléphone avec le labo pour décaler la démo.
J’ai du mal à comprendre comment avec un des rares métiers du monde ou y a plus d’offre que de candidat on peut encore se plier en 8 à faire des heures sup et sacrifier ses week end pour un sale con et ou l’outcome personnel sera surement d’une tape dans le dos, alors que, et ton pote Lambert l’a prouvé, tu peux retrouver du boulot en une semaine (et souvent mieux que ce que tu faisais avant).
Je crois outre le professionnalisme, y a beaucoup de développeur (hors junior) qui se rendent juste pas compte du rapport de force qu’ils peuvent exercer sur ce genre de meeting. Le gars tu lui dis non et si t’es pas content vire moi, ben soit il te vire, c’est cool tu gagnes des sous, tu changes d’air et tu conserves ta life, soit il sort un mouchoir et commence à chouiner.
Stop se soumettre face à quelqu’un qui a tout à perdre à vous tenir tête.
Salut Benjamin,
MERCI ! Et totalement d’accord avec toi sur ce que tu dis. C’est dur de faire ça, surtout quand tu crois que ton taf c’est seulement faire du code. C’est pas simple du tout de tenir tête à des gens comme ça.
Je suis indep et je passe ma vie a expliquer ça aux collègues.
Bonjour Mehdi, merci pour ton retour d’expérience.
Je suis du même avis que les autres commentateurs. Tu n’as pas l’entière responsabilité de cet échec. Tu aurais pu dire non, aller à la confrontation mais le dirigeant a choisi de te forcer la main alors tant pis pour lui.
Je connais bien l’écosystème agence / ESN à Lyon, ce n’est pas la première fois, ni la dernière qu’une situation similaire se déroule… Malheureusement beaucoup trop de managers et de dirigeant n’ont pas conscience des implications d’un tel comportement à court comme à long terme, en interne, avec leurs clients mais aussi dans la réputation de l’entreprise.
Il m’a fallu 30 secondes pour retrouver le nom de l’entreprise en question et ajouter cette histoire sur le tas des autres casseroles qui les suivent… C’est dommage pour eux.
Sais-tu dire pourquoi, avec le recul, tu n’as pas été en capacité d’aller à la confrontation et de dire non à l’époque ? De quoi avais-tu peur ?
Qu’est-ce qui fait qu’aujourd’hui tu aurais/as un comportement différent ?
C’est difficile pour beaucoup de jeunes développeurs de poser un cadre et de le tenir. Normalement ce n’est pas leur rôle mais bien celui d’une direction technique et d’un management qui est là pour les faire grandir. Dommage que tu n’ais pas put être protégé à ce moment-là.
Merci encore pour tes articles.
Pierre
Bonjour à tous, j’ai déjà vécu récemment ce cas de figure… du coup je vois parfaitement l’idée de ce texte.
Je pense aussi que la pression émanant d’une personne ayant autorité dans l’organisation de la boite n’est pas sain du tout (déjà bosser sous pression c’est très bof, et puis boss + court circuit du schéma décisionnel ordinaire), je suis d’accord avec la plupart des commentaires qui en parlent.
Mais ce qui est intéressant à mon sens c’est le « non rejet de la responsabilité » sur autrui: les choses ne sont ni blanches ni noires et dans une situation ou on est parti prenante on à toujours une part de responsabilité aussi fine soit elle.
Si ils avaient absolument dit non cash a Greg, alors en effet les choses auraient pu se passer différemment (licenciement en mode gros sale, ou pression violente d’en haut) mais ils n’auraient pas sacrifié leur « dignité » de dev (respect de leur métier et valeurs: la qualité de leur appli et respect des process, de leur environnement de taff: l’appli semble avoir été bien dégueulassée) pour tenter un coup
qu’ils savaient tous les deux absolument pas gérable.
Avec des « si » on refait un monde c’est vrai, mais ce qui est sur, c’est qu’ils savaient à l’avance ce qu’ils allaient perdre et devoir sacrifier.
Je pense que c’est la tout l’intérêt de cette histoire: la différence entre professionnel (qui s’assume et assume ses choix) du reste des développeurs.
Amen!
J’ai déjà vécu cette situation, mais elle est symptomatique de beaucoup de choses autre que « c’est la faute du développeur ». Greg qui se mêle d’un projet qu’il n’a pas géré et dont il n’a pas osé dire au client que ce n’était pas possible… Ce n’est pas Greg qui dirige l’agence, mais le client. Et Greg lui mange dans la main. Tu as dit plus haut à Greg que ça n’allait pas faire, que – logiquement- si on ajoute du travail, il faut ajouter du temps. Il a refusé de t’écouter. Ce n’est pas la faute du développeur. Greg a vu l’appât du gain, au lieu de la réalité du terrain. Il ne peut que s’en prendre à lui-même.
Nous ne sommes pas responsables d’un mauvais management basé sur le chiffre, la terreur et la pression.
Salut Frei,
On est pas responsable d’un mauvais management tout à faire d’accord avec toi.
Par contre on est responsable de mettre la tête dans le caca à ce management. Et comme répété plusieurs fois dans les commentaires : Greg aurait dû quitter la réunion furieux contre moi, à la recherche d’une solution. Il est parti serein, il est passé à autre chose la minute d’après. Ça, c’est entièrement ma faute. Et ce qui en découlera aussi.
Merci pour ce retour d’expérience instructif.
Avec plaisir !
Je pense que plus on est à l’aise dans son job et conscient de ses capacités, plus on sera apte à refuser ce genre de job fait à la va-vite.
Après, on ne peut pas blâmer quelqu’un de peu expérimenté, qui aurait peur de perdre son job, d’accepter ce genre de choses….
Donc oui, un vrai pro expérimenté n’aura pas peur de la confrontation, saura que son job n’est pas en jeu et qu’il en trouvera facilement dans le pire des cas, etc…
En effet, j’écris cet article de mon point de vue « expérimenté ». Je peux tout a faire admettre que des profiles plus jeunes trouve ça aberrant de dire non et tenir tête. Bon point.
À ce que j’ai lu, c’est Greg, et seulement Greg, qui a décidé de se sortir d’un mauvais pas en mettant ses salariés sous pression. Les stresser et espérer qu’ils garderont les idées claires et leur sang froid, voilà quoi ! C’est comme jouer à la roulette, des fois ça marche, des fois non.
Et puis bon, il faut quand-même avoir de sacrés aptitudes dialectiques pour tenir tête à un type dont c’est le métier de tchatcher, avec un niveau hiérarchique supérieur de surcroît.
À mon sens, être un bon dev, c’est aussi éviter de travailler pour des boîtes de comm, SSII ou n’importe-quelle autre qui ne cherche que le bénéfice à court terme. Mais ça c’est une autre histoire.
C’était la dernière boite de comm pour laquelle j’ai bossé. Trop insupportable et ça part dans tous les sens ce genre de boite. Après c’est super formateur et ça te fait de bonnes histoires à raconter. Mais à vivre, c’est abominable.
Merci pour cet article Mehdi !
Ton histoire est intéressante, et les commentaires qui ont suivi le sont tout autant.
En fait ce n’est la faute de personne, et en même temps de tout le monde, client final y compris.
Tous les intervenants se sont mis en position d’échec dans la réalisation de ce projet et c’était sûr que ca allait finir en fiasco : ajouter des dizaines de fonctionnalités 1 semaine avant mise en prod ?! Ne pas faire intervenir au moins un dév pendant la réunion avec le client ?! Ne pas faire de retour au client sur la charge de travail induite ?! Accepter de compresser 3 semaines de travail en une seule ?! Désolé de le dire, mais tous le monde était au pays des bisounours dans cette histoire et aucun intervenant n’a été professionnel. Développeur ne veut pas dire magicien 😉
Quelque soit le secteur d’activité, si on est un bon professionnel, on doit être capable de dire non et d’expliquer pourquoi. D’autant qu’avec l’expérience j’ai appris qu’un client est capable de se voir dire non, si on l’accompagne et qu’on lui donne des perspectives. Dans le cas présent, il aurait sans doute accepter d’avoir un calendrier de mise en oeuvre des fonctionnalités demandées par exemple. Tout n’est pas binaire dans la vie…
Quand aux développeurs qui se prennent pour des rockstars / divas parce que le métier est en tension, je vous dirais bien de vous calmer. J’ai fait et je continue régulièrement à faire des heures supplémentaires parce que j’aime ce que je fais et avec qui je le fais. Ce n’est pas rose tous les jours, mais si on se comporte comme des barbouzes, faut pas s’étonner que la hiérarchie se comporte comme des sagouins avec les développeurs et ne prennent pas en compte ce qu’ils disent…
« Désolé de le dire, mais tous le monde était au pays des bisounours dans cette histoire et aucun intervenant n’a été professionnel. »
100% d’accord avec toi.
C’est pour ça que je dis que je suis responsable des conséquences après avoir dit « on essaye ». J’aurais pu rattraper les erreurs des autres en mettant un grand coup d’arrêt. Mais j’ai continué le désastre amener par le client et Greg.
Hello,
Merci pour cette article qui me donne pas mal à réfléchir et, au final, je suis partiellement d’accord avec tout ça. Je pense en effet qu’il est vital (tant pour soi que pour l’entreprise) d’apprendre à dire non. C’est un apprentissage assez long (en tout cas il l’a été pour moi) et je pense qu’il faut parfois s’être mangé des projets irréalisables où l’on a dit oui à tord pour l’apprendre.
Néanmoins, je serais moins catégorique : ça ‘peut’ être la faute du dev — et plus généralement de la personne qui produit — mais pas forcément.
J’ai été dans une boite où une très grande majorité des projets étaient gérés comme ça. J’ai vécu cette situation depuis le poste de dev (enfin, on ne faisait plus que du dev), comme depuis celui du manager évincé quand le patron court-circuit son poste pour « aller plus vite » pour donner des instructions irréalisables à son équipe (déjà signé, le contrat, bien sur). J’ai vécu ces réunions tendues, ces coups de fil douloureux, ces discussions au détour d’une salle où tu apprends qu’on attend plus que prévu pour la veille. Où tu dis que c’est impossible et où céder est la seule sortie possible. Et où ça foire, bien sûr.
Chaque employé a tenté des façons de faire différentes. Faire le dos rond, courber l’échine : ça foire et c’est la faute de celui qui produit (dev). Faire un mail à tout le monde pour bien expliquer ce qu’il s’était passé : le patron s’arrangeait avec la réalité. Claquer la porte avec fracas : c’était le salarié qui ne correspondait pas à l’équipe. Dire non et camper sur ses positions : ça se retournait contre l’équipe. Gueuler en séminaire : discussion sans fin et victimisation du patron.
Quand le patron est un mur qui ne se remet pas en question, dire non n’a aucun effet. Même quand il part furax.
Je sais que ce n’est pas tout à fait le cas abordé ici (un autre article parle du management toxique, merci beaucoup d’ailleurs, cet article m’a permis de comprendre pas mal de choses), mais le pitch de base du projet est très très très semblable à ce qu’on vivait tous les jours. Ça fait un peu trop écho à ce que j’ai vécu, même. J’ai eu beaucoup de mal à comprendre que ce n’était pas ma faute. Pas QUE de ma faute, en tout cas. Ou pas toujours de ma faute.
D’où mon besoin de nuance : ça ‘peut être’ la faute du dev 🙂
C’est sur que chaque situation est différente.
« Quand le patron est un mur qui ne se remet pas en question, dire non n’a aucun effet. Même quand il part furax. »
Mais quand il part furax j’ai fait mon travail. J’ai été pro dans mes positions. Peu importe ce qui se passe après. Là dans mon histoire, j’ai fait le héros.
Voici ce qui se dit dans l’armée (je ne suis pas militaire). « La fonction prime le grade » « Dans les situations où deux personnes sont en conflit professionnel, cet adage permet de faire un tri rapide dans les priorités de qui-peut-se-permettre-quoi-par-rapport-à-qui. »
En gros ça veux dire que celui qui sait comment ne pas se fracasser contre un mur n’est pas toujours le plus gradé.
Un article qui explique cet etat de fait : https://yannickprimel.wordpress.com/2011/01/18/la-fonction-prime-le-grade/+
Je pense quand même que c’est très compliqué de dire « NON ».
J’aime beaucoup tes articles. Continue !
« En gros ça veux dire que celui qui sait comment ne pas se fracasser contre un mur n’est pas toujours le plus gradé. »
Amen ! C’est ça !
Un grand merci à toi Mehdi : ce que je viens de lire est le partage d’expérience pro par un développeur sincèrement professionnel et qui aime son métier ;
J’ai également lu les commentaires : et oui, via son statut de supérieur hierarchique, Greg a aussi sa part de responsabilité en ayant imposé à sa team ce que le client final a voulu imposer.
Cela étant, je suis à 100% la leçon retenue que tu partages avec nous ici ; d’autant que ça fait écho de ouf à une expérience perso où j’ai pas su dire NON à des gens ayant un pouvoir … illusoire, au final :
1/ J’avais bêtement cru que la voix et l’intuition d’une mère solo ne valaient rien par rapport à la voix d’une assistante sociale débutante zélée et scotchée sur de la théorie obsolète.
2/ En plus, j’ai voulu éviter le conflit, en refusant d’écouter ce que je savais ainsi les doutes aussi flagrants que les voyants rouges du tableau de bord d’une voiture.
En résumé, j’ai foutu mon propre fils dans la sauce et ma responsabilité était engagée, point barre.
C’est pourquoi cette expérience me parle.
D’ailleurs, en parlant de mon fiston et en m’adressant à celles et ceux qui pensent que c’est seulement de la faute de Greg : un jour, mon mini-moi m’a dit un truc « Je sais que tu te préoccupes de moi car quand je fais une erreur, tu me le dis. »
Enfin, je retiens ceci :
Savoir dire non face à l’absence de connaissances d’untel ou untel (comme le client de cette agence et Greg ici): c’est une compétence professionnelle aussi importante que coder proprement, de faire sa veille tech’, … ; et comme toute compétence, elle n’est pas innée et ça s’apprend
Allez, je vais choper ce livre car j’ai vraiment beaucoup à apprendre ; Et dire que je voulais, pour ces prochains mois, ne me consacrer qu’à mes skills techniques : bref, une erreur esquivée, une 🙂
Il est touchant ton fils !
Je viens d’avoir une fille, ca me parle !
Salut Mehdi,
Je te cite :
« Je le répète, il aurait dû quitter la salle furieux. Il a quitté la salle serein. Ce fait est ma faute. Ce fait-là va entrainer tout le reste. »
Pourquoi c’est arrivé ?
1- Parce qu’il te connaît un minimum et savait comment te retourner (le coup de flatter l’égo avec « pourtant vous êtes en avance. C’est toi que me l’a dit » – une semaine d’avance punaise !)
2- Parce que des fois, contre toute attente, le sale boulot, ça passe; et que la boîte ne perd pas le client. Et du coup le patron ne perd pas la face.
La situation décrite illustre bien une autre très mauvaise pratique dans l’IT (peut-être ailleurs aussi, hein ,je parle de ce que je connais un peu) : le chef de projet amovible : un coup tout doit passer par lui, un coup il est court-circuité et tu te retrouves avec un contexte complètement différent, face à quelqu’un qui n’est pas équipé pour comprendre les contraintes, délais, objectifs qualité et tout l’arsenal. Pourquoi le boss l’a évincé ? Parce que vous auriez été 3 à faire front contre lui, et là ça changeait la donne.
D’une certaine façon, ta première erreur a été d’accepter la réunion SANS que le chef de projet n’y assiste ^^
PS : merci pour la référence du bouquin, je me jette dessus 🙂
« Pourquoi le boss l’a évincé ? Parce que vous auriez été 3 à faire front contre lui, et là ça changeait la donne. »
Alors oui à 300%. Le chef de projet qu’on avait aurait refusé tout en bloc. Je ne le dis pas dans mon histoire, mais ce mec-là à chercher un autre taf après cette histoire et quelques mois plus tard il était parti aussi. Le turn-over de cette boite était (est?) énorme !
La direction qui courtcircuite les chemins de décisions habituels c’est de toute manière voué à l’échec.
Perso j’ai déjà vécue ce genre de situation (avec moins d’enjeu) : Le big boss (qui vire plus vite que son ombre) te demande un truc impossible , tu lui dis non , il te répond que en fait ca sera oui … et ba tu t’écrases , tu te plante comme prévu et tu prend une chasse parce que tu avais raison …
Tu lui a dis non ou que t’allait essayer ?
Si il avait aucun espoir et que tu as prévenu tout le monde que c’était voué à l’echec tu as déjà fait plus que moi.
Je suis partagé sur ton expérience.
Bien raconté et clair.
La question que je me pose (j’ai quelques années d’expériences dans le monde du développement)
Ok, vous n’avez pas assez alerté.
Ok, vous saviez que cela n’allait pas passer.
Celui qui a perdu son client c’est bien Greg et pas toi.
Ton salaire (je parle après du licenciement abusif), lui a été versé et celui ton collègue.
Donc dans l’absolu tu n’as pas à culpabiliser.
Je vous rejoins sur l’envie de fournir un outil performant, dans les temps et sans la présence de bugs.
Je vous rejoins sur l’envie d’être tranquille un week-end plutôt que de coder comme des cons mêmes si bien payés ou bien compensés.
Prenons du recul sur ce genre de situation en général.
Il faut apprendre à faire la part des choses entre les enjeux de l’entreprise, et l’envie de faire des choses de qualités.
L’entreprenariat est une prise de risque. Ce n’est pas une science exacte. On peut (nous développeurs) laisser le choix de livrer un outil dans un état ou dans un autre. Si tous les signaux d’alertes ont été envoyés, le métier a été fait.
Avez vous la garantie que le client aurait été conservé avec la version initiale ?
Pour la suite, sur ton collègue, je ne peux pas jugé en l’absence de détails si le licenciement est abusif. Je ne peux pas m’exprimer ou avoir un avis. Ce qui est certains, c’est que le risque pris par le dirigeant en se séparant d’un collaborateur de qualités a t’il été bien mesuré ?
Notre métier est fait que nous touchons à tellement de domaines de l’entreprise, que souvent nous en avons une très grande voir trop grande compréhension de son fonctionnement. Des choses qui nous paraissent évidents sont souvent difficilement compréhensibles par d’autres personnes.
Le management est compliqué. Ce n’est pas un art, ce n’est pas une science. Il faut faire avec les contraintes du métier, des personnes.
Votre expérience traduit bien cette difficulté que l’on a du toujours plus.
Je suis persuadé à 90% que Greg aurait convaincu le client de trouver une alternative si j’avais fait mon travail en anéantissant clairement tous ces espoirs de livrer à temps.
Génial cet article ! J’ai eu une expérience similaire lors de mon premier emploi, ça m’a foutu dans un état psychologique assez difficile, je peux te dire que ça forge le caractère, tu ne peux plus négocier avec moi. Si je dis 1 mois, ce n’est pas 15 jours (au mieux t’auras la moitié des features), pareil pour les heures sups pour moi il y a deux types d’heures sups : celles imposées par la direction car c’est elle qui a donné une deadline et dans ce cas il est hors de question que je les fasse et celles où c’est moi qui ai merdé dans mon estimation et dans ce cas j’assume et je bosses plus pour terminer à temps.
Un moment donné il faut arrêter d’avoir peur de dire non sous prétexte qu’il faut respecter la hiérarchie. Je ne vois pas en quoi la hiérarchie donne le droit de littéralement chier sur notre taf ou nous manquer de respect. Si le boss n’est pas content ben ce n’est pas mon problème, si le fait que je dise non, en donnant les explications de mon refus, ne lui plaît pas, je l’invite à venir faire le taf à ma place (j’ai déjà entendu dire : « C’est rien ça se fait en 2j, s’il faut j’apprends à dev et je vous aide »).
On a cette responsabilité de dire ce qui est faisable ou non et de donner des délais, ce n’est pas à des personnes non techniques d’imposés ce qu’ils souhaitent. Expliquer au client qu’il y a du retard ou qu’il faut un délai supplémentaire, c’est pas mon travail ! Si au dessus ça ne sait pas l’expliquer ce n’est pas moi qui ne suis pas pro.
Récemment j’ai bossé pour un client qui avait les mots de passe enregistré en clair en base de données car c’était une demande de la hiérarchie pour je cite : « Pouvoir renvoyé facilement les mots de passe aux clients ». Et bien sur personne à dit non on ne fait pas ça. Le responsable ici c’est clairement le développeur, pas la direction complément à l’ouest.
« Je ne vois pas en quoi la hiérarchie donne le droit de littéralement chier sur notre taf ou nous manquer de respect. »
Exact ! J’ai l’impression qu’il faut respecter l’avis de tous les corps de métiers sauf le nôtre. Pourquoi on devrait systématiquement s’écraser quand on a l’expertise technique qui est la base du produit vendu ?
Et pour l’histoire des mots de passe, c’est clairement irresponsable du dev, je te rejoins aussi là-dessus.
Surement l’un des développeurs francophone les plus intelligents qu’il nous est donné de lire, le mec se regarde bien en face dans le miroir, chapeau 🙂
Biensur que Greg est un con, mais des Greg il y’en a dans toutes ENS ou agence web … et c’est bien de savoir aussi les gérer.
Merci pour tes articles.
J’ai pas l’habitude des compliments sur Internet lol merci à toi !
Article et commentaires très intéressants.
Pour moi, il y a clairement une « faute » des devs par la non application d’un principe de base du travail en agence : on est jamais en avance.
Au mieux on est dans les clous pour la future deadline, voire on a une chance très raisonnable de pousser en prod dans les délais, mais annoncer une semaine d’avance, ce n’est plus un bâton que l’on tend, c’est un fouet (avec les boules cloutées).
Ce non respect des effets de la loi de Parkinson ( qui énonce que, comme le gaz, le temps se dilate jusqu’à occuper la totalité de l’espace disponible. ) ouvre une voie royale à ceux qui, comme ton manager, sont prés à accepter 3000 features (?!!?) une semaine avant la livraison.
Pas sur que devant le client il aurait enclenché la manip s’il n’avait pas eu cette « marge » d’une semaine annoncée.
Par contre, je suis sur que depuis, à chaque fois que tu annonce une avance, tu dois ressentir un léger picotement annonciateur, là, pas loin du bas du dos.
Au plaisir de te lire à nouveau
Il me semble important de dissocier les mots ‘faute’, « erreur », ‘responsabilité’ et de clarifier ces termes sur le plan humain, technique et juridique. Je vais rester sur le plan humain …
La faute est un jugement de valeur, une assignation psychologique péjorative qui ne désigne pas vraiment la réalité, c’est un mot qui va surtout faire peser le sentiment de culpabilité sur la personne, il n’apporte généralement rien de constructif, si ce n’est la punition que l’on s’inflige ou que l’on inflige à l’autre. C’est un mot qui exprime davantage notre volonté d’avoir raison plutôt que de décrire la réalité.
La responsabilité, sur le plan humain, c’est ce que l’on porte tous envers nous-même, c’est de notre vie dont nous sommes responsables avant tout. Si nous ne prenons pas soin de nous-même, ne comptons pas prendre soin des autres, c’est impossible même si on peut simuler. En d’autres termes, dans l’exemple, tu es responsable de ton stress, de ton émotion, même si tu n’en n’es pas le déclencheur direct. Quelqu’un d’autre aurait pu gérer la situation sans stress, on ne réagit pas tous de la même manière.
Si tu es conscient en chaque instant de tes décisions, y compris lorsque tu décides d’essayer, alors peu importe le résultat, à ce moment-là c’était le meilleur choix pour toi que tu envisageais, il ne pouvait en être autrement dans l’instant. L’important est d’être conscient de ce que l’on fait pour ne pas regretter où se culpabiliser après. De plus, c’est important que l’on ne donne pas à l’autre la possibilité de télécommander sa vie par les sentiments, on doit prendre la responsabilité de ce que l’on ressent, pas de ce que l’autre ressent. Autre importance : le choix des mots, il est courant d’user de « faute » mais il ne faut pas oublier qu’on ne ressent pas la même chose quand on parle d’erreur. L’erreur est humaine, la faute moins…
Dans la situation exposée, personne n’est coupable mais personne n’a pris la responsabilité de ce qu’il ressentait, chacun a pris le chemin de la réaction première comme il est courant de le faire. Si le côté « stress » avait été un minimum pris en compte pour chacun, chaque partie aurait pu s’exprimer en posant les faits sur la table et en discutant des choix possibles. Une fois que l’on comprend mieux comment ces interactions se font, il est plus facile de reprendre le contrôle de soi, de ne pas se laisser porter par ses réactions premières mais il ne faut pas non plus toujours s’attendre à ce que nous soyons purement cartésien à chaque fois, surtout quand un gros bagage émotionnel est là…
On peut avoir un gros QI mais un faible QE et je pense que c’est ce dernier point que l’on a tous besoin de travailler …
Ce n’est pas de ta faute, ce n’est pas à toi d’encaisser les humeurs de ton boss, si tu avais refuser en bloc tu aurais été viré
Je suis en partie d’accord : effectivement, savoir dire non est important. De l’autre côté, et ça a déjà été dit, mais 1/ ton boss a, dans cette société, l’autorité sur toi 2/ tout le monde n’a pas la force mentale nécessaire (pas besoin d’être excellent en communication, charisme, etc pour être un bon dev en soit), c’est à ça que sert le chef de projet (et c’est précisément pour ça qu’il a été sorti de la boucle je suppose).
Et c’est usant à long terme. Dans ma boîte on est pas dev, mais on est 10 à dire non tout le temps. Mais des fois c’est plus facile de dire oui (quand c’est techniquement faisable mais crado, surtout. Quand c’est pas faisable du tout c’est moins difficile à tenir comme position). Dans tous les cas avec un management comme celui-là, la seule solution c’est de changer de boîte… perso si je reste dans celle où je suis, c’est que l’équipe fait bloc donc on arrive à se faire comprendre, et la situation s’améliore continuellement depuis les 3 ans que j’y ait passé (y’a juste la Covid qui fait stagner un peu récemment, mais on approche d’un nouveau grand bond en avant).
Je suis d’accord sur le fait de savoir dire non quand il faut. Le boss aurait aussi dû écouter et surtout passer par le chef de projet (dans le cas où il y en a un).
Mais
Moi ce que je ne comprends pas dans cette histoire c’est comment une nouvelle liste de tâche importante est apparue quelques jours avant la deadline.
Comment on peut en arriver à avoir des tâches (qui ne sont pas des bugs mais bien des features) à ce moment là d’un projet ? Et sans modification de contrat ou de deadline ? Une étape à été sauté et pour moi il est là le vrai problème. Il n’y a pas que le Dev qui n’a pas su dire non.
Ce chef est zéro. Mais il va faire carrière j’en suis sûr.
Un chef a toujours raison et ce qu’ils détestent le plus c’est qu’on les désobéissent.
L’erreur aurait été de rester dans cette boite et de continuer à s’en plaindre.
Accepter de venir bosser le weekend pour rattraper les erreurs des chefs c’est quand même abusé.
Ça dépend du rapport de force aussi. En France malgré tout on peut se faire virer mais derrière c’est pas gratuit on a un filet pour nous rattraper et en plus dans la tech on retrouve facilement autre chose, souvient mieux, au pire on trouve un truc pour payer ses factures pendant un temps.
Les choses seraient différentes si le rapport de force était encore plus défavorable. Que fait-on dans la même situation si on est plus sur un job très demandé et qu’on a un âge qui dérange les DRH ?
C’est ce que je craint le plus, le moment ou je devrait m’agenouiller devant le chef sous peine d’être en vraie galère.
Peut être que chef de projet protège plus de ce type de situation. Même si la direction peut dans tous les cas décider de ce qu’elle veut…
Ou alors il faut faire partie de ceux qui arrivent à devenir chef. Le job ne me fait pas rêver mais dans le pire des cas on peut sacrifier à son tour un « grouillot » pour sauver sa peau.
La dure loi de la jungle en quelque sorte.
En vrai , j’ai eu les mêmes problèmes dans ma précédente entreprise. C’était constamment trop de taff/ pas assez de taff / trop de taff.
Des tâches hors scope qui pop dans tt les sens, des tâches « inutiles » de refacto non demandées par les clients , pour être sûr qu’on bosse. Par contre, tous les projets à délais tirés au maximum pour être sûr de les gagner, et des modifications qui semblent faciles pour le commercial/patrons, mais qui ne le sont pas.
Aucun temps pour se reformer correctement, aucun temps pour refacto correctement les choses.
Je suis pas d’accord avec toi . Déjà, discuter avec des idiots (au sens duning kruger du terme) , ca sert à rien. Un idiot, il croit avoir raison sur des sujets qu’il maitrise pas. Un idiot tu discute pas avec lui, soit tu le court circuite, soit tu l’écoute pas et tu refuse toute décision de sa part quitte à tomber dans l’insubordination la plus pure. La tech a toujours raison, la science a toujours raison, point.
De deux, ces gens , les manager/patron/commerciaux/financier , sont ceux qui touchent le plus de thune. Parce qu’ils sont plus proches de la thune, parce qu’ils prennent « plus de risque ». Ben justement, c’est lui qui a pris le risque. Il aurait dû le payer, se faire dégager. Si tu livre pas le produit , si tu appuie pas sur le bouton en tant que tech , il peut rien faire. Il SAIT rien faire. C »est des gens ils maitrisent la suite office et ils croient t’apprendre ton travail.
Moi je crois, que c’est le monde qui est fuckedup . Les gens qui produisent des produits, de l’intelligence, de la méthode, de l’automatisation, sont les sous fifres sous payés des gens qui produisent de la valeur commerciale et du prestige, et qui depuis un certain temps sont les maitres des délais et des idées.
Rien n’est plus mauvais. Un idiot ne devrait jamais pouvoir décider, et on laisse des idiots décider. Le monde va mal, parce que c’est pas normal que l’argent et le pouvoir décisionnel soit aussi mal distribué entre ceux qui vendent la valeurs et ceux qui a crée.