Ah Safe, ça fait partie de ce qui m'a fait quitter l'IT ...
Ah Safe, ça fait partie de ce qui m'a fait quitter l'IT ...
Mon site sur Fuji, la photographie et les voyages : http://www.gau-photos.blogspot.fr/
Alors je connaissais Product Owner, mais Feature Owner...
- La version 3 est arrivée !
Nope, je viens d'être nommé "Single Point Of Contact" aka SPOC. Cela consiste à forwarder des mails et à perdre mon temps dans des réunions sans intérêt. C'est à se flinguer.
Heureusement que j'ai aussi gardé de vrais trucs un peu intéressants à coté, sinon je finirai par sauter du toit.
Spoiler Alert!
Some days, some nights, some live, some die in the way of the samurai
Some fight, some bleed, sun up to sun down, the sons of a battlecry
Dans une boite précédente, j'avais fait développer un POC par un stagiaire Data Scientist... Ca marchait tellement bien que le client n'en a pas voulu. Sur le sujet (complexe et pénible), statistiquement le SPOC humain fait environ 45 à 55% de bon en un seul envoi (il envoie directement à la bonne personne). Mon algo (gnagnagna proof of concept développé en interne par nos expert gnagnagna vous êtes les premiers à qui on le présente, ganagnagna client préféré slurp), dev en 2h tout compris par un stagiaire (brillant) de dernier année en R à base d'algo publics et d'une dataviz élégante (et d'une spec claire et précise de ma part, assorti d'un échantillon important de données) tapait entre 72 et 76% de bon du premier coup.
"On en reparlera quand vous l'aurez installé chez un autre client".
Comme j'ai rage quit la boite, autant dire que le sujet est parti loin... Vu qu'ils ont viré les gens avec qui j'ai fait les présentation chez les autres clients. C'est dommage, il y avait des contrats en millions annuels sur ces méthodes.
Remarque mon employeur suivant était à moitié d'accord, mais comme la data science était dans une autre division, ça a été "non".
Bref, t'as pas fini d'être spoc.
Mes propos n'engagent personne, même pas moi.
Je vais faire comme mes prédécesseurs et me trouver un autre poste
Ou je mettrai ma tenue orange et irai vérifier qu’elle me rend invulnérable face à un train.
Nan mais du coup c'est vraiment un poste où tu pousses des mails, c'était pas une blague?
Some days, some nights, some live, some die in the way of the samurai
Some fight, some bleed, sun up to sun down, the sons of a battlecry
Il n’y a pas que ça bien sûr, je dois aussi faire des extraits de fichiers PDF avant de les forwarder et faire un suivi de tout ça dans des fichiers Excel imbitables, ce serait pas assez chiant sinon.
Dernière modification par Praetor ; 24/02/2020 à 22h22.
Ce que tu décris ca me rappelle une mission en tant que coordinateur, pendant 6 mois. Perso j'ai trouvé ca bof mais il y en a d'autres à qui ça convenait...
Penche toi, sur les méthodes agiles, en particulier Scrum, parce que la tendance est que ça se répande... avant qu'on truc une autre idée
Au chapitre des baises : je viens d'apprendre que les certifications SAFe sont valides 1 seule année. Entre 100 et 300US$/an pour repasser TOUS LES ANS la certification. Bon, ben ils peuvent se la rouler bien serré, leur certifications et se l'enfiler dans l'oignon. (Bon en vrai, mon employeur est centre de formation, donc si mon employeur le souhaite je la passerai, mais à titre perso, c'est mort)
Mes propos n'engagent personne, même pas moi.
Flickr: http://www.flickr.com/derdide/
Je me permets de déterrer le topic pour une question de débutant en management.
Je me retrouve un peu contre mon gré (mes compétences sont techniques) à la tête d'une petite équipe < 15 personnes, très diverse : com, design, commerciaux, etc.
On a des soucis de communication entre nous, et la prise de décision est souvent très longue et compliquée.
Auriez-vous un livre à conseiller (kindle si possible) sur le management qui s'appliquerait bien dans mon cas, et qui soit une base solide, avec un minimum de bullshit ?
Merci !
Pour faire simple, on a un fonctionnement très communautaire. Comme on est tous en remote (même avant le virus), on a un serveur discord sur lequel tout le monde partage ses progrès, ses avis, retours. On a deux soucis principaux :
- tendance à se disperser : quelqu'un lance un sujet à résoudre et on s'en éloigne et change de sujet avant de le clore
- feedback négatif : plus souvent que non, on a une ou deux personnes (pas tjs les mêmes) qui ne seront pas d'accord quand une idée est lancée. ça mène à des débats sans fin, des décisions très longues à prendre, de l'amertume pour ceux qui essayent d'avancer, et une fatigue générale
Bon là on est en plein kickstarter, donc tout le monde est encore plus à cran, mais ces problèmes ne vont sûrement pas s'envoler à la fin de la campagne.
Tant que ça tournera comme ça vous aurez toujours les mêmes problèmes.
Dans un bateau y'a un capitaine, pas deux. Que la décision soit bonne ou mauvaise il faut quelqu'un pour la prendre et l'assumer si ça tourne mal.
Le "management" c'est pas un truc démocratique dans lequel tout le monde vote sur les décisions prises, c'est un système autoritaire dans lequel une personne (démocratiquement désignée ou pas) va prendre une décision pour les autres. Et en subir les conséquences -bonnes ou mauvaises-.
Pour filer la métaphore du bateau, tu n'imagine pas sortir la moitié du spi parce que l'équipage hésite entre spi et pas spi. Le rôle du manager c'est précisément de dire "on fait ça".
Mais en même temps de savoir que c'est sa tête qui est sur le billot si ça tourne mal (chose que beaucoup oublient malheureusement).
Le fonctionnement communautaire c'est magnifique mais ça ne marche pas (enfin trèèèès rarement) à part dans la désignation de la personne qui prendra la responsabilité de prendre les décisions (qui sont forcément clivantes mais elles doivent être prises -l'absence de décision est souvent pire qu'une mauvaise décision).
Protip, c'est pas un truc que tu apprend dans des bouquins malheureusement.
Dernière modification par Daedaal ; 27/02/2021 à 04h00.
Si ça ne marche toujours pas... Prend un plus gros marteau !
Envoyé par Daedaal
La métaphore du bateau est intéressante. Dans "The mythical man-month" l'auteur utilise la métaphore du chirurgien en bloc opératoire qui a une équipe qui l'assiste avec chacun des zones de responsabilités et d'expertise. D'ailleurs ce bouquin reste une très bonne lecture imho sur la gestion de projet IT. Le fait qu'il soit un peu vieux maintenant rend sa lecture assez intéressante quand on voit les projets qui sont décrits dans ce bouquin et ceux sur lesquels on bosse aujourd'hui.
Alors sur le point 1, c'est au "chef" (leader, scrum master, manager, chef de projet, ... whatever the title) de recentrer systématiquement les débats en repoussant "à la fin du point" les sujets qui débordent. Voir "tu montes un point sur le sujet, tu invites georges, michel, marie et tu me mets en copie, merci".
Sur le 2 : Reformuler, faire reformuler, reformuler, faire reformuler, décider. Toujours axer sur la valeur vu de client (fût-il interne) et sur l'abattement de risques.
Vu ce que je lis, il ne me semble pas qu'il ait un problème de méthode, mais plutôt un soucis, au choix non exclusif, de leadership ou d'autorité.
Donc je pense pertinent d'encourager avec une phrase d'Alexandre Astier dans la bouche de Pierre Mondy :
Mais il faut que je réfléchisse, j'ai peut-être de la matière académique/bibliographique quelque part pour donner de meilleurs éléments de langages sur ces sujets.On ne devient pas chef parce qu'on le mérite (andouille), on devient chef par un concours de circonstances, on le mérite après.
Mes propos n'engagent personne, même pas moi.