Attention je parle pour des équipes de dev ou assimilé. Pour des métiers réactifs et a interruption c'est un peu différent.
Mais dans tout les cas il très important de toujours savoir ce qu'on cherche à optimiser et ensuite de décider des mesures et des actions pour y parvenir. C'est extrêmement important de comprendre dans quel but sont collectés les métriques afin de les choisir judicieusement, et de reporter ce qui est utile: granularité, type de reporting, analyse à faire etc. Il faut aussi réfléchir aux différentes approches pour essayer d'atteindre l'objectif qu'on se donne. Le reporting n'est jamais une solution. Ca peut par contre être un outil temporaire ou une mesure à long terme dans un processus d'amélioration et gagnant de la connaissance sur soi même.
Je ne connais Scrum et autres méthodes Agiles que de nom, jamais eu le temps/dispo/[ mettez ce que vous voulez ici ] pour apprendre et mettre en place dans mon équipe
Le passage "service IT d'une PME" m'en fait douter. Mais citer Scrum n'était pas le point fort, juste un mauvais exemple du à un biais de dev.
Par contre le "jamais eu le temps/dispo/[ mettez ce que vous voulez ici ] pour apprendre et mettre en place dans mon équipe" me semble souligner le syndrome . Je vais caricaturer vu que je ne connais rien de ton cas ne m'en tiens pas rigueur, mais en gros tu collectes des données à postériori sans avoir de but ou de plan assurer la qualité produire et améliorer constamment ton équipe. Pourquoi perdre du temps à demander un reporting à grain fin ? Si l'objectif est suffisamment important pour justifier une action de toute ton équipe pourquoi ne pas prendre le temps pour réfléchir sérieusement à ton organisation afin d'augmenter significativement la productivité, la qualité ou les conditions de travail de ton équipe ?
Si c'est pour détecter les imprévus, pourquoi ne pas chercher le moyen le plus efficace de suivre ce points. Ce n'est surement pas une métrique à l'heure qui t'intéresse; mais d'avoir une idée du volume que ca représente, du taux d'interruption, de la fréquence, des sources, pour pouvoir prendre les actions pour protéger ton équipe.
Si c'est pour de la facturation, selon la taille de tes projets une estimation "gros grain" peut largement être suffisante et peut être faite par le management. Par exemple à la fois mon manager, mon project manager, mon scrum master et toute mon équipe seraient capable de fournir la même facturation que si on demande à chaque personne de le faire. Pourquoi faire perdre du temps à X personnes ? De même notre organisation nous permet d'avoir une connaissance de nos capacité et de notre planning que ne nous donnerait pas du time tracking. Ce n'est donc que de la perte.
Si c'est pour mesurer la qualité des projets (reporting au type de tâche). Alors là c'est juste de la connerie pur et dure car il n'y a aucune corrélation entre la métrique et l'objectif, c'est ultra couteux à reporter, et tout le monde va biaiser les entrées pour rentrer dans le stats et pas être emmerdé.
Encore une fois ce que je dis est extrêmement caricatural. L'idée c'est que je n'ai jamais vu d'utilisation utile et raisonnable du time tracking dans le but d'améliorer la production. Après ça peut être imposé par une politique de boîte ou des contraintes légales et là il faut juste exploiter le système pour fournir des stats dans le bon ordre de grandeur à moindre coût (typiquement je rapporte à la semaine ou au mois en agrégeant plutôt que faire 200 entrées ce qui n'a aucune valeur). Mais si on reste à des échelles où la logique à encore un sens, faut bien réfléchir aux raisons qui feraient mettre ça en place. On ne peut pas s’améliorer sans mesurer, mais mesurer ne veut pas dire qu'on s' améliore ni que c'est pertinent...
[^] # Re: Contraintes pour l'utilisateur
Posté par ckyl . En réponse à la dépêche eHour, SO Planning: 2 logiciels de suivi d'activité. Évalué à 4.
Attention je parle pour des équipes de dev ou assimilé. Pour des métiers réactifs et a interruption c'est un peu différent.
Mais dans tout les cas il très important de toujours savoir ce qu'on cherche à optimiser et ensuite de décider des mesures et des actions pour y parvenir. C'est extrêmement important de comprendre dans quel but sont collectés les métriques afin de les choisir judicieusement, et de reporter ce qui est utile: granularité, type de reporting, analyse à faire etc. Il faut aussi réfléchir aux différentes approches pour essayer d'atteindre l'objectif qu'on se donne. Le reporting n'est jamais une solution. Ca peut par contre être un outil temporaire ou une mesure à long terme dans un processus d'amélioration et gagnant de la connaissance sur soi même.
Le passage "service IT d'une PME" m'en fait douter. Mais citer Scrum n'était pas le point fort, juste un mauvais exemple du à un biais de dev.
Par contre le "jamais eu le temps/dispo/[ mettez ce que vous voulez ici ] pour apprendre et mettre en place dans mon équipe" me semble souligner le syndrome . Je vais caricaturer vu que je ne connais rien de ton cas ne m'en tiens pas rigueur, mais en gros tu collectes des données à postériori sans avoir de but ou de plan assurer la qualité produire et améliorer constamment ton équipe. Pourquoi perdre du temps à demander un reporting à grain fin ? Si l'objectif est suffisamment important pour justifier une action de toute ton équipe pourquoi ne pas prendre le temps pour réfléchir sérieusement à ton organisation afin d'augmenter significativement la productivité, la qualité ou les conditions de travail de ton équipe ?
Si c'est pour détecter les imprévus, pourquoi ne pas chercher le moyen le plus efficace de suivre ce points. Ce n'est surement pas une métrique à l'heure qui t'intéresse; mais d'avoir une idée du volume que ca représente, du taux d'interruption, de la fréquence, des sources, pour pouvoir prendre les actions pour protéger ton équipe.
Si c'est pour de la facturation, selon la taille de tes projets une estimation "gros grain" peut largement être suffisante et peut être faite par le management. Par exemple à la fois mon manager, mon project manager, mon scrum master et toute mon équipe seraient capable de fournir la même facturation que si on demande à chaque personne de le faire. Pourquoi faire perdre du temps à X personnes ? De même notre organisation nous permet d'avoir une connaissance de nos capacité et de notre planning que ne nous donnerait pas du time tracking. Ce n'est donc que de la perte.
Si c'est pour mesurer la qualité des projets (reporting au type de tâche). Alors là c'est juste de la connerie pur et dure car il n'y a aucune corrélation entre la métrique et l'objectif, c'est ultra couteux à reporter, et tout le monde va biaiser les entrées pour rentrer dans le stats et pas être emmerdé.
Encore une fois ce que je dis est extrêmement caricatural. L'idée c'est que je n'ai jamais vu d'utilisation utile et raisonnable du time tracking dans le but d'améliorer la production. Après ça peut être imposé par une politique de boîte ou des contraintes légales et là il faut juste exploiter le système pour fournir des stats dans le bon ordre de grandeur à moindre coût (typiquement je rapporte à la semaine ou au mois en agrégeant plutôt que faire 200 entrées ce qui n'a aucune valeur). Mais si on reste à des échelles où la logique à encore un sens, faut bien réfléchir aux raisons qui feraient mettre ça en place. On ne peut pas s’améliorer sans mesurer, mais mesurer ne veut pas dire qu'on s' améliore ni que c'est pertinent...