Existe-t-il un facteur de relation entre le temps de réunion et le gain de temps de développement?


10

Je travaille sur un projet et nous avons des réunions informelles régulières (généralement hebdomadaires), où nous discutons de l'état du projet et de son interface graphique.

Je suis le seul développeur là-bas, les 4-5 autres personnes ont une formation non informatique.

Cette réunion a pris beaucoup plus de temps que d'habitude, mais à un moment donné, un de mes collègues a posé des questions sur certains domaines du programme et comment les remplir. J'ai répondu et au cours de la discussion, j'ai remarqué que je me suis totalement trompé de processus.

Mais puisque nous en avons parlé et trouvé l'erreur au préalable, je peux la changer assez rapidement.

En y réfléchissant, je me suis demandé s'il y avait un facteur entre le temps de réunion pour gagner du temps de développement?

Par exemple, 1 minute de temps de réunion peut économiser X minutes de temps de développement.

Si oui, cela aiderait à définir, à quelle fréquence et combien de temps nos réunions devraient être.

(Juste pour clarifier: je ne veux pas faire de meilleures réunions, même être en mesure de déterminer à peu près la durée des réunions est facultatif. Je suis surtout intéressé s'il y a une relation entre le temps de réunion et le temps de développement! Ma raison de demander: la curiosité! )


Dans quelle mesure pouvez-vous comprendre et confirmer votre compréhension lors des réunions par rapport aux autres méthodes?
JeffO

@JeffO: De quelles autres méthodes parlez-vous?
hamena314

Je dirais que "je pensais avoir compris une exigence mais j'ai découvert lors d'une réunion que j'avais tort" ne devrait pas signifier que vous devez avoir plus de réunions, mais que votre organisation doit améliorer son processus de définition des exigences (oui, je sais que cela est plus facile à dire que le faire).
SJuan76

Après plusieurs millions d'années d'évolution, l'homme échoue encore gravement sur la communication. Le succès de toute réunion dépend des compétences de communication des participants. Aussi la «capacité» de compréhension. La même réunion portée par un bon communicateur peut vous faire gagner beaucoup de temps et la même réunion portée par quelqu'un comme mon chef de projet actuel va vous faire perdre votre temps. Et beaucoup d'argent pour l'entreprise. OMI, il n'y a aucun facteur.
Laiv

Recevez-vous d'autres documents, diagrammes, e-mails ou autres réunions / sessions individuelles?
JeffO

Réponses:


14

"Tant qu'ils doivent l'être, et non plus."

La chose à réaliser ici est que le temps de réunion pour gagner du temps de développement n'est en aucune façon linéaire. Pour votre équipe, pour votre entreprise, pour ce sujet, alors 1 heure de réunions pourrait économiser 2 heures de travail de développement. Si vous disposez de 10 heures de réunions, une autre heure de réunions peut économiser 0 travail de développement. Enfer, cela peut vous faire économiser -2 heures de travail de développement en raison d'interruptions ou d'un impact sur le moral.

En fin de compte, tout l'intérêt des réunions est que la communication et la collaboration vous aident à faire avancer les choses. Si les réunions ne vous aident pas à faire avancer les choses, alors elles devraient être tuées.


6

Pas exactement.

Comprendre le client / acteur peut faire gagner du temps de développement. Et les conversations doivent être suffisamment longues pour faciliter la compréhension. Mais discuter d'une fonctionnalité que vous présumez déjà comprendre n'améliorera pas nécessairement votre compréhension.

Si personne dans la salle ne soupçonne d’incompréhension ou de fausses hypothèses, quittez la pièce. Prolonger artificiellement une "discussion" dans l'espoir que le temps de cisaillement et la pression pousseront un conflit à sortir et créeront une harmonie sont désespérés et démoralisants.

Et rappelez-vous que la communication est une combinaison de compétence et de chance; la discussion n'implique pas nécessairement la communication (compréhension mutuelle). Vous serez tous mieux à même d'exposer de mauvaises hypothèses plus vous travaillez longtemps sur le terrain et plus vous travaillez ensemble.

En attendant, «l'agilité» peut être utile.

Gardez les réunions «courtes» et implémentez des interfaces utilisateur ou des maquettes brutes dès que possible après chaque réunion - bien avant de soupçonner d'avoir une compréhension complète. Vos interfaces utilisateur / simulations serviront de matériel pour clarifier les malentendus. Le temps entre les réunions aidera tout le monde à décompresser et à réfléchir sur ce qui a été dit. Et si vous implémentez votre matériel de démonstration dans le code , vous avez également commencé le développement. (Et vos clients / collègues seront ravis d'entendre cela!)

Et le pire des cas, lorsque vous avez implémenté un petit morceau de code visible : vous êtes totalement hors de la base et vous le jetez. Mais, si vous avez seulement consacré un peu de temps, l'investissement est rentable grande à clarifier grossière incompréhension.

Et rappelez-vous, la société ne se soucie pas du temps de développement ; il se soucie juste du temps-personne . (Comme moyen de calculer le coût total , faites attention à vous.) Donc, vous devez rechercher l'équilibre dans lequel le temps-personne est minimisé; pas de temps passé à écrire du code.


3

Je ne pense pas qu'il y ait une sorte de corrélation qui pourrait être généralement appliquée. Cela dépend vraiment de la réunion et des choses que vous faites là-bas qui se rapportent au développement.

Dans la situation que vous décrivez, vous êtes passé en quelques minutes d'une exigence mauvaise ou mal comprise à une meilleure. Nous savons que le fait d'avoir de bonnes exigences a un impact direct sur le temps de développement.

Mais que faire si votre réunion ressemblait à une réunion sur le statut de l'entreprise. Vous partagez de bonnes informations pour savoir comment se porte l'entreprise, être au courant d'autres choses, etc. Mais, pour la plupart, cela n'aura aucun effet sur le temps de développement de votre projet. Tout ce temps est "gaspillé" quand on le regarde dans une perspective de développement.

Une fois que vous avez dû aller à suffisamment de réunions, vous commencez à réaliser que certaines sont vraiment productives (par exemple, prenez une petite équipe de développement et un bon ensemble d'exigences et commencez à mettre en tableau blanc une architecture. Vous pouvez faire beaucoup si vous restez concentré .). Vous en trouvez également qui ne sont pas du tout productifs ou qui ont même une productivité négative (une fois, un client a eu un débat de 15 minutes entre quelques-uns sur la question de savoir si une page de connexion doit dire "Connexion" ou "Connexion". fin de cela, personne ne le savait et il a fallu le déposer plus tard).

TL / DR: dépend de la réunion, des personnes et des objectifs de la réunion.


La partie "Log In | On" sonne comme un cyclisme
hamena314
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.