Merci pour ce partage et ce constat courageux et lucide.
L'essentiel est comme tu le dis de pouvoir en tirer toutes les leçons.
Pas facile de trouver le juste milieu entre s'imposer et taper du poing sur la table et essayer de "faire avec".
Je pense que tu as eu une attitude intelligente en proposant ce que tu pensais être juste : si le client ne t'as pas écouté tant pis pour lui.
Maintenant de nouvelles opportunités vont s'offrir à toi et fort de tes expériences passés tu sauras sans nulle doute les saisir et les faire fructifier.
Merci pour ton partage, Pierre ! C'est rare de constater ses erreurs aussi vite, et encore plus de les partager au monde entier !
J'ai le sentiment, après lecture de ton article, qu'au fond l'équipe (pas que toi) a manqué de combativité et de résilience face à l'autorité.
Est-ce qu'une devteam peut contester, objecter ou même refuser de produire quand les conditions de travail sont insatisfaisantes voire néfastes ? Quand je me suis retrouvé dans la même position avec l'un de mes clients, pour des raisons différentes des tiennes, j'en suis arrivé à la conclusion que, parfois, il faut s'arrêter de produire n'importe quoi n'importe comment, et forcer le client à changer de comportement vis-à-vis de la dev team. Sinon, il faut s'en aller et le laisser dans sa bouze (tant pis pour lui, tant mieux pour nous !).
La réalité, c'est que nous sommes (encore) en position de force sur le marché. Il devient urgent d'en profiter tant que ça dure pour que notre production soit en phase avec notre philosophie du travail (agilité, TDD, lean...). Cela revient à s'organiser collectivement, entre producteurs de valeur (c'est nous, les codeurs !), et identifier, dénoncer, lutter contre tous les comportements anti-agiles (ou, plus globalement, anti-travail). Je peux t'assurer qu'un employeur, s'il se sent en danger de ne plus pouvoir employer tes talents, réfléchira à deux fois avant de t'envoyer des specs de 60 pages sans t'avoir consulté en amont !
Bonjour Pierre,
Merci pour ce partage et ce constat courageux et lucide.
L'essentiel est comme tu le dis de pouvoir en tirer toutes les leçons.
Pas facile de trouver le juste milieu entre s'imposer et taper du poing sur la table et essayer de "faire avec".
Je pense que tu as eu une attitude intelligente en proposant ce que tu pensais être juste : si le client ne t'as pas écouté tant pis pour lui.
Maintenant de nouvelles opportunités vont s'offrir à toi et fort de tes expériences passés tu sauras sans nulle doute les saisir et les faire fructifier.
Bonne chance et bon courage à toi pour la suite.
A bientôt.
Sébastien
Merci pour ton partage, Pierre ! C'est rare de constater ses erreurs aussi vite, et encore plus de les partager au monde entier !
J'ai le sentiment, après lecture de ton article, qu'au fond l'équipe (pas que toi) a manqué de combativité et de résilience face à l'autorité.
Est-ce qu'une devteam peut contester, objecter ou même refuser de produire quand les conditions de travail sont insatisfaisantes voire néfastes ? Quand je me suis retrouvé dans la même position avec l'un de mes clients, pour des raisons différentes des tiennes, j'en suis arrivé à la conclusion que, parfois, il faut s'arrêter de produire n'importe quoi n'importe comment, et forcer le client à changer de comportement vis-à-vis de la dev team. Sinon, il faut s'en aller et le laisser dans sa bouze (tant pis pour lui, tant mieux pour nous !).
La réalité, c'est que nous sommes (encore) en position de force sur le marché. Il devient urgent d'en profiter tant que ça dure pour que notre production soit en phase avec notre philosophie du travail (agilité, TDD, lean...). Cela revient à s'organiser collectivement, entre producteurs de valeur (c'est nous, les codeurs !), et identifier, dénoncer, lutter contre tous les comportements anti-agiles (ou, plus globalement, anti-travail). Je peux t'assurer qu'un employeur, s'il se sent en danger de ne plus pouvoir employer tes talents, réfléchira à deux fois avant de t'envoyer des specs de 60 pages sans t'avoir consulté en amont !