Comment pouvez-vous suivre ce que vous et votre équipe travaillez au quotidien?
Je n'arrive pas à savoir ce que moi et les membres de mon équipe font réellement chaque jour. J'obtiens une bonne vue d'ensemble en passant en revue les fiches remplies chaque semaine et les stand-ups aident un peu, mais j'ai l'impression que je n'ai pas une bonne maîtrise du fonctionnement quotidien de mon équipe. Les cartes resteront en cours pendant des jours sans mise à jour au stand-up quotidien, et certains ingénieurs sont que mon équipe n'est pas la plus communicative.
J'ai pensé à mettre en place une sorte d'enregistrement quotidien que tout le monde remplit (via une liste de diffusion ou un document google partagé) mais cela semble assez lourd et manuel.
La surveillance de l'activité de GitHub fait un travail correct mais peut être un peu écrasante avec le nombre d'e-mails qu'il envoie quotidiennement. J'ai pensé à essayer de construire un système de résumé pour cela, mais je n'ai pas le temps à perdre.
Quelles stratégies avez-vous mises en œuvre pour rester au fait de ce que votre équipe fait au quotidien afin que vous puissiez mesurer le travail sur les tâches "en cours"?
je leur parle.
La technologie ne peut pas résoudre les problèmes sociaux. Vous avez de courtes séances de matinée. Qu'est-ce que vous avez fait hier? Que vas-tu faire aujourd'hui? Des obstacles?
Si quelque chose semble louche (ou je suis curieux), je m'arrête et pose des questions: "Vous travailliez sur XYZ hier, comment ça s'est passé?". Cela oblige les gens à faire attention et à réellement savoir ce qui se passe. Cela vous permet également de garder la tête de l'équipe dans la boucle (et de faire attention, et de savoir réellement ce qui se passe). Ce a besoin pour être à l'heure et court (10 minutes max ). Rien d'autre et les gens ne "suspendent" pas le travail. Ils s'arrêteront et attendront le standup, puis prendront le temps de recommencer. Certains le feront de toute façon, mais c'est largement inévitable.
Puis je m'arrête au bureau de tout le monde dans l'après-midi. Pas tous les après-midi (bien que cela puisse être plus que chaque après-midi pour les nouvelles personnes), pas en même temps, mais à peu près à la même heure (c'est donc à la fois informel et régulier). "Des problèmes? Des obstacles?"
Vous serez surpris de la fréquence à laquelle vous rencontrerez des problèmes lorsque les gens sont un à un.
Si les gens n'ont aucun problème, tant mieux; retourne travailler. S'ils n'ont pas de problèmes toute la semaine ? Problème. Vous ne les défiez pas suffisamment ou ils ne s'ouvrent pas. Demandez comment va XYZ (qu'ils ont mentionné dans standup). Faites-leur expliquer les choses.
Ce n'est pas de la microgestion. Vous ne leur dites pas comment faire leur travail. Vous ne les gardez pas. Vous êtes là pour éliminer les obstacles de leur vie quotidienne. Vous avez besoin d'informations pour cela. Tant que vous gardez votre équipe hors des réunions et les chefs de projet hors de leurs cubes, une personne qui s'arrête pour aider une fois par jour ne va pas leur causer de la peine. Mais toutes ces interactions doivent provenir de la veine "Je suis là pour vous aider".
Une autre chose que je ferai est d'examiner les ensembles de modifications (par moi-même, de manière informelle). Je peux alors voir à quelle fréquence les gens s'enregistrent, quelle est la taille de leurs changements, comment cela correspond à ce qu'ils ont signalé, à quelle fréquence ils refont les choses, combien de corrections de bogues ils ont, etc. Un élément de travail qui passe du statut à "terminé" n'a presque aucun sens. Regardez le code. Semble-t-il fait?
note: Un point extrêmement grave: quelle est la taille de votre équipe? Est-ce plus de 7 personnes? Bien sûr, vous ne pourrez pas suivre tout ce qui se passe si votre équipe est trop grande.
Ne micro-gérez pas vos développeurs!
Le développement de logiciels productifs nécessite de longues périodes d'effort mental concentré. Il n'est pas réaliste de s'attendre à ce qu'ils produisent une sortie constante. Si vous commencez à les mesurer quotidiennement, ils restructureront leur travail afin qu'ils produisent toujours des artefacts discernables que vous pourrez voir chaque jour. Cela peut ou non avoir un impact positif sur la qualité de votre logiciel. Cela aura presque certainement un impact négatif sur l'efficacité de vos développeurs.
Comme suggère Robert Harvey , ne gérez pas micro votre équipe. Donnez à l'équipe des tâches prioritaires avec une valeur commerciale concrète et laissez votre équipe trouver le meilleur moyen de fournir cette valeur commerciale.
Si l'équipe offre une valeur commerciale, vous devriez être heureux. La manière dont ils s'assurent de fournir les fonctionnalités demandées devrait leur appartenir.
Toutefois:
Les cartes resteront en cours pendant des jours sans mise à jour au stand-up quotidien
Cela pourrait indiquer qu'il y a une lacune dans le processus.
Ce pourrait être l'équipe qui ne fonctionne pas vraiment en équipe, et qui n'intervient pas pour s'entraider lorsqu'elle est coincée. Cela pourrait aussi être la communication avec l'entreprise. Les tâches sont trop importantes, il devient donc difficile de déterminer ce qui est nécessaire. Les spécifications ne sont pas claires.
Il se pourrait également qu'il n'y ait aucun problème réel. Peut-être que l'équipe fonctionne très bien avec des cartes représentant des travaux majeurs qui prennent des jours à terminer, et peut-être que l'équipe travaille bien pour y parvenir.
Je pense qu'il est valable d'utiliser la rétrospective comme une plate-forme pour exprimer votre préoccupation. Parfois, c'est une bonne chose de recevoir des observations de l'extérieur.
Mais laissez l'équipe déterminer s'il y a un problème et quelle en est la cause. Et soyez prêt à accepter que vous deviez peut-être ajuster la façon dont les tâches sont livrées à l'équipe.
N'oubliez pas que le stand up quotidien est un outil pour l'équipe pour l'aider à organiser le travail; ce n'est PAS un outil permettant aux gestionnaires de suivre ce que fait l'équipe.
"Messagerie push" et non "messagerie pull"
Un développeur se rendra souvent dans l'un des états suivants qui vous importent:
- Yaaay, j'ai fait X!
- Je travaille sur X, mais il semble que cela prendra un certain temps ...
- Je suis bloqué sur le problème Y, je fais des recherches mais je pourrais avoir besoin de conseils;
- Je suis bloqué car j'attends A, B et C.
Idéalement, vous souhaitez disposer d'informations raisonnablement à jour sur ces statuts sans perturber la productivité réelle. Constant "Sommes-nous encore là?" est contre-productif, mais il se peut que vous puissiez faire quelque chose d'utile pour les états 2-4, vous devez donc en être informé.
Ce qui fonctionnera, c'est une culture de la "messagerie push", de préférence de manière automatisée. Vous n'aurez peut-être pas besoin de consulter l'intégralité du journal de validation, mais vous pouvez créer un "tableau de bord" où vous verrez le dernier commit ou le dernier ticket résolu (pour les bogues ou les fonctionnalités) de chaque membre de l'équipe. Pour le reste des situations, vous pouvez les amener à vous envoyer un e-mail de manière proactive avec de telles mises à jour (j'espère qu'elles sont plus rares que les validations) ou aller leur demander si vous ne voyez pas de progrès continus sur n'importe quel tableau de bord - si vous avez un accord interne selon lequel le blocage doit être relevé (il se peut qu'une fonctionnalité ne soit pas nécessaire s'il s'avère que cela coûte 80 heures et non 8 heures), alors soit ils vous tiendront au courant, soit vous dérangeront.
Alternativement, vous pouvez créer une culture de quelque chose comme https://idonethis.com/ des rapports quotidiens envoyés à toute l'équipe - cela garantira que les autres sont également sur la même page.
Une alternative à certaines des autres réponses (axées sur la communication) est que peut-être les tâches sur vos fiches peuvent être divisées en petits morceaux sur lesquelles vous pourrez alors obtenir des commentaires plus tôt.
Avec des pièces plus petites, l'équipe se sent comme si elle accomplit quelque chose tous les jours qui devrait se refléter dans le stand-up.
L'inconvénient est que ces cartes distinctes dépendront probablement beaucoup les unes des autres. Une équipe capable de communiquer très facilement les uns avec les autres est bénéfique ici, ou les pièces peuvent ne pas se combiner aussi bien qu'elles le devraient. Vous devrez peut-être également conserver certaines des cartes si vous avez besoin de faire certaines choses en premier.
Cela étant dit, les gens seront toujours bloqués ou découvrir qu'une tâche est beaucoup plus difficile qu'ils ne le prévoyaient de temps en temps. C'est pourquoi il est toujours utile de discuter ouvertement des problèmes dans le stand-up où d'autres peuvent offrir des conseils sans juger la personne qui a des problèmes.
Pour répondre au problème de la micro-gestion comme certaines des autres réponses l'ont soulevé: même si les gens accomplissent de petites tâches chaque jour, il faudra vue plus large de leur travail accompli pour avoir une idée de combien chaque personne se fait réellement, plutôt que de les juger par leurs réalisations quotidiennes.
Je suggère cela parce que je travaille dans une équipe de 8 personnes, où la communication est très facile et les gens sont très accessibles. On nous confie des tâches qui ne devraient jamais prendre plus de deux jours de travail. Parfois, ces tâches sont étroitement liées et nous devons nous tenir mutuellement au courant de la façon dont nous réalisons chacun notre travail. Nous sommes chacun responsables de signaler ce que nous avons accompli toutes les deux semaines à notre responsable.
Après avoir relu la question, je me rends compte que vous demandez peut-être cela en tant que membre de l'équipe, pas en tant que leader, et donc vous ne pouvez pas avoir le contrôle sur vos tâches.
- Vous pourriez suggérer à votre leader de diviser davantage les tâches
- Si votre travail est bloqué ou dépend du travail d'un autre membre de l'équipe, n'hésitez pas à le vérifier et à effectuer une tâche différente si vous en avez besoin.
Tout d'abord, vous devez vous analyser en termes de temps et de compétences. Si vous êtes un technicien avec une expérience pratique antérieure, les choses peuvent différer de celles au cas où vous êtes juste un manager (pas avec de solides connaissances techniques sur ce que sont vos développeurs travaille actuellement sur) qui doit seulement s'assurer que les délais sont respectés.
Le point commun dans les deux cas, c'est que vous devez être en mesure de faciliter votre équipe et de créer un sentiment de confiance. Vous ne jugez pas leur performance mais essayez d'être empathique et utile pour rendre leur expérience amusante et facile.
Supposons maintenant que vous êtes juste un gestionnaire comme je l'ai dit ci-dessus, dans ce cas, même si un développeur est vraiment confronté à un problème sérieux de développement, vous ne pourrez peut-être pas l'aider. Le problème réel peut prendre du temps et nécessitera également une concentration. En supposant en outre que le développeur soit vraiment sincère dans son travail et qu'il paie à temps plein (voire du temps supplémentaire) pour résoudre ce problème, mais malheureusement toujours pas en mesure de le résoudre. Et dans une telle situation (lorsque vous n'êtes même pas en mesure de comprendre pleinement le problème), vous continuez à poser des questions sur le problème en faisant des progrès tous les jours et même de manière informelle deux fois par jour. Le résultat serait une frustration et une perturbation extrêmes pour le développeur. Que ce soit une application pour recueillir des progrès quotidiens ou une réunion de stand-up quotidienne, les deux peuvent être frustrants.
D'un autre côté, en gardant tous les autres facteurs identiques, supposez simplement que vous avez une solide formation technique et que vous avez travaillé sur les mêmes technologies dans le passé. Dans ce cas, prendre des progrès quotidiens ou avoir des réunions debout est vraiment utile. Les développeurs auront sûrement confiance en vous et en votre expertise et seront à l'aise pour discuter du grand défi auquel ils sont confrontés. Vous fournirez quelques suggestions qui peuvent être utiles ou même si elles ne le sont pas directement, elles vous aideront à proposer des approches alternatives.
Cependant, dans tous les cas les réunions quotidiennes de stand-up doivent créer le sentiment que vous êtes un membre de l'équipe et non un chef/lead/manager. À moins que les membres de votre équipe ne vous considèrent au même niveau qu'eux, ils ne seront pas en mesure de communiquer leurs préoccupations/suggestions/problèmes/commentaires, etc.
n autre point à considérer est la taille de votre équipe et le temps dont vous disposez pour les gérer, avant de penser à utiliser un logiciel de suivi de progression automatisé ou d'augmenter votre interaction. Vous devez vous assurer que quelles que soient les préoccupations soulevées par votre équipe, vous êtes en mesure de les résoudre dès que possible. Un facteur démotivant majeur pour un membre de l'équipe est que ses préoccupations/suggestions/commentaires ne sont pas pris au sérieux ou ne sont pas valorisés. Connaître les progrès quotidiens est important, mais uniquement si vous êtes pleinement impliqué dans le travail d'équipe. Si vous êtes également impliqué dans certaines entreprises parallèles, n'essayez pas d'interagir davantage avec votre équipe. Pensez à une situation dans laquelle la réponse de votre équipe est écrasante et elle soumet ses tâches bien avant l'heure, ce qui soulève des préoccupations et des questions, mais vous n'êtes pas en mesure de fournir des commentaires et des critiques en temps opportun. Dans une telle situation, votre influence en tant que chef d'équipe sera considérablement réduite
Créez et faites bon usage de diverses salles de chat IM pour les différentes configurations. Certains peuvent être larges comme @engineers et certains peuvent être spécifiques tels que @newFeatureA
Envisagez de faire un standup quotidien en incluant un examen des billets en vol.
Utilisez un environnement ouvert qui prend en charge la collaboration et assurez-vous que QE et le propriétaire du produit principal se trouvent au milieu des développeurs. Vous entendrez beaucoup et vous vous ferez une idée en voyant des écrans autour de vous.
Comme le souligne Robert, il ne s'agit surtout pas de microgestion (notez l'utilisation de `` être vu '', c'est-à-dire quelle que soit votre intention réelle).
En fin de compte, nous suivons ce qui est accompli au fil du temps et voyons quelle est notre vitesse à partir de cela. Se concentrer sur les progrès au cours de la journée est contre-productif car les gens vont se démoraliser et/ou partir.
Je suis surpris que personne ici n'ait encore mentionné la messagerie de référentiel "suivie" ou "étoilée" intégrée à des systèmes comme GitHub ou BitBucket.
Nos intervenants techniques (chefs de projet, responsables développement et support) suivent tous notre problématique et engagent des historiques de mise à jour sur leurs projets concernés. Nous avons une petite équipe (15 ETP + contractants), mais cela semble fonctionner pour nous
Personne n'est mesuré sur aucune de ces choses, mais en plus des rapports de situation hebdomadaires des PM, cela donne une vue quotidienne du projet pour au moins garder tout le monde au courant des domaines sur lesquels on travaille afin que personne ne manque de visibilité.
Cela a également contribué à accroître la transparence entre les développeurs et les sous-traitants et nos liaisons commerciales, ce qui aide tout le monde à être responsable de leurs calendriers de livrables.
Lorsqu'il est combiné avec des flux RSS associés à des référentiels spécifiques ou dans l'ensemble de notre organisation, nous avons été en mesure de limiter les e-mails (là où ils le souhaitaient) et d'offrir un ensemble de données similaire en temps réel et en résumé via des lecteurs RSS. Pour certains utilisateurs, il s'agit d'Outlook, il s'agit donc essentiellement d'un courrier électronique pour eux, bien que légèrement différent, mais pour d'autres utilisateurs, ils utilisent un client RSS à part entière avec tout le filtrage supplémentaire dont ils ont besoin pour le personnaliser en fonction de leurs besoins exacts.
Nous avons rencontré des préoccupations similaires au sujet du volume des e-mails au début, mais nos utilisateurs finaux sont arrivés avec le système RSS sans que l'Organisme d'ingénierie n'ait à faire beaucoup plus que de proposer des clients pour ceux qui n'utilisent pas Outlook. A travaillé pour nous, encore une fois autour de 20-30 ETP + entrepreneurs tout au long de l'année dans plusieurs bureaux et fuseaux horaires. YMMV, évidemment.
C'est un ajout très marginal (et ce n'est pas spécifique au programmeur), mais j'ai eu un bon succès avec Asana dans les projets récents.
Pour l'intégration avec les outils de collaboration en ligne existants, ne cherchez pas plus loin que Slack . Il est construit autour d'un salon de discussion, mais il sert de hub assez minimaliste pour d'autres outils , notamment Asana, GitHub et Bitbucket. Il a une collection décente de ces "intégrations", à la fois pré-faites et faites par la communauté , en utilisant l'API qui bien sûr vous permet de construire la vôtre.