Vous êtes tombé dans le mythe selon lequel les équipes se gèrent elles-mêmes et maintenant vous êtes coincé avec le fait déplaisant que la plupart d'entre elles ne le font pas.

Oui, les 10% des meilleurs programmeurs s'auto-gèrent bien. Cela fait partie de ce qui les place parmi les 10% les plus riches. Mais la réalité est que la plupart des entreprises n'ont pas de programmeurs parmi les 10% les plus riches. La plupart des programmeurs aiment prétendre être des rock stars qui méritent un traitement spécial, mais la réalité est que la plupart ne le sont pas.

Donc d'abord, votre erreur est que vous avez abandonné toute votre autorité dont il est vraiment, vraiment difficile de récupérer. Il est toujours plus facile de commencer par des choses plus strictes et de desserrer les choses à mesure que les gens produisent que l'inverse.

Vous avez fait confiance à vos développeurs pour produire et ils n'ont pas produit, alors comment y remédier. Première étape, arrêtez de faire confiance. Oui, ils ont abusé de votre confiance (en général, lorsque les gens pensent qu'ils se font arnaquer par d'autres, faites confiance à votre instinct) et vous devez les retenir.

Vous devez d'abord obtenir un comprendre pourquoi les estimations sont si éloignées. Parce que vous avez fait un si mauvais travail de gestion, il y a de nombreuses raisons et il sera difficile d'obtenir les informations dont vous avez besoin pour résoudre le problème car vous ne demandez actuellement aucune information. Ils pourraient régulièrement promettre ce qu'ils ne peuvent pas offrir, même en travaillant dur. Ou ils pourraient promettre ce qu'ils pensent que vous voulez entendre et se relâcher parce qu'il n'y a aucun inconvénient à ne pas répondre aux attentes. Donc, avant de pouvoir réparer quoi que ce soit, vous devez savoir s'ils pourraient respecter le délai s'ils le voulaient ou s'ils ont travaillé les heures réelles auxquelles ils devraient travailler (au moins 40).

Je pense que votre meilleur pari étant donné la latitude ridicule que vous leur avez donnée, c'est de commencer par des réunions debout quotidiennes auxquelles tout le monde doit assister et des heures de base où tout le monde doit être présent (peut être de 11 à 3, pas besoin d'être 9 -6). Chaque jour, chaque personne doit se lever et dire quels progrès elle a réalisés la veille et quels problèmes elle a actuellement et comment cela pourrait affecter le délai. Vous obtenez ce que vous attendez et franchement vous ne vous attendez à rien.

Vous devez maintenant commencer à poser des questions. L'un des avantages de la réunion quotidienne est que personne ne veut dire qu'il n'a rien fait et n'a fait aucun progrès la veille. Donc, si le problème est vraiment qu'ils vous jouent, le simple fait d'avoir la réunion quotidienne devrait commencer à voir plus de progrès. Lorsqu'il y a un problème qui empêche quelqu'un de progresser (par exemple, la personne travaillant sur un module auquel elle doit se référer ne fait pas de progrès ou ne se présente pas au travail avant 3), alors c'est à vous d'éliminer les obstacles auxquels elle doit faire face. faire des progrès.

Mais il est aussi probablement vrai que les estimations de temps sont décalées. Vous devez donc également vous pencher sur la façon dont vous estimez les tâches. Vous devez également comprendre que l'estimation du temps est difficile et que vous devrez peut-être conserver des enregistrements des estimations par rapport au temps réel pour améliorer l'estimation. Les estimations de groupe ont également tendance à être plus réalistes, car les surestimateurs ont tendance à être abattus par les sous-estimateurs. Pour obtenir ces données, vous devez indiquer le temps par tâche afin de pouvoir les comparer à l'estimation. Faites-en un système de rapports simple qui ne prend pas plus de 5 minutes par jour à remplir. Et faites-leur savoir qu'il est utilisé pour améliorer les estimations pour les sprints futurs. Vous devrez peut-être également modifier spécifiquement votre formulaire d'estimation du temps pour inclure le temps pour les tests unitaires, les communications, l'assurance qualité et la correction des bogues d'assurance qualité, le déploiement, etc.

Maintenant, parce que vous avez abdiqué vos responsabilités en tant que gestionnaire, vous aurez un certain recul à ce que sont des attentes raisonnables. Eh bien, quiconque ne passe pas cinq minutes à remplir une feuille de temps ou qui ne peut pas gérer une réunion quotidienne debout (même les magasins Agile le font) et les heures de base n'est pas quelqu'un que vous voulez employer à long terme de toute façon. Ce ne sont pas des attentes déraisonnables. Il y a plus à travailler que de faire ce que vous voulez quand vous voulez le faire et si vous travaillez en équipe, vous ne pouvez pas laisser une prima donna (qui n'est vraiment qu'un programmeur moyen et tout à fait remplaçable) vous empêcher de faire votre travail. .

J'ai quelques réflexions ici

1. Vous pensez que vous dirigez, mais est-ce que l'équipe? La raison pour laquelle je vous pose la question est que j'ai déjà passé un contrat pour un entreprise où mon responsable m'a dit explicitement que tous les développeurs étaient au même niveau, mais l'un des développeurs se considérait comme le chef de file, lorsqu'il s'agissait d'un problème et d'un seul problème - il voulait que tout le monde utilise des espaces au lieu des onglets et mettez des commentaires après la ligne de code au lieu d'en haut. Aucun des autres développeurs n'a soutenu cela, mais il a estimé qu'il avait le droit d'insister pour que nous le fassions (et a refusé de discuter de la question). Cependant, lorsque le leadership était réellement nécessaire, il était introuvable. Par exemple, il m'avait demandé de prendre possession d'un sous-système et avait refusé de prendre parti lorsque l'autre développeur voulait déchirer mon système bien conçu pour quelque chose qui était moins maintenable par l'OMI. Donc dans ce cas, j'ai ignoré son "leadership" sur le formatage du code. Dirigez, suivez ou écartez-vous, mais n'insistez pas seulement pour diriger lorsque c'est quelque chose de trivial / stupide. Assurez-vous également d'occuper réellement le rôle de leadership que vous pensez occuper.
2. Existe-t-il d'autres facteurs qui ont un impact sur leurs estimations qui échappent à leur contrôle? Vos développeurs sont-ils aux prises avec une charge de code merdique à maintenir / à construire? Il est impossible de bien estimer dans ces conditions. Il se peut que pour une raison quelconque (et espérons que ce n'est pas vous), vos développeurs sont empêchés de nettoyer les points douloureux lorsqu'ils sont rencontrés. S'ils sont empêchés de résoudre les problèmes sous-jacents et ils sentent que leurs pieds sont tenus au feu pour être à la hauteur d'estimations que personne ne pourrait faire avec précision, alors ils hésiteront à le dire. en écrivant que c'est ce qui se passe.
3. Faites-vous suffisamment d'efforts pour vous assurer que les barrages routiers sont supprimés? J'ai constaté que dans les entreprises qui disent que pointer du doigt n'est pas acceptable, cela signifie "ne faites pas de vagues quand vous n'êtes pas obtenir les ressources dont vous avez besoin, "pas" vous ne serez pas blâmé si vous ne pouvez pas respecter les délais parce que quelqu'un ne vous a pas fourni ce dont vous avez besoin. " Restez au courant des experts en la matière, des concepteurs, etc., qui sont plus avancés que vos développeurs. Lorsqu'une ressource n'arrive pas comme prévu, elle peut avoir un impact énorme , même sur les développeurs qui peuvent changer de tâche en réponse. En outre, j'ai constaté que certains concepteurs n'ont aucune idée de ce que je fais avec un fichier une fois qu'il quitte leurs mains, donc leur travail prendra plus de temps à traiter. De nombreux développeurs ne prendront pas cela en compte, surtout s'il n'est pas socialement acceptable pour votre équipe de le remarquer ou s'ils n'ont jamais travaillé avec ce concepteur auparavant.
4. Les développeurs, en fait, sont-ils absents? leurs délais? J'ai été dans des situations où les spécifications étaient vraiment floues et mes demandes de clarification n'ont pas reçu beaucoup de réponses. Une fois que quelque chose a été construit, d'autres exigences sont apparues, et celles-ci ont été signalées comme des «bogues» par rapport aux fonctionnalités que j'avais déjà construites, pas en tant que nouvelles fonctionnalités. De plus, tout le monde peut être vraiment insistant sur le fait que la façon dont le développeur dit qu'elle prendra le plus de temps est la seule façon de le construire. Une fois que les gens l'ont vu, ils décident que ce n'était pas bon après tout et veulent revenir en arrière et le reconstruire d'une autre manière. Créer une fonctionnalité deux fois, c'est créer deux fonctionnalités, et vous devez la voir de cette façon.

Cela dit, je ne vois pas que quiconque ait réellement répondu à votre question. La réponse est dans le référentiel. Regardez pour voir à quoi les gens s'enregistrent et à quels problèmes se rapportent leurs enregistrements. Cela peut vous donner beaucoup d'informations sur ce qui se passe. Si les concepteurs utilisent un emplacement pour placer des actifs, voyez ce qui est prêt et ce qui manque. Si votre build est bon et que vous savez comment construire le produit, construisez-le et voyez où il se trouve.

Si vous êtes sûr que vous êtes bon sur les autres points et que vous pensez vraiment qu'il faites en sorte que tout le monde utilise votre suivi du temps, vous devez vous rendre compte que vous devez amener tout le monde à coller la tête au-dessus du parapet en même temps, car personne ne veut commencer. Cela signifie que vous devez être prêt à mettre le pied à terre avec des conséquences réelles si vous ne le faites pas, quel que soit l '«auteur» (ou le non-agresseur, selon le cas). Réfléchissez longuement si vous voulez "y aller".

Une chose à considérer est que si vous êtes un leader un peu "mouillé", il se peut que certains membres de votre équipe vous en soient très reconnaissants si vous fournissez un certain leadership - mais vous devez le fournir à tous les niveaux, pas seulement sur cette seule chose.

Vous abordez un grand nombre de problèmes différents dans la question.

Le but

Je commencerais par votre objectif de configurer le tout. Votre objectif principal est-il de savoir comment le travail progresse afin d'avoir une meilleure visibilité de ce qui se passe? Ou peut-être souhaitez-vous contrôler votre équipe jusqu'à un certain point. Ou vous le traitez comme une base du système de récompense. (Vous mentionnez les trois.)

Commencez par répondre à cette question car les solutions pour répondre à chacune d'elles seraient différentes.

Connaître le travail

Si l'objectif principal est de connaître les progrès, je conseillerais fortement la visualisation en tant qu'outil qui fait généralement des miracles. Des outils simples tels que les tableaux de tâches ou les tableaux de kanban aident non seulement les dirigeants à connaître l'état des tâches en cours dans une équipe, mais améliorent également considérablement les connaissances sur le travail de l'équipe. .

De plus, ils sont amusants. Cela signifie qu'il est généralement assez facile de les introduire dans l'équipe. L'astuce est cependant de faire en sorte que les gens travaillent avec le conseil d'administration de manière cohérente. En fait, le plus grand risque de travailler avec le tableau est que il n'est pas mis à jour. La différence entre l'outil de gestion des tâches avec le suivi du temps et le tableau des tâches / kanban est que dans ce dernier cas, vous en apprenez davantage sur les nouvelles tâches à partir du tableau, vous y allez quand même - il y a une incitation naturelle à mettre à jour la tâche chaque fois que son statut change.

Contrôle de l'équipe

Vous avez évoqué la confiance à quelques reprises. En même temps, vous indiquez la nécessité de contrôler les gens. Bien que je ne dise pas que vous devez choisir l'un plutôt que l'autre, je pense que vous devriez au moins savoir dans quelle direction vous vous dirigez.

Si vous choisissez la confiance, je ne forcerais pas les gens à rendre seule heure de leur travail chaque jour, sauf si vous travaillez à l'heure sur la base matérielle & et c'est une information de base dont vous avez besoin pour régler les comptes avec vos clients.

Je me concentrerais davantage sur le flux de travail dans son ensemble, par exemple mesurer la rapidité et la fluidité des éléments de travail qui passent de l'arriéré à la fin, et prêterait attention aux éléments bloqués pour une raison quelconque Si vous avez un élément de travail en développement beaucoup plus long que d'habitude, c'est certainement un appel pour enquêter sur le cas et savoir ce qui se passe. Soit vous trouvez un problème à résoudre, soit si quelqu'un vous laisse tomber, vous obtenez également un signal clair à ce sujet.

Cela signifie également que vous n'appliquez pas une comptabilité de travail très stricte à l'équipe qui devrait plutôt être apprécié. D'autant plus que votre équipe ne semble pas être de grands fans de l'approche actuelle, étant donné qu'elle ne met pas à jour les données assez fréquemment.

Récompenses

En ce qui concerne les informations dont nous parlons ici, je déconseille fortement de les utiliser comme base pour tout système de récompense.

Premièrement, je suis un grand fan du travail de Dan Pink sur la motivation. En fait, comme vous avez mentionné les récompenses, je ne pense pas que l'argent motive les gens comme nous le pensions auparavant. La motivation est intrinsèque et très individuelle.

Ce que je conseillerais ici, c'est d'apprendre ce qui motive votre peuple et d'essayer de traiter ces points au lieu de créer un système de récompense unique, ce qui introduit généralement beaucoup plus de négatif les émotions et les comportements dysfonctionnels que tout ce qui est positif.

C'est encore pire, si vous basez la récompense sur le travail effectué individuellement par les membres de l'équipe, vous découragez d'aider, de grouillant de problèmes et de travail collaboratif. Si j'ai terminé à 90%, je vais probablement me battre avec le reste seul au lieu de demander de l'aide (même si c'est la chose la plus raisonnable et la plus efficace à faire) car j'ai peur que ce ne soit pas "mon" succès, mais «le nôtre». Une autre perspective pourrait être que je ne suis pas disposé à aider car j'ai mon propre travail à faire et je ne suis pas sûr que ce que vous me demandez n'est pas une sorte de marais où je perdrai beaucoup de temps.

Dans l'ensemble, je déconseillerais d'utiliser les données que vous obtenez des systèmes de suivi des tâches pour récompenser, motiver ou inciter les gens.

Je ferais l'observation que même si vous avez utilisé une terminologie Agile / Scrum (Sprints, estimation) et indiquez que vous n'utilisez pas le stand-up quotidien - cependant, certains aspects de ce que vous faites semblent plus commandés / control ("J'attribue des tâches aux développeurs / j'enlève ou en mets des tâches ..")

Si vous voulez avoir une équipe auto-organisée, qui (plus critique) identifie et résout ses propres échecs ( comme accomplir 50 à 60% du travail dans le Sprint), vous devrez probablement aller plus loin dans la voie Agile / Sprint, ce qui signifie donner plus de contrôle à l'équipe.

Les points clés seraient:

• l'équipe doit définir ses objectifs de sprint (pas vous)
• l'équipe doit évaluer ensemble (pas les individus )
• l'équipe doit surveiller sa propre performance (pas vous)

Si vous avez une réunion «rétrospective» bien organisée pour l'équipe, elle doit identifier le fait ils manquent leurs objectifs et, de manière plus critique, trouvent des moyens de s'améliorer.

D'après ce que vous avez dit, vous trouverez la perte de contrôle que cela implique assez effrayante. De mon côté:

• J'ai trouvé que les rétrospectives sont plus ouvertes et honnêtes si je n'y participe pas (!)
• vous devez être prêt pour que votre équipe puisse avez des choses dures à dire sur vous
• vous devez écouter ce que votre équipe dit et agir en conséquence

Si vous n'aimez pas le son, Je vous suggère de continuer à discuter de vos problèmes avec votre équipe et de demander leurs suggestions d'amélioration. Si vous leur faites confiance, ils vous répondront de manière positive.

Une feuille de temps n'est pas un moyen de suivre les progrès. Aux endroits où j'ai travaillé, la feuille de temps était requise pour attribuer des heures au bon client. Il n'a jamais suivi la progression de la tâche.

En fait, je reprends ça. Une entreprise a essayé de suivre des informations plus détaillées. Nous avons dû mettre à jour une base de données Access via une interface graphique spéciale pour désigner par incréments d'une minute le temps passé à examiner les exigences, à rechercher, à concevoir, à coder, à construire, à tester, à déboguer. Nous avons également dû tenir compte du temps consacré aux réunions et aux tâches indirectes. C'était pour qu'ils puissent essayer de faire de meilleures estimations. Cela ne leur a jamais permis de savoir au jour le jour à quel point nous travaillions bien, ou à quel point nous étions sur le point de terminer la tâche.

Le fait de ne pas remplir une simple fiche de présence n'est pas lié au fait d'être un développeur. Cela vient seulement de la compréhension que c'est nécessaire. Si vous êtes un entrepreneur du gouvernement américain, cela est obligatoire. Ils peuvent faire des vérifications sur demande des fiches de présence. La plupart des entreprises ont maintenant mis en place des systèmes automatisés qui envoient des e-mails lorsqu'ils ne sont pas remplis à minuit chaque jour.

Le pourcentage terminé sera toujours problématique. À moins que les tâches ne soient en petits morceaux qui peuvent être effectuées en moins d'une journée, les estimations seront erronées. Si la tâche prend plusieurs jours, ils auront soit tendance à vouloir s'engager sur des pourcentages uniquement lorsqu'ils sont forcés.

Vous oscillez entre trop peu de contrôle et trop de contrôle. Les exigences quotidiennes en matière de feuilles de temps que vous souhaitez sont très strictes, mais vous les laissez ensuite commencer des tâches sans leur estimation. Vous prenez des parties incompatibles de différentes méthodologies de gestion et vous vous demandez pourquoi elles ne sont pas maillées.

J'ai complètement perdu le temps de suivi des problèmes des équipes que je dirige. Je n'exige aucune réflexion de l'individu et cela ne donne aucune information réelle sur l'état du développement. Au lieu de cela, je leur demande de mettre régulièrement à jour le temps restant pour chaque problème. Je trouve qu'il est plus facile de convaincre les gens de le faire car il y a un objectif plus clair et cela est perçu comme moins de suivre les gens et plus de suivre les efforts.

Je conteste également votre déclaration selon laquelle "PHB". Vous gérez 10 développeurs, mais vous continuez à attribuer des problèmes individuels à tous les développeurs. Cela me semble peut-être trop de micro-gestion. J'envisagerais d'essayer de laisser les développeurs choisir eux-mêmes leurs problèmes et de les organiser entre eux. D'après mon expérience, un développeur se sentira plus concerné par un problème s'il le choisissait plutôt que s'il lui était attribué. Essayez de faire des estimations lors d'une séance de planification de groupe, plutôt que de les confier à des individus, comme vous le faites aujourd'hui. Encore une fois, d'après mon expérience, cela rendra des estimations plus précises et avec moins d'écart au fil du temps. Cela renforcera également le sentiment que vous livrez en équipe plutôt qu'en groupe d'individus sur un organigramme.

N'oubliez pas de tenir des rétrospectives après chaque sprint. Comme vous le dites, vous n'arrivez souvent pas à atteindre vos objectifs. Découvrez pourquoi c'est. Mettez votre équipe au défi d'identifier les raisons de votre échec et de suggérer des moyens de surmonter. Votre équipe n'est pas une boîte noire, elle doit vous dire pourquoi elle échoue. Et puis vous (en tant que manager) devez faire ce qui est nécessaire pour les aider à réussir.

On dirait que vous faites des choses Agile-ish, mais pas tout. Agile permet une flexibilité dans la façon dont vous gérez vos équipes, mais il y a des choses qui doivent tout simplement se produire dans Agile, quelle que soit la façon dont vous les faites, et il y a une balle essentielle pour Agile que vous laissez tomber; retour rapide.

Vous voulez le stand-up quotidien. Tout le monde se rassemble en cercle autour d'un graphe déroulant et raconte à tous les autres ce qu'ils ont fait depuis le dernier stand-up. C'est une bonne chose pour tout le monde; les développeurs ont un sentiment quotidien d'accomplissement et vous obtenez des données quotidiennes sur ce qui est prévu et ce qui ne l'est pas. Si des ajustements doivent être apportés, c'est là que vous l'apprenez.

Maintenant, dans ce standup, en tant que chef de projet, vous n'êtes pas un participant actif. Tu es un poulet". Les développeurs, et tout analyste commercial ou personnel d'assurance qualité que vous avez, sont des "porcs". L'analogie vient d'une blague:

Un cochon et un poulet marchent sur la route. Le Poulet dit: "Hey Pig, je pensais qu'on devrait ouvrir un restaurant!". Pig répond: "Hm, peut-être, comment l'appellerions-nous?" Le poulet répond: "Que diriez-vous de 'jambon-n-oeufs'?". Le Cochon réfléchit un instant et dit: "Non merci. Je serais engagé, mais tu serais seulement impliqué!"

Le résultat est que vous êtes "impliqué" dans le processus, mais ce sont les membres de l’équipe qui sont «engagés» à livrer le travail. Le standup est leur outil pour s'assurer qu'ils peuvent livrer, et en tant que tel, ils l'exécutent, pas vous. Votre seule exigence est de vous assurer qu'ils l'ont et, si nécessaire, de vous assurer que cela ne se dissout pas dans une grande discussion (les standups devraient prendre 5 à 10 minutes au maximum). Cela peut être un concept difficile pour un manager, mais vous semblez être dans le paradigme des équipes autogérées, alors j'espère que ce sera une transition plus facile.

Autres conseils:

• Faites l'estimation du projet lors d'une réunion de tous les développeurs. Cette réunion d'estimation et de planification de sprint est fondamentale, et le faire en entreprise garantit que toutes les estimations arrivent; la personne est juste là, et vous devriez demander des estimations de petits morceaux avec une portée bien définie; un développeur ne doit jamais se voir attribuer une «épopée» (grand projet complexe) sans qu'elle soit d'abord décomposée en petits morceaux. Comment manges tu un éléphant? Une bouchée à la fois.
• Peu importe le temps qu'ils passent (à moins qu'ils ne travaillent 12 heures par jour ou 3 heures par jour); ce qui compte, c'est tout ce qu'ils font chaque jour et si cela les met sur la bonne voie pour respecter leurs obligations. Si, après avoir travaillé deux jours de 8 heures, ils sont en mesure de rater leur estimation initiale de moitié, alors l'une des deux choses se produit; ils ont mordu plus qu'ils ne pourraient mâcher, ou ils sont en train de sucer et de ne pas faire le travail. Réévaluez la charge de travail pour le sprint et si cela semble toujours faisable, tenez-y.
• Il est généralement préférable d'avoir des équipes travaillant chacune sur un projet. Une équipe ne doit pas être composée d'un gars travaillant sur le projet A et d'un autre travaillant sur le projet B. Même si A et B sont des sous-projets du superprojet C, les équipes tirées dans des directions différentes finiront par se fracturer. Les équipes peuvent être aussi petites qu'une personne et fonctionnent généralement bien jusqu'à une douzaine (après cela, il est généralement bon de diviser les grandes équipes en plus petites).

Dans votre longue liste de plaintes, je ne vous ai pas vu dire qu'ils n'accomplissent pas leurs tâches. Les développeurs peuvent parfois être bloqués en train de tourner les roues, vous voulez donc un certain niveau de surveillance.

Surveillez l'équipe d'une manière qui leur convient . Ils sont plus nombreux que vous - il est donc plus important que la communication soit facile pour eux.

Comment peuvent-ils communiquer leurs progrès? Standups, rapports quotidiens, rapports hebdomadaires, feuilles de temps (doivent avoir une section de notes pour la communication hors bande) - choisissez celui qui convient le mieux aux membres de votre équipe

Je vois quelques problèmes.

Le premier est qu'il semble que les «tâches» que vous avez soient trop importantes. Décomposez-les en morceaux plus petits - de préférence ceux qui devraient être terminés en une seule journée.

Ensuite, ne leur demandez pas de suivre le temps passé sur les tâches. Vous faites cela si les tâches sont réparties en fonction des attentes quotidiennes, cela devrait être facile pour vous et les progrès devraient être rapportés lors d'une réunion quotidienne. Pour la plupart, je suis d'accord avec Amy et HLGEM sur les employés qui déclarent cela; cependant, nous devons d'abord arriver à ce point.

La principale chose que je recherche ici est que si l'équipe ne peut pas correctement estimer les tâches qui durent plus d'une journée, nous devons la former. La meilleure façon d'y arriver est de leur demander d'estimer les petites tâches. Un avantage secondaire est que les gens soient enthousiastes à l'idée de montrer leurs progrès. Un autre est que si vous avez des personnes qui ne peuvent pas accomplir des tâches faciles à plusieurs reprises en une seule journée, vous savez qui remplacer. D'ailleurs, "créatif" ne veut pas dire "quand ils s'y mettent"

Une fois que vous leur avez permis de réaliser rapidement de petites tâches, commencez à passer à des tâches de plusieurs jours. À ce stade, ils devraient être en mesure de fournir de bien meilleures estimations que vous pouvez les retenir.

Il y a plus, mais je pense que c'est là que vous devez commencer.