Je pense que vous n'avez pas bien compris mon propos. Et, si vous l'avez mal compris, c'est que je me suis mal exprimé. Ce qui m'ennuie, c'est qu'on est HORS DEBAT. Le cas eéchéant, je couperai la discussion...
Je vais donc me reprendre et vous allez voir que c'est évident. En tous cas, après en avoir débattu plusieurs heures avec le directeur informatique d'un grand groupe pharmaceutique, il a fini par acquiescer mon propos, ce qui me laisse à penser que je ne suis pas dans le faux...
Je dis :
- les développements longs sont un mal nécessaire pour avoir quelque chose de stable, bien pensé, perenne dans le temps
=>Je pense que, sur ce point, nous sommes d'accords - les développements faits par les utilisateurs sont des aberrations
* Ce n'est pas leur job, ils ont suffisamment de taff comme ça pour se rajouter ça sur le dos
* Ils n'ont pas la formation pour faire quelque chose d'efficace
* En cas de seuil de compétence ou de bug, c'est l'info qui récupère le bébé
=>Je pense que, là aussi, nous sommes d'accords - L'utilisateur doit pouvoir travailler sans attendre le bon vouloir de l'informatique, parce que c'est pour cela qu'il est payé
=>Personne ne s'oppose à ce point de vue je pense
Alors quid de cette idée de "coin de table" ?
Le service informatique devrait prévoir une équipe de VRAIS développeurs, intégrés à l'équipe informatique, qui ait :
Du point de vue de l'utilisateur, pour unique rôle, de répondre à son besoin immédiat, afin qu'il ne se préoccupe pas de programmation, mais de production.
=> Le programme est vite fait... et bien fait
=> le code est documenté
=> la convention de dénomination de l'entreprise est respectée
=> le SI garde la main sur le développement, puisqu'il n'est pas passé chez l'utilisateur
=> l'utilisateur n'endosse pas le rôle de développeur
Du point de vue du SI, pour rôle de remonter l'ensemble des besoins exprimé, mais également, les solutions mises en place.
=> l'ensemble de ces remontées sera recoupés par le nombre de demandes
=> sera priorisé
=> permettra la définition d'un cahier des charges
=> permettra une véritable analyse des véritables besoins des véritable utilisateur (pour éviter les développement SAP après audit des comptable pour un usage par le contrôle de gestion ... par exemple ...)
=> permettra donc d'implémenter des solutions perennes dans un SI stable, avec un développement à cycle long, et ce, sans avoir pénalisé, dans l'immédiat, l'utilisateur.
Du point de vue de l'entreprise, travaillant en tant qu'interface entre les utilisateurs et l'informatique, le fossé existant entre ces deux mondes va tendre à disparaitre car, le jour ou le développement cycle long, intégrant le besoin X exprimé 5 ans avant sera mis en prod, les membres du groupe pourront facilement identifier les personnels à l'origine de la demande et leur montrer à quel point leurs désirs ont été pris en compte, au point d'en faire un outil intégré à l'entreprise. D'autre part, en cas de changement important de la structure des données (par exemple) le groupe en question pourra intervenir directement sur leurs développement "coin de table" pour faire des mises à jour quasiment transparentes pour l'utilisateur final, ce qui permettra la maintenance, par des pros, d'applications, en attendant la prise en compte du besoin dans le SI.
On a donc, meilleure communication, donc meilleure collaboration, donc une meilleure ambiance, donc meilleure production. On a également une sécurité et une solidité des développement accrues. On a aussi une meilleure analyse des besoins puisqu'on est au plus près de l'utilisateur et qu'on récupère ses demandes au fil de l'eau.
Plus clair comme ça ?
Répondre avec citation
, naaan, allez, c'est juste pour troller )
Envoyé par mon nom est personne
)
Ben, ca ne me dérange pas ! Quand tu connaitras Access, tu changeras d'avis 
)
Partager