Dans cet article, je partagerai mon expérience dans la sélection d'idées pour développer la fonctionnalité de nos produits et vous expliquerai comment conserver les principaux vecteurs de développement.
Nous développons un système de facturation automatisé (ASR) - facturation. Durée
La durée de vie de notre produit est de 14 ans. Pendant ce temps, le système est passé des premières versions de tarification industrielle à un complexe modulaire composé de 18 produits qui se complètent. L'un des aspects les plus importants de la longue durée de vie des programmes est le développement continu. Et pour le développement, des idées sont nécessaires.
Des idées
Les sources
Il existe 5 sources:
- Le principal ami du développeur de systèmes d'information d'entreprise est le client . Et le client est une image collective de décideurs, de promoteurs de projets, de propriétaires et de cadres de processus, de spécialistes informatiques de la maison, d'utilisateurs ordinaires et d'un grand nombre de personnes différemment intéressées. Il est important pour nous que chacun des représentants du client soit potentiellement un fournisseur d'idées. Dans le pire des cas, nous n'obtenons que des commentaires négatifs sur les problèmes du système. Au mieux, du côté du client, il y a une personne qui est une source constante d'idées d'amélioration, fournissant des informations structurées sur les besoins du client.
- Nos vendeurs et gestionnaires de comptes sont la deuxième source d'idées d'amélioration la plus importante. Ils communiquent beaucoup avec les représentants de l'industrie et reçoivent activement des demandes directes de fonctionnalité de facturation de clients potentiels. Les vendeurs et les comptes doivent être conscients de tous les changements importants dans leurs fonctionnalités et des dernières mises à jour logicielles des concurrents, pour pouvoir justifier les avantages et les inconvénients des différentes solutions. Ce sont nos employés qui sont les premiers à ressentir si certaines capacités de facturation deviennent une norme de facto, sans lesquelles le logiciel ne peut être considéré comme complet.
- Le chef de produit est l'un de nos top managers ou un chef de projet très expérimenté. Il garde à l'esprit les objectifs stratégiques de l'entreprise et ajuste les plans de développement de produits en conséquence.
- Un architecte , une personne qui comprend les possibilités et les limites des solutions technologiques sélectionnées / utilisées et leur impact sur le développement de produits.
Développement, équipes de tests. Personnes directement impliquées dans le développement de produits.
Classification des appels
Des sources, nous recevons des données brutes - lettres, tickets, demandes verbales. Tous
les appels sont classés:
- Consultations avec le sens de "Comment faire?", "Comment ça marche?", "Pourquoi ça ne marche pas?", "Je ne comprends pas ...". Ce type d'appel est dirigé vers la ligne d'assistance de niveau 1. Re-qualification possible de la consultation dans d'autres types d'applications.
- Incidents avec la signification de «ne fonctionne pas» et «erreur». Géré par 2 et 3 lignes de support. Si nécessaire, une correction rapide et la publication du correctif peuvent être transférées du support immédiatement au développement. Il est possible de se recycler dans une demande de modification et de l'envoyer au backlog.
- Demandes de changement et de développement . Entrez dans le backlog du produit en contournant les lignes d'assistance. Mais pour eux, il existe une procédure de traitement distincte.
Il existe de telles statistiques sur les appels - immédiatement après la publication, le nombre d'appels augmente de 10 à 15% pendant une courte période. En outre, des rafales d'appels se produisent lorsqu'un nouveau client avec un grand nombre d'utilisateurs vient à nos services cloud. Les gens apprennent à utiliser les nouvelles fonctionnalités du logiciel, ils ont besoin de conseils. Même un petit client au début du travail dans le système brûle facilement plus de 100 heures de consultations par mois. Par conséquent, lors de la connexion d'un nouveau client, nous réservons toujours du temps pour les consultations initiales. Souvent, nous mettons même en évidence un spécialiste spécifique. Le coût du loyer, bien sûr, ne rembourse pas ces coûts de main-d'œuvre, mais avec le temps, la situation se stabilise. La période d'adaptation prend, en règle générale, de 1 à 3 mois, puis le besoin de conseil est considérablement réduit.
Auparavant, nous utilisions des solutions auto-écrites pour stocker les appels. Mais progressivement passé aux produits Atlassian. Tout d'abord, nous avons développé le développement pour faciliter le travail sur Agile, puis le support. Maintenant, tous les processus critiques vivent dans Jira SD, et ils sont fournis par divers plugins pour Jira, plus Confluence. Les solutions auto-écrites ne sont restées que sur des processus qui n'étaient pas critiques pour les activités de l'entreprise. Il s'est avéré que nos tâches sont désormais transversales, peuvent être transférées entre support et développement sans passer d'un système à un autre.
À partir de cet ensemble, nous pouvons obtenir des données sur toutes les tâches, les coûts de main-d'œuvre prévus et réels, utiliser diverses options de tarification pour les clients et générer une documentation pour les besoins internes et faire rapport aux clients.
Traitement des demandes de changement
En règle générale, ces demandes se présentent sous la forme d'exigences fonctionnelles. Notre analyste étudie la demande, génère une spécification et des TdR de haut niveau. Il transmet la spécification et l'énoncé des travaux à la personne qui a soumis cette demande d'approbation - nous devons nous assurer que nous parlons la même langue avec le client.
Après avoir reçu la confirmation du client que nous nous comprenons bien, l'analyste écrit la demande dans le backlog produit.
Gestion des produits
Le backlog accumule les demandes entrantes de changement et de développement. Tous les six mois, un conseil technique est réuni, composé d'un directeur, de la maintenance, du développement, des ventes et des architectes système. Dans le format de discussion, le forum analyse et hiérarchise les applications du backlog et coordonne 5 tâches de développement pour la mise en œuvre dans la prochaine version.
En effet, le conseil technique répond aux exigences de l'industrie et du marché, compte tenu des besoins enregistrés dans les candidatures. Tout ce qui a peu de pertinence reste dans l'arriéré et n'atteint pas le développement.
Classification des demandes de changement et des finances
Le développement coûte cher. Par conséquent, nous vous dirons immédiatement quelles options nous pouvons avoir si la demande de changement provient d'un client et non d'un employé.
Les demandes de changement sont classées comme suit: besoins de l'industrie ou caractéristiques individuelles de l'entreprise; quantité importante de nouvelles fonctionnalités ou petite correction. Les petits correctifs et les demandes individuelles sont traités sans fioritures. Les demandes individuelles sont calculées et mises en œuvre pour un client particulier dans le cadre du travail de projet avec lui.
Si ce n'est pas un besoin massif de l'industrie et que l'étendue des fonctionnalités est grande, alors une décision peut être prise pour développer un nouveau module séparé, qui sera vendu en plus de la fonctionnalité principale. Si une telle demande est reçue du client, nous pouvons assumer les coûts de développement du module, fournir au client le module gratuitement ou avec paiement partiel, et mettre le module en vente publique. Le client assume une partie de la charge méthodologique dans une telle situation et réalise essentiellement l'implémentation pilote du module.
S'il s'agit d'un besoin massif de l'industrie, une décision peut être prise pour inclure de nouvelles fonctionnalités dans le produit de base. Dans ce cas, les coûts nous incombent entièrement et la nouvelle fonctionnalité apparaît dans la version actuelle des programmes.
Les anciens clients reçoivent une mise à jour.
Il se peut également que plusieurs clients aient un besoin similaire, mais cela n'attire pas un produit de masse. Dans ce cas, nous pouvons envoyer la spécification à ces clients et proposer de partager les coûts de développement entre eux. En conséquence, tout le monde gagne: les clients reçoivent la mise en œuvre de la fonctionnalité à faible coût, nous enrichissons le produit, après un certain temps, les autres acteurs du marché peuvent également recevoir la fonctionnalité pour leur utilisation.
Devops
Le développement prépare deux versions majeures par an. Dans chaque version, du temps est réservé à la mise en œuvre de 5 tâches reçues du conseil technique. Ainsi, pour le fluide, nous n'oublions jamais le développement du produit.
Chaque version réussit un ensemble approprié de tests et de documentation. De plus, cette version est installée dans l'environnement de test du client correspondant, qui, à son tour, vérifie minutieusement tout et seulement après que la version est traduite en production.
En plus du système de publication, il existe un format de correction rapide des bogues afin que les clients ne vivent pas avec des erreurs pendant six mois. Ce format provisoire vous permettra de répondre rapidement aux incidents de première priorité et de respecter le SLA déclaré.
Tout ce qui précède est vrai principalement pour le secteur des entreprises et les solutions sur site. Pour les services cloud axés sur le segment des PME, il n'y a pas de telles opportunités pour les clients de participer au développement du produit. Le format de bail pour SMB ne le suggère même pas. Au lieu d'une demande de changement sous la forme d'exigences claires de la part de l'entreprise, voici juste les commentaires et souhaits habituels pour le service. Nous essayons d'écouter, mais le produit est énorme et le désir d'un client d'apporter quelque chose de familier de son ancien système historique peut contredire la stratégie de développement du système dans son ensemble.