Réussir avec le développement à distance


L’une des situations les plus courantes aujourd’hui est celle où le chef de produit se trouve dans un seul endroit et l’équipe d’ingénierie est ailleurs. Je ne parle pas seulement de l’externalisation en Inde non plus – l’équipe de développement à distance peut être la conséquence d’une acquisition ou d’une fusion, ou peut-être que votre organisation est suffisamment grande lorsque les développeurs sont situés au centre d’une installation quelque part où vous n’êtes pas.

Lorsque les développeurs ne sont pas assis juste à côté de vous, tous les défis normaux de communication et d’exécution sont amplifiés, souvent au point où de nombreuses équipes sont extrêmement frustrées par le développement à distance, et certaines contestent les avantages des économies de coûts perçues.

J’ai écrit plus tôt sur certains des problèmes liés à l’externalisation pour les mauvaises raisons, mais quelle qu’en soit la cause, si vous vous trouvez avec une équipe de développement à distance, vous pouvez faire trois choses essentielles pour améliorer considérablement vos chances de succès:

1) Plus l’équipe est éloignée de vous, et plus les défis de communication liés à la langue, à la culture et aux fuseaux horaires sont nombreux, plus il y a de pression pour vous assurer que vous avez fait un très bon travail sur les spécifications du produit. Le projet cauchemar est celui où le chef de produit n’est pas sûr de ce qu’il veut construire (ou continue de changer d’avis) et l’équipe d’ingénierie à distance se débat. C’est comme être du mauvais côté d’un fouet. Dans le dernier article, j’ai écrit sur l’importance d’un prototype haute fidélité comme base de la spécification du produit. Je n’en répéterai pas toutes les raisons ici, mais il suffit de dire que si votre équipe est distante, vous voulez absolument vous assurer d’utiliser le prototype haute fidélité comme principal mécanisme de communication. À la fois pour communiquer la spécification réelle et pour communiquer les changements. Les documents écrits sont suffisamment difficiles pour que les gens les lisent, mais s’ils sont écrits dans une langue qui n’est pas native, et si vous n’avez pas l’auteur dans le cube au bout du couloir pour vous interpréter, vous demandez simplement pour de gros ennuis.

2) Lorsqu’une équipe de développement est locale, s’il y a des conflits de ressources (par exemple, deux gestionnaires différents donnent des instructions contradictoires), cela est généralement détecté rapidement et résolu. Avec les équipes distantes, vous finissez par avoir beaucoup de mauvaises surprises, et des mois peuvent s’écouler littéralement avant que les déconnexions ne soient identifiées. Ceci est généralement dû au fait que les développeurs distants sont obligés de faire des hypothèses sur qui voulait quoi et comment interpréter les différentes instructions, et les hypothèses sont rarement correctes. Il est essentiel que quelqu’un local gère toute la coordination avec l’équipe distante. Cela ne signifie pas que toutes les communications doivent passer par cette personne, mais il ne devrait pas y avoir de question de savoir à qui l’équipe d’ingénierie est responsable. Parfois, il s’agit d’un chef de projet (alias chef de programme) et parfois d’un directeur ou d’un vice-président de l’ingénierie basé localement (près du chef de produit).

3) Il y a tellement de bons mécanismes de communication maintenant. En plus du courrier électronique et de la messagerie instantanée, la vidéoconférence est bien meilleure et la VoIP a réduit les coûts des appels internationaux. Cela dit, il n’y a toujours pas de substitut à l’établissement de relations personnelles. Au moins une fois par trimestre, le chef de produit doit se rendre à l’équipe d’ingénierie, rencontrer les principaux architectes et gestionnaires et passer du temps de qualité en face à face. Cela améliorera toutes les autres formes de communication. Une autre excellente technique ici est d’avoir un programme d’échange où les développeurs clés viennent rester avec vous pendant un certain temps, et vous y allez pendant un certain temps.

Si vous avez une équipe distante talentueuse, et si vous gérez la relation comme je l’ai décrit, vous pouvez vraiment profiter de cet arrangement. Surtout avec les ingénieurs basés en Inde, le décalage horaire peut faire en sorte que chaque matin, lorsque vous arrivez, vous voyez des progrès qui vous attendent, et vous pouvez passer votre journée (et leur nuit) à examiner, tester et fournir des commentaires. Le résultat peut en fait être des temps de cycle extrêmement rapides.

Notez que vous pouvez également avoir vos ressources de prototypage à distance, mais vous devrez travailler un peu plus dur sur la communication et être plus flexible sur vos heures, en raison des temps de cycle très rapides (plusieurs itérations par jour).

Une autre solution aux problèmes liés à la gestion d’une équipe de développement distante consiste à localiser l’ensemble de l’équipe produit sur un site distant. Je vois que cette tendance ne fait que commencer, mais je pense qu’elle sera profonde. Cela dit, vous n’avez pas à vous en préoccuper pour le moment. Il a fallu 10 ans pour développer les capacités d’ingénierie et d’assurance qualité dans ces sites distants, et il en faudra probablement 10 autres avant que ces sites aient également des chefs de produit et des concepteurs qualifiés. Mais c’est un sujet pour un prochain article.



Source

  • Partager cet article

Laisser un commentaire