Depuis quand le manager définit des deadlines? J'imagine que les ingés de dante sont sur des projets donc ont des chefs de projets qui définissent des deadlines projets...
Ou alors la deadline c'est pour faire la formation "qualité de vie au travail"...:o

 
   question sérieuse en fait...
Ca fait 20 ans que je bosse et dans toutes les boites ou je suis passé tous les gens opérationnels (soit l'écrasante majorité des salariés) bossent sur des projets, les seuls à ne pas le faire sont en général sur des fonctions supports.

 
En fait je suis pas vraiment informaticien.
Si tu veux la sortie d emon travail c'est un élément physique qui est produit.
 
Mais je dois dire que personnellement j'ai touours été dans un monde ou tout est très orienté projet du coup je suis intéressé par les organisations à l'ancienne vu que visiblement pleins de gens connaissent ça...:o

 
 
En fait je suis pas vraiment informaticien.
Si tu veux la sortie d emon travail c'est un élément physique qui est produit.
 
Mais je dois dire que personnellement j'ai touours été dans un monde ou tout est très orienté projet du coup je suis intéressé par les organisations à l'ancienne vu que visiblement pleins de gens connaissent ça...:o

300k c'est le CA sur combien de temps ? tu ramènes ça quelle rem ?

 
Je n’ai jamais travaillé dans une boîte où il y avait des chefs de projet.
 

 
Je n’ai jamais bossé dans une vieille COGIP comme toi, mais voilà le mode de fonctionnement classique en startup web.
 
Ça fait 20 ans que je bosse, et j’ai globalement toujours eu du temps libre pour des « projets » pas définis par la boîte.
 
En tant que manager d’équipes orientées Product Engineering, mon but est de trouver un équilibre entre différents besoins. Je dis souvent qu’idéalement, le travail de l’équipe devrait être reparti ainsi :
- 50% en développement de nouvelles fonctionnalités / amélioration de fonctionnalités. Ce boulot est généralement guidé par un Product Manager (PO en VO il me semble), mais les développeurs peuvent soumettre des suggestions.
- 25% en correction de bugs. Ce boulot est principalement guidé par le SLA
- 25% en amélioration du code. Ce boulot est principalement guidé par les ingénieurs de l’équipe.
 
En bossant en environnement agile, on évite d’avoir des deadlines. Quand cela arrive malgré tout, le team leader est la personne responsable pour faire ce que tu présentes comme le boulot d’un chef de projet (souvent soutenu par le PO).
 

 
Des projets ou des produits?
 
Perso je dirais que la façon dont ma team bosse dans la pluspart des boites que j'ai fréquenté c'est:
- 1 Une part du taf sur le ou les produits, ce que la boite commercialise et qui rapporte de la thune - taches et deadline gérées par la prod, avec mon apport pour aider la prod a savoir de quoi ils ont besoin et comment le faire
- 2 Une part du taf sur des produits ou des projets internes à ma team (ex construire un outil de prédiction (produit), retravailler le tracking pour améliorer les perf de nos reportings (projet)) - taches et deadlines gerées par moi
 
La répartition entre ces 2 poles varie selon la maturité de la boite, + elle est immature + y'a de taf en 2

 
Je n’ai jamais travaillé dans une boîte où il y avait des chefs de projet.
 

 
Je n’ai jamais bossé dans une vieille COGIP comme toi, mais voilà le mode de fonctionnement classique en startup web.
 
Ça fait 20 ans que je bosse, et j’ai globalement toujours eu du temps libre pour des « projets » pas définis par la boîte.
 
En tant que manager d’équipes orientées Product Engineering, mon but est de trouver un équilibre entre différents besoins. Je dis souvent qu’idéalement, le travail de l’équipe devrait être reparti ainsi :
- 50% en développement de nouvelles fonctionnalités / amélioration de fonctionnalités. Ce boulot est généralement guidé par un Product Manager (PO en VO il me semble), mais les développeurs peuvent soumettre des suggestions.
- 25% en correction de bugs. Ce boulot est principalement guidé par le SLA
- 25% en amélioration du code. Ce boulot est principalement guidé par les ingénieurs de l’équipe.
 
En bossant en environnement agile, on évite d’avoir des deadlines. Quand cela arrive malgré tout, le team leader est la personne responsable pour faire ce que tu présentes comme le boulot d’un chef de projet (souvent soutenu par le PO).
 

 
Oui enfin il y a pas de chef de projet parce que vous les appelez autrement en fait.  
Si tu pars comme ça en ce moment j'ai pas de chef de projet non plus vu qu'on a des PO qui gèrent l'éxécution.
 

 
Enfin il suffit de dire que ce sont des projets et ça reste tout à fait le genre de truc qu'on fait...

 
Je n’ai jamais travaillé dans une boîte où il y avait des chefs de projet.
 

 
Je n’ai jamais bossé dans une vieille COGIP comme toi, mais voilà le mode de fonctionnement classique en startup web.
 
Ça fait 20 ans que je bosse, et j’ai globalement toujours eu du temps libre pour des « projets » pas définis par la boîte.
 
En tant que manager d’équipes orientées Product Engineering, mon but est de trouver un équilibre entre différents besoins. Je dis souvent qu’idéalement, le travail de l’équipe devrait être reparti ainsi :
- 50% en développement de nouvelles fonctionnalités / amélioration de fonctionnalités. Ce boulot est généralement guidé par un Product Manager (PO en VO il me semble), mais les développeurs peuvent soumettre des suggestions.
- 25% en correction de bugs. Ce boulot est principalement guidé par le SLA
- 25% en amélioration du code. Ce boulot est principalement guidé par les ingénieurs de l’équipe.
 
En bossant en environnement agile, on évite d’avoir des deadlines. Quand cela arrive malgré tout, le team leader est la personne responsable pour faire ce que tu présentes comme le boulot d’un chef de projet (souvent soutenu par le PO).
 

La différence c'est que tu bosse que sur du 1 apparement, 100% de temps temps est lié à produire un produit, pas de process et de projets propres à ta team "métier", mais je pense que c'est pareil pour les devs et ingé dans mes boites.
Dailleurs ils ont ce système d'avoir 1 manager purement RH (quel job de merde d'après moi), et un lead sur le produit qui suit leur day to day, donc ils ont pas vraiment d'équipe métier en fait.

Ma team utilise des outils et des process très spécifiques, c'est mon rôle de décider comment les maintenir et de les faires évoluer en fonction de l'évolution de la boite, c'est la différence avec ton métier je pense.

 
Oui enfin il y a pas de chef de projet parce que vous les appelez autrement en fait.  
Si tu pars comme ça en ce moment j'ai pas de chef de projet non plus vu qu'on a des PO qui gèrent l'éxécution.
 

 
T'as pas des sprints / releases?
En général dans les boites où je bossent ils mesurent le succès d'un sprint au % de réalisé versus prévu, et le succès d'une release a ce qu'elle sorte à la date prévue avec le contenu prévu et sans trop de bugs

 
Depuis quand le manager définit des deadlines? J'imagine que les ingés de dante sont sur des projets donc ont des chefs de projets qui définissent des deadlines projets...
Ou alors la deadline c'est pour faire la formation "qualité de vie au travail"...:o

 
Bah non on fait ça aussi mais globalement pour moi ce sont des projets plus petits avec pas forcement des chefs de projet et effectivement souvent géré par les managers (il me semble qu'on appelle ça le métier dans ma boite actuelle), ça donne des trucs du genre: "amélioration du process de desanussage des poulpes", "etude des nouveaux outils de  desanussage des poulpes".

 
Dans ce que tu décris et mon domaine, ce sont les membres de l’équipe qui ont donné le temps de réalisation. Les fonctionnalités sortent quand elles sont prêtes. Il n’y a pas de deadline. Dans certaines boites, ils livrent plusieurs fois par jours. Dans mon monde B2B, on livre ce qui est dispo toutes les 2 semaines après un sprint.
 
Après il y a des fois où il y a des deadlines (principalement liées à la signature d’un client), et là le mode de travail peut être différent.
 
Quand j’ai commencé ma carrière, on avait une release annuelle pour laquelle il fallait être dans les temps pour que les CDs puissent être créés et envoyés par la poste  

 
Dans ce que tu décris et mon domaine, ce sont les membres de l’équipe qui ont donné le temps de réalisation. Les fonctionnalités sortent quand elles sont prêtes. Il n’y a pas de deadline. Dans certaines boites, ils livrent plusieurs fois par jour. Dans mon monde B2B, on livre ce qui est dispo toutes les 2 semaines après un sprint.
 
Après il y a des fois où il y a des deadlines (principalement liées à la signature d’un client), et là le mode de travail peut être différent.
 
Quand j’ai commencé ma carrière, on avait une release annuelle pour laquelle il fallait être dans les temps pour que les CDs puissent être créés et envoyés par la poste  

L individuel c’est tous les 15 jours.
 
Je fais ça depuis des années    
 
Et en 2023 ça sort comme bonne pratique dans les formations « prévenir le burn-out » qui sont donnés aux managers  

Un entretien individuel tout les 15 jours ?!!
 
WTF c est quel genre de management ça

 
Le truc, c'est qu'un manager ne doit PLUS JAMAIS mettre les mains dans le cambouis. Ne PLUS JAMAIS prendre des projects sensibles ou des cas litigieux. Un manager ne doit faire QUE ça : manager = gérer ses collaborateurs, les encadrer, les aider, les protéger, les faire progresser, les virer parfois, les former, en recruter de nouveaux, etc...  
....
Job à temps plein ! Si vous êtes promu manager, ne faites que cela, ce sera déjà très bien !  

Je vais éviter d’éditer puisque cela a déjà été quoté.
 
A très haut niveau, je dirais que mon rôle est de m’assurer qu’on arrive à cet équilibre dans la répartition du travail. S’il y a un gros écart, ça amène globalement toujours des problèmes dans la boîte à moyen terme.
- pas assez de temps passé à développer des fonctionnalités : moins de business et la boîte coule  
- trop de temps passé à développer des fonctionnalités : le code devient infâme et ralenti la progression et bien être de l’équipe. Diminution de la satisfaction du client car baisse de la qualité.
- trop de temps à corriger des bugs: moins de business et la boîte coule. Développeurs mécontents, donc ils se barrent
- pas assez de temps à corriger des bugs : clients mécontents. Développeurs mécontents car honte de bosser sur un truc qui ne marche pas.
- trop de temps à améliorer le code : moins de fonctionnalités, moins de vente = boîte qui coule
- pas assez de temps à améliorer le code : lenteur pour développer des fonctionnalités, nombre de bugs en augmentation, performance dégradée. Développeurs pas contents qui démissionnent, PO frustré des délais pour livrer la fonctionnalité, manque général de compétitivité de la boîte

 
Et vous avez personne qui consolide un plan de MVP ou un truc du genre?
Votre management veut jamais avoir telle fonctionnalité à telle date pour faire une demo?
Vos clients n'ont jamais besoin de fonctionnalité à une date donnée (j'imagine que c'est couvert par ton "des fois" )
Chez nous on fait de l'agile mais une fois que ton produit est annoncé dans la presse, que les usines sont bookées, t'as plutôt intérêt à être à l'heure (ou pas trop en retard) sinon ça coute vite très cher à tout le monde...:o

 
Il me semble que c'est pareil ici, les devs chiffrent leurs propres taches, mais n'empeche que si 60% du contenu prévu dans le sprint seulement est livrés ça va poser question, surtout si c'est répété.  
Vous n'évaluez pas la performance de la team? C'est pas grave si ils mettent 2 mois à livrer une fonctionnalité dont tout le monde sait que normalement c'est 8 jours de taf?
 
C'est moins le cas dans ma team, on a quelques taches dans chaque sprint qui sont très liées à la prod (faut que ça soit pret pour la livraison), le reste en soit si ça vient 1 semaine plus tard c'est pas très grave, mais on donnera pas l'image d'une team qui délivre quoi

 
Oui c'est important les bilats, mais y a plein de manières différentes de les faire, et tout le monde n'a pas besoin du même rythme.
Selon les personnes j'ai 15j, 3 semaines, un mois ou 3 mois.
 
Certains je n'en ai pas, je cours avec 2 fois par semaines, c'est encore mieux
 

 
C'est pas un 'entretien', c'est une discussion; ça vire d'ailleurs souvent sur le perso (plusieurs séparations actuellement dans mes équipes).
 

 
Et bien je suis en total désaccord
 
Garder les mains dans le cambouis permet d'être réellement au contact de ce qu'ils font et d'être plus pertinent dans le soutien qu'on apporte aux équipes.

 
Je trouve cette image particulièrement adaptée :
https://media.licdn.com/dms/image/C [...] ZPFEbJzJT8

 
Oui c'est important les bilats, mais y a plein de manières différentes de les faire, et tout le monde n'a pas besoin du même rythme.
Selon les personnes j'ai 15j, 3 semaines, un mois ou 3 mois.
 
Certains je n'en ai pas, je cours avec 2 fois par semaines, c'est encore mieux
 

 
C'est pas un 'entretien', c'est une discussion; ça vire d'ailleurs souvent sur le perso (plusieurs séparations actuellement dans mes équipes).
 

 
Et bien je suis en total désaccord
 
Garder les mains dans le cambouis permet d'être réellement au contact de ce qu'ils font et d'être plus pertinent dans le soutien qu'on apporte aux équipes.
 
 

 
C'est pas un 'entretien', c'est une discussion; ça vire d'ailleurs souvent sur le perso (plusieurs séparations actuellement dans mes équipes).
 

 
C'est pas un 'entretien', c'est une discussion; ça vire d'ailleurs souvent sur le perso (plusieurs séparations actuellement dans mes équipes).
 

Ben ouais, je parle du perso avec mes +1. Ca peut leur permettre de comprendre pas mal de trucs. Je ne suis pas qu'un travailleur. ET j'espère ne pas être que ça à leurs yeux.

ah ouais carrément parler de séparation avec le manager ?!

 
en fait je vois meme pas comment c'est possible de pas le faire    
on se voit tous les jours, on est voisin de bureau, on mange ensemble 1 midi sur 2
si y avait séparation, ça viendrait evidemment sur le tapis  

J'ai simplement donné mon opinion dans la 2eme partie, mais tu peux botter en touche si tu veux    

Non mais avec l équipe oui, mais le manager, je sais pas, bizarre pour moi
 
Après tu peux être pote avec le manager, ok, mais avec tout tes colab ?

 
en fait je vois meme pas comment c'est possible de pas le faire    
on se voit tous les jours, on est voisin de bureau, on mange ensemble 1 midi sur 2
si y avait séparation, ça viendrait evidemment sur le tapis  

Là c'est de la discussion entre collègue, dont l'un est manager.
 
On n'est plus dans le point / rdv / entretien managérial.

 
Bien sûr que si, mais c’est contre productif d’utiliser comme mesure le taux de réussite sur une métrique donnée par l’équipe elle même.
 
Si ils veulent avoir 70% de taches livrées dans le sprint, il leur suffit de surévaluer toutes les tâches    
 
De plus, le boulot est bien moins délimité que certaines personnes extérieures ne le comprennent.
 
Est ce que c’est en retard parce que la définition du besoin par le PM n’a pas été bonne ? Parce qu’il y’a eu des bugs découverts sur lequel reposent la fonctionnalité et qu’on a préféré corriger ? Est ce que le QA a bien testé ou on livre à la va-vite pour dire qu’on a livré mais il va falloir 1 mois pour corriger les bugs ?
 
C’est un job d’équilibriste à la fin.

 
Certes mais si tu connais une séparation difficile et que t'en chies (et que tu t'entends bien avec ton manager), ça peut être l'occasion de l'en informer. Parce que ça peut avoir un impact sur ton boulot/ta disponibilité dans les prochains temps quand même.

Non mais avec l équipe oui, mais le manager, je sais pas, bizarre pour moi
 
Après tu peux être pote avec le manager, ok, mais avec tout tes colab ?

 
Ça marche avec tous les évènements impactants dans la vie:
 - Décès
 - Maladie
 - Naissance
... Et le nouveau Zelda pour certains  

... Et le nouveau Zelda pour certains  

Tu l'as commence ?

 
Certes mais si tu connais une séparation difficile et que t'en chies (et que tu t'entends bien avec ton manager), ça peut être l'occasion de l'en informer. Parce que ça peut avoir un impact sur ton boulot/ta disponibilité dans les prochains temps quand même.

Bien sûr. Je vais rester assez flou malheureusement, pour des raisons évidentes.

J'ai un collaborateur qui travaille essentiellement sur le calcul et l'analyse d'un indicateur financier (on parle d'un truc impactant, et scruté par les auditeurs internes et externes, par la commfi, bref par un peu tout le monde). Cet indicateur est calculé de façon trimestrielle.

En annualisé, il va travailler environ la moitié du temps sur le calcul et l'analyse de cet indicateur. Ce temps inclut la remédiation des différents problèmes rencontrés, IT principalement, mais que.

Le reste du temps, il va travailler sur l'amélioration et l'évolution des programmes d'analyse, sur des méthodologies de modélisation de l'évolution de cet indicateur, sur l'anticipation des évolutions IT, réglementaires ou métier en terme d'impact et en terme d'analyse.

Donc sur tout ça, y'a ptet 10-15% des tâches qui se réfèrent à des projets gérés par des chefs de projet.

Tu l'as commence ?

Chez nous on dirait que c'est un projet de mise en place de l'indicateur X  

 
Certes mais si tu connais une séparation difficile et que t'en chies (et que tu t'entends bien avec ton manager), ça peut être l'occasion de l'en informer. Parce que ça peut avoir un impact sur ton boulot/ta disponibilité dans les prochains temps quand même.