États et Requêtes dans un Projet: avantages et inconvénients

Le
Réal Phil
Bonjour,

Je suis à considérer la possibilité de laisser certains clients plus =
avancés utiliser États et Requêtes dans certaines applications.

Je sais que certains clients plus expérimentés en seraient ravis mais j=
'ai toujours eu une certaines appréhensions que j'aimerais clarifier avec=
ceux qui ont une certaine expérience sur le sujet.

On dévoile nécessairement au client la majorité des champs des fichie=
rs HyperFiles comme ceux du journal des ventes (entête et détails des l=
ignes), des dossiers clients et des produits, des comptes à recevoir, etc=

Mais, cela a-t-il de l'importance dans un sens comme dans l'autre ?

Les clients auront-ils souvent tendance à nous contacter pour se plaindre=
que cela ne fonctionne pas ou pour de l'aide ?

Si on prend entente que cette fonction est pour les utilisateurs avancés =
et qu'il y a des frais pour toute assistance alors ça peut être monét=
airement avantageux pour le développeur. Mais si les clients considèren=
t que cette fonction fait partie du logiciel et que ça devrait fonctionne=
r alors que ça ne fonctionne pas alors ils seront frustrés de devoir pa=
yer en prétendant que le logiciel ne fonctionne pas.

J'apprécierais beaucoup recevoir vos avis sur cette question.

Merci à l'avance.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Eric Demeester
Le #25284812
dans (in) fr.comp.developpement.agl.windev, Réal Phil ecrivait (wrote) :

Bonjour,

Je suis à considérer la possibilité de laisser certains clients plus
avancés utiliser États et Requêtes dans certaines applications.

Je sais que certains clients plus expérimentés en seraient ravis mais
j'ai toujours eu une certaines appréhensions que j'aimerais clarifier
avec ceux qui ont une certaine expérience sur le sujet.



Une première réponse, un peu à côté de la question, pourquoi ne pas
faire le test avec certains clients pour voir ce que ça donne ?

Dans un logiciel développé en des temps anciens, j'avais prévu dès le
départ les fonctions suivantes :

- un identifiant unique par client (numéro de licence) ;
- une gestion des droits en fonction de l'identifiant du client :
* accès ou nom à certains modules, en consultation et/ou en
modification.

Corollaire : un seul source à maintenir (je venais de migrer le projet
de DOS à Windows avec un source par client, m'étais dis « plus jamais
ça »), et des droits d'accès adapté en fonction des licences acquises
par les clients.

Donc, pour en revenir à ta question, si ton logiciel est organisé selon
le même schéma, tu développes le module d'utilisation « états et
requêtes », tu l'ouvres à quelques clients triés sur le volet en
précisant que c'est gratuit mais en test, et qu'en échange tu demandes
des remontées quant aux avantages, inconvénients, limitations, etc.

En gros, tu échanges la fourniture du bidule en béta-test contre la
promesse de remontée d'informations, de bugs, etc, et la gratuité finale
pour les heureux élus s'il est validé.

J'ai déjà pratiqué ce genre de démarche avec succès, avant de décider
d'inclure ou non un module complémentaire, soit de façon généralisée
lors de la mise à jour suivante, soit de façon sélective, gratuite ou
pas, auprès de tel ou tel client.

Mes deux centimes.

--
Eric
Réal Phil
Le #25285132
Bonjour Éric,

Merci d'avoir pris le temps de me répondre.
C'est une idée, je vais certainement considérer la possibilité de cet te approche.

Si on regarde l'aide de WD18 sur le sujet il y a quand même plusieurs cho ses à considérer si on active cette possibilité aux usagers.

D'autres ont-ils eu des mauvaises (ou des bonnes) expériences vécues en accordant cette "permission" d'utiliser le logiciel États et Requêtes par leurs client ?
Publicité
Poster une réponse
Anonyme