L'outsourceur dit : Ne pas externaliser

N'externalisez pas le développement de vos logiciels.

Oui, vous avez bien lu. Je travaille pour une société d'externalisation du développement de logiciels et je vous dis de ne pas externaliser.

Mais pourquoi pas ? Tout le monde le fait et tout le monde ne peut pas se tromper, n'est-ce pas ? La perception commune est que l'externalisation permet d'économiser de l'argent grâce à l'arbitrage de la main-d'œuvre. Il peut y avoir d'autres facteurs, mais les entreprises le font principalement pour obtenir plus de logiciels, probablement plus rapidement, pour moins d'argent.

Toutefois, les aspects économiques de l'externalisation sont beaucoup moins simples que ne le laisse supposer la comparaison des taux de main-d'œuvre. Il n'existe pas vraiment d'"arbitrage de main-d'œuvre" dans le domaine du développement de logiciels. Contrairement au cuivre ou au blé, tous les développeurs ne sont pas créés égaux, de sorte que vous n'êtes pas exactement en train d'échanger des produits de base. En outre, l'externalisation n'est pas sans risque, comme nous le verrons plus loin. Le concept d'arbitrage ne s'applique donc pas, et avec lui toute la proposition.

Tout d'abord, comparons-nous des pommes avec des pommes ? Oui, cette entreprise étrangère ne vous facture que $20/heure pour un développeur. Mais quelle est la valeur ajoutée de cette heure ? Quelle est la compétence de ce développeur ? Votre équipe est-elle composée de personnes compétentes ou de jeunes diplômés dont le niveau de compétence est discutable ? Quelle est leur expérience ? Un développeur interne expérimenté ($100/h) peut très bien produire plus de valeur pour vous que 5 ou même plus de développeurs juniors ($20/h) à l'étranger.

N'oubliez pas non plus que vous devez former les ressources externes. Au départ, elles ne connaissent pas votre produit, elles ne connaissent pas votre processus et vous n'avez jamais travaillé ensemble auparavant ; il faut donc du temps avant qu'elles puissent commencer à produire de la valeur. Même s'il est nécessaire, l'investissement dans la courbe d'apprentissage se répercute sur les économies prévues. Et le développeur interne expérimenté qui est parfaitement au point sera encore plus performant.

Supposons maintenant que vous ayez dépassé le stade du transfert initial de connaissances. Avez-vous déjà réalisé ces économies ? C'est loin d'être le cas. Dans le domaine du développement de logiciels, la communication est essentielle. Il est parfois assez difficile d'expliquer à une personne expérimentée se trouvant dans la même pièce ce que vous voulez qu'elle construise. Imaginez que vous fassiez la même chose avec quelqu'un qui se trouve à des milliers de kilomètres de chez vous et qui se contente essentiellement de courriels et de messages instantanés, et parfois d'appels vocaux et vidéo sur Skype. Le développement de logiciels est un processus social très impliqué, où les gens partagent des idées complexes et des concepts abstraits. Et non, la documentation n'y remédiera pas complètement : on ne peut pas vraiment documenter tout sur un système dès le départ, et toute Les textes écrits sont toujours sujets à de multiples interprétations. En outre, le marché évolue si rapidement que, lorsque votre documentation est terminée, elle est généralement obsolète et de nouvelles exigences conduisent à un système différent. Le développement de logiciels fait appel à des connaissances tacites et à une compréhension émergente. Là encore, c'est assez difficile en interne et encore plus difficile avec un fournisseur externe (pensez aux différences culturelles, aux accents, aux barrières de communication, etc.)

Qu'en est-il de la possibilité d'affecter davantage d'organismes à un projet ? Par exemple, vous êtes en retard sur votre calendrier de publication et vous êtes tenté d'ajouter des ressources offshore moins chères pour respecter les délais. Malheureusement, si vous le faites, Loi de Brooks est susceptible de prendre effet. Ce célèbre principe stipule que l'ajout de ressources à un projet en retard le rendra plus efficace. plus tardou, comme l'a formulé de manière plus imagée son auteur Fred Brooks, "Neuf femmes ne peuvent pas faire un bébé en un mois". Même lorsqu'un projet n'est pas en retard, un plus grand nombre de personnes n'est pas synonyme de plus grande valeur. Compte tenu de la complexité de la communication, une équipe plus nombreuse progresse plus lentement, parfois de manière significative, et la productivité s'en ressent. Votre investissement peut vous permettre d'acheter plus de développeurs à l'étranger, mais pas nécessairement plus de valeur sous la forme d'un logiciel commercialisable pour votre argent.

N'oubliez pas non plus les coûts de gestion supplémentaires que vous devrez supporter pour communiquer avec votre fournisseur et contrôler ses performances. L'étude d'Aberdeen Group montre que plus de 76% des clients déclarent que les coûts d'administration de projet et de gestion des fournisseurs s'élèvent à beaucoup plus élevé que prévu, ce qui ne surprendra pas ceux qui ont déjà eu recours à l'externalisation.

Enfin, il faut tenir compte du risque global d'échec du projet. Les statistiques varient mais, selon la source, entre 30 et 50% des projets externalisés échouent purement et simplement : ils sont soit complètement abandonnés (et le travail est repris en interne à un coût supplémentaire), soit radicalement insuffisants en termes de fonctionnalité et de valeur commerciale. Certes, tous les projets internes ne sont pas menés à terme, mais le risque d'échec est plus élevé dans le cas de l'externalisation.

Alors, s'il vous plaît, n'externalisez pas le développement de vos logiciels.

Sauf en cas de nécessité absolue. Et à moins que vous ne le fassiez avec Agile. Plus précisément, Scrum.

Parfois, il n'est pas possible de conserver un projet en interne. Par exemple, vous pouvez avoir besoin de renforcer rapidement votre équipe de développement pour livrer un produit à une date précise, au risque de voir la fenêtre d'opportunité se refermer, mais vous savez que vous ne pouvez pas embaucher suffisamment de personnes de qualité dans votre zone géographique. Si vous optez pour la distribution, vous avez essentiellement recours à l'externalisation et au moins certaines des difficultés inhérentes au développement traditionnel de logiciels s'appliquent. L'externalisation auprès d'une entreprise utilisant Scrum vous aidera toutefois à surmonter les obstacles qui rendent l'approche traditionnelle lourde et inefficace, et qui sont à l'origine d'échecs endémiques des projets. 

Inspiré par le système de production Toyota (TPS), le Scrum a été présenté pour la première fois dans un document de conférence par Dr. Jeff Sutherland et Ken Schwaber en 1995. Scrum s'articule autour de plusieurs principes et pratiques fondamentaux, notamment le développement par itérations courtes, la livraison incrémentale d'un logiciel potentiellement livrable après chaque itération, la hiérarchisation des fonctionnalités en fonction de la valeur commerciale et l'implication directe du client dans la planification, l'élaboration et l'acceptation.

Contrairement à l'approche traditionnelle "en cascade", où tous les logiciels sont livrés une seule fois, à la fin du projet, Scrum se concentre sur la fourniture d'un flux continu de valeur au client, ce qui minimise les risques du projet et augmente le retour sur investissement. Avec Scrum, les échecs catastrophiques de projets tels que le récent Système de gestion des tribunaux de Californie (CCMS) $500 millions de dollars de débâcle sont impossibles par définition.

Les recherches de Sutherland montrent que, lorsqu'il est bien géré, le Scrum peut aider à atteindre - même dans le cadre d'un projet de grande envergure et mondialement distribué - le type d'hyperproductivité/de vitesse extrême que l'on ne pensait possible que dans de petites équipes co-localisées, des vitesses qui sont plusieurs fois supérieures à la productivité généralement observée dans les équipes en cascade, en interne ou à l'étranger. Appliqué dans le contexte du développement de logiciels externalisés et distribués, Scrum agit comme un catalyseur de communication et comme un puissant projecteur éclairant chaque aspect de la relation client-fournisseur, forçant la responsabilisation d'une part et libérant une énorme productivité d'autre part.

M. Sutherland, qui conseille actuellement l'équipe d'investissement de la société OpenView Venture Partners, basée à Boston, et accompagne les entreprises du portefeuille d'OpenView dans l'utilisation des techniques de développement Agile, m'a expliqué qu'il donnait ce conseil précis aux entreprises du portefeuille d'OpenView : soit vous externalisez auprès d'entreprises Scrum, soit vous n'externalisez pas du tout.

Steve Denning chez Forbes qualifie le Scrum de découverte majeure en matière de gestion et, en fait, soutient que ses fondateurs devraient recevoir un prix Nobel de gestion, s'il en existait un. Peut-il en fait vous aider à ajouter des personnes, y compris à l'étranger, et à les intégrer dans votre entreprise ? d'aller plus vite plutôt que plus lentement ? Peut-il vous aider à fournir des logiciels de manière fiable lorsque vous travaillez avec des fournisseurs d'externalisation ? Je réponds personnellement à ces questions par un "oui" sans réserve, mais je vous invite à faire des recherches et à vous faire votre propre opinion. En particulier si vous externalisez, Je ne pense pas que vous puissiez vous permettre de ne pas le faire. Et je soupçonne vos concurrents de l'avoir déjà fait.

1.       Scrum atteint des vitesses jusqu'à 5 fois supérieures à la moyenne de l'industrie pour les cascades. (Capers Jones, Jeff Sutherland)

2.       Les projets Waterfall ont un taux d'échec 3x plus élevé (29% vs. 9%) et un taux de réussite 1/3 plus élevé (14% vs. 42%) que les projets Agile. (Standish Group, rapport CHAOS 2012)

3.    Système de gestion des tribunaux de Californie: Échec retentissant d'une cascade où le coût prévu était de 1T81T500M, le coût réel était de 1T81T2B, ce qui dépassait les estimations initiales de 630%, et le projet a été complètement abandonné.

4.    Les analystes suggèrent aux responsables informatiques de dire adieu à la chute d'eau. (Gartner 2012 Planning Guide : Application Delivery Strategies)

5.    Les leaders de l'industrie qui utilisent Scrum comprennent Google, Microsoft, Yahoo, Citrix, Facebook, Adobe, Salesforce.com, Nokia, Siemens et bien d'autres.