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


12

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?


Avec beaucoup de grognements et de jurons sous mon souffle>. <Après tout, ils me paient ....
Rachel

Réponses:


16

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.


2
Eh bien, ils paient, mais nous aimerions vraiment nous concentrer sur les demandes de fonctionnalités plus importantes qu'ils finiront par utiliser (et cela pourrait nous attirer plus de clients à l'avenir) plutôt que sur de nombreuses petites demandes triviales qui ne font qu'encombrer le code.
Earlz

8
@Earlz - "Nous aimerions vraiment nous concentrer sur ..." - Je suis sûr que vous ne seriez pas ainsi que les relations avec les clients fonctionnent. Ces petites demandes (qui peuvent ajouter une valeur significative au client) sont le prix à payer pour se mettre au travail sur les plus gros trucs. Ils ont besoin d'un fournisseur qui réponde à leurs besoins, pas de ceux qui choisissent et choisissent. La solution consiste à les évaluer équitablement, mais à souligner que les regrouper dans des versions plus importantes est rentable (moins de tests de régression, etc.) et essayer de rendre plus attrayant leur traitement de cette manière, mais vous ne pouvez pas prends et choisis.
Jon Hopkins

2
Si vous pouvez réduire les coûts de 50% en perdant 5% de clients, c'est une bonne affaire, selon la sagesse conventionnelle. Ces champs personnalisés sont-ils vraiment beaucoup de sueur pour peu de récompense?
9000

5
Il y a une mauvaise tendance dans le développement de logiciels pour les développeurs de ne pas vouloir faire ce que le client veut, car ce n'est pas cool ou amusant. Nous, les développeurs, avons tendance à mettre notre propre bonheur avant les désirs du client presque partout. Cependant, ce n'est pas notre plaisir et notre plaisir. Il s'agit du client. Le client est celui qui paie les factures, vous feriez mieux de le rendre heureux. Si vous êtes en train d'écrire des logiciels personnalisables, cela fait partie du travail.
John Kraft

3
@Wayne M merci d'avoir démontré l'attitude à laquelle je faisais référence. Les clients peuvent ne pas comprendre la technologie, mais ils ne sont généralement pas idiots. C'est généralement le développeur qui ne comprend pas les besoins de l'entreprise. De plus, si l'ajout d'une fonctionnalité compromet l'intégrité de l'application, c'est un signe de mauvaise conception de l'application.
John Kraft

3

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.


3

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.


3

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.


Cette application est trop complexe pour ajouter une telle fonctionnalité sans une énorme refonte. Cette solution est donc sortie (mais prévue dans une mise à jour majeure de la version qui devrait arriver dans un an, espérons-le)
Earlz

1
Si vous pouvez gérer cela en un an, quel est le problème?
JeffO

@Jeff un an en supposant que nous ne soyons pas enlisés par ces demandes de fonctionnalités dans le même temps .. Une année de développement ininterrompu en gros
Earlz

1

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!"


2
N'oubliez pas que derrière chaque problème se trouve une opportunité de trouver une solution, puis de la vendre à quelqu'un;)
MattC

0

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.


0

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.


0

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.


Les méthodes Kanban ne fonctionnent que lorsque vous pouvez vous rendre au Gemba: l'endroit où le problème se produit. Soyez dans l'espace physique, parlez aux gens qui font le travail, regardez-les vous montrer comment ils le font. Voyez avec vos yeux, touchez avec vos doigts. Ensuite, et alors seulement, essayez de trouver comment l'améliorer. Et demandez-leur comment l'améliorer.
Christopher Mahan

@Christopher - point pris, mais le système pourrait sûrement être modifié dans une certaine mesure. Oubliez peut-être le Kanban, mais essayez de conserver l'idée d'un système de traction. Peu importe comment cela fonctionne spécifiquement, l'utilisateur doit avoir un moyen de hiérarchiser les tâches et de choisir celle qui sera effectuée ensuite dans un environnement où le développement est continu. Un développeur n'a aucun moyen de vraiment savoir quelle fonctionnalité doit être exécutée par lui-même.
Morgan Herlocker

1
Ironcode, vous avez raison. Je travaille chez Bank of America et notre équipe permet à l'unité commerciale de prioriser les demandes de fonctionnalités via la priorité de bug bugzilla. Ils classent les bogues, puis hiérarchisent les bogues. Ils peuvent changer la priorité à tout moment, et nous nous ajustons. Oui, il entraîne parfois des frais de changement de fournisseur, mais nous avons constaté qu'il était plus efficace pour l'entreprise. Notez que cela ne fonctionnerait probablement pas pour l'affiche originale, car la direction peut avoir des objectifs pour ceux de ses clients. (à part, cette approche de gestion semble erronée)
Christopher Mahan

0

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.


Nous l'avons fait. C'est pourquoi nous savons quand les demandes de fonctionnalités ne seront probablement pas utilisées.
Earlz

Ah, eh bien, il y a des combats politiques dans l'entreprise cliente. Vous êtes foutus. Ou vous pourriez les Steaks et Strippers eux.
Christopher Mahan

0

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.


0

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

0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.