Est ce qu'on vérifiait ca avant nous autres , lol ? On nous a juste habitué à vos CR a posteriori du coup on a cru que c'était partie intégrante de votre taf/mission
Mymi, les autres ont déjà parlé pour moi
Les métiers aiment qu'on leur mâchent le boulot après ce sont les mêmes qui vont se plaindre que ça ne marche pas (l'expression qui peut me tuer ).
kikou a écrit :Les métiers aiment qu'on leur mâchent le boulot après ce sont les mêmes qui vont se plaindre que ça ne marche pas (l'expression qui peut me tuer ).
J'aurais aimé ne pas avoir à l'écrire, mais c'est exactement le msg que je viens d'envoyer .
La vérité, les SI sont des embrouillés aussi hein: Soyez-sûrs de vos développements avant de nous demander de les tester, où bien?
Y a plein de facteurs.
1. C'est pas la magie.
2. On ne connait pas forcément vos métiers.
3. Blindez vos cahiers des charges ou adoptez les méthodes style Agile.
4. Lisez bien et validez les specs.
Merci
Mais le développement marche sinon on ne t'aurait pas envoye ca a tester. Lol.. Malheureusement nous on ne sait pas ce que ce l'application est censée faire! C'est pour ca qu'il faut bien expliquer EN DETAILS les business rules (ce que les metiers ne font JAMAIS)
oui je valide aussi tout ce que bichilla a dit. Tout ça me fait revenir à mon postulat de départ : je n'aime pas travailler avec les SI on dirait que c'est plus compliqué quand ce sont des internes, avec les externes c'est plutôt chap chap