Innovation, culture projet vs culture produit en Data Science
By WORMS David
8 oct. 2019
- Catégories
- Data Science
- Gouvernance des données
- Tags
- DevOps
- Agile
- Scrum [plus][moins]
Ne ratez pas nos articles sur l'open source, le big data et les systèmes distribués, fréquence faible d’un email tous les deux mois.
La Data Science porte en elle le métier de demain. Elle est étroitement liée à la compréhension du métier, des comportements et de l’intelligence qu’on tirera des données existantes. Les enjeux sont à la fois humains et technologiques. Ils intègrent l’innovation, la comprenssion des besoins métiers et la nécessité d’industrialisation.
Science et ingénierie
Les Data Scientists doivent trouver un équilibre inhabituel entre la découverte de nouveaux savoirs (la science) et leur maîtrise rapide (l’ingénierie). Ils doivent être simultanément innovants et perspicaces tout en fournissant des résultats reproductibles et un code de qualité de production. Or, les méthodes de travail de recherche et de développement nécessaires à l’exploration sont souvent antinomiques avec la manière dont le code de production se construit.
À ce titre, les méthodogies développées et déployées par Bell Labs lui on permit de maintenir le leadership de l’innovation mondial pendant plusieurs décennies. L’innovation est processus qui peut être favorisé. L’ouvrage “The Idea Factory: Bell Labs and the Great Age of American Innovation” écrit par Jon Gertner retrace cette aventure.
John Pierce, ingénieur aux Bell Labs et écrivain, définit 4 piliers sur lesquels se construit l’innovation. Premièrement, le management doit être techniquement compétent, de préférence issue d’une formation et d’une expérience d’ingénieur. Deuxièmement, les travaux ne doivent pas être conditionné par l’attribution de budget afin d’éviter une trop forte pression financière et des objectifs à court terme. Troisièmement, les travaux doivent s’inscrire sur le long terme, c’est-à-dire plusieurs années, afin de porter tous les bénéfices de la recherche et de délivrer des solutions fiables et évolutive à la société. Quatrièmement, l’arrêt d’un projet ne doit pas conduire un sentiment d’échec mais à une valorisation des efforts et des connaissances acquises.
Culture projet vs culture produit
La majorité des équipes avec lesquels nous travaillons basent leurs développements sur des processus issue de la méthodologie Agile, c’est une très bonne chose ! Construire le produit par incrément permet de diminuer les risques techniques et de partager l’avancée des développements.
Cependant, l’exécution d’une stratégie (avec sa fameuse “Roadmap”) définie en début de projet doit être continuellement remise en cause. Les équipes sont davantage focalisées sur les fonctionnalités à développer que sur l’impact de ces fonctionnalités. Bien qu’utilisant le développement Agile, la culture est restée celle d’une culture projet avec ses limites.
À cela s’ajoute très souvent une organisation composée d’un mélange de cycle en V et de méthodes Scrum dont la conséquence est un ratio disproportionné de cadre vis à vis des développeurs avec des tâches qui se superposent et qui manquent de clarté.
Finalement, les conséquences multiples d’un delivery brutal à des équipes sans connaissances fonctionnelles et parfois techniques n’impliquent pas les équipes dans la construction d’un produit aux évolutions complexes et ambitieuses.
La culture produit, à l’inverse, invite à tester une autre approche : expérimenter et apprendre sur la stratégie au fur et à mesure. Cette démarche consiste à vérifier pas à pas (et ce n’est pas simple) que ce que nous souhaitons développer est bien ce qu’il faut développer…
Le développement et le support de services utilisent des équipes quasi-permanentes tant que le service est opérationnel. Le budget peut varier d’année en année, mais il suffit généralement de financer en permanence une organisation de développement durable pour la durée de vie du service. Les équipes sont financées pour travailler sur un problème ou une solution particulière sur une période donnée ; la nature du travail se définit par les enjeux de l’entreprise plutôt que par la mise à disposition de fonctionnalités.
Dans la culture projet | Dans la culture produit | |
---|---|---|
Objectif visé | Construire un logiciel / un service | Régler un problème / créer un business |
Satisfaction recherchée | Satisfaction du sponsor | Satisfaction des utilisateurs |
Focalisation | Sur coûts / délais / qualité | Sur la valeur et l'apprentissage |
Outil de pilotage | Roadmap des fonctionnalités | Rapport d'expérimentations / Mesure d'Impact |
Méthode de développement | Agile ou Cycle en V | Agile |
Mesure de la performance | Budget et Vélocité du dev. | Métriques business et techniques |
Changement de stratégie | Arrêt du projet / nouveau projet | Pivot |
Structure de l'organisation | Par silo | Décloisonnée |
Rôle du Management | Commanditaire / Contrôleur | Investisseur |
En mode produit, aucun projet n’est sous-traité aux fournisseurs ou remise à la charge d’équipes dédiées à l’exploitation. Au lieu de cela, les fournisseurs et exploitant peuvent être invités à fournir une équipe stable, de longue durée, idéale, avec des rôles clés dotés de talents internes.
Le produit doit être géré tout au long de sa vie par la même équipe mais si sa constitution évolue en fonction des demandes et impératifs.
Conclusion
Les conditions de création doivent être maximisées et mis en adéquation avec le puits d’information que constitue le Data Lake. Les Data Scientists doivent trouver l’équilibre entre l’innovation et la nécessaire industrialisation de leurs idées.
Plusieurs modèles sont possibles. Certaines sont rapidement exploitables et d’autres, même si déjà en production dans les sociétés les plus innovantes, sont en avance de phase. La stratégie de chaque entreprise détermine son positionnement, conservateur avec le risque de passer à côté du “Next Big Thing” mais avec des résultats immédiats et/ou innovante avec le risque de miser sur une technologie sans futur mais avec l’opportunité d’acquérir un avantage comparatif sur la concurrence.