Dans cet article, je vais partager mon expérience de sélection d'idées pour le développement des fonctionnalités de nos produits et vous dire comment conserver les principaux vecteurs de développement.
Nous développons un système de règlement automatisé (ACS) - facturation. Terme
La durée de vie de notre produit est de 14 ans. Pendant ce temps, le système est passé des premières versions d'un évaluateur industriel à un complexe modulaire composé de 18 produits qui se complètent. L'un des aspects les plus importants de la longévité des programmes est le développement continu. Et les idées sont nécessaires pour le développement.
Des idées
sources
Il existe 5 sources :
- Le principal ami du développeur de systèmes d'information d'entreprise est client. Et le client est une image collective de décideurs, de porteurs de projets, de propriétaires et d'exécuteurs de processus, d'informaticiens internes, d'utilisateurs ordinaires et d'un grand nombre de personnes intéressées à des degrés divers. 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, il y a une personne côté client qui est une source constante d'idées d'amélioration, fournissant des informations structurées sur les besoins du client.
- Notre vendeurs et gestionnaires de comptes sont la deuxième source la plus importante d'idées d'amélioration. Ils communiquent beaucoup et activement avec les représentants de l'industrie, reçoivent des demandes directes de fonctionnalités de facturation de la part de clients potentiels. Les commerçants et les comptes doivent être au courant de tous les changements significatifs de leurs fonctionnalités et des dernières mises à jour logicielles des concurrents, être en mesure de justifier les avantages et les inconvénients des différentes solutions. Ce sont ces employés qui sont les nôtres qui sont les premiers à sentir si certaines fonctionnalités de facturation deviennent un standard de facto, sans lequel le logiciel ne peut être considéré comme complet.
- Propriétaire du produit l'un de nos top managers ou un chef de projet très expérimenté. Garde à l'esprit les objectifs stratégiques de l'entreprise et ajuste les plans de développement de produits en fonction de ceux-ci.
- Architecte, une personne qui comprend les possibilités et les limites des solutions technologiques choisies/utilisées et leur impact sur le développement de produits.
Equipes de développement et de tests. Les personnes qui sont directement impliquées dans le développement de produits.
Classement des hits
Nous recevons des données brutes de sources - lettres, tickets, demandes orales. Tous
les recours sont classés :
- consultations avec le sens "Comment faire ?", "Comment ça marche ?", "Pourquoi ça ne marche pas ?", "Je ne comprends pas...". Les appels de ce type sont dirigés vers la ligne d'assistance de niveau 1. Il est possible de réorienter la consultation vers d'autres types de recours.
- Incidents avec la signification "Ne fonctionne pas" et "Erreur". Prise en charge par 2 et 3 lignes de support. S'il est nécessaire de corriger et de publier rapidement un correctif, il peut être transféré directement du support au développement. Il est possible de le reclasser en demande de changement et de l'envoyer dans le backlog.
- Demandes de modifications et de développement. Entrez dans le carnet de 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 visites - immédiatement après la sortie, le nombre de visites augmente de 10 à 15% pendant une courte période. Il y a aussi des rafales d'appels lorsqu'un nouveau client avec un grand nombre d'utilisateurs vient à nos services cloud. Les gens apprennent à utiliser de nouvelles fonctionnalités logicielles, ils ont besoin de conseils. Même un petit client, lorsqu'il commence à travailler 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 choisissons même 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, après quoi le besoin de conseil est considérablement réduit.
Auparavant, nous utilisions des solutions auto-écrites pour stocker les appels. Mais progressivement basculé vers les produits Atlassian. D'abord, le développement a été transféré pour faciliter le travail en Agile, puis le support. Désormais, tous les processus critiques vivent dans Jira SD, et ils sont fournis avec divers plugins pour Jira, ainsi que Confluence. Les solutions auto-écrites ne sont restées que sur les processus non critiques pour les activités de l'entreprise. Il s'est avéré que nos tâches sont maintenant de bout en bout, elles peuvent être transférées entre le support et le développement sans sauter d'un système à l'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 facturation pour les clients et générer une documentation pour les besoins internes et un rapport aux clients.
Traitement des demandes de modification
En règle générale, ces demandes se présentent sous la forme d'exigences de fonctionnalités. Notre analyste étudie la demande, génère un cahier des charges et un TDR de haut niveau. Transfère la spécification et les termes de référence à la personne qui a soumis cette demande pour approbation - nous devons être sûrs que nous parlons la même langue avec le client.
Après avoir reçu la confirmation du client que nous nous sommes bien compris, l'analyste inscrit la demande dans le backlog produit.
Gestion des fonctionnalités du produit
Le backlog accumule les demandes de changement et de développement reçues. Une fois tous les six mois, le conseil technique, composé du directeur, des responsables de la maintenance, du développement, des ventes et de l'architecte système, se réunit. Dans le format de discussion, le conseil analyse et hiérarchise les applications du backlog et convient de 5 tâches de développement à mettre 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 applications. Tout ce qui est peu pertinent reste dans le backlog et n'atteint pas le développement.
Classification des demandes de changement et finances
Le développement coûte cher. Par conséquent, nous vous dirons immédiatement quelles options nous pouvons avoir si une demande de changement provenait d'un client et non d'un employé.
Les demandes de modification sont classées comme suit : besoins spécifiques à l'industrie ou caractéristiques individuelles de l'entreprise ; une quantité importante de nouvelles fonctionnalités ou un petit correctif. Les petites corrections et les demandes individuelles sont traitées sans fioritures. Les demandes individuelles sont calculées et mises en œuvre pour un client spécifique dans le cadre du travail de projet avec lui.
S'il ne s'agit pas d'un besoin massif de l'industrie et que la quantité de fonctionnalités est importante, une décision peut être prise de 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 couvrir les coûts de développement du module, fournir au client le module gratuitement ou avec un paiement partiel et mettre le module dans le domaine public pour la vente. Dans une telle situation, le client assume une partie de la charge méthodologique et, de fait, réalise une mise en œuvre pilote du module.
S'il s'agit d'un besoin industriel massif, une décision peut être prise d'inclure de nouvelles fonctionnalités dans le produit de base. Les coûts dans ce cas sont entièrement à notre charge et la nouvelle fonctionnalité apparaît dans la version actuelle des programmes.
Les anciens clients reçoivent une mise à jour.
Il se peut aussi que plusieurs clients aient un besoin similaire, mais cela ne tire pas sur un produit de masse. Dans ce cas, nous pouvons envoyer le cahier des charges à ces clients et leur proposer de partager les coûts de développement entre eux. Au final, tout le monde y gagne : les clients obtiennent la mise en œuvre de la fonctionnalité à moindre coût, nous enrichissons le produit, après un certain temps, d'autres acteurs du marché peuvent également obtenir la fonctionnalité pour leur utilisation.
DevOps
Le développement prépare deux versions majeures par an. Dans chaque version, un temps est réservé à la mise en œuvre de 5 tâches reçues du conseil technique. Ainsi, derrière le chiffre d'affaires, on n'oublie jamais le développement du produit.
Chaque version passe par 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 tout méticuleusement, et seulement après cela, la version est transférée en production.
En plus du système de publication, il existe un format de corrections de bogues rapides afin que les clients ne vivent pas avec des erreurs pendant six mois. Ce format intermédiaire vous permettra de répondre rapidement aux incidents de première priorité et de respecter le SLA annoncé.
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'existe pas d'opportunités aussi vastes pour les clients de participer au développement de produits. 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 d'une partie de l'entreprise, il n'y a que les commentaires et les souhaits habituels pour le service. Nous essayons d'écouter, mais le produit est massif 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.
Source: habr.com