Retour d'expérience sur l'organisation Data chez Blablacar.
Ils ont créé une équipe Data transverse avec uniquement des Data Enginers.
Quelques take aways:
-
investir dans des solutions génériques et réutilisables paye sur le moyen/long term
-
il y a un intérêt à ce que l'équipe Data devienne le point central entre tous les stackholders
-
rechercher l'adoption plutôt que l'obligation
-
toujours considérer le "build vs buy"
Les résultats d'un programme de recherche basé sur les DORA métriques pour évaluer les méthodes de travail ayant le plus d'impact.
-
les équipes qui se concentrent sur l'utilisateur ont de meilleures performances organisationnelles
-
une documentation de qualité amplifie l'impact des autres méthodes (~x2 en moyenne!)
Pour les pratique de développement pures:
- intégration continue
- vitesse des revues de code
- architecture découplée
- trunk based development
Récapitulatif sur les métriques possibles dans une équipe de développeurs.
DORA, un framework axé sur la qualité des processus de développement et du code:
- Lead Time for Change: combien de temps entre une idée de feature et son déploiement
- Deployment Frequency
- Change Failure Rate: % de code déployé qui cause des bugs dans le système
- Mean Time to Recovery: combien de temps pour fixer un bug
SPACE, un framework plus global sur la performance au sein d'une équipe:
- Satisfaction & Well Being: état mentale au sein de l'équipe pendant le travail
- Performance: observation de la vélocité de l'équipe
- Activity: observation de la quantité de travail réalisé
- Communication & Collaboration: qualité des interactions au sein de l'équipe
- Efficiency & Flow: qualité de l'organisation du temps de l'équipe
DevEx, un framework qui se concentre sur l'expérience des développeurs:
- Feedback Loops: processus et temps nécessaire à prendre en compte les retours
- Cognitive Load: qualité et taille de la codebase
- Flow State: organisation du temps de développement
Un outil de data visualisation qui peut se connecter à la plupart des bases de données afin de créer des dashboards.
C'est un aggrégateur de sources de données pour créer des dashboards assez facilement.
Le but de ce genre d'outil c'est que l'équipe data se charge de la stratégie de collecte mais ensuite chaque équipe est responsable de créer ses propres metriques un utilisant le système de dashboarding.
Aussi le produit est open source donc on peut commencer en SaaS et passer en OS quand ça coûte trop cher et inversement
Un article sur les métriques dans une équipe tech.
C'est quelque chose dont on peut se passer lorsque l'équipe est encore petite (<20 personnes) mais qui devient indispensable par la suite afin de comprendre le coût d'un effort et si il est réellement nécessaire.
Par exemple, ça permet de planifier (ou non) des chantier de refactoring de code ou de scaling infra.
Il y a plusieurs niveaux de maturité (Data Maturity Level):
- 0 Unaware: aucune collecte et utilisation de la donnée
- 1 Aware: certaines données sont collectées mais pas vraiment de responsable pour les surveiller
- 2 Reactive: présence de KPI produit, adoption légère
- 3 Proactive: présence de responsable sur les outils de collecte
- 4 Managed: la donnée est considérée comme critique pour l'entreprise et est communiquée au plus haut niveau
- 5 Effective: la donnée est publiée et utilisée à l'extérieur de l'entreprise