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é! )
la source
Réponses:
"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.
la source
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.
la source
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 source