J'ai regardé cette question en détail il y a quelques années et ont abouti aux conclusions suivantes (sans ordre particulier):
Les organisations de sous-traitance que nous avons examinés (tous les indiens) avaient une base de processus très forte. Je ne sais pas si c'était culturel ou juste la façon dont ils ont choisi de se mettre en place (peut-être un peu des deux) mais nous avons pensé que c'était probablement un vrai problème. Ils parlaient d'être un cinq sur le modèle de maturité Carnegie Melon (Google mais en gros cela signifie qu'ils ont défini et documenté tout jusqu'à et y compris ce qui se passe quand quelqu'un pète), nous courions généralement autour d'un 1 ou un 2 (équivaut à croiser les doigts et espérer le meilleur). Notre niveau de processus était largement déterminé par nos clients qui n'avaient aucun intérêt à signer des spécifications (pour de bonnes et mauvaises raisons), qui voulaient des gens qui comprenaient leur entreprise et qui combleraient les lacunes, et qui voulaient changer leur les esprits trois fois par jour. Autant que beaucoup de ces facteurs ont exaspéré les programmeurs au Royaume-Uni, nous avons compris qu'ils n'allaient jamais changer. C'était probablement notre plus grande préoccupation - nous ne pensions pas que nous pourrions trouver un modèle de processus qui fonctionnerait pour les trois groupes impliqués (les clients, l'équipe informatique basée au Royaume-Uni et l'équipe d'externalisation basée en Inde). Donc, la première chose à faire est de déterminer quel est votre processus et de déterminer si vous pensez sincèrement que vous pouvez le faire fonctionner pour toutes les parties impliquées. Il est facile de dire «nous allons faire de l'agilité», mais comment allez-vous faire fonctionner cela quand une partie est à 1 000 milles de là? Alternativement, si vous voulez un itinéraire en cascade solide, est-ce réaliste étant donné vos clients? Deuxièmement, comprenez les différences culturelles bien ancrées au sein de vos équipes. Mon expérience (et je généralise ici) est que les programmeurs des États-Unis et du Royaume-Uni n'hésitent pas volontiers (parfois trop volontiers) à questionner l'autorité et les hypothèses. Demandez-leur de faire quelque chose de stupide et vous risquez de vous faire dire que vous leur avez demandé de faire quelque chose d'idiot en termes non équivoques et qu'ils vous diront ensuite ce que vous voulez vraiment.
Ce n'est pas la norme dans le monde entier. Beaucoup de développeurs indiens avec lesquels j'ai travaillé ne remettent pas en question les choses de la même manière. Cela ne veut pas dire qu'ils ne sont pas aussi brillants, ils appliquent simplement leur intelligence à la livraison de ce que vous avez demandé, en supposant que vous aviez une bonne raison de le faire. Vous pouvez argumenter que l'un ou l'autre est bon ou mauvais (j'ai perdu le compte du nombre de fois que j'ai entendu des développeurs questionner ce qu'on leur dit et dire comment les choses devraient être en dépit de ne pas comprendre les bases de l'industrie dans laquelle ils travaillaient), mais l'important est qu'ils sont différents et qu'ils vont s'affronter.
Donc, la réponse est probablement que vous allez avoir besoin de sentir les équipes impliquées et, sur cette base, choisir des façons de travailler qui sont confortables pour les deux. Oui, mettez en place une vidéoconférence, rendez-vous à chaque fois pour visiter l'autre site (cela fait une grande différence) et, si possible, faites parler les gens même si cela n'est pas strictement nécessaire au début, mais surtout effort pour comprendre les groupes impliqués et concevoir une dynamique qui fonctionne pour tous - l'imposition d'une vision du monde de l'autre ne fonctionnera pas.
Cela devrait être une question de communauté wikki. – FrustratedWithFormsDesigner
Maintenant, c'est le wiki de la communauté ... Je ne savais pas que je pourrais le signaler comme un wiki du début. –
On dirait un sujet pour le blog http://www.wideteams.com ... – ewall