États et Requêtes dans un Projet: avantages et inconvénients
2 réponses
Réal Phil
Bonjour,
Je suis =E0 consid=E9rer la possibilit=E9 de laisser certains clients plus =
avanc=E9s utiliser =C9tats et Requ=EAtes dans certaines applications.
Je sais que certains clients plus exp=E9riment=E9s en seraient ravis mais j=
'ai toujours eu une certaines appr=E9hensions que j'aimerais clarifier avec=
ceux qui ont une certaine exp=E9rience sur le sujet.
On d=E9voile n=E9cessairement au client la majorit=E9 des champs des fichie=
rs HyperFiles comme ceux du journal des ventes (ent=EAte et d=E9tails des l=
ignes), des dossiers clients et des produits, des comptes =E0 recevoir, etc=
...
Mais, cela a-t-il de l'importance dans un sens comme dans l'autre ?=20
Les clients auront-ils souvent tendance =E0 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=E9s =
et qu'il y a des frais pour toute assistance alors =E7a peut =EAtre mon=E9t=
airement avantageux pour le d=E9veloppeur. Mais si les clients consid=E8ren=
t que cette fonction fait partie du logiciel et que =E7a devrait fonctionne=
r alors que =E7a ne fonctionne pas alors ils seront frustr=E9s de devoir pa=
yer en pr=E9tendant que le logiciel ne fonctionne pas.
J'appr=E9cierais beaucoup recevoir vos avis sur cette question.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Eric Demeester
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
dans (in) fr.comp.developpement.agl.windev, Réal Phil <realmip@yahoo.ca>
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.
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
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 ?
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 ?
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 ?
