La transformation numérique
de Nike.
Zéro défauts.
9 milliards au jeu.

La plateforme eCommerce B2B de Nike fonctionnait depuis plus de six ans. Elle traitait des milliards de dollars de commandes. Et les deux applications Web à son cœur étaient dues pour une migration qui toucherait l'intégration SAP, la pile de bibliothèques open source et la plateforme d'application elle-même. L'équipe chez TechSparq a été engagée comme partenaire eCommerce de Nike pour l'exécuter.

Ce n'est pas une histoire sur une découverte qui a changé la stratégie. C'est une histoire sur ce que l'exécution propre ressemble quand les enjeux sont 9 milliards de dollars de revenus et la barre pour une livraison sans défaut a constamment ne pas été remplie par les partenaires plus grands avant vous.

La plateforme et ce qui était en jeu

Les deux applications ATG Dynamo que TechSparq a été engagé à migrer n'étaient pas expérimentales. Elles avaient été en production pendant plus de six ans, servant les opérations de commerce B2B de Nike. La plateforme dont elles faisaient partie était responsable de neuf milliards de dollars de revenus annuels.

L'étendue de la migration était importante. Déplacer les deux applications d'ATG Dynamo vers la plateforme d'applications d'entreprise JBoss. Mettre à niveau toutes les bibliothèques open source vers les versions actuelles. Mettre à niveau l'intégration SAP BAPI vers la version la plus récente possible. Et livrer plusieurs modifications de fonctionnalités aux côtés de la migration. Tout cela sans perturber les opérations commerciales s'exécutant sur la plateforme.

L'attente de base de Nike pour les publi­ca­tions de production de ce type était ancrée dans une expérience douloureuse. Les publi­ca­tions comme celle-ci produisaient généralement environ sept à dix bogues critiques dans les quatre premières semaines en production. Ce n'était pas une anomalie. C'était la norme du secteur pour ce que les autres partenaires de Nike avaient livré.

Le défi technique et où cela s'est aggravé

ATG Dynamo vers JBoss est un changement architecturel important. Les applications existantes étaient basées sur JSP et Struts, construites sur l'infrastructure de commerce ATG aux côtés de diverses dépendances open source accumulées au cours de six ans. Mettre à niveau les bibliothèques tout en changeant simultanément la plateforme d'application et en livrant les modifications de fonctionnalités est une migration multidimensionnelle qui renforce le risque à chaque couche.

L'intégration SAP a ajouté une dimension qui ne pouvait pas être planifiée autour. L'une des deux applications interfacée directement avec SAP et nécessitait la technologie SAP BAPI pour cette intégration. Pendant le développement, l'équipe a découvert que les incompatibilités de version entre le code BAPI existant et l'environnement cible n'étaient pas résolubles avec les mises à jour incrémentielles. Le code BAPI nécessitait une réécriture à grande échelle.

Ce genre de découverte, au milieu de la migration, sur une plateforme de production 9 milliards de dollars, est où les projets glissent les horaires, où les équipes demandent un allègement du périmètre, et où les firmes ayant une profondeur technique moins élevée commencent à faire des compromis qui compromettent la qualité. L'équipe TechSparq l'a résolu sans temps supplémentaires et sans impact sur la chronologie.

Le modèle d'équipe distante qui l'a rendu possible

L'engagement a été doté de manière maigre. Un chef de projet, un développeur Java principal, un développeur Java senior, un développeur Oracle et un gestionnaire de programme et de relations. Le développeur principal s'est déplacé vers le site client de Nike environ une semaine par mois. Le reste de l'équipe fonctionnait à partir du centre de développement d'Atlanta de TechSparq.

C'est worth de faire une pause. Les clients d'entreprise à l'échelle de Nike sont habitués aux grandes équipes sur site de grands cabinets de conseil - des équipes qui créent l'impression visuelle d'effort par le nombre de têtes et la présence physique. TechSparq fonctionnait avec une équipe distante disciplinée qui nécessitait un soutien et une direction client minimaux. Le résultat a été reconnu en interne chez Nike dans plusieurs réunions de leadership senior en tant que modèle de la façon dont ce type de projet devrait fonctionner.

Le modèle distant fonctionne quand l'équipe a la profondeur technique pour fonctionner indépendamment, la discipline de processus pour rester synchronisée sans proximité, et les normes de communication pour faire surface aux problèmes avant qu'ils ne deviennent des bloqueurs. Il ne fonctionne pas quand les équipes nécessitent une tenue constante de main ou quand la gestion de projet couvre les lacunes techniques. Cette équipe n'avait pas de lacunes à couvrir.

Le résultat qui parle de lui-même

Les applications mises à niveau ont été livrées à temps et au budget. Aucune heure supplémentaire n'a été nécessaire. Et dans les quatre premières semaines de production, deux bogues non critiques ont été découverts. Pas sept. Pas dix. Pas de bogues critiques du tout. Deux problèmes non critiques sur une migration de plateforme B2B complète impliquant une réécriture SAP BAPI complexe, un changement de plateforme et une mise à niveau de bibliothèque dans une base de code vieille de six ans.

Ce résultat n'est pas arrivé parce que le projet était simple. C'est arrivé parce que l'équipe qui l'a fait était techniquement capable d'assez trouver des problèmes pendant le développement plutôt que de les laisser surface en production. C'est la distinction entre une équipe qui code et une équipe qui conçoit.

Ce que le directeur de Nike demandait vraiment

La question de Shane Guenes - pourquoi TechSparq peut-elle le faire quand les partenaires plus grands ne le peuvent pas - mérite une réponse directe. Ce n'est pas une question rhétorique. C'est une question structurelle.

Les grandes entreprises de conseil et de technologie apportent des ressources importantes. Elles apportent aussi une surcharge, des couches de gestion de projet, des équipes avec une profondeur technique inégale, et des modèles de gouvernance optimisés pour protéger l'entreprise plutôt que de livrer le résultat. Quand la qualité d'exécution souffre, c'est rarement parce que l'entreprise manquait de gens intelligents. C'est parce que les gens intelligents ont été enterrés sous le processus, ou parce que l'équipe sur le travail réel n'était pas l'équipe qui a remporté l'engagement.

TechSparq fonctionne différemment. L'équipe qui délimite le travail est l'équipe qui fait le travail. La profondeur technique est réelle et elle traverse toute l'équipe, pas seulement le chef. La discipline de processus et la capacité d'exécution à distance ne sont pas des points de parlure. Elles sont le modèle opérationnel. Et quand quelque chose d'inattendu se produit au milieu du projet - comme une base de code BAPI qui nécessite une réécriture complète - il n'y a pas de couche de gestion de projet entre le problème et les ingénieurs le résoudre.

• ■
  La profondeur technique bats le nombre de têtes. Une équipe maigre avec une expertise authentique surpassera une grande équipe avec une capacité moyenne sur chaque migration complexe.
• ■
  Les équipes distantes peuvent surpasser les équipes sur site. La présence n'est pas un substitut pour la qualité. La discipline de processus et les normes de communication détermine le résultat, pas la géographie.
• ■
  Les taux de défaut sont un choix. Sept à dix bogues critiques en quatre semaines n'est pas inévitable. C'est ce qui arrive quand la qualité est traitée comme un problème de test plutôt qu'une norme d'ingénierie.
• ■
  Les surprises ne sont pas des excuses. Une réécriture BAPI au milieu du projet est une découverte importante. C'est aussi quelque chose qu'une équipe techniquement capable absorbe et résout sans impact sur la chronologie ou le budget.