Les rapports quotidiens peuvent-ils diminuer la productivité d'un développeur? [fermé]

Dans une autre question , j'ai demandé pourquoi les développeurs n'aimaient pas la mêlée quotidienne . Nous avons parlé aux développeurs et nous avons décidé de ne pas organiser de mêlée quotidienne pendant un certain temps (pour faire un essai et une mêlée personnalisée lors de notre première tentative). C'est le résultat de la consultation directe des développeurs.

D'un autre côté, nous ne voulons pas perdre de bonnes parties de la mêlée quotidienne, comme avoir la chance de coordonner les développeurs tous les jours, ou regarder l'avancement du travail comme un indicateur de performance clé, pour prendre des mesures plus tôt.

Comme alternative à la mêlée quotidienne, nous pensons demander aux développeurs de fournir des rapports quotidiens avec les conditions suivantes:

1. Pas besoin de suivre un format spécifique. Chaque format est accepté.
2. Même si le travail n'est pas fait, nous voulons entendre la quantité de progrès.
3. Il n'est pas nécessaire de mentionner le temps consacré à chaque tâche.
4. Les obstacles au développement et les exigences de coordination doivent être mentionnés.
5. Il n'est pas nécessaire d'être obsédé par les rapports quotidiens. Ce n'est pas pris aussi strict.

Pensez-vous que cela peut diminuer leur productivité? Avez-vous eu une expérience de rapport quotidien? Avez-vous une suggestion à nous faire pour que nous puissions nous assurer que nous ne faisons pas de microgestion ?

Comme alternative à la mêlée quotidienne, nous pensons demander aux développeurs de fournir des rapports quotidiens avec les conditions suivantes:

Quelle idée terrible.

Pensez-vous que cela peut diminuer leur productivité?

Oui.

Pourquoi? Une présentation verbale lors d'une réunion combine l'écriture et n personnes "lisant" le rapport en une seule activité simultanée. Parler et écouter. Fini et fini. Les questions ont répondu immédiatement.

La rédaction d'un rapport est une perte de temps car il y aura des questions et vous devrez réviser le rapport avec des gens qui (a) ont des questions et (b) ne l'ont pas vraiment lu.

Les rapports quotidiens ne seront pas lus. Ils évoluent rapidement vers le bruit dans la boîte.

"Il n'est pas nécessaire d'être obsédé par les rapports quotidiens". Dans ce cas, pourquoi les faire?

Avez-vous une suggestion à nous faire pour que nous puissions nous assurer que nous ne faisons pas de microgestion?

Oui. Ayez un stand-up quotidien. Cela prend quelques minutes et vous avez terminé.

Si votre stand-up quotidien prend plus de quelques (15?) Minutes, vous partagez trop de détails et devez planifier des réunions distinctes pour ces détails. Les stand-up quotidiens sont faciles à faire. Après un résumé de 2 minutes, tout le reste est probablement des détails, pas pour toute l'équipe, et doit être poussé dans une réunion de suivi. La réunion passe à la concentration de la personne suivante pour la journée.

Je l'ai fait par le passé, mais le matin plutôt qu'en fin de journée. Cela prenait généralement moins de cinq minutes à remplir, donc non, je ne vois pas comment il y aurait une diminution de la productivité d'un développeur. La bonne chose à faire le matin, c'est que cela vous a fait réfléchir à ce que vous allez faire pour le reste de la journée.

Cela dit ...

Nous avons constaté que c'était plus souvent qu'autrement, ce n'était pas la méthode la plus efficace pour communiquer ce que nous avions fait la veille et ce que nous allions travailler ce jour-là. Pourquoi? Les gens ne les lisaient généralement pas. C'était une tâche Outlook planifiée, donc tout le monde les envoyait tous les jours, mais soit ils étaient passés sous silence, soit tout simplement manqués (à l'exception des pistes ou de la direction).

Nous avons constaté que les réunions quotidiennes étaient beaucoup plus utiles car les gens avaient tendance à s'écouter les uns les autres. De plus, s'il y avait un malentendu, il serait éliminé de temps en temps, ce qui est plus susceptible de se produire que quelqu'un répondant à un e-mail de statut quotidien pour poser d'autres questions.

En toute honnêteté, permettre à quiconque de se présenter sans contraintes semble un peu trop loin du côté libéral de l'équation. Là où je travaille, nous tournons en rond et chaque développeur donne ce qui suit:

1. Ce qui a été fait la veille. Pas tous les petits détails, mais dans l'ensemble.
   • Si ce qui précède n'est pas terminé, sinon, ce qui est nécessaire pour terminer et combien de temps cela prendra.
   • Si ce qui précède est terminé, quelle est la tâche suivante, ce qui est requis et le temps qu'il faudra.
2. Bloqueurs. Si vous travaillez sur Foo, qui dépend de Bar, et que Bar n'est pas terminé, cela doit être précisé.

La mise en place d'un schéma général que tout le monde doit suivre peut faciliter la lecture d'un rapport donné. Vous pouvez facilement configurer une méthode pour que tout le monde reçoive un e-mail avec les rapports quotidiens et permettre ainsi à quiconque de savoir ce qui se passe.

L'OMI tout type de réunion / rapport quotidien diminue la productivité car, pour être franc, ça pue la microgestion. Oui, je suis au courant de Scrum et autres et ceux-ci ne sont pas trop mauvais à condition qu'il s'agisse de courtes mises à jour de statut ("Hé, comment va Project X?"), Mais je crois fermement qu'il est insultant pour les développeurs professionnels de garder un œil sur nous à ce niveau bas; cela revient à utiliser des cartes de pointage pour nous assurer que nous sommes au bureau 8 heures par jour, ou à s'assurer qu'il n'y a pas de murs afin que vous puissiez espionner les ordinateurs des gens pour voir quelles fenêtres ils ont ouvertes à un moment donné.

Si vous devez garder un œil sur tout le monde pour vous assurer qu'ils fonctionnent, cela signifie que vous ne leur faites pas confiance. Si vous ne leur faites pas confiance, il y a un plus gros problème au travail que celui dont vous vous inquiétez.

Mon équipe fait de la mêlée depuis environ un an maintenant. Avant cela, nous avions deux réunions par semaine, au cours desquelles chaque membre de l'équipe a rendu compte de son activité au cours des 2 ou 3 derniers jours. Chaque réunion a duré entre 30 minutes et 1 heure. Au cas où nous aurions besoin d'échanger des informations et de coordonner notre travail, nous venions juste de parler à nos collègues et de leur parler (ce que nous faisons toujours, bien sûr).

Maintenant que nous faisons de la mêlée, nous avons souvent l'impression qu'une réunion par jour (même si elle ne dure que 15 minutes), c'est trop. Souvent, les rapports de certains membres se résument à: "Rien de nouveau depuis hier". Nous avons souvent eu l’impression que le schéma de 2 réunions par semaine était plus efficace.

Un autre inconvénient est que la réunion quotidienne est une interruption planifiée (voir par exemple l'article de Paul Graham , point 1. Évitez les distractions): puisque vous savez que l'interruption va se produire, vous n'allez pas commencer quelque chose de difficile avant la réunion (les réunions quotidiennes peuvent lieu une heure et demie après le début du travail).

Dernier point mais non des moindres, bien que les premiers retours aient des avantages ("Oh, vous travaillez sur ce problème, nous devrions en discuter!"), Il est parfois plus efficace de démarrer une discussion uniquement lorsque vous avez déjà organisé vos idées dans votre esprit. , vous avez des questions spécifiques et vous vous sentez prêt à discuter. Au lieu de cela, les rapports quotidiens peuvent rapidement provoquer beaucoup de remue-méninges inutiles et non structurés. Alors, méfiez-vous des retours trop tôt : cela peut vous embrouiller et vous ralentir.

Donc: dans certains cas, les rapports quotidiens ont diminué notre productivité. En moyenne, je n'ai pas l'impression qu'ils ont rendu notre travail plus efficace.

MISE À JOUR

J'ai écrit ma réponse originale il y a quelques années, et entre-temps, j'ai changé d'équipe. Dans mon équipe actuelle, nous organisons des réunions quotidiennes à la demande, c'est-à-dire lorsque nous estimons avoir besoin d'une courte mise à jour de l'état. Ainsi, chaque jour il y a la possibilité d'avoir une telle réunion mais nous ne le faisons pas si personne ne le demande. Nous avons une réunion rétrospective hebdomadaire. Ceci est fondamentalement très similaire à l'approche que nous utilisions à l'origine dans mon équipe précédente, non agile: réunions hebdomadaires fixes et réunions supplémentaires sur demande pendant le reste de la semaine.

Si ce que vous voulez vraiment, c'est un statut approximatif et pour noter les obstacles, le meilleur moyen est de leur demander un court "email de statut quotidien". Si vous y mettez trop l'accent ou faites une liste de ce qu'il devrait / ne devrait pas contenir, au moins certains de vos développeurs passeront plus de temps à le fabriquer pour répondre aux exigences. Au lieu de cela, demandez simplement un simple e-mail. Lorsque les choses arrivent tout au long de la journée, dites des choses comme "oh, mettez ça dans votre e-mail de fin de journée" et si vous recevez un e-mail de fin de journée très long, mentionnez nonchalamment "vous n'avez pas besoin d'être aussi détaillé chaque jour".

Il est très utile d'être clair sur le but de toute réunion ou rapport, en particulier celui qui est fait par tout le monde tous les jours. Vous dites que la raison est:

nous ne voulons pas perdre de bonnes parties de la mêlée quotidienne, comme avoir la chance de coordonner les développeurs tous les jours,

Qu'entendez-vous par coordonner les développeurs ? Quel type de travail nécessite une coordination et n'est-il pas coordonné de manière ad hoc par les développeurs et leurs gestionnaires en cas de besoin? Existe-t-il un moyen d'identifier les tâches qui nécessiteront une coordination et de communiquer uniquement dans ces cas?

ou regarder l'avancement du travail comme un indicateur de performance clé, pour prendre des mesures rapidement.

De nombreux bons KPI (comme le temps de réponse du site ou le nombre de bogues critiques) seront mesurables mécaniquement, et vous n'avez pas besoin d'imposer un coût aux développeurs pour le faire.

J'ai dû faire des rapports quotidiens dans plusieurs formats différents sur le lieu de travail. De manière générale, je pense que les rapports quotidiens ont tendance à n'ajouter de la valeur que pour les managers, pas pour les développeurs eux-mêmes. Alors que les gestionnaires tirent profit des rapports quotidiens en étant capables de dire l'état global de chaque projet et la charge de travail de chaque employé en peu de temps, d'après mon expérience, la plupart des développeurs ne prennent pas la peine de lire les rapports d'état des autres.

Cependant, il semble qu'en n'appliquant pas de format pour vos rapports quotidiens, vous rendiez les rapports plus difficiles à lire et à traiter pour les gestionnaires et les autres développeurs, exacerbant ainsi le problème de la perte de temps des développeurs.

Si vous décidez d'aller de l'avant avec des rapports quotidiens pour vos développeurs, puis-je suggérer d'utiliser un wiki interne au lieu de rapports par e-mail? De cette façon, vous ne spammez pas les boîtes de réception des personnes, tout en conservant l'historique des statuts quotidiens de chacun.

C'est une excellente idée de personnaliser vos méthodes Agiles pour qu'elles vous conviennent - alors bravo pour cela.

Donc, des rapports quotidiens à la place, je dirais que ce n'est pas beaucoup mieux qu'une réunion quotidienne, c'est toujours la même approche "dites-moi ce que vous faites", vous avez juste fait que tout le monde l'écrive au lieu de le parler.

Voici une approche alternative: au lieu d'utiliser ces techniques «d'interrogation» où vous demandez à chaque développeur son statut, vous utilisez plutôt une technique «push». Si le développeur n'a pas grand-chose à signaler, ils ne le font pas, ils doivent signaler tous les problèmes et les progrès à mesure qu'ils se produisent. Donc, quand ils terminent un module, ils doivent envoyer un e-mail à toute l'équipe que c'est terminé, que c'est dans SCM, où la documentation peut être trouvée, et un bref résumé de ce que c'est, comment cela fonctionne et / ou comment utiliser il. En cas de problème, ils doivent envoyer un e-mail à l'équipe pour demander des conseils, de l'aide ou des conseils. (ouais, tout comme au bon vieux temps où les équipes communiquaient bien sans la microgestion dont nous souffrons aujourd'hui)

vous constaterez que c'est beaucoup plus productif et constructif. Vous n'aurez pas de rapports inutiles pour eux et vous obtiendrez une équipe plus motivée car tout le monde aime informer ses pairs de leur travail.

Je conviens également que c'est une mauvaise idée de remplacer les stand-up quotidiens par un rapport. Un stand-up quotidien est un endroit idéal pour exprimer des idées et des problèmes. C'est l'une des raisons pour lesquelles j'aime le bon vieux tableau blanc (que nous utilisons aux côtés de Jira + Greenhopper). Le tableau blanc est un endroit où le groupe «se blottit» et partage des informations, tout est là, tout est visible, tout le monde bouge et change les collants sur lesquels il a travaillé, c'est aussi très amusant.

Vous ne pouvez pas extraire ces informations de vos autres outils?

• Sur quoi travailles-tu actuellement? Les billets que j'ai attribués.
• Quelle est votre progression? Pour les tickets dont la durée est supérieure à 1 jour, voir les commentaires dans le ticket ou valider les messages de la branche. Les billets que j'ai plus courts: probablement faits demain (vous ne faites pas de gros billets de 5 jours ou plus, oui?)
• Quelle est la progression générale? voir le ratio de tickets ouverts / fermés
• Que faut-il organiser? les tickets qui vous sont attribués en retour, avec les informations de statut nécessaires , et tout ce qui est discuté dans l'IRC de votre équipe, la salle de feu de camp, peu importe.

Lorsque vous avez des questions plus précises à répondre, je verrais la nécessité de rapports spécifiques, mais sans cela, vos rapports ressemblent un peu à une fin en soi.