19 fév 08 Du developpement offshore

Motivations

De plus en plus de sociétés déplacent leurs équipes de devéloppement à l’étranger. Pour 2 raisons principales:
- la première, évidente, faire des économies en s’installant dans un pays où la main d’oeuvre est moins chère (Europe de l’Est, Maghreb, Asie).
- la seconde, moins immédiate: trouver des gens compétents.

Peut-être avez vous déjà envisagé de délocaliser votre développement pour faire créer vos produits offshore. Et peut-être ne l’avez vous finalement pas fait, de peur de ne pas avoir suffisamment de controle sur une équipe pas suffisamment compétente? Cet article a pour but de vous convaincre d’y réflechir encore une fois!

Reglons tout de suite un point crucial et souvent bloquant: les développeurs offshore ne sont ni moins bon ni meilleurs que par chez nous ou aux US. Ils sont tout autant compétents. Par ailleurs, pour des raisons purement démographiques, il y a de fortes chances que vous en trouviez PLUS là-bas :) Oubliez-donc le préjugé selon lequel un développeur local travaillera mieux que 3 Indiens, c’est bas et infondé.

Le principal problème, ou plutôt la contrainte la plus importante est le fait que la communication devient évidemment plus difficile à assurer dans de bonnes conditions. Cela se décline sous plusieurs aspects, mais à chaque fois, c’est bien la communication qui est en jeu.

Des contraintes dont il faut être conscient

Il y a évidemment la barrière de la langue. Vous allez dire, pas de problèmes, de nos jours tout le monde parle anglais, surtout dans l’informatique. C’est pas faux. Sauf que 2 anglais discutant entre eux c’est différent d’un français conversant avec un chinois… Les quiproquos sont déjà fréquents quand on utilise les emails ou la messagerie instantanée en temps normal, alors imaginez entre 2 personnes n’utilisant pas leurs langues maternelles. Ca y est vous voyez? Alors bien sur il ne faut pas le voir comme une énorme barrière mais juste être très vigilant lors des échanges pour être sur que tout est bien compris (de la même façon!) de chaque coté. Quitte à insister lourdement. On vous sera toujours reconnaisant d’avoir pris le temps de réexpliquer et vous pourrez ensuite avoir l’esprit tranquille…

Une seconde contrainte est le décalage horaire. Cela parait difficile d’avoir une équipe en Inde travaillant au même moment qu’une équipe en France. Toutefois, dans ce cas comme dans tout travail avec l’Asie vous aurez quand même un créneau horaire (réduit) commun. A vous de l’utiliser au mieux pour effectuer les taches demandant d’être en contact direct avec l’équipe offshore. Le reste peut attendre qu’ils soient rentrés chez eux. Car on oublie aussi trop souvent une chose: si vous commencez votre journée, eux la finissent, et comme tout le monde en fin de journée, ils peuvent être moins réactifs alors que vous êtes frais et d’attaque!

Enfin, et comme avec toute équipe travaillant à distance, il est plus difficile de tisser des liens alors que vous nous vous rencontrerez probablement jamais face-to-face (pardonnez l’anglicisme). Par ailleurs cela peut éventuellement s’accompagner d’un léger décalage culturel. Alors oui, il n’est pas si facile de jauger les gens au début.
Il ne faut pas non plus que l’équipe offshore soit éloignée des utilisateurs. Au contraire, même si elle n’est pas à leur contact direct, elle doit se sentir concernée par leurs attentes! Si vous êtes l’intermédiaire c’est à vous de leur transmettre les requêtes des utilisateurs, mais aussi de leur dire combien ce qu’ils développent a du succès (ou pas) !

Il est très facile d’en demander trop à quelqu’un qu’on ne voit jamais. On s’autorise bien plus de choses dans le monde virtuel… Pourtant il est encore plus important que dans une organisation classique d’être conscient du niveau de stress de l’équipe et de parer à tout coup « de moins bien ». Il faut à tout prix éviter la démobilisation car elle peut être difficile à detecter et avoir des conséquences malheureuses sur l’avancement ou même le succès d’un projet.

Une méthode adaptée

Puisque le problème potentiel se situe au niveau de la communication il s’agit pour les commanditaires de s’assurer que tout ira pour le mieux de ce coté là.

Une première chose importante est d’avoir une vision précise votre équipe offshore. Savoir distinguer l’administrateur système d’un développeur Java ou de l’intégrateur XHTML/CSS. Cela rassure et vous disposez des ressources humaines de façon plus pertinente. Evidemment c’est la tâche du chef de projet d’allouer les ressources, mais garder un oeil sur ce qui est fait et montrer que l’on suit est primordial comme dans tout business. Vous êtes a priori le lien entre eux et les clients!
Vous pouvez imaginer aussi d’avoir un contact privilégié avec un des membres de l’équipe pour servir d’intermédiaire, sans oublier que les décisions se prennent avec le chef de projet. Il ne s’agit pas de titiller un ego…

Il ne faut pas hésiter à diversifier les canaux de communication. Il parait qu’on est passé au Web2.0? Alors il est temps de se servir de quelqu’uns de ses outils emblématiques:

Le Wiki:

Déjà utilisé depuis quelques temps par les équipes de développements, il permet de centraliser certaines ressources comme la documentation. Cela peut inclure les spécifications qui sont ainsi disponibles de façon transparentes pour chaque membre et qui peuvent être discutées, expliquées ou remaniées rapidement.
Une parenthèse concernant les specifications: si vous devez spécifier pour une équipe offshore, spécifiez 2 fois plus (ce qui reste peu dans le cas d’un développement Agile), et autant que possible en utilisant des images (quand c’est possible, par exemple pour tout ce qui touche au front-end). Pouff la barrière linguistique, à dégager! Il est très important de prendre le pli de centraliser toutes les informations dans le wiki dès que possible et de dissuader l’utilisation des e-mails, source de confusion. N’oubliez pas non plus d’expliquer le « pourquoi » d’une demande et d’éclaircir les attentes des utilisateurs. Cela rendra plus compréhensible la tâche à effectuer pour le développeur.

Un Blog:

Je sais que le blog a du mal à faire son entrée dans les entreprises… la plupart ont déjà compris son utilité en matière de communication avec les clients mais pas l’usage qu’elle pourrait en faire en interne. En voilà quelques uns: notifier à un groupe de personnes (couplé à l’utilisation du flux RSS), tenir au courant de l’avancement d’une tâche (cela peut servir pour le rapport quotidien dans le cas de la méthode SCRUM par exemple), signaler un prochain meeting..

Last but not least: la messagerie instantanée, Skype

Pas besoin de faire un dessin, cela fait un moment que tout le monde a compris l’utilité de Skype pour les discussions quotidiennes ou les questions qui appellent une réponse immédaite. Toutefois je preconiserai l’utilisation du multi-chat. L’idée étant d’avoir un channel de discussion ouvert pour toute l’équipe à n’importe quel moment. Cela permet de garder une trace de ce qui se dit, de tenir tout le monde informé et fait office d’enregistreur en cas d’absence :)

Enfin

Le développement offshore est encore trop jeune pour pouvoir garantir son succès. Toutefois la tendance semble se confirmer et même certaines start-up commencent à franchir le pas en voyant une occasion de réduire leur problèmes de fonds… Je connais des gens qui le déconseilleront. Mon avis est que bien managée il n’y a pas de raison que cela se passe plus mal qu’avec une autre équipe.

Quelques ressources:

• Comment bien exporter son developpement
• Offshore development the reasons why not
• Offshore development aim for it even if you never go there
• When will the offshore bubble burst
• Agile offshore
• Les prestataires « offshore » : une concurrence de plus en plus compétitive

Articles en rapport (ou pas!) :

• [KDE 4] Plasma: Des tutoriaux screencast comme s’il en pleuvait
• Ma tablette graphique Wacom Bamboo sous (K)Ubuntu Gutsy
• [KDE 4] Compiler KDE pour Kubuntu à partir des sources (Build KDE from trunk)