Les adopteurs précoces sont des fondus de technologie recherchant un changement radical, alors que la majorité avancée veut une « amélioration de la productivité ». Le second groupe veut un produit fini, alors que le premier accepte les imperfections et possède les compétences techniques pour voir immédiatement les avantages. Le challenge d'une startup est de passer cette faille c'est avant tout un challenge qualité

les équipes doivent avoir une autonomie pour prendre la décision de mettre en production

lire,écouter les retours fait sur les stores, TrustPilot faire le point avec les équipes de support observer les tendances de vos utilisateurs (fréquence d'utilisation, temps passé pour une action) évitant les designs non revus et solutions sur un coin de bureau qui pénalisent les utilisateurs au profit de la mise en production

corriger les bugs existants avant d'ajouter des nouvelles fonctionnalités meme les plus mineurs, sinon ils vont s'accumuler... on peut corriger en ne pas corrigeant n'ajoutez pas de nouvelles fonctionnalités sans revoir les décisions techniques, tous les problèmes ne sont pas toujours visibles, pensez a garder un œil sur les resources, les logs d'erreurs, et l'absence de log ou de consommation de resources

La qualité comme facteur de réduction des coûts, rien de plus coûteux que le temps passé par le support client et les équipes de dev pour résoudre les problèmes rencontrés par les utilisateurs

[raccourcir la boucle de feedback] Utiliser les revue de design (UX & solution technique) pour: - discuter les impacts sur les utilisateurs - discuter la nécessité / priorité (c'est le meilleur moment pour changer d'avis) - tester sur papier les différents cas, surtout les cas d'erreurs - collecter le feedback des équipes supports

[accélérer la mise en production] [raccourcir la boucle de feedback] Petits incréments au plus tôt: - revue de design des que possible pour commencer les développements en parallèle - build en continue pour commencer les tests exploratoire des que possible - déploiement au plus tot pour avoir le design selon les retours utilisateurs

La qualité comme facteur d'amélioration des revenus, quelque soit le budget marketing, des utilisateurs insatisfaits ne génèrent pas de revenu, mais plutôt des revues négatives qui peuvent déterrer de futures utilisateurs une mauvaise reception nécessite un budget plus important en support

[raccourcir la boucle de feedback] Utiliser les interview d'utilisateurs: - collecter les avis sur de futurs changements - identifier les points douloureux

[raccourcir la boucle de feedback] Utiliser les revue de design (UX & solution technique) pour: - discuter les impacts sur les utilisateurs - identifier les différents cas, surtout les cas d'erreurs - collecter le feedback des équipes supports

[raccourcir la boucle de feedback] Tester la localisation pour: - éviter une mauvaise expérience utilisateurs (traductions confuses or incorrectes) - éviter une mauvaise perception de votre produit (traduction par la machine)

[accélérer la mise en production] Utiliser un design system pour: - réduire le temps sur le design et le développement de l'interface - réduire le temps d'apprentissage des nouvelles fonctionnalités (ergonomie) - réduire les risques de bugs

[raccourcir la boucle de feedback] Utiliser messages d'erreur explicites - trop souvent traités en 2nde classe - pour: - réduire le temps de résolution avant la prod et en prod - réduire les coût du support client - certaines erreurs peuvent être résolu sans support

[atténuer les goulots d'étranglement] Automatiser des tâches pour libérer le temps de vos équipes, par exemples: - pipeline de déploiement - surveillances des resources (alerte) - réparation des incidents - automatisation des traductions - automatisation des tests - generation de la documentation

[accélérer la mise en production] Utiliser les feature toggles pour: - déployer avec des incertitudes et réduire le temps en tests - stopper les problèmes en production et réduire le temps en support

[accélérer la mise en production] Utiliser les tests exploratoire - réduire le temps passé à maintenir des cas de tests - augmenter le temps sur l'execution des tests - ajuster rapidement le périmètre de tests

[raccourcir la boucle de feedback] Communiquer avec les équipes support, ce sont vos meilleurs alliés: - informer au plus tot des changements pour anticiper le besoin de support - identifier les problèmes les plus frequents pour les réduire

[atténuer les goulots d'étranglement] Les roadmaps doivent être transparentes: - chacun doit comprendre pourquoi on décide de faire quelque chose - important de comprendre les impacts si on ne le fait pas, ou si on est en retard - les autres équipes doivent pouvoir alerter les risques de conflits, pensez finances, juridique, support client... pas seulement équipe techniques Avec plus d'une application, il est facile d'avoir plusieurs fonctionnalités majeurs planifiées dans la même période: - risque de surcharge des équipes support - risque de ralentissement sur la résolution des bugs (on ne sait pas quel changement créer une régression) - perte de visibilité sur les métriques, quels changements affecte positivement les avis utilisateurs et lequel négativement

Si vos équipes traitent le role de testeurs comme celui/celle qui teste avant la prod alors vous allez perdre: - compréhension du métier - retour interne utilisateur - temps, beaucoup de temps

Cela va sembler simple, mais pour réussir sa culture qualité il faut avoir les bonnes fondations

Assurez vous que vous partager les meme objectifs a court terme: jour, semaine, mais aussi a plus long terms (iteration, release) Évitez l'implicites, soyez explicite dans vos priorités, résultats attendus, délais Privilégiez la communication directe (synchrone ou asynchrone) plutôt que l'indirecte (notifications, message sans destinataire)

Est-ce encore nécessaire d'insister sur le fait de travailler à taille humaine?

Utilisez les rétrospectives non pas comme un outil pour célébrer ou féliciter du travail bien fait mais comme un outil actionable, documenter vos décisions et mettez les en place

Si vous pensez à embaucher un testeur, demandez vous pourquoi? - vous ne savez pas quoi tester, alors il est sûrement temps d'abandonner le produit - vous n'avez pas le temps de tester, alors il est sûrement temps d'abandonner le produit - vous voulez accélérer la mise en production, mais à court d'idée, vous avez peut être besoin d'un coach qualité - vous voulez accélérer réduire les coûts, mais à court d'idée, vous avez peut être besoin d'un coach qualité - vous passez trop de temps à tester, vous avez peut être besoin d'un coach qualité

Ce sont nos prochaines étapes dans ma division

On va documenter nos processus, pour: - aider les nouveaux membres à monter en compétence rapidement - identifier les écarts et les absences - éviter les implicites

On passer plus de temps sur la conception a documenter nos decisions, revoir la solution, pour: - identifier les écarts et les absences sur la compréhension du besoin - améliorer nos estimations - découper les fonctionnalités en petite livraisons - ajuster l'architecture existante

On va faire plus de test d'intégration automatisés pour: - renforcer les contrats d'interface - réduire les dépendances de test (fameux tests de bouts en bouts) - tester plus tot - réduire les tests manuels

On veut communiquer plus efficacement entre équipes: - réduire les échanges JIRA - ajuster rapidement les priorités - communiquer avec les équipes en dehors de l’ingénierie: finance, juridique, marketing, support, ...