De nombreux experts dans le domaine du développement de logiciels estiment qu'il est impossible de combiner développement et assistance aux utilisateurs au sein d'une même équipe. Soit l'un soit l'autre. En général, un soutien devrait être fourni aux individus.
Aujourd'hui, je veux vous expliquer comment, à Odobrim.ru, nous avons réussi à combiner l'incompatible, ou plutôt, comment l'équipe de développement peut prendre en charge les produits. Cela doit être 2-3 lignes de support en même temps.
Odobrim.ru est un service en ligne gratuit de sélection de cartes de crédit, de prêts et de prêts aux particuliers, indépendant des banques.
Notre tâche : aider le client à obtenir et à maintenir le produit de prêt optimal qui résout les tâches du client.
Le processus de traitement des appels est structuré comme suit
1. «Customer Care Service» prend soin de nos clients - la première ligne d'assistance. Oui, oui, dans les bons endroits ça existe :))
Le "Service à la clientèle" aide les utilisateurs à répondre à toutes les questions qui se posent lorsqu'ils travaillent avec le service. Toute entreprise qui se soucie de ses clients devrait avoir une première ligne d'assistance, que vous pouvez contacter 24h / 24 pour obtenir de l'aide.
Si le «Service client» a pu aider le client, la ligne suivante ne démarre pas. Sinon, l'appel est lancé et transmis à la ligne suivante. Rien de surnaturel jusqu'à présent.
Et après cela, il y a généralement deux autres lignes de support, mais nous en avons une: nous combinons les deuxième et troisième lignes de support. Cela s'est produit après que le produit est entré sur le marché, et nous vivons donc depuis environ deux ans. Et nous vivons parfaitement bien!
2. Le suivi des demandes des utilisateurs est effectué régulièrement.
L'ingénieur en service est appelé volontairement pour un appel hebdomadaire.
Un tableau de référence est similaire à un tableau Kanban.
Tout y est très bien configuré:
3. Le classement initial de l'appel est effectué par l'ingénieur de service et, sur la base de ses résultats, il est créé séparément Bug (bug en référence à la documentation / exigences) ou Story (tâche). Ils sont attachés à la circulation. Nous avons les délais pour corriger les erreurs et le préposé s'efforce de les rattraper.
4. À l'étape suivante, le bogue corrigé est corrigé par les développeurs (bloqueur, critique). Ensuite, la vérification et la confirmation de la correction sont effectuées par l'ingénieur de service
5. L'histoire (tâche) est transférée au PO (propriétaire du produit) pour la hiérarchisation.
Depuis 2 ans, l'équipe de développement a traité plus de 270 appels de priorités différentes de notre business unit et des utilisateurs parmi ceux que la première ligne de support n'a pas pu traiter.
Avantages de cette approche
- Les appels des clients et des unités commerciales ne sont pas perdus et sont collectés sur une seule carte.
- L'équipe voit tous les principaux problèmes du produit et souhaite les résoudre, c'est-à-dire qu'elle se rapproche des utilisateurs de son service, ce qui affecte positivement la qualité du service et le produit dans son ensemble.
- Chaque développeur, se rendant compte qu'il devra être de service lors des appels, essaie de mieux écrire le code afin de ne pas créer de problèmes supplémentaires pour lui et ses collègues.
- Il y a toujours un ingénieur responsable.
- L'implication de l'équipe dans la résolution des problèmes de produits courants augmente.
- Surveillance constante sans réglementations supplémentaires.
Inconvénients de cette approche
Les membres de l'équipe doivent faire preuve d'un haut niveau de professionnalisme, de responsabilité et d'intérêt. Et le courage d'être appelé en service.
Si vous avez rencontré des schémas d'organisation de soutien similaires, partagez votre expérience dans les commentaires.