Faites-leur participer. Présentez cela comme un problème à votre équipe: "Je suis loin de vous. Nous avons une fenêtre limitée dans laquelle nous pouvons communiquer pendant nos heures de travail respectives. J'ai besoin de savoir ce qui s'est passé dans votre journée afin de pouvoir vous aider. Pour Par exemple, nous avons récemment rencontré un bloqueur de build. Cela s'est produit quelques jours avant notre réunion d'équipe habituelle, et je ne l'ai découvert que lors de la réunion d'équipe. J'ai pu y remédier lorsque j'en ai eu connaissance. J'ai pu vous ont aidé plus tôt. Comment pouvons-nous éviter de tels problèmes à l'avenir? "

Tenez compte des problèmes culturels. Ils pourraient craindre que la publication d'informations dans un lieu public (par exemple, sur un wiki auquel n'importe qui dans l'entreprise puisse accéder) puisse mettre leur travail en péril s'ils admettent avoir des problèmes. Ils ne pouvaient pas vouloir perdre la face. Ils ne pouvaient pas vouloir donner une mauvaise image de leurs collègues. Ils ne peuvent pas vouloir admettre qu'ils vivent un problème parce qu'ils craignent que cela les rend incompétents. Réfléchissez à ce qui pourrait les bloquer autre qu'une simple allergie au «travail occupé» et proposez une stratégie qui répondra également à leurs besoins. Il se peut que vous n'obteniez pas votre page de statut, mais plutôt que vous la receviez par e-mail. C'est un peu plus difficile pour vous de voir en un coup d'œil, mais si cela vous donne les informations dont vous avez besoin, je suis sûr que vous pouvez faire un peu de travail de votre côté pour les rendre plus facilement utilisables par vous.

Donnez l'exemple. Quel que soit le statut quotidien que vous attendez d'eux, c'est probablement le statut quotidien qu'ils aimeraient de vous afin qu'ils aient un aperçu de ce qui se passe lorsque vous travaillez. "Nous avons rencontré un problème avec notre système de construction, alors j'en ai parlé avec le service informatique, et ils prévoient de déployer un correctif à 20 heures PT / 2 heures du matin. Vous devriez pouvoir construire demain matin."

Il semble que votre lieu commun soit essentiellement l'endroit où vous voulez que votre réunion de mêlée quotidienne ait lieu, et certaines personnes ne parlent pas (métaphoriquement) pendant la réunion. Encouragez-les à considérer cela comme une réunion de mêlée virtuelle et à donner une mise à jour rapide, même lorsqu'ils vérifient les choses.

S'il s'agit d'un endroit où TOUT LE MONDE écrit au moins une phrase sur son quotidien progrès, alors il sera plus apparent lorsque les gens ne contribuent pas (comme dans une mêlée). C'est un endroit où ils peuvent voir ce que font les autres (y compris vous). Et encouragez-les même s'ils n'écrivent qu'une seule phrase. Si cela a de la valeur, ce sera quelque chose qu'ils continueront à utiliser, peut-être plus en détail. Si cela n'a de valeur pour personne d'autre que vous, alors cela peut encore être nécessaire, si la valeur pour vous est supérieure à la douleur pour tous ensemble. Mais, s'il ne s'agit que d'une phrase (au moins pour commencer), un simple statut de mêlée, il ne devrait vraiment pas y avoir autant de douleur.

Mais, vous devrez leur parler à nouveau, faites-le remarquer la valeur qu'il vous apporte et demandez-leur s'ils ont des idées qui l'aideront également à leur apporter de la valeur. Poussez-le comme une mêlée virtuelle quotidienne où tout le monde contribue, ne serait-ce que brièvement.

Je soupçonne que cela peut aider toute l'équipe à mieux travailler ensemble, à résoudre les problèmes les uns des autres plus rapidement, tout comme dans une bonne mêlée. Si tel est le cas, cela apportera de la valeur à toute l'équipe.

Il ne semble pas que votre équipe ait de réelles objections à faire des mises à jour. On dirait plus que l'équipe néglige de faire des mises à jour et que vous voulez leur rappeler sans les harceler. Cela pourrait aider si les membres de l'équipe recevaient une notification récurrente non intrusive de quelque nature que ce soit qui incite à penser: "Oh, il est temps de faire ma mise à jour aujourd'hui."

Mon équipe gère cela avec des e-mails à chaque équipe membre lorsque quelqu'un publie sa mise à jour quotidienne. Lorsqu'une personne publie, cela rappelle à tout le monde de publier également. Si vous faites d'abord votre mise à jour quotidienne, toute l'équipe sera toujours rappelée.

Une autre option consisterait à mettre 5 minutes sur leurs calendriers pour "l'heure de mise à jour" ou quelque chose de similaire. Le voir sur l'agenda tous les jours leur rappellera de faire des mises à jour.

Se souvenir d'accomplir des tâches banales peut être difficile. J'essaierais d'intégrer cela dans le système.

1) Je ferais de mon mieux pour m'assurer que tout le travail est associé à une tâche (JIRA dans ce cas). Cela permet de suivre toute la progression de la tâche.

2) Rendre les commentaires «commit» obligatoires. Si vous n'attendez qu'un court message, cela devrait suffire à ce qui s'est passé. Les développeurs ne devraient pas avoir de longues périodes entre les validations, cela devrait donc être satisfaisant pour la plupart des jours.

Dans le cas où un développeur est affecté à une tâche et qu'il n'a pas commis de changements pendant une journée, alors l'hypothèse devrait être quelque chose ne va pas; la tâche est trop importante, ils ont frappé un barrage routier, etc. Cela devrait être un signal d'alarme et vous donner la possibilité de contacter individuellement le développeur pour déterminer quel est son problème.

D'après mon expérience ( en tant que développeur) les tâches de «liste de contrôle» manuelles sont les plus difficiles à réaliser. Même si cela ne prend que peu de temps pour terminer cette tâche, la tâche elle-même est très intrusive dans le processus de bien de vos développeurs.

Lorsqu'ils sont intégrés au système d'une manière ou d'une autre, ils sont bien plus organique pour compléter et se sentir moins intrusif. Travaillez à améliorer la communication de manière systémique plutôt que d'espérer que vous, les développeurs, vous souviendrez de remplir une mise à jour banale.

D'un point de vue Agile:

Implémentez une réunion quotidienne Scrum debout ... à distance Obtenez une ligne de conférence ou des webcams et organisez une réunion quotidienne:

Qu'avez-vous fait?

Sur quoi travaillez-vous aujourd'hui?

Des bloqueurs ?

Maintenant, à propos du décalage horaire: vous allez devoir trouver un compromis ici, il y a sûrement 15 minutes qui se chevauchent quelque part pour que vous parliez tous.

Voir comme vous aurez un tour de parole tous les jours, vous pourrez mettre l'accent sur vos préoccupations et demander des comptes aux gens.

À toutes les autres bonnes réponses, j'ajouterais que l'utilisation d'un bon outil de gestion de projet partagé comme Trello, Jira ou Pivotal Tracker peut être d'une grande aide. Cela permet aux développeurs de se concentrer sur les tickets, les bugs, les tâches, etc. et les aide à gérer leur propre travail.
Mon préféré est Pivotal Tracker qui l'a utilisé dans plusieurs organisations ainsi que dans des projets personnels.
Alors il pourrait être une tâche distincte de résumer à partir d'un tel outil pour mettre à jour l'emplacement / le document dont vous avez besoin, mais cette étape pourrait maintenant être plus facile pour 1 personne (vous) lorsque vous pouvez tout faire en passant au peigne fin tous les e-mails que vous êtes automatiquement cc ' d à propos de l'outil.

Vous êtes le chef d'équipe. Demain, vous vérifiez qui n’a pas envoyé ses notes, vous les appelez et vous demandez pourquoi ils ne l’ont pas fait. Dites-leur que c'est important pour vous. Dites-leur de mettre une alarme dans leur calendrier dix minutes avant l'échéance des notes.

Si vous devez les appeler une deuxième fois et qu’ils n’ont pas d’alarme, demandez-leur de la régler maintenant, pendant que vous êtes au téléphone. Si vous devez appeler une troisième fois, vous leur informez que cela sera reflété dans leur évaluation des performances.

Ils font la partie difficile ( excellent code ) mais il manque la partie facile (éd.: communication ).

(c'est moi qui souligne)

C'est votre point de vue. Je suis sûr que pour de nombreux développeurs, ce qui est "facile" et ce qui est "difficile" n'est pas la même chose que ce qui est "facile" et "difficile" pour vous.

Parlant du point de vue d'un programmeur travaillant dans un environnement distant, écrire une telle mise à jour quotidienne peut sembler vraiment inutile. Utilisez git log pour voir ce que j'ai fait, et si j'ai des problèmes / questions, je vous les poserai directement, non? Et si vous, en tant que responsable, avez besoin que je vous dise ce qui se passe, alors demandez simplement [0].

En d'autres termes, il semble que vous avez déjà demandé à votre équipe - plus d'une fois, apparemment - et ils ont répondu tacitement. Vous devriez peut-être essayer d'attaquer le problème sous un autre angle. Et, en tant que responsable, vous devriez peut-être être prêt à faire un suivi individuel avec les membres de l'équipe de leurs progrès dans le cadre du flux de travail normal.

[0] Vous avez mentionné le décalage horaire. Il y a probablement encore des chevauchements (sinon, cela devrait être introduit, l'OMI est très important pour une communication réussie lorsque vous travaillez à distance).

Mise à jour n ° 0: Sur mon lieu de travail, nous utilisons un système à trois composants, qui semble plutôt bien fonctionner:

• Les réunions bihebdomadaires servent de jalons et permettent à la direction d'évaluer et d'estimer.
• Nous utilisez un système de gestion de projet similaire à Jira et nous nous assurons d'avoir un ticket pour toute tâche sur laquelle on pourrait travailler - cela aide à suivre l'activité des personnes.
• Tous les problèmes en cours (tels que les accidents de production, les correctifs urgents, etc.) font l'objet d'un suivi plus ou moins individuel par des moyens informels.

Mise à jour # 1: demandez-vous si, en fait, vous essayez de micro -gérer vos développeurs. Si quelqu'un n'accomplit pas ce que l'on attend d'eux, vous devriez lui poser la question de le renvoyer. La microgestion, cependant, n'est pas la solution. Il y a quelques commentaires intéressants sur le sujet sur ce message d'Ian Bicking.

Mise à jour n ° 2: voici une collection de bons points qui expliquent mon idée d'une manière plus éloquente: 44 leçons de gestion de l'ingénierie. Espérons que quelqu'un ayant la même question que OP la trouvera digne d'être lue (pour son bien et celui de son équipe).

Il y a deux leçons pertinentes:

• Embauchez des gens formidables, puis faites-leur entièrement confiance. Évaluez les performances sur une base mensuelle ou trimestrielle, puis déclenchez si nécessaire. N'évaluez pas les gens quotidiennement, cela rendra tout le monde fou (y compris vous).

• Appliquez des normes de comportement et de performance. Feu les intimidateurs et les sous-performants.

Vous demandez comment faire faire à votre équipe ce que vous voulez. Peut-être devriez-vous plutôt demander si votre demande est une pratique de gestion sensée dans le monde du génie logiciel. Pardonnez-moi ma franchise, mais gérer les membres de l’équipe sous-performants en exigeant une évaluation quotidienne de tout le monde probablement ne l’est pas.