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

Le
Réal Phil
Bonjour,

Je suis considrer la possibilit de laisser certains clients plus =
avancs utiliser tats et Requtes dans certaines applications.

Je sais que certains clients plus expriments en seraient ravis mais j=
'ai toujours eu une certaines apprhensions que j'aimerais clarifier avec=
ceux qui ont une certaine exprience sur le sujet.

On dvoile ncessairement au client la majorit des champs des fichie=
rs HyperFiles comme ceux du journal des ventes (entte et dtails 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 avancs =
et qu'il y a des frais pour toute assistance alors a peut tre mont=
airement avantageux pour le dveloppeur. Mais si les clients considren=
t que cette fonction fait partie du logiciel et que a devrait fonctionne=
r alors que a ne fonctionne pas alors ils seront frustrs de devoir pa=
yer en prtendant que le logiciel ne fonctionne pas.

J'apprcierais beaucoup recevoir vos avis sur cette question.

Merci l'avance.
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