Comment gérer les demandes de type «pouvez-vous ajouter quelques champs supplémentaires» des clients?

Très souvent, nous avons des demandes de fonctionnalités pour les champs qu'un seul client souhaite. Au mieux, cela encombre le code de l'application. Souvent, lorsque nous regardons dans leur base de données quelques mois après avoir ajouté les champs, nous pouvons voir qu'ils n'utilisent même pas les champs supplémentaires. En outre, il s'agit d'une application assez ancienne, l'ajout d'un champ unique nécessite plusieurs modifications de code, la modification des rapports et la vérification que cela n'affecte pas les autres clients qui n'ont pas besoin de voir le champ.

• Comment pouvons-nous nous assurer qu'un client a réellement besoin de ces demandes de fonctionnalités?

• Comment dire poliment "vous n'avez pas vraiment besoin de ça"?

Actuellement, nous commençons à facturer certaines demandes de fonctionnalités. (Auparavant, les demandes de fonctionnalités étaient généralement gratuites) Y a-t-il autre chose que nous pouvons faire?

Payent-ils pour les fonctionnalités supplémentaires? Si c'est le cas, ce n'est vraiment pas votre affaire, qu'ils les utilisent ou non. Donnez-leur ce pour quoi ils paient. Si, cependant, ce n'est pas le cas, c'est à votre direction de décider si elle est disposée à continuer d'ajouter des fonctionnalités sans revenu supplémentaire.

Nous avons une situation similaire. La façon dont nous traitons est de construire une relation basée sur la confiance qui nous donne la liberté de dire "vous n'en avez pas besoin". Cela prend du temps, de la tranquillité et vous devez être prêt à parler beaucoup et à avoir des déjeuners et d'autres tâches ennuyeuses. Ces réunions ennuyeuses seront rentables à long terme où vous pourrez vous concentrer sur la création de fonctionnalités vraiment importantes.

Parler vous permettra également de voir si ce qu'ils demandent est vraiment important.

Je ne pense pas que vous puissiez entrer dans le "en avez-vous vraiment besoin?" discussion avec les clients. Personnellement, je voudrais demander: "Comment cela va-t-il faire gagner plus d'argent à votre entreprise?" mais le fait est que certains gestionnaires, pour une raison quelconque, veulent le suivre et ils ont l'habitude de faire leur chemin. Si vous ne voulez pas le faire, dites non ou facturez un montant aussi élevé pour décourager la demande.

Commencez à envisager des moyens de faciliter la gestion d'un plus grand nombre de champs clients par votre application.

1. Autoriser le client à définir des étiquettes dans les rapports et les formulaires pour utiliser les champs existants.
2. Ajoutez des champs génériques (String12) aux tables de champs personnalisées existantes ou supplémentaires.
3. Avoir un système de champs défini par l'utilisateur où tout cela est géré par la saisie de données et ne pas avoir à créer de nouvelles colonnes dans les tables (je ne me souviens pas de ce que cela s'appelle l'aide).

Vous constaterez peut-être que les clients existants dépassent votre système. L'industrie est peut-être en train de changer et de nouvelles exigences apparaissent.

Désolé, mais si vous ne pouvez pas offrir à vos clients ce qu'ils veulent uniquement pour des raisons techniques et sans but lucratif, vous devez accélérer le rythme. Il ne serait pas difficile pour un nouveau venu d'entrer sur votre marché avec plus de domaines, alors ne laissez pas cela se produire.

En regardant de l'autre côté de la fenêtre pendant un moment, lors de mon dernier travail, j'ai été exposé à un système ERP qui permettait à l'utilisateur final d'ajouter des colonnes "personnalisées" à n'importe quelle entité / table. D'après mes brèves interactions avec, il semblait qu'ils ajoutaient dynamiquement les colonnes à une deuxième table avec un mappage un à un. Par exemple:

Table WIDGET avec colonnes statiques:

• WIDGET_ID
• NOM DU WIDGET
• WIDGET_COST
• etc.

Table WIDGETCUSTOM avec colonnes définissables par l'utilisateur:

• WIDGET_ID
• WIDGET_WEIGHT
• DID_BOB_WORK_ON_WIDGET
• etc.

La colonne WIDGET_ID pourrait les lier ensemble. Il montrait automatiquement vos champs supplémentaires lorsque vous éditiez un widget, et vous pouviez les inclure dans des rapports dynamiques, ou même rechercher par eux. C'était assez efficace car la base de données pouvait toujours les suivre et indexer ces colonnes si nécessaire, etc.

Du point de vue de la programmation, je vois comment cela pourrait rester sain d'esprit. Chaque client peut avoir ses propres colonnes personnalisées, mais ces colonnes personnalisées n'interfèrent pas avec votre logique principale.

Les «demandes» de fonctionnalités ne sont que des demandes. S'ils font des demandes, vous devez décider combien cela vaut pour l'entreprise de "surcharger" la base de code avec cela. Si cela devient un problème endémique, vous pouvez y remédier, mais s'ils sont prêts à payer ce que vous demandez ou quelque chose de proche et que ce ne sont que quelques fonctionnalités ici et là, je dis allez-y avec l'argent.

Pour aller encore plus loin, s'il s'agit d'un problème constant avec votre produit et que plusieurs clients recherchent ce type de personnalisations, il est peut-être temps de repenser ces parties de votre application et de les rendre flexibles de manière à ce que les clients soient autorisés à le faire. eux-mêmes, que ce soit des rapports ad hoc, une collecte de données flexible, etc. Essayez de transformer ces désagréments en argument de vente. "Notre modèle de données boursières n'est pas assez bon pour vous? Découvrez nos options de personnalisation! Vous pouvez le faire vous-même!"

Vous devez spécifier exactement ce que vous allez faire dans ladite fonctionnalité et appliquer un temps estimé pour le construire. Si le client souhaite que des champs supplémentaires conviennent, facturez-le. Je dis à mes clients que si vous souhaitez ajouter des fonctionnalités après avoir créé la fonctionnalité, c'est bien, mais cela va coûter un peu plus cher pour les utiliser, dans certains cas.

J'ai du mal à comprendre pourquoi vous vous souciez qu'ils l'utilisent ou non. C'est simple, vous construisez ce qu'ils veulent et vous êtes payé pour cela.

Encombrement de la base de code? Si vous devez refactoriser votre code lorsque vous travaillez dans la nouvelle fonctionnalité, facturez-le.

Créez une liste de plusieurs fonctionnalités que vous envisagez d'ajouter, y compris l'ajout de "seulement quelques champs supplémentaires". Montrez la liste à vos clients et demandez-leur quels sont ceux qu'ils souhaitent en premier. Expliquez que vos ressources sont limitées et que vous ne pouvez pas tout faire en même temps. Utilisez les commentaires pour décider dans quelle direction vous souhaitez aller avec votre application.

Si un client insiste sur le fait que les quelques champs supplémentaires sont vraiment si importants et que vous décidez toujours de ne pas les ajouter, nous espérons que le client pourra toujours voir les avantages des fonctionnalités que vous implémentez à la place.

Il semble que vous pourriez bénéficier d'une sorte de système de traction. Laissez l'utilisateur choisir quelle fonctionnalité sera implémentée ensuite, mais limitez le nombre qui peut être en développement à un moment donné. Un tableau Kanban est formidable pour cela. Il peut donner à l'utilisateur la propriété du processus de priortisation (c'est-à-dire moins de responsabilité et de stress pour vous). Croyez-moi, si l'utilisateur est obligé de décider quelle fonctionnalité sera ensuite mise en développement, sachant que les autres demandes seront mises de côté, il investira beaucoup plus pour vraiment décider de ce qu'il doit avoir.

Je pense que vous devriez demander à votre client de passer un ou plusieurs d'entre vous dans une "journée au bureau" pour voir comment ils utilisent vraiment le logiciel ... Attendez ... Embauchez-moi pour 250 $ / heure et je vais le découvrir. De plus, veuillez ne pas plaquer d'or. Faites que ça marche. La plupart des entreprises se moquent du fait que ça a l'air moche quand ça marche bien.

Suivez les demandes. Au fur et à mesure que vous concevez / développez les grandes fonctionnalités, choisissez une poignée de demandes prioritaires à inclure dans cette version.

Construisez un système de négociation standard pour les demandes. Peut-être quelque chose basé sur un système de rapport de bogues ou de demande de fonctionnalité, comme fogbugz. Permettez à vos clients de déposer une demande et hiérarchisez-la en fonction de:

• la faisabilité technique / coût de la fonctionnalité
• la demande de fonctionnalité est-elle «payante»? Si c'est dans un contrat et / ou qu'ils l'ont payé, mettez-le
• la fonctionnalité a-t-elle du sens? C'est un peu un art, mais, généralement, si suffisamment de clients demandent une fonctionnalité, alors implémentez-la gratuitement. C'est l'occasion d'améliorer votre produit et de faciliter la vente au prochain client
• avez-vous des cycles payants inutilisés disponibles? Si vous incluez un ensemble d'heures mensuelles de maintenance / support dans vos contrats (je vous recommande fortement de le faire, même si le nombre est très faible), et qu'ils ne sont pas utilisés, commencez à les lancer pour effectuer ce genre de changements

Si le client est entièrement propriétaire de l'application, faites ce qu'il vous demande. Qu'ils dépensent leur argent; c'est le leur.

Cependant, si vous ne le faites pas, vous voulez aller à une solution pour ces champs auxiliaires qui implique de les stocker en dehors du modèle de données principal. Vous pouvez ensuite utiliser quelque chose comme une vue de base de données pour fusionner les champs supplémentaires pour ce client particulier. (Il existe plusieurs façons de faire le stockage auxiliaire, selon la nature des données stockées; la plus simple est simplement une table qui a la même clé primaire que certains PK dans votre table principale, mais cela est inefficace lorsque l'utilisation du champ est très clairsemé. Ce n'est vraiment un problème que lorsqu'ils veulent des fonctionnalités du champ qui nécessitent des choses comme l'indexation.)

Vous pouvez également différer les demandes des clients en disant que vous ne disposez pas de ressources suffisantes pour les mettre en œuvre à ce stade. Cela aide vraiment si à ce stade vous pointez votre feuille de route qui indique (votre meilleure estimation à) quand il sera possible de mettre en œuvre ce qu'ils veulent à moindre coût. Et vous devez donner la priorité d' obtenir l'application dans un état où il devient possible de soutenir les fonctionnalités à moindre coût, car ce méta-fonctionnalité devient une vente principale caractéristique de votre application principale.